Dokumen ini membahas konsep manajemen proyek perangkat lunak yang terdiri dari tiga pilar: people, problem, dan process. Fokus utama adalah pada pengelolaan tim, dekomposisi masalah, dan proses yang digunakan dalam pengembangan perangkat lunak. Ini mencakup peran berbagai stakeholder, teknik koordinasi, dan cara mendefinisikan ruang lingkup serta menangani tantangan yang muncul dalam proyek perangkat lunak.

1. 1
1
4. Konsep Manajemen Proyek
4. Konsep Manajemen Proyek
Perangkat Lunak
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)

2. 2
2
Konsep Manajemen Proyek
Konsep Manajemen Proyek
Perangkat Lunak
Perangkat Lunak
 Manajemen Proyek Perangkat Lunak merupakan
Manajemen Proyek Perangkat Lunak merupakan
suatu aktivitas pelindung (umbrella activity) untuk
suatu aktivitas pelindung (umbrella activity) untuk
mengelola proyek perangkat lunak, yang difokuskan
mengelola proyek perangkat lunak, yang difokuskan
pada 3P: People (manusia); Problem (masalah) dan
pada 3P: People (manusia); Problem (masalah) dan
Process (proses)
Process (proses)

People
People: semua orang yang terlibat dalam proyek
: semua orang yang terlibat dalam proyek
perangkat lunak
perangkat lunak

Problem
Problem: menentukan ruang lingkup dan batasan proyek
: menentukan ruang lingkup dan batasan proyek
perangkat lunak sekaligus teknik pemecahannya.
perangkat lunak sekaligus teknik pemecahannya.

Process
Process: kerangka kerja yang komprehensif dalam
: kerangka kerja yang komprehensif dalam
pembangunan perangkat lunak
pembangunan perangkat lunak

3. 3
3
4.1 People
4.1 People
4.1.1 Para Pemain (Stakeholder)
4.1.1 Para Pemain (Stakeholder)
 Senior managers:
Senior managers: yang menentukan isu-isu bisnis yang
yang menentukan isu-isu bisnis yang
sering memiliki pengaruh penting dalam proyek.
sering memiliki pengaruh penting dalam proyek.
 Project (technical)
Project (technical) managers: yang harus merencanakan,
managers: yang harus merencanakan,
memotivasai, mengorganisasi, dan mengontrol sebuah
memotivasai, mengorganisasi, dan mengontrol sebuah
produk atau aplikasi.
produk atau aplikasi.
 Practitioners:
Practitioners: yang menyampaikan keteranpilan teknik yang
yang menyampaikan keteranpilan teknik yang
diperlukan untuk merekayasa sebuah produk atau aplikasi.
diperlukan untuk merekayasa sebuah produk atau aplikasi.
 Customers:
Customers: yang menentukan jenis kebutuhan bagi
yang menentukan jenis kebutuhan bagi
perangkat lunak yang akan direkayasa.
perangkat lunak yang akan direkayasa.
 End users:
End users: yang akan memakai perangkat lunak.
yang akan memakai perangkat lunak.

4. 4
4
4.1.2 Pemimpin Tim
4.1.2 Pemimpin Tim
 Pemimpin tim (team leaders): seseorang yang
Pemimpin tim (team leaders): seseorang yang
memimpin sebuah proyek perangkat lunak.
memimpin sebuah proyek perangkat lunak.
 Syarat : Model Kepemimpinan MOI (Weinberg):
Syarat : Model Kepemimpinan MOI (Weinberg):
 Motivasi
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
Gagasan dan Inovasi: kemampuan untuk mendorong
: kemampuan untuk mendorong
manusia untuk menciptakan dan bertindak kreatif
manusia untuk menciptakan dan bertindak kreatif
meskipun mereka bekerja di dalam suatu ikatan yang
meskipun mereka bekerja di dalam suatu ikatan yang
dibangun untuk suatu produk perangkat lunak yang
dibangun untuk suatu produk perangkat lunak yang
spesifik.
spesifik.

