Konsep Manajemen Proyek Perangkat Lunak

4. Konsep Manajemen Proyek
Perangkat Lunak
4.1 People
4.1.1 Para Pemain (Stakeholder)
4.1.2 Pemimpin Tim
4.1.3 Tim Perangkat Lunak
4.1.4 Tiga Organisasi Tim (Mantei)
4.1.5 Faktor-faktor dalam Perencanaan Struktur Tim RPL (Mantei)
4.1.6 Pengaruh Karakteristik Proyek pada Struktur Tim
4.1.7 Masalah Koordinasi dan Komunikasi
4.1.8 Teknik Koordinasi Proyek (Kraul dan Streeter)
4.2 Problem
4.2.1 Ruang Lingkup Masalah
4.2.2 Dekomposisi Masalah
4.3 Proses
4.3.1 Menggabungkan Masalah dan Proses
4.3.2 Dekomposisi Proses
4.3.3 Contoh Dekomposisi (simple project)
4.3.4 Contoh Dekomposisi (complex project)
1
Konsep Manajemen Proyek
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
2
4.1 People
4.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.
3
4.1.2 Pemimpin Tim


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
4
spesifik.
4.1.3 Tim Perangkat Lunak

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.
5
4.1.4 Tiga Organisasi Tim (Mantei)



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
6
internal, koordinasi vertikal
4.1.5 Faktor-faktor dalam Perencanaan
Struktur Tim RPL (Mantei)







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
7
4.1.6 Pengaruh Karakteristik Proyek
pada Struktur Tim
Team type:
Difficulty
high
low
Size
large
small
Team lifetime
short
long
Modularity
high
low
Reliability
high
low
Delivery date
strict
lax
Sociability
high
low
DD
CD
CC
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
8
4.1.7 Masalah Koordinasi dan
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): perubahanperubahan yang terus-menerus.
Interoperability (interoperabilitas): perangkat
lunak yang dibuat harus dapat berkomunikasi
dengan perangkat lunak yang lain.
9
4.1.8 Teknik Koordinasi Proyek
(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.
10
4.2 Problem
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.

11
4.2.1 Ruang Lingkup Masalah

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?
12
4.2.2 Dekomposisi Masalah


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
13
4.3 Proses



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.
14
4.3.1 Menggabungkan Masalah dan
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
engineering
risk
analysis
planning
customer
communication
COMMON PROCESS
FRAMEWORK ACTIVITIES
Software Engineering Tasks
Product Functions
Text input
Editing & formatting
Automatic copy edit
Page layout capability
Automatic indexing & TOC
File management
Document production
16
4.3.2 Dekomposisi Proses

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.


17
4.3.3 Contoh Dekomposisi
(simple project)

Membuat daftar klarifikasi

Bertemu dengan customer untuk klarifikasi

Bersama-sama menentukan scope

Review scope

Penyempurnaan scope berdasarkan berbagai
kendala
18
4.3.4 Contoh Dekomposisi
(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. 19
***