Manajemen proyek Perangkat Lunak (PL) yang efektif berfokus

pada 3 P, dimana harus berurut yaitu

 PEOPLE :
› Elemen terpenting dari suksesnya proyek
 PRODUCT /PROBLEM :
› Software yang dikembangkan
 PROCESS :
› Suatu kerangka kerja dari suatu aktifitas dan kumpulan tugas
untuk mengembangkan PL
 PROJECT (tambahan) :
› Penggabungan semua kerja untuk membuat produk menjadi
kenyataan
 SEI telah mengembangkan suatu model
kematangan kemampuan manajemen manusia
(People Management Capability Manurity Model
(PM – CMM) ) untuk :
› Mempertinggi kesiapan organisasi PL dalam membuat
aplikasi yang semakin kompleks sehingga menarik,
› Menumbuhkan, memotivasi, menyebarkan dan
memelihara bakat yang dibutuhkan untuk
mengembangkan kemapuan mengembankan PL
mereka.
 Model kematangan manajemen manusia
membatasi pada
› Rekruitmen
› Seleksi
› Manajemen unjuk kerja
› Pelatihan
› Kompensasi
› Pengembangan karir
› Desain kerja & organisasi
› Perkembangan karir tim / kultur
 Manusia dalam pengembangan PL
terdiri dari :
› Player (Pemain)
› Team Leader (Pimpinan Tim)
› The Software Team ( Tim PL)
 Manajer Senior
› menentukan isu bisnis yang mempengaruhi dalam proyek

 Manajer Proyek
› merencanakan, memotivasi, mengorganisir, mengontrol
aplikasi/produk

 Pelaksana
› mempunyai ketrampilan teknik untuk merekayasa aplikasi

 Pelanggan
› menentukan jenis kebutuhan bagi PL yang akan dibuat

 Pemakai akhir
› yang berinteraksi dengan PL yang dibuat
 Model Kepemimpinan menurut Jerry Weinberg
yaitu : Motivasi, Organisasi, gagasan & Inovasi
(MOI)

 Karakteristik yang menentukan manajer proyek

efektif yaitu
› Pemecahan Masalah
› Prestasi
› Identitas manajerial
› Pengaruh & pembentukan tim
 Sumber daya manusia kepada sebuah proyek yang akan
membutuhkan n manusia yang bekerja selama k tahun ,
 Ada beberapa alternatif untuk menentukan sumber daya tersebut :
1. n orang mengerjakan tugas fungsional berbeda sebanyak m
dengan sedikit kombinasi kerja & koordinasi tanggung jawab
manajer proyek

2. n orang mengerjakan tugas fungsional berbeda sebanyak m

(m<n), seorang pemimpin tim ad hoc dapat dipilih, koordinasi
bertanggung jawab manajer PL

3. n orang diatur di dalam tim , setiap orang mengerjakan >= 1

tugas fungsional, setiap tim mempunyai sebuah struktur spesifik
yang ditentukan untuk semua tim yang bekerja pada sebuah
proyek, koordinasi dikontrol oleh tim itu sendiri dan oleh manajer
proyek PL (sistem ini paling produktif)
Mantei, mengusulkan 3 organisasi tim yaitu:

 Demokrasi terdesentralisasi (DD)

 Terkontrol terdesentralisasi (CD)
 Terkontrol tersentralisasi (CC)
 Democratic Decentralized (DD)
› Tidak memiliki pimpinan permanen dan koordinator dipilih
untuk tugas pendek bila tugas berbeda maka pimpinan
berbeda.
› Keputusan diambil oleh konsensus kelompok dan
komunikasi secara horizontal
 Controlled Decentralized (CD)
› Tim memiliki pimpinan tertentu dan memiliki pimpinan
skunder untuk sub-sub masalah. Pemecahan masalah
merupakan aktifitas dari kelompok dan implentasi
pemecahan pada sub-sub kelompok.
› Komunikasi antar kelompok dan orang bersifat horizontal
tetapi komunikasi secara vertical berjalan bila hirarki
kontrol berjalan .
 Controlled Centralized (CC)