5. 5
5
4.1.3 Tim Perangkat Lunak
4.1.3 Tim Perangkat Lunak
 Alternatif pemanfaatan SDM pada proyek perangkat
Alternatif pemanfaatan SDM pada proyek perangkat
lunak:
lunak:
 n individu diberi m tugas fungsional yang berbeda
n individu diberi m tugas fungsional yang berbeda
(m > n),
(m > n), ada individu yang
ada individu yang merangkap
merangkap kombinasi kerja.
kombinasi kerja.
 n individu diberi m tugas yang berbeda
n individu diberi m tugas yang berbeda (m < n),
(m < n), secara
secara
tidak langsung terbentuk tim
tidak langsung terbentuk tim informal.
informal.
 n individu dibagi menjadi t tim, setiap tim mempunyai
n individu dibagi menjadi t tim, setiap tim mempunyai
tugas yang
tugas yang spesifik
spesifik.
.
 Struktur tim yang terbaik
Struktur tim yang terbaik berdasarkan gaya
berdasarkan gaya
manajemen, jumlah orang, tingkat keahlian,
manajemen, jumlah orang, tingkat keahlian,
kompleksitas masalah.
kompleksitas masalah.

6. 6
6
4.1.4 Tiga Organisasi Tim (Mantei)
4.1.4 Tiga Organisasi Tim (Mantei)

Democratic
Democratic Decentralized
Decentralized (DD); tidak ada
(DD); tidak ada
pimpinan yang tetap, keputusan diambil
pimpinan yang tetap, keputusan diambil
secara bersama-sama, hubungan horizontal.
secara bersama-sama, hubungan horizontal.

Controlled Decentralized
Controlled Decentralized (CD); ada pimpinan
(CD); ada pimpinan
untuk setiap 'task' dan sub-pimpinan untuk
untuk setiap 'task' dan sub-pimpinan untuk
'sub-task', terjadi komunikasi horizontal &
'sub-task', terjadi komunikasi horizontal &
vertikal.
vertikal.

Controlled Centralized
Controlled Centralized (CC); ada team leader
(CC); ada team leader
untuk top-level problem solving &
untuk top-level problem solving &
koordinasi internal, koordinasi vertikal
koordinasi internal, koordinasi vertikal

7. 7
7
4.1.5 Faktor-faktor dalam Perencanaan
4.1.5 Faktor-faktor dalam Perencanaan
Struktur Tim RPL (Mantei)
Struktur Tim RPL (Mantei)

Tingkat
Tingkat kesulitan
kesulitan masalah
masalah

Besarnya
Besarnya program (dalam LOC atau FP)
program (dalam LOC atau FP)

Team
Team lifetime
lifetime
 Tingkat
Tingkat modularitas
modularitas program
program
 Kualitas dan reliabilitas
Kualitas dan reliabilitas program
program

Batas
Batas waktu
waktu pengembangan
pengembangan

Tingkat
Tingkat sosialisasi
sosialisasi (sosiabilitas) proyek
(sosiabilitas) proyek

8. 8
8
4.1.6 Pengaruh Karakteristik Proyek
4.1.6 Pengaruh Karakteristik Proyek
pada Struktur Tim
pada Struktur Tim
Te am type:
D ifficulty
high
low
S ize
large
sm all
Te am lifetim e
short
long
M odularity
high
low
R eliability
high
low
D elivery date
strict
lax
S ociability
high
low
D D C D C C
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x

9. 9
9
4.1.7 Masalah Koordinasi dan
4.1.7 Masalah Koordinasi dan
Komunikasi
Komunikasi
Ada banyak hal yang menyebabkan proyek
Ada banyak hal yang menyebabkan proyek
perangkat lunak bermasalah, penyebabnya
perangkat lunak bermasalah, penyebabnya
diantaranya adalah:
diantaranya adalah:
 Scale
Scale (skala): skala proyek yang demikian besar,
(skala): skala proyek yang demikian besar,
sehingga koordinasi sulit.
sehingga koordinasi sulit.
 Uncertainty
