Transcript KPL3_Chapter4_Manajemen Proyek

092904006
092904010
092904011
092904030
092904035
092904041
092904043
SYAPUTRI ARTAMI S
AYU ANGGRIANI H
RUDI DIAN SYAH
ZUL FADLY SULTHAN
JUMIATI
HUSNAENI
NURHALIMAH
kegagalan banyak megaproyek perangkat lunak
pada tahun 1960-an dan awal 1970-an merupakan
petujuk awal mengenai kesulitan manajemen perangkat
lunak.
proyek-proyek ini gagal bukan karena manajer
atau programer tidak kompeten. Sebaliknya, proyek
yang besar dan menantang ini menarik ornga – orang
dengan kemampuan diatas rata-rata. Kegagalan yang
terjadi ditimbulkan oleh pendekatan manajemen yang
digunakan.
Kebutuhan akan manajemen merupakan
perbedaan penting antara pengembangan perangkat
lunak profesional dan pemograman yang amatir. Kita
memerlukan majaemen proyek perangkat lunak karena
rekayasa perangkat lunak profesional salalu dibatasi
oleh anggaran dan jadwal.
Manajer perangkat lunak bertanggung jawab
dalam merencanakan dan menjadwalkanpengembangan
proyek. Mereka mensupervisi pekerjaan untuk
menjamin pengerjaan sesuai dengan standar.
Menejemen yang baik tidak dapat menjamin
keberhasilan proyek. Namun demikian semula , dan
gagal memenuhi persyaratan pemesan.
Manajemen perangkat lunak melakukan
pekerjaan yang sama dengan menejer proyek rekayasa
lain. Namundemikian, rekayasa perangkat lunak
berbeda dari jenis rekayasa lain karena beberapa hal,
manajemen perangkat lunak sangat sulit.
Beberapa perbedaan pada
Manajemen perangkat lunak
1.
Produk pernagkat lunak tidak berwujud.
Manjemen proyek pembuatan kapal atau proyek
rekayasa sipil dapat melihat produk yang dikembangkan .
Jika satu jadwal tidak tepat, efek pada produk akan tampak
.bagian-bagian struktur yang bersangkutan jelas tidak
selesai. Perangkat lunak tidak dapat dilihat atau disentuh.
Manajer proyek perangkat lunak tidak dapat melihat
kemajuan. Mereka bergantung pada orang lain yang
membuat dokumentasi yang dibutuhkan untuk meninjau
kemajuan.
2. tidak ada proses perangkat lunak standar.
kita tidak memilki pemahaman yang jelas mengenai
hubungan antara proses perangkat lunak dan jenis produk.
Pada disiplin rekayasa dengan sejarah yang panjang, proses
dicoba dan diuji. Proses rekayasa untuk jenis sistem tertentu,
seperti jembatan, dipahami dengan baik. Pemahaman kita
mengenai proses perangkat lunak telah berkembang dengan
signifikan dalam beberapa tahun terakhir ini. Namun
demikian, kita tetap tidak dapat meramalkan dengan pasti
kapan suatu proses perangkat lunak akan menyebabkan
masalah pada pengembangan.
3. Proyek perangkat lunak yang besar seringkali
merupakan proyek………………..
sangat luas yang dapat dipakai untuk
memperkecil ketidakpastian pada rencana. Secara
konsekuen, antisipasi masalah lebih sulit. Lebih jauh
lagi, perubahan teknologi yang cepat dalam komputer
dan komunikasi akan meghapus pengalaman
sebelumnya.
Kegiatan-kegiatan Manajemen
Pekerjaan ini sangat bervariasi, tergantung pada
organisasi dan produk perangkat lunak yang
dikembangkan. Namun demikian, sebagian besar
manajer mengambil tanggung jawab pada beberapa
Penulisan proposal
Beberapa atau seluruh tahap
kegiatan manajemen
Perencanaan dan penjadwalan
proyek
Pembiayaan proyek
Pemantauan dan peninjauan proyek
Pemilihan dan evaluasi personel
Penulisan laporan dan presentasi
Tahap pertama proyek peragkat lunak dapat
melibatkan penulisan proposal untuk melaksanakan
proyek tersebut. Proposal mendeskripsikan tujuan
proyekdan bagaimana pelaksanaannya.
Penulisan proposal merupakan pekerjaan kritis
karena keberadaan banyak organisasi perangkat lunak
bertanggung pada banyaknya proposal yang telah
disetujui dan kontrak yang didapat.
Pemantauan proyek merupakan kegiatan proyek
yang berkesinambungan. Manajer harus mengetahui
kemajuan proyek dan membandingkan kemajuan dan
biaya yang sebesarnya dikeluarkan dengan biaya yang
direncanakan.
Pemantauan informal seringkali dapat
meramalkan masalah proyek yang potensial karena
pemantauan ini dapat mengungkapkan kesulitan pada
saat kejadian.
selama berjalannnya proyek adalah normal untuk
memiliki sejumlah tinjauan manajemen proyek formal.
Tinjauan ini berhubungan dengan peninjauan kemajuan
secara keseluruhan dan pengembangan teknis proyek
terebut dan mempertimbangkan status proyek terhadap
tujuan organisasi yang memesan perangkat lunak
tersebut.
waktu pengembangan untuk proyek perangkat
lunak besar bisa memakan waktu beberapa tahun.
Selama itu, tujuan organisasi bisa dipastikan berubahubah. Perubahan – perubahan ini dapat menyebabkan
perangkat lunak tidak lagi dibutuhkan atau sudah tidak
sesuainya bagi persyaratan proyek yang asli.
Alasan kebanyakan kasus manajer
harus menerima tim proyek yang
kurang ideal.
Anggaran prroyek mungkin tidak memenuhi
penggunaan staf yang harus dibayar mahal.
2. Staf dengan pengalaman yang sesuai mungkin tidak
tersedia baik di dalam maupun di luar organisasi.
3. Organisasi mungkin ingin mengembangkan
keahlian karyawannya. Staf yang tidak
berpengalaman bisa ditugaskan pada suatu proyek
untuk belajar dan memproleh pengalaman.
1.
Perencanaan Proyek
Manajemen yang efektif bagi proyek perangkat
lunak bertumpu pada perencanaan kemajuan proyek
yang menyeluruh. Manajemen proyek harus
mengantisipasi masalah yang mungkin muncul dan
menyiapkan solusi tentatif terhadap masalah-malasah
tersebut. Rencana ini berubah seiring berjalannya
proyek dan tersediannya informasi yang lebih baik.
selain rencana proyek, manajer munkin juga
harus membuat rencana lainnya.
Pseudo-code yang ditunjukan pada Peraga 4.2
mendeskripsikan proses perencanaan proyek untuk
pengembangan perangkat lunak . Kerana informasi
proyek akan kita dapatkan selama belangsungnya
proyek, perncanaan harus direvisi secara reguler. Tujuan
bisnis yang utama merupakan faktor penting yang harus
diperhitungkan ketika merumuskan rencana proyek.
Jika tujuan tersebut berubah,
perubahan terhadap rencana
proyek perlu dilakukan
Rencana
Keterangan
Rencana kualitas
Mendeskripsikan prosedur kualitas dan
standar yang akan digunakan pada
sebuah proyek.
Rencana validasi
Mendeskripsikan pendekatan, sumber
daya, dan jadwal yang digunakan untuk
validasi.
Rencana manajemen konfigurasi
Mendeskripsikan prosedur dan struktur
manajemen konfigurasi yang akan
digunakan.
Encana pemeliharaan
Meramalkan pemeliharaan sistem ,
biaya pemeliharaan , dan usaha yang
dibutuhkan .
Peraga 4.1 Jenis- jenis rencana
Proses perencanaan dimulai dengan penilaian
batasan-batasan ( tanggal penyerahan yang diminta, staf
yang tersedia, anggaran total, dll ) yang dipengaruhi
proyek. Tahap-tahap kemajuan dan apa yang harus
diserahkan pada saat itu kemudian didefenisikan. Proses
kemudian memasuki loop.
Manajer proyek merevisi asumsi-asumsi proyek
dengan bertambah banyaknya informasi yang masuk.
Jika proyek tertunda, mereka mungkin harus melakukan
negosiasi ulang mengenai batasan proyek dan apa yang
harus yang diserahkan kepada pelanggan.
tujuan tinjauan ini adalah untuk menemukan
pendekatan alternatif terhadap pengembangan yang
masuk dalam batasan-batasan proyek dan memenuhi
jadwal.
Rencana Proyek
rencana proyek menentukan sumberdaya yang
tersedia bagi proyek , pembagian pekerjaan, dan jadwal
untuk melakukan pekerjaan tersebut. Pada beberapa
organisasi, rencana proyek merupakan satu dokumen
yang mencakup semua jenis rencana .
struktur rencana yang saya deskripsikan disini
adalah untuk jenis rencana yang kedua. Perincian
rencana proyek bervariasi , tergantung pada jenis proyek
dan organisasi.
Sebagian besar rencana harus
mencakup bagian-bagian berikut
ini :
Pendahuluan . Bagian ini dengan singkat
mendeskripsikan tujuan proyek dan menetukan
batasan-batasan yang mempengaruhi manajemen
proyek.
2. Organisasi proyek. Bagian ini mendeskripsikan
bagaimana tim pengembangan diorganisir, siapa saja
yang terlibat dan perannya dalam tim.
3. Analisis risiko. Bagian ini mendiskripsikan risiko
proyek yang mungkin timbul , kemungkinan
munculnya risiko-risiko tersebut dan strategi
pengurangan risiko yang diusulkan .
1.
Persyaratan sumberdaya perangkat keras dan perangkat
lunak. Bagian ini mendeskripsikan perangkat keras dan
perangkat lunak pendukung yang dibutuhkan untuk
melakukan pengembangan.
5. Pembagian kerja. Bagian ini mendiskripsikan pembagian
proyek menjadi kegiatan-kegiatan , dan identifikasi
patokan dan hasil yang diharapkan dari setiap kegiatan.
6. Jadwal proyek. Bagian ini mendeskripsikan
ketergantungan antara kegiatan, perkiraan waktu yang
diperlukan untuk mencapai setiap patokan dan alokasi
SDM bagi kegiatan-kegiatan tersebut.
7. Monitor dan mekanisme pelaporan. Bagian ini
mendeskripsikan laporan manajemen yang dihasilkan,
kapan laporan itu harus diberikan, dan mekanisme
pemantauan proyek yang digunakan.
4.
Patokan (milestone) dan Hasil yang
dapat diserahkan (deliverable)
Manajer memerlukan informasi. Karena
perangkat lunak tidak berwujud, informasi ini hanya
dapat diberikan sebagai dokumen yang mendiskripsikan
status perangkat lunak yang sedang dikembangkan.
Tanpa informasi ini, tidaklah mungkin dilakukan
penilaian kemajuan dan perkiraan biaya, sehingga
jadwal tidak dapat di update.
Penjadwalan Proyek
penjadwalan proyek merupakan pekerjaan yang
sangat menantang bagi manajer perangkat lunak.
Manajer memperkirakan waktu dan sumber daya yang
diperlukan untuk menyelesaikan kegiatan dan
mengaturnya dalam urutan yang logis.
jika proyek tersebut canggih dari segi teknis dari
segi teknis, perkiraan awal hampir pasti akan optimis tis
bahkan jika manajer mencoba memperhitungkan semua
kemungkinan.
Kegiatan proyek normalnya harus berdurasi
setidak-tidaknya seminggu. Dalam perkiraan jadwal,
manajer tidak boleh mengasumsikan bahwa setiap tahap
proyek akan bebas dari masalah.
Sebagaimana halnya waktu kelender , manajer
juga harus memperkirakan sumber daya yang
diperlukan untuk menyelesaikan setiap pekerjaan.
suatu kaidah yang baik untuk di ikuti adalah
membuat estimasi seolah tidak akan ada masalah,
kemudian menaikkan nya untuk memperhintungkan
masalah yang diantisiapasi .
jadwal proyek biasanya dipresentasikan sebagai
seperangkat diagram yang menunjukan pembagian
pekerjaan, ketergantungan kegiatan , dan alokasi staf.
Diagram batang dan jaringan
kegiatan
Diangram batang dan jaringan kegiatan
merupakan notasi grafis yang dipakai untuk
mengilustrasikan jadwal proyek. Diagram batang
menunjukan siapa yang bertanggung jawab untuk setiap
kegiatan dan kapan kegiatan tersebut dijadwalkan
dimulai dan berakhir.
Pekerjaan
Durasi (hari)
Ketergantungan
T1
8
T2
15
T3
15
T4
10
T5
10
T2, T4 (M2)
T6
5
T1, T2 (M3)
T7
20
T1 (M1)
T8
25
T4 (M5)
T9
15
T3, T6 (M4)
T10
15
T5, T7 (M7)
T11
7
T9 (M6)
T12
10
T11 (M8)
T1 (M1)
Peraga 4.5 Durasi dan keuntungan pekerjaan
lihatlah rangkaian kegiatan yang ditunjukan pada
Peraga 4.5. Table tersebut menunjukan kegiatan, durasi
dan saling ketergantungannya. Dari peraga 4.5 anda
dapat melihat bahwa perkerjaan T3 bergantung pada T1.
ini berarti bahwa T1 harus selesai sebelum T3 dimulai.
pada tool manajement proyek yang dipakai unutk
memebuat diagram ini , semua kegiatan harus berakhir
pada patokan. Suatu patokan bisa dimulai ketika
patokan sebelumnya(yang munkin tergantungpada
beberapa kegiatan) telah dicapai.
Dengan demikian kolom, pada kolom ketiga di peraga
4.5, saya juga telah menunjukan patokan patokan yang
bersangkutan dengannya, yang dicapai ketika pekerjaan pada
kolom tersebut berakhir (lihat Peraga 4.6).
Sebelum menuju ke patokan ke patokan yang lainnya,
semua jalur yang menuju ke patokan tersebut harus telah
selesai. Sebagai contoh,pekerjaan T9, yang ditunjukan pada
Peraga 4.6, tidak dapat dimulai sampai pekerjaan T3 dan T6
selesai. Kedatangan pada patokan M4 menunjukan bahwa
pekerjaan-pekerjaan ini telah selesai.
Dilain pihak, penundaan kegiatan yang tidak berada
pada jalur kritis tidak perlu menyebabkan ketidaktepatan
jadwal secara keseluruhan. Selama penundaan tidak
memperlama kegiatan ini sedemikian besar sehingga waktu
total melampaui jalur kritis, jadwal proyek tidak akan
terpengaruh.
Peraga 4.7 merupakan cara alternatifuntuk
mempersentasikan informasikan jadwal proyek. Gambar
tersebut merupakan diangram batang (kadang kala disebut
diagram Gantt, sesuai penemunya) yang menuntujukan
kalender proyek dan tanggal dimulainya dan selesainya
kegiatannya.
Peraga 4.7 Diangram batang kegiatan
Peraga 4.9 Alokasi waktu vs diagram waktu
Perga 4.8 juga dapat diproses dengan tool
pendukung manajemen proyek dan diagram batang
dibuat untuk menunjukan periode waktu ketika satf
dipekerjakan pada proyek (Peraga 4.9 )
Organisasi besar biasanya memperkerjakan
sejumlah spesialis yang bekerja pada proyek
sebagaimana diburtuhkan. Hal ini dapat menyebabkan
masalah penjadwalan. Jika satu proyek tertunda katika
seorang spesialis sedangkan mengerjakannya, hal ini
bisa menimbulkan efek tak terduga pada proyek lain .
Manajemen Risiko
satu tugas penting bagi manajer proyek adalah
mengantisipasi risiko yang dapat mempengaruhi jadwal
proyek atau kualitas perangkat lunak yang sedang
dikembangkan, dan mengambil tidakkan guna
menghindari risiko ini.
Risiko proyek, Risiko yang mempengaruhi jadwal
atau sumber daya proyek.
2. Risiko Produk. Risiko yang mempengaruhi kualitas
atau kinerja perangkat lunak yang dikembangkan.
3. Risiko bisnis, Risioko yang mempengaruhi organisasi
yang sedang mengembangkan atau mengadakan
perangkat lunak tersebut.
1.
Manajer risioko sangat penting bagi proyek
perangkat lunak akibat adanya ketidakpastian yang
dihadapi sebagian besar proyek.
Jenis-jenis risiko yang yang dapat mempengaruhi
proyej yang bergantung pada proyek tersebut dan
lingkungan organisasi dimana perangkat lunak tersebut
dikembangkan . Namun demikian, banyak risiko yang
bersifat universal dan mendeskripsikan bebertapa
dinataranya pada Peraga 4.10
Peraga 4.10 Risiko perangkat lunak yang mungkin terjadi
Peraga 4.11 Proses manajemen Risiko
Proses manajemen Risiko di
ilustrasikan pada Peraga 4.11
1) Identifikasi risiko. Risiko Proyek, produk dan bisnis
yang mungkin terjadi di identifikasi.
2) Nanalisis risiko. Kemungkinan dan konsekuensi
risiko-risiko yang di nilai.
3) Perancangan risiko. Dibuat rencana untuk
menangani risiko apakah dengan menghindari atau
meminimasi afeknya pada proyek.
4) Monitor risiko. Risiko dinilai secara konstan dan
rencana unutk meringankan risiko direvisi seiring
bertabahnya informasi mengenai risiko tersebut.
Identifikasi Risiko
Indentifikasi risiko merupakan tahap awaldari
manajemen risiko. Tahap ini berkenaan dengan
penemuan risiko yang mungkin terjadi pada suatu
proyek. Pada prinsipnya, risiko-risiko ini tidak boleh
dinilai atau diberi prioritas pada thap ini walaupun,
pada prakteknya,risiko dengan konsekuensi yang sangat
kecil atau risiko dengan kemungkinan yang sangat
rendah biasanya tidak diperhitungkan.
Jenis-Jenis Risiko
1) Risko Manusia.
2) Risiko Organisasi
3) Risiko alat bantu
4) Risiko Prasyaratan
5) Risiko ekstimasi
Peraga 4.12 Risiko dan jenis risiko
Analisis Risiko
hasil proses analisis ini harus dimbulasikan
dengan table yang disusun menurut keseriusan risiko.
Peraga 4.13 mengilustrasikan risiko yang diidentifikasi
pada Peraga 4.12. Jelas bahwa penilaian probabilitas dan
keseriusan di sini bisa berubah.
Tentu saja, baik probalitas maupun penilaian efek
risiko bisa berubah dengan tersedianya rencana
manajemen risiko . Dengan demikian table ini harus diupdate pada setiap iterasi proses risiko.
Peraga 4.13 Analisis Risiko
Perancangan Risiko
Proses perancangan risiko memperhitungkan
masing-masing risiko kunci yang telah dikenali dan
mengidentifikasi strategi unutk menangani risiko
tersebut. Tidak ada proses sederhan yang dapat kita
ikuti untuk menetapkan rencana manajemen risiko.
Peraga 4.14 menunjukan strategi yang mungkin,
yang didentifikasi untuk risiko-risiko kunci pada Peraga
4.13.
Peraga 4.1.4 Strategi manajemen Risiko
Strategi-strategi ini dibagi menjadi
3 kategori :
1) Strategi menghindar. Strategi ini
ditunjukan unutk memperkecil
probabilitas munculnya risiko tersebut.
2) Strategi minimasi. Strategi ini ditunjukan
untuk memperkecil dampak risiko yang
ada.
3) Rencana Kontijensi. Dengan mengikuti
strategi ini, jika terjadi yang terburuk .
Pemantauan Risiko
Pemantauan risiko mencakup penilaian secara
reguler dari setiap risiko yang teridetifikasi unutk
memutuskan apakah probalitas terjadinya risiko
tersebut menjadi lebih besar atau lebih kecil dan apakah
efeknya telah berubah.
Pemantauan risiko harus merupakan proses yang
berkesinambungan dan pada setiap peninjauan
kemajuan manajemen, setiap risiko kunci harus
dipikirkan secara terpisah dan dibahas dalam rapat.
Peraga 4.15 Faktor-faktor risiko
Hal-hal penting
 Manajemen proyek perangkat lunak yang baik sangat




penting jika proyek rekayasa perangkat lunak akan
dikembangkan tepat waktu dan dalam batasan-batasan
anggaran yang ada.
Manajemen perangkat lunak berbeda dari manajemen
rekasaya lain.
Manajer perqangkat lunak memilki peran yang beragam
Patokan (milistone) proyek adalah hasil yang dapat dimana
laporan formal mengenai kemajuan harus diberikan ke
manajemen.
Risiko proyek yang besar harus didentifikasi dan dinilai
unutk menrapkan probalitas dan konsekuensinya pada
proyek.