MANAJEMEN PROYEK PERANGKAT LUNAK

Presentasi berjudul: "MANAJEMEN PROYEK PERANGKAT LUNAK"— Transcript presentasi:

1 MANAJEMEN PROYEK PERANGKAT LUNAK
PERENCANAAN PROYEK PERANGKAT LUNAK MANAJEMEN PROYEK PERANGKAT LUNAK DEDED RAMAD KAMDA, S. KOM

2 Mengapa Proyek Direncanakan ?
Perencanaan sistem adalah proses membuat sebuah Laporan Perencanaan Sistem yang menggunakan sumber sistem informasi yang berhubungan dan mendukung tujuan bisnis dan operasi organisasi. Perencanaan sistem berhubungan dengan perencanaan bisnis. Selain itu juga untuk menghindari pinaliti/ hukuman yang diderita jika tidak sesuai atau tidak ada perencanaan sistem, yaitu : 􀂃 Kehilangan kesempatan untuk memanfaatkan faktor strategis PDM 􀂃 Biaya yang terlalu tinggi untuk hardware, software dan jaringan telekomunikasi yang terlambat dipesan 􀂃 Pekerjaan yang terburu-buru hingga akhir proyek, karena tim proyek tidak menyediakan waktu yang cukup untuk mengimplementasikan tugas, seperti persiapan lapangan, ujicoba, pelatihan dan konversi 􀂃 Gangguan user dan pekerjaannya dan operasi perusahaan selama produksi memuncak karena salah penjadualan 􀂃 Kehilangan kredibilitas user karena tanggal target yang terlewat (ini dapat terjadi bagi suatu perencanaan sistem yang baik karena manajer proyeknya tidak hati-hati).

3 Perencanaan sistem adalah proses membuat sebuah Laporan Perencanaan Sistem yang menggunakan sumber sistem informasi yang berhubungan dan mendukung tujuan bisnis dan operasi organisasi. Perencanaan sistem berhubungan dengan perencanaan bisnis. Selain itu juga untuk menghindari pinaliti/ hukuman yang diderita jika tidak sesuai atau tidak ada perencanaan sistem, yaitu : Kehilangan kesempatan untuk memanfaatkan faktor strategis .Biaya yang terlalu tinggi untuk hardware, software dan jaringan telekomunikasi yang terlambat dipesan Pekerjaan yang terburu-buru hingga akhir proyek, karena tim proyek tidak menyediakan waktu yang cukup untuk mengimplementasikan tugas, seperti persiapan lapangan, ujicoba, pelatihan dan konversi Gangguan user dan pekerjaannya dan operasi perusahaan selama produksi memuncak karena salah penjadualan Kehilangan kredibilitas user karena tanggal target yang terlewat (ini dapat terjadi bagi suatu perencanaan sistem yang baik karena manajer proyeknya tidak hati-hati).

4 Perencanaan pada dasarnya menggambarkan proses bagaimana proyek akan dilaksanakan hingga selesai.

5 Observasi Pada Estimasi
Ukuran proyek (project size) merupakan faktor penting lain yang dapat mempengaruhi akurasi estimasi. Bila ukuran bertambah maka ketergantungan di antara berbagai elemen perangkat lunak akan meningkat dengan cepat. Tingkat ketidakpastian struktural (structural uncertainty) juga berpengaruh dalam resiko estimasi. Bila ruang lingkup proyek tidak dipahami dengan baik atau syarat proyek merupakan subyek terjadinya perubahan, maka resiko dan ketidakpastian menjadi sangat tinggi. Perencana perangkat lunak harus melengkapi fungsi, kinerja dan definisi interface (yang diisikan ke dalam spesifikasi sistem).

6 Yang mempengaruhi estimasi
Project complexity (kompleksitas proyek) Project size (ukuran proyek) Struktural uncertainty (ketidakpastian struktural)

7 Tujuan Perencanaan Proyek
Untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasiyang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan seharusnya diperbaharui secara teratur selagi proyek sedang berjalan.

8 Tujuan Perencanaan Proyek
Bagi Project Manager: untuk menggambarkan status proyek kepada manajer senior dan stakeholder, untuk merencanakan aktivitas tim proyek. Bagi anggota Tim Proyek: untuk memahami konteks pekerjaan. Bagi Manajer Senior: untuk memastikan apakah biaya dan waktu yang dialokasikan masuk akal dan terkendali, untuk melihat apakah proyek dilaksanakan secara efisien dan cost effective. Bagi Stakeholder: untuk memastikan apakah proyek masih berada pada jalurnya, untuk memastikan kebutuhan mereka sedang diakomodir oleh proyek.

9 Aktifitas Perencanaan Proyek PL
Menentukan ruang lingkup PL Mengestimasi sumber daya yang dibutuhkan

