Perancangan Proyek Perangkat Lunak

Proses manajemen proyek perangkat lunak dimulai dengan serangkaina aktivitas yang secara kolektif disebut project panning (Perancangan proyek). Yang pertama dari aktivitas aktivitas ini adalah estimation (perkiraan). Kapanpun estimasi dilakukan, kita mulai melihat pada masa depan serta menerima tingkat ketidak pastian sebagain bahan percakapan. Seperti yang dikatakan oleh Frederick Brooks.

Teknik estimasi kita dikembangkan dengan sangat buruk. Yang lebih parah lagi, Teknik ini mencerminkan asumsi yang tidak tersuarakan namun sangat tidak benar, yaitu bahwa semua akan berjalan dengan baik…. Karena kita tidak pasti dengan estimasi yang kita buat, maka para manajer perangkat lunak sering harus bersikap keras kepala untuk membuat orang mau menunggu sebuah produk yang baik.

Tujuan perencanaan proyek perangkat lunak :

  • menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Tujuan perencanaan dicapai melalui suatu proses penemuan informasi yang menunjuk ke estimasi yang dapat dipertanggungjawabkan.

Berikut adalah Hal yang harus diperhatikan dalam Perencanaan proyek perangkat lunak :

  1. Ruang Lingkup
  2. Sumber Daya
    – SDM (Sumber Daya Manusia)
    – Hardware dan Software
  3. Operasional biaya
  4. Total Biaya
  5. Waktu (Timeline) Pekerjaan

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 ketidakpastian 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.

Resiko 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 resiko dan ketidak pastian 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.

RUANG LINGKUP PERANGKAT LUNAK

Penentuan ruang lingkup perangkat lunak merupakan aktivitas pertama dalam perencanaan proyek perangkat lunak. Ruang lingkup perangkat lunak menggabarkan fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi yang digambarkan dalam statmen ruang lingkup dievaluasi dan disaring untuk memberikan awalan yang lebih detail pada saat estimasi dimulai. Pertimbangan kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Batasan ini mengidentifikasi dari batas yang ditempatkan pada perangkat lunak oleh perangkat keras eksternal, memori atau sistem informasi yang ada.

SUMBER DAYA

Tugas kedua perencanaan perangkat lunak adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak tersebut. Lingkungan pengembangan piranti perangkat keras dan perangkat lunak – berada pada fondasi piramid sumber daya dan menyediakan infrastruktur untak mendukung usaha pengembangan. Dalarn tingkat yang lebih tinggi, kita menemukan komponen perangkat lunak reusable – blok bangunan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat penyampaian. Di puncak piramida terdapat sumber daya utama – manusia (people). Masing-masing sumber daya ditentukan dengan empat karakteristik: deskripsi sumber daya, statemen ketersediaan, waktu kronologis sumber daya diperlukan, serta durasi waktu sumber daya diaplikasikan. Dua karakteristik terakhir dapat dilihat sebagai time windows (jendela waktu). Tersedianya sumber daya untuk sebuah jendela khusus harus dibangun pada waktu praktik paling awal.

ESTIMASI PROYEK PERANGKAT LUNAK

Biaya perangkat lunak terdiri dari presentase kecil pada biaya sistem berbasis komputer secara keseluruhan. Kesalahan estimasi biaya yang besar dapat memberikan perbedaan antara keuntungan dan kerugian. Estimasi proyek perangkat lunak dapat ditranformasi dari suatu seni yang misterius ke dalam langkah-langkah yang sistematis yang memberikan estimasi dengan risiko yang dapat diterima.

Ada Sejumlah pilihan untuk mencapai estimasi biaya dan usaha yang dapat dipertanggung jawabkan :

  1. Menunda etimasi sampai akhir proyek.
  2. Mendasarkan etimasi pada proyek-proyek yang mirip yang sudah pernah dilakukan sebelumnya.
  3. Menggunakan “teknik dekomposisi” yang relatif sederhana untuk melakukan estimasi biaya dan usaha proyek.
  4. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya perangkat lunak.

Model estimasi empiris dapat digunakan untuk melengkapi teknik dekomposisi serta menawarkan pendekatan estimasi yang secara potensial berharga. Model berbasis pengalaman(data hitoris) dan berbentuk :

d=f(vi)

di mana d adalah satu dari sejumlah harga estimasi(contoh : usaha, biaya,durasi proyek) dan vi adalah parameter independen yang dipilih (seperti LOC dan FP yang diestimasi). Peranti estimasi otomatis mengimplementasi satu atau lebih teknik dekomposisi atau model empiris. Masing-masing pilihan estimasi biaya perangkat lunak yang dapat dilakukan sama baiknya dengan data hitoris yang digunakan untuk menumbuhkan estimasi.

TEKNIK DEKOMPOSISI

Masalah yang dipecahkan sangat kompleks untuk dipertimbangkan sebagai satu kesatuan, karena itu kita mendekoposisi masalah, menandainya sebagai serangkaian masalah yang lebih kecil.

Software Sizing
Akurasi estimasi proyek perangkat lunak didasrkan pada sejumlah hal :

  1. Tingkat di mana perencana telah dengan tepat mengestimasi ukuran produk yang akan dibuat
  2. .Kemampuan untuk menerjemahkan estimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar (fungsi availabiltas metrik perangkat lunak yang reliabel dari proyek sebelumnya).
  3. Tingkat di mana rencana proyek mencerminkan kemampuan tim perangkat lunak.
  4. Stabilitas syarat produk serta lingkungan yang mendukung usaha pengembangan perangkat lunak.

Dalam konteks perencanaan proyek, ukuran berarti keluran yang dapat dikuantitatifkan dari proyek perangkat lunak. Bila dilakukan pendekatan secara langung, ukuran dapat diukur dalam LOC. Tetapi bila dipilih pendekatan tidak langsung, ukuran dihadirkan dalam FP. Putnam dan Myres mengusulkan :

  1. Fuzzy-logic sizing
    Pendekatan yang menggunakan teknik reasoning aproksimasi yang merupakan dasar bagi fuzzy logic(logika kabur). Perencana harus mengidentifikasi tipe aplikasi, membuat besarnya dalam skala kuantitatif, dan menyaring besaran itu dalam bentuk oriinil.
  2. Function point sizing
    Perencanaan pengembangan estimasi karakteritik domain informasi.
  3. Standart component sizing
    Perangkat lunak dibangun dari sejumlah komponen yang standar yang berbeda-beda yang umum bagi suatu era aplikasi tertentu.
  4. Change sizing
    Pendekatan ini digunakan bila proyek melingkupi pemakaian perangkat lunak yang ada harus dimodihikasi dengan banyak cara sebagai bagian dari sebuah proyek.

Dengan menggungakan suatu “rasio kerja” bagi masing-masing tipe perubahanm, maka ukuran perubahan dapat diperkirakan.

 Perkiraan Berdasarkan Masalah

Baris kode(LOC) dan titik fungsi (FP) digambarkan sebagai pengukuran dasar di mana metrik produktivitas dapat dihitung. Data LOC dan FP digunakan dalam dua cara :

  • Sebagai variabel untuk estimasi yang dipakai untuk mengukur masing-masing elemen perangkat lunak
  • Sebagai metrik baseline yang dikumpulkan dari proyek yang lalu dan dipakai dalam hubungannya dengan variabel estimasi untuk mengembangkan proyeksi kerja dan biaya.

Teknik estimasi LOC dan FP  berbeda di dalam tingkat detail yang dibutuhkan untuk dekomposisi dan target pembagian. Bila LOC digunakan sebagai wariable estimasi, dekomposisi menjadi sangat penting dan sering dipakai pada tingkat yang dapat dipertanggungjawabkan. Semakin besar tingkat pemisahaannya, semakin akurat estimasi LOC dan FP yang dikembangkan. Pada esimasi FP, dekomposisi bekerja secara berbeda. Selain berfokus pada fungsi, masing-masing karakteristik domain informasi – input, output, file data, inquiry, dan interface eksternal. Estimasi resultan digunakan untuk mendapatkan nilai FP yang dapat diikat dengan data sebelumnya untuk melakukan estimasi.

MODEL PERKIRAAN EMPIRIRIS

Model perkiraan untuk perangkat lunak komputer menggunakan rumusan yang ditarik secara empiris untuk memprediksi usaha sebagai sebuah fungi LOC dan FP. Data empiris yang mendukung sebagaian besar model perkiraan ditarik dari sebuah sampel proyek yang terbatas.

Struktur Model Perkiraan
Model perkiraan tertentu ditarik dengan menggunakan analisis regresi terhadap data yang dikumpulkan dari proyek perangkat lunak sebelumnya. Struktur model ini berbentuk :

E = A+Bx(Ev)c

Dimana A, B, C adalah konstanta yang ditarik secara empiris, E adalah usaha dalam peron-month, dan EV adalah variabel perkiraan (baik dalam LOC maupun FP).

Model COCOMO
Kependekan dari COnstructive COst MOdel (Model Biaya Konstruktif). Hirarki model Boehm berbentuk sebagai berikut :

  • Model 1 : Model COCOMO dasar menghitung usaha pengembangan perangkat lunak (dan biaya) sebagai fungsi dari ukuran program yang diekspresikan dalam baris kode yang diestimasi,
  • Model 2 : Model COCOMO Intermediete menghitung usaha pengembangan perangkat lunak sebagai fungsi ukuran program dan serangkaian “pengendali biaya” yang menyangkut penilaian yang subyektif terhadap produk, perangkat keras personil, dan atribut proyek.
  • Model 3 : Model COCOMO advenced menghubungkan semua karakteristik versi intermediete dengan penilaian terhadap pengaruh pengendali biaya pada setiap langkah (analisis, perancangan, dll) dari proses rekayasa perangkat lunak. Persamaan COCOMO dasar berbentuk :

E = abKLOCbb D = cbEdb

Dimana E adalah usaha yang diaplikasikan dalam person-month, D adalah waktu pengembangan dalam bulan kronologis, dan KLOC adalah jumlah baris penyampaian kode yang diperkirakan untuk proyek tersebut. Koefisien ab dan cb dan eksponen bb dan db ada pada tabel Model cocomo dasar Proyek perangkat lunak.
ab bb cb db
Organik 2,4 1,05 2,5 0,38
Semi-detached 3,0 1,12 2,5 0,35
Embedded 3,6 1,20 2,5 0,32

Persamaan Perangkat Lunak

Persamaan perangkat lunak adalah model yang multivariasi yang mengasumsikan distribusi khusus usaha sepanjang hidup proyek pengembangan perangkat lunak. Model estimasinya berbentuk :

E = [LOC x B0,333/P]3 x (1/t4)

Di mana E = Usaha dalam person-month atau person-year T = durasi proyek dalam bulan atau tahun B = “faktor skill khusus” yang meningkat secara pelan- pelan “pada saat kebutuhan akan integrasi, pengujian, jaminan kualitas, dokumentasi, manajemen skill tumbuh”. Untuk oprogram kecil (KLOC = 5 sampai 15)` B = 0,16. Untuk program yang lebih besar dari pada 70 KLOC, B=0,39. P = “parameter produktivitas” yang mencerminkan :

  • Kematangan proses dan praktik manajemen secara keseluruhan.
  • Tingkat bahasa pemrograman yang digunakan.
  • Keadaan lingkungan perangkat lunak.
  • Skill dan pengalaman tin perangkat lunak.
  • Kompleksitas aplikasi.

KEPUTUSAN MAKE-BUY

Manajer rekayasa perangkat lunak dihadapkan pada keputusan make-buy yang dapat dikompilasikan lebih jauh lagi oleh sejumlah pilihan akuisisi :

  1. Perangkat lunak dapat dibeli(atau lisensi) off-the-shelf.
  2. Komponen perangkat lunak full-experience dan partial-experiance dapat diperoleh dan kemudian dimodifikasi dan diintegrasikan untuk memenuhi kebutuhan tertentu.
  3. Perangkat lunak dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi pembeli.

Langkah-langkah yang tercakup dalam akuisisi perangkat lunak ditentukan oleh kekritisan perangkat lunak yang akan dibeli dan biaya akhir. Dalam analisis akhir, keputusan make-buy dibuat berdasarkan kondisi berikut :

  1. Apakah tanggal penyampaian produk perangkat lunka akan lebih cepat dari pada perangkat lunak yang dikembangkan secara internal?
  2. Apakah biaya akuisisi ditambah biaya pemesanan akan lebih kecil dari pada biaya pengembangan perangkat lunak secara internal?
  3. Apakah biaya dukungan luar (seperti kontrak pemeliharaan) akan lebih rendah daripada biaya dukungan internal? Kondisi ini berlaku untuk setiap pilihan akuisisi yang telah dicantumkan di atas.

Membuat Pohon Keputusan

Langkah-langkah menggunakan teknik statistic seperti analisa puhon keputusan , diantaranya:

  1. Menbangung sistem X sebagai permulaan,
  2. Menggunakan lagi komponen partial experience yang ada untuk membangun sistem,
  3. Membeli sebuah produk prangkat lunak yang dapat dipeoleh dan memodifikasinya untuk memenuhi kebutuhan local, atau
  4. Mengontrakan pengembangan perangkat lunak ke vendor luar.

Outsourcing

Dalam konsep, outsourcing (mengontrakan keluar) sangatlah sederhana. Aktivitas rekayasa perangkat lunak dikontrakan kepada pihak ketiga yang melakukan pekerjaan tersebut dengan biaya yang lebih murah, dan diharapkan kualitas lebih tinggi. Kerja perangkat lunak yang dilakukan dalam sebuah perusahaan dikurangi untuk sebuah aktivitas manajemen kontrak.

PERANTI ESTIMASI OTOMATIS

Teknik dekomposisi dan model perkiraan empiriris yang digambarkan sebagian dari luasnya variasi peranti perangkat lunak. Peranti perangkat lunak otomatis ini memungkinkan para perencana memperkirakan biaya dan usaha serta melekuakan analisis “what if” pada variable proyek yang penting seperti tanggal penyampaian. karakteristik peranti otomatis umum dan semua memerlukan satu atau lebih kategori data berikut ini:

  1. Kuantitatif ukuran perangkat lunak (seperti LOC) atau fungsionalitas (data function point),
  2. Karakteristik proyek kuantitatif seperti kompleksitas, realibitas yang dibutuhkan,
  3. Banyak gambaran staf pengembangan dana tau lingkungan pengembangan.

KESIMPULAN

Perencanaan proyek perangkat lunak harus memperhitungkan tiga hal sebelum dimulai: berapa lama proyek akan berlangsung, beberapa usaha yang diperlukan, dan dan berapa banyak manusia yang akan terlibat. Sebagai tambahan, perencanaan juga harus memperediksi sumber-sumber (perangkat keras dan perangkat lunak) dan resiko yang akan dihadapi.

Comments are closed.

css.php
Skip to toolbar