28
Pertemuan VII

Perencanaan Proyek Software

  • Upload
    alvis

  • View
    103

  • Download
    7

Embed Size (px)

DESCRIPTION

Perencanaan Proyek Software. Pertemuan VII. :: Outline. Pendahuluan 5.1. Observasi pada estimasi 5.2. Tujuan perencanaan proyek 5.3. Ruang lingkup software 5.4. Sumber daya 5.5. Estimasi proyek software. :: Pendahuluan. - PowerPoint PPT Presentation

Citation preview

Page 1: Perencanaan Proyek  Software

Pertemuan VII

Page 2: Perencanaan Proyek  Software

Pendahuluan 5.1. Observasi pada estimasi 5.2. Tujuan perencanaan proyek 5.3. Ruang lingkup software 5.4. Sumber daya 5.5. Estimasi proyek software

Page 3: Perencanaan Proyek  Software

Proses manajemen proyek software dimulai dengan sekumpulan aktifitas yang disebut dengan “Project Planning”

Aktifitas pertama dalam Perencanaan Proyek adalah : “estimation”.

Saat estimasi dilakukan mulai melihat masa depan ;)

Page 4: Perencanaan Proyek  Software

Meski begitu, estimasi tidak bisa serampangan

Benar-benar ada teknik yang berguna untuk mengestimasi waktu dan usaha

estimasi dasar perencanaan Perencanaan peta jalan suskesnya RPL Sehingga tanpa estimasi, RPL tidak dapat

berjalan dengan sukses

Page 5: Perencanaan Proyek  Software

Estimasi sumber daya, biaya dan jadwal pengembangan software memerlukan :◦ pengalaman, ◦ akses informasi historis yang baik, ◦ keberanian melakukan pengukuran kuantitatif pada saat

data kualitatif tersebut ada.

“Project Complexity” mempunyai pengaruh yang kuat terhadap ketidakpastian perencanaan.

“Project size” merupakan faktor penting lainnya yang dapat mempengaruhi ketepatan estimasi.

“Problem decomposition” merupakan pendekatan yang penting untuk estimasi.

Page 6: Perencanaan Proyek  Software

Tingkatan “structural uncertainty” juga berpengaruh terhadap resiko estimasi. Struktur dalam hal ini adalah tingkatan kebutuhan, kemudahan fungsi yang akan dihasilkan dan informasi yang harus diproses.

Informasi historis juga berpengaruh terhadap resiko estimasi. Dengan mengetahui data-data yang lalu kita dapat mengoptimalkan pekerjaan dan menghindari hal-hal yang bisa menimbulkan persoalan.

Resiko diukur berdasar tingkatan ketidakpastian estimasi terhadap sumber daya, biaya, dan jadwal. Jika batasan proyek tidak jelas dan kebutuhan proyek senantiasa berubah maka hal ini bisa menimbulkan dampak yang membahayakan.

Page 7: Perencanaan Proyek  Software

Obyektif perencanaan proyek software adalah untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer untuk membuat estimasi yang bisa dipertanggung jawabkan mengenai sumber daya, biaya dan jadwal.

Estimasi ini dibuat dalam batasan waktu tertentu dan akan diupdate secara teratur disesuaikan dengan progres proyek.

Page 8: Perencanaan Proyek  Software

Aktifitas pertama Perencanaan Proyek Software adalah menentukan ruang lingkup software.

Ruang lingkup software menggambarkan :◦ function, ◦ performance,◦ constraint,◦ interfaces,◦ reliability.

Page 9: Perencanaan Proyek  Software

Function statement ruang lingkup dievaluasi & disaring sebagai

awalan estimasi. Estimasi biaya dan jadwal berorientasi secara fungsional. Beberapa tingkatan dekomposisi diperlukan.

Performance Mempertimbangkan proses yang harus dilakukan dan

waktu respons yang diperlukan.

Constraint Mengidentifikasi keterbatasan software terhadap perangkat

keras eksternal, memori maupun terhadap sistem lainnya yang sudah ada.

Page 10: Perencanaan Proyek  Software

Teknik umum yang biasa digunakan untuk mengatasi miskomunikasi antara customer dan developer serta untuk memulai proses komunikasi adalah dengan mengadakan “preliminary meeting” atau “interview”.

