MANAJEMEN PROYEK PERANGKAT LUNAK

1. MANAJEMEN PROYEK PERANGKAT LUNAK

2. Konsep Manajemen Proyek • Suatu aktivitas manajemen yang digunakan untuk mengelola proyek perangkat lunak, yang difokuskan pada 3P: People (manusia); Problem (masalah) dan Process (proses) • People: semua orang yang terlibat dalam proyek perangkat lunak • Problem: menentukan ruang lingkup dan batasan proyek perangkat lunak sekaligus teknik pemecahannya. • Process: kerangka kerja yang konprehensif dalam pembangunan perangkat lunak

3. Para Pemain Proyek Perangkat Lunak (Stakeholder) • Senior managers:yang menentukan isu-isu bisnis yang sering memiliki pengaruh penting di dalam proyek • Project (technical) managers: yang harus merencanakan, memotivasai, mengorganisasi dan mengontrol sebuah produk atau aplikasi • Practitioners: yang menyampaikan ketranpilan teknik yang diperlukan untuk merekayasa sebuah produk atau aplikasi • Customers: yang menentukan jenis kebutuhan bagi perangkat lunak yang akan direkayasa • End users: yang akan memakai perangkat lunak

4. Pimpinan Tim • Pimpinan tim (team leaders): seseorang yang memimpin sebuah proyek perangkat lunak. • Model kepempinan MOI (Jerry Weinberg): • Motivasi: kemampuan untuk memberi dorongan pada staf teknis untuk menghasilkan sesuatu dengan kemampuan terbaiknya. • Organisasi: kemampuan untuk membentuk proses yang sedang berlangsung yang memungkinkan konsep dasar diterjemahkan ke dalam suatu hasil akhir. • Gagasan dan inovasi: kemampuan untuk mendorong manusia untuk menciptakan dan bertindak kreatif meskipun mereka bekerja di dalam suatu ikatan yang dibangun untuk suatu produk perangkat lunak yang spesifik

5. Tim Perangkat Lunak • Alternatif pemanfaatan SDM pada proyek perangkat lunak: • n individu diberi m tugas fungsional yang berbeda (m > n), ada individu yang merangkap kombinasi kerja. • n individu diberi m tugas yang berbeda (m < n), secara tidak langsung terbentuk tim informal. • n individu dibagi menjadi t tim, setiap tim mempunyai tugas yang spesifik. • Struktur tim yang terbaik berdasarkan gaya manajemen, jumlah orang, tingkat keahlian, kompleksitas masalah.

6. Tiga Organisasi Tim (Mantei) • Democratic Decentralized (DD); tidak ada pimpinan yang tetap, keputusan diambil secara bersama-sama, hubungan horizontal. • Controlled Decentralized (CD); ada pimpinan untuk setiap 'task' dan sub-pimpinan untuk 'sub-task', terjadi komunikasi horizontal & vertikal. • Controlled Centralized (CC); ada team leader untuk top-level problem solving & koordinasi internal, koordinasi vertikal

7. 7 Faktor Dalam Merencanakan Struktur Tim RPL (Mantei) • Tingkat kesulitan masalah • Besarnya program (dalam LOC atau FP) • Team lifetime • Tingkat modularitas program • Kualitas dan reliabilitas program • Batas waktu pengembangan • Tingkat sosialisasi (sosiabilitas) proyek

8. Pengaruh Karakteristik Proyek Pada Struktur Tim

9. Masalah Koordinasi dan Komunikasi Ada banyak hal yang menyebabkan proyek perangkat lunak bermasalah, penyebabnya diantaranya adalah: • Scale (skala): skala proyek yang demikian besar, sehingga sulit melakukan koordinasi. • Uncertainty (ketidakpastian): perubahan-perubahan yang terus-menerus. • Interoperability (interoperabilitas): perangkat lunak yang dibuat harus dapat berkomunikasi dengan perangkat lunak yang lain.