Uncertainty (ketidakpastian): perubahan-
(ketidakpastian): perubahan-
perubahan yang terus-menerus.
perubahan yang terus-menerus.
 Interoperability
Interoperability (interoperabilitas): perangkat
(interoperabilitas): perangkat
lunak yang dibuat harus dapat berkomunikasi
lunak yang dibuat harus dapat berkomunikasi
dengan perangkat lunak yang lain.
dengan perangkat lunak yang lain.

10. 10
10
4.1.8 Teknik Koordinasi Proyek
4.1.8 Teknik Koordinasi Proyek
(Kraul dan Streeter)
(Kraul dan Streeter)
 Pendekatan impersonal, formal
Pendekatan impersonal, formal.
.
Dokumen, memo teknis, milestone proyek, schedule, error
Dokumen, memo teknis, milestone proyek, schedule, error
tracking report, dll
tracking report, dll
 Prosedur interpersonal, formal
Prosedur interpersonal, formal.
.
Difokuskan pada jaminan kualitas kegiatan, diantaranya
Difokuskan pada jaminan kualitas kegiatan, diantaranya
inspeksi desain dan kode.
inspeksi desain dan kode.
 Prosedur interpersonal, informal
Prosedur interpersonal, informal.
.
Group meeting untuk bertukar informasi dan problem
Group meeting untuk bertukar informasi dan problem
solving, requirement gathering dan pengembangan staff.
solving, requirement gathering dan pengembangan staff.
 Komunikasi elektronik
Komunikasi elektronik.
.
E-mail, E-BB, web sites, video conference.
E-mail, E-BB, web sites, video conference.
 Jaringan interpersonal
Jaringan interpersonal.
.
Diskusi informal dengan orang di luar proyek.
Diskusi informal dengan orang di luar proyek.

11. 11
11
4.2 Problem
4.2 Problem
 Manajer proyek perangkat lunak berhadapan dengan
Manajer proyek perangkat lunak berhadapan dengan
dilema awal proyek, yaitu menentukan perkiraan
dilema awal proyek, yaitu menentukan perkiraan
kuantitatif dan rencana organisasi tetapi
kuantitatif dan rencana organisasi tetapi informasi
informasi
yang akurat belum tersedia.
yang akurat belum tersedia.

Requirement analysis yang lengkap dibutuhkan
Requirement analysis yang lengkap dibutuhkan
untuk melakukan estimasi, tetapi memerlukan
untuk melakukan estimasi, tetapi memerlukan
waktu yang lama dan kadang-kadang
waktu yang lama dan kadang-kadang kebutuhan
kebutuhan
berubah-ubah pada saat proyek berjalan
berubah-ubah pada saat proyek berjalan.
.
Solusi:
Solusi: definisikan scope (ruang lingkup) dengan
definisikan scope (ruang lingkup) dengan
benar dan segera.
benar dan segera.

12. 12
12
4.2.1 Ruang Lingkup Masalah
4.2.1 Ruang Lingkup Masalah
 dibatasi oleh:
dibatasi oleh:
 Context
Context
Bagaimana perangkat lunak yang dibangun dapat
Bagaimana perangkat lunak yang dibangun dapat
memenuhi
memenuhi sebuah sistem, produk, atau konteks bisnis
sebuah sistem, produk, atau konteks bisnis
yang
yang lebih besar
lebih besar, serta apa batasan yang ditentukan
, serta apa batasan yang ditentukan
sebagai hasil dari konteks tersebut?
sebagai hasil dari konteks tersebut?
 Information Objectives
Information Objectives
Obyek data pelanggan apa yang dihasilkan sebagai
Obyek data pelanggan apa yang dihasilkan sebagai output
output
dari perangkat lunak, dan obyek data apa yang diperlukan
dari perangkat lunak, dan obyek data apa yang diperlukan
sebagai input?
sebagai input?
 Function dan performance
