BAB 3 - Openstorage Gunadarma

Rekayasa Perangkat Lunak
PERTEMUAN 3
KONSEP MANAJEMEN PROYEK
3.1. Spektrum Manajemen
Manajemen proyek perangkat lunak yang efektif berfokus pada tiga P : People
(manusia), problem (masalah), process (proses). Urutan ini tidak dapat berubah.
3.1.1. Manusia
Faktor manusia sangat penting sehingga Software Engineering Institute telah
mengembangkan sebuah model kematangan kemampuan manajemen manusia
(PM-CMM) ”untuk mempertinggi kesiapan organisasi perangkat lunak untuk
mengerjakan aplikasi yang semakin kompleks dengan membantu menarik,
menumbuhkan, memotivasi, menyebarkan, dan memelihara bakat yang
dibutuhkan untuk mengembangan kemampuan perkembangan perangkat lunak
mereka”
Model kematangan manajemen manusia membatasi area praktikj berikut kunci
bagi masyarakat perangkat lunak : rekruitmen, seleksi, manajemen unjuk kerja,
pelatihan, kompensasi, perkembangan karir, desain kerja dan organisasi, dan
perkembangan tim/kultur.
3.1.2. Masalah
Sebelum proyek direncanakan, obyektivitas dan ruang lingkupnya harus
ditetapkan,
pemecahan
alternatifnya
harus dipertimbangkan, teknik dan
bataspun harus didefinisikan. Tanpa informasi ini tidak mungkin melakukan
estimasi biaya yang dapat dipertanggungjawabkan (akurat); penilaian yang
efektif terhadap resiko; merinci secara realistis tugas-tugas proyek; atau jadwal
proyek yang dapat dikelola yang memberikan indikasi kemajuan yang berarti.
Lecture-Note
Hal : 1
Rekayasa Perangkat Lunak
Pengembang dan pemakai perangkat lunak harus bertemu untuk menentukan
tujuan dan ruang lingkup proyek. Di dalam banyak kasus, aktivitas ini dimulai
sebagai bagian dari proses rekayasa sistem dan berlanjut sebagai langkah
pertama dalam analisis kebutuhan perangkat lunak.
3.1.3. Proses
Proses perangkat lunak memberikan suatu kerangka kerja di mana rencana
komprehensif bagi pengembangan perangkat lunak dapat dibangun. Sejumlah
kumpulan
tugas
yang
berbeda
–
tugas-tugas
milestone,
kemampuan
penyampaian, dan jaminan kualitas – memungkinkan aktivitas kerangka kerja
disesuaikan dengan karakteristik proyek perangkat lunak serta kebutuhan tim
proyek. Akhirnya aktivitas pelindung seperti jaminan kualitas perangkat lunak,
manajemen konfigurasi perangkat lunak, dan pengukurannya – melapisi model
proses yang ada.
3.2. Manusia
Hasil dari wawancara dengan beberapa wakil president direktur menandakan
pentingnya manusia dalam proses rekayasa perangkat lunak.
3.2.1. Para Pemain
Proses perangkat lunak diisi oleh para pemain yang dapat dikategorikan ke
dalam salah satu dalam lima konstituen berikut ini :
1. Manajer Senior, yang menentukan isu-isu bisnis yang sering memiliki
pengaruh penting di dalam proyek.
2. Manajer (teknik) Proyek, yang harus merencanakan, memotivasi,
mengorganisir, dan mengontrol sebuah produk atau aplikasi.
Lecture-Note
Hal : 2
Rekayasa Perangkat Lunak
3. Pelaksana, yang menaympaikan ketrampilan teknik yang diperlukan untuk
merekayasa sebuah produk atau aplikasi.
4. Pelanggan, yang menentukan jenis kebutuhan bagi perangkat lunak yang
akan direkayasa.
5. Pemakai Akhir, yang berinteraksi dengan perangkat lunak bila perangkat
lunak telah dikeluarkan untuk digunakan.
3.2.2. Pimpinan Tim
Jerry Weinberg cenderung mengusulkan model kepemimpinan MOI :
Motivasi.
Kemampuan
untuk
memberi
dorongan
orang
teknik
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 atau aplikasi perangkat lunak yang
spesifik.
Pandangan lain tentang karakteristik seorang manajer proyek yang efektif
memberikan tekanan pada empat kata kunci :
Pemecahan masalah. Seorang manajer proyek yang efektif dapat mendiagnosis
isu-isu organisasi dan teknis yang paling relevan, yang secara sistematis
membentuk sebuah pemecahan atau dengan tepat memotivasi para pelaksana
yang lain untuk membuat pemecahan.
Identitas manajerial. Seorang manajer proyek yang baik harus bersentuhan
secara langsung dengan proyeknya. Dia harus memilki rasa percaya diri untuk
melakukan kontrol bila perlu dan membolehkan orang-orang teknik yang baik
untuk mengikuti insting mereka.
Prestasi. Untuk mengoptimasi produktivitas sebuah tim proyek, seorang manajer
harus
memiliki
Lecture-Note
inisiatif
dan
prestasi,
serta
dengan
caranya
sendiri
Hal : 3
Rekayasa Perangkat Lunak
memperlihatkan bahwa pengambilan risiko yang terkontrol tidak akan dikenai
hukuman.
Pengaruh dan pembentukan tim. Seorang manajer proyek yang efektif harus
mampu “membaca” manusia; dia harus mampu memahami sinyal verbal dan
nonverbal serta bereaksi terhadap kebutuhan-kebutuhan orang-orang yang
mengirimkan sinyal tersebut. Manajer harus dapat menguasai diri meskipun
berada pada situasi tekanan yang sangat tinggi.
3.2.3. Tim Perangkat Lunak
Mantei mengusulkan tiga organisasi tim yang umum :
Demokratis terdesentralisasi (DD). Tim rekayasa perangkat lunak ini tidak
memiliki pemimpin yang permanen. Tetapi “koordinator” dipilih untuk bertugas di
dalam durasi waktu yang pendek, yang kemudian diganti oleh yang lain yang
mungkin bertugas untuk mengkoordinasi tugas-tugas yang berbeda. Keputusan
terhadap masalah dan pendekatan yang dilakukan dibuat oleh konsensus
kelompok. Komunikasi di antara anggota tim bersifat horisontal.
Terkontrol terdesentralisasi (CD). Tim rekayasa perangkat lunak memiliki
pemimpin tertentu yang mengkoordinasi tugas-tugas khusus serta memiliki
pemimpin-pemimpin sekunder yang bertanggung jawab atas masalah sub-sub
tugas. Pemecahan masalah merupakan aktivitas dari kelompok, tetapi
implementasi dari pemecahan masalah dipecah di antara sub-sub kelompok oleh
pimpinan tim. Komunikasi antar kelompok dan orang bersifat horisontal, tetapi
komunikasi vertikal sepanjang hirarki kontrol juga terjadi di sini.
Terkontrol terdesentralisasi (CC). Koordinasi pemecahan masalah tingkat
puncak dan internal tim diatur oleh pimpinan tim. Komunikasi antara pimpinan
dan anggota tim bersifat vertikal.
Tabel 3.1. merangkum pengaruh karakteristik proyek terhadap organisasi tim.
Karena struktur tersentralisasi dapat menyelesaikan tugas dengan lebih cepat,
struktur tsb paling banyak digunakan pada penanganan masalah-masalah yang
Lecture-Note
Hal : 4
Rekayasa Perangkat Lunak
sederhana. Tim terdesentralisasi memberikan solusi yang lebih banyak dan lebih
baik daripada individual sehingga tim semacam itu memiliki kemungkinan
keberhasilan lebih banyak pada saat bekerja pada masalah yang sulit. Karena
tim CD tersentralisasi untuk penyelesaian masalah, baik struktur tim CD ataupun
CC dapat diterapkan dengan baik pada masalah-masalah yang sederhana.
Struktur DD merupakan yang terbaik untuk masalah-masalah yang sulit.
Tabel 3.1 Pengaruh karakteristik Proyek Pada Struktur Tim
Tipe tim :
DD
CD
CC
X
X
X
X
X
X
X
X
Tingkat kesulitan
Tinggi
X
Rendah
Ukuran
Besar
Kecil
X
Umur tim
Singkat
Panjang
X
Modularitas
Tinggi
Rendah
X
Keandalan
Tinggi
X
X
Rendah
X
Tanggal pengiriman
Ketat/pasti
Longgar
X
X
X
Sosiabilitas
Tinggi
Rendah
Lecture-Note
X
X
X
Hal : 5
Rekayasa Perangkat Lunak
Karena unjuk kerja dari sebuah tim berbanding terbalik dengan jumlah
komunikasi yang harus dilakukan, proyek-proyek yang sangat besar paling baik
bila diserahkan kepada tim dengan struktur CC atau CD bila kelompok-kelompok
sub dapat diakomodasi dengan baik.
Telah dibuktika bahwa struktur tim DD menghasilkan kepuasan kerja dan moral
yang tinggi sehingga baik untuk tim dengan jangka waktu hidup yang lama.
Struktur tim DD paling baik diaplikasikan pada masalah-masalah dengan
modularitas relatif rendah karena di sini dibutuhkan volume komunikasi yang
lebih tinggi. Bila modularitas tinggi dimungkinkan (dan manusia dapat melakukan
tugas-tugas mereka sendiri), struktur CC dan DD akan bekerja dengan baik.
Tim CC dan CD terbukti menghasilkan cacat yang lebih sedikit dibanding struktur
tim DD, tetapi berhubungan erat dengan aktivitas jaminan kualitas khusus yang
diaplikasikan
oleh
tim
tersebut.
Tim
yang
terdesentralisasi
biasanya
membutuhkan lebih banyak waktu untuk menyelesaikan sebuah proyek daripada
struktur yang tersentralisasi, dan pada saat yang sama merupakan pilihan yang
terbaik bila sosiabilitas yang tinggi diperlukan.
Constantine mengusulkan empat “paradigma organisasional” bagi tim rekayasa
perangkat lunak :
1. Paradigma tertutup membentuk sebuah tim di sepanjang hirarki otoritas
tradisional (sama dengan tim CC). Tim semacam ini dapat bekerja dengan
baik pada saat memproduksi perangkat lunak yang sangat mirip dengan
apa yang dilakukan sebelumnya; tetapi tim ini kurang inovatif ketika
bekerja dalam paradigma tertutup.
2. Paradigma random membentuk sebuah tim secara longgar dan
tergantung pada inisiatif individual anggota tim. Pada saat terobosan
inovasi atau teknologi dibutuhkan, tim yang mengikuti paradigma random
akan unggul. Tetapi tim semacam ini dapat berjuang keras bila “unjuk
kerja yang teratur” diperlukan.
3. Paradigma terbuka cenderung membentuk tim dengan cara tertentu
sehingga tercapai banyak kontrol yang berhubungan dengan paradigma
Lecture-Note
Hal : 6
Rekayasa Perangkat Lunak
tertutup, tetapi sekaligus juga banyak inovasi pada saat menggunakan
paradigma random. Kerja dilakukan secara kolaboratif dengan komunikasi
yang sarat serta konsensus yang didasarkan pada pengambilan
keputusan. Struktur tim paradigma terbuka sesuai bagi pemecahan
masalah-masalah yang kompleks, tetapi tidak akan bekerja seefisien tim
yang lain.
4. Paradigma sinkron bertumpu pada pemggolongan alami dari suatu
masalah serta mengorganisasi anggota tim untuk bekerja pada bagianbagian kecil masalah dengan komunikasi aktif di antara mereka sendiri.
3.2.4. Masalah Koordinasi dan Komunikasi
Kraul dan Streeter menguji sekumpulan teknik koordinasi proyek yang
dikategorikan dalam kelompok berikut :
Pendekatan impersonal, formal. Mencakup penyampaian dan dokumen
rekayasa perangkat lunak (seperti kode sumber), memo-memo teknis, kejadian
penting pada proyek, jadwal dan piranti kontrol proyek, kebutuhan akan
perubahan dan dokumentasi yang berhubungan, laporan pelacakan kesalahan
dan data cadangan.
Prosedur interpersonal, formal. Berfokus pada aktivitas jaminan kualitas yang
diterapkan kepada produk kerja rekayasa perangkat lunak. Hal ini menyangkut
pertemuan status pengkajianserta perancangan dan inspeksi kode.
Prosedur interpersonal, informal. Menyangkut pertemuan kelompok untuk
penyebaran informasi dan pemecahan masalah serta “alokasi kebutuhan dan
pengembangan staf”.
Komunikasi elektronik. Mencakup surat elektronik, papan buletin elektronik,
web sites, serta sistem konferensi berbasis video.
Jaringan interpersonal. Diskusi informal dengan orang-orang di luar proyek yang
mungkin memiliki pengalaman atau pengetahuan yang dalam yang dapat
mendukung anggota tim.
Lecture-Note
Hal : 7
Rekayasa Perangkat Lunak
3.3. Masalah
Seorang manajer proyek perangkat lunak dihadapkan pada sebuah dilema pada
awal proyek rekayasa perangkat lunak. Kebutuhan terkadang berubah-ubah,
berubah secara reguler pada saat proyek berjalan. Tetapi walau bagaimanapun
diperlukan suatu rencana, “sekarang!”
3.3.1. Ruang lingkup
Aktivitas manajemen proyek perangkat lunak yang pertama adalah menentukan
ruang lingkup perangkat lunak. Ruang lingkup dibatasi dengan menjawab
pertanyaan-pertanyaan berikut :
Konteks. Bagaimana perangkat lunak yang akan dibangun dapat memenuhi
sebuah sistem, produk, atau konteks bisnis yang lebih besar, serta batasan apa
yang ditentukan sebagai hasil dari kontek tersebut?
Tujuan informasi. Objek data pelanggan apa yang dihasilkan sebagai output
dari perangkat lunak? Objek data apa yang diperlukan sebagai input?
Fungsi dan unjuk kerja. Fungsi apa yang dilakukan oleg perangkat lunak untuk
mentransformasi input data menjadi output? Adakah ciri kerja khusus yang akan
ditekankan?
Ruang lingkup proyek perangkat lunak harus tidak ambigu dan dapat dipahami
pada tingkat teknis maupun manajemen.
3.3.2 Dekomposisi Masalah
Dekomposisi masalah sering disebut juga partitioning (pembagian), merupakan
sebuah aktivitas yang mendudukan inti dari analisis kebutuhan perangkat lunak.
Dekomposisi diterapkan pada dua area utama :
(1). Fungsionalitas yang harus disampaikan, dan
(2). Proses yang akan dipakai untuk menyampaikannya.
Lecture-Note
Hal : 8
Rekayasa Perangkat Lunak
Secara sederhana, masalah yang kompleks dibagi ke dalam sejumlah masalah
yang lebih kecil yang dapat lebih dikendalikan.
3.4. Proses
Fase-fase generik yang menandai proses perangkat lunak
– definisi,
pengembangan dan pemeliharaan – dapat diaplikasikan pada semua perangkat
lunak. Masalahnya adalah bagaimana memilih model proses yang sesuai bagi
perangkat lunak yang akan direkayasa oleh sebuah tim proyek. Berikut ini
beberapa jenis paradigma yang dapat dipergunakan dalam rekayasa perangkat
lunak :

Model sekuensial linier

Model prototipe

Model RAD

Model inkremental

Model spiral

Model asembli komponen

Model pengembangan kongkuren

Model metode formal

Model teknik generasi keempat
Manajer proyek harus memutuskan model proses mana yang paling sesuai
untuk proyek tertentu.
Perencanaan proyek dimulai dengan menggabungkan masalah dan proses.
Setiap fungsi yang akan direkayasa oleh tim perangkat lunak harus melampaui
sejumlah aktivitas kerangka kerja yang sudah ditentukan bagi sebuah organisasi
perangkat lunak. Misal organisasi sudah mengadopsi serangkaian aktivitas
kerangka kerja sebagai berikut :

Komunikasi pelanggan – tugas-tugas yang diperlukan untuk membangun
komunikasi yang efektif diantara pengembang dan pelanggan.
Lecture-Note
Hal : 9
Rekayasa Perangkat Lunak

Perencanaan – tugas-tugas yang diperlukan untuk menentukan sumbersumber daya, ketepatan waktu, dan informasi proyek yang lain.

Analisis resiko – tugas-tugas yang diperlukan untuk memperkirakan resikoresiko manajemen dan teknis.

Rekayasa – tugas-tugas yang diperlukan untuk membangun satu perwakilan
aplikasi atau lebih.

Konstruksi dan rilis – tugas-tugas yang diperlukan untuk membangun,
menguji, memasang, dan memberikan dukungan kepada pemakai (seperti
dokumentasi dan pelatihan)

Evaluasi pelanggan – tugas-tugas yang diperlukan untuk memperoleh umpan
balik dari pelanggan.
Anggota-anggota
tim
yang
bekerja
pada
masing-masing
fungsi
akan
menerapkan setiap aktivitas kerangka kerja pada fungsi.
Lecture-Note
Hal : 10