RESUME

MANAJEMEN PROYEK PERANGKAT LUNAK

Dosen :

Choirul Zain

Disusun oleh :

Rahayu Eka R (08560082)

Shoni Alam Arista (08560104)

Hadi Rahmanto (08560107)

Didik Kurniawan (08560120)

Eko Arif Wicaksono (08560124)

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS TEKNIK

UNIVERSITAS MUHAMMADIYAH MALANG

2011
 MANAJEMEN PROYEK PERANGKAT LUNAK

SOFTWARE PROJECT MANAGEMENT

Software manajemen proyek meliputi pengetahuan, teknik, dan alat yang diperlukan

untuk manusia usia pengembangan produk perangkat lunak Sekarang ini
modul kurikulum membahas materi yang manager perlu membuat suatu
rencana pengembangan perangkat lunak,menggunakan estimasi efektif ukuran dan usaha, dan
melaksanakan rencana yaitu dengan memperhatikan produktivitas dan kualitas.

Dalam konteks ini, topik seperti risiko,manajemen, alternatif model siklus-hidup,
pembangunan tim organisasi pemerintah, dan manajemen teknologi.
Software manajemen`proyek tetap berbeda`dari manajemen proyek di lainnya.Untuk sejumla
h alasan: Software adalah otak "produk "saja, tidak dibatasi oleh hukum fisika
atau dengan batas-batas proses manufaktur.

Software bisa sangat kompleks.Akhirnya, sebagai sebuah discipline,pengembangan pe
rangkat lunak begitu muda yang Tindakan teknik yang sangat
efektif belum tersedia,dan mereka yang tersedia tidak baik dikalibrasi.

Percaya bahwa manajemen proyek perangkat lunak harus menjadi

bagian dari program rekayasa perangkat lunak karena teknologi yang mengembangkan
perangkat lunak begitu erat terikat dengan teknik pengelolaan. Apa itu jelaskan di
sini adalah pertama manajemen; manusia produk pengelolaan dan manajemen tingkat yang
lebih tinggi adalah domain sekolah bisnis. Beberapa pasangan yang Material dibahas di
sini, seperti penjadwalan alat-alat seperti PERT dan konsep -
konsep seperti kemajuan pelacakan, juga bagian dari program manajemen proyek yang
ditawarkan oleh business sekolah, tetapi titik modul ini
adalah untuk conSider seperti alat dan konsep dalam konteks lunak pembangunan

Manajemen Personal, Produk dan Proses

 Manajemen proyek perangkat lunak mengatur 4 hal penting :
– Personal

– Masalah (problem) à berkaitan dengan Produk

– proses dan

– Proyek à tambahan (tapi sangat penting)

 Empat hal ini berurutan mulai dari yang paling penting.

 Personel mendapat tempat paling penting karena tanpa personal yang baik dan tepat
maka 3 hal lain tidak bisa berjalan dengan baik.

Kategori Personal

• Proses pembangunan PL melibatkan banyak personal dan dikategorikan dalam 5

kategori :

1. manajer senior : yang menentukan usaha yang dikerjakan, dan pemegang

keputusan dalam proyek.
2. manajer proyek (teknis)– pemimpin tim: yang membuat rencana,
memotivasi, mengatur dan mengendalikan praktisi yang mengerjakan PL
3. praktisi : yang mengerjakan PL
4. klien : yang menentukan kebutuhan PL dan pihak lain yang berkaitan
dengan hasil produk
5. pengguna PL : yang berinteraksi langsung dengan PL yang dibangun.

Pemimpin Tim

• Pemimpin Tim PL disini adalah manager proyek.

• Seorang pemimpin tim diharuskan mempunyai ketrampilan memimpin yang cukup.

• Seseorang tidak menjadi pemimpin tim secara kebetulan tapi sungguh-sungguh

karena punya kemampuan.

• Kemampuan yang dibutuhkan dalam kepemimpinan seperti:

Tim Perangkat Lunak (Software Team)

• Struktur organisasi dalam tim ini bisa mengadaptasi dari banyak struktur organisasi
yang sudah ada.
• Berikut beberapa pilihan pembagian tugas/penugasan yang bisa diterapkan untuk tim
perangkat lunak yang terdiri dari n personal yang bekerja selama k tahun:

– n personal ditugaskan untuk sejumlah m tugas yang berbeda dengan sedikit

tugas gabungan.

– n personal di tugaskan untuk sejumlah m tugas yang berbeda dengan m < n

sehingga terbentuk tim informal. Pemimpin tim khusus perlu ada.

– n personal dibagi menjadi sejumlah t tim. Tiap tim ditugaskan mengerjakan

satu atau lebih tugas. Tiap tugas mempunyai struktur yang ditentukan sebelumnya bagi
semua tim

• Cara atau gaya manajemen, jumlah personal, tingkat kemampuan para personel dan
masalah-masalah yang dihadapi tim menentukan bentuk struktur organisasi yang bisa
diterapkan. Yaitu :

– Democratic Decentralized (DD) : Tidak ada pemimpin yang permanen,

koordinator ditunjuk untuk jangka waktu yang pendek, keputusan diambil berdasarkan
konsensus bersama, komunikasi horizontal antar anggota tim (posisi sejajar semua)

– Controlled decentralized (CD) : Pemimpin tim ditentukan, ada wakil

pemimpin dan mereka berbagi tugas, penyelesaian masalah adalah tugas tim dan
implementasinya dibagi di antara beberapa sub-tim oleh pemimpin, komunikasi horisontal di
antara sub-tim dan di antara personel, komunikasi vertikal berdasarkan struktur hirarki

– Controlled Centralized (CC): penyelesaian masalah dikerjakan oleh

pemimpin, pemimpin melakukan koordinasi internal tim, komunikasi lebih banyak vertikal
antara pemimpin dan anggota tim

Masalah (berkaitan dengan produk)

 Masalah à sesuatu yang menghambat tercapainya tujuan (goal).

 Oleh karena itu kita harus mengamati masalah pada awal dimulainya sebuah
proyek.
 Ruang lingkup masalah :
1. Konteks à bagaimana PL yang dibangun dapat memenuhi sebuah sistem,
produk, atau konteks bisnis yang besar, serta batasan apa yang ditentukan sebagai hasil dari
konteks tersebut?

2. Tujuan Informasi à Objek data pelanggan apa yang dihasilkan sebagai output
dari perangkat lunak?

3. Fungsi dan Unjuk kerja à Fungsi apa yang dilakukan oleh PL untuk
mentransformasi input data menjadi output? Adakah ciri kerja khusus yg akan ditekankan?

PERENCANAAN PROYEK INFRASTRUKTUR 

Pada akhir proyek pertemuan kesepuluh meninjau rencana, Dinesh, kepala

pengiriman pada Infosys pada saat itu, tidak terlalu bahagia. Dalam peninjauan setelah
peninjauan rencana proyek, Dinesh telah mencatat bahwa setiap manajer proyek bekerja di
sebuah dunia sendiri, dengan gagah berani berjuang untuk menciptakan proses yang optimal
untuk melaksanakan proyek dan untuk menghasilkan memperkirakan bahwa ia bisa bertemu-
ini meskipun Dinesh tahu bahwa mirip proyek telah dilaksanakan sebelumnya oleh tim-tim
lain yang pengalaman dan data yang cukup bisa meringankan rasa sakit manajer
proyek.Tidak hanya itu manajer proyek investasi usaha perencanaan mereka dalam
menemukan kembali roda, tetapi juga mereka adalah "perencanaan" untuk membuat
kesalahan yang sama seperti para manajer proyek sebelum mereka. Dinesh menyadari bahwa
jawaban untuk keadaan ini terletak pada menciptakan memori institusional yang dapat
diakses oleh semua manajer proyek. 