Function dan performance
Fungsi apa yang dilakukan oleh perangkat lunak untuk
Fungsi apa yang dilakukan oleh perangkat lunak untuk
mentransformasi
mentransformasi input data menjadi output?
input data menjadi output?

13. 13
13
4.2.2 Dekomposisi Masalah
4.2.2 Dekomposisi Masalah
 Dekomposisi masalah disebut juga
Dekomposisi masalah disebut juga
partitioning
partitioning (pembagian), merupakan
(pembagian), merupakan
aktivitas yang mendudukkan inti dari analisis
aktivitas yang mendudukkan inti dari analisis
kebutuhan perangkat lunak.
kebutuhan perangkat lunak.
 Dekomposisi dilakukan dalam 2 area:
Dekomposisi dilakukan dalam 2 area:
 Fungsionalitas
Fungsionalitas yang harus dihasilkan
yang harus dihasilkan
 Proses
Proses yang akan dipakai untuk menghasilkan
yang akan dipakai untuk menghasilkan
sesuatu
sesuatu
 Manusia cenderung melakukan dekomposisi
Manusia cenderung melakukan dekomposisi
jika menghadapi masalah yang kompleks
jika menghadapi masalah yang kompleks

14. 14
14
4.3 Proses
4.3 Proses
 Fase-fase generik dan menandai proses
Fase-fase generik dan menandai proses
perangkat lunak:
perangkat lunak: definisi, pembangunan, dan
definisi, pembangunan, dan
pemeliharaan
pemeliharaan
 Fase generik dijalankan menggunakan
Fase generik dijalankan menggunakan salah
salah
satu model
satu model rekayasa perangkat lunak.
rekayasa perangkat lunak.
 Project manager harus memilih model
Project manager harus memilih model
rekayasa yang paling tepat berdasarkan
rekayasa yang paling tepat berdasarkan
karakteristik
karakteristik masalah, tim, dan kriteria
masalah, tim, dan kriteria
proyek.
proyek.

15. 15
15
 Tahap awal project planning dimulai dengan penggabungan
Tahap awal project planning dimulai dengan penggabungan
problem dan process.
problem dan process.
 Setiap fungsi yang akan direkayasa harus melampaui
Setiap fungsi yang akan direkayasa harus melampaui
sejumlah aktivitas yang sudah ditentukan
sejumlah aktivitas yang sudah ditentukan
 Misal organisasi mengadopsi kerangka aktivitas
Misal organisasi mengadopsi kerangka aktivitas sbb:
sbb:
 Customer communication
Customer communication – membangun komunikasi yang efektif
– membangun komunikasi yang efektif
antara pengembang dan pelanggan
antara pengembang dan pelanggan
 Planning
Planning – menentukan sumber daya, ketepatan waktu, dan
– menentukan sumber daya, ketepatan waktu, dan
informasi proyek yang lain
informasi proyek yang lain
 Risk analysis
Risk analysis – menentukan resiko-resiko manajemen dan teknis
– menentukan resiko-resiko manajemen dan teknis
 Engineering
Engineering – membangun aplikasi perangkat lunak
– membangun aplikasi perangkat lunak
 Construction and release
Construction and release – membangun, menguji, menginstal, dan
– membangun, menguji, menginstal, dan
memberikan dukungan kepada pemakai (dokumen dan pelatihan)
memberikan dukungan kepada pemakai (dokumen dan pelatihan)
 Customer evaluation
Customer evaluation – umpan balik pelanggan
– umpan balik pelanggan
 Selanjutnya dibuat matriksnya.
Selanjutnya dibuat matriksnya.
4.3.1 Menggabungkan Masalah dan
4.3.1 Menggabungkan Masalah dan
Proses
Proses

16. 16
16
Software Engineering Tasks
Product Functions
Text input
Editing & formatting
Automatic copy edit
Page layout capability
Automatic indexing & TOC
File management
Document production
COMMON PROCESS
FRAMEWORK ACTIVITIES
customer
communication
planning
risk
analysis
engineering