› Pemecahan tingkat puncak dan internal tim oleh
pimpinan tim.
› Komunikasi dilakukan secara vertical.
 7 faktor proyek yang harus dipertimbangkan
dalam rencanakan tim RPL yaitu :
1. Kesulitan pada masalah
2. Ukuran program yang dihasilkan (LOC / function)
3. Waktu tim (umur)
4. Tingkat dimana dapat dimodularitasi
5. Kualitas serta keandalan
6. Kepastian tanggal penyampaian
7. Tingkat sosiabilitas / komunikasi
 DD CD CC

Tingkat Kesulitan Tinggi Rendah Rendah

Ukuran Kecil Besar Besar

Umur Tim Panjang Singkat Singkat

Modularitas Rendah Tinggi Tinggi

Keandalan Tinggi Tinggi Rendah

Tanggal
Longgar Longgar Ketat / Pasti
Pengiriman

Sosiabilitas Tinggi Rendah Rendah

1. Paradigma Tertutup
› Membentuk hirarki otoritas tradisional ( mirip tim
CC) tetapi kurang inovatif

2. Paradigma Random
› Membentuk tim longgar & tergantung pada
inisiatif individual tim, untuk inovasi sangat
baik(unggul) bila unjuk kerja tim teratur.
3. Paradigma Terbuka
› Membentuk tim dengan cara tertentu sehingga
banyak kontrol, inovasi banyak . Cocok untuk
masalah yang kompleks tetapi tidak seefesien
tim lainnya

4. Paradigma Sinkron
› Mengorganisasikan tim untuk bekerja pada
bagian-bagian kecil masalah dengan
komunikasi aktif pada tim
Proyek PL mengalami kesulitan dikarenakan :

 Skala usaha pengembangan yang besar sehingga

kesulitan dalam mengkoordinasi anggota tim &
Kompleksitas yang semakin besar

 Ketidakpastian mengakibatkan perubahan terus

menurus pada proyek

 Interoperabilitas merupakan ciri dari sistem dan

menyesuaikan dengan batasan sistem
 Prosedure interpersonal, formal aktifitas jaminan kualitas yang
diterapkan kepada produk kerja RPL (status pengkajian ,
perancangan & inpeksi kode)

 Prosedure interpersonal, informal pertemuan kelompok untuk

menyebarkan informasi & pemecahan masalah serta
pengembangan staf

 Komunikasi teknik, surat elektronis, web sites, teleconferens,

papan buletin elektronik

 Jaringan interpersonal diskusi informal pada orang diluar

proyek untuk mendapatkan pengalaman sehinnga
mendukung kerja proyek
 Analisis yang mendetail mengenai
kebutuhan PL akan memberikan
informasi untuk menghitung perkiraan
kuantitatif & perencanaan organisasi.
Ruang lingkup masalah dibatasi dengan :

 Konteks
› PL yang dibangun memenuhi sistem, produk / konteks bisnis
yang lebih besar serta batasan yang menentukan hasilnya

 Tujuan informasi
› Objek pelanggan yang dihasilkan sbg output dari PL yang
dapat digunakan sebagai input

 Fungsi & unjuk kerja

› PL digunakan untuk mentransformasikan input menjadi output
Dekomposisi Masalah / pembagian masalah
diterapkan pada :
 Fungsionalitas yang disampaikan
 Proses yang dipakai
 Proses PL memberikan suatu kerangka kerja
dimana rencana komprehensip bagi
pengembangan PL yang dapat dibangun dengan
› Sejumlah kumpulan tugas yang berbeda, kemampuan
penyampaian & jaminan kualitas
› Aktifitas pelindung, jaminan kualitas PL, manajemen
konfigurasi PL & pengukuran
1. Sekunsial Linier
› Classic Life Cycle / model air terjun

2. Prototipe
› Perencanaan kilat untuk konstruksi oleh prototype

3. Rapid Aplication Development (RAD)

› Model sekunsial linier yang menekankan siklus
pengembangan yang sangat pendek dengan pendekatan
konstruksi berbasis komponen

4. Inkremental (Pertambahan)
› Menggabungkan elemen-elemen model sekunsial linier
dengan filosopi prototype iterative khusus untuk staffing
5. Spiral
› Merangkai sifat iterative dari prototype dengan cara kontrol &
aspek sistematis dari sekunsial linier

