4. Konsep Manajemen Proyek Perangkat Lunak

Presentasi berjudul: "4. Konsep Manajemen Proyek Perangkat Lunak"— Transcript presentasi:

1 4. Konsep Manajemen Proyek Perangkat Lunak
4.1 People 4.1.1 Para Pemain (Stakeholder) 4.1.2 Pemimpin Tim 4.1.3 Tim Perangkat Lunak 4.1.4 Tiga Organisasi Tim (Mantei) 4.1.5 Faktor-faktor dalam Perencanaan Struktur Tim RPL (Mantei) 4.1.6 Pengaruh Karakteristik Proyek pada Struktur Tim 4.1.7 Masalah Koordinasi dan Komunikasi 4.1.8 Teknik Koordinasi Proyek (Kraul dan Streeter) 4.2 Problem 4.2.1 Ruang Lingkup Masalah 4.2.2 Dekomposisi Masalah 4.3 Proses 4.3.1 Menggabungkan Masalah dan Proses 4.3.2 Dekomposisi Proses 4.3.3 Contoh Dekomposisi (simple project) 4.3.4 Contoh Dekomposisi (complex project)

2 Konsep Manajemen Proyek Perangkat Lunak
Manajemen Proyek Perangkat Lunak merupakan suatu aktivitas pelindung (umbrella activity) 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 komprehensif dalam pembangunan perangkat lunak

3 4.1 People 4.1.1 Para Pemain (Stakeholder)
Senior managers: yang menentukan isu-isu bisnis yang sering memiliki pengaruh penting dalam proyek. Project (technical) managers: yang harus merencanakan, memotivasai, mengorganisasi, dan mengontrol sebuah produk atau aplikasi. Practitioners: yang menyampaikan keteranpilan 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 4.1.2 Pemimpin Tim Pemimpin tim (team leaders): seseorang yang memimpin sebuah proyek perangkat lunak. Syarat : Model Kepemimpinan MOI (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 4.1.3 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 4.1.4 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 4.1.5 Faktor-faktor dalam Perencanaan 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 4.1.6 Pengaruh Karakteristik Proyek pada Struktur Tim

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

10 4.1.8 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 kegiatan, diantaranya inspeksi desain dan kode. Prosedur interpersonal, informal. Group meeting untuk bertukar informasi dan problem solving, requirement gathering dan pengembangan staff. Komunikasi elektronik. , E-BB, web sites, video conference. Jaringan interpersonal. Diskusi informal dengan orang di luar proyek.

11 4.2 Problem Manajer proyek perangkat lunak berhadapan dengan dilema awal proyek, yaitu menentukan perkiraan 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: definisikan scope (ruang lingkup) dengan benar dan segera.

12 4.2.1 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 4.2.2 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 sesuatu Manusia cenderung melakukan dekomposisi jika menghadapi masalah yang kompleks

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

15 4.3.1 Menggabungkan Masalah dan Proses
Tahap awal project planning dimulai dengan penggabungan problem dan process. Setiap fungsi yang akan direkayasa harus melampaui 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, menginstal, dan memberikan dukungan kepada pemakai (dokumen dan pelatihan) Customer evaluation – umpan balik pelanggan Selanjutnya dibuat matriksnya.

16

17 4.3.2 Dekomposisi Proses Memilih paradigma rekayasa perangkat lunak yang paling baik sesuai dengan tingkat relativitas 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 4.3.3 Contoh Dekomposisi (simple project)
Membuat daftar klarifikasi Bertemu dengan customer untuk klarifikasi Bersama-sama menentukan scope Review scope Penyempurnaan scope berdasarkan berbagai kendala

19 4.3.4 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 spesifikasi detail yang merefleksikan data, fungsi, dan karakteristik yang berhubungan dengan perilaku perangkat lunak Mengkaji setiap spesifikasi detail tersebut untuk upaya perbaikan, konsistensi, dan mengurangi ambiguitas Mencantumkan spesifikasi detail ke dalam sebuah dokumen ruang lingkup Mengkaji dokumen ruang lingkup dengan semua pendapat yang ada. Memodifikasi dokumen ruang lingkup sesuai dengan kebutuhan. ***