-Perencanaan Proyek Perangkat Lunak- (NPM Ganjil)

                                                 1.Observasi Pada Estimasi 

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. 

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.

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 dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Tujuan perencanaan dicapai melalui suatu proses penemuan informasi yang menunjuk ke estimasi yang dapat dipertanggungjawabkan.
 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.

MENCARI INFORMASI YANG DIBUTUHKAN UNTUK RUANG LINGKUP

Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi antara pelanggan dan pengembang serta untuk memulai proses komunikasi adalah dengan melakukan pertemuan atau wawancara pendahuluan. Gause & weinberg mengusulkan bahwa analis harus memulai dengan mengajukan pertanyaan-pertanyaan bebas konteks, yaitu serangkaian pertanyaan yang akan membawa pada pemahaman mendasar terhadap masalah, orang yang menginginkan suatu solusi, sifat solusi yang diharapkan, dan efektivitas pertemuan itu. Beberapa pertanyaan bebas konteks pada pelanggan yang meliputi tujuan keseluruhan, serta keuntungan :
o Siapa di belakang permintaan kerja ini?
o Siapa yang akan memakai solusi ini?
o Apakah yang akan menjadi keutungan ekonomi dari sebuah solusi yang sukses? o Adakah sumberdaya lain bagi solusi ini?

Beberapa contoh pertanyaan yang memungkinkan analis untuk memahami masalah lebih baik :
o Bagaimanakah anda menandai output yang baik yang akan dimunculkan oleh sebuah solui yang baik?
o Masalah apa yang akan dituju oleh solusi ini?
o Dapatkah anda memperlihatkan atau menggambarkan lingkungan di mana solusi akan dipakai?
o Adakah batasan atau isu kinerja khusus yang akan mempengaruhi cara pendekatan terhadap solusi?

Beberapa pertanyaan yang berfokus pada efektivitas pertemuan :
o Apakah anda orang yang tepat untuk menjawab pertanyaan ini? Apakah anda resmi?
o Apakah pertanyaan saya relevan dengan problem yang anda punyai?
o Apakah saya terlalu banyak pertanyaan?
o Apakah ada orang lain yang dapat menyedikan informasi tambahan?
o Adakah sesuatu yang lain yang dapat saya tanyakan kepada anda?

Bagian Question dan Answer hanya akan digunakan untuk pertemuan pertama yang kemudian diganti dengan format pertemuan yang mengkombinasikan elemen-elemen penyelesaian masalah, negoisasi, dan spesifikasi. Sejumlah peneliti lepas mengembangkan pedekatan yang berorientasi pada tim terhadap pengumpulan kebutuhan yang dapat deiterapkan untuk membangun ruang lingkup sebuah proyek, yang disebut teknik spesifikasi aplikasi yang teraplikasi (FAST) SUMBER DAYA

Mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak yang meliputi manusia, komponen perangkat lunak, dan peranti perangkat keras/perangkat lunak.
Piramida di atas memperlihatkan sumber daya pengembangan sebagai sebuah piramid. Peranti perangkat keras dan perangkat lunak berada pada fondasi dari piramida di atas dan menyediakan infrastruktur untuk mendukung usaha pengembangan(lingkungan pengembang).
Dalam tingkat yang lebih tinggi terdapat komponen perangkat lunak reuseable – blok bangungan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat penyampaian. Dan di puncak terdapat sumber daya utama yaitu manusia. Masing-masing sumber daya ditentukan dengan empat karakteristik :
o Deskripsi sumber daya
o Statemen ketersediaan
o Waktu kronologis sumber daya diperlukan
o Durasi waktu sumber daya diaplikasikan

Sumber daya manusia
Perencanaan sumber daya manusia memulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk mnyelesaikan pengembangan. Baik posisi organisasi maupun specialty. Jumlah orang yang diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan setelah estimasi usaha pengembangan dibuat.

Sumber daya perangkat lunak reusable
Kreasi dan penggunaan kembali blok bangunan perangkat lunak yang seharusnya dikatalog menjadi referensi yang mudah, distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk integrasi yang mudah. Ada empat kategori sumber daya perangkat lunak yang harus dipertimbngkan pada saat perencanaan berlangsung, yaitu :
– Komponen off-the-self Perangkat lunak yang ada dapat diperoleh dari bagian ketiga atau telah dikembangkan secara internal untuk proyek sebelumnya.
– Komponen full-experience Spesifikasi, kode, desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan perangkat lunak yang akan dibangun pada proyek saat ini.
– Komponen partial-experience Aplikasi, kode, desain, atau data pengujiaan yang ada pada proyek yang lalu yang dihubungkan dengan perangkat lunak yang dibangun untuk proyek saat ini, tetapi akan membutuhkan modifikasi substansial.
– Komponen baru Komponen perangkat lunak yang harus dibangun oleh tim perangkat lunak khususnya adalah untuk kebutuhan proyek sekarang .
Lebih baik mengkhususkan syarat sumber daya perangkat lunak dari awal. Dengan cara ini evaluasi teknis dari semua alternatif dapat dilakukan dan akuisisi secara berkala dapat terjadi.

Sumber daya lingkungan
Lingkungan yang mendukung poyek perangkat lunak, yang disebut juga software engineering environment (SEE), menggabungkan perangkat lunak dan perangkat keras. Karena sebagian besar organisasi perangkat lunak memiliki konstituen ganda yang memerlukan akses ke SEE, maka perencana proyek harus menentukan jendela waktu yang dibutuhkan bagi perangkat keras dan perangkat lunak serta membuktikan bahwa sember-sumber daya tersebut dapat diperoleh.
Pada saat sebuah sistem berbasis komputer akan direkayasa, tim perangkat lunak mungkin membutuhkan akses ke elemen perangkat keras yang sedang dikembangkan oleh tim rekayasa yang lain.

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

5.6 TEKNIK DEKOMPOSISI

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

5.6.1 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
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 4 pendekatan yang berbeda dalam masalah pengukuran :

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 :
o Sebagai variabel untuk estimasi yang dipakai untuk mengukur masing-masing elemen perangkat lunak
o Sebagai metrik baseline yang dikumpulkan dari proyek yang lalu dan dipakai dalam hubungannya dengan variabel estimasi untuk mengembangkan proyeksi kerja dan biaya.
Expected value untuk variabel estimasi (ukuran), EV, dapat dihitung sebagai rata-rata terbobot dari estimasi optimistik (Sopt), paling sering(Sm), dan pesimistik (Spess). Contohnya :

EV=( Sopt +Sm +Spess)/6

Memberikan kepercayaan terbesar pada estimasi “yang paling mungkin” serta mengikuti distribui probabilitas beta. Sekali expected value untuk variabel estimasi ditentukan, data produktivitas LOC dan FP diaplikasikan. Setiap teknik estimasi, bagaimanapun canggihnya, masih harus tetap di cross check dengan pendekatan lainnya dan baru kemudian kaidah umum dan pengalaman dapat berlaku di sini.

MODEL PERKIRAAN EMPIRIS

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.

5.7.1 Struktur model perkiraaan
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 :
Model1 : Model COCOMO dasar menghitung usaha pengembangan perangkat lunak (dan biaya) sebagai fungsi dari ukuran program yang diekspresikan dalam baris kode yang diestimasi,
Model2 : 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.
Model3 : 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, keoputusan make-buy dibuat berdasarkan kndisi 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 

                                                2.Tujuan Perencanaan Proyek 

Tujuan Perangkat Lunak terdiri dari dua komponen utama, yaitu :
a.    Penelitian
Memungkinkan pemimpin proyek menentukan atau mendefenisikan batasan dan elemen yang diperlukan dalam pengerjaan masalah.
b.    Perkiraan
Kemampuan pemimpin proyek untuk memandang ke depan tentang tindakan tindakan yang akan diambil walaupun belum ada kepastian.

Tujuan dari Perencanaan Proyek Perangkat Lunak adalah untuk menyediakan kerangka atau
landasan yang memungkinkan manajer atau pimpinan proyek dapat membuat perkiraan tentang
sumber daya, biaya dan jadwal.

Ada beberapa hal yang harus diperhatikan dari pengerjaan perangkat lunak antara lain adalah :
1.    FUNCTION
Function merupakan fungsi dari perangkat lunak yang akan dibuat atau dikerjakan, harus dievaluasi kembali sehingga mendapat fungsi dari perangkat lunak secara rinci. Fungsi ini termasuk biaya dan jadwal perkiraan pengerjaan perangkat lunak.
2.    PERFORMANCE
Performance meliputi kendala dari pengerjaan perangkat lunak, keterbatasan memori dan ketergantungan dari mesin-mesin tertentu.
3.    INTERFACE
Interface meliputi :
–    Perangkat keras yang akan dipakai untuk mengerjakan perangkat lunak dan peralatan secara tidak langsung mengontrol perangkat lunak.
–    Perangkat lunak yang telah ada digabungkan dengan perangkat lunak yang baru.
–    Pemakai yang akan menggunakan perangkat lunak melalui terminal atau Input/Output.
–     Prosedur pemakaian perangkat lunak.
4.    REALIBILITY
Reliability merupakan keandalan perangkat lunak yang dihasilkan.

A.    PERENCANAAN SUMBER DAYA

Perencanaan Sumber Daya meliputi 3 kriteria yaitu :
1.    PERENCANAAN SUMBER DAYA MANUSIA
Manusia merupakan sumber daya yang paling utama dan sangat vital dalam pengembangan,atau pengerjaan perangkat lunak.
2.    PERENCANAAN SUMBER DAYA PERANGKAT KERAS
Sumber daya perangkat keras dapat dibedakan menjadi tiga kategori antara lain :
Sumber daya perangkat keras dapat dibedakan menjadi tiga kategori antara lain :
–    Development system, kategori ini merupakan perencanaan perangkat keras yang akandipergunakan dalam pengerjaan perangkat lunak.
–    Target machine, merupakan perangkat keras yang diperlukan dalam penerapannya.
–    Elemen perangkat keras, merupakan elemen tambahan yang diperlukan dalam pengoperasian perangkat lunak pada saat perangkat lunak dioperasikan oleh pemakai.
3.    PERENCANAAN SUMBER DAYA PERANGKAT LUNAK
Umumnya digunakan prinsip “Bootstrapping” yaitu menggunakan perangkat lunak yang telah ada untuk mengembangkan dan membangun perangkat lunak yang baru.

B.    PENGUKURAN KUALITAS PERANGKAT LUNAK
Dalam proyek perencanaan perangkat lunak yang ditekankan adalah produktivitas metrik artinya mengukur pengembangan keluaran perangkat lunak dimana hal ini merupakan hal yang paling penting dari perangkat lunak.
Perangkat lunak metrik adalah teknik pengukuran yang ada dalam pengembangan perangkat lunak.
Dalam mengukur produktivitas diperlukan data dari proyek pengembangan perangkat lunak yang telah dikerjakan sebelumnya

Adapun tujuan dari pengukuran perangkat lunak adalah :
1. Untuk menyatakan kualitas produk.
2. Untuk menilai kualitas manusia yang terlibat dalam pembuatan produk tersebut.
3. Untuk menilai keuntungan pemakai metode dan alat bantu yang baru.
4. Sebagai dasar untuk melakukan perkiraan.
5. Untuk membantu penyesuaian pemakaian alat bantu yang baru atau pelatihan tambahan.

Metoda pengukuran terdiri dari :
1.    Pengukuran Langsung
Yang dimaksud dengan Pengukuran Langsung (direct) adalah pengukuran yang dilakukan dimana langsung terlihat hasilnya.
Yang diukur dalam pengukuran langsung adalah :
•    Biaya.
•    Pengaruh.
•    Line of Code (jumlah baris perintah dalam program).
•    Kecepatan.
•    Ukuran memori.
•    kesalahan

2.    Pengukuran tidak Langsung
Dalam Pengukuran Tidak Langsung (indirect), yang diukur adalah :
–    Fungsi.
–    Kualitas.
–    Kekompleksan.
–    Effisiensi.
–    Keandalan.
–    Pemeliharaan.

C.    LINE OF CODE ( LOC )
Line Of Code dapat juga disebut Size Oriented Metric (jumlah baris perintah program yang telah ditulis).
Size oriented metric digunakan untuk mengukur perangkat lunak dan proses pengembangannya.
Rumus untuk menghitung produktivitas dan kualitas dari perangkat lunak yang telah dibuat adalah sebagai berikut :
Produktivitas = KLOC / EFFORT
Kualitas         = Kesalahan / KLOC
Dimana
Effort = Jumlah tenaga kerja yang dihasilkan per bulan.
KLOC = Jumlah baris perintah dari program yang dihasilkan dalam ribuan.
Sedangkan untuk biaya dan dokumentasi ditinjau dari produktivitasnya.

Ada lima faktor penting yang mempengaruhi produktivitas perangkat lunak antara lain adalah :
1. Manusia
Ukuran keahlian dari organisasi pengembangan.
2. Permasalahan
Kekompleksan permasalahan yang akan dikerjakan dan jumlah perubahan, kendala,
serta keperluan dalam perancangan.
3. Proses
Analisa dan perancangan atau teknik yang digunakan dalam pembahasan
pemrograman yang digunakan.
4. Produk
Keandalan dan performansi dari perangkat lunak dan perangkat keras yang digunakan.
5. Sumber daya
keberadaan alat-alat pengembangan, perangkat keras dan perangkat lunak yang ada.

D.    PENGUMPULAN DATA METRIK
Ada beberapa hal yang perlu diperhatikan dalam pengumpulan data antara lain adalah :
•    Data harus akurat.
•    Sejumlah data proyek terdahulu harus sebanyak mungkin.
•    Kriteria pengukuran harus teratur dan konsisten.
•    Harus sesuai dengan proyek yang terdahulu untuk memperkirakan proyek yang baru.

E.    PERKIRAAN PROYEK PERANGKAT LUNAK
Dalam Perkiraan Proyek Perangkat Lunak dapat ditransformasikan dengan mengikuti langkahlangkah sistimatis yang dapat digunakan dalam memperkirakan sehingga resiko dapat diperkecil.
Teknik perkiraan proyek perangkat lunak berusaha untuk menyediakan tingkat keandalan yang tinggi.
Untuk dapat mencapai perkiraan biaya dan effort yang dapat diandalkan dapat digunakan pilihan-pilihan sebagai berikut :
–    Memperkirakan waktu yang paling lama dari pengerjaan proyek.
–    Menggunakan teknik dekomposisi.
–    Mengembangkan model empiris untuk biaya dan effort dari perangkat lunak.
–    Menggunakan alat bantu yang telah tersedia.
Teknik dekomposisi adalah Teknik memecah-mecah atau membagi perkiraan proyek ke dalam bagian-bagian yang kecil, dalam pembagian ini berhubungan juga dengan tugas, biaya dan effort.

F.    PERKIRAAN LOC
Data LOC digunakan dua cara selama perkiraan proyek perangkat lunak yaitu :
1.    Variabel perkiraan yang digunakan untuk mengukur masing masing elemen dari perangkat lunak.
2.    Sebagai basis metrik yang dikumpulkan dari proyek terdahulu dan penggunaannya digabungkan dengan variabel perkiraan untuk pengembangan proyeksi dan effort.

Berdasarkan data lampau, perencana dapat memperkirakan perkiraan waktu optimis, perkiraan waktu yang mendekati (most likely), perkiraan waktu pesimis dari nilai LOC atau FP masing-masing fungsi.

Jumlah rata-rata yang diharapkan LOC atau FP dapat dihitung dengan teknik perkiraan.
Nilai yang diharapkan adalah variabel perkiraan E dihitung dari rata-rata pertimbangan dari optimis
(a), Most likely (m) dan pessimistic (b).
Dengan Rumus :
E = (a + 4m + b) / 6 

                                                         3.Ruang Lingkup Perangkat Lunak  

 

• Software requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak.
• Software design mencakup proses penentuan arsitektur, komponen, antarmuka, dan karakteristik lain dari perangkat lunak.
• Software construction berhubungan dengan detil pengembangan perangkat lunak, termasuk algoritma, pengkodean, pengujian, dan pencarian kesalahan. 
• Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.
• Software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan.
• Software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu.
• Software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak.
• Software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL.
• Software engineering process berhubungan dengan definisi, implementasi,pengukuran, pengelolaan, perubahan dan perbaikan proses RPL.
• Software quality menitikberatkan pada kualitas dan daur hidup perangkat lunak. 

                                                                4.Sumber Daya 

Mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak yang meliputi manusia, komponen perangkat lunak, dan peranti perangkat keras/perangkat lunak.
Piramida di atas memperlihatkan sumber daya pengembangan sebagai sebuah piramid. Peranti perangkat keras dan perangkat lunak berada pada fondasi dari piramida di atas dan menyediakan infrastruktur untuk mendukung usaha pengembangan(lingkungan pengembang).
Dalam tingkat yang lebih tinggi terdapat komponen perangkat lunak reuseable – blok bangungan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat penyampaian. Dan di puncak terdapat sumber daya utama yaitu manusia. Masing-masing sumber daya ditentukan dengan empat karakteristik :
o Deskripsi sumber daya
o Statemen ketersediaan
o Waktu kronologis sumber daya diperlukan
o Durasi waktu sumber daya diaplikasikan

Sumber daya manusia
Perencanaan sumber daya manusia memulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk mnyelesaikan pengembangan. Baik posisi organisasi maupun specialty. Jumlah orang yang diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan setelah estimasi usaha pengembangan dibuat.

Sumber daya perangkat lunak reusable

Kreasi dan penggunaan kembali blok bangunan perangkat lunak yang seharusnya dikatalog menjadi referensi yang mudah, distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk integrasi yang mudah. Ada empat kategori sumber daya perangkat lunak yang harus dipertimbngkan pada saat perencanaan berlangsung, yaitu :
– Komponen off-the-self Perangkat lunak yang ada dapat diperoleh dari bagian ketiga atau telah dikembangkan secara internal untuk proyek sebelumnya.
– Komponen full-experience Spesifikasi, kode, desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan perangkat lunak yang akan dibangun pada proyek saat ini.
– Komponen partial-experience Aplikasi, kode, desain, atau data pengujiaan yang ada pada proyek yang lalu yang dihubungkan dengan perangkat lunak yang dibangun untuk proyek saat ini, tetapi akan membutuhkan modifikasi substansial.
– Komponen baru Komponen perangkat lunak yang harus dibangun oleh tim perangkat lunak khususnya adalah untuk kebutuhan proyek sekarang .
Lebih baik mengkhususkan syarat sumber daya perangkat lunak dari awal. Dengan cara ini evaluasi teknis dari semua alternatif dapat dilakukan dan akuisisi secara berkala dapat terjadi.Sumber daya lingkungan

Lingkungan yang mendukung poyek perangkat lunak, yang disebut juga software engineering environment (SEE), menggabungkan perangkat lunak dan perangkat keras. Karena sebagian besar organisasi perangkat lunak memiliki konstituen ganda yang memerlukan akses ke SEE, maka perencana proyek harus menentukan jendela waktu yang dibutuhkan bagi perangkat keras dan perangkat lunak serta membuktikan bahwa sember-sumber daya tersebut dapat diperoleh.
Pada saat sebuah sistem berbasis komputer akan direkayasa, tim perangkat lunak mungkin membutuhkan akses ke elemen perangkat keras yang sedang dikembangkan oleh tim rekayasa yang lain.

                                                       5.Estimasi Proyek Perangkat Lunak           

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.

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. 

Referensi  : https://rpl07.wordpress.com/2007/06/20/perencanaan-proyek-perangkat-lunak-oleh-             mizar-5105-100-067/

Continue reading →

-Pengenalan Rekayasa Perangkat Lunak- (NPM Ganjil)

                       1. Konsep dasar Rekayasa Perangkat Lunak (Software Engineering)

Software engineering didefinisikan oleh Fritz Bauer sebagai: penerapan dan penggunaan prinsip-prinsip engineering yang baik dalam rangka menghasilkan software yang ekonomis, reliable, dan bekerja secara efisien pada komputer sungguhan. Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.

Sementara itu IEEE mendefinisikan software engineering sebagai: Aplikasi yang sistematis, tertata, mampu untuk dikembangkan, dioperasikan, dirawat dan diperbaiki, itulah sebuah aplikasi software engenering.dan mempelajarinya

Komponen Software Engenering :

Komponen adalah pokok bahasan yang sangat menarik jika kita membicarakan masalah reuse. Membangun software yang bersifatreusable akan sangat sulit dikarenakan desain komponen yang tidak baik. Hal ini dapat mengakibatkan komponen yang satu dengan yang lain sulit untuk dipisahkan. Di dalam membangun dan memelihara komponen memiliki hubungan external atau ketergantungan antar komponen dibutuhkan kejelasan pengertian dari dan antar komponen. Suatu komponen dapat saja (komponen dependence). Untuk itu diperlukan sebuah tools yang dapat melihat komponen dependence.

Metode software engineering memberikan tehnik-tehnik bagaimana membentuk software. Metode ini terdiri dari serangkaian tugas:

§  Perencanaan & estimasi proyek

§  Analisis kebutuhan sistem dan software

§  Desain struktur data

§  Arsitektur program dan prosedur algoritma

§  Coding

§  Testing dan pemeliharaan

 Peralatan Software Engineering

Peralatan software engineering memberikan dukungan atau semiautomasi untuk metode. Contohnya :

§  CASE (Case Aided Software Engineering), yaitu suatu software yang menggabungkan software, hard­ware, dan database software engineering untuk menghasilkan suatu lingkungan software engineering.

§  Database Software Engineering, adalah sebuah struktur data yang berisi informasi penting tentang analisis, desain, kode dan testing.

§  Analogi dengan CASE pada hardware adalah : CAD, CAM, CAE

Prosedur Software Engineering

Terdiri dari :

§  urut-urutan di mana metode tersebut diterapkan

§  dokumen

§  laporan-laporan

§  formulir-formulir yang diperlukan

§  mengontrol kualitas software

§  mengkoordinasi perubahan yang terjadi pada software

                                2.Tanggung Jawab Profesional dan Etika

   Setiap profesi harus memiliki sebuah kode etik (etika) yang digunakan untuk panduan dalam menjalankan aktivitas pekerjaan mereka agar sesuai dengan tujuan profesi yang sebenarnya dan hasilnya bisa berguna oleh orang lain serta tidak menimbulkan mudharat (kerugian) bagi orang sekitarnya.

Menurut Donald Gotterbarn Etika rekayasa perangkat lunak dapat didekati dari tiga arah.
Pertama, Menggambarkan aktivitas sofware engineer membuat pilihan praktis lain yang mempengaruhi orang dalam cara yang signifikan.
Kedua, Digunakan untuk menggambarkan kumpulan prinsip-prinsip,
pedoman, atau imperatif etis yang membimbing atau tindakan legislatif.
ketiga, Dapat digunakan
untuk nama sebuah disiplin ilmu yang mempelajari etika hubungan antara dua indra lain.


Ada berbagai nama yang terlibat dalam pengembangan Software, seperti analis sistem informasi, bagi mereka yang terlibat dalam pengembangan perangkat lunak profesional. Terlepas dari judul yang digunakan, fokus perangkat lunak kegiatan rekayasa terutama pada kecukupan teknis produk yang dikembangkan. Tetapi fakta bahwa kira-kira satu milyar orang tergantung pada sistem perangkat lunak untuk secara efektif melakukan 
kehidupan sehari-hari mereka (Reed, 2000) telah menyebabkan banyak di komputer untuk memberikan lebih banyak perhatian pada nonteknis aspek dan bergulat dengan dampak etis keputusan sehari-hari mereka dan nilai-nilai yang tertanam di dalamnya. 

Hubungan antara komputer dan etika dapat digambarkan sebagai terjadi ketika manusia membuat keputusan tentang komputer, dan mereka keputusan yang mempengaruhi kehidupan masyarakat. Nilai-nilai kemanusiaan yang terkait dengan keputusan teknis dengan cara ini. 

Kegiatan Software Engineering Etika Profesional terjadi ketika suatu keputusan 
dibuat oleh komputer profesional selama desain, pengembangan, konstruksi dan 
pemeliharaan artefak komputasi mempengaruhi orang lain. Keputusan ini dapat dilakukan oleh individu, tim, manajemen, atau profesi. Keputusan rekayasa perangkat lunak bagaimana merancang pelepasan kantong udara akan mempengaruhi kehidupan orang lain. 
Keputusan ini juga dipandu oleh keputusan etis tentang nilai-nilai kemanusiaan. Barry Boehm (1981) memulai bekerja pada rekayasa perangkat lunak ekonomi dengan sebuah anekdot tentang bagaimana Kegagalan untuk mempertimbangkan nilai-nilai manusia mempengaruhi pengembangan perangkat lunak untuk sekolah tinggi 
sistem kehadiran. Karyanya pada proyek ini membuatnya melihat bahwa insinyur perangkat lunak 
"... Kesempatan untuk membuat dampak positif yang signifikan pada masyarakat, hanya dengan menjadi 
lebih sensitif terhadap manusia dalam jangka panjang hubungan implikasi dari pekerjaan kita dan menggabungkan 
kepekaan ini ke dalam perangkat lunak kami desain dan produk. "(Boehm, 1981)

Software Engineering Prinsip Etis 
Aktivitas etika terlibat dalam keputusan-keputusan teknis harus didasarkan pada pemahaman dampak dari keputusan tersebut. Seringkali keputusan dibuat sementara hanya melihat masalah teknis, tetapi keputusan itu dampak lain dalam cara-cara positif dan negatif. Baik keputusan rekayasa perangkat lunak memerlukan kesadaran dan pertimbangan yang cermat baik dari teknis dan dimensi etika keputusan teknis harus sadar dipandu oleh nilai-nilai. Tidak adanya kesadaran dari hubungan antara 
teknologi dan nilai-nilai berarti bahwa nilai-nilai yang terkait dengan teknologi serampangan. 

Profesi menggambarkan nilai-nilai ini dalam Kode Etik, Kode Etik dan Kode Practice. Kode-kode ini melayani berbagai fungsi yang terkait dengan suatu profesi termasuk menyediakan panduan bagi praktisi pilihan etis dan mendidik praktisi dan publik tentang standar etika profesi.

Kode etik adalah pernyataan tentang interaksi teknologi dan nilai-nilai. Mereka 
juga dimaksudkan untuk memastikan bahwa interaksi ini tidak sembarangan. Beberapa kode, seperti Australian Computer Society Kode Etik membawa berat badan hukum untuk menjamin terstruktur interaksi, sementara kode-kode lain, seperti Rekayasa Perangkat Lunak Kode Etik dan Praktek profesional, bergantung pada tekanan normatif. Tujuan dari semua kode ini adalah untuk memastikan bahwa kegiatan berlatih profesional sebagai individu, tim, manajemen, atau organisasi profesional, memajukan dan melindungi nilai-nilai kemanusiaan daripada melakukan kerusakan mereka. 

Tata-tertib Software Engineering Etika 
Disiplin studi etika rekayasa perangkat lunak interaksi etika prinsip-prinsip dan teknologi untuk memeriksa cara-cara ini yang mempengaruhi interaksi ini masyarakat, para warga negara, dan produk rekayasa perangkat lunak. Sebagai sebuah disiplin, perangkat lunak menggambarkan etika enjiniring, memurnikan dan lebih mengeksplorasi hubungan antara prinsip dan praktek teknis berkembang. 

Perkembangan Etika Software Engineering 
Software engineering adalah profesi yang muncul, yang sadar diri dari pengaruhnya terhadap masyarakat dan kewajiban yang dihasilkan. Kenyataan bahwa komputasi memiliki dampak yang signifikan harian pada kehidupan milyaran orang telah menyebabkan banyak dalam komputasi untuk bergulat dengan etika mereka kewajiban. Pada 1990-an banyak organisasi telah ditinjau ulang kode perilaku mereka atau 
kode etik dan direvisi mereka dengan cara yang lebih jelas menyatakan kewajiban etis untuk masyarakat luas. Sebagai contoh, Association for Computing Machinery (ACM), yang Australian Computer Society, British Computer Society (BCS), IEEE Computer 
Society (IEEE-CS), dan Selandia Baru Computer Society memiliki semua halus Codes mereka Etik. Sebuah usaha berbasis luas untuk professional rekayasa perangkat lunak dimulai oleh IEEE Computer Society, dan kemudian bergabung oleh ACM (Gotterbarn a, 1996). 
Awal tujuan organisasi ini adalah untuk: 
1. Adopsi Standar Definisi 
2. Define Diperlukan Body of Knowledge and Recommended Practices (dalam listrik 
teknik, misalnya, teori elektromagnetik adalah bagian dari tubuh pengetahuan 
sementara Listrik Nasional Keselamatan Kode adalah praktek yang disarankan.) 
3. Menetapkan Standar Etika 
4. Define Pendidikan Kurikulum untuk (a) mahasiswa, (b) lulus (MS), dan (c) 
melanjutkan pendidikan (untuk pelatihan ulang dan migrasi). (Gotterbarn b, 1996)

Tujuan tersebut konsisten dengan tujuan profesi lain. Salah satu elemen kunci 
dalam setiap profesi adalah pengakuan dari etika dan tanggung jawab moral kepada para klien, untuk masyarakat, dan profesi itu sendiri. Banyak profesi, seperti teknik dan obat, menyatakan tanggung jawab tersebut secara terbuka dalam kode etik dan kemudian membutuhkan pelatihan etika profesional dalam rangka untuk memasuki profesi. Sebagai contoh, IEEE-CS Sertifikasi sebagai Rekayasa Perangkat Lunak Profesional memerlukan kepatuhan pada Perangkat Lunak Engineering Kode Etik dan Profesional Practice.

Namun, minat ini etika tidak selalu merupakan unsur utama rekayasa perangkat lunak. 
Rekayasa perangkat lunak telah ditetapkan dirinya sebagai "pembentukan dan penggunaan suara prinsip-prinsip rekayasa [metode] dalam rangka untuk memperoleh perangkat lunak secara ekonomis yang dapat diandalkan dan bekerja pada mesin yang nyata. "(Bauer, 1972) tidak secara eksplisit menunjukkan keberadaan 
isu-isu etis. Standar IEEE 610,12 definisi juga memiliki kekosongan yang sama. 
"Software Engineering: 
(1) Permohonan yang sistematis, disiplin, pendekatan kuantitatif 
pembangunan, operasi, dan pemeliharaan perangkat lunak, yaitu penerapan 
rekayasa perangkat lunak. 
(2) Studi pendekatan seperti pada (1). "

Sebagai disiplin matang menuju profesi dan dampak dari produk yang diperbesar, deskripsi dari disiplin mulai secara eksplisit menyebutkan tempat-tempat di mana isu-isu etis mungkin muncul. Ketika rekayasa perangkat lunak digambarkan sebagai suatu disiplin yang "memerlukan pemahaman dan penerapan prinsip-prinsip teknik, keterampilan desain, manajemen yang baik praktek, ilmu komputer, dan matematika formalisme. (BCS, 1989) ", beberapa daerah keprihatinan etis seperti praktek manajemen yang baik mulai muncul. Awal ini deskripsi tidak memberikan keunggulan untuk isu-isu etis. Definisi Bauer tidak menyebut kepuasan dari kebutuhan klien atau memenuhi standar profesi, namun ini adalah tersirat dalam istilah-istilah seperti "diandalkan", "ekonomis" dan "bekerja". The BCS definisi lengkap 
tidak termasuk beberapa referensi insinyur perangkat lunak tanggung jawab kepada profesi. 

Sebagai dampak dari rekayasa perangkat lunak telah diperluas sehingga memiliki pengakuan atas tanggung jawab dari insinyur perangkat lunak.

Tanggung jawab ini dirumuskan dalam Rekayasa Perangkat Lunak Kode Etik dan 
Perilaku Profesional (SECODE 1999) adalah diringkas sebagai: 
Sofware Engineer akan berkomitmen untuk membuat analisis, spesifikasi, desain, pengembangan, pengujian dan pemeliharaan perangkat lunak yang menguntungkan dan 
dihormati profesi. Sesuai dengan komitmen mereka terhadap kesehatan, keselamatan 
dan kesejahteraan masyarakat, perangkat lunak insinyur harus mematuhi Delapanberikut 
Prinsip: 
1 PUBLIC - Software insinyur harus bertindak secara konsisten dengan kepentingan publik. 
2 KLIEN DAN MAJIKAN - Software insinyur harus bertindak dengan cara yang ada di 
kepentingan terbaik klien atau majikan mereka dan yang konsisten dengan publik 
bunga. 
3 PRODUK - Software insinyur harus memastikan bahwa produk mereka dan yang terkait 
modifikasi memenuhi standar profesional tertinggi mungkin. 
4 JUDGMENT - Software insinyur harus menjaga integritas dan kemandirian dalam 
penilaian profesional mereka. 
5 MANAJEMEN - Software engineering manajer dan pemimpin harus berlangganan ke 
dan mempromosikan pendekatan etis dengan pengelolaan dan pengembangan perangkat lunak 
pemeliharaan. 
6 PROFESI - Software insinyur memajukan integritas dan reputasi 
profesi konsisten dengan kepentingan publik. 
7 KOLEGA - Software engineer harus bersikap adil dan mendukung mereka 
rekan. 
8 DIRI - Software insinyur akan berpartisipasi dalam mengenai belajar sepanjang hayat 
praktek profesi mereka dan mempromosikan pendekatan etis praktek 
profesi.

Seperangkat prinsip ini, dikembangkan dan direview oleh insinyur perangkat lunak dari setiap benua insinyur perangkat lunak mengungkapkan komitmen untuk tingkat perawatan profesional. Itu profesionalisasi dari setiap disiplin melibatkan kesadaran bahwa menjadi seorang profesional melibatkan lebih dari yang kaku penerapan teknologi terbaru ke artefak bahwa disiplin (Ford, 1996). Praktek kedokteran adalah lebih daripada aplikasi obat ke tubuh manusia. Dokter prihatin dengan kesejahteraan pasien mereka. Itu arsitek profesional tidak hanya menerapkan prinsip-prinsip struktural stres saat merancang sebuah bangunan namun berkaitan dengan efek desain pada orang-orang yang akan menggunakan gedung. 
Dalam profesionalisasi disiplin ada adalah: 
1) realisasi dari 
dampak pada masyarakat dari penerapan keterampilan khusus, 
2) pengetahuan oleh praktisi 
dari standar profesi dan, 
3) realisasi dari tanggung jawab yang datang dengan 
hak istimewa untuk menjadi diperbolehkan untuk menerapkan keterampilan-keterampilan.

Semacam ini realisasi dalam rekayasa perangkat lunak terlihat dalam definisi yang ditawarkan oleh Software Engineering Institute. Ini mendefinisikan software engineering sebagai "bentuk rekayasa yang menerapkan prinsip-prinsip ilmu komputer dan matematika untuk mencapai costeffective solusi untuk masalah software (Ford, 1990). "Tetapi rekayasa perangkat lunak, sebagai subset dari rekayasa, adalah menciptakan dan membangun "biaya-efektif solusi praktis masalah dalam pelayanan umat manusia "(Ford, 1990). Ford terus menunjukkan secara eksplisit bahwa 
biaya efektif tidak berarti membuat sesuatu yang berkualitas marjinal untuk meminimalkan waktu dan sumber daya, lebih tepatnya, "biaya-efektif ... berarti mendapatkan nilai yang baik bagi sumber daya yang diinvestasikan; 
nilai ini termasuk kualitas (Ford, 1990).

SOFTWARE ENGINEERING ETIKA 
Rekayasa perangkat lunak telah digambarkan sebagai "penerapan disiplin rekayasa, 
ilmiah, dan prinsip-prinsip matematika, metode, dan alat untuk produksi ekonomis 
perangkat lunak berkualitas ". (Humphrey, 1989). Sebagai insinyur perangkat lunak menerapkan prinsip-prinsip ini, nilai-nilai kemanusiaan menjadi terkait dengan keputusan teknis. Etika rekayasa perangkat lunak mempelajari interaksi nilai-nilai kemanusiaan dan keputusan teknis yang melibatkan komputasi. Software engineering sebagai teknik-seperti disiplin memiliki hubungan langsung dengan etika.

Software engineering adalah ilmu terapan. Setiap produk dari rekayasa perangkat lunak melibatkan orang dan begitu pada setiap tahap pengembangan produk para pengguna menengah dan produk akhir harus diingat. Lunak insinyur mempunyai kewajiban kepada pengguna produk mereka, yang tidak hanya mencakup sistem diimplementasikan, tetapi juga mencakup produk lain seperti persyaratan, rencana manajemen proyek perangkat lunak, spesifikasi, desain, dokumentasi, test suite, program, user manual, dan materi pelatihan.

Dalam mengembangkan artefak rekayasa perangkat lunak ini, setiap keputusan adalah kompromi yang dipengaruhi oleh kendala-kendala tersebut sebagai anggaran yang tersedia, kebutuhan klien, tersedia perangkat lunak, keandalan persyaratan, pertimbangan lingkungan, efek sosial, dan bahkan politik realitas. Semua ini membuat pekerjaan dari insinyur perangkat lunak profesional lebih sulit dan memerlukan penilaian lebih subyektif. Tetapi ada beberapa panduan untuk membuat ini 
penilaian.

Dalam beberapa situasi mungkin standar dalam ketegangan dengan satu sama lain atau dengan standar dari sumber lain. Situasi ini memerlukan perangkat lunak insinyur untuk menggunakan etika penilaian untuk bertindak dengan cara yang paling konsisten dengan semangat dari Kode Etika dan Profesional Practice, mengingat keadaan. 
Ketegangan etis terbaik dapat ditangani oleh pertimbangan pemikiran fundamental 
prinsip, daripada buta ketergantungan pada peraturan rinci. Prinsip ini seharusnya mempengaruhi insinyur perangkat lunak untuk mempertimbangkan secara luas yang terpengaruh oleh mereka pekerjaan; untuk memeriksa jika mereka dan rekan-rekan mereka memperlakukan manusia lain dengan rasa hormat; untuk mempertimbangkan bagaimana publik, jika informasi yang cukup baik, akan memandang keputusan mereka; untuk menganalisis bagaimana paling tidak diberdayakan akan terpengaruh oleh mereka 
keputusan; dan untuk mempertimbangkan apakah tindakan mereka akan dinilai layak ideal profesional yang bekerja sebagai insinyur perangkat lunak. Dalam penilaian semua perhatian kesehatan, keselamatan dan kesejahteraan masyarakat adalah utama, yaitu yang "Kepentingan Umum" adalah pusat Kode ini. (Kode SE, 1999)

                      

                        3.Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)

Perangkat lunak adalah suatu benda tak berwujud (intangible) yang berpasangan dengan perangkat keras yang dibuat untuk memenuhi suatu maksud atau tujuan tertentu. Tujuan atau maksud ini bisa jadi bagian dari sebuah sistem atau bahkan sistem itu sendiri. Manusia berperan dalam membangun atau membuat kedua perangkat tersebut, dan berperan untuk menggunakan atau menerima hasilnya. Misalnya perangkat lunak personalia, perangkat lunak tersebut dijalankan pada suatu komputer (perangkat keras) untuk menangani masalah-masalah yang terkait dengan pengelolaan sumber daya manusia sebuah perusahaan. Ada orang-orang yang terlibat dalam mengembangkan perangkat lunak dan ada orang-orang yang menjalankan atau memakainya. Dari penjelasan di atas dapat dilihat ada beberapa hal atau elemen yang terlibat, yaitu perangkat lunak, perangkat keras, pembuat perangkat lunak, pemakai perangkat lunak dan masalah.
         Pada Umumnya terdapat 4 siklus hiup pengembangan software Yaitu :

A. Model WaterFall

Menurut Pressman (2010), model waterfall adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini termasuk kedalam model generic pada rekayasa perangkat lunak dan pertama kali diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan berurutan. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.

Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan. Langkah-langkah yang harus dilakukan pada metodologi Waterfall adalah sebagai berikut :

    A.    Analisis kebutuhan perangkat lunak
Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada perangkat lunak. Untuk memahami sifat program yang dibangun, rekayasa perangkat lunak (analisis) harus memahami domain informasi, tingkah laku, unjuk kerja dan antar muka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak di dokumentasikan dan dilihat dengan pelanggan.

Mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh software yang akan dibangun. 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.

     B.    Desain
Desain perangkat lunak sebenarnya adalah proses multi langka yang berfokus pada empat atribut sebuah program yang berbeda; struktur data, asitektur perangkat lunak, representasi interface dan detail (algoritma) prosedural.  Proses desain menerjemahkan syarat/kebutuhan kedalam sebuah representasi perangkat lunak yang dapat di perkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian  dari konfigurasi perangkat lunak.
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 dua aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada user. Proses software design untuk mengubah kebutuhan-kebutuhan di atas menjadi representasi ke dalam bentuk "blueprint" software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. seperti dua aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.

     C.  Generasi Kode
    Desain harus diterjemahkan dalam bentuk mesin yang bisa di baca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus 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.

      D.  Pengujian
   Proses Pengujian dilakukan pada logika internal untuk memastikan semua pernyataan sudah diuji. Pengujian eksternal fungsional untuk menemukan kesalahan-kesalahan dan memastikan bahwa input akan memberikan hasil yang aktual sesuai yang dibutuhkan.

      E.  Pemeliharaan
Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau sistem operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja.
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.
Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yangdibuat tidak selamanya hanya seperti itu ketika dijalankan mungkin saja masih ada error 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.

Kelebihan dari model ini adalah selain karena pengaplikasian menggunakan model ini mudah, kelebihan model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal proyek, maka Software Engineering(SE) dapat berjalan dengan baik dan tanpa masalah meskipun seringkali kebutuhan sistem tidak dapat didefinisikan se-eksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal proyek lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.

Masalah dengan waterfall :
A. Perubahan sulit dilakukan karena sifatnya yang kaku
B. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.
C. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar yaitu dengan proyek yang dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.

Berikut ini gambaran dari waterfall model.

Fase-fase dalam model waterfall menurut referensi Sommerfille :

B. V Model

Apa itu V Model?

Merupakan model pengembangan perangkat lunak yang didasarkan pada hubungan antara setiap fase pengembangan siklus hidup yang tercantum dalam model Watterfall yang merupakan pengembangan perangkat lunak dan fase yang terkait pengujian.

Apa saja tahapan V Model?

1. Lifecycle Process Model
2. Allocation of Methods
3. Functional Tools Requirements

Apa saja Submodel pada V Model?

1. Project Management (PM)
2. System Development (SD)
3. Quality Assurance (QA)
4. Configuration Management (CM)

Fase Implementasi Pada V Model

a.  Requirement Analysis & Acceptance Testing

     Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan

pengguna.

Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para

pengguna atau tidak.

b.  System Design & System Testing

     Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada

tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan

yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram

dan Data Dictionary.

c.  Architecture Design & Integration Testing

    Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti:

pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.

d.  Module Design & Unit Testing

    Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi

penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan

logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.

e.  Coding

     Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.

Tahapan V Model

Tahapan pada V Model dibagi menjadi 2 garis besar yaitu tahap Verifikasi dan Validasi atau testing.

Tahap Verfiikasi mengacu kepada usaha penyesuaian spesifikasi software dengan kebutuhan klien/konsumen, tahapan ini meliputi serangkaian kegiatan sebagai berikut:

1. Business Case: Merupakan tahapan awal yang menggambarkan kebutuhan/harapan konsumen terhadap sistem yang akan dikembangkan, termasuk manfaat sistem terhadap konsumen dan perkiraan biaya yang harus disediakan.
2. Requirement: pada fase ini klien mendapatkan gambaran atau diminta memberikan gambaran kebutuhan yang diharapkan dapat dipenuhi oleh software, baik kebutuhan fungsional maupun non fungsional.
3. Analisis Informasi: Setelah diperoleh spesifikasi sistem dari fase requirement, selanjutnya aktivitas difokuskan bagaimana cara kerja software untuk memenuhi kebutuhan tersebut, termasuk metode, hardware dan software apa saja yang diperlukan untuk mencapai kebutuhan yang sudah didefinisikan.
4. Perancangan Sistem: pada tahapan ini akan dibuat rancangan software secara lebih terinci sesuai spesifikasi yang sudah disepakati.
5. Unit Design: merancang setiap elemen/unit software termasuk rancangan modul/program, antarmuka, database dan lain-lain.
6. Development: merealisasikan hasil rancangan menjadi satu aplikasi/program tertentu.

Tahapan Validasi merupakan serangkaian tahapan yang mengacu kepada kesesuaian software dengan spesifikasi yang sudah ditetapkan. Tahapan ini dicapai melalui serangkaian pengujian/testing sebagai berikut:

• Unit test: menguji setiap komponen/unit program apakah sesuai dengan rancangan unit yang sudah ditetapkan. Secara teoritis seharusnya pengujian dilakukan oleh orang tertentu yang bertugas sebagai software tester, tetapi dalam kenyataannya seringkali unit testing dilakukan oleh programmer sendiri.
• Interface test: setelah semua komponen diuji secara terpisah, tahapan selanjutnya dilakukan interface test untuk melihat sejauh mana setiap komponen dapat berinteraksi satu sama lain sesuai dengan fungsi yang diharapkan.
• System test: setelah semua interface berjalan dengan baik, selanutnya dilakukan system test untuk melihat sejauh mana sistem/software dapat memenuhi kebutuhan secara keseluruhan. System testing bersifat menyeluruh dan tidak dapat dilakukan berdasarkan fungsionalitas sistem yang diuji secara terpisah. Aktivitas pada system testing termasuk melakukan pengujian hal-hal berikut:
  1. Performance – apakah kinerja sistem sesuai dengan target yang sudah didefinisikan sebelumnya.
  2. Volume – apakah software/sistem dapat menampung volume informasi yang cukup besar.
  3. Stress – apakah software/sistem dapat menampung sejumlah informasi pada waktu-waktu tertentu.
  4. Documentation – apakah semua dokumentasi penting sudah disiapkan.
  5. Robustness – apakah software/sistem cenderung stabil pada berbagai kondisi diluar dugaan/ekstrim.

• Acceptance test merupakan aktivitas untuk menguji sejauh mana sistem/software dapat membantu memecahkan business case, dalam artian apakah sistem/software tersebut sudah sesuai dengan harapan konsumen/klien dan sejauh mana manfaat sistem/software ini bagi klien. Test ini sering kali disebut sebagai User Acceptance Test (UAT).
• Release testing: test ini dilakukan untuk menguji sejauh mana sistem/software dapat mendukung aktivitas organisasi dan berjalan dengan harmonis sesuai dengan kegiatan rutin organisasi. Beberapa pertanyaan coba dijawab pada fase ini misalnya apakah software tersebut mempengaruhi sistem lain? Apakah software tersebut kompatibel dengan sistem lain? Bagaimana kinerja sistem sebenarnya di dalam organisasi?

Dimana saja V Model Diterapkan?

1. Dalam proyek teknologi informasi di Jerman
2. V Model dibandingkan dengan CMM
3. V Model didesain untuk mengembangkan sistem yang didalamnya terdapat dua komponen
4. Pengembangan V Model dalam bidang industri dapat dilakukan dengan mudah

Kelebihan V Model

1. V Model sangat fleksibel
2. V Model dikembangkan dan dirawat oleh publik
3. Kelebihan V Model dibandingkan dengan Waterfall biasa yaitu, pada setiap fase selalu dilakukan pengujian yang cukup memadai

Kekurangan V Model

1. Model yang project oriented
2. Memiliki beberapa activity
3. Asusmsi yang digunakan adalah requirement bersifat tetap dan tidak berubah
4. Requirement dan rancangan tidak diverifikasi
5. Pada setiap fase terdapat peluang error

C. Simple Interaction Design Model Lifecycle

Simple Interaction Design Model Lifecycle Software adalah model yang menggabungkan tiga prinsip pengguna berpusat desain dan empat kegiatan desain interaksi. 

Prinsip User-Centered Design

Prinsip-prinsip ini dikembangkan oleh John D. Gould dan Clayton Lewis. prinsipnya adalah sebagai berikut:

1. Fokus pada pengguna dan tugas

2. Pengukuran empiris

3. Desain Interatif

Dasar kegiatan Desain Interaksi

Preece et al. menggambarkan model dasar untuk proses desain interaksi yang mencakup empat kegiatan seperti yang ditunjukkan di bawah

ini. Sejumlah akademisi dan lembaga desain terkenal telah menciptakan model yang sama. Zimmerman, J., Forlizzi, J., dan Evenson, S., dari

Sekolah Desain di Carnegie Mellon University.

Kegiatannya adalah sebagai berikut:

1. Mengidentifikasi kebutuhan dan persyaratan mendirikan untuk pengalaman pengguna

2. Mengembangkan alternatif desain yang memenuhi persyaratan

3. Membangun versi interaktif dari desain

4. Mengevaluasi apa yang sedang dibangun di seluruh proses dan pengalaman pengguna yang menawarkan

Bentuk dari simple interaction design model lifecycle software adalah sebagai berikut:

Tahapan Simple Interaction Design Model

1.      Identifikasi kebutuhan dan persyaratan sistem disini suatu sistem akan di identifikasi sesuai 

          dengan kebutuhan sistem itu sendiri.

2.       Pengembangan desain alternatif (desain konseptual dan fisikal)

3.       Membuat versi interaktif dari desain yang dihasilkan

4.       Mengevaluasi desain (usabilitas dan user experience)

D. Star Lifecycle Model

              Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama akan lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user.

Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.

Perbandingan Metodologi

Perbandingan Metodologi untuk mengembangkan Sistem informasi Web :

Waterfall Setiap phase pada Waterfall dilakukan secara berurutan namun kurang dalam iterasi pada setiap level. Dalam pengembangan Web Informasi Waterfall memiliki kekakuan untuk ke iterasi sebelumnya. Dimana Web Informasi selalu berkembang baik teknologi ataupun lingkungannya.

Prototipe Membantu user dalam menilai setiap versi dari sistem. Sangat baik untuk “aplikasi yang interaktif”, Umumnya user lebih tertarik pada tampilan dari pada proses pada sistem. Namun dalam prosesnya prototipe cenderung lambat karena user akan menambah komponen dari luar sistem. Sehinggakepastian penyelesaian project tidak jelas. Dan target user dalam Web lebih bervariasi.

Rapid Application Development

Bentuk dari prototipe dengan “throwaway” jika ada modul yang salah maka akan dibuang. Artinya setiap modul tidak akan dikembangkan sampai selesai, karena jika dianalisa salah langsung dibuang.“RAD involve building the wrong site multiple times until the right site falls out of the process”.

Incremental Prototipe

Digunakan untuk menyelesaikan sistem secara global terlebih dahulu, kemudian untuk feature dari sistem akan dikembangkan kemudian. Dengan ini mempercepat dalam pengimplementasian project. dan hal ini cocok digunakan dalam system informasi Web.

Alat-alat dalam Pengembangan Sistem
Untuk dapat melakukan langkah-langkah sesuai dengan metodologi pengembangan sistem maka dibutuhkan beberapa alat. Alat-alat yang digunakan biasanya berupa gambar atau diagram atau grafik.
Contohnya :
• HIPO diagram
• Data Flow diagram
• Structured chart
• SADT diagram
• Warnier/Orr diagram
• Jakson’s diagram
Diagram-diagram diatas digunakan untuk mengambarkan suatu metode tertentu, ada beberapa grafik yang lebih bersifat umum, antara lain :
• Bagan untuk menggambarkan aktifitas (activity charting), seperti : bagan alir sistem, bagan alis program, bagan alir kertas kerja, bagan alir hubungan database, bagan alir proses, dan Gantt chart.
• Bagan untuk menggambarkan tataletak
• Bagan untuk menggambarkan hubungan personil, seperti : Bagan distribusi kerja dan bagan organisasi.
Teknik yang Digunakan untuk Pengembangan Sistem
Teknik yang digunakan untuk pengembangan sistem antara lain :
• Teknik manajemen proyek, seperti CPM (Critical Path Method) dan PERT (Program Evaluation and Review Technique). Teknik ini digunakan untuk penjadualan proyek.
• Teknik menemukan fakta, yaitu teknik yang dapat digunakan untuk mengumpulkan data dan menemukan fakta-fakta dalam kegiatan mempelajari sistem yang ada. Contohnya : Teknik wawancara, observasi, daftar pertanyaan, pengumpulan sampel.
• Teknik analisis biaya/manfaat
• Teknik inspeksi/walkthrought

Gambar.

• Analisa

Identifikasi kemampuan user, strategi yang digunakan untuk meningkatkan ketrampilannya, alat yang saat ini dipakai, masalah-masalah yang dialami, perubahan yang diinginkan baik dalam ketrampilan maupun peralatan.
Metode : tanya kemampuan user dan buat daftar dengan skala prioritas, observasi ketrampilan di lapangan.

• Evaluasi kompetisi

Tentukan kekuatan dan kelemahan rancangan
Metode : pengguna diminta untuk mencoba menggunakan berbagi produk dan minta untuk menyebutkan kelebihan dan kelemahan dari masing-masing produk.

• Rancang sambil jalan

Gunakan hasil analisa untuk membuat alternatif solusi, minta masukan sampai dengan penentuan pilihan yang terbaik.
Metode : tanyai user sehubungan dengan pengalaman menggunakan prototipe.

• Evaluasi dan validasi

Secara periodik user memberikan masukan selama pengembangan dan perancangan akan diulang berdasarkan masukan tadi.
Metode : amati kebutuhan pokok user dalam menggunakan sistem.

• Benchmark

Memadukan hal-hal terbaik yang dimiliki pesaing untuk diterapkan dalam sistem yang dibangun Metode : menggali informasi dari user hal-hal yang sebaiknya ada dibandingkan dengan kompetitor, contoh : situs IBM.

Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design ) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama aka lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user. Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.

 Referensi : https://rinnooberta.wordpress.com/2013/12/23/konsep-dasar-pada-software-engineering/

                   http://nartos-jog.blogspot.co.id/2009/12/etika-profesi-software-engineering.html  

                   http://jackindigo.blogspot.co.id/2014/11/model-waterfall.html

Continue reading →