10. Teknik Koordinasi Proyek (Kraul dan Streeter) • Pendekatan impersonal, formal. Dokumen, memo teknis, milestone proyek, schedule, error tracking report, dll • Prosedur interpersonal, formal. Difokuskan pada jaminan kualitas aktivitas, diantaranya inspeksi disain dan kode. • Prosedur interpersonal, informal. Group meeting untuk bertukar informasi dan problem solving, requirement gathering dan pengembangan staff. • Komunikasi elektronik. E-mail, E-BB, web sites, video conference. • Jaringan interpesonal. Diskusi informal dengan orang di luar proyek.

11. Masalah • Manajer proyek perangkat lunak berhadapan dengan dilema awal proyek, yaitu menentukan perikiraan kuantitatif dan rencana organisasi tetapi informasi yang akurat belum tersedia. • Requirement analysis yang lengkap dibutuhkan untuk melakukan estimasi, tetapi memerlukan waktu yang lama dan kadang-kadang kebutuhan berubah-ubah pada saat proyek berjalan. • Solusi: mendefinisikan scope (ruang lingkup) dengan benar dan segera.

12. Ruang Lingkup Masalah • Dibatasi oleh: • Context: Bagaimana perangkat lunak yang dibangun dapat memenuhi sebuah sistem, produk, atau konteks bisnis yang lebih besar, serta apa batasan yang ditentukan sebagai hasil dari konteks tersebut? • Information Objectives: Obyek data pelanggan apa yang dihasilkan sebagai output dari perangkat lunak? Dan obyek data apa yang diperlukan sebagai input? • Function dan performance: Fungsi apa yang dilakukan oleh perangkat lunak untuk mentransformasi input data menjadi output?

13. Dekomposisi Masalah • Dekomposisi masalah disebut juga partitioning (pembagian), merupakan aktivitas yang mendudukkan inti dari analisis kebutuhan perangkat lunak. • Dekomposisi dilakukan dalam 2 area: • Fungsionalitas yang harus dihasilkan • Proses yang akan dipakai untuk menghasilkan • Manusia cenderung melakukan dekomposisi jika menghadapi masalah yang kompleks

14. Proses • Fase-fase generik dan menandai proses perangkat lunak: definisi, pengembangan dan pemeliharaan • Fase generik dijalankan menggunakan salah satu model pengembangan perangkat lunak. • Project manager harus memilih model pengembangan yang paling tepat berdasarkan karakteristik masalah, tim dan kriteria proyek.

15. Menggabungkan Masalah dan Proses • Tahap awal project planning dimulai dengan penggabungan problem dan process. • Setiap fungsi yang akan direkayasa harus melampui sejumlah aktivitas yang sudah ditentukan • Misal organisasi mengadopsi kerangka aktivitas sbb: • Customer communication – membangun komunikasi yang efektif antara pengembang dan pelanggan • Planning – menentukan sumber daya, ketepatan waktu dan informasi proyek yang lain • Risk analysis – menentukan resiko-resiko manajemen dan teknis • Engineering – membangun aplikasi perangkat lunak • Construction and release – membangun, menguji, menginstall dan memberikan dukungan kepada pemakai (dokumen dan pelatihan) • Customer evaluation – umpan balik pelanggan • Selanjutnya dibuat matriksnya.

17. Dekomposisi Proses • Memilih paradigma rekayasa perangkat lunak yang paling baik sesuai dengan tingkat relatifitas dari perangkat lunak. • Bila proyek relatif kecil dan mirip dengan proyek sebelumnya, maka dapat dipilih pendekatan linier sekuensial • Bila masalah dapat dipecah-pecah dan batasan waktu yang ketat, maka dapat dipilih model RAD. • Bila batas waktunya ketat, tetapi fungsionalitas tidak dapat optimal, maka dapat dipilih strategi pertambahan. dll • Sekali model dipilih, kerangka kerja umum (CPF=common Process Framework) harus disesuaikan dengan model.

18. Contoh Dekomposisi (simple project) • Membuat daftar klarifikasi • Bertemu dengan cutomer untuk klarifikasi • Bersama-sama untuk menentukan scope • Review scope • Penyempurnaan scope berdasarkan berbagai kendala