Database proses (PDB) menangkap data kinerja proyek yang

diselesaikan.Kemampuan proses awal (PCB) merangkum kinerja di seluruh proyek. Hal
demikian menetapkan kuantitatif kisaran hasil yang telah diperoleh dengan mengikuti proses,
dan karenanya berbagai hasil yang akan diharapkan jika proses yang sama diikuti.Proses aset
adalah dokumen-dokumen seperti daftar, template, metodologi, dan pelajaran-bahan yang
menangkap pengalaman masa lalu dan membantu manajer proyek dan insinyur menggunakan
proses secara efektif. Komponen ini biasanya terdapat dalam organisasi tinggi jatuh tempo,
walaupun mereka menggunakan dalam organisasi-organisasi differs.1 

PROSES PERENCANAAN
 Ravi, seperti banyak manajer proyek, telah mempelajari model airterjunpengembanga
n perangkat lunak sebagai proses siklus kehidupan perangkat
lunakutama. Dia siap untuk menggunakannya untuk proyek yang akan
datang, tugaspertama. Namun, Ravi menemukan bahwa model air
terjun tidak dapat digunakankarena pelanggan menginginkan perangkat lunak yang
dikirimkan secara
bertahap,sesuatu yang tersirat bahwa sistem harus disampaikan dan dibangun di bagian-
bagian dan tidak secara keseluruhan.
Situasi di proyek lain tidak jauhberbeda. Dunia nyata jarang menyajikan masalah di
mana sebuah proses baku, atau proses yang digunakan dalam proyek sebelumnya,adalah
pilihan terbaik. Untuk menjadi yang paling cocok, proses yang ada
harusdisesuaikan dengan masalah baru.

UPAYA ESTIMASI DAN PENJADWALAN 

Pada awal tahun 2000, surat kabar dan TV di India melaporkan dengan sorak-sorai
penerbangan tes yang sukses dari sebuah pesawat tempur baru dibangun cahaya.Tetapi
laporan rinci juga menunjukkan sisi suram: Penyerahan prototipe lebih dari lima tahun
terlambat, dan proyek itu biaya lebih dari 10 kali biaya estimasi awal nya.Banyak proyek di
seluruh dunia mengalami nasib yang sama. Tampaknya seolah-olah estimasi biaya dan waktu
tidak pernah cukup untuk mengeksekusi proyek.estimasi yang tidak benar adalah kutukan
dari manajemen proyek dalam banyak disiplin ilmu teknik, dan rekayasa perangkat lunak
tidak berbeda, sebagai catatan buruk proyek perangkat lunak jelas menggambarkan. 

Dalam bisnis jasa, estimasi yang tidak benar jauh lebih sakit. Diminta untuk
mengidentifikasi hal yang ia inginkan dari proyek, Nandan Nilekeni, direktur Infosys,
jawaban, "Tidak ada kejutan." Tidak ada kejutan di bagian depan kepuasan pelanggan, dan
tidak ada kejutan di bagian depan pendapatan dan laba. Lebih sering daripada tidak,
penyebab kejutan yang datang terlambat dalam sebuah proyek di kedua front adalah estimasi
yang tidak tepat usaha atau jadwal. 

Tidak ada solusi cepat dan siap pakai untuk masalah estimasi. Para manajer proyek,
bagaimanapun, dapat meningkatkan estimasi mereka dengan menggunakan pedoman diuji
yang didasarkan pada pengalaman masa lalu dan data. Bab ini membahas pendekatan yang
digunakan oleh manajer proyek Infosys untuk estimasi usaha dan jadwal. Ini mencakup
contoh-contoh dari proyek-proyek nyata dan perkiraan untuk studi kasus ACIC. 

KUALITAS PERENCANAN