“Context free question” merupakan sekumpulan pertanyaan yang mengarah terhadap :◦ dasar pemahaman terhadap masalah, ◦ orang-orang yang menginginkan sebuah solusi,◦ solusi yang diinginkan◦ Efektifitas pertemuan itu sendiri.

Page 11: Perencanaan Proyek  Software

Pertanyaan pertama context free question difokuskan pada customer, goal dan benefit. Misal analis dapat menanyakan:

◦ Siapa yang menginginkan pekerjaan tersebut?◦ Siapa yang akan memakai solusi tersebut?◦ Apa saja keuntungan ekonomis yang akan

didapatkan jika solusi tersebut berhasil?◦ Adakah sumber daya lain untuk solusi tersebut?

Page 12: Perencanaan Proyek  Software

Pertanyaan berikutnya memungkinkan analis untuk menambah pemahaman persoalan dengan lebih baik dan customer menyampaikan persepsinya mengenai solusi yang diharapkan.

◦ Bagaimana anda(customer) menandai output yang baik yang akan dimunculkan oleh solusi baik tersebut?

◦ Problem apa saja yang akan diatasi oleh solusi tersebut?◦ Dapatkah anda menunjukkan lingkungan dimana solusi

tersebut akan dipergunakan?◦ Adakah performance khusus atau constraint yang

mempengaruhi solusi tersebut?

Page 13: Perencanaan Proyek  Software

Pertanyaan terakhir difokuskan pada efektifitas pertemuan tersebut :

◦ Apakah anda orang yang tepat untuk menjawab pertanyaan ini? Apakah jawaban anda merupakan jawaban yang “resmi”?

◦ Apakah pertanyaan saya relevan terhadap persoalan yang anda hadapi?

◦ Apakah pertanyaan saya terlalu banyak?◦ Apakah ada orang lain yang dapat menyediakan

informasi tambahan?◦ Apakah masih ada hal lain yang sebaiknya saya tanyakan

kepada anda?

Page 14: Perencanaan Proyek  Software

 Software yang akan dikembangkan adalah “Conveyor Line Sorting System” (CLSS).

Pernyataan ruang lingkup CLSS adalah sebagai berikut :

Page 15: Perencanaan Proyek  Software

“… CLSS mensortir kotak-kotak yang bergerak pada jalur conveyor. Masing-masing kotak ditandai dengan sebuah “Bar code” yang berisi nomer barang dan disortir kedalam salah satu dari enam buah BINS pada akhir jalur. Kotak-kotak tersebut melewati sebuah stasiun sortir yang terdiri dari sebuah “Bar Code Reader” dan sebuah PC. PC pada stasiun sortir tersebut terhubung dengan mekanis yang mensortir kotak-kotak tersebut kedalam BINS. Kotak-kotak tersebut lewat dengan urutan yang random. Jalur tersebut bergerak dengan kecepatan 5 feet per menit. … (cont)”

Page 16: Perencanaan Proyek  Software

“… Software CLSS menerima masukan informasi  dari sebuah bar code reader pada interval waktu yang sesuai dengan kecepatan jalur conveyor. Data dari bar code akan dikodekan menjadi format identifikasi kotak. Software tersebut akan mencocokkannya dengan database kode barang yang berisi maksimal 1000 data untuk menentukan lokasi BIN yang tepat untuk kotak yang saat itu sedang berada di Reader (stasiun sortir). Lokasi BIN yang tepat akan dilewatkan ke “Sorting Shunt” yang akan menempatkan kotak pada posisi yang tepat. Rekaman BIN tujuan untuk masing-masing kotak akan dimaintain untuk keperluan recovery dan reporting… (cont)”

Page 17: Perencanaan Proyek  Software

“… Software CLSS juga akan menerima input dari “Pulse Tachometer" yang digunakan untuk mensinkronkan sinyal kontrol dengan mekanik “shunting”. Berdasar jumlah pulsa yang dihasilkan antara stasiun sortir dan shunt, software akan menghasilkan sebuah sinyal kontrol untuk shunt untuk menempatkan kotak pada posisi yang tepat. (end)”

Page 18: Perencanaan Proyek  Software

Gambar : CLSS secara skematik

Page 19: Perencanaan Proyek  Software