6. Rakitan Komponen
› Paradigma orientrasi obyek menekankan kreasi kelas yang
mengenkapsulasi data & algoritma yang dipakai untuk
memanipulasi data (gabungan dengan karakter spiral)

8. Perkembangan Komponen
› Sering dipakai untuk mengembangkan aplikasi client server
› Aktifitas dibagi menjadi :
 - dimensi sistem : desain, assembly & pemakai
 - dimensi komponen : desain & realisasi
8. Metode Formal
› Mengkhususkan, mengembangkan, & menverifikasi sistem
berbasis komputer dengan notasi matematis yang tepat
(Clean room RPL)

9. Teknik Generasi Keempat

› Serangkaian alat bantu PL yang secara otomatis
memunculkan kode sumber yang berdasarkan pada
spesifikasi perekayasaan
 1,2 3 (konvensional) sisanya evolusioner
 Harus ditentukan model paling banyak memawakili
pelanggan,karakteristik produk & lingkungan proyek
 Komunikasi pelanggan
 Perencanaan
 Analisa Resiko
 Rekayasa
 Konstruksi dan rilis
 Evaluasi Pelanggan
 Bila batasan waktu yang ketat diberikan dan masalah dapat
dipecah-pecah, model RAD mungkin pilihan yang paling
tepat.
 Tugas kerja yang actual bervariasi sehingga dekomposi
proses dimulai pada saat bagaimana menyesesaikan kerja
proses secara umum.
 Profesional industri sering mengacu pada aturan 90-90 yaitu
pada saat mendiskusikan proyek PL yang sukar maka 90 % dr
sistem yang pertama menyerap 90 % dari usaha & waktu
yang diberikan.
 10 %terakhir mengambil 90 % lain dari usaha & waktu yang
diberikan.
 Dari penyataan tersebut proyek mengalami kesulitan yaitu
1. Kemajuan mengalami kecacatan
2. Tidak ada cara untuk mengkalibrasi kemajuan karena tidak
memperoleh matrik kuantitatif
3. Rencana proyek belum dirancang untuk menakomodasi
sumber daya yang diperlukan pada akhir sebuah proyek
4. Resiko-resiko belum mempertimbangkan secara eksplisit
serta belum dibuat rencana untuk mengurangi, mengatur &
memonitor
5. Jadual yang ada tidak realistis & cacat
 Untuk mengatasi masalah tersebut maka diperlukan waktu
pada awal proyek untuk membangun rencana yang realistis
guna memonitor rencana proyek selama berjalan & pada
keseluruhan proyek serta mengontrol kualitas serta
perubahannya.
 Memfokuskan pada aktifitas pengembangan
software sesuai dengan jadwal penyelesaian dan
organisasi pengembangan software
 Manajemen projek dibutuhkan karena
pengembangan software memiliki kendala pada
biaya dan jadwal yang ditentukan oleh
pengembang.
 Pembuatan Proposal
 Perencanaan dan penjadwalan Projek
 Pembuatan rencana biaya projek
 Monitoring dan review projek
 Pemilihan dan evaluasi projek
 Pembuatan Laporan dan presentasi
 Penentuan Personal dalam Projek
› Dana projek terbatas untuk pembiayan staff yang tinggi
› Dimungkinkan tidak tersedianya staff yang memiliki
kemampuan sesuai dengan yang diinginkan
› Pengembangan kemampuan(skill) pegawai pada projek
software
 Menuntut kemampuan manager dalam
menentukan staff sesuai dengan standar tenaga IT
internasional
 Merupakan aktifitas manajemen projek yang membutuhkan
waktu paling lama

 Merupakan aktifitas berkelanjutan dari tahap initial hingga

pengiriman software sehingga secara regular harus
diperbaharui ketika terdapat informasi baru,

 Beberapa tipe perencanaan (rencana validasi, rencana

perubahan managemen, rencana pengembangan dan
training staff, rencana perawatan) harus pula dikembangkan
untuk mendukung perencanaan projek utama yang memiliki
kendala terhadap waktu dan biaya
 Jenis Deskripsi