Sampai beberapa tahun yang lalu, rekayasa perangkat lunak menderita gagasan tragis
yang sama kualitas yang perusahaan manufaktur sudah jauh lebih awal-bahwa kualitas adalah
sesuatu yang dilakukan pada akhir perakitan / proses pengembangan, sebelum produk
tersebut harus disampaikan. Itu adalah umum untuk melihat kualitas proyek-sadar rencana
manajer untuk menguji sistem setelah pembangunan (manajer proyek lain bahkan tidak
merencanakan dengan baik untuk pengujian sistem!) Tetapi gagal untuk memberikan apapun
kepada tugas-tugas penting kontrol kualitas selama pengembangan. Hasilnya? pengujian
sistem sering mengungkapkan banyak cacat lebih dari yang diantisipasi. Cacat ini, pada
gilirannya, dibutuhkan banyak usaha lebih dari yang direncanakan untuk perbaikan, akhirnya
menghasilkan perangkat lunak kereta yang terlambat dikirimkan. 

Sebagai situasi membaik, manajer proyek mulai merencanakan untuk review dan unit
testing. Tapi mereka tidak tahu bagaimana untuk menilai efektivitas dan implikasi dari
langkah-langkah. Dengan kata lain, proyek masih tidak memiliki tujuan yang jelas kualitas,
meyakinkan rencana untuk mencapai tujuan mereka, dan mekanisme untuk memantau
efektifitas tugas-tugas pengawasan mutu seperti unit testing. 

Dengan penggunaan yang tepat dari pengukuran dan data masa lalu, adalah mungkin
untuk mengobati kualitas dengan cara yang sama Anda memperlakukan dua parameter
penting lainnya: usaha dan jadwal. Artinya, Anda dapat menetapkan tujuan kualitas
kuantitatif, bersama dengan subgoals yang akan membantu melacak kemajuan proyek guna
mencapai tujuan kualitas. 

MANAJEMEN RISIKO 
 Sebuah proyek perangkat lunak adalah suatu usaha yang kompleks. peristiwa Tak
Terduga mungkin memiliki dampak buruk terhadap biaya proyek, jadwal, atau
kualitas. Manajemen risiko adalah suatu usaha untuk meminimalkan kemungkinan kegagalan
yang disebabkan oleh kejadian yang tidak direncanakan. Tujuan dari manajemen risiko tidak
untuk menghindari masuk ke proyek-proyek yang memiliki risiko melainkan untuk
meminimalkan dampak risiko pada proyek-proyek yang dilakukan. Dalam kata-kata
N.R. Narayana Murthy, CEO Infosys, "Ada yang layak dilakukan memiliki risiko Tantangan
bagi seorang pemimpin bukanlah untuk menghindari mereka namun efektif mengelola
mereka melalui strategi de-mempertaruhkan.." Manajemen risiko yang tidak benar, hasil
terutama dari penyakit yang umum optimisme, adalah sumber dari kegagalan proyek banyak. 

Vasu ditunjuk sebagai manajer proyek dari sebuah proyek besar dilakukan oleh
sebuah perusahaan multinasional bergengsi. Proyek ini untuk membangun bagian-bagian dari
suatu sistem terpadu untuk pengelolaan sumber daya di seluruh dunia manusia. Untuk sistem
final, tim perangkat lunak Vasu adalah untuk mengembangkan harus diintegrasikan dengan
sistem yang sedang dikembangkan oleh vendor lain.Untuk digunakan dalam proyek tersebut,
pelanggan menyediakan alat-alat versi berpemilik yang baru akan dirilis segera. Tim Vasu
tentang 35 orang telah sedikit lebih dari satu tahun untuk memberikan perangkat
lunak. Meskipun proyek yang dipekerjakan tim yang bagus dan manajer proyek dibuat
estimasi yang memadai, sistem ditugaskan enam bulan terlambat, dengan tagihan Infosys
pijakan bagi upaya eskalasi 50% dalam proyek tersebut. 

