Perencanaan Proyek Software

1. PerencanaanProyek Software Pertemuan VII

2. :: Outline • Pendahuluan • 5.1. Observasipadaestimasi • 5.2. Tujuanperencanaanproyek • 5.3. Ruanglingkup software • 5.4. Sumberdaya • 5.5. Estimasiproyeksoftware

3. :: Pendahuluan • 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 ;)

4. :: Pendahuluan • 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

5. :: 5.1. Observasi pada estimasi • 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.

6. :: 5.1. Observasi pada estimasi • 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.

7. :: 5.2. Tujuan perencanaan proyek • 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.

8. :: 5.3. Ruang lingkup software • Aktifitas pertama Perencanaan Proyek Software adalah menentukan ruang lingkup software. • Ruang lingkup software menggambarkan : • function, • performance, • constraint, • interfaces, • reliability.

9. :: 5.3. Ruang lingkup 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.

10. :: 5.3.1 MendapatkanInformasiuntukmenentukanRuangLingkup. • 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.

11. :: 5.3.1 Mendapatkan Informasi untuk menentukan Ruang Lingkup. • 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?

12. :: 5.3.1 Mendapatkan Informasi untuk menentukan Ruang Lingkup. • 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?

13. :: 5.3.1 Mendapatkan Informasi untuk menentukan Ruang Lingkup. • 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?

14. :: 5.3.2 Contoh Pembuatan Ruang Lingkup. •  Software yang akan dikembangkan adalah “Conveyor Line Sorting System” (CLSS). • Pernyataan ruang lingkup CLSS adalah sebagai berikut :

15. :: 5.3.2 Contoh Pembuatan Ruang Lingkup. • “… 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)”

16. :: 5.3.2 Contoh Pembuatan Ruang Lingkup. • “… 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)”

17. :: 5.3.2 Contoh Pembuatan Ruang Lingkup. • “… 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)”

18. :: 5.3.2 Contoh Pembuatan Ruang Lingkup. • Gambar : CLSS secara skematik

19. :: 5.3.2 Contoh Pembuatan Ruang Lingkup. • 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.

20. :: 5.3.2 Contoh Pembuatan Ruang Lingkup. • 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.

21. :: 5.4. Sumber daya • Tugas kedua perencanaan software adalah estimasi sumber daya yang diperlukan untuk pengembangan software. • Gambar : Sumber Daya

22. :: 5.4. Sumber daya 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).

23. :: 5.4. Sumber daya Reusable software resource Ada 4 kategori software resource yang bisa dipertimbangkan pada perencanaan: • Off the self component Existing software yang telah dibuat untuk pihak ketiga atau yang telah dikembangkan secara internal pada proyek sebelumnya yang mirip dengan software yang akan dibuat. • Full-experience spesifikasi, 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.

24. :: 5.4. Sumber daya • Partial experience component Spesifikasi, 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 component Komponen software yang harus dibuat oleh tim software adalah kebutuhan proyek yang sekarang.

25. :: 5.4. Sumber daya 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.

26. :: 5.5. ESTIMASI PROYEK SOFTWARE • Untuk mendapatkan estimasi biaya dan effort yang bisa dipertanggung jawabkan, maka muncul sejumlah opsi: • Estimasi didelay sampai dengan akhir proyek (estimasi biaya akurat 100% jika proyek selesai). • Estimasi berdasarkan proyek serupa yang telah dikembangkan • Gunakan teknik dekomposisi yang sederhana untuk menghasilkan biaya dan effort proyek tersebut. • Gunakan satu atau beberapa model empiris untuk estimasi biaya dan effort software.

27. selesai…

28. :: Materi Diskusi :: • 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.