Menentukan standar dan prosedur penentuan

Perencanaan Kualitas
kualitas software yang digunakan

Menentukan teknik, jadwal, dan sumber daya

Perencanaan Validasi
yang digunakan untuk validasi software

Perencanaan Perubahan Menggambarkan struktur dan prosedur

Manajemen perubahan manajemen

Memprediksi kebutuhan, biaya dan usaha

Perencanaan Perawatan
perawatan sistem

Menggambarkan bagaimana perencanaan

Perencanaan
pengembangan kemampuan dan ketrampilan
pengembangan staff
staff untuk menunjang projekS
 Mendefinisikan kendala projek
 Menentukan penilaian awal terhadap parameter projek
 Menentukan projek milestone dan pengiriman

while projek belum selesai ataupun dibatalkan loop

Menyusun jadwal projek
Initiasi aktifitas sesuai dengan jadwal
delay (untuk sementara)
review perkembangan projek
revisi parameter dan estimasi projek
apply revisi ke jadwal
negosiasikan kembali kendala projek dan pengiriman
if (terdapat masalah) then
initiasi review teknis dan kemungkinan revisi
end if
end loop
1. Pendahuluan
2. Organisasi Projek
3. Analisis Resiko
4. Kebutuhan akan sumber daya hardware dan
software
5. Work breakdown
6. Penjadwalan Projek
7. Mekanisme pemantauan dan pelaporan
 Aktifitas pada suatu pengembangan projek harus
diorganisasikan untuk menghasilkan output yang terukur bagi
manajemen dan penentuan progress
 Milestones merupakan titik akhir dari aktifitas proses
 Deliverable (pengiriman) merupakan hasil projek yang dikirim
ke pelanggan
 Pada model proses air terjun (waterfall) boleh didefnisikan
progress milestone secara langsung
 ACTIVITIES

Feasibility Requirement Prototype Design Requirement

study analysis development study specification

Feasibilty Requirement Evaluation Architectural Requirements

report definition report design specification

MILESTONES
 Membagi projek ke dalam bentuk tugas dan estiamsi waktu
serta sumber daya yang dibutuhkan untuk menyelesaikan
tugas tsb
 Pengorganisasian tugas yang bersamaan untuk membuat
jadwal yang optimum
 Meminimumkan ketergantungan tugas untuk menghindari
adanya delay yg ditimbulkan oleh suatu tugas yang
menunggu tugas lainnya selesai
 Ditentukan oleh intusi dan pengalaman manajer
 Estimate Alocate
Identify Identify Create
resourse for people to
study activity study project chart
activity activity

Activity chart
Software
&
requirement
Bar chart
 Estimasi kesulitan masalah dan berakibat pada biaya
pengembangan solusi menjadi cukup rumit
 Produktifitas tidak berbanding lurus dengan jumlah orang
yang mengerjakan tugas
 Penambahan personal pada akhir projek menyebabkan
adanya overhead komunikasi
 Segala sesuatu yang tidak diharapkan akan terjadi, sehingga
membutuhkan suatu perencanaan contingency
 Merupakan notasi grafis yang digunakan untuk
mengilustrasikan jadwal projek
 Menyatakan suatu breakdown projek ke dalam tugas-tugas.
Tugas seharusnya tidak terlalu kecil dan diestimasi waktunya
selama satu atau dua minggu
 Bagan Aktifitas menyatakan ketergantungan dan jalur kritis
 Diagram batang menyatakan jadwal yang sesuai dengan
waktu kalender.
Tugas Durasi (hari) Ketergantungan
T1 8
T2 15
T3 15 T1 (M1)
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)
 14/7/99 15 days
15 days
M1 T3
8 days T9
T1 5 days 4/8/99 25/8/99
25/7/99
T6 M4 M6
4/7/99 M3
start 20 days 7 days
15 days
T7 T11
T2

25/7/99 10 days 11/8/99 5/9/99

10 days
M2 M7 M8
T4 T5 15 days
T10 10 days
18/7/99
T12
M5
25 days
T8 Finish
19/9/99
 4/7 11/7 18/ 7 25/ 7 1/8 8/8 15/ 8 22/ 8 29/ 8 5/9 12/ 9 19/ 9