Mengapa proyek ini gagal? Ada dua alasan yang jelas. Pertama, perangkat lunak yang
dikembangkan oleh vendor lainnya tidak dikirimkan tepat waktu, dan antarmuka yang
disediakan untuk tim Vasu's terus berubah. Kedua, versi baru alat pelanggan dirilis selama
pengembangan, membutuhkan software yang akan porting ke versi baru ini. 
Kedua peristiwa ini adalah contoh jelas risiko yang tidak dikelola dengan baik. Risiko ini
yang nyata di awal, walaupun, seperti dengan risiko apa pun, tidak yakin bahwa mereka akan
terwujud. Saat proyek dimulai, manajer proyek, manajer bisnis, dan pelanggan berharap
bahwa vendor lainnya akan menyediakan perangkat lunak pada waktu dan bahwa versi baru
alat tidak akan mempengaruhi proyek. 

Di belakang, Vasu berpikir bahwa jika sebuah tim yang terdiri kemudi-manajer
proyek dari dua proyek dan pelanggan perwakilan-telah dibentuk untuk memastikan
koordinasi yang baik antara dua proyek dan pengiriman mereka, keterlambatan bisa saja
diminimalkan. Untuk risiko kedua, dia berpikir bahwa perangkat lunak harus dikembangkan
pertama dengan versi sebelumnya dari alat. Maka seharusnya sudah bermigrasi ke versi baru
nanti melalui proyek terpisah. Solusi pertama akan diperlukan usaha ekstra minimal, dan
implikasi biaya yang kecil. Yang kedua memiliki implikasi biaya yang jelas bagi
pelanggan. Mungkin untuk menghindari menyenangkan pelanggan, risiko ini tidak disorot
dan mitigasinya tidakdirencanakan. 

PROYEK PENGAWASANDAN PENGENDALIAN 

Sebuah rencana proyek, tidak peduli bagaimana hati-hati disiapkan, masih hanya
selembar kertas. Selama pelaksanaan proyek, Dr Manajer Proyek harus hati-hati memantau
kesehatan pasien-proyek dan memberikan dosis yang tepat obat-tindakan korektif bila
diperlukan. Jika dosis yang tepat diberikan pada waktu yang tepat, pasien bertahan. Tetapi
gagal untuk membaca gejala benar dan gagal untuk memberikan pil pahit tepat waktu dapat
mengakibatkan komplikasi lebih lanjut dan kemungkinan kematian pasien. Dua mini-kasus
berikut menggambarkan hal ini. 

Kasus A: Shiva adalah manajer proyek yang bertanggung jawab untuk

mengembangkan sistem transaksi yang aman untuk sebuah perusahaan reksa dana
besar. Timnya, yang terdiri dari orang-orang yang berdedikasi tetapi banyak junior, memiliki
sedikit pengalaman dalam keamanan komputer. Pengujian unit untuk beberapa modul
pertama ditemukan sejumlah besar cacat-jauh lebih dari yang diharapkan. Setelah analisis,
Siwa disimpulkan bahwa karena sulitnya program dan kurangnya pengalaman dari
programmer, kode yang dihasilkan mempunyai cacat lebih banyak. Akibatnya, ia merasa,
cacat lebih banyak akan mencapai tahap pengujian dan integrasi sistem, dan kecuali sesuatu
yang dilakukan, cacat lebih banyak akan diserahkan. Tindakan korektif dan pencegahan Siwa
ambil adalah untuk menciptakan sebuah tim tes terpisah yang dipimpin oleh orang yang
memiliki bakat untuk detail dan temperamen yang tepat untuk pengujian. Melalui diskusi
dengan pelanggan, ia mampu memperluas uji coba sistem dengan 15 hari. Akhirnya,
meskipun ada penundaan 15 hari, sistem disampaikan melebihi kualitas tujuan dengan
menunjukkan kurang dari cacat diharapkan selama pengujian penerimaan. 
 Kasus B: Setelah tahap desain detail, analisis tonggak dalam proyek Bala
