REFERENSI FUNCTION POINT DALAM PENGUKURAN EFFORT

Dalam Development sebuah perangkat lunak/software terkadang para developer memiliki kesulitan untuk mencari satuan yang dapat mendeskripsikan ukuran dari sofware yang akan dibuat. Untuk mengetahui ukuran software yang akan dibuat sangat penting karena akan berpengaruh pada biaya dalam produksi software tesebut.

Salah satu cara yang populer untuk melakukan pengukuran perangkat lunak dapat mengunakan cara yang bernama FUNCTION POINT.

Hasil dari metode Function Point akan lebih mudah dipahami oleh pengguna non teknis yang dapat membantu mengkomunikasikan informasi ukuran software ke pengguna atau client.

Function Point dikembangkan pertama kali oleh Allan J. Albrecht di pertengahan tahun 1970-an. Merupakan upaya untuk mengatasi kesulitan yang berhubungan dengan kode program sebagai ukuran dari ukuran perangkat lunak, dan untuk membantu dalam memprediksi effort dalam development perangkat lunkas.

Function Point pertama kali di terbitkan pada tahun 1979. Pada tahun 1984 Albrecht menyempurnakan metode Function Point.

Sejak Function Point Internasional User Group (IFPUG) didirikan, beberapa versi Function Point sebagai Pedoman telah diterbitkan oleh IFPUG. Secara global pengukuran Software dengan Function Point telah diterima secara luas dalam industri perangkat lunak lebih dari 40 tahun sebagai pengukuran standar perangkat lunak.

Dalam ilmu fisika banyak satuan untuk mengukur fenomena yang ada di alam semesta ini seperti Menit untuk mengukur waktu, Kilo Meter untuk mengukur jarak, Celsius untuk mengukur Suhu.

Dan untuk mengukur perangkat lunak atau software maka dapat menggunakan Function Point yang biasa disingkat dengan FP.

Function Point adalah sebuah sebuh teknik terstruktur dalam memecahkan masalah dengan cara memecah sistem menjadi komponen yang lebih kecil dan menetapkan beberapa karakteristik dari sebuah software sehingga dapat lebih mudah dipahami dan dianalisis.

Function Point mengukur dari perspektif Functional dari software yang akan dibangun, terlepas dari bahasa programaan, metode development atau platform perangkat keras yang digunakan,

Function Point harus dilakukan oleh orang terlatih dan berpengalaman dalam development software, karena dalam memberikan nilai-nilai dari setiap komponen Function point bersifat subyektif, dan akan wajar apabila hasil perhitungan function point seseorang akan berbeda dengan yang lain.

Pengerjaan Function poin harus dimasukkan sebagai bagian dari rencana proyek secara keseluruhan. Artinya harus dijadwalkan dan direncanakan pengerjaannya.

Hasil dari pengukuran menggunakan Function Point dapat digunakan untuk mengestimasi biaya dan effort yang diperlukan dalam development perangkat lunak.

TAHAPAN MELAKUKAN FUNCTION POINT

TAHAP 1. Menghitung Crude Function Points (CFP)

Crude Function Points (CFP) adalah untuk menghitung bobot nilai dari komponen-komponen Function Point yang dikaitkan dengan software yang akan dibuat.

Komponen-komponen Function Point terdiri dari 5 buah yaitu sebagai berikut.

• Tipe Input, Berkaitan dengan interface yang lakukan pengguna/user dalam memasukan data pada aplikasi.
• Tipe Output, Berkaitan dengan output yang dihasilkan aplikasi untuk pengguna/user yang dapat berupa laporan di print atau yang ditampilkan pada layar.
• Tipe Query/Search/View, Berkaitan dengan query terhadap data yang tersimpan.
• Tipe File/Tabel/Database, berkaitan dengan logic penyimpan data yang dapat berupa file atau semacam database relational.
• Tipe Interface Eksternal, Berkaitan dengan komunikasi data pada parangkat/mesin yang lain, contoh nya adalah membuat aplikasi SMS Server yang membutuhkan. koneksi pada perangkat keras Modem telepon.

Selanjutnya setiap tipe komponen tersebut diberikan bobot berdasarkan kompleksitasnya, seperti yang ditujukan pada table dibawah ini.

Klik Gambar Untuk Melihat Lebih Jelas

• Nilai-nilai Bobot dari setiap komponen diatas adalah ketetapan atau konstanta yang dibuat oleh Function Point Internasional User Group (IFPUG)

TAHAP 2. Menghitung Relative Complexity Adjustment Factor (RCAF)

RCAF digunakan untuk menghitung bobot kompleksitas dari software berdasarkan 14 karakteristik.

Penilaian Komplesitas memilik skala 0 s/d 5

• 0 = Tidak Pengaruh
• 1 = Insidental
• 2 = Moderat
• 3 = Rata-rata
• 4 = Signifikan
• 5 = Essential

Berikut ini adalah 14 Karakteritik Software

NO	KARAKTERISTIK	BOBOT
1.	Tingkat kompleksitas Komunikasi Data	[0/1/2/3/4/5]
2.	Tingkat kompleksitas Pemrosesan Terdistribusi	[0/1/2/3/4/5]
3.	Tingkat kompleksitas Performance	[0/1/2/3/4/5]
4.	Tingkat kompleksitas Konfigurasi	[0/1/2/3/4/5]
5.	Tingkat Frekuensi Penggunaan Software	[0/1/2/3/4/5]
6.	Tingkat Frekuensii Input Data	[0/1/2/3/4/5]
7.	Tingkat Kemudaaan Pengunaan Bagi User	[0/1/2/3/4/5]
8.	Tingkat Frekuensi Update Data	[0/1/2/3/4/5]
9.	Tingkat Kompleksitas Prosesing Data	[0/1/2/3/4/5]
10.	Tingkat Kemungkinan Penggunaan Kembali/Reusable Kode Program	[0/1/2/3/4/5]
11.	11. Tingkat Kemudahaan Dalam Instalasi	[0/1/2/3/4/5]
12.	Tingkat Kemudahaan operasional software (backup, recovery, dsbny)	[0/1/2/3/4/5]
13.	Tingkat Software dibuat untuk multi organisasi/perusahaan/client	[0/1/2/3/4/5]
14.	Tingkat kompleksitas dalam mengikuti perubahaan/fleksibel	[0/1/2/3/4/5]
	TOTAL	?

• Karakteristik diatas merupakan ketetapan atau konstanta yang dibuat oleh Function Point Internasional User Group (IFPUG)

TAHAP 3 : Menghitung Function Point (FP)

Adalah proses melakukan perhitungan untuk mendapat nilai Function point dari sofrware yang akan dibangun

Rumus FP

• FP = CFP x (0.65 + 0.01 x RCAF)

Angka 0.65 dan 0.01 adalah ketetepan atau konstanta yang dibuat oleh Function Point Internasional User Group (IFPUG)

CONTOH  KASUS PENGGUNAAN FUNCTION POINT DALAM PROJEK

Akan dibangun sebuah software dalam pengelolahan Sistem Informasi Sumber Daya Manusia yang rencanakan untuk mengelola karyawan dari jumlah 10 hingga 200 karyawan dan akan menghasilkan berbagai macam laporan seperti absensi karyawan,sallery karyawan dan sebagainya. Aplikasi ini sangat memungkinkan berinteraksi dengan perangkat keras absensi seperti Fingger Print serta menyediakan webservice agar Software Sumber Daya Manusia ini dapat berkolaborasi Software Menajemen Proyek yang telah berjalanan.

TAHAP 1. Menghitung Crude Function Points (CFP)

Klik Gambar Untuk Melihat Lebih Jelas

• Crude Function Points (CFP) yang didapat 923

TAHAP 2. Menghitung Relative Complexity Adjustment Factor (RCAF)

NO	KARAKTERISTIK	BOBOT
1.	Tingkat kompleksitas Komunikasi Data	3
2.	Tingkat kompleksitas Pemrosesan Terdistribusi	3
3.	Tingkat kompleksitas Performance	5
4.	Tingkat kompleksitas Konfigurasi	2
5.	Tingkat Frekuensi Penggunaan Software	5
6.	Tingkat Frekuensii Input Data	3
7.	Tingkat Kemudaaan Pengunaan Bagi User	5
8.	Tingkat Frekuensi Update Data	1
9.	Tingkat Kompleksitas Prosesing Data	3
10.	Tingkat Kemungkinan Penggunaan Kembali/Reusable Kode Program	3
11.	11. Tingkat Kemudahaan Dalam Instalasi	3
12.	Tingkat Kemudahaan operasional software (backup, recovery, dsbny)	2
13.	Tingkat Software dibuat untuk multi organisasi/perusahaan/client	3
14.	Tingkat kompleksitas dalam mengikuti perubahaan/fleksibel	4
	TOTAL	45

TAHAP 3. Menghitung Function Point (FP)

FP = CFP x (0.65 + 0.01 x RCAF)

     = 923 x (0.65 + (0.01 x 45))

     = 1015.3

Nilai FP untuk proyek Software dalam pengelolahan Sistem Informasi Sumber Daya Manusia adalah 1015.3 FP

TAHAP 4. Konversi FP menjadi Biaya

Misalkan kita mempunyai table yang berisikan tarif untuk setiap nilaI FP sebagai berikut

NO	TIPE PROJEK	TARIF/FP	JAM/FP	ALOKASI SDM
1	Web Profile	Rp. 20.000	1	2
2	Sistem Informasi	Rp. 100.000	1	5
3	E-Commerce	Rp. 40.000	1	2

Tabel tarif tersebut dihasilkan berdasarkan data history atau pengalaman dari perusahaan sendiri dalam developing software atau pengalaman perusahaan lain. Setiap perusahaan bisa berbeda-beda tarifnya karena bersifat subyektif,

Dan mengenai Tarif Rupiah per-FP setiap peruhaan bisa berbeda-berbeda tergantug dari kredibilitas perusahaan di pasar, semakin banyak berhasi menyelesaikan proyek sejenis atau memiliki produk yang laku di pasaran akan membuat tarif per FP nya meningkat.

Proyek Software dalam pengelolahan Sistem Informasi Sumber Daya Manusia adalah 1015.3 FP dengan Tarif Rupiah/FP untuk jenis Sistem Informasi adalah Rp. 100.000.  Maka Dapat dihasilkan sebagai berikut.

• Estimasi Biaya Development Software : Rp 100.000 x 1015.3 = Rp. 101.530.000
• Estimasi Khusus Produksi Software : 1 Jam x 1015.3 = 1015 Jam atau 127 Hari Kerja (Asumsi 1 Hari Kerja sama dengan 8 Jam) atau 5 Bulan (Asumi 1 bulan 25 Hari Kerja)

ESTIMASI

saya sangat tertarik dengan pertanyaan yang diajukan oleh Profesor saya pagi ini tentang manajemen projek dimana pada pembahasan kali ini kami membahas soal estimasi .. berikut peranyaan nya sebagai bahan dokumentasi buat saya atas jawaban saya yang mungkin saja bisa terdapat kekeliruan dan bisa dikoreksi sebagai bahan pembelajaran..

Estimating

Salah satu persoalan terbesar dalam manajemen proyek software adalah bagaimana kita dapat membuat perkiraan yang tepat atas 3 komponen, yaitu usaha (effort), sumber daya (resources), dan jangka waktu (duration). Mohon anda diskusikan dari masing-masing komponen tersebut, mana cara dan pendekatan yang paling baik dan tepat untuk digunakan, dan apa alasannya. Silakan saling memberi masukan dan tanggapan atas pertanyaan ini.

awalnya agag bingung untuk menjawab kaena dari ketiga aspek komponen tersebut memiliki beberapa keterkaitan yang cukup kuat sehingga saya hanya menjawab sesuai pengetahuan saya .. semoga benar ..

Assalamualaikum,

siang Prof.

menurut saya dari ke 3 komponen itu antara lain

effort (usaha) : adalah serangkaian aktivitas atau proses yang dilakukan dalam mengerjakan sebuah proyek atau memanajemen sebuah projek mengacu pada fase-fase pelaksanaan proyek yang mencakup  fase inisiasi proyek, perencanaan proyek, pelaksanaan proyek, pengendalian proyek dan penyerahan proyek, agar ruang lingkupnya tercapai , kualitasnya terpenuhi, selesai sesuai jadwal dan menggunakan dana sesuai dengan yang disediakan.

sedangkan Resourses (sumber daya) adalah segala  sesuatu yang akan mendukung terlaksananya sebuah effort dimana resourses harus memiliki fungsi pendukung dalam mencapai efisiensi dan efektivitas dalam penyelesaian proyek. Fungsi pendukung tersebut meliputi manajemen sumber daya manusia, manajemen komunikasi, manajemen resiko dan manajemen pengadaan.yang nantinya akan berhubungan dengan manager project .

selanjutnya adalah Duration ( jangka waktu) adalah salah satu faktor yang sangat menentukan dalam pembangunan sebuah project TI dimana manajemen waktu harus benar- benar diperhitungkan .waktu adalah masuk kedalam komponen tujuan sebuah proyek yang antara lain nya adalah ruang lingkup (scope) , waktu, biaya dan kualitas,dimana waktu adalah salah satu faktor pendukung dalam keberhasilan sebuah projek. Keberhasilan dari sebuah proyek dapat diukur dari ketepatan waktu sesuai yang telah direncanakan. Penyelesaian yang terlambat akan berdampak buruknya kredibelitas pelaksana proyek dimata user atau pemberi proyek, karena bagi user proyek tersebut bisa mempengaruhi aktivitas organisasi. Sehingga waktu merupakan faktor yang sangat penting dari sebuah proyek.

menurut saya ketika kita melakukan manajemen sebuah projek kita harus benar- benar mengetahui tahapan- tahapan pelaksaan projek tersebut.antara lain Project Initiation (Inisiasi proyek),Project Planning (perencanaan awal proyek),Project Executing (Pelaksanaan proyek),Project Control (Pengendalian proyek),Project Closing, agar kita dapat melakukan manajemen estimasi dengan tepat sesuai fase-fase yang dilakukan.

Requirement project…

MANAJEMEN PROSES

MANAJEMEN PROSES

Langkah-langkah dalam manajemen proses adalah :

1. Identifikasi resiko

Proses ini meliputi identifikasi resiko yang mungkin terjadi dalam suatu aktivitas usaha. Identifikasi resiko secara akurat dan komplit sangatlah vital dalam manajemen resiko. Salah satu aspek penting dalam identifikasi resiko adalah mendaftar resiko yang mungkin terjadi sebanyak mungkin. Teknik-teknik yang dapat digunakan dalam identifikasi resiko antara lain:

• Brainstorming
• Survei
• Wawancara
• Informasi histori
• Kelompok kerja

Tipe-tipe resiko:

Untuk keperluan identifikasi dan mengelola resiko yang dapat menyebabkan sebuah pengembangan melampaui batas waktu dan biaya yang sudah dialokasikan maka perlu diidentifikasikan tiga tipe resiko yang ada yaitu:

• Resiko yang disebabkan karena kesulitan melakukan estimasi.
• Resiko yang disebabkan karena asumsi yang dibuat selama proses perencanaan.
• Resiko yang disebabkan adanya even yang tidak terlihat (atau tidak direncanakan).

Beberapa kategori faktor yang perlu dipertimbangkan adalah sebagai berikut:

• Application Factor

Sesuatu yang alami dari aplikasi baik aplikasi pengolahan data yang sederhana, sebuah sistem kritis yang aman maupun sistem terdistribusi yang besar dengan elemen real time terlihat menjadi sebuah faktor kritis. Ukuran yang diharapkan dari aplikasi juga sesuatu yang penting – sistem yang lebih besar, lebih besar dari masalah error, komunikasi dan manajemennya.

• Staff Factor

Pengalaman dan kemampuan staf yang terlibat merupakan faktor utama – seorang programer yang berpengalaman, diharapkan akan sedikit melakukan kesalahan dibandingkan dengan programer yang sedikit pengalamannya. Akan tetapi kita harus juga mempertimbangkan ketepatan pengalaman tersebut- pengalaman membuat modul dengan Cobol bisa mempunyai nilai kecil jika kita akan mengembangkan sistem kendali real-time yang komplek dengan mempergunakan C++.

Beberapa faktor seperti tingkat kepuasan staf dan tingkat pergantian dari staf juga penting untuk keberhasilan sebarang pengembangan – staf yang tidak termotivasi atau person utama keluar dapat menyebabkan kegagalan pengembangan.

• Project Factor

Merupakan hal yang penting bahwa pengembangan dan obyektifnya terdefinisi dengan baik dan diketahui secara jelas oleh semua anggota tim dan semua stakeholder utama. Jika hal ini tidak terlaksana dapat muncul resiko yang berkaitan dengan keberhasilan pengembangan tersebut. Dengan cara serupa, perencanaan kualitas yang formal dan telah disepakati harus dipahami oleh semua partisipan.  Jika perencanaan kualitas kurang baik dan tidak tersosialisasi maka  dapat mengakibatkan gangguan pada pengembangan tersebut.

• Project Methods

Dengan mempergunakan spefikasi dan metode terstruktur yang baik pada manajemen pengembangan dan pengembangan sistem akan mengurangi resiko penyerahan sistem yang tidak memuaskan atau terlambat. Akan tetapi penggunaan metode tersebut untuk pertama kali dapat mengakibatkan problem dan delay.

• Hardware/software Factor

Sebuah pengembangan yang memerlukan hardware baru untuk pengembangan mempunyai resiko yang lebih tinggi dibandingkan dengan software yang dapat dibangun pada hardware  yang sudah ada (dan familiar). Sebuah sistem yang dikembangkan untuk satu jenis hardware atau software platform tertentu jika dipergunakan pada hardware atau software platform lainnya bisa menimbulkan resiko tambahan (dan tinggi) pada saat instalasi.

• Changeover Factor

Kebutuhan perubahan “all-in-one” kedalam suatu sistem baru mempunyai resiko tertentu. Perubahan secara bertahap atau gradual akan meminimisasi resiko akan tetapi cara tersebut tidak praktis. Menjalankan secara paralel dapat memberikan solusi yang aman akan tetapi biasanya tidak mungkin atau terlalu mahal.

• Supplier Factor

Suatu pengembangan yang melibatkan organisasi eksternal yang tidak dapat dikendalikan secara langsung dapat mempengaruhi keberhasilan pengembangan.  Misal tertundanya  instalasi jalur telpon atau pengiriman peralatan yang sulit dihindari- dapat berpengaruh terhadap keberhasilan pengembangan.

• Environment Factor

Perubahan pada lingkungan dapat mempengaruhi keberhasilan pengembangan. Misal terjadi perubahan regulasi pajak, akan mempunyai dampak yang cukup serius pada pengembangan aplikasi penggajian.

• Health and Safety Factor

Ada satu isu utama yaitu faktor kesehatan dan keamanan dari partisipan yang terlibat dalam pengembangan software walaupun tidak umum (dibandingkan dengan pengembangan teknik sipil) yang dapat mempengaruhi aktifitas pengembangan.

Kesalahan estimasi

Beberapa pekerjaan lebih sulit untuk melakukan estimasi dibandingkan pekerjaan lainnya disebabkan karena terbatasnya pengalaman pada pekerjaan serupa atau disebabkan karena jenis pekerjaan tersebut. Pembuatan sebuah user manual merupakan langkah yang tepat yang dapat dipertanggungjawabkan dan sebagai bukti bahwa kita pernah mengerjakan tugas yang serupa sebelumnya. Dengan pengalaman itu seharusnya kita mampu untuk melakukan estimasi dengan lebih tepat mengenai berapa lama pekerjaan dapat diselesaikan dan berapa besarnya biaya yang dibutuhkan. Selain itu, waktu yang dibutuhkan untuk melakukan pengujian dan penelusuran program dapat menjadi sesuatu hal yang sulit diprediksi dengan tingkat keakuratan yang serupa walaupun kita pernah membuat program yang serupa sebelumnya.

Estimasi dapat ditingkatkan melalui analisa data historis untuk aktifitas yang serupa dan untuk sistem yang serupa. Dengan menyimpan perbandingan antara estimasi semula dengan hasil akhir akan mengakibatkan beberapa tipe pekerjaan sulit diestimasi secara tepat.

Resiko ini terjadi jika perkiraan LOC pada kenyataan yang ada jauh melebihi LOC perkiraan pada perhitungan COCOMO, yang mengakibatkan berubahnya jadwal pengerjaan dan biaya operasional.

Asumsi perencanaan

Pada setiap tahapan perencanaan, asumsi perlu dibuat, jika tidak benar maka dapat mengakibatkan resiko tersebut beresiko. Misal pada jaringan aktifitas, aktifitas dibangun berdasarkan pada asumsi menggunakan metode desain tertentu dimana memungkinkan urutan aktifitas diubah. Kita biasanya membuat asumsi bahwa setelah coding, biasanya sebuah modul akan diuji dan kemudian diintegrasikan dengan modul lainnya. Akan tetapi kita tidak merencanakan pengujian modul yang dapat mangakibatkan perubahan desain awal. Hal ini dapat terjadi setiap saat.

Pada setiap tahapan pada proses perencanaan, sangat penting untuk memeperinci secara eksplisit semua asumsi yang dibuat dan mengidentifikasi apa pengaruhnya jika ternyata dalam pelaksanaannya tidak sesuai dengan yang sudah direncanakan.

Kemungkinan

Beberapa kemungkinan dapat saja tidak pernah terlihat dan kita hanya dapat menyakinkan diri kita sendiri bahwa ada sesuatu yang tidak dapat dibayangkan, kadang-kadang dapat terjadi. Akan tetapi biasanya jarang terjadi hal seperti itu. Mayoritas kejadian yang tidak diharapkan biasanya dapat diidentifikasi beberapa spesifikasi kebutuhan kemungkinan diubah setelah beberapa modul telah dikodekan, programmer senior meninggalkan pengembangan, perangkat keras yang diperlukan tidak dikirim tapat waktu. Beberapa kejadian semacam itu dapat terjadi sewaktu-waktu dan walaupun kejadian tersebut kemungkinan terjadinya relatif rendah akan tetapi kejadian tersebut perlu dipertimbangkan dan direncanakan.

Metode untuk evaluasi pengaruh ketidakpastian ini terhadap jadwal proyek:

• Penggunaan PERT untuk evaluasi pengaruh ketidakpastian

PERT dikembangkan untuk menghitung estimasi ketidakpastian lingkungan terhadap durasi pekerjaan. PERT dikembangkan pada suatu lingkungan proyek yang mahal, beresiko tinggi dan kompleks. Metode PERT ini memerlukan tiga estimasi:

• Most likely time

Waktu yang diperlukan untuk menyelesaikan pekerjaan dalam situasi normal dan diberikan simbol m.

• Optimistic time

Waktu tersingkat yang diperlukan untuk menyelesaikan pekerjaan dan diberi simbol a.

• Pessimistic time

Waktu terlama yang diperlukan untuk menyelesaikan pekerjaan dikarenakan berbagai kemungkinan yang masuk akal dan diberikan simbol b.

PERT mengkombinasikan ketiga estimasi tersebut untuk membentuk durasi tunggal yang diharapkan, t_e = a + 4m + b

• Penggunaan durasi yang diharapkan

Durasi yang diharapkan dipergunakan supaya suatu forward pass dapat melalui sebuah jaringan; dengan mempergunakan metode yang sama dengan teknik CPM. Akan tetapi dalam hal ini, tanggal aktifitas yang dihitung bukan merupakan tanggal paling awal akan tetapi merupakan tanggal yang diharapkan dapat mencapai aktifitas tersebut.

Jaringan PERT yang diperlihatkan pada gambar 3 memperlihatkan bahwa kita berharap proyek tersebut dapat diselesaikan dalam waktu 13,5 minggu- tidak seperti CPM yang tidak memperlihatkan tanggal paling awal untuk menyelesaikan proyek tersebut akan tetapi tanggal yang diharapkan (atau most likely). Salah satu keuntungan dari pendekatan ini adalah menempatkan sebuah emphasis dalam ketidakpastian di dunia nyata.

MANAJEMEN RESIKO DALAM PENGEMBANGAN PERANGKAT LUNAK

MANAJEMEN RESIKO

Manajemen resiko adalah proses pengukuran atau penilaian resiko serta pengembangan strategi pengelolaannya. Strategi yang dapat diambil antara lain adalah memindahkan resiko kepada pihak lain, menghindari resiko, mengurangi efek negatif resiko, dan menampung sebagian atau semua konsekuensi resiko tertentu. Manajemen resiko tradisional terfokus pada resiko-resiko yang timbul oleh penyebab fisik atau legal (seperti bencana alam atau kebakaran, kematian serta tuntutan hokum). (Wikipedia)

Manajemen resiko adalah rangkaian langkah-langkah yang membantu suatu perangkat lunak untuk memahami dan mengatur ketidak pastian (Roger S. Pressman).

Rekayasa Perangkat lunak

SOFTWARE ENGINGEERING

Dalam rekayasa perangkat lunak tahap awal adalah pendefinisian tentang rekayasa system apa yang akan dibuat. Diperlukan proses perencanaan dan analisis kebutuhan. Setelah pendefinisian tahap selanjutnya adalah pengembangan, dalam tahap ini adalah bagaimana produk yang telah didefinisikan dengan jelas kemudian akan mulai diimplementasikan.  Maka pada proses pengembangan ini akan dilakukan design software, kemudian mengenerate koding-koding pembangun program, hingga program siap dites kebenarannya.

Proses rekayasa perangkat lunak adalah proses yang terus berulang, karena karakteristik perangkat lunak yang membutuhkan pemeliharaan dan continue development agar perangkat lunak tidak kadarluasa. Dalam proses pemelihataan kita melakukan koreksi kesalahan, adaptasi kebutuhan, peningkatan kemampuan atau fungsi dan bentuk pencegahan lainnya agar perangkat lunak tersebut tidak kadarluasa.

Penyebab kegagalan rekayasa perangkat lunak adalah :

• Perencanaan yang tidak realistik, terlalu optimis dalam perhitungan.
• sistem pemantauan kerja yang tidak berjalan dengan seharusnya.
• Perubahan kebutuhan.
• Resiko-resiko lainnya

METODOLOGI PROSES

Metodologi adalah cara sistematis atau cara yang didefinisikan secara jelas untuk mencapai tujuan akhir. Juga merupakan sebuah system tata tertib dalam berpikir atau bertindak. Metodologi yang baik adalah sebuah peta atau jalan yang menjadi panduan untuk menemukan jalan yang tepat untuk mencapai tujuan.

Metodologi dalam proses rekayasa perangkat lunak masih menjadi objek penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, yaitu :

• Pendekatan Waterfall
• Pengembangan secara evolusioner
• Trasformasi Formal
• Reuse

MODEL WATERFALL

Pertama kali diperkenalkan oleh Winston Royce tahun1970. Model ini merupakan model klasik yang sederhana dengan aliran system yang linear. Output dari setiap tahap menjadi input bagi tahap berikutnya. Model ini melibatkan SQA (Software Quality Assurance) dengan tahapan yang setiap tahapannya dilakukan verivikasi dan testing. Tahapa-tahapannya adalah :

Requirement

Pada tahapan ini dilakukan analisa kebutuhan, kemudian diverivikasi oleh klien dan tim SQA. Jasa, kendala, tujuan dihasilkan dari konsultasi dengan pengguna system, kemudian semuanya dibuat dalam bentuk yang dapat dimengerti oleh staf pengembang.

Specification

Jika dokumentasi spesifikasi disetujui oleh klien, maka dokumen tersebut merupakan kontrak kerja antara klien dengan pengembang software. Selanjutnya adalah merencanakan jadwal pengembangan software. Jika disetujui, maka tahap desain akan dilakukan.

Desain

Pada proses desain, system membagi kebutuhan-kebutuhan untuk menghasilkan sebuah arsitektur system keseluruhan. Yang dilakukan pada tahap ini adalah :

• Dekomposisi modul system
• Rancangan masukan dan keluaran
• Penetapan struktur data
• Penetapan prosedur kerja
• Penetapan formula pengolahan data

Implementasi dan Integrasi

Adalah tahap dilakukannya konversi dari hasil rancangan (spesifikasi program) menjadi source code yang terpisah masih dalam bentuk modul, kemudian setiap modul akan diuji terlebih dahulu sebelum digabungkan dengan modul lainnya, kemudian system yang terbentuk dari proses integrasi akan diuji untuk meyakinkan persyaratan perangkat lunak terpenuhi.

Operation Mode dan Retriment

Merupakan tahap terpanjang. Sistem dipasang dan digunakan. Dilakukan pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya.

Jika tim SQA tidak menyetujui maka tahapan pada model waterfall tidak dianggap selesai. Jika terdapat ketidaksesuaian dengan dokumen tahap sebelumnya, maka proses harus kembali ke tahap sebelumnya untuk penyesuaian dan peninjauan ulang. Model ini mengijinkan untuk kembali ketahap sebelumnya.

Permasalahan pada linear model atau waterfall adalah :

• Penanganan perubahan pada saat proses sedang berlangsung menjadi lebih sulit.
• Semua kebutuhan sudah terefenisi sejak awal.
• Software yang diberikan adalah versi terakhir dari setiap tahap, perubahan dalam proses biasanya tidak dilakukan.
• Blocking state

MODEL PROTOTYPING

Terdiri atas tiga bentuk model proses yaitu :

• Diatas kertas berbasis komputer menggambarkan interaksi manusia.
• Working prototype : mengimplementasikan sebagian fungsi perangkat lunak.
• Program jadi : melakukan sebagian atau keseluruhan fungsi yang akan dilakukan. Ada beberapa feature yang belum dikembangkan.

Tahapan proses prototyping adalah :

• Requirement : pengumpulan kebutuhan dan perbaikan
• Quick design
• Pembentukan Prototyping
• Evaluasi Pelanggan
• Perbaikan Prototyping

* Iterasi dilakukan terus menerus mulai dari tapa Quick Design hingga perbaikan Prototype sampai didapat produk akhir.

Permasalahan pada model Prototyping adalah :

• Pelanggan yang melihat working version kemungkinan tidak menyadari bahwa mungkin prototype dibuat terburu-buru dengan rancangan yang disusun tidak terstruktur.
• Pembuatan kadang membuat implementasi sembarang karena ingin working version bekerja lebih cepat.

MODEL SPIRAL BOEHM

Model ini diusulkan oleh Boehm pada tahun 1988 sebagai pendekatan alternative dari model waterfall. Model ini menggunakan fitur yang ada pada model waterfall dan prototype. Setiap tahapan model ini selalu dilakukan risk analisys dan verivikasi atau testing. Model ini memiliki empat aktivitas yaitu :

• Determine objectives : penentuan tujuan, alternative dan batasan dalam proses.
• Risk Analysis : analisa alternatif terhadap resiko yang mungkin terjadi.
• Engineering/develop : pengembangan produk.
• Plant next phase : penentuan rencana-rencana untuk tahap selanjutnya.

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah  bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Risk Analysis yang dilakukan model spiral ini adalah :

• Project Risk : Hal-hal yang mempengaruhi tahap proyek, contoh : kekurangan sumber daya.
• Technical Risk : Hal-hal yang mempengaruhi tahap actual, contoh :; personil tidak terlatih ditahap tersebut.
• Bussiness Risk : Hal-hal yang mempengaruhi keinginan perusahaan untuk membuat software, contoh : software ternyata tidak dibutuhkan lagi.

Prioritas resiko dapat dikategorikan sebagai berikut :

• Catastrophic (luar biasa), contoh : penurunan kualitas yang luar biasa, biaya yang tidak terkontrol.
• Critical (kritis), contoh : tidak tepat waktu, biaya diluar perkiraan.
• Marginal (ringan), contoh : penjadwalan yang terlambat.
• Negligible (tidak berarti), contoh : penggunaan waktu proyek yang tidak optimal.

Model spiral sangat baik digunakan untuk pengembangan sistem yang besar, karena sistem ini meminimalisasi resiko lewat mekanisme yang baik. kelemahan sistem ini ada pada pengontrollannya dan belum banyak cerita sukses tentang penggunaan model ini.

MODEL INCREMENTAL

Model ini menerapkan rekayasa perangkat lunak perbagian, hingga menghasilkan perangkat lunak yang lengkap. Proses membangun berhenti jika produk telah mencapai seluruh fungsi yang diharapkan. Pada awal tahapan dilakukan penentuan, kebutuhan dan spesifikasi. Kemudian dilakukan perancangan arsitektur software yang terbuka, agar dapat diterapkan pembangunan per-bagian pada tahapan selanjutnya.

Tahapan pada model incremental adalah requirement, specification, architektur design, kemudian tahapan membangun tiap bagian secara berurutan. Setiap bagian yang telah selesai testing, maka akan dikirim kepemakai untuk lansung dapat digunakan. Pada model incremental, tahapan requirement, specification dan architektur design harus dikerjakan terlebih dahulu sebelum tahapan pembagian tiap modul.

Kembali lagi kepada MANAJEMEN RESIKO PADA REKAYASA PERANGKAT LUNAK

Pada saat kita mengerjakan pengembangan perangkat lunak sering kita menghadapi berbagai situasi yang tidak nyaman seperti keterlambatan pengembangan atau pengeluaran biaya pengembangan yang melebihi anggaran. Hal ini dikarenakan kurang siapnya kita menghadapi berbagai kemungkinan resiko yang akan terjadi. Untuk itu perlu dilakukan identifikasi tindakan yang harus dilakukan untuk mencegah ataupun meminimalkan resiko tersebut.

Mengapa manajemen resiko itu penting? Sikap orang ketika menghadapi resiko berbeda-beda. Ada orang yang berusaha untuk menghindari resiko, namun ada juga yang sebaliknya sangat senang menghadapi resiko sementara yang lain mungkin tidak terpengaruh dengan adanya resiko. Pemahaman atas sikap orang terhadap resiko ini dapat membantu untuk mengerti betapa resiko itu penting untuk ditangani dengan baik.

Beberapa resiko lebih penting dibandingkan resiko lainnya. Baik penting maupun tidak sebuah resiko tertentu bergantung pada sifat resiko tersebut, pengaruhnya pada aktifitas tertentu dan kekritisan aktifitas tersebut. Aktifitas beresiko tinggi pada jalur kritis pengembangan biasanya merupakan penyebabnya.

Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk meminimalkan resiko atau paling tidak mendistribusikannya selama pengembangan tersebut dan idealnya resiko tersebut dihapus dari aktifitas yang mempunyai jalur yang kritis.

Resiko dari sebuah aktifitas yang sedang berlangsung sebagian bergantung pada siapa yang mengerjakan atau siapa yang mengelola aktifitas tersebut. Evaluasi resiko dan alokasi staf dan sumber daya lainnya erat kaitannya.

Resiko dalam perangkat lunak memiliki dua karakteristik:

• Uncertainty : tidak ada resiko yang 100% pasti muncul.
• Loss : resiko berimbas pada kehilangan.

Dan resiko memiliki tiga kategori:

• Resiko proyek : berefek pada perencanaan proyek.
• Resiko teknikal : berefek pada kualitas dan waktu pembuatan perangkat lunak.
• Resiko bisnis : berefek pada nilai jual produk

Contoh : Seorang programmer yang sangat pintar keluar. Resiko yang mana?

1. Analisa resiko

Setelah melakukan identifikasi resiko, maka tahap berikutnya adalah pengukuran resiko dengan cara melihat potensial terjadinya seberapa besar severity (kerusakan) dan probabilitas terjadinya risiko tersebut. Penentuan probabilitas terjadinya suatu event sangatlah subyektif dan lebih berdasarkan nalar dan pengalaman. Beberapa risiko memang mudah untuk diukur, namun sangatlah sulit untuk memastikan probabilitas suatu kejadian yang sangat jarang terjadi. Sehingga, pada tahap ini sangtalah penting untuk menentukan dugaan yang terbaik supaya nantinya kita dapat memprioritaskan dengan baik dalam implementasi perencanaan manajemen risiko. Kesulitan dalam pengukuran risiko adalah menentukan kemungkinan terjadi suatu risiko karena informasi statistik tidak selalu tersedia untuk beberapa risiko tertentu. Selain itu, mengevaluasi dampak severity (kerusakan) seringkali cukup sulit untuk asset immateriil. Dampak adalah efek biaya, waktu dan kualitas yang dihasilkan suatu resiko.

Dampak	Biaya	Waktu	Kualitas
Sangat rendah	Dana mencukupi	Agak menyimpang dari target	Kualitas agak berkurang namun masih dapat digunakan
Rendah	Membutuhkan dana tambahan	Agak menyimpang dari target	Gagal untuk memenuhi janji pada stakeholder
Sedang	Membutuhkan dana tambahan	Penundaan berdampak terhadap stakeholder	Beberapa fungsi tidak dapat dimanfaatkan
Tinggi	Membutuhkan dana tambahan yang signifikan	Gagal memenuhi deadline	Gagal untuk memenuhi kebutuhan banyak stakeholder
Sangat tinggi	Membutuhkan dana tambahan yang substansial	Penundaan merusak proyek	Proyek tidak efektif dan tidak berguna

Setelah mengetahui probabilitas dan dampak dari suatu resiko, maka kita dapat mengetahui potensi suatu resiko. Untuk mengukur bobot resiko kita dapat menggunakan skala dari 1 – 5 sebagai berikut seperti yang disarankan oleh JISC InfoNet:

Skala	Probabilitas	Dampak
Sangat rendah	Hampir tidak mungkin terjadi	Dampak kecil
Rendah	Kadang terjadi	Dampak kecill pada biaya, waktu dan kualitas
Sedang	Mungkin tidak terjadi	Dampak sedang pada biaya, waktu dan kualitas
Tinggi	Sangat mungkin terjadi	Dampak substansial pada biaya, waktu dan kualitas
Sangat tinggi	Hampir pasti terjadi	Mengancam kesuksesan proyek

Setelah resiko yang dapat mempengaruhi pengembangan teridentifikasi maka diperlukan cara untuk menentukan tingkat kepentingan dari masing-masing resiko. Beberapa resiko secara relatif tidak terlalu fatal (misal resiko keterlambatan penyerahan dokumentasi) sedangkan beberapa resiko lainnya berdampak besar.  (misal resiko keterlambatan penyerahan software).  Beberapa resiko sering terjadi (salah satu anggota tim sakit sehingga tidak bisa bekerja selama beberapa hari). Sementara itu resiko lainnya jarang terjadi (misal kerusakan perangkat keras yang dapat mengakibatkan sebagian program hilang).

Probabilitas terjadinya resiko sering disebut dengan risk likelihood; sedangkan dampak yang akan terjadi jika resiko tersebut terjadi dikenal dengan risk impact dan tingkat kepentingan resiko disebut dengan risk value atau risk exposure. Risk value dapat dihitung dengan formula :

Risk exposure = risk likelihood x risk impact

Idealnya risk impact diestimasi dalam batas moneter dan likelihood dievaluasi sebagai sebuah probabilitas. Dalam hal ini risk exposure akan menyatakan besarnya biaya yang diperlukan berdasarkan perhitungan analisis biaya manfaat. Risk exposure untuk berbagai resiko dapat dibandingkan antara satu dengan lainnya untuk mengetahui tingkat kepentingan masing-masing resiko.

Akan tetapi, estimasi biaya dan probabilitas tersebut sulit dihitung, subyektif, menghabiskan waktu dan biaya. Untuk mengatasi hal ini maka diperlukan beberapa pengukuran yang kuantitatif untuk menilai risk likelihood dan risk impact, karena tanpa ini sulit untuk membandingkan atau meranking resiko tersebut untuk berbagai keperluan. Akan tetapi, usaha yang dilakukan untuk medapatkan sebuah estimasi kuantitatif yang baik akan menghasilkan pemahaman yang mendalam dan bermanfaat atas terjadinya suatu permasalahan.

Beberapa manajer resiko mempergunakan sebuah metode penilaian yang sederhana untuk menghasilkan ukuran yang kuantitatif pada saat mengevaluasi masing-masing resiko. Beberapa manajer memberikan kategori pada likelihood dan impact dengan high, medium atau low. Akan tetapi bentuk ini tidak memungkinkan untuk menghitung risk exposure. Sebuah pendekatan yang lebih baik dan populer adalah memberikan skor pada likelihood dan impact dengan skala tertentu misal 1-10. Jika suatu resiko kemungkinan besar akan terjadi diberi skor 10, sedangkan jika kecil jika kemungkinan terjadinya kecil maka akan diberi nilai 1.

Penilaian likelihood dan impact dengan skala 1-10 relatif mudah, akan tetapi kebanyakan manajer resiko akan berusaha untuk memberikan skor yang lebih bermakna, misal skor likelihood 8 akan dipertimbangkan dua kali likelihood dengan skor 4.

Hasil pengukuran impact, dapat diukur dengan skor yang serupa, harus dimasukkan pada perhitungan total risk dari proyek tersebut. Untuk itu harus melibatkan beberapa biaya potensial seperti :

• Biaya yang diakibatkan keterlambatan penyerahan atas jadwal yang sudah ditentukan
• Biaya yang berlebihan dikarenakan harus menambah sumber daya atau dikarenakan mempergunakan sumber daya yang lebih mahal

2. Prioritas resiko

Pengelolaan resiko melibatkan penggunaan dua strategi:

·         Risk exposure dapat dikurangi dengan mengurangi likehood atau impact

·        Pembuatan rencana kontingensi berkaitan dengan kemungkinan resiko yang akan terjadi.

Sebarang usaha untuk mengurangi sebuah risk exposure atau untuk melakukan sebuah rencana kontigensi akan berhubungan dengan biaya yang berkaitan dengan usaha tersebut. Merupakan hal yang penting untuk menjamin bahwa usaha ini dilaksanakan dengan cara yang paling efektif dan diperlukan cara untuk memprioritaskan resiko sehingga usaha yang lebih penting dapat menerima perhatian yang lebih besar.

Estimasi nilai likehood dan impact dari masing-masing usaha tersebut akan menentukan nilai risk exposure. Setelah risk exposure dapat dihitung maka resiko dapat diberi prioritas high, medium atau low sesuai dengan besar kecilnya nilai risk exposure.

Risk exposure yang berdasarkan pada metode penilaian perlu diberikan beberapa perhatian. Hasil evaluasi pada tabel 1, contoh, tidak memperlihatkan resiko R5 adalah dua kali lebih penting dibandingkan R6. Pada kasus ini, kita tidak bias mengintepretasikan nilai risk exposure secara kuantitatif disebabkan nilai tersebut didasarkan pada metode penilaian yang non-cardinal. Pada kasus kedua, nilai exposure yang terlalu berjauhan akan mampu untuk membedakan antara resiko tersebut. Akan tetapi risk exposure akan memungkinkan kita untuk memperoleh suatu ranking sesuai dengan kepentingannya. Pertimbangkan resiko pada tabel 1, R3 dan R4 merupakan resiko yang paling penting dan kita dapat mengklasifikasikannya dengan high risk. Tingkat kepentingan yang berbeda dapat membedakan antara skor exposure satu dan dua ini dengan exposure tertinggi berikutnya yaitu R2. R2 dan R5 mempunyai skor yang hampir sama dan dapat dikelompokkan pada resiko dengan prioritas medium. Dua resiko lainnya, R1 dan R6 mempunyai nilai exposure yang rendah sehingga dapat dikelompokan pada prioritas rendah.

Dalam kenyataannya, secara umum ada beberapa factor lain, selain nilai risk exposure, yang harus diperhitungkan pada saat menentukan prioritas resiko.

Kepercayaan terhadap penilaian resiko

Beberapa penilaian risk exposure relative kurang. Untuk diperlukan investigasi lebih lanjut sebelum tindakan diambil.

Penggabungan resiko

Beberapa resiko saling bergantung dengan lainnya. Dalam hal ini maka beberapa resiko tersebut perlu dianggap sebagai satu resiko.

Jumlah resiko

Perlu batas jumlah resiko yang dapat dipertimbangkan secara efektif dan dapat diambil tindakannya oleh seorang manajer proyek. Untuk itu perlu dibatasi ukuran daftar prioritas.

Biaya tindakan

Beberapa resiko, yang suatu saat dapat dikenali, dapat dikurangi atau dicegah segera dengan biaya atau usaha yang sedikit tanpa menganggap nilai resikonya. Untuk resiko lainnya perlu dilakukan perbandingan antara biaya yang diperlukan dengan benefit yang diperoleh dengan mengurangi resiko tersebut. Satu metode untuk melaksanakan perhitungan ini adalah dengan menghitung risk reduction leverage (RRL) dengan mempergunakan persamaan sebagai berikut:

RRL = RE_before – RE_after

Risk reduction cost

RE_before adalah nilai risk exposure semula, RE_after adalah nilai risk exposure yang diharapkan setelah diambil tindakan dan risk education cost adalah biaya untuk implementasi tindakan pengurangan resiko. Risk reduction cost harus dinyatakan dengan unit yang sama dengan nilai resiko yaitu nilai moneter yang diperlukan atau dengan nilai skor. Jika nilai yang diharapkan ternyata lebih besar maka RRL yang lebih besar memperlihatkan bahwa kita perlu berharap untuk meningkatkan rencana pengurangan resiko disebabkan reduksi risk exposure yang diharapkan lebih besar dibandingkan dengan biaya rencana.

3.  Pengelolaan resiko

Jenis-jenis cara mengelola resiko :

1. Risk Avoidance

Yaitu memutuskan untuk tidak melakukan aktivitas yang mengandung resiko sama sekali. Dalam memutuskan untuk melakukannya, maka harus dipertimbangkan potensial keuntungan dan potensial kerugian yang dihasilkan oleh suatu aktivita

1.  Risk Reduction

Risk reduction atau disebut juga risk mitigation yaitu merupakan metode yang mengurangi kemungkinan terjadinya suatu resiko ataupun mengurangi dampak kerusakan yang dihasilkan oleh suatu resiKo.

2.  Risk Transfer

Yaitu memindahkan resiko pada pihak lain, umumnya melalui suatu kontrak (asuransi) maupun hedging.

3. Risk Deferral

Dampak suatu resiko tidak selalu konstan. Risk deferral meliputi menunda aspek suatu proyek hingga saat dimana probabilitas terjadinya resiko tersebut kecil.

4.  Risk Retention

Walaupun resiko tertentu dapat dihilangkan dengan cara mengurangi maupun mentransfernya, namun beberapa resiko harus tetap diterima sebagai bagian penting dari aktivitas.

Penanganan resiko:

1. High probability, high impact: resiko jenis ini umumnya dihindari ataupun ditransfer.
2. Low probability, high impact: respon paling tepat untuk tipe resiko ini adalah dihindari. Dan jika masih terjadi, maka lakukan mitigasi resiko serta kembangkan contingency plan.
3. High probability, low impact: mitigasi resiko dan kembangkan contingency plan.
4. Low probability, low impact: efek dari resiko ini dapat dikurangi, namun biayanya dapat saja melebihi dampak yang dihasilkan. Dalam kasus ini mungkin lebih baik untuk menerima efek dari resiko tersebut.

Contigency plan

Untuk resiko yang mungkin terjadi maka perlu dipersiapkan contingency plan seandainya benar-benar terjadi. Contigency plan haruslah sesuai dengan proposional terhadap dampak resiko tersebut. Dalam banyak kasus seringkali lebih efisien untuk mengalokasikan sejumlah sumber daya untuk mengurangi resiko dibandingkan mengembangkan contingency plan yang jika diimplementasikan akan lebih mahal. Namun beberapa skenario memang membutuhkan full contingency plan, tergantung pada proyeknya. Namun jangan sampai tertukar antara contingency planning dengan re-planning normal yang memang dibutuhkan karena adanya perubahan dalam proyek yang berjalan.

Tabel resiko proyek software dan strategi mengurangi resiko

Resiko	Teknik mengurangi resiko
Kegagalan pada personil	· Memperkerjakan staf yang handal · Job matching · Membangun tim ·   Mengadakan pelatihan dan peningkatan karir · Membuat jadwal lebih awal bagi personil utama
Estimasi biaya dan waktu yang tidak realistis	·   Membuat beberapa estimasi ·   Desain untuk biaya ·   Meningkatkan pengembangan ·   Merekam dan menganalisa proyek sebelumnya ·   Standarisasi metode
Mengembangkan fungsi software yang salah	·   Evaluasi proyek ditingkatkan ·   Buat metode spesifikasi yang formal ·   Survey pengguna ·   Buat prototype ·   Buat user manual lebih awal
Mengembangkan antarmuka pengguna yang salah	·   Membuat prototype ·   Analisis tugas ·   Keterlibatan pengguna
Gold plating	·   Mengurangi kebutuhan ·   Membuat prototype ·   Analisis biaya manfaat ·   Desain biaya
Terlambat untuk mengubah kebutuhan	·   Mengubah prosedur kendali ·   Membatasi perubahan yang terlalu banyak ·   Meningkatkan prototype ·   Meningkatkan pengembangan (akibat perubahan)
Kegagalan pada komponen yang disuplai pihak eksternal	·   Melakukan benchmarking ·   Inspeksi ·   Spesifikasi formal ·   Kontrak perjanjian ·   Prosedur dan sertifikasi jaminan kualitas
Kegagalan menjalankan tugas eksternal	·   Prosedur jaminan kualitas ·   Desain / prototype yang kompetitif ·   Membangun tim ·   Kontrak insentif
Kegagalan kinerja real-time	·   Simulasi ·   Benchmarking ·   Prototipe ·   Tuning ·   Analisis teknis
Pengembangnya terlalu sulit secara teknis	·   Analisa teknis ·   Analisis biaya manfaat ·   Prototipe ·   Melatih dan mengembangkan staf

4.  Implementasi manajemen resiko

Setelah memilih respon yang akan digunakan untuk menangani resiko, maka saatnya untuk mengimplementasikan metode yang telah direncanakan tersebut.

1. Monitoring resiko

Mengidentifikasi, menganalisa dan merencanakan suatu resiko merupakan bagian penting dalam perencanaan suatu proyek. Namun, manajemen resiko tidaklah berhenti sampai disana saja. Praktek, pengalaman dan terjadinya kerugian akan membutuhkan suatu perubahan dalam rencana dan keputusan mengenai penanganan suatu resiko. Sangatlah penting untuk selalu memonitor proses dari awal mulai dari identifikasi resiko dan pengukuran resiko untuk mengetahui keefektifitas respon yang telah dipilih dan untuk mengidentifikasi adanya resiko yang baru maupun berubah. Sehingga, ketika suatu resiko terjadi maka respon yang dipilih akan sesuai dan diimplementasikan secara efektif.

Paradigma dan Prinsip Interaksi

pertemuan ke 2

Paradigma dan Prinsip Interaksi

Prinsip Utama Design Interface atau Antarmuka

Pada pembahasan kelas saya pada pertemuan pertama tentang prinsip utama IMK dan pengertian dari IMK itu sendiri hingga faktor – faktor pendewasaan dari IMK itu sendiri silahkan dicek ya,, ada slide yang saya sediakan..

IMK pertemuan 1

Metodologi Pengembangan Software berbasis SDLC (Software Development Life Cycle)

SDLC (Software Development Life Cycle) merupakan sebuah siklus hidup pengembangan perangkat lunak yang terdiri dari beberapa tahapan-tahapan penting dalam membangun perangkat lunak yang dilihat dari segi pengembangannya. Dengan siklus SDLC, proses membangun sistem dibagi menjadi beberapa langkah dan pada sistem yang besar, masing-masing langkah dikerjakan oleh tim yang berbeda. SDLC tidak hanya penting untuk proses produksi software, tetapi juga sangat penting untuk proses maintenance software itu sendiri,

Terdapat 4 metodologi penting dalam pengembangan software berbasis SDLC yaitu

A. WATERFALL

“Classic Life Cycle” atau model Waterfall merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Roger S. Pressman memecah model ini menjadi 6 tahapan, yaitu :

1. System / Information Engineering and Modeling.
Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.

2. Software Requirements Analysis.
Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.

3. Design
Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.

4. Coding
Desain yang telah dibuat kemudian diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.

5. Testing / Verification
Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.

6. Maintenance
Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

Berikut adalah bagan dari Waterfall Model :

Konsep SDLC – Waterfall

Keuntungan menggunakan teknik waterfall:

• Proses menjadi teratur
• Estimasi proses menjadi lebih baik
• Jadwal menjadi lebih menentu

Kelemahan menggunakan teknik waterfall:

• Sifatnya kaku, sehingga susah melakukan perubahan di tengah proses
• Membutuhkan daftar kebutuhan yang lengkap di awal, tapi jarang konsumen bisa memberikan kebutuhan secara lengkap diawal

B. PROTOTYPE

Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau komponen-komponen perangkat lunak akan bekerja dalam lingkungannya sebelum tahapan konstruksi aktual dilakukan (Howard, 1997). Beberapa model prototype adalah sebagai berikut :

• Reusable prototype : Prototype yang akan ditransformasikan menjadi produk final.
• Throwaway prototype : Prototype yang akan dibuang begitu selesai menjalankan maksudnya.
• Input/output prototype : Prototype yang terbatas pada antar muka pengguna (user interface).
• Processing prototype : Prototype yang meliputi perawatan file dasar dan proses-proses transaksi
• System prototype : Prototype yang berupa model lengkap dari perangkat lunak.

Proses pada model prototyping adalah sebagai berikut:

1. pengumpulan kebutuhan
developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan

2. perancangan
perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.

3. Evaluasi prototype
klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan.

Skema dari prototype secara umum adalah sebagai berikut :

Konsep SDLC – Prototype

Pendekatan prototyping memiliki beberapa keuntungan yaitu:

• Pemodelan membutuhkan partisipasi aktif dari end-user. Hal ini akan meningkatkan sikap dan dukungan pengguna untuk pengerjaan proyek. Sikap moral pengguna akan meningkat karena system berhubungan nyata dengan mereka.
• Perubahan dan iterasi merupakan konsekuensi alami dari pengembangan system-sehingga end user memiliki keinginan untuk merubah pola pikirnya. Prototyping lebih baik menempatkan situasi alamiah ini karena mengasumsikan perubahan model melalui iterasi kedalam system yang dibutuhkan.
• Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat, merasakan, dan mengalaminya.
• Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini
• Prototyping dapat meningkatkan kreatifitas karena membolehkan adanya feedback dari end user. Hal ini akan memberikan solusi yang lebih baik.
• Prototyping mempercepat beberapa fase hidup dari programmer.

Pendekatan prototyping memiliki beberapa kekurangan yaitu:

• Prototyping memungkinkan terjadinya pengembalian terhadap kode, implementasi, dan perbaikan siklus hidup yang dugunakan untuk mendominasi sistem informasi.
• Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya dapat memecahkan masalah yang salah dan memberi kesempatan sebagai sistem pengembangan konvensional.
• Prototyping dapat mengurangi kreatifitas perancangan.

C. RAD (Rapid Application Development)

Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction.

Kelemahan dalam model RAD yaitu:

• Model RAD membutuhkan sumber daya yang besar, terutama untuk proyek dengan skala besar.
• proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
• sistem yang tidak bisa dimodularisasi tidak cocok untuk model RAD
• resiko teknis yang tinggi juga kurang cocok untuk model RAD

Skema dari Model RAD adalah sebagai berikut:

Konsep SDLC – RAD

Secara umum fase-fase pada RAD adalah sebagai berikut

• Bussines modeling
• Data modeling
• Proses modeling
• Application generation : RAD mengasumsikan pemakaian teknik 4G (generasi keempat). Selain menciptakan Perangkat Lunak dengan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program atau menciptakan komponen yang bisa dipakai lagi.
• Testing and Turn Over : karena menekankan pada reusability, banyak komponen program yang telah diuji sehingga mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji dan semua interface harus dilatih secara penuh.

D. AGILE SOFTWARE DEVELOPMENT

Agile merupakan adalah jenis pegembangan sistem jangka pendek yang memerlukan adaptasi cepat dan pengembang terhadap perubahan dalam bentuk apapun. Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana. Agile juga dapat diartikan sebagai sekelompok metodologi pengembangan software yang didasarkan pada prinsip-prinsip yang sama atau pengembangan system jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun. Menurut Agile Alliance, ada 12 prinsip yang mendorong keberhasilan dalam penerapan Agile Software Development, yaitu:

• Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus.
• Menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
• Penyerahan hasil/software dalam hitungan waktu beberapa minggu sampai beberapa bulan.
• Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan.
• Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.
• Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien
• Software yang berfungsi adalah ukuran utama dari kemajuan proyek
• Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan
• Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile
• Kesederhanaan penting
• Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri
• Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.

Kelebihan dari Agile Software Development yaitu:

• Meningkatkan kepuasan kepada klien
• Pembangunan system dibuat lebih cepat
• Mengurangi resiko kegagalan implementasi software dari segi non-teknis
• Jika pada saat pembangunan system terjadi kegagalan,kerugian dar segi materi relative kecil.

Berikut beberapa model proses yang terdapat pada model Proses Agile :

a. Extreme Programming (XP)

Dipublikasikan oleh Kenn Beck pada tahun 1999 dengan menggunakan pendekatan OOP (Object Oriented Programming), terdiri dari aktivitas perencanaan, aktivitas desain, aktivitas pengkodean dan aktivitas pengujian. Skemanya adalah sebagai berikut :

Konsep Agile – Extreme Programming (XP)

b. Adaptive Software Development (ASD)

Di usulkan oleh Jim Highsmith sebagai tehnik untuk membangun software dan sistem yang komplek, filosofi dari ASD adalah kolaborasi manusia dan tim yang mengatur diri sendiri, aktivitas pada proses ASD adalah speculation, collaboration & learning. Skemanya adalah sebagai berikut:

Konsep Agile – Adaptive Software Development (ASD)

c. Dinamic System Development Method

Menyajikan kerangka kerja (framework) untuk membangun dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototyping yang incremental dalam lingkungan yang terkondisikan. Aktifitas pada DInamic System development method adalah Feasibility Study, Business Study, Functional Model Iteration, Desain & Build iteration, Implementation, skema dari model ini adalah sebagai berikut :

Konsep Agile – Dinamic System Development

d. SCRUM

Diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990-an, Pengembangan berikutnya dilakukan oleh Schwaber dan Beedle, Scrum memiliki prinsip:

• ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan emberdayakan satu sama lain
• proses dapat beradaptasi terhadap perubahan teknis dan bisnis
• proses menghasilkan beberapa software increment
• pembangunan dan orang yang membangun dibagi dalam tim yang kecil
• dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun
• proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

pada metode SCRUM terdapat aktivitas yang dijalankan sebagai berikut: Backlog, Sprints, Scrum Meetings, Demo. Skema dari SCRUM adalah sebagai berikut:

Konsep Agile – SCRUM

e. Agile Modelling

AM adalah suatu metodologi yang praktis untuk dokumentasi dan pemodelan sistem software. AM adalah kumpulan nilai-nilai, prinsip dan praktek-praktek untuk memodelkan software agar dapat diaplikasian pada software development proyek secara efektif. Prinsip dalam Agile Modelling adalah sebagai berikut:

• membuat model dengan tujuan
• mengunakan multiple models
• travel light
• isi lebih penting dari pada penampilan
• memahami model dan alat yang yang digunakan untuk membuat software
• adaptasi secara lokal

MANAJEMEN KEBUTUHAN SISTEM PERANGKAT LUNAK

dalam membangun sebuah sistem perangkat lunak maka kita harus benar benar memahami kebutuhan dari sistem perangkat lunak yang akan kita bangun, ada beberapa tahapan untuk menganalisa kebutuhan dalam sebuah sistem.. ketika searchig2 saya dapat tautan yang menarik dari fakultas TI di salah satu universitas .. bisa di baca2 … monggo…

MANAJEMEN KEBUTUHAN

REQUIREMENT ENGINERING ANALIST

Overview On State Of The Art

The intention of this paper is to provide an overview on the subject of Human-Computer Interaction. The overview includes the basic definitions and terminology, a survey of existing technologies and recent advances in the field, common architectures used in the design of HCI systems which includes unimodal and multimodal configurations, and finally the applications of HCI. This paper also offers a comprehensive number of references for each concept, method, and application in the HCI.

Overview On State Of The Art