PENYUSUNAN MANAJEMEN PROYEK PERANGKAT LUNAK

Manajemen/pengelolaan proyek (selanjutnya ditulis manajemen proyek saja) adalah suatu

disiplin ilmu pada era tahun 1950-an, Amerika bangsa yang pertama kali menggunakan ilmu
manajemen proyek. Henry Gantt dapat dikatakan bapak dari ilmu manajemen proyek, dan
namanya pun menjadi metode yang digunakan, bernama Gantt Chart. Perlu diingat bahwa
mempelajari Manajemen Proyek itu tidak terlalu sulit, karena didalamnya terdapat hal-hal yang
terbiasa dilakukan oleh manusia, hanya ditambahkan sedikit logika dan aturan yang khusus.
Sedangkan Proyek itu usaha yang harus dilakukan dari awal hingga akhir pada suatu kejadian,
yang mempunyai batasan waktu anggaran sumber daya yang dibutuhi oleh pelanggan. Meski
pada akhir tujuan dari adanya proyek adalah untuk memuaskan pelanggan.
Dalam Penyusunan Manajeman Proyek Perangkat Lunak Meliputi:
1. Perencanaan
2. Analisis
3. Perancangan
4. Implementasi
5. Testing
6. Pemeliharaan
Penjabaran dalam Penyusunan Manajemen Proyek Perangkat Lunak itu sendiri adalah:
1. PERENCANAAN
Proses manajemen proyek perangkat lunak dimulai dengan beberapa aktivitas yang
secara kolektif disebut dengan project planning (perencanaan proyek). Aktivitas ini
dimulai dengan estimasi, yang merupakan gambaran dimana kita melihat masa depan
serta menerima tingkat ketidakpastian sebagai bahan pembicaraan. Perencanaan proyek
memberikan sebuah peta jalan bagi suksesnya rekayasa perangkat lunak.
OBSERVASI PADA ESTIMASI
Estimasi yang diperlukan dalam perancangan proyek perangkat lunak di antaranya adalah
sumber daya, biaya, dan jadwal sebagai usaha dalam pengembangan perangkat lunak,
mengakses informasi historis yang baik, dan keberanian untuk melakukan pengukuran
kuantitatif bila hanya data kualitatif saja yang ada. Berikut adalah yang menimbulkan
ketidakpastian dalam estimasi :
Project complexity (kompleksitas proyek) berpengaruh kuat terhadap ketidak
pastian yang inheren dalam perencanaan. Komplekitas ini merupakan pengukuran
relatif yang dipengaruhi oleh kebiasaan dengan usaha yang dilakukan sebelumnya.
Project size (Ukuran proyek) Merupakan faktor penting yang dapat mempengaruhi
akurasi estimasi. Bila ukuran bertambah maka ketergantungan di antara berbagai
elemen perangkat lunak akan meningkat dengan cepat.
Structural uncertainty (Ketidakpastian struktural) Tingkat ketidakpastian strutural
juga berpengaruh dalam risiko estimasi. Dengan melihat kembali, kita dapat
mengingat lagi hal-hal yang terjadi dan dapat menghindari tempat-tempat dimana
masalah muncul.
Risiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang dibuat untuk
sumber daya, biaya, dan jadwal.Bila ruang lingkup proyek atau syarat proyek tidak
dipahami dengan baik, maka risiko dan ketidakpastian menjadi sangat tinggi.
Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface(yang
diisikan ke dalam spesifikasi sistem). Pendekatan-pendekatan rekayasa perangkat lunak
modern (seperti model proses evolusioner) memakai pandangan pengembangan yang
interaktif. Dengan pandangan semacam ini dimungkinkan untuk melihat estimasi dan
merevisinya bila customer mengubah kebutuhannya.