menunjukkan bahwa walaupun tidak ada selip jadwal, ada upaya overrun sebesar
40%. Karena jadwal itu tidak tergelincir, tidak ada tindakan yang diambil. Pada tonggak
berikutnya sebulan kemudian, bagaimanapun, proyek menunjukkan penundaan satu minggu,
yang Bala dijelaskan sebagai hasil dari keadaan khusus.Akhirnya, pembangunan itu selesai
satu bulan terlambat. Untuk top it off, jumlah cacat yang ditemukan dalam pengujian
penerimaan itu berkali-kali tujuan kualitas Bala.Pada akhirnya, proyek gagal pada semua tiga
dimensi: usaha, jadwal, dan kualitas.Kemudian analisis menunjukkan bahwa ia telah salah
mengerti ruang lingkup sistem dan akibatnya telah terlalu meremehkan usaha. Jika lingkup
atau jadwal telah dinegosiasi ulang ketika masalah pertama muncul setelah tonggak desain,
hasil akhir akan sama sekali berbeda. 

Mini-kasus membawa keluar dua aspek kunci dari pemantauan proyek. Pertama,

manajer proyek harus memiliki visibilitas ke status sebenarnya dari proyek, pendekatan yang
terbaik adalah dengan mengukur kuantitatif parameters.1 kunci, 2 Sebagai manajer proyek,
penggunaan utama dari metrik perangkat lunak adalah untuk menyediakan visibility.3
Kedua, visibilitas dengan sendirinya tidak memecahkan masalah. Para manajer proyek benar
harus menafsirkan data, dan jika mereka menemukan bahwa proyek tidak bergerak sepanjang
jalan yang direncanakan, mereka harus melakukan tindakan korektif yang tepat untuk
membawanya kembali ke jalur. Ini pengumpulan data untuk memberikan umpan balik
mengenai keadaan saat ini dan setiap tindakan korektif yang diperlukan membentuk
paradigma mendasar dari manajemen proyek.

PENUTUPAN PROYEK 

Perangkat lunak ini telah diserahkan dan berhasil diinstal. Setelah bekerja berjam-jam
dan akhir pekan selama beberapa bulan proyek ini, manajer proyek dan timnya menarik napas
lega karena proyek ini tidak terlalu berhasil selesai. Tapi apakah manajer proyek belajar
setiap pelajaran? Apakah ia dan anggota tim dapat menghindari mengulangi masalah yang
mereka masuk ke dalam proyek ini? Jika proyek berakhir sekarang, kemungkinan bahwa
cerita akan diulangi dalam proyek lain, mungkin dengan perbaikan kecil. 
 Untuk manajer proyek, tim, dan organisasi, proyek tidak berakhir sampai postmortem
telah dilakukan untuk mengungkap apa yang salah dan mengapa, dan apa yang bekerja dan
mengapa. Analisis ini akan memungkinkan manajer proyek dan anggota tim untuk
pemusnahan keluar pelajaran utama dalam pelaksanaan proyek. Selain membantu anggota
tim dalam proyek-proyek masa depan mereka, pelajaran ini juga akan membantu proyek-
proyek lain untuk meningkatkan eksekusi mereka. 

Sebuah penutupan proyek analisis, atau analisis postmortem, adalah kesempatan emas
bagi perbaikan proses yang tidak boleh missed.1, 2,3,4 Memang, latihan ini dianggap sebagai
praktek terbaik dari perangkat lunak engineering.5 Salah satu langkah dalam paradigma
peningkatan kualitas dari pengalaman factory6 adalah untuk menganalisis data pada akhir
setiap proyek untuk mengevaluasi praktek saat ini, menentukan masalah, dan
sebagainya. Tetapi meskipun manfaatnya, analisis postmortem bukanlah "standar" activity.7