Anda di halaman 1dari 18

Konsep Manajemen Proyek 1

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
1 People 2

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.
1.2 Pemimpin Tim 3

 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.
1.3 Tim Perangkat Lunak 4

 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.
1.4 Tiga Organisasi Tim (Mantei) 5

 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
1.5 Faktor-faktor dalam Perencanaan
Struktur Tim RPL (Mantei) 6

 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
1.6 Pengaruh Karakteristik Proyek 7
pada Struktur Tim
T e a m ty p e : DD CD CC
T e a m ty p e : DD CD CC
D iffic u lty
D iffic u lty
h ig h x
h ig h x
lo w x x
lo w x x
S iz e
S iz e
la r g e x x
la r g e x x
s m a ll x
s m a ll x
T e a m life tim e
T e a m life tim e
s h o rt x x
s h o rt x x
lo n g x
lo n g x
M o d u la r ity
M o d u la r ity
h ig h x x
h ig h x x
lo w x
lo w x
R e lia b ility
R e lia b ility
h ig h x x
h ig h x x
lo w x
lo w x
D e liv e r y d a te
D e liv e r y d a te
s tr ic t x
s tr ic t x
la x x x
la x x x
S o c ia b ility
S o c ia b ility
h ig h x
h ig h x
lo w x x
lo w x x
1.7 Masalah Koordinasi dan 8
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.
1.8 Teknik Koordinasi Proyek 9
(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-mail, E-BB, web sites, video conference.
 Jaringan interpersonal.
Diskusi informal dengan orang di luar proyek.
2 Problem 10

 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.
2.1 Ruang Lingkup Masalah 11

 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?
2.2 Dekomposisi Masalah 12

 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
3 Proses 13

 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.
3.1 Menggabungkan Masalah dan
14
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.
15

communication

engineering
customer

planning

analysis
CO M M O N PROCESS

risk
F R A M E W O R K A C T IV IT IE S

S o ftw a r e E n g in e e r in g T a s k s
P r o d u c t F u n c tio n s
T e x t in p u t
E d itin g & fo r m a ttin g
A u to m a t ic c o p y e d it
P a g e la y o u t c a p a b ility
A u to m a tic in d e x in g & T O C
F ile m a n a g e m e n t
D o c u m e n t p r o d u c tio n
3.2 Dekomposisi Proses 16

 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.
3.3 Contoh Dekomposisi 17
(simple project)
 Membuat daftar klarifikasi
 Bertemu dengan customer untuk klarifikasi
 Bersama-sama menentukan scope
 Review scope
 Penyempurnaan scope berdasarkan berbagai kendala
3.4 Contoh Dekomposisi 18
(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.
***