10 Ruang Lingkup Perangkat Lunak
Ruang lingkup perangkat lunak menggambarkan fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi-fungsi yang digambarkan dalam statemen ruang lingkup dievaluasi dan dalam banyak kasus juga disaring untuk memberikan awalan yang lebih detail pada saat estimasi dimulai. 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. Gause & Weinberg mengusulkan bahwa analisis 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, sifat solusi yang diharapkan, dan efektivitas pertemuan itu sendiri.

11 Ruang Lingkup Perangkat Lunak (sambungan….)
Informasi yang dibutuhkan Pertanyaan berfokus pada pelanggan, tujuan keseluruhan serta keuntungan. - Siapa di belakang permintaan kerja ini? - Siapa yang akan memakai solusi ini? - Apakah keuntungan ekonomi dari solusi yang sukses? - Adakah sumber daya lain bagi solusi ini? 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. Gause & Weinberg mengusulkan bahwa analisis 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, sifat solusi yang diharapkan, dan efektivitas pertemuan itu sendiri.

12 Ruang Lingkup Perangkat Lunak (sambungan….)
Pertanyaan yang memungkinkan analis memahami masalah lebih baik dan pelanggan menyuarakan persepsi tentang sebuah solusi. - Bagaimana Anda (pelanggan) menandai output yg baik yg akan dihasilkan oleh sebuah solusi yg baik? - Masalah apa yang dituju solusi ini? - Dapatkah anda menggambarkan lingkungan dimana solusi akan dipakai? - Adakah batasan atau isu kinerja khusus yg akan mempengaruhi 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. Gause & Weinberg mengusulkan bahwa analisis 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, sifat solusi yang diharapkan, dan efektivitas pertemuan itu sendiri.

13 Sumber Daya Perencana Sumber daya manusia memulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk menyelesaikan pengembangan.Beunatan mengusulkan empat kategori sumber daya perangkat lunak yang harus dipertimbangkan pada saat perencanaan berlangsung, yaitu :

14 Sumber Daya Komponen Off-the-self Komponen Full-Experience.
Komponen partial-experience. Komponen baru Komponen Off-the-self. Komponen-komponen PL yang ada dapat diperoleh dari proyek sebelumnya yang siap digunakan pada proyek sekarang dan telah divalidasi seluruhnya. Komponen Full-Experience. Komponen-konponen PL yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan PL yang akan dibangun pada proyek saat ini. Setiap anggota tim memiliki pengalaman penuh sehingga modifikasi yang dibutuhkan bagi komponen ini secara relatif resikonya akan lebih rendah. Komponen partial-experience. Komponen-konponen PL yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan PL yang akan dibangun pada proyek saat ini, tetapi akan membutuhkan modifikasi substansial. Anggota tim PL ini memiliki pengalaman yang terbatas sehingga modifikasi yang dibutuhkan bagi komponen partial-experience memiliki tingkat resiko sedang. Komponen baru. Komponen PL yang harus dibangun oleh tim Pl khususnya adalah untuk kebutuhan proyek sekarang. Lingkungan yang mendukung proyek Perangkat lunak, yang disebut juga Software Engineering environment (SEE), menggabungkan PL dan PK.

15 Akurasi estimasi proyek PL didasarkan pada :
1. Tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk yg akan dibuat. 2. Kemampuan mengestimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar. 3. Tingkat dimana rencana proyek mencerminkan kemampuan tim PL. 4. Stabilitas syarat produk serta lingkungan yg mendukung usaha pengembangan PL.

16

17 Dokumen Perencanaan Proyek Perangkat Lunak
Vision and Scope Statement of Work Resource List Work Breakdown Structure Project Schedule Risk Plan

18 Vision and Scope Problem Statement
Bagian Problem Statement terdiri atas empat sub bab, antara lain: Latar belakang proyek Sub bab ini menceritakan dengan cukup mendalam baik latar belakang masalah maupun penjelasan mengenai mengapa organisasi memutuskan untuk membangun software untuk mengatasi masalah tersebut. Pada sub bab ini diceritakan sebab munculnya masalah, sejarah organisasi dengan permasalahan tersebut dan mengapa akhirnya diputuskan untuk membangun software yang diproyekkan. Stakeholder

19 Stakeholder Pada sub bab ini akan diberikan daftar stakeholder yang dilibatkan dalam proyek. Mulai dari customer hingga manajer-manajer senior. Stakeholder ini bisa berupa nama atau jabatan. Tim proyek harus paham dengan siapa mereka bekerja dan apa bidang kerja mereka. Daftar juga dilengkapi dengan alasan dicantumkannya stakeholder tersebut. Untuk proyek-proyek besar tentu saja pencantuman nama tidak relevan karena akan menjadi terlalu panjang daftarnya. Pengguna Sub bab ini berisi daftar calon pengguna software. Sama dengan stakeholder, bisa berupa nama atau jabatan. Daftar juga dilengkapi dengan alasan dicantumkannya pengguna tersebut. Resiko Sub bab ini akan diisi dengan faktor-faktor yang mungkin menjadi pemicu munculnya masalah, seperti keterlambatan dan permasalahan lain. Resiko yang dimaksud pada sub bab ini bisa faktor internal maupun eksternal.