19. Contoh Dekomposisi (complex project) • Mengkaji kebutuhan customer • Merencanakan dan menjadwal sebuah pertemuan formal dengan customer • Melakukan penelitian untuk menentukan pemecahan yang diusulkan • Mempersiapkan dokumen kerja serta agenda untuk pertemuan formal • Mengadakan pertemuan • Secara bersama-sama mengembangkan perincian kecil yang merefleksikan data, fungsi, dan ciri-ciri yang berhubungan dengan perilaku perangkat lunak • Mengkaji setiap perincian kecil tersebut untuk upaya perbaikan, konsistensi, dan mengurangi ambiguitas • Memasang perincian kecil ke dalam sebuah dokumen ruang lingkup • Mengkaji dokumen yang membatasi dengan semua pendapat yang ada. • Memodifikasi dokumen yang membatasi sesuai dengan kebutuhan.

20. Metrik Proses dan Proyek Perangkat Lunak • Measure (mengukur); kuantitatif luasan, jumlah, dimensi, kapasitas, atau ukuran dari atribut sebuah proses atau produk. • Measurement (pengukuran); kegiatan menentukan sebuah measure. • Metrics (IEEE): ukuran kuantitatif dari tingkat di mana sebuah sistem, komponen, atau proses memiliki atribut tertentu • Indikator adalah sebuah metrik atau kombinasi dari metrik yang memberikan pengetahuan ke dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk perangkat lunak.

21. Tujuan Umum Pengukuran • Mengetahui kualitas perangkat lunak; baik atau jelek • Menilai produktifitas pembuatan perangkat lunak; kecepatan pembuatan, ukuran perangkat lunak • Menilai manfaat dari penerapan sebuah metoda; mencari paradigma andalan • Dasar untuk melakukan perkiraan; pedoman dimasa mendatang • Membantu untuk memastikan apakah dibutuhkan peralatan baru, pelatihan tambahan

22. Domain Metrik • Pengukuran perangkat lunak dilakukan pada proses dan proyek perangkat lunak. • Indikator proses memungkinkan: • Software engineer memperoleh pengetahuan tentang reliablitas sebuah proses yang sedang berlangsung. • Manajer dan pelaksana memperkirakan apa yang harus dikerjakan dan apa yang tidak • Indikator proyek, memungkinkan manajer proyek: • Memperkirakan status proyek • Menelusuri resiko-resiko potensial • Menemukan area masalah sebelum menjadi kritis • Menyesuaikan aliran kerja atau tugas-tugas • Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas.

23. Determinan Kualitas dan Efektivitas Perangkat Lunak

24. Pengukuran Perangkat Lunak • Size-Oriented Metrics: metrik yang berorientasi pada besar fisik ukuran perangkat lunak • Function-Oriented Metrics: metrik yang berorientasi pada fungsionalitas dan utilitas perangkat lunak, menggunakan: • Function Points • Feature Points

25. Size-Oriented Metrics • Normalisai kualitas dan produktifitas dengan mengukur besar-kecilnya (LOC/KLOC) perangkat lunak, sehingga diperoleh: • Error per KLOC • Defect (cacat) per KLOC • Rupiah (Rp) per LOC • Halaman dokumentasi per KLOC • Metrik lain dapat diturunkan: • Error per orang-bulan • LOC per orang-bulan • Rupiah (Rp) per halaman dokumentasi

26. Contoh (size-oriented metrics)

27. Kontoversi Size-Oriented Metrics • Metrik size-oriented tidak diterima secara universal; kontroversi terletak pada pemakaian LOC. • Pendukung: LOC merupakan artifak proyek pengembangan perangkat lunak yang mudah dihitung. • Penentang: LOC tergantung bahasa pemrograman, LOC tidak mendukung disain yang baik tetapi program singkat, tidak dapat dengan mudah mengakomodasi bahasa non-prosedural, dan pemakaiannya membutuhkan tingkat detail yang sulit dicapai.