St art
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Finis h
 4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10

Jim T7

Mary T5
 Manajemen risiko mengidentifikasikan risiko dan
menggambarkan minimisasi dampak risiko

 Suatu risiko adalah kemungkinan munculnya

dampak yang akan merugikan
› Risiko projek berdampak pada jadwal dan sumber daya
› Risiko produk berdampak pada kualitas dan unjuk kerja
software yang dikembangkan
› Risiko Bisnis berdampak pada organisasi pengembang
software
 Risiko Tipe Risiko Deskripsi
Perginya staff berpengalaman sebelum projek
Pindahnya Staff Projek
selesai
Perubahan Berubahnya manajemen maka berubah pula
Projek
Manajemen prioritas program
Hardware yang tidak Harware penting tidak dapat dikirim sesuai dengan
Projek
tersedia waktu yang sudah ditentukan
Perubahan Projek dan Munculnya perubahan kebutuhan yang lebih besar
Kebutuhan Produk dibandingkan antisipasinya
Delay terhadap Projek dan Spesifikasi pada interface penting tidak dapat
spesifikasi Produk disediakan tepat waktu
Estimasi ukuran yang Projek dan
Estimasi ukuran sistem yang terlalu rendah
rendah Produk
Unjuk kerja
Tool (CASE) yang digunakan tidak menunjukkan
tool/sumber daya Produk
performa yg baik dalam mengantisipasi masalah
yang rendah
Adanya perubahan teknologi dalam implementasi
Perubahan Teknologi Bisnis
software
Produk saingan sudah dipasarkan sebelum software
Produk saingan Bisnis
yang dikembangkan selesai
 Identifikasi Risiko
› Identifikasi risiko projek, produk dan bisnis
 Analisis Risiko
› Menilai konsekuensi dan likelihood risiko
 Perencanaan Risiko
› Menggambarkan perencanaan untuk menghindari dan
meminimisasi dampak risiko
 Memantau Risiko
 Memantau risiko selama projek pengembangan
 Risk Risk
Risk analysis Risk planning
identification monitoring

Risk
List of Prioritised risk avoidence & Risk
potential risks list contingency assessment
plans
 Risiko Teknologi
 Risiko Personal
 Risiko Organisasi
 Estimasi Risiko
 Jenis Risiko Kemungkinan Risiko
Kecepatan Database-Engine yang digunakan tidak dapat melakukan proses
transaksi sebanyak yang dinginkan,
Teknologi Terdapat kerusakan pada komponen software yg digunakan sehingga tidak
sesuai dengan fungsinya

Tidak dimungkinkannya melakukan recruitment staff yang memiliki kemampuan

Personal sesuai dengan yang diingikan
Tidak tersedianya tempat training untuk staff yang dibutuhkan

Organisasi direstrukturisasi sehingga manajemen yg berbeda bertanggung

Organisasi jawab ke projek
Masalah dalam keuangan organisasi mengakibatkan menurunkan biaya-biaya

Code yang dibangkitkan oleh Tool tidak efisien

Tools CASE tool tidak dapat diintegrasikan

Kebutuhan- Perubahan kebutuhan mengakibatkan perancangan ulang

kebutuhan Tidak pahamnya pelanggan terhadap dampak perubahan kebutuhan

Perkiraan jumlah waktu yang diperlukan untuk menyelesaikan projek terlalu

rendah
Estimasi Perkiraan jumlah perbaikan kerusakan terlalu rendah
Perkiraan ukuran sistem software terlalu rendah
 Menilai kemungkinan terjadinya risiko dan dampak
risiko
 Kemungkinan risiko: sangat rendah, rendah,
sedang, tinggi, dan sangat tinggi
 Dampak risiko: fatal, serius, dapat ditolerir, tidak
signifikan
 Risiko Kemungkinan Dampak
Masalah dalam keuangan organisasi mengakibatkan
Rendah Fatal
menurunkan biaya-biaya.

Tidak dimungkinkannya melakukan recruitment staff yang