TUJUAN PERENCANAAN PROYEK
Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah kerangka
kerja yang memungkinkan manajer membuat estimasi yang dapat ipertanggungjawabkan
mengenai sumber daya, biaya dan jadwal. Tujuan perencanaan dicapai melalui suatu
proses penemuan informasi yang menunjuk ke estimasi yang dapat
dipertanggungjawabkan.
2. ANALISIS
Tahap kedua, adalah tahap analisis, yaitu tahap dimana kita berusaha mengenali setiap
permasalahan yang muncul pada pengguna dengan mendekomposisi use case diagram
lebih lanjut, mengenali komponen-komponen sistem, objek-objek, hubungan antar objek,
dan sebagainya. Analisis analis itu disusun sebagai berikut:
Analisis resiko merupakan serangkaian langkah untuk menyiasati resiko
Analisis resiko sangat penting dalam manajemen proyek perangkat lunak.
Beberapa hal yang
harus diperhatikan berkaitan dengan resiko adalah: Masa yang akan datang,
Perubahan, Pilihan.
Menyiasati Resiko
Pengendalian Resiko
3. PERANCANGAN
Tahap ketiga adalah tahap perancangan dimana kita mencoba mencari solusi
permasalahan yang didapat dari tahap analisis
Masalah perangkat lunak (software engineering) biasanya dipilih berdasarkan 3 aspek
antara lain sifat dari proyek dan aplikasi, metode dan alat bantu yang digunakan serta
kontrol dan output yang dibutuhkan. Perekayasaan perangkat lunak berupa penggunaan
metode pengembangan perangkat lunak berkualitas tinggi secara ekonomi dan handal.
Dari usaha-usaha tersebut dihasilkan alternatif paradigma, alternatif metodologi dan
perangkat bantu komputer.
1. Siklus Hidup
Pengesetan dan piranti teknik serta metode yang digunakan oleh para ahli software
dalam proyek disebut Metodologi Proyek. Metodologi proyek diterapkan dalam
konteks tahap-tahap pengembangan software (software live cycle) , yang disebut fase,
yang merupakan tahapan yang harus dilalui oleh produk software dari konsep awal
sampai tahap akhir. Model tahap-tahap tersebt merupakan enyajian dari tahap-tahap
pengembangan software yang juga dapat berisikan alur informasi, saat penentuan
keputusan, dan sebagainya.
Langkah-langkah dari model tahapan penyusunan dapat merupakan fase temoporal
yang membentuk urutan dalam waktu atau fase logis yang menunjukkan tahap-tahap
bukan membentuk urutan temporal. Sebagai contoh implementasi secara logis akan
mendahului pengujian, namun bagian fase implementasi dan pengujian dapat terjadi
secara serempak. Jadi moedl tahapan yang menggunakan fase logis dapat memiliki
fase implementasi sebelum fase pengujian, sedangkan model yang menggunakan fase
temporal mungkin fase-fase ini kan bertumpang tindih.
2. Model Spiral
Permodelan dalam suatu perangkat lunak merupakan suatu hal yang dilakukan di
tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya maih
memungkinkan tanpa melakukan suatu permodelan. Hal ini tidak dapat lagi dilakukan
dalam suatu industri perangkat lunak. Permodelan dalam perangkat lunak merupakan
suatu yang harus ikerjakan di bagian awal dari rekayasa, dan permodelan ini akan
mempengaruhi pekerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut. dalam
prakteknya, setiap langkah sering tumpang tindih dan sering memberi informasi satu
ama lain.
Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari
aktivitas pengembangan. Selama langkah terakhir, perangkat lunak telah digunakan.
Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat
diatasi.
Namun sayang, model yang banyak mengandung iterasi sehingga membuat kesulitan
bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu,
seteleh sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan
dilanjutkan dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang
sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik
implementasi.
3. Pendekatan Waterfall
Model waterfall menawarkan cara pembuatan perangkat lunak secara lebih nyata.
Langkah-langkah yang penting dalam model ini adalah :
Penentuan dan analisis spesifikasi
Desain sistem dan perangkat lunak
Implementasi dan ujicoba unit
Integrasi dan uji coba sistem
Operasi dan pemeliharaan
Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam
langkah yang nyata atau jelas. Sistem yang disampaikan kadang-kadang tidak dapat
digunakan sesuai keinginan customer. Namun demikian model waterfall
mencerminkan kepraktisan engineering. Konsekwensinya, model proses perangkat
lunak yang bredasarkan pada pendekatan ini digunakan dalam pengembangan sistem
perangkat lunak dan hardware yang luas.
4. Pendekatan Evolusioner
Pendekatan evolusioner ini berdasarkan pada ide pengembangan dan implementasi
awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan
melalui banyak versi sampai sistem yang mencukupi dapat dikembangkan. Selain
memiliki kegiatan-kegiatan terpisah model ini memberikan umpan balik dengan cepat
dan serempak. Ada 2 tipe pada model ini yaitu :
a. Pemrogramaman evolusioner
Tujuan proses adalah bekerja sama dengan cusomer untuk menghasilakan
kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/ customer.
Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem
dikembangkan melalui penambahan features sesuai yang diusulkan oleh customer.

b. Pemodelan
Pemrograman evolusioner penting saat sulit untuk membuat spesifikasi sistem
secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam
tipe ini. Namun, pemrograman evolusioner banayk digunakan dalam
pengembangan sistem pakar (artifacial intelegence) yang berusaha untuk
menyamai kemampuan manusia.
Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang
menyamai manusia karena kita tidak mengerti bagaimana biasanya manusia
menjalankan tugas-tugasnya. Pendekatan evolusioner biasanya lebih efektif
daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang
harus dengan segera dapat memenuhi kebutuhan customer. Namun, daris egi
teknik dan manajemen, model ini mempunyai masalah mendasar yaitu :
proses tidak visibel
sistem biasanya kurang terstruktur
ketrampilan khusus jarang dimiliki
Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari
pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini
digunakan untuk mengerti dan memvalidasikan spesifikasi sistem. Disinilah
pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih
luas (seperti model waterfall).
Oleh karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak
dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk
pengembangan yang relatif kecil. Masalah-masalah mengenai perubahan sistem
yang ada dihindari dengan mengimplementasikan ulang sistem keseluruhan
kapanpun perubahan yang signifikan diperlukan. Jika permodelan digunakan,
tidak terlalu mahal. Pengembangan sistem yang memiliki masa hidup yang relatif
singkat.
5. Spiral Boehm
Boehm (1988) mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa
resiko yang disadari mungkin membentuk dasar model umum. Model yang diusulkan
oleh Boehm ini berbentuk spiral. Tak ada tahap yang ditetapkan dalam model ini.
Manajemen harus memutuskan bagaimana membentuk proyek ke dalam tahap-tahap.
Perusahaan biasanya bekerja dengan beberapa model umum dengan tambahan untuk
proyek khusus atau ketika masalah-masalah ditemukan selama pembuatan proyek.
Setiap loop dibagi dalam 4 sektor yaitu :
Pembuatan tujuan
Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek yang
ditentukan. Rencana rinci manajemen juga ditulis lengkap. Pembuatan strategi-
strategi alternatif direncanakan sesuai dengan resiko yang ada.
Perkiraan dan pengurangan resiko
Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya.
Kemudian diambil langkah-langkah untuk mengurangi resiko. Contohnya jika ada
resiko bahwa persayaratan-persyaratan tidak tepat maka sebuah model mungkin
dapat dikembangkan.
Pengembangan dan validasi
Setelah evaluasi resiko, jika resiko sebuah model pengembangan untuk sistem
dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model
pengembangan yang tepat mungkin pengembangan evolusioner dengan
menggunakan contoh (prototype). Jika resiko keselamatan yang diutamakan,
model pengembangan sesuai adalah transformasi formal. Model waterfall
mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.


Perencanaan
Jika diputuskan untuk melanjutkan pada loop spiral berikutnya, maka prosyek
yang dibicarakan kembali dan rencana perlu dibuat untuk tahap selanjutnya. Tidak
perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan
dalam keseluruhan sistem perangkat lunak. Model spiral encompasses model
lainnya. Pemodelan digunakan pada salah satu spiraluntuk memecahkan masalah
kebutuhan.
Pada implementasinya, model spiral banyak digunakan , tetapi biasanya
dikombinasikan dengan model lain. Pemodelan waterfall yang sangat bagus dalam
menentukan milestones dan pemodelan spiral, yang sangat bagus dengan
menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam
kontrak-kontrak untuk perangkat lunak dewasa ini.
4. IMPLEMENTASI
Tahap keempat adalah tahap implementasi dimana kita mengimplementasikan
perancangan sistem ke situasi dunia nyata.