20 Vision and Scope Vision of the Solution
Bagian Vision of the Solution juga akan terdiri atas empat sub bab, yaitu: Vision statement Tujuan vision statement adalah menggambarkan apa yang ingin dicapai setelah proyek berjalan. Di dalam sub bab ini disebutkan faktor-faktor apa yang harus terpenuhi untuk menandakan kapan proyek dinyatakan selesai. Selain itu tujuan dari proyek juga harus jelas disebutkan di dalam sub bab ini. Waktu terbaik untuk membuat vision statement adalah setelah tim melakukan proses Requirement Engineering.

21 Gambaran produk yang ingin dicapai tersebut akan menjadi batasan ruang lingkup (scope) yang harus diperhatikan oleh semua pihak yang terlibat di dalam project. Ruang lingkup ini membutuhkan biaya dan waktu tertentu. Project manager yang baik akan mempersembahkan software tepat seperti yang telah dijanjikan kepada stakeholder dan user, tepat pada waktunya dengan menghabiskan biaya (menerima bayaran) tepat sama dengan perjanjiannya dengan customer.

22 Mungkin ada pendapat bahwa memberikan sedikit bonus fungsi terhadap software, dengan asumsi bahwa stakeholder atau user akan menyukainya, maka pendapat itu adalah kesalahan. Antara ruang lingkup, waktu dan biaya/harga harus ada keseimbangan. Jika ada penambahan pada ruang lingkup, maka seharusnya ada penambahan waktu atau biaya, jika tidak maka akan menyebabkan ketidak adilan bagi tim proyek/pengembang. Begitu juga sebaliknya. Perubahan ruang lingkup mestinya diatur dengan Change Control System.

23 Daftar fitur Sebuah paket software umumnya dapat dibagi-bagi menjadi beberapa fitur. Jumlah yang umumnya dapat diterima adalah sekitar sepuluh fitur. Jumlah ini sudah cukup menggambarkan kompleksitas software namun tetap nyaman dibaca oleh tim pengembang. Tiap fitur sebaiknya ditulis dalam paragraph yang terpisah atau dalam bentuk pointer-pointer. Deskripsi fitur-fitur ini tidak perlu sangat detil, cukup beberapa kalimat yang menggambarkan penjelasan umum tentang fitur tersebut. Fitur-fitur ini mungkin mengalami penambahan atau pengurangan, sesuai dengan permintaan stakeholder. Jika perlu, sebuah fitur dapat dilengkapi dengan use case. Namun tentu saja use case dibuat agar cukup simpel untuk dipahami oleh semua stakeholder.

24 Ruang lingkup tiap fase (jika perlu)
Terkadang deadline yang diberikan untuk mengerjakan sebuah proyek software membuat pengerjaan seluruh fitur yang diajukan tidak mungkin selesai. Oleh karenanya dibuat solusi untuk membagi software menjadi beberapa fase rilis. Software akan dirilis pada saat deadline tercapai, namun dengan fitur yang dikurangi. Sedangkan rilis berikutnya lah yang memuat semua fitur.

25 Fitur-fitur yang ada pada rilis awal seharusnya adalah fitur yang sifatnya lebih penting daripada fitur lainnya, menurut stakeholder. Hal semacam ini perlu dikonsultasikan kepada tim pengembang. Fitur yang tidak akan dibuat Terkadang stakeholder meminta fitur yang memang harus dibuang/ditinggalkan karena tidak masuk akal untuk diselesaikan dalam waktu yang tersedia, atau karena sebab-sebab lain. Fitur-fitur semacam ini perlu dicantumkan pada sub bab ini. Ini dicantumkan untuk diketahui semua pihak agar ada kesepahaman dan agar semua setuju dengan penghapusan fitur ini.

26 Work Breakdown Structure
Work Breakdown Structure, disingkat WBS, berisi daftar pekerjaan yang jika diselesaikan akan menghasilkan work product. WBS menyebutkan: Apa saja pekerjaan yang akan dilakukan, Tipe-tipe resource yang dibutuhkan untuk bekerja, Estimasi tiap elemen pekerjaan, Identifikasi lokasi penyimpanan. Tetapi tidak mencantumkan: Siapa yang mengerjakan pekerjaan-pekerjaan itu, Dan kapan pekerjaan itu akan diselesaikan