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) 1
4.3.4 Contoh Dekomposisi (complex project)
 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: DD CD CC

Difficulty
high x
low x x
Size
large x x
small x
Team lifetime
short x x
long x
Modularity
high x x
low x
Reliability
high x x
low x
Delivery date
strict x
lax x x
Sociability
high x
low 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): perubahan-
perubahan 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
15
 Selanjutnya dibuat matriksnya.
 communication

engineering
customer

planning

analysis
COMMON PROCESS

risk
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
***