28. Function-Oriented Metrics • Mengukur secara tidak langsung. • Ditekankan pada fungsional & utilitas program. • Diusulkan pertama kali oleh Albrecht, dengan usulan cara perhitungan yang disebut: function point (FP). • FP diturunkan dengan menggunakan hubungan empiris berbasis pada sesuatu yang terukur dari domain informasi dan berhubungan dengan komplesitas P/L.

29. Function Points Domain Informasi: • Jumlah input dari user: jumlah user input yang dibutuhkan aplikasi • Jumlah output untuk user: jumlah semua keluaran baik laporan maupun kesalahan (ke printer/layar) • Jumlah input inquiry: masukan on-line yang mengakibatkan keluaran on-line • Jumlah file • Jumlah interface eksternal: semua interface yang dibaca oleh mesin untuk memincahkan informasi ke sistem lain.

30. Mengitung Metrik Function Points Weighting Factor measurement parameter count simple average complex number of user inputs x 3 4 6 = number of user outputs x 4 5 7 = number of user inquiries x 3 4 6 = number of files x 7 10 15 = number of external interfaces x 5 7 10 = count = total • FP= count-total x [0.65 + 0.01 x  Fi] Fi (i = 1 s/d 14) adalah ‘complexity adjustment values’

31. Pertanyaan-Pertanyaan Untuk menghitung Fi , pertanyaan-pertanyaan dibawah ini dijawab dengan memberi nilai antara 0 s/d 5 • Apakah sistem memerlukan backup dan recovery? • Apakah diperlukan fasilitas komunikasi data? • Apakah diperlukan fasilitas ‘distributed processing’? • Apakah kinerja sangat penting? • Apakah sistem akan dijalankan pada lingkungan yang sudah ada yang sudah terpakai secara penuh? • Apakah memerlukan pemasukan data secara ‘on-line’? • Apakah pemasukan data ‘on-line’ terjadi pada ‘multiple-screen’ atau ‘multiple operation’?

32. Lanjutan • Apakah file master di’update’ secara on-line? • Apakah input,output, file secara inquiry begitu kompleks? • Apakah proses internal begitu kompleks? • Apakah kode yang dibuat harus dapat digunakan ulang? • Apakah konversi dan instalasi termasuk dalam perancangan? • Apakah sistem dirancang untuk dapat diinstall pada berbagai organisasi yang berbeda? • Apakah aplikasi dirancang untuk memberikan fasilitas perubahan dan kemudahan pemakaian bagi user?

33. Feature Points • Seperti function point dengan penambahan karakteristik perangkat lunak lain: algorithma. • Boeing telah mengembangkan function point extension untuk sistem-sistem waktu nyata yang disebut 3D function point. • Untuk menghitung 3D function point hubungan berikut dipakai • Index = I + O + Q + F + E + T + R

34. Keterangan I = input O = output Q = inquiry, F = internal data structure E = external file, T = transformation, R = transition.

36. Penentuan Kompleksitas Transformasi Function Points Semantic Statements 1 - 5 6 - 10 11 + Processing Steps 1 - 10 low low average 11 - 20 low average high 21 + average high high

38. Faktor yang mempengaruhi kualitas • McCall dan Cavano mendefinisikan satu set quality factors yang merupakan tahap awal untuk mengembangkan metrik untuk pengukuran kualitas perangkat lunak: • product operation (using it), • product revision (changing it), dan • product transition (porting it).

39. Kualitas Perangkat Lunak Faktor-faktor yang mempengaruhi kualitas perangkat lunak (GILB): • Correctness: perangkat lunak bekerja dengan baik & benar ( correctness = kesalahan / kloc ) • Maintainability: mudah dirawat; mttc (mean time to change) kecil • Integrity: tahan gangguan; tingkat sekuriti yang baik • Usability: mudah digunakan

40. Proses kumpulan metrik-metrik perangkat lunak software engineering process software data measures project collection data metrics collection software product data indicators collection