Tinggi Fatal
memiliki kemampuan sesuai dengan yang diingikan
Staff penting sakit pada saat jalur kritis Sedang Serius
Terdapat kerusakan pada komponen software yg
Sedang Serius
digunakan sehingga tidak sesuai dengan fungsinya

Perubahan kebutuhan mengakibatkan perancangan

Sedang Serius
ulang

Organisasi direstrukturisasi sehingga manajemen yg

High Serius
berbeda bertanggung jawab ke projek

Kecepatan Database-Engine yang digunakan tidak dapat

Sedang Serius
melakukan proses transaksi sebanyak yang dinginkan

Perkiraan jumlah waktu yang diperlukan untuk

Tinggi Serius
menyelesaikan projek terlalu rendah
CASE tool tidak dapat diintegrasikan Tinggi Dapat ditolerir
Tidak pahamnya pelanggan terhadap dampak
Sedang Dapat ditolerir
perubahan kebutuhan

Tidak tersedianya tempat training untuk staff yang

Sedang Dapat ditolerir
dibutuhkan
Perkiraan jumlah perbaikan kerusakan terlalu rendah Sedang Dapat ditolerir
Perkiraan ukuran sistem software terlalu rendah High Dapat ditolerir
Code yang dibangkitkan oleh Tool tidak efisien Sedang Tidak Signifikan
 Mempertimbangkan setiap risiko dan mengembangkan
strategi untuk mengatur risiko tersebut
 Strategi penghindaran
› Kemungkinan risiko muncul dikurangi
 Strategi minimisasi
› Dampak risiko pada projek ataupun produk harus dikurangi
 Perencanaan Contigency
› Jika terjadi risiko, rencana contingency dilakukan untuk
antisipasi risiko
Risiko Strategi
Membuat suatu dokumen singkat yang diajukan ke manajer senior untuk
Masalah Keuangan
menggambarkan bahwa pentingnya projek terhadap kemajuan bisnis
Organisasi organisasi

Memberitahukan ke pelanggan bahwa sulitnya memperoleh sumber daya

Masalah Recruitment sehingga dimungkinkan terjadinya penundaan

Mengorganisasikan pekerjaan sehingga yang menangani setiap tugas terdiri

Staff yg sakit dari lebih dari satu orang ataupun bagian lainnya dapat memahmi proses
bagian lain
Mengganti komponen yg rusak dengan yg tersedia di pasaran yg sudah
Rusaknya komponen diketahui kehandalannya.
Mengatur informasi yang dapat ditelusuri untuk menilai dapak perubahan
Perubahan Kebutuhan kebutuhan,
Membuat suatu dokumen singkat yang diajukan ke manajer senior untuk
Restrukturisasi
menggambarkan bahwa pentingnya projek terhadap kemajuan bisnis
Organisasi organisasi

Unjuk Kerja Database Melihat kemungkinan pembelian database yang memiliki untuk kerja tinggi

Rendahnya perkiraan
Menggunakan program generator ataupun pembelian komponen-komponen
waktu pengembangan
 Menilai setiap risiko yang teridentifikasi secara
regular untuk memutuskan apakah kemungkinan
munculnya risiko tersebut akan lebih
banyak/sedikit
 Menilai apakah dampak risiko tersebut sudah
berubah
 Setiap risiko harus didiskusikan pada pertemuan
manajemen progress
Tipe Risiko Indikator Potensial

Pengiriman produk hardware/software yang

Teknologi
terlambat karena adanya masalah teknologi

Rendahnya moral staff, kurangnya team work, dan

Personal
ketersediaan pekerjaan

Gossip di organisasi, kurangnya aksi dari senior

Organisasi
manajemen, reward & punishment

Adanya komentar kerusakan CASE tool, butuhnya

Tools
spesifikasi komputer yang tinggi,

Kebutuhan Complaints dr pelanggan, berubahnya kebutuhan

Tidak adanya kesesuaian terhadap jadwal, tidak

Estimasi
adanya laporan yang jelas terhadap kerusakan.
 T3

START M1
M4

T1
T7 T9 M6

M3 T11
T2
T6

M7 M8
T10
M2
T5
T4

T12
M5
T8

FINISH