Pangantar Manajemen Proyek Perangkat Lunak

Nama : Paskal Hutapea
Nim : 09 310 732
Kelas : A (RPL)

Manajemen Proyek Perangkat Lunak (MPPL)
Tujuan pembelajaran

• Mendefinisikan batasan manajemen proyek perangkat lunak (MPPL)
• Membedakan pengembangan proyek perangkat lunak dengan lainnya
• Memahami beberapa permasalah dan kekuatiran manajer proyek perangkat lunak
• Mendefinisikan tahapan-tahapan proyek perangkat lunak
• Menjelaskan elemen utama aturan manajemen
• Memahami kebutuhan perencanaan yang baik, monitoring dan kontrol
• Mengidentifikasi stakeholder proyek, tujuan mereka dan cara mengukur keberhasilan dalam mencapai tujuan tersebut

Pengenalan MPPL

• Perencanaan, Monitoring dan Kontrol proyek perangkat lunak
• Mengidentifikasi proyek dan mencapai tujuan Stakholder adalah proyek yang sukses

Proyek Perangkat Lunak Vs Tipe Proyek Lain

• Banyak teknik manajemen proyek umum yang dapat diaplikasikan dengan MPLL, tapi menurut Fred Brooks memberi catatan bahwa produk proyek perangkat lunak mempunyai karakteristik tertentu.
• Satu cara untuk melihat MPLL adalah sebagai proses membuat visible dari invisible

Karakteristik MPPL

1. Tidak nampak
2. Komplek
3. Flexible

Aktifitas dalam MPPL
Tiga proses aktifitas MPPL

1. Studi Kelayakan / evaluasi proyek
2. Perencanaan
3. Implementasi Proyek

Tahapan siklus hidup MPPL

1. Analisa kebutuhan
2. Spesifikasi
3. Disain
4. Coding
5. Verifikasi dan validasi
6. Implementasi / Instalasi
7. Maintenance dan support

Kategori proyek perangkat lunak
Kategori proyek perangkat lunak berdasarkan
sistemnya :
1. Sistem informasi
Contoh : Sistem kontrol stok
2. Sistem embedded / real time
Contoh : Sistem kontrol AC
Proyek dapat dikategorikan berdasarkan orientasinya :
1. Produk
Proyek membuat produk yang detailnya ditentukan oleh client dan Client bertanggung jawab menjustifikasi produk tersebut
2. Tujuan
Proyek diperlukan untuk mencapai tujuan tertentu biasanya berhubungan dengan level service
Proyek sebagai sebuah system
Sebuah proyek mempertimbangkan untuk membuat sistem baru dan atau merubah sistem lama menjadi baru dan proyek itu sendiri adalah sebuah system
Sistem, subsistem dan linkungan sistem

•  Definisi sederhana dari sistem adalah sebuah kumpulan dari bagian-bagian yang saling berhubungan. Sebuah sistem normalnya merupakan bagian dari sistem yang lebih besar dan sistem itu sendiri terdiri dari subsistem.

•  Di luar dari sistem adalah lingkungan sistem. LIngkungan sistem ini dapat mempengaruhi sistem tapi sistem tidak bisa mengontrol langsung.

•  Pada kasus kampus Brighmouth, bangkrutnya supplier utama perangkat IT adalah kejadian yang menimpa pada lingkungan sistem

Sistem Terbuka Vs Sistem Tertutup

•  Sistem terbuka yaitu yang berinteraksi dengan lingkungan. Hampir semua sistem adalah terbuka. Salah satu alasan nahwa sistem engineering dan proyek membentuk sistem tersebut sering kali gagal dikarenakan keterlibatan staf teknikal tidak menghargai tingkat sistem yang terbuka dan mudah dipengaruhi oleh perubahan dari luar

Sub optimasi

•  Adalah sebuah subsistem yang bekerja pada saat optimum tapi mempunyai efek yang merugikan pada keseluruhan sistem

•  Contoh pengembang perangkat lunak menyerahkan ke user sebuah sistem yang sangat efisien pada penggunaan sumber daya mesin tapi juga sangat susah untuk dimodifikasi.

Sistem sosioteknikal

•  Proyek perangkat lunak ini tergolong dalam kategori sistem ini. Setiap proyek perangkat lunak membutuhkan organisasi teknikal dan organisasi orang.

•  Manager Proyek perangkat lunak diperlukan baik kompetensi teknikal dan kemampuan untuk berinteraksi dengan orang lain secara persuasif.

Masalah proyek perangkat lunak
Masalah-masalah proyek dilihat dari kacamata
manajer :

•  Estimasi dan rencana yang jelek

•  Standard dan pengukuran kualitas yang kurang
•  Petunjuk yang kurang tentang membuat keputusan organisasi
•  Difinisi aturan yang jelek – siapa mengerjakan apa ?
•  Kriteria sukses yang salah

Masalah-masalah yang diidentifikasi oleh mahasiswa sistem komputer dan
informasi yang telah menyelesaikan penempatan industri :

•  Spesifikasi pekerjaan yang kurang
•  Manajemen mengabaikan IT
•  Pengetahuan area aplikasi yang kurang
•  Standard yang kurang
•  Update dokumentasi yang kurang
•  Aktifitas sebelumnya yang tidak lengkap pada waktunya – termasuk pengiriman perangkat yang terlambat
•  Komunikasi antara teknisi dan user yang kurang
•  Komunikasi yang kurang menyebabkan duplikasi pekerjaan
•  Komitmen yang kurang – khusunya ketika proyek terikat pada satu orang kemudian keluar
•  Kemampuan Keahlian teknikal yang kurang
•  Perubahan kebutuhan hukum
•  Perubahan lingkungan perangkat lunak

•  Tekanan deadline
•  Pengendalian kualitas yang kurang
•  Management jarak jauh
•  Pelatihan yang kurang

Pengontrolan manajemen

•  Siklus hidup pengontrolan proyek
•  Tujuan harus didifinisikan dengan jelas
•  Pengukuran efektifitas konkret dan jelas dengan jawaban dari pertanyaan yes / no

Contoh : Apakah kita akan menginstal perangkat lunak baru sebelum 1 Jani ?

•  Tujuan harus diturunkan ke sub tujuan / goal

Stakeholder

•  Tim Proyek internal
•  Tim Proyek eksternal tapi dalam satu organisasi
•  Pihak eksternal dari tim proyek dan organisasi

Kebutuhan spesifikasi
Umumnya kasus proyek berorientasi produk
mempunyai tujuan :

•  Kebutuhan fungsional
•  Kebutuhan kualitas
•  Kebutuhan sumberdaya

Informasi dan pengontrolan dalam organisasi

•  Hirarki sistem informasi dan pengontrolan
•  Level pengambil keputusab dan informasi
•  Perbedaan tipe informasi
•  Kuantifikasi pengukuran efektifitas mengurangi salah persepsi