17. 17
17
4.3.2 Dekomposisi Proses
4.3.2 Dekomposisi Proses
 Memilih paradigma
Memilih paradigma rekayasa perangkat lunak yang
rekayasa perangkat lunak yang
paling baik sesuai dengan tingkat relativitas dari
paling baik sesuai dengan tingkat relativitas dari
perangkat lunak.
perangkat lunak.
 Bila proyek relatif
Bila proyek relatif kecil dan mirip
kecil dan mirip dengan proyek
dengan proyek
sebelumnya, maka dapat dipilih pendekatan
sebelumnya, maka dapat dipilih pendekatan linier
linier
sekuensial
sekuensial
 Bila masalah dapat
Bila masalah dapat dipecah-pecah
dipecah-pecah dan
dan batasan waktu
batasan waktu
yang ketat
yang ketat, maka dapat dipilih model
, maka dapat dipilih model RAD
RAD.
.
 Bila
Bila batas waktunya ketat
batas waktunya ketat, tetapi
, tetapi fungsionalitas
fungsionalitas tidak
tidak
dapat optimal, maka dapat dipilih
dapat optimal, maka dapat dipilih strategi pertambahan
strategi pertambahan.
.
dll
dll
 Sekali model dipilih, kerangka kerja umum (
Sekali model dipilih, kerangka kerja umum (CPF=common
CPF=common
Process Framework
Process Framework) harus disesuaikan dengan model.
) harus disesuaikan dengan model.

18. 18
18
4.3.3 Contoh Dekomposisi
4.3.3 Contoh Dekomposisi
(simple project)
(simple project)

Membuat
Membuat daftar
daftar klarifikasi
klarifikasi
 Bertemu dengan customer untuk
Bertemu dengan customer untuk klarifikasi
klarifikasi

Bersama-sama
Bersama-sama menentukan scope
menentukan scope
 Review
Review scope
scope

Penyempurnaan
Penyempurnaan scope berdasarkan berbagai
scope berdasarkan berbagai
kendala
kendala

19. 19
19
4.3.4 Contoh Dekomposisi
4.3.4 Contoh Dekomposisi
(complex project)
(complex project)

Mengkaji
Mengkaji kebutuhan customer
kebutuhan customer

Merencanakan dan
Merencanakan dan menjadwal
menjadwal sebuah pertemuan formal dengan
sebuah pertemuan formal dengan
customer
customer

Melakukan
Melakukan penelitian
penelitian untuk menentukan pemecahan yang diusulkan
untuk menentukan pemecahan yang diusulkan

Mempersiapkan
Mempersiapkan dokumen kerja
dokumen kerja serta agenda untuk pertemuan formal
serta agenda untuk pertemuan formal

Mengadakan
Mengadakan pertemuan
pertemuan

Secara bersama-sama mengembangkan spesifikasi detail yang
Secara bersama-sama mengembangkan spesifikasi detail yang
merefleksikan
merefleksikan data, fungsi, dan karakteristik
data, fungsi, dan karakteristik yang berhubungan
yang berhubungan
dengan perilaku perangkat lunak
dengan perilaku perangkat lunak

Mengkaji setiap spesifikasi detail tersebut untuk upaya
Mengkaji setiap spesifikasi detail tersebut untuk upaya perbaikan,
perbaikan,
konsistensi, dan mengurangi ambiguitas
konsistensi, dan mengurangi ambiguitas

Mencantumkan spesifikasi detail ke dalam sebuah
Mencantumkan spesifikasi detail ke dalam sebuah dokumen ruang
dokumen ruang
lingkup
lingkup

Mengkaji
Mengkaji dokumen ruang lingkup dengan semua pendapat yang ada.
dokumen ruang lingkup dengan semua pendapat yang ada.

Memodifikasi
Memodifikasi dokumen ruang lingkup sesuai dengan kebutuhan.
dokumen ruang lingkup sesuai dengan kebutuhan.
***
***