Perencanaan proyek berikutnya menguji pernyataan ruang lingkup tersebut dan mengekstrak semua fungsi software yang penting. Proses ini disebut dengan “dekomposisi” dan menghasilkan fungsi sebagai berikut :

◦ Baca masukan dari bar code◦ Baca pulsa tachometer◦ Mengkodekan kembali data kode barang◦ Melaksanakan database lookup◦ Menentukan lokasi BIN◦ Menghasilkan sinyal kontrol untuk shunt◦ Memaintain record tujuan kotak.

Page 20: Perencanaan Proyek  Software

Dalam kasus ini, performance ditentukan oleh kecepatan jalur conveyor.

Proses setiap kotak harus diselesaikan sebelum kotak berikutnya sampai bar code reader.

Software CLSS terbatas oleh hardware yang harus diakses (bar code reader, shunt dan PC), memori, konfigurasi jalur conveyor.

Page 21: Perencanaan Proyek  Software

Tugas kedua perencanaan software adalah estimasi sumber daya yang diperlukan untuk pengembangan software.

Gambar : Sumber Daya

Page 22: Perencanaan Proyek  Software

Human Resource

Perencanaan mulai evaluasi ruang lingkup dan memilih keahlian yang dibutuhkan untuk pengembangan. Perencana harus menentukan posisi organisasional (misal: manajer, software enginer dll) dan speciality (misal: telecomunication, database, client /server).

Untuk proyek yang relatif kecil (6 orang-month atau kurang), seseorang bisa melaksanakan semua tahapan rekayasa software, konsultasi dengan cpesialis pada saat diperlukan.

Jumlah orang yang dibutuhkan untuk sebuah proyek software bisa ditentukan setelah adanya estimasi usaha untuk pengembangan (misal: person-month atau person-years).

Page 23: Perencanaan Proyek  Software

Reusable software resource

Ada 4 kategori software resource yang bisa dipertimbangkan pada perencanaan:

Off the self componentExisting software yang telah dibuat untuk pihak ketiga atau yang telah dikembangkan secara internal pada proyek sebelumnya yang mirip dengan software yang akan dibuat.

Full-experiencespesifikasi, kode , desain, atau pengujuan data yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan software yang akan dibangun pada proyek sat ini. Setiap anggota tim memiliki pengalaman penuh. Sehingga modifikasi yang dibutuhkan relatif beresiko rendah.

Page 24: Perencanaan Proyek  Software

Partial experience componentSpesifikasi, desain, kode atau data test yang telah dikembangkan pada proyek sebelumya berkaitan dengan software yang akan dikembangkan, akan tetapi memerlukan modifikasi. Substansinya, anggota tim software mempunyai pengalaman yang terbatas pada area aplikasi tersebut. Maka modifikasi pada partial experience component beresiko sedang.

New componentKomponen software yang harus dibuat oleh tim software adalah kebutuhan proyek yang sekarang.

Page 25: Perencanaan Proyek  Software

Environment Reusable Proyek

Lingkungan yang mendukung software disebut Software Environtment Enginering (SEE) baik hardware maupun software. Perencana proyek harus memperhatikan batasan waktu yang dibutuhkan hardware dan software dan memverifikasi resource-resource yang bisa dimanfaatkan.

Page 26: Perencanaan Proyek  Software

Untuk mendapatkan estimasi biaya dan effort yang bisa dipertanggung jawabkan, maka muncul sejumlah opsi:

1. Estimasi didelay sampai dengan akhir proyek (estimasi biaya akurat 100% jika proyek selesai).

2. Estimasi berdasarkan proyek serupa yang telah dikembangkan

3. Gunakan teknik dekomposisi yang sederhana untuk menghasilkan biaya dan effort proyek tersebut.

4. Gunakan satu atau beberapa model empiris untuk estimasi biaya dan effort software.

Page 27: Perencanaan Proyek  Software

selesai…

Page 28: Perencanaan Proyek  Software

Sebelum dilakukan diskusi ini mahasiswa yang dalam kelas dibagi menjadi beberapa kelompok sesuai kelompok tugas yang sudah dibentuk.

Adapun materi yang perlu didiskusikan setiap kelompoknya adalah :

Dari software aplikasi yang telah dibuat oleh masing-masing kelompok, diskusikan obyektif, ruang lingkup dan sumber daya yang diperlukan.