3.1 SPEKTRUM MANAJEMEN
Manajemen proyek Perangkat Lunak
(PL) yang efektif berfokus pada 3 P, dimana harus berurut yaitu
PEOPLE
|
:
|
Elemen terpenting dari suksesnya proyek
|
PRODUCT / PROBLEM
|
:
|
Software yang dikembangkan
|
PROCESS
|
:
|
Suatu kerangka kerja dari suatu aktifitas
dan kumpulan tugas untuk memgembangkan PL
|
PROJECT
(tambahan)
|
:
|
Penggabungan semua kerja untuk membuat
produk menjadi kenyataan
|
3.2
PEOPLE ( MANUSIA)
SEI telah mengembangkan suatu model kematangan
kemampuan manajemen manusia (People Management Capability Manurity Model
( PM – CMM ) ) untuk mempertinggi kesiapan organisasi PL dalam membuat
aplikasi yang semakin kompleks sehingga menarik, menumbuhkan, memotivasi,
menyebarkan dan memelihara bakat yang dibutuhkan untuk mengembangkan kemapuan
mengembankan PL mereka.
Model kematangan manajemen manusia membatasi pada
Rekruitmen
Seleksi
Manajemen
unjuk kerja
Pelatihan
|
Kompensasi
Pemgembangan karir
Desain kerja & organisasi
Perkembangan karir tim / kultur
|
Manusia dalam pengembangan PL terdiri dari :
a.
Player
(Pemain)
-
Manajer Senior menentukan isu bisnis
yang mempengaruhi dalam proyek
-
Manajer Proyek merencanakan,
memotivasi, mengorga-nisir,mengontrol aplikasi/produk
-
Pelaksana mempunyai
ketrampilan teknik untuk merekayasa aplikasi
-
Pelanggan menentukan jenis
kebutuhan bagi PL yang akan dibuat
-
Pemakai akhir yang berinteraksi
dengan PL yang dibuat
b. Team
Leader (Pimpinana Tim)
Manajemen proyek merupakan
kegiatan manusia intensif sehingga memerlukan praktisi yang cakap.
Model Kepemimpinan (MOI yaitu Motivasi,
Organisasi,
gagasan & Inovasi) menurut Jerry
Weinberg.
Karakteristik yang menentukan
manajer proyek efektif yaitu
-
Pemecahan
Masalah - Prestasi
-
Identitas
manajerial - Pengaruh & pembentukan
tim
c. The
Software Team ( Tim PL)
Sumber daya manusia kepada sebuah
proyek yang akan membutuhkan n
manusia yang bekerja selama k tahun ,
ada beberapa alternatif untuk menentukan sumber daya tersebut :
-
n orang
mengerjakan tugas fungsional berbeda sebanyak m dengan sedikit kombinasi kerja
& koordinasi tanggung jawab manajer proyek
-
n orang
mengerjakan tugas fungsional berbeda sebanyak m (m<n) , seorang pemimpin tim
ad
hoc dapat dipilih, koordinasi bertanggung jawab manajer PL
-
n orang
diatur di dalam tim , setiap orang mengerjakan >= 1 tugas fungsional, setiap
tim mempunyai sebuah struktur spesifik yang ditentukan untuk semua tim yang
bekerja pada sebuah proyek, koordinasi dikontrol oleh tim itu sendiri dan oleh
manajer proyek PL ( sistem ini paling
produktif)
Mantei, mengusulkan 3 organisasi tim yaitu:
§
Demokrasi terdesentralisasi (DD)
Tidak
memiliki pimpinan permanen dan koordinator dipilih untuk tugas pendek
bila tugas berbeda maka pimpinan berbeda. Keputusan diambil oleh konsensus
kelompok dan komunikasi secara horizontal
§
Terkontrol terdesentralisasi (CD)
Tim
memiliki pimpinan tertentu dan memiliki pimpinan skunder untuk sub-sub masalah.
Pemecahan masalah merupakan aktifitas dari kelompok dan implentasi
pemecahan pada sub-sub kelompok. Komunikasi antar kelompok dan orang
bersifat horizontal tetapi komunikasi secara vertical berjalan bila
hirarki kontrol berjalan .
§
Terkontrol tersentralisasi (CC)
Pemecahan tingkat puncak dan
internal tim oleh pimpinan tim. Komunikasi dilakukan secara vertical.
7 faktor proyek yang harus dipertimbangkan dalam
rencanakan tim RPL yaitu :
1.
Kesulitan
pada masalah
2.
Ukuran
program yang dihasilkan (LOC / function)
3.
Waktu
tim (umur)
4.
Tingkat
dimana dapat dimodularitasi
5.
Kualitas
serta keandalan
6.
Kepastian
tanggal penyampaian
7.
Tingkat
sosiabilitas / komunikasi
Pengaruh Karakteristik Proyek pada Struktur Tim
Tipe Tim
|
DD
|
CD
|
CC
|
Tingkat Kesulitan
|
|
|
|
o
Tinggi
|
x
|
|
|
o
Rendah
|
|
x
|
x
|
Ukuran
|
|
|
|
o
Besar
|
|
x
|
x
|
o
Kecil
|
x
|
|
|
Umur Tim
|
|
|
|
o
Singkat
|
|
x
|
x
|
o
Panjang
|
x
|
|
|
Modularitas
|
|
|
|
o
Tinggi
|
|
x
|
x
|
o
Rendah
|
x
|
|
|
Keandalan
|
|
|
|
o
Tinggi
|
x
|
x
|
|
o
Rendah
|
|
|
x
|
Tanggal Pengiriman
|
|
|
|
o
Ketat/pasti
|
|
|
x
|
o
Longgar
|
x
|
x
|
|
Sosiabilitas
|
|
|
|
o
Tinggi
|
x
|
|
|
o
Rendah
|
|
x
|
x
|
Constantine, mengusulkan 4 paradigma organisasional bagi tim RPL
1.
Paradigma
Tertutup
Membentuk hirarki otoritas tradisional
( mirip tim CC) tetapi kurang inovatif
2.
Paradigma
Random
Membentuk tim longgar &
tergantung pada inisiatif individual tim, untuk inovasi sangat baik(unggul)
bila unjuk kerja tim teratur.
3.
Paradigma
Terbuka
Membentuk tim dengan cara
tertentu sehingga banyak kontrol, inovasi banyak . Cocok untuk masalah yang
kompleks tetapi tidak seefesien tim lainnya
4.
Paradigma
Sinkron
Mengorganisasikan tim untuk
bekerja pada bagian-bagian kecil masalah dengan komunikasi aktif pada tim
d.
Coordinatian
& Communication Issue (masalah koordinasi & komunikasi)
Proyek PL mengalami kesulitan
dikarenakan :
ü
Skala
usaha pengembangan yang besar sehingga kesulitan dalam mengkoordinasi anggota
tim & Kompleksitas yang semakin besar
ü
Ketidakpastian mengakibatkan perubahan terus menurus pada proyek
ü
Interoperabilitas merupakan ciri dari sistem dan menyesuaikan dengan batasan
sistem
Kraul
& Streeter menguji sekumpulan teknik
koordinasi proyek yang dibagi atas
ü
Pendekatan impersonal, formal penyampaian & dokumen RPL (memo, laporan dll)
ü
Prosedure interpersonal, formal aktifitas jaminan kualitas yang diterapkan kepada
produk kerja RPL (status pengkajian , perancangan & inpeksi kode)
ü
Prosedure interpersonal, informal pertemuan kelompok untuk menyebarkan informasi
& pemecahan masalah serta pengembangan staf
ü
Komunikasi teknik, surat elektronis, web sites, teleconferens, papan buletin
elektronik
ü
Jaringan interpersonal diskusi informal pada orang diluar proyek untuk
mendapatkan pengalaman sehinnga mendukung kerja proyek
3.3
PROBLEM / PRODUCT
Analisis yang mendetail mengenai kebutuhan PL akan
memberikan informasi untuk menghitung perkiraan kuantitatif & perencanaan
organisasi. Tetapi itu sulit karena informasi yang diberikan customer tidak
lengkap.
Ruang lingkup masalah dibatasi dengan :
-
Konteks
PL yang dibangun memenuhi sistem,
produk / konteks bisnis yang lebih besar serta batasan yang menentukan hasilnya
-
Tujuan
informasi
Objek pelanggan yang dihasilkan
sbg output dr PL yang dapat digunakan
sebagai input
-
Fungsi
& unjuk kerja
PL digunakan untuk mentransformasikan
input menjadi output
Pernyataan ruang lingkup dibatasi (data jumlah
pemakai simultan, ukuran pengiriman, waktu mak respon ), batasan /& jangka
waktu dicatat (biaya produk membatasi jumlah memori) & factor mitigasi
(algoritma yang dibutuhkan software aplikasi (pemograman))
Dekomposisi
Masalah / pembagian masalah
diterapkan pada :
-
Fungsionalitas
yang disampaikan
-
Proses
yang dipakai
3.4
PROCESS
Proses PL memberikan suatu kerangka kerja
dimana rencana komprehensip bagi pengembangan PL yang dapat dibangun dengan
-
Sejumlah
kumpulan tugas yang berbeda, kemampuan penyampaian & jaminan kualitas
-
Aktifitas
pelindung, jaminan kualitas PL, manajemen konfigurasi PL & pengukuran
Model
PROSES :
1. Sekunsial Linier
Classic Life Cycle / model air terjun
2.
Prototipe
Perencanaan
kilat untuk konstruksi oleh prototype
3.
Rapid Aplication
Development (RAD)
Model
sekunsial linier yang menekankan siklus pengembangan yang sangat pendek dengan
pendekatan konstruksi berbasis komponen
4.
Inkremental
(Pertambahan)
Menggabungkan
elemen-elemen model sekunsial linier dengan filosopi prototype iterative khusus untuk staffing
5.
Spiral
Merangkai
sifat iterative dari prototype dengan
cara kontrol & aspek sistematis dari sekunsial linier
6.
Rakitan Komponen
Paradigma
orientrasi obyek menekankan kreasi kelas yang mengenkapsulasi data &
algoritma yang dipakai untuk memanipulasi data (gabungan dengan karakter
spiral)
7.
Perkembangan Komponen
Sering
dipakai untuk mengembangkan aplikasi client
server
Aktifitas
dibagi menjadi :
-
dimensi sistem : desain,
assembly & pemakai
-
dimensi komponen :
desain & realisasi
8.
Metode Formal
Mengkhususkan,
mengembangkan, & menverifikasi sistem berbasis komputer dengan notasi
matematis yang tepat (Clean room RPL)
9.
Teknik Generasi Keempat
Serangkaian
alat bantu PL yang secara otomatis memunculkan kode sumber yang berdasarkan
pada spesifikasi perekayasaan
1,2
3 (konvensional) sisanya evolusioner
Harus
ditentukan model paling banyak memawakili pelanggan, karakteristik produk &
lingkungan proyek
Serangkaian aktifitas kerja PL :
1. Komunikasi
pelanggan
2. Perencanaan
3. Analisa
Resiko
4. Rekayasa
5. Konstruksi
dan rilis
6. Evaluasi
Pelanggan
Dekomposisi
Proses
Bila batasan waktu yang ketat diberikan dan
masalah dapat dipecah-pecah, model RAD mungkin pilihan yang paling tepat.
Tugas kerja yang actual bervariasi sehingga
dekomposi proses dimulai pada saat bagaimana menyesesaikan kerja proses secara
umum.
3.5
PROYEK
Profesional industri sering mengacu pada aturan
90-90 yaitu pada saat mendiskusikan proyek PL yang sukar maka 90 % dr sistem yang
pertama menyerap 90 % dari usaha & waktu yang diberikan. 10 %terakhir
mengambil 90 % lain dari usaha & waktu yang diberikan.
Dr penyataan tersebut proyek mengalami kesulitan
yaitu
1.
Kemajuan
mengalami kecacatan
2.
Tidak
ada cara untuk mengkalibrasi kemajuan karena tidak memperoleh matrik
kuantitatif
3.
Rencana
proyek belum dirancang untuk menakomodasi sumber daya yang diperlukan pada
akhir sebuah proyek
4.
Resiko-resiko
belum mempertimbangkan secara eksplisit serta belum dibuat rencana untuk
mengurangi, mengatur & memonitor
5.
Jadual
yang ada tidak realistis & cacat
Untuk mengatasi masalah tersebut maka diperlukan
waktu pada awal proyek untuk membangun rencana yang realistis guna memonitor
rencana proyek selama berjalan & pada keseluruhan proyek serta mengontrol
kualitas serta perubahannya.
Tidak ada komentar:
Posting Komentar