Tugas 2 MPPL - Perencanaan Proyek Perangkat Lunak

Perencanaan Proyek Perangkat Lunak

Pemahaman terhadap Proyek Perangkat Lunak

Proyek Software adalah manajemen proyek yang berfokus hanya pada membuat dan mengupdate software. Sifat manajemen proyek haruslah seperti berikut ini:

• Menyelesaikan masalah,
• Mengerjakan sesuatu hingga selesai,
• Memiliki batas waktu mulai dan selesainya,
• Membutuhkan resource/sumber daya dan waktu,
• Bagi beberapa orang merupakan kesempatan/opportunity dan menarik.

Untuk itu sebuah proyek software perlu dikelola. Pengelolaan (Manajemen) itu berupa persiapan pekerjaan, pelaksanaan rencana, mengendalikan proyek tersebut dan terakhir menutup proyek dengan sebuah kesimpulan, yaitu sukses. Secara lebih sistematis, tahapan-tahapan proyek dapat dilihat pada gambar berikut:

Tahapan-tahapan Proyek Perangkat Lunak

Tahapan proyek

• Initiating: proyek sedang dalam proses untuk dipilih/disetujui, disponsori, didanai, dan diluncurkan.
• Planning: perencanaan adalah proses yang berulang (perhatikan gambar). Perencanaan pada dasarnya menggambarkan proses bagaimana proyek akan dilaksanakan hingga selesai.
• Executing: setelah proyek direncanakan, tim proyek memulai pekerjaannya.
• Controlling: selama tim proyek mengerjakan tugasnya, project manager mengontrolnya.
• Closing: setelah proyek diselesaikan project manager akan menutup proyek software. Banyak proyek gagal di awal, bukan di akhir. Artinya, persiapan adalah bagian yang sangat penting bagi proyek software. Persiapan diwujudkan dalam bentuk perencanaan proyek. Tulisan ini menjelaskan point kedua yaitu Planning

Tujuan Perencanaan Proyek

Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat perkiraan yang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Perkiraan dibuat dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan seharusnya diperbarui secara teratur selagi proyek sedang berjalan. Sebagai tambahan, perkiraan akan berusaha mendefinisikan skenario kasus terbaik dan kasus terburuk.

Tujuan perencanaan dicapai melalui suatu proses penemuan informasi yang menunjuk ke estimasi yang dapat dipertanggungjawabkan

Aktivitas pertama dalam perencanaan proyek perangkat lunak adalah penentuan ruang lingkup perangkat lunak. Fungsi dan kinerja yang dialokasikan untuk perangkat lunak selama rekayasa sistem seharusnya ditaksir untuk membentuk sebuah ruang lingkup proyek yang jelas dan dapat dimengerti pada, tingkat manajemen dan teknis.

Ruang lingkup perangkat lunak menggambarkan fungsi, batasan, interface dan reliabilitas. Fungsi-fungsi yang digambarkan dalam pernyataan ruang lingkup dievaluasi dan dalam banyak kasus juga disaring untuk memberikan awalan. yang lebih detail pada. saat estimasi dimulai. Banyak derajat dekomposisi sering menjadi berguna karena baik estimasi jadwal maupun biaya diorientasikan secara fungsional. Pertimbangan kine~a melingkupi pemrosesan dan kebutuhan waktu respon. Batasan mengidentifikasi batas yang ditempatkan pada. perangkat lunak oleh perangkat keras eksternal, memori atau sistem lain yang ada.

Mencari Informasi yang Dibutuhkan untuk Ruang Lingkup

Segala sesuatu selalu kelihatan tidak jelas pada saat sebuah proyek perangkat lunak dimulai. Suatu kebutuhan telah ditentukan dan sasaran serta tujuan dasar telah dibicarakan, tetapi informasi yang perlu untuk menentukan ruang lingkup (sebuah persyaratan untuk estimasi) belum ditentukan.

Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi antara pelanggan. dan pengembang serta untuk memulai proses komunikasi adalah dengan melakukan pertemuan atau wawancara pendahuluan. Pertemuan pertama antara seorang teknisi perangkat lunak (analis) dan pelanggan dapat disamakan dengan kakunya kencan pertama antara dua remaja. Tak satupun orang yang tahu apa yang akan dikatakan atau ditanyakan, keduanya khawatir apa yang mereka katakan akan disalahartikan; kedua pihak berpikir ke mana arah yang mereka tuju (di sini keduanya memiliki pengharapan yang sangat berbeda); keduanya ingin pertemuan segera selesai; tetapi pada, saat yang sama mereka ingin hal  itu dapat berjalan dengan sukses.

Bagaimanapun juga komunikasi harus dimulai. Gause & Weinberg mengusulkan bahwa analis harus memulainya dengan. mengajukan pertanyaan-pertanyaan bebas konteks, yaitu serangkaian pertanyaan yang akan membawa kepada pemahaman yang mendasar terhadap masalah, orang yang menginginkan suatu solusi.

Rangkaian pertanyaan bebas konteks yang pertama berfokus pada pelanggan, tujuan keseluruhan serta keuntungan. Sebagai contoh, analis dapat meMM%-dkan:

• Siapa, yang akan memakai solusi ini?
• Apakah yang akan menjadi keuntungan ekonomi dari sebuah solusi yang sukses?
• Adakah sumber daya lain bagi solusi ini?

Rangkaian pertanyaan berikutnya memungkinkan analis untuk memahami masalah dengan lebih baik serta memungkinkan pelanggan menyuarakan persepsi mereka tentang sebuah solusi:

• Bagaimanakah Anda (pelanggan) menandai output yang baik yang akan dimunculkan oleh sebuah solusi yang baik?
• Masalah apa, yang akan dituju oleh solusi ini?
• Dapatkah Anda memperlihatkan atau menggambarkan lingkungan di mana solusi akan dipakai?
• Adakah batasan atau isu kinerja khusus yang akan mempengaruhi cara pendekatan terhadap solusi?

Rangkaian akhir dari pertanyaan berfokus pada efektivitas perternuan Gause clan Weinberg menyebutnya meta-question dan mengusulkan daftar berikut (disingkat):

• Apakab Anda orang yang tepat untuk menjawab pertanyaan ini? Apakah jawaban Anda resmi?
• Apakah pertanyaan saya relevan dengan problem yang Anda punyai? Apakah saya terlalu banyak pertanyaan?
• Apakah ada orang lain yang dapat menyediakan informasi tambahan? Adakah sesuatu yang lain yang dapat saya tanyakan kepada Anda?

Pertanyaan-pertanyaan tersebut (dan juga lainnya) akan membantu. “memecahkan kekakuan” dan memulai komunikasi yang esensial untuk menentukan ruang lingkup proyek. Namun demikian, pertanyaan clan jawaban dalam format pertemuan tersebut bukanlah sebuah pendekatan yang dianggap sukses. Kenyataannya, bagian Q&A hanya akan digunakan untuk pertemuan pertama yang kemudian diganti dengan format pertemuan yang mengkombinasikan elemen-elemen penyelesaian. masalah, negosiasi, dan spesifikasi.

Sumber Daya

Tugas kedua perencanaan perangkat lunak adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak tersebut. Lingkungan pengembangan piranti perangkat keras dan perangkat lunak – berada pada fondasi piramid sumber daya dan menyediakan infrastruktur untak mendukung usaha pengembangan. Dalarn tingkat yang lebih tinggi, kita menemukan komponen perangkat lunak reusable – blok bangunan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat penyampaian. Di puncak piramida terdapat sumber daya utama – manusia (people). Masing-masing sumber daya ditentukan dengan empat karakteristik: deskripsi sumber daya, statemen ketersediaan, waktu kronologis sumber daya diperlukan, serta durasi waktu sumber daya diaplikasikan. Dua karakteristik terakhir dapat dilihat sebagai time windows (jendela waktu). Tersedianya sumber daya untuk sebuah jendela khusus harus dibangun pada waktu praktik paling awal.

Sumber Daya Manusia

Perencana Sumber Daya Manusia memulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untak menyelesaikan pengembangan. Baik posisi organisasi (seperti manajer, perekayasa perangkat lunak senior, dan lain-lain) maupun specialis (seperti telekomunikasi, data base, client/server) ditentukan. Untuk proyek yang sangat kecil (6 person-month atau kurang), seorang individu dapat melakukan semua langkah rekayasa perangkat lunak, berkonsultasi dengan spesialis jika diperlukan.

Jumlah orang/manusia, yang diperlukan untak sebuah proyek peranglat lunak dapat ditentukan hanya setelah sebuah estimasi usaha pengembangan (seperti person-months atau person-years) dibuat. Teknik untuk usaha estimasi’didiskusikan pada bagian selanjutnya dari bab ini.

Sumber Daya Perangkat Lunak Reusable

Setiap diskusi mengenai sumber daya perangkat lunak tidak akan lengkap tanpa pengetahuan tentang reusahilitas, yaitu kreasi dan penggunaan kembali blok bangunan perangkat lunak. Blok-blok bangunan semacam itu harus dikatalog menjadi referensi yang mudah, distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk integrasi yang mudah.

Beunatan [mengusulkan empat kategori sumber daya perangkat lunak yang harus dipertimbangkan pada saat perencanaan berlangsung, yaitu:

Komponen Off-the-self 

Perangkat lunak yang ada yang dapat diperoleh dari sebuah bagian ketiga atau telah dikembangkan secara internal untuk proyek sebelumnya. Komponen-komponen tersebut siap digunakan pada proyek sekarang dan tlash selesai.

Komponen Full-Experience 

Spesifikasi, kode, desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa. dengan perangkat lunak yang akan dibangun pada proyek saat ini. Setiap anggota tim. perangkat lunak saat ini memiliki pengalaman penuh pada bidang apRasi yang disajikan oleh komponen-komponen tersebut sehingga modifikasi yang dibutuhkan bagi komponen full-experience secara relatif risikonya akan lebih rendah.

Komponen partial-experience

Aplikasi, kode, desain, atau data pengujian yang ada pada proyek yang lalu yang dihubungkan dengan perangkat lunak yang dibangun untuk proyek saat ini, tetapi akan membutuhkan modifikasi substansial. Anggota tim. perangkat lunak yang sekarang hanya, memiliki pengalaman yang terbatas di dalam area aplikasi yang diwakilkan oleh komponen-komponen ini sehingga modifikasi yang dibutuhkan bagi komponen partial-experience memiliki tingkat risiko sedang.

Komponen baruKomponen perangkat lunak yang harus dibangun oleh tim. perangkat lunak khususnya, adalah untuk kebutuhan proyek sekarang.

Panduan berikut harus dipertimbangkan oleh perencana perangkat lunak bila komponen reusable ditentukan sebagai sebuah sumber daya:

• Bila komponen off-the-shelf memenuhi persyaratan proyek, sediakanlah. Biaya yang digunakan untuk integrasi dan akuisisi komponen off-the-shelf akan selalu lebih kecil dibanding biaya yang digunakan untuk mengernbangkan perangkat lunak yang ekivalen.’ Risiko yang ada juga relatif rendah.
• Bila ada komponen full-experience, risiko yang berhubungan dengan integrasi dapat diteriina secara utnum. Perencanaan proyek harus mencerminkan penggunaan komponen-komponen ini.
• Bila komponen partial-experience ada, maka penggunaannya untuk proyek yang sedang dilakukan harus dianalisis secara lengkap. Bila modifikasi ekstensif dibutuhkan sebelum komponen dapat diintegrasi dengan tepat dengan elernen perangkat lunak yang lain, maka hal itu harus dilakukan dengan hati-hati. Biaya untuk memodifikasi komponen partial-experience kadang-kadang dapat lebih tinggi daripada biaya untuk mengembangkan komponen-komponen baru.

Ironisnya, penggunaan komponen reusabel sering diabaikan selama perencanaan, atau hanya menjadi perhatian sesaat selarna fase pengembangan proses perangkat lunak. Jauh lebih baik mengkhususkan syarat surnber daya perangkat lunak dari awal. Dengan cara ini evaluasi teknis dari semua alternatif dapat dilakukan dan akuisisi berkala dapat tetJadi.

Sumber Daya Lingkungan

Lingkungan yang mendukung proyek perangkat lunak, yang disebut juga software engineering environment (SEE), menggabungkan perangkat lunak dan perangkat keras. Perangkat keras menyediakan sebuah platform yang men-dukung peranti (perangkat lunak) yang dibutuhkan untuk menghasilkan produk keda yang merupakan keluaran dari praktik rekayasa perangkat lunak yang baik.’ Karena sebagian besar organisasi perangkat lunak memiliki konstituen ganda yang mernerlukan akses ke SEE, maka perencana proyek harus menentukan jendela waktu yang dibutuhkan bagi perangkat keras dan perangkat lunak serta membuktikan bahwa sumber-sumber daya tersebut dapat diperoleh.

Pada saat sebuah sistem berbasis komputer (gabungan khusus antara, perangkat keras dan perangkat lunak) akan direkayasa, thn perangkat lunak mungkin membutuhkan akses ke elemen perangkat keras yang sedang dikembangkan oleh tim rekayasa yang lain. Contohnya, perangkat lunak untuk kontrol numeris (NQ yang digunakan pada kelas peranti mesin mungkin membutuhkan

Daftar Pustaka

• Presman, Rouger S, Software Enigineering, 4th Edition, Mc. Graw Hill,1997.
• Sommerville,Ian, Software Engineering, 7th Edition, Addison Wesley, 20
• http://fairuzelsaid.com/perencanaan-proyek-perangkat-lunak/