Dalam konteks rekayasa perangkat lunak, mengukur (measure) mengindikasikan kuantitatif dari ukuran atribut sebuah proses atau produk. Pengukuran (measurement) adalah kegiatan menentukan sebuah measure (pengukuran). Dan definisi metriks menurut IEEE adalah “ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu”.
Pengukuran telah ada jika suatu data-data tunggal telah dikumpulkan (misal: jumlah kesalahan yang ditemukan pada kajian sebuah modul tunggal). Metrik perangkat lunak menghubungkan pengukuran-pengukuran individu dengan banyak cara, misal rata-rata dari jumlah kesalahan yang ditemukan pada setiap kajian.

Rekayasa perangkat lunak mengumpulkan pengukuran dan mengembangkan metrik menjadi sebuah indikator, yaitu sebuah metrik atau kombinasi metrik yang memberikan pengetahuan dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk itu sendiri. Fungsinya adalah memberi pengetahuan pada manajer proyek atau perekayasa perangkat lunak untuk menyesuaikan proses, proyek, dan produk agar menjadi lebih baik.

2. PENGUKURAN PERANGKAT LUNAK

Pengukuran langsung dari produk berkaitan dengan deretan kode, kecepatan eksekusi, ukuran memori, dan cacat yang dilaporkan pada suatu periode tertentu. Sedangkan pengukuran tidak langsung dari produk adalah tentang fungsionalitas, kualitas, kompleksitas, efisiensi, realibilitas, kemampuan pemeliharaan, dsb.Dalam kenyataannya, pengukuran perangkat lunak secara objektif akan sulit dilakukan secara langsung karena ada pengaruh-pengaruh seperti individu dalam tim pengukuran, atau tingkat kompleksitas proyek.
Tetapi jika pengukuran dinormalisasi, maka mungkin akan dapat didapatkan metrik perangkat lunak yang memungkinkan perbandingan dengan rata-rata organisasional yang lebih besar.

2.1 METRIK SIZE ORIENTED

Parameternya adalah ”ukuran” dari software yang dihasilkan. Dapat dilakukan jika ada record atau catatan dari organisasi. Perlu diperhatikan bahwa yang record yang diperlukan adalah keseluruhan aktivitas rekayasa perangkat lunak. Misalnya tabel dibawah ini adalah pengumpulan dari data-data record yang ada dari sebuah organisasi:

Dimana LOC (line of code) menunjukkan jumlah baris kode yang dibuat pada masing-masing proyek, misalnya pada kolom pertama, proyek aplha dibuat dengan 12100 baris kode dalam 365 halaman, dikembangakan dengan usaha 24 orang per bulan dengan biaya $168000. Lalu ditemukan kesalahan sebanyak 134 pada proyek sebelum direlease, 29 cacat setelah direlease pada pelanggan, dan ada 3 orang yang bekerja pada pengembangan proyek perangkat lunak alpha.

Untuk pengembangan dari metrik ini, dapat dibuat metrik size oriented baru yang sederhana untuk tiap proyek, misal: kesalahan per baris kode (dihitung ribuan), cacat per baris kode (ribuan), dokumentasi per baris kode (ribuan), kesalahan per usaha, baris kode per usaha, biaya per halaman dokumentasi, dsb.

Metrik ini tidak dapat diterima secara universal karena adanya kontroversi pada penggunaan baris kode sebagai titik ukur. Sebagian yang setuju pada pengukuran LOC menganggap bahwa LOC adalah suatu bukti real dari apa yang dilakukan oleh perekayasa perangkat lunak (dalam konteks ini membuktikan berapa banyak baris program yang ditulis oleh seorang programmer – comment yang ada).

Sedangkan sebagian yang tidak setuju bahwa LOC dijadikan suatu tolak ukur kebanyakan disebabkan alasan ambiguitas dari cara menghitung LOC itu sendiri. Dalam masa-masa awal bahasa pemrograman Assembly, hal ini tidak menjadi suatu masalah karena dalam 1 baris aktual program merupakan 1 baris instruksi, tetapi dalam bahasa pemrograman tingkat tinggi, dimana pada masing-masing bahasa, untuk menyelesaikan suatu masalah dengan algoritma yang sama pun LOC nya sudah berbeda-beda. Bahkan dalam satu bahasa pemrograman yang sama, untuk menyelesaikan masalah yang sama, LOC nya bisa berbeda jauh tergantung dari algoritma yang digunakan. Hal ini yang membuat banyak sekali kontroversi mengenai LOC sebagai tolak ukur dari sebuah software.

2.2 METRIK FUNCTION ORIENTED

Normalisasi dilakukan pada fungsionalitas pada aplikasi, tetapi untuk melakukan hal ini, fungsionalitas harus diukur dengan pengukuran langsung yang lain karena fungsionalitas tidak dapat diukur secara langsung. Maka pengukuran dapat dilakukan dengan pengukuran function point. Function point didapat dari penarikan hubungan empiris berdasarkan pengukuran domain informasi software dan perkiraan kompleksitas software.
Domain informasi yang biasa digunakan ada 5 karakteristik, yaitu:
· jumlah input pemakai: setiap input pemakai yang memberikan data yang berorientasi pada aplikasi yang jelas pada perangkat lunak (harus dibedakan dari penelitian yang dihitung secara terpisah) misal: tipe transaksi.
· jumlah output pemakai: setiap output pemakai yang memberikan informasi yang berorientasi pada aplikasi kepada pemakai. Pada konteks ini output mengacu pada laporan, layar, tampilan kesalahan, dsb. Jenis data individual pada laporan tidak dihitung terpisah. misal: report type.
· jumlah penyelidikan pemakai: input online yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk output online.
· jumlah file: setiap master logika (pengelompokan data logis yang menjadi suatu bagian dari sebuah database yang besar atau sebuah file terpisah).
· jumlah interface eksternal: semua interface yang dapat dibaca oleh mesin yang digunakan untuk memindahkan informasi ke sistem yang lain

Sekali data telah dikumpulkan, maka nilai kompleksitas dihubungkan dengan masing-masing penghitungan dengan tabel perhitungan sebagai berikut:
Faktor pembobotan

Dalam hal ini faktor pembobotan setiap faktor sudah menjadi standar dan tidak dapat diubah-ubah, tetapi dalam penentuan kriteria suatu perangkat lunak pada salah satu parameter pengukuran adalah sederhana, rata-rata atau kompleks ditentukan oleh organisasi atau perkeyasa perangkat lunak yang melakukan penghitungan itu sendiri. Tetapi meskipun begitu perkiraan kompleksitas tetap bersifat subyektif.

Untuk menghitung function point (FP) dapat digunakan hubungan sbb:
FP = jumlah total x [0,65 + 0,01 x Fi]
dimana jumlah total adalah nilai yang kita dapatkan pada tabel perhitungan di atas.

Sedangkan Fi dapat dihitung dari perhitungan sebagai berikut:
· Pertama-tama kita diberi 14 buah karakteristik dari suatu perangkat sebagai berikut:
1. Data communications
2. Distributed functions
3. Performance
4. Heavily used configuration
5. Transaction rate
6. Online data entry
7. End-user efficiency
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitation of change
Pada setiap karakteristik tersebut diberi bobot dari nilai 0 sampai 5 dengan asumsi nilai sebagai berikut:
0. Tidak berpengaruh
1. Insidental
2. Moderat
3. Rata-rata
4. Signifikan
5. Essential

Setelah setiap karakteristik diberi bobot masing-masing, lalu bobot-bobot dari setiap karakteristik ini dijumlahkan (jadi minimum 0 dan maksimal 70) dan kita akan mendapatkan nilai Fi. Setelah mendapatkan nilai Fi maka kita bisa menghitung nilai FP dengan rumus di yang sudah ada di atas.
Setelah kita mendapatkan nilai FP, maka kita dapat menggunakannya dengan cara analog dengan LOC untuk menormalisasi pengukuran produktivitas, kualitas perangkat lunak, serta atribut-atribut yang lain seperti:

· kesalahan per FP
· cacat per FP
· $ per FP
· halaman dokumentasi per FP
· FP per person-month
· dsb
(dimana untuk mendapatkan data-data untuk kesalahan, cacat, dolar, dsb dapat diambil dari data-data pada tabel record pada metrik size-oriented).

Contoh:

Pada proyek alpha (tabel record metrik size oriented) sudah dihitung bahwa jumlah input pemakainya ada 18 buah, jumlah output pemakai: 6 buah, jumlah penyelidikan pemakai 22 buah, jumlah file 45 buah, jumlah interface eksternal 20 buah, dengan asumsi bahwa jumlah input pemakai rata-rata, jumlah output pemakai sederhana, jumlah penyelidikan pemakai rata-rata, jumlah file kompleks, jumlah interface eksternal sederhana. Semua karakteristik pada perangkat lunak ini moderat. Hitung $ per FP nya!

Jawab:

jumlah total = (18 x 4) + (6 x 4) + (22 x 4) + (45 x 15) + (20 x 6) = 979
Fi = 14 x 2 = 28
FP = 979 x (0,65 + (0,01 x 28)) = 910,47
$ pada proyek alpha: 168000
$ per FP = 168000 / 910,47 = $184,52

Hasil dari contoh kasus diatas masih berupa suatu angka mentah, untuk dapat dilihat apakah angka ini termasuk baik atau tidak harus diperbandingkan dengan perhitungan lain, misalnya $ per FP dari proyek beta atau gamma, atau proyek dari organisasi lain.

Sebenarnya banyak sekali metrik-metrik yang digunakan untuk mengukur perangkat lunak, misalnya metrik FP yang diperluas (biasanya diaplikasikan dalam dunia bisnis) tetapi belum sempat dibahas disini.

Penulis:
Arief Martoyo
5105100139

IEEE Glossary: keadaan dimana sebuah sistem, komponen, atau proses sesuai dg (1)permintaan yang spesifik (2) permintaan atau kebutuhan konsumen atau penguna
ISO: fitur dan karakteristik dari produk atau jasa yang didalamnya tdr dari kecakapan utk kepuasan yang spesifik atau yang sesuai dengan permintaan

Kriteria2 Quality terdiri:
correctness
efficiency
flexibility
integrity
interoperability
maintainability
portability
reliability
reusability
testability
usability

Konsep SQA

Pengertian SQA: suatu aktivitas sistemik yang diaplikasikan dalam software proses sehingga hasilnya menjadi lebih baik.
SQA meliputi bagian2:
(1) a quality management approach
(2) effective software engineering technology
(3) formal technical reviews
(4) a multi-tiered testing strategy
(5) document change control
(6) software development standard and its control procedure
(7) measurement and reporting mechanism

Contoh Software gagal

Taurus (London Stock Exchange)
11 years late & 13,200% over budget
London Ambulance Service
faults led to reversion to manual processes
Ariane 5
coding defect in module reused from Ariane 4
AT&T switching system
coding defect in three-line “fix”

Prosentase Software Project

Hambatan dalam pengembangan Software

· Masalah terlalu komplek dan susah

· Solusi terlalu komplek dan susah dispesifikasi Permintaan dengan ketelitian yang sangat tinggi

· progress susah untuk dipantau

· Teknologi dan bisnis terlalu cepat untuk berubah

Langkah2 mewujudkan QA

· Dengan mengadaptasi berbagai disiplin ilmu dan profesional

· Quality Management System

§ Documented processes & Best Practice

§ ISO 9001 & TickIT registration

· Continuous Improvement

§ New methods (e.g. DSDM, UML) & tools

§ Better & more focussed Training

Quality Manajemen System

· Defesinikan alur kerja

focuses

flexible

broadly applicable

· Procedures and guidelines

mandatory elements and recommendations

· Mix of best practice & common sense

Project Control

· Inisiasi Project
· Akhir Project
· Estimasi
· Risks & issues
· Project & Quality plans
· Schedule plans
· Progress monitoring & reporting

Quality Control

· Perencanaan
· Quality Control Reviews
· Proses persetujuan
· Validation, Verification & Testing

Desain Perangkat Lunak Dan Rekayasa Perangkat Lunak

Desain perangkat lunak berada pada inti teknik dari proses rekayasa perangkat lunak dan diaplikasikan tanpa memperhatikan model proses perangkat lunak yang digunakan. Begitu persyaratan perangkat lunak telah mulai dianalisis dan ditentukan, maka desain perangkat lunak menjadi yang pertama dari tiga aktivitas teknik – desain, pembuatan kode dan pengujian – yang diperlukan untuk membangun dan menguji perangkat lunak. Persyaratan perangkat lunak, yang dimanifestasi oleh data, fungsional, dan model-model perilaku, mengisi langkah desain. Dengan menggunakan satu dari sejumlah metode desain, langkah desain menghasilkan
a. desain data
b. desain arsitektur
c. desain interface
d. desain prosedural

Selama desain, kita dapat membuat keputusan yang akan mempengaruhi kesuksesan konstruksi perangkat lunak dan kemudahan maintenance-nya. Desain sangat penting karena dapat menentukan kualitas dari suatu perangkat lunak.
Proses Desain

Desain perangkat lunak adalah suatu proses interaktif yang melaluinya persyaratan diterjemahkan ke dalam suatu “cetak biru” untuk membangun perangkat lunak. Cetak biru menggambarkan suatu pandangan menyeluruh perangkat lunak, yaitu bahwa desain dihadirkan pada tingkat abstraksi yang tinggi (dapat secara lanngsung ditelusuri sampai data spesifik, fungsional, dan persyaratan behavioral)

1. Desain dan kualitas perangkat lunak

McGlaughlin mengusulkan 3 karakteristik yang berfungsi sebagai pedoman bagi evaluasi suatu desain yang baik :
a. desain harus mengimplementasikan keseluruhan persyaratan eksplisit yang dibebankan dalam model analisis, dan harus mengakomodasikan semua persyaratan implisit yang diinginkan pelanggan.
b. Desain harus menjadi panduan yang dapat dibaca, dapat dipahami bagi mereka yang menghasilkan kode dan yang menguji serta memelihara perangkat lunak.
c. Desain harus memberikan suatu gambaran lengkap mengenai perangkat lunak, yang menekankan data, dan domain perilaku dari perspektif implementasi.
Kriteria teknis untuk desain yang baik :
a. Desain harus memperlihatkan suatu organisasi yang dengan baik menggunakan kontrol di antara elemen-elemen perangkat lunak.
b. Desain harus modular : yaitu bahwa perangkat lunak harus dipartisi secara logika ke dalam elemen-elemen yang melakukan fungsi dan subfungsi khusus.
c. Desain harus berisi data dan abstraksi prosedural.
d. Desain harus membawa ke arah modul (misal subrutin atau prosedur) yang memperlihatkan karakteristik fungsional independent.
e. Desain harus mengarah kepada interface yang mengurangi kompleksitas hubungan antara modul-modul dan dengan lingkunga eksternal.
f. Desain harus didapat dengan menggunakan metode berulang yang dikendalikan oleh informasi yang diperoleh selama analisis persyaratan perangkat lunak.

2. Evolusi desain perangkat lunak

Merupakan suatu proses kontinu yang terus berlangsung selama tiga dekade. Kerja desain awal dikonsentrasikan pada kriteria untuk pengembangan program moduler dan metode-metode untuk menyaring arsitektur perangkat lunak dengan cara top-down. Aspek-aspek prosedural dari definisi desain yang tercakup dalam suatu filosofi disebut pemrograman terstruktur. Usaha selanjutnya mengusulkan metode-metode translasi aliran data atau struktur data ke dalam definisi desain. Pendekatan desain yang lebih baru mengusulkan suatu pendekatan orientasi obyek ke derivasi desain.

Banyak metode desain yang tumbuh dari kerja tersebut, sedang diaplikasi pada industri. Setiap metode tersebut mempunyai sejumlah karakteristik umum :
a. mekanisme penerjemahan suatu model analisis ke dalam representasi desain.
b. Notasi untuk merepresentasikan komponen-komponen fungsional dan interface-nya.
c. Heuristik bagi penyaringan dan partisi
d. Pedoman bagi penilaian kualitas

Prinsip desain

Desain perangkat lunak berupa model dan proses. Proses desain adalah serangkaian langkah iteratif yang memungkinkan desainer menggambarkan semua aspek perangkat lunak yang dibangun. Model desain adalah ekivalen rencana arsitek untuk sebuah “rumah”, yang dimulai dengan menyajikan totalitas dari hal yang akan dibangun. Prinsip desain dasar memungkinkan perekayasa perangkat lunak untuk mengendalikan proses desain.
a. Proses desain tidak boleh menderita karena “tunnel vision”
b. Desain harus dapat ditelusuri sampai model analisis.
c. Desain tidak boleh berulang.
d. Desain harus “meminimalkan kesenjangan intelektual” di antara perangkat lunak dan masalah yang ada di dunia nyata.
e. Desain harus mengungkap keseragaman dan integrasi.
f. Desain harus terstruktur untuk mengakomodasi perubahan.
g. Desain harus terstruktur untuk berdegradasi dengan baik, bahkan pada saat data dan event-event menyimpang, atau menghadapi kondisi operasi.
h. Desain bukanlah pengkodean, dan pengkodean bukanlah desain.
i. Desain harus dinilai kualitasnya pada saat desain dibuat, bukan setelah jadi.
j. Desain harus dikaji untuk meminimalkan kesalahan-kesalahan konseptual (semantik).

Konsep-konsep desain

1. Abstraksi

Abstraksi memungkinkan desainer menentukan prosedur dan data, dan masih menekan detail tingkat rendah.
Terdapat 3 macam bentuk abstraksi, yaitu :
a. Abstraksi prosedural.
Merupakan urutan instruksi yang diberi nama yang mempunyai fungsi tertentu dan terbatas.
b. Abstraksi data.
Kumpulan data yang bernama yang menggambarkan obyek data.
c. Abstraksi kontrol.
Mengimplikasikan suatu mekanisme kontrol program tanpa menentukan detail-detail internal

2. Penyaringan.

Penyaringan stepwise (dengan serangkaian langkah) adalah strategi desain top-down yang diusulkan oleh Wiklaus Wirth. Kajian dari konsep tersebut adalah
“Pada setiap langkah (penyaringan), satu atau beberapa instruksi dari program yang diberikan didekomposisi ke dalam instruksi-instruksi yang lebih detail. Dekomposisi berurutan atau penyaringan spesifikasi berhenti bila semua instruksi diekspresikan dalam bentuk bahasa pemrograman atau komputer yang mendasar. Jika tugas-tugas disaring, maka data harus disaring juga, didekomposisi atau distruktur, dan adalah wajar untuk menyaring program dan spesifikasi data secara paralel” .

Abstraksi dan penyaringan adalah konsep kompementer. Kedua konsep tersebut membantu desainer dalam menciptakan suatu model desain lengkap jika desain berkembang.

3. Modularitas

Modularitas merupakan atribut tunggal dari perangkat lunak yang memungkinkan sebuah program untuk dikelola secara intelektual.
Meyer menyebutkan 5 kriteria yang memungkinkan kita untuk mengevaluasi suatu metode desain dengan merujuk pada kemampuannya untuk menentukan sistem modular yang efektif.
a. Dekomposisi modular.
b. Komposabilitas modular.
c. Kemampuan pemahaman modular.
d. Kontinuitas modular.
e. Proteksi modular.

4. Arsitektur perangkat lunak

Arsitektur perangkat lunak mencakup “struktur keseluruhan perangkat lunak dan cara dimana struktur memberikan integrasi konseptual bagi suatu sistem”.

Shaw dan Garlan menjelaskan sekumpulan properti yang seharusnya ditetapkan sebagai bagian dari desain arsitektural :
a. Properti struktural.
Menentukan komponen suatu sistem dan cara dimana komponen-komponen tersebut dikemas dan berinteraksi satu dengan yang lain.
b. Properti ekstra-fungsional.
Menekankan pada bagaimana arsitektur desain memenuhi persyaratan kinerja, kapasitas, reliabilitas, keamanan, adaptibilitas, dan karakteristik sistem yang lain.
c. Keluarga dari sistem yang berhubungan.
Desain harus memiliki kemampuan untuk memakai lagi blok bangunan arsitektural tersebut.

5. Hirarki Kontrol
Hirarki kontrol, disebut juga struktur program merepresentasikan organisasi komponen program serta mengimplikasikan suatu hirarki kontrol. Hirarki kontrol tidak mengimplikasikan aspek prosedural dari perangkat lunak, seperti urutan proses, kejadian/urutan dari keputusan, atau pengulangan operasi.

6. Partisi struktural
Struktur progam harus dipartisi baik secara horizontal maupun vertikal.
Partisi horizontal menentukan cabang-cabang terpisah dari hirarki modular untuk setiap fungsi program mayor. Keuntungannya :
a. menghasilkan perangkat lunak yang lebih mudah diuji.
b. Membawa kepada perangkat lunak yang lebih mudah dipelihara.
c. Menghasilkan penyebaran efek samping yang lebih sedikit.
d. Menghasilkan suatu perangkat lunak yang lebih mudah untuk diperluas.
Partisi vertikal menyatakan bahwa kontrol dan kerja harus didistribusikan secara top-down dalam arsitektur program.
7. Struktur data
Struktur data adalah representasi dari hubungan logis antara elemen-elemen data individual.

8. Prosedur perangkat lunak
Prosedur perangkat lunak berfokus pada detail-detail pemrosesan dari masing-masing modul secara individual. Prosedur harus memberikan spesifikasi yang teliti terhadap pemrosesan, mencakup urutan event, poin-poin keputusan nyata, operasi repetitif, dan organisasi struktur data.

9. Penyembunyian informasi
Prinsip penyembunyian informasi menyatakan bahwa bahwa modul ditandai dengan keputusan desain tersembunyi dari semua desain lain.

Desain Modular Afektif
1. Independensi fungsional
Merupakan hasil pertumbuhan langsung dari modularitas dan konsep abstraksi dan penyembunyian informasi.
Independensi fungsional dicapai dengan mengembangkan modul dengan fungsi “single-minded” dan suatu “aversi” ke interaksi eksesif dengan modul yang lain.

2. Kohesi
Kohesi adalah suatu ekstensi natural dari konsep penyembunyian informasi. Modul kohesi melakukan suatu tugas tunggal pada suatu prosedur perangkat lunak yang memerlukan sedikit interaksi dengan prosedur yang sedang dilakukan di bagian lain dari suatu program.

3. Perangkaian
Perangkaian adalah pengukuran interkoneksi diantara modul-modul pada sebuah struktur progam. Perangkaian tergantung pada kompleksitas interface diantara modul-modul, titik dimana entri atau referensi dibuat untuk sebuah modul dan data yang dilewatkan pada interface tersebut.

Strategi pengujian software haruslah cukup fleksibel untuk mempromosikan kreatifitas dan customisasi yang diperlukan bagi pengujian semua system software berskala besar. Pada saat yang sama, strategi haruslah cukup kaku untuk mempromosikan perencanaan yang layak dan tracking manajemen sebagai jalannya proyek.
Shooman[SHO83] :
Dalam berbagai bentuk, pengujian atau testing adalah proses yang bersifat individu dan banyaknya jenis perbedaan dari variasi pengujian sebanyak perbedaan dalam pendekatan pengembangan. Dalam beberapa tahun, pertahanan kita menghadapi error dalam pemrograman hanyalah desain yang hati-hati dan kecerdasan alami dari programmer. Sekarang kita berada pada masa dimana teknik desain modern [dan review dari teknik formal] membantu kita untuk menurunkan jumlah dari error yang terinisialisasi dan tidak dapat dipisahkan dari kode. Dengan cara yang sama, metode pengujian yang berbeda diawali untuk mengikat error kedalam beberapa pendekatan dan filosofi yang berbeda.
Pendekatan dan filosofi inilah yang akan disebut strategi.
Pendekatan strategi dalam pengujian software
Pengujian atau testing adalah aktifitas yang dapat direncanakan kedepannya dan penyelenggaraannya secara sistematis. Karena alasan ini untuk pengujian software haruslah didefinisikan dalam proses rekayasa perangkat lunak atau software engineering.
Sejumlah strategi pengujian software telah diusulkan dalam literatur. Semuanya menyediakan developer software dengan template untuk pengujian dan semuanya memiliki memiliki karakteristik umum:
— Testing dimulai pada level modul dan bekerja keluar kearah integrasi pada sistem berbasiskan komputer
— Teknik testing yang berbeda sesuai dengan poin-poin yang berbeda pada waktunya
— Testing diadakan oleh software developer dan untuk proyek yang besar oleh group testing yang independent
— Testing dan Debugging adalah aktivitas yang berbeda tetapi debugging harus diakomodasikan pada setiap strategi testing
Sebuah strategi untuk pengujian software harus mengakomodasi pengujian tingkat rendah yang diperlukan untuk memverifikasi segmentasi source code yang kecil apakah telah dengan benar diimplementasikan sebaik pengujian pada pengujian tingkat tinggi yang memvalidasi fungsi system utama dalam menghadapi kebutuhan pelanggan. Sebuah strategi haruslah menyediakan petunjuk bagi praktisi dan manajer. Karena langkah-langkah dalam strategi pengujian terjadi pada saat tekanan deadline meningkat, kemajuan harus terukur dan permasalahan harus diketahui secepat mungkin.
Verifikasi dan Validasi
Pengujian Software adalah satu elemen dari sebuah topik broader yang sering diartikan sebagai
è Verifikasi dan Validasi (V&V)
Verifikasi : menunjuk ke kumpulan aktifitas yang memastikan bahwa software mengimplementasi sebuah fungsi spesifik.
Validasi : menunjuk ke sebuah kumpulan berbeda dari aktivitas yang memastikan bahwa software yang telah dibangun dapat di-trace terhadap kebutuhan customer.
Boehm [BOE81]:
Verifikasi: “Apakah kita membangun produk dengan baik?”
Validasi: “Apakah kita membangun produk yang baik?”
Defenisi V&V meliputi banyak aktifitas SQA, termasuk review teknis formal, kualitas dan audit konfigurasi monitor performance, tipe yang berbeda dari pengujian software study feasibility dan simulasi.

Mendapatkan Kualitas Software

[gambar 1]

— Metode software engineering menyediakan dasar dari mutu yang mana yang akan dipakai.
— Metode Analysis, design and Construction berupa tindakan untuk meningkatkan kualitas dengan menyediakan teknik yang seragam dan hasil yang sesuai dengan keinginan.
— Metode Formal Technical Reviews menolong untuk memastikan kualitas kerja produk merupakan hasil konsekuensi dari setiap langkah software engineering.
— Metode Measurement diberlakukan pada setiap elemen dari konfigurasi software
— Metode Standards and Procedures membantu untuk memastikan keseragaman dan formalitas dari SQA untuk menguatkan dasar “filosofi kualitas total”
— MetodeTesting menyediakan cara terakhir dari tingkat kualitas mana yang dapat dicapai dan dengan praktis dapat mengetahui letak error.
Organisasi Pengujian Software
Obyektif pengujian: tidak menutup error(defects) pada software, termasuk error pada:
- kebutuhan dari analisa kebutuhan
- desain terdokumentasi dalam spesifikasi desain
- coding (implementasi)
- sumber sistem dan lingkungan sistem
- masalah-masalah hardware dan interface-nya terhadap software
Pengujian Software dapat dipertimbangkan secara psikologi dihancurkan(destructive).
Siapa yang terlibat dalam pengujian software?
- developer
- tester (test engineer) di ITG
- SQA group
Organisasi pengujian software:
- Individual tester dalam sebuah tim pengembang
- Independent test group (ITG)

Sebuah Strategi Pengujian Software

Diagram diatas menunjukkan dua langkah yaitu proses rekayasa perangkat lunak(software engineering) dan proses strategi pengujian perangkat lunak. Untuk proses software engineering :
— Software Engineering mendefinisikan peran dari software dan mengarahkan ke software requirement analysis, sebagai pusat kriteria informasi, fungsi, perilaku, performa, batasan dan validasi dari software yang dibangun.
— Bergerak kedalam sepanjang spiral, hingga design dan terakhir proses koding (code).
Untuk proses strategi pengujian perangkat lunak :
— Dimulai dari Unit Testing yang dikonsentrasikan pada setiap unit software seperti yang diterapkan dalam source code
— Kemudian bergerak keluar hingga ke integration testing dimana fokus pada desain dan konstruksi pada arsitektur software.
— Kemudian bergerak lagi hingga ke validation testing dimana kebutuhan dibentuk sebagai bagian dari software requirement analysis yang divalidasi berdasarkan software yang dibentuk.
— Terakhir pada system testing dimana software dan element system lainnya dites secara keseluruhan

Langkah-langkah Pengujian Software

Terdapat 4 langkah yaitu:
— Unit testing-testing per unit yaitu mencoba alur yang spesifik pada struktur modul kontrol untuk memastikan pelengkapan secara penuh dan pendeteksian error secara maksimum
— Integration testing –testing per penggabungan unit yaitu pengalamatan dari isu-isu yang diasosiasikan dengan masalah ganda pada verifikasi dan konstruksi program
— High-order test yaitu terjadi ketika software telah selesai diintegrasikan atau dibangun menjadi satu –tidak terpisah-pisah
— Validation test yaitu menyediakan jaminan akhir bahwa software memenuhi semua kebutuhan fungsional, kepribadian dan performa.
Kriteria dari Testing yang telah selesai
• Dengan menggunakan model statisitik dan teori software reliability, model dari kegagalan software-yang tidak terdeteksi selama testing-sebagai fungsi dari waktu eksekusi dapat dikembangkan
• Sebuah versi dari model kegagalan yang disebut logarithmic Poisson execution-time model, memiliki bentuk

Fungsi diatas dapat disederhanakan menjadi
Keterangan
f(t)=jumlah kegagalan secara kumulatif yang diharapkan terjadi ketika software telah diuji dalam waktu tertentu, t.
l0 = inisial intensitas kegagalan software(kegagalan per unit dalam satuan waktu) pada awal testing
p = reduksi secara eksponensial pada intensitas kegagalan atas error yang tidak terdeteksi dan perbaikan yang dibuat
Grafik intensitas kegagalan sebagai fungsi dari waktu eksekusi

Argumen Tom Gilb
Yang menyatakan bahwa prosedur berikut harus digunakan jika ingin mengimplementasikan software testing strategy yang sukses
1. Menetapkan seluruh kebutuhan produk software dalam perhitungan sebelum memulai testing
2. Status obyek testing harus jelas
3. Memahami pengguna software dan mengembangkan sebuah profil untuk setiap kategori user
4. Mengembangkan rencana testing yang menekankan pada “rapid cycle testing”
5. Membangun software yang sempurna yang didesain untuk mengetes dirinya sendiri
6. Menggunakan tinjauan ulang yang formal sebagai filter sebelum pengujian
7. Melakukan tinjauan ulang secara formal untuk menilai strategi tes dan kasus tes itu sendiri
8. Mengembangkan pendekatan peningkatan yang berkelanjutan untuk proses testing

Test Unit (Test Level Komponen)
Pengujian unit: Komponen individual yang diuji secara independen untuk memastikan kualitasnya. Fokusnya untuk tidak menutup error pada desain dan implementasi, meliputi:
struktur data pada sebuah komponen
logika program dan struktur program pada sebuah komponen
interface komponen
fungsi dan operasi dari sebuah component
Penguji/tester unit: pengembang dari komponen.

Test Integrasi
Test Integrasi: Sebuah group dari component dependent diuji bersama untuk memastikan kualitas dari unit integrasinya. Merupakan teknik sistematik untuk membangun struktur program pada saat melakukan testing untuk mencari error. Secara obyektif untuk mengambil modul unit test dan membangun struktur program yang telah dirancang oleh desainnya
Fokusnya untuk meng-uncover error pada:
ü Desain dan konstruksi arsitektur software
ü Fungsi-fungsi yang terintegrasi atau operasi pada level sub-system
ü Interface dan interaksi diantaranya
ü Integrasi resource dan/atau integrasi lingkungan
Penguji integration: pengembang dan/atau test engineer.
Strategi Pengujian Integrasi
Pendekatan:

a) integrasi non-incremental
b) integrasi incremental
Integrasi non-incremental :
- Big Band
- menggabungkan (atau mengintegrasi) semua bagian dalam sekali.
Keuntungan: - sederhana
Kerugian:
- sulit untuk men-debug, tidak mudah untuk mengisolasi error
- tidak mudah untuk memvalidasi hasil test
- mustahil untuk membentuk sebuah sistem terintegrasi impossible

Integrasi incremental:
mengintegrasi sistem tahap demi tahap(atau bagian demi bagian) dalam sebuah pesanan yang didesain dengan baik.
Tiga metode penting:
a) Top-down
b) bottom-up
c) Sandwich
- menggunakan top-down untuk modul upper-level dan bottom-up untuk modul low-level

Integrasi Top-down
Ide:
- Modul-modul diintegrasi dengan memindahkan downward melalui struktur kontrol. Modul subordinate ke modul kontrol utama digabung ke sistem dalam cara depth-first atau breadth-first.

Proses integrasi(lima langkah):
1. modul kontrol utama digunakan sebagai sebuah test driver, dan stubs disubstitusi untuk semua modul secara langsung ke modul kontrol utama.
2. stub subordinate digantikan sekali satu waktu dengan modul actual.
3. test terkonduksi sebagai tiap modul diintegrasi.
4. pada pelengkapan tiap kumpulan test, stub lainnya diganti dengan modul real.
5. pengujian regresi dapat dikonduksi.
Integration top-down pros dan cons :
- biaya kostruksi stub
- fungsi kontrol utama dapat diuji lebih cepat.

Integrasi Bottom-Up
Ide:
- Modul pada level terbawah diintegrasi pertama, kemudian dengan menggerakkan keatas melalui struktur kontrol.
Proses integration(lima langkah):
1. Modul low-level dikombinasikan ke cluster yang menunjukkan sebuah sub-function software spesifik.
2. sebuah driver ditulis untuk meng-coordinate input dan output test case.
3. Test cluster diuji.
4. Driver dipindah dan cluster digabungkan bergerak ke atas dalam struktur program.
Integrasi bottom-up pros dan cons:
- tidak ada biaya stub
- perlu pengujian driver
- tidak ada sistem yang dapat dikontrol hingga langkah terakhir

Regression Testing
Merupakan aktivitas yang membantu untuk memastikan sebuah perubahan (yang berkaitan dengan testing atau penjelasan lain) tidak menghasilkan perilaku yang tidak diharapkan atau error tambahan
Regression tes terdiri dari 3 kelas, yaitu:
— Sebuah Contoh yang mewakili tes yang akan menguji semua fungsi software
— Tes tambahan yang berfokus pada fungsi software yang tampak yang akan berubah akibat perubahan lain
— Tes yang berfokus pada komponen software yang telah berubah
Validation testing
Uji Validasi : Software yang berintegrasi diuji berdasarkan pada kebutuhan untuk memastikan bahwa kita memiliki produk yang benar.
— Fokus-nya adalah untuk meng-uncover error pada:
- Input/output sistem
— - Informasi fungsi sistem dan data
— - Interface sistem dengan bagian eksternal
— - User interface
— - Perilaku dan performance sistem
Penguji validasi : uji engineer pada orang-orang ITG atau SQA.

Uji Sistem
Uji sistem: Sistem software diuji keseluruhan. Ini memverifikasi semua elemen secara langsung untuk memastikan bahwa semua fungsi dan performance sistem diterima dalam lingkungan target.
Terbagi menjadi 4 bagian yaitu
— Recovery Testing : sistem tes yang menekan software untuk gagal dengan cara yang bervariasi dan memverifikasi perbaikan sendiri dengan baik
— Security Testing : usaha untuk memverifikasi mekanisme perlindungan yang dibuat dalam sistem apakah akan melindunginya dengan semestinya.
— Stress Testing : didesain untuk menghadapi program dengan situasi abnormal.
— Performance Testing : didesain untuk menguji performa software ketika bekerja dalam konteks pengintegraian sistem.
— Pengujian instalasi : didesain untuk menguji prosedur instalasi dan software pendukungnya
Area fokus adalah:
— Fungsi dan performance sistem
— Reliability(ketersediaan) dan recoverability (kemampuan menutup/recovery test) sistem
— Instalasi (uji instalasi) sistem
— Perilaku pada kondisi tertentu (uji tekanan dan load) sistem
— Operasi user (acceptance test/alpha test/) sistem
— Integrasi dan kolaborasi hardware dan software
— Integrasi software eksternal dan sistem
Penguji sistem : uji engineer pada orang-orang ITG atau SQA.
Saat sebuah sistem akan dikeluarkan sebagai sebuah produk software, suatu proses pengujian yang disebut pengujian beta sering digunakan.
Rencana Uji
Rencana uji berhubungan dengan mengeset standar untuk pengujian proses dibanding penggambaran pengujian produk.
Test plan/rencana uji terdiri atas:
- standar untuk proses pengujian
- resource yang diperlukan (hardware, software dan engineer)
- jadwal pengujian (pengujian task dan milestones)
- uji item (apa yang harus diuji)
- prosedur recording test
(hasil test harus secara sistematis direkam)
- constraint
Test planning adalah sebuah dari suatu test manager.
Sebuah test plan adalah output dari perencanaan.
(Gambar berikut)

Debugging
— Gejalanya mungkin sebagai hasil dari masalah pemilihan waktu dibanding masalah proses
— Kemungkinan sulit secara akurat mereproduksi kondisi input
— Gejalanya mungkin terjadi dalam waktu yang dekat berkelanjutan
— Gejalanya mungkin berkaitan dengan penyebab yang didistribusikan melewati sejumlah task yang berjalan pada prosesor yang berbeda
Terdapat 3 kategori pendekatan Debugging
1. Brute force : metode yang paling umum dan lebih efisien untuk mengisolasi penyebab dari error software
2. Backtracking : metode yang dapat berhasil pada program kecil
3. Cause elimination : perwujudan dari induksi atau deduksi dan pengenalan dari konsep binary partitioning
Test Issues pada Dunia Nyata
Pengujian software sangat mahal.
Bagaimana mendapat pengujian secara otomatis??????
Kriteria pengujian, lingkup pengujian, pengujian adequate.
Pengujian software lainnya:
Pengujian GUI
Pengujian Software Berorientasi Object
Pengujian Komponen dan Pengujian Berbasis Komponen Software
Pengujian Fitur spesifik Domain
Pengujian Sistem Berbasis Web

The End
Ard fachruz
5105100118

Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner, saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.
Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang keefektifannya.
Selain itu, saat ini juga ada model-model proses hasil pengembangan seperti Agile modelling, XP (Xtreeme Programming), RUP, dan MSF.
a. Waterfall/Linear Sequential Model
Model ini adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Berikut ini ada dua gambaran dari waterfall model. Sekalipun keduanya menggunakan nama-nama fase yang berbeda, namun sama dalam intinya.
Fase-fase dalam Waterfall Model menurut referensi Pressman:

Fase-fase dalam Waterfall Model menurut referensi Sommerville:

Dimodelkan setelah siklus rekysa konvensional, model sekuensial linier melingkupi aktivitas – aktivitas sebagai berikut:
1. Rekayasa dan pemodelan sistem/informasi
Karena sistem merupakan bagian dari sebuah sistem yang lebihbesar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke software tersebut. Pandangan sistem ini penting ketika software harus berhubungan dengan elemen-elemen yang lain seperti software, manusia, dan database. Rekayasa dan anasisis sistem menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.
2. Analisis kebutuhan Software
Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khusunya pada software. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan baik untuk sistem maupun software didokumentasikan dan dilihat lagi dengan pelanggan.
3. Desain
Desain software sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda struktur data, arsitektur software, representasi interface, dan detail (algoritma) prosedural. Proses desain menterjemahkan syarat/kebutuhan ke dalam sebuah representasi software yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi software.
4. Generasi Kode
Desain harus diterjemahkan kedalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
5. Pengujian
Sekali program dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal software, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional, yaitu mengarahkan pengujian untuk menemukan kesalahan – kesalahan dan memastikan bahwa input yang dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.
6. Pemeliharaan
Software akan mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin adalah software yang dilekatkan). Perubahan akan terjadi karena kesalahan – kesalahan ditentukan, karena software harus disesuaikan untuk mengakomodasi perubahan – perubahan di dalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi.

Masalah dengan waterfall :
1. Perubahan sulit dilakukan karena sifatnya yang kaku.
2. 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.
3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.

b. Evolutionary Software Process Models
Bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir dari proses. Dua model dalam evolutionary software process model adalah:

1. Incremental Model

Keterangan:
1. Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan.
2. Element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.
3. Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan.
4. Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup.
5. Mampu mengakomodasi perubahan secara fleksibel.
6. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.

Masalah dengan Incremental model:
1. Cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)
2. Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment

2. Spiral model

Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor :
1. Objective settings (menentukan tujuan): menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.
2. Risk assessment and reduction (Penanganan dan pengurangan resiko): setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.
3. Development and Validation (Pembangunan dan pengujian): Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok.
4. Planning: Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya.

Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian sektor berikut pada model variasi spiral di bawah ini:

§ Customer communication: membangun komunikasi yang baik dengan pengguna/customer.
§ Planning: mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek
§ Risk analysis: identifikasi resiko managemen dan teknis
§ Engineering: pembangunan contoh-contoh aplikasi, misalnya prototype
§ Construction and release : pembangunan, test, install dan support.
§ Customer evaluation: mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi.

Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.

c. Transformasi formal
Metode ini berbasiskan pada transformasi spesifikasi secara matematik melalui representasi yang berbeda untuk suatu program yang dapat dieksekusi. Trasformasi menyatakan spesifikasi program
Menggunakan pendekatan ‘Cleanroom’ untuk pengembangan PL.

Metode ini mempunyai keterbatasan dalam pemakaiannya. Keunggulannya adalah mengurangi jumlah kesalahan pada sistem sehingga penggunaan utamanya adalah pada sistem yang kritis. Hal ini menjadi efektif dari segi biaya.
Pemakaian model pengembangan formal memerlukan tingkat kerahasian sebelum digunakan.
Permasalahan dalam model pengembangan metode formal:
• Memerlukan keahlian khusus dan pelatihan untuk mengaplikasikannya
• Sulit menentukan beberapa aspek dari suatu sistem seperti
user interface

c. Pengembangan Menggunakan Konsep Re-use (Penggunaan Ulang)
Metode ini didasarkan pada sistem yang telah tergabung dari
sejumlah komponen yang ada atau sistem COTS (Commercial-off-the-shelf)
Langkah-langkah proses:
• Analisis komponen
• Kebutuhan perubahan
• System design dengan penggunaan ulang
• Pengembangan dan Development dan penggabungan
Pendekatan ini menjadi penting tetapi tetap saja mempunyai keterbatasan dalam penggunaannya

MODEL RAPID APLICATION DEVELOPMENT

Rapin Aplication Development (RAD) adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut :

1. Bussiness modeling
Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan berikut : informasi apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya?

2. Data modeling
Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing–masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan.

3. Prosess modelling
Aliran informasi yang didefinisikan di dalam fase data modeling
ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.

4. Aplication generation
RAD mengasumsikan pemakaian teknik generasi ke empat. Selain
menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memkai lagi komponen program yang ada ( pada saat memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

5. Testing and turnover
Karena proses RAD menekankan pada pemakaian kembali, banyak
komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh.

Kekurangan model RAD adalah :
1. Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
2. RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.

Prototyping Model

Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software.
Proses pada model prototyping yang digambarkan pada gambar 1, bisa dijelaskan sebagai berikut:
· 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
· perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.
· 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. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari prototype , membantu mendapatkan kebutuhan detil lebih baik namun demikian prototype juga menimbulkan masalah:
1. Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.
2. Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.
Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

Component-based Development Model

Component-based development sangat berkaitan dengan teknologi berorientasi objek. Pada pemrograman berorientasi objek, banyak class yang dibangun dan menjadi komponen dalam suatu software. Class-class tersebut bersifat reusable artinya bisa digunakan kembali. Model ini bersifat iteratif atau berulang-ulang
prosesnya.
Secara umum proses yang terjadi dalam model ini adalah:
1. Identifikasi class-class yang akan digunakan kembali dengan menguji class tersebut dengan data yang akan dimanipulasi dengan aplikasi/software dan algoritma yang baru
2. Class yang dibuat pada proyek sebelumnya disimpan dalam class library, sehingga bisa langsung diambil dari library yang sudah ada. Jika ternyata ada kebutuhan class baru, maka class baru dibuat dengan metode berorientasi objek.
3. Bangun software dengan class-class yang sudah ditentukan atau class baru yang dibuat, integrasikan.

Penggunaan kembali komponen software yang sudah ada menguntungkan dari segi:
a. Siklus waktu pengembangan software, karena mampu mengurangi waktu 70%
b. Biaya produksi berkurang sampai 84% arena pembangunan komponen berkurang
Pembangunan software dengan menggunakan komponen yang sudah tersedia dapat menggunakan komponen COTS (Commercial off-the-shelf) – yang bisa didapatkan dengan membeli atau komponen yang sudah dibangun sebelumnya secara internal. Component-Based Software Engineering (CBSE) adalah proses yang menekankan perancangan dan pembangunan software dengan menggunakan komponen software yang sudah ada. CBSE terdiri dari dua bagian yang terjadi secara paralel yaitu software engineering (component-based development) dan domain engineering seperti yang digambarkan pada Gambar 2:
1. Domain engineering menciptakan model domain bagi aplikasi yang akan digunakan untuk menganalisis kebutuhan pengguna. Identifikasi, pembangunan, pengelompokan dan pengalokasikan komponen-komponen software supaya bisa digunakan pada sistem yang ada dan yang akan datang.
2. Software engineering (component-based development) melakukan analisis terhadap domain model yang sudah ditetapkan kemudian menentukan spesifikasi dan merancang berdasarkan model struktur dan spesifikasi sistem, kemudian melakukan pembangunan software dengan menggunakan komponen-komponen yang sudah ditetapkan berdasarkan analisis dan rancangan yang dihasilkan sebelumnya hingga akhirnya menghasilkan software.

Extreme Programming (XP) Model

Model proses ini diciptakan dan dikembangkan oleh Kent Beck. Model ini adalah model proses yang terbaru dalam dunia rekayasa perangkat lunak dan mencoba menjawab kesulitan dalam pengembangan software yang rumit dan sulit dalam implementasi.
Menurut Kent Beck XP adalah : “A lightweight, efficient, low-risk, flexible,predictable, scientific and fun way to develop software”. Suatu model yang menekankan pada:
- keterlibatan user secara langsung
- pengujian
- pay-as-you-go design

Adapun empat nilai penting dari XP
1. Communication/Komunikasi : komunikasi antara developer dan klien sering menjadi masalah. Karena itu komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Selain itu perkiraan beban tugas juga diperhitungkan.
2. Simplicity/ sederhana: Menekankan pada kesederhanaan dalam pengkodean: “What is the simplest thing that could possibly work?” Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan. Komunikasi yang lebih banyak mempermudah, dan rancangan yang sederhana mengurangi penjelasan.
3. Feedback / Masukan/Tanggapan: Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
4. Courage / Berani: Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.

Banyak cara yang bisa dilakukan untuk meningkatkan proses perangkat lunak. Tetapi, satu-satunya cara yang paling rasional untuk meningkatkan proses adalah dengan mengukur atribut tertentu dari proses, mengembangkan serangkaian metrik yang berarti berdasarkan atibut-atribut tersebut, dan kemudian metrik itu untuk memberikan indikator yang akan membawa kepada sebuah strategi pengembangan.

Dalam gambar diatas, proses berada ditengah-tengah sebuah segitiga yang menghubungkan tiga faktor yang sangat besar pengaruhnya terhadap kualitas perangkat lunak dan untuk kerja organisasional. Ketrampilan dan motivasi yang diperlihatkan manusia merupakan satu-satunya faktor yang paling berpengaruh pada kualitas dan untuk kerja tim. Teknologi yang menghuni proses juga berpengaruh. Segitiga proses yang berada dalam lingkaran yang menggambarkan kondisi lingkungan yang menyangkut lingkungan pengembangan, kondisi bisnis dan karakteristik pelanggan.

Mengukur realibilitas proyek perangkat lunak secara tidak langsung yaitu mengambl serangkaian metrik berdasarkan keluaran yang diambil oleh proses. Kelauaran menyangkut pengukuran kesalahan yang ditemukan sebelum pelepasan perangkat lunak, cacat yang disampaikan dan dilaprokan oleh pemakai akhir, produk kerja yang dikirim, usaha manusia yang dilakukan, waktu kalender yang digunakan, konfirmasi jadwal, serta pengukuran yang lain.

Metrik proses perangkat lunak dapat memberikan sumbangan yang berarti sebagai sesuatu kerja organisasi untuk meningkatkan keseluruhan level kematangan proses. Akan tetapi, seperti semua metrik, dapat digunkaan dengan salah, menimbulkan banyak masalah daripada yang mereka selesaikan. Pada saat organisasi menjadi lebih nyaman dengan kumpulan dan manfaat metrik proses, derivasi dari indikator sederhana memberikan suatu cara kepada suatu pendekatan yang lebih teliti yang disebut statistical software process improvement (SPPI). Pada dasarnya SPPI menggunakan analisis kegagalan perangkat lunak untuk mengumpulkan informasi seputar semua kesalahan dan cacat yng terjadi pada sebuah aplikasi, sistem , atau produk dikembangkan atau dipakai.

B. METRIK PROYEK

Metrik proses perangkat lunak digunakan untuk tujuan strategis. Pengukuran proyek perangkat lunak bersifat taktis, yaitu bahwa metrik proyek dan indikator yang berasal dari pengukuran digunakan oleh manajer proyek dan tim perangkat lunak untuk mengadaptasi aliran kerja proyek dan aktivitas teknis.

Aplikasi pertama dari metrik proyek pada sebagian besar proyek perangkat lunak terjadi selama perkiraan. Metrik yang dikumpulkan dari proyek yang terdahulu digunakan sebagai dasar untuk kerja perangkat lunak saat ini. Selagi sebuah proyek berjalan, pengukuran usaha dan waktu kalender yang digunakan dibandingkan dengan perkiraan awal. Manajer proyek menggunakan data tersebut untuk memeonitor dan mengkontrol kemajuan.

Pada saat kerja teknis dimulai, metrik proyek mulai memiliki arti. Nilai produksi yang disajikan dalam bentuk halaman dokumntasi, jam kajian, titik fungsi, dan deretan sumber yang disampaikan diukur, dan kesalahan selama masing-masing tugas kerja rekayasa perangkat lunak kemudian ditelusuri. Selagi perangkat lunak berjalan dari spesifikasi ke perancangan, metrik teknik dikumpulkan untuk memikirkan kualitas disain serta memberikan indikator yang akan mempengaruhi pendekatan yang akan diambil untuk memunculkan kode dan modul serta pengujian integrasi.

Metrik proyek mempunyai tujuan ganda. Pertama metrik tersebut digunakan untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yang diperlukan untuk menghindari penundaan serta mengurangi masalah dan resiko potensial. Kedua, metrik proyek ini dipakai untuk memperkirakan kualitas produk pada basis yang berlaku dan, bila dibutuhkan, memodifikasi pendekatan teknis untuk meningkatakan kualitas.

Model yang lain dari metrik proyek mengusulkan bahwa setiap proyek seharusnya mengukur :
a. input (pengukuran sumber daya seperti manusia, lingkungan yang dibutuhkan untuk melakukan pekerjaan)
b. output (pengukuran kemampuan penyampaian atau produk kerja yang diciptakan selama proses rekayasa perangkat lunak)
c. hasil (pengukuran yang menunjukkan efektifitas kemampuan penyampaian)

Macam-macam Metrik:
a. Metrik Size-Oriented
Ditarik dengan normalisasi kualitas dan atau pengukuran produktivitas dengan mempertimbangkan “ukuran” perangkat lunak yang dihasilkan.

b. Metrik Function-Oriented
Menggunakan sebuah pengukuran fungsionalis yang disampaikan oleh aplikasi sebagai suatu nilai normalisasi. Karena fungsionalitas tidak dapat diukur langsung, maka fungsionalitas harus ditarik secara tidak langsung dengan menggunakan pengukuran langsung yang lain.

c. Metrik Function-Oriented Yang Diperluas
Sama seperti Metrik Function point secara orisinil, hanya saja dilakukan penyempurnaan.

Faktor – faktor yang mempengaruhi Kualitas perangkat lunak
Lebih dari dua dekade lalu, McCall dan Cavano menetapkan sekumpulan faktor kualitas yang merupakan langkah pertama dalam mengembangkan metrik-metrik untuk kualitas perangkat lunak dari 3 sudut pandang berbeda, antara lain:
(1) operasi produk
(2) revisi produk
(3) transisi produk

Mengukur Kualitas
a.) Cara Yang Benar. Program harus beroprasi dengan benar atau program itu memberikan sedikit saja nilai bagi pemakainya. Tingkat dimana perangkat lunak melakukan fungsi yang ditentukan.
b.) Maintanabilitas. Kemudahan dimana program itu dapat dikoreksi jika ditemukan kesalahan, diadaptasi jika lingkungan berubah, atau diperkuat jika pelanggan menginginkan perubahan kebutuhan.
c.) Integritas. Mengukur kemampuan sistem untuk menahan serangan terhadap sekuritasnya.
d.) Usabilitas. Usaha untuk mengukur userfriendliness dan dapat diukur dalam empat karakteristik:
(1) keterampilan fisik dan atau intelektual untuk mempelajari sistem.
(2) waktu yang diperlukan untuk menjadi cukup efisien dalam menggunakan sistem.
(3) peningkatan bersih dalam produktifitas yang diukur ketika sistem digunakan oleh seseorang yang cukup efisien.
(4) penilaian subyektif dari sikap pemakai terhadap sistem.

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.

5.1 OBSERVASI PADA ESTIMASI

Estimasi yang diperlukan dalam perancangan proyek perangkat lunak di antaranya adalah sumber daya, biaya, dan jadwal sebagai usaha dalam pengembangan perangkat lunak, mengakses informasi historis yang baik, dan keberanian untuk melakukan pengukuran kuantitatif bila hanya data kualitatif saja yang ada. Berikut adalah yang menimbulkan ketidakpastian dalam estimasi :

- Project complexity (kompleksitas proyek) berpengaruh kuat terhadap ketidakpastian yang inheren dalam perencanaan. Komplekitas ini merupakan pengukuran relatif yang dipengaruhi oleh kebiasaan dengan usaha yang dilakukan sebelumnya.
- Project size (Ukuran proyek) Merupakan faktor penting yang dapat mempengaruhi akurasi estimasi. Bila ukuran bertambah maka ketergantungan di antara berbagai elemen perangkat lunak akan meningkat dengan cepat.
- Structural uncertainty (Ketidakpastian struktural) Tingkat ketidakpastian strutural juga berpengaruh dalam risiko estimasi. Dengan melihat kembali, kita dapat mengingat lagi hal-hal yang terjadi dan dapat menghindari tempat-tempat dimana masalah muncul.

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.

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

5.4 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)

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

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

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

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

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

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

5.7.2 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

5.7.2 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

5.8 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

[gambar 1]

► Entity Relationship Diagram (ERD) : Menggambarkan hubungan antara objek data.
► Data Flow Diagram (DFD) :
§ Memberikan indikasi mengenai bagaimana data ditranformasi pada saat data bergerak melalui sistem
§ Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentranformasi aliran data.
► State Transition Diagram (STD) :
Menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal.
► Dekripsi setiap fungsi yang disajikan pada DFD diisikan dalam sebuah spesifikasi proses / process specification (PSSPEC)
► Informasi tambahan mengenai aspek kontrol dari perangkat lunak diisikan dalam Control Specification (CSPEC)
Namun dalam pembahasan kali ini hanya akan dijelaskan Data Flow Diagram secara detail. Mengingat luas-nya materi pembahasan mengenai permodelan analisis, dan diharapkan dengan spesifik-nya materi pembahasan, pembaca diaharapkan dapat memahami dengan baik mengenai Data Flow Diagram.

WHAT IS DATA FLOW DIAGRAM a.ka DIAGRAM ALIRAN DATA?
DFD adalah sebuah teknik grafis yang menggambarkan aliran informasi dan tranformasi yang diaplikasikan pada saat data bergerak dari input menjadi output.
DFD juga dikenali sebagai grafik aliran data atau bubble chart. Bentuk dasar dari suatu aliran data sebagai beikut:

[gambar 2]

DFD dapat digunakan untuk menyajikan sebuah system atau perangkat lunak pada setiap tingkat abstaksi. DFD dapat dipartisi ke dalam tingkat-tingkat yang merepresentasikan aliran informasi yang bertambah dan fungs ideal.
DFD tingkat 0, yang disebut juga dengan model sistem fundamenatasi atau model konteks, merepresentasikan seluruh elemen sistem sebagai sebuah bubble tunggal dengan data input dan output yang ditunjukkan oleh anak panah yang masuk dan keluar secara berurutan. Proses tambahan (bubble) dan jalur aliran informasi direpresentasikan pada saat DFD tingkat 0 dipartisi untuk mengungkap setail yang lebih. Contohnya, sebuah DFD tingkat 1 dapat berisi lima atau enam bubble dengan anak panah yang saling menghubungka. Setiap proses yang direpresentasikan pada tingkat 1 merupakan subfungsi dari seluruh sistem yang digambarkan di dalam model konteks.

Prosedur atau konsumer informasi yang ada di luar bound sistem untuk dimodelkan

[gambar 3]

Transfer informasi (fungsi) yang ada di dalam bound sistem untuk dimodelkan

[gambar 4]

Objek data , anak panah menunjuk arah aliran data.

[gambar 5]

Repositori data yang disimpan untuk digunakan oleh satu atau lebih, proses dapat disederhanakan buffer atau queue. Atau serumit database relasional.

[gambar 6]

Penting untuk dicatat bahwa tidak ada indikasi eksplisit dari urutan pemrosesan yang didukung oleh diagram tersebut. Prosedur atau urutan dapat menjadi implicit di dalam diagram, tetapi representasi procedural biasanya ditunda sampai desain perangkat lunak.
Seperti telah diacatat sebelumnya, masing-masing bubble dapat direfinasi atau dilapisi untuk menggambarkan lebih setail. Gambar dibawah menggambarkan konsep ini. Perhatikan, sebuah model fundamental untuk sistem F yang menunjukkan input utama adalah A dan awal ouput B. Kemudian kita menyaring model F ke dalam tranformasi f1 sampai f7. Catatlah bahwa kontinuitas aliran informasi harus dijaga, yaitu input dan output ke masing-masing penyaringan harus tetap sama. Konsep ini, yang sering disebut dengan balancing, esensial bagi pengembangan model konsisten. Penyaringan lebih jauh dari f4 menggambarkan detail di dalam bentuk transformasi f41 sampai f45. Lagi, input (X,Y) dan output (Z) tetap tidak berubah.

[gambar 7]

Perlu diperhatikan disini, sebuah DFD dapat disalahinterpresentasikan jika fungsinya tidak sesuai dengan diagram alir. Sebuah DFD menggambarkan aliran informasi tanpa representasi logika procedural yang eksplisit (misalnya kondisi atau loop).
Contoh Data Flow Diagram

[gambar 8]

Pada tahun 1981, Barry Boehm mendesain COCOMO untuk memberikan estimasi / perkiraan jumlah Person-Months untuk mengembangkan suatu produk software. Referensi pada model ini dikenal dengan nama COCOMO 81.
Pada tahun 1990, muncul suatu model estimasi baru yang disebut dengan COCOMO II. Secara umum referensi COCOMO sebelum 1995 merujuk pada original COCOMO model yaitu COCOMO 81, kemudian setelah itu merujuk pada COCOMO II.
Model estimasi COCOMO telah digunakan oleh ribuan project manager suatu proyek perangkat lunak, dan berdasar pada pengalaman dari ratusan proyek sebelumnya. Tidak seperti model estimasi biaya yang lain, COCOMO adalah model terbuka, sehingga semua detail dipublikasikan, termasuk :
· Dasar persamaan perkiraan biaya
· Setiap asumsi yang dibuat dalam model
· Setiap definisi
· Biaya yang disertakan dalam perkiraan dinyatakan secara eksplisit
Perhitungan paling fundamental dalam COCOMO model adalah penggunaan Effort Equation (Persamaan Usaha) untuk mengestimasi jumlah dari Person-Months yang dibutuhkan untuk pengembangan proyek. Sebagian besar dari hasil-hasil lain COCOMO, termasuk estimasi untuk Requirement dan Maintenance berasal dari persamaan tersebut.

SOURCE LINE OF CODE

Perhitungan COCOMO didasarkan pada estimasi anda pada ukuran proyek dalam Source Line Of Code (SLOC). Pendefinisian SLOC:
· Hanya jumlah baris kode yang dikirim sebagai bagian dari produk yang disertakan (test drivers dan software pendukung lainnya tidak dihitung).
· Baris kode dibuat oleh staf proyek (kode yang di-generate oleh aplikasi tidak dihitung).
· Satu SLOC adalah satu baris kode secara logis.
· Deklarasi dihitung sebagai SLOC.
· Komentar tidak dihitung sebagai SLOC.
Model COCOMO 81 didefinisikan dalam bentuk Delivered Source Instruction, yang mana sangat menyerupai SLOC. Perbedaan utama antara DSI dan SLOC adalah sebuah SLOC mungkin merupakan beberapa baris secara fisik. Sebagai contoh, sebuah statement “if-then-else” akan dihitung sebagai satu SLOC, tetapi mungkin dihitung sebagai beberapa DSI.

SCALE DRIVERS

Pada model COCOMO II, beberapa factor terpenting yang berkontribusi pada durasi proyek dan biaya yang dikeluarkan adalah Scale Drivers. Anda mengeset setiap Scale Driver untuk mendeskripsikan proyek anda. Scale Drivers tersebut menentukan eksponen yang digunakan dalam Effort Equation.
Ada 5 Scale Drivers :
· Precedentedness
· Development Flexibility
· Architecture / Risk Resolution
· Team Cohesion
· Process Maturity
Catat bahwa Scale Drivers telah menggantikan Development Mode dari COCOMO 81. Dua Scale Drivers yang pertama, Precedentedness dan Development Flexibility sebenamya mendeskripsikan pengaruh yang hampir sama dibanding Development Mode.

COST DRIVERS

COCOMO II memiliki 17 cost drivers. Cost driver tersebut adalah factor pengali yang menentukan usaha yang diperlukan untuk menyelesaikan proyek software anda. Sebagai contoh, jika proyek anda akan mengembangkan software yang mengatur penerbangan pesawat, anda akan mengeset Required Software Reliability (RELY) cost driver menjadi sangat tinggi. Rating tersebut berhubungan dengan effort multiplier 1,26 yang berarti bahwa proyek anda akan membutuhkan usaha lebih sebesar 26% dibanding proyek software pada umumnya. COCOMO II mendefinisikan setiap cost drivers dan effort multiplier yang terhubung dengan setiap rating.

COCOMO II EFFORT EQUATION

Model COCOMO II membuat estimasi dari usaha yang dibutuhkan (diukur dari Person-Month) berdasarkan keutamaan dalam estimasi anda akan ukuran proyek perangkat lunak (yang diukur dalam ribuan SLOC atau KSLOC) :
Effort = 2,94 * EAF * (KSLOC)E
Dimana :
EAF = Effort Adjustment Factor yang berasal dari Cost Drivers
E = Eksponen yang berasal dari Scale Drivers.
Sebagai contoh, suatu proyek dengan semua Nominal Cost Drivers dan Scale Drivers akan memiliki sebuah EAF 1,00 dan eksponen (E) 1,0997. Diasumsikan bahwa proyek diproyeksikan terdiri atas 8.000 baris kode, COCOMO II mengestimasi bahwa 28,9 Person-Months effort diperlukan untuk menyelesaikannya :
Effort = 2.94 * (1.0) * (8)1.0997 = 28.9 Person-Months
EFFORT ADJUSTMENT FACTOR

Effort Adjustment Factor dalam effort equation adalah produk dari effort multipliers yang terhubung pada masing-masing cost drivers untuk proyek anda.
Sebagai contoh, jika proyek anda berating sangat tinggi untuk kompleksitas (effort multipliers 1,34) dan rendah untuk pengalaman language & tools (effort multipliers 1,09) dan semua cost drivers yang lain berating nominal (effort multipliers 1,00), sehingga EAF adalah produk dari 1,34 dan 1,09.
EAF= 1,34 * 1,09 = 1,46
Effort = 2,94 * (1,46) * (8)1,0097 = 42,3 Person-Months

COCOMO II SCHEDULE EQUATION

COCOMO II Schedule Equation memprediksi jumlah bulan yang dibutuhkan untuk menyelesaikan proyek perangkat lunak anda. Durasi dari proyek berdasarkan pada usaha yang diprediksi oleh effort equation :
Duration = 3,67 * (Effort)SE
Dimana :
Effort = usaha dari COCOMO II effort equation.
SE = eksponen scheduled equation yang berasal dari Scale Dirvers.
Melanjutkan contoh, dansubtitusi eksponen dengan 0.3179 yang dihitung dari scale drivers, menghasilkan estimasi hanya dalam satu tahun dan rata-rata staf antara 3 sampai 4 orang.
Duration = 3.67 * (42.3)0.3179 = 12.1 months
Average staffing = (42.3 Person-Months) / (12.1 Months) = 3.5 people

SCED COST DRIVER

COCOMO cost driver untuk Required Development Schedule (SCED) adalah unik dan memerlukan penjelasan special.
SCED cost driver digunakan untuk menghitung observasi bahwa proyek yang dikembangkan dalam jadwal yang dipercepat akan membutuhkan usaha yang lebih banyak dari proyek yang dikembangkan dalam jadwal optimal. Sebuah rating SCED yang sangat rendah diwakili oleh sebuah effort multipliers sebesar 1,43 dan berarti bahwa anda berniat menyelesaikan proyek anda dalam 75% jadwal optimal (yang ditentukan oleh estimasi COCOMO sebelumnya). Melanjutkan contoh yang digunakan tadi, tetapi diasumsikan bahwa SCED memiliki rating sangat rendah, COCOMO menghasilkan estimasi :
Duration = 75% * 12.1 Months = 9.1 Months
Effort Adjustment Factor = EAF = 1.34 * 1.09 * 1.43 = 2.09
Effort = 2.94 * (2.09) * (8)1.0997 = 60.4 Person-Months
Average staffing = (60.4 Person-Months) / (9.1 Months) = 6.7 people
Catat bahwa perhitungan durasi tidak berdasar secara langsung pada effort (jumlah Person-Months), justru hal tersebut berdasar pada jadwal yang akan diperlukan untuk proyek diasumsikan proyek tersebut telah berjalan dalam jadwal nominal. Ingat bahwa SCED cost driver berarti “percepatan dari jadwal nominal”.

COCOMO II

COCOMO II diset sebagai siklus hidup software modern. Orgininal COCOMO model sudah sangat berhasil, tetapi tidak sesuai dengan praktek pengembangan software yang lebih baru sebagaimana dengan software tradisional. COCOMO II menargetkan proyek software pada tahun 1990an sampai 2000an dan akan terus berkembang dalam beberapa tahun ke depan.
COCOMO II memiliki 3 model berbeda :
· The Application Composition Model
Sesuai untuk pembangunan proyek dengan tools GUI-builder yang modern. Berdasar pada Object Points baru.
· The Early Design Model
Anda bisa menggunakan model ini untuk mendapat estimasi kasar biaya dan durasi dari suatu proyek sebelum anda menentukan arsitektur keseluruhan proyek tersebut. Model ini menggunakan sekumpulan kecil cost driver baru dan persamaan estimasi baru. Berdasar pada Unadjusted Function Points atau KSLOC.
· The Post-Architecture Model
Ini adalah model COCOMO II yang paling detail. Anda akan menggunakannya setelah anda membentuk arsitektur proyek anda secara menyeluruh. Model ini memiliki cost driver baru, aturan penghitungan baris yang baru, dan persamaan baru.

Mungkin yang paling dikenal baik dari software reuse adalah code. Ide dari penggunaan ulang code ialah sebagian atau keseluruhan program computer yg ditulis suatu ketika lalu digunakan oleh program lain yang di tulis kemudian. Penggunaan ulang code adalah teknik yg umum dilakukan untuk menghemat waktu dan energi untuk mengurangi pekerjaan. Contoh yang umum dari software reuse adalah Teknik penggunaan software library. Banyak operasi umum seperti konversi informasi diantara format yang berbeda, mengakses simpanan luar, berkomunikasi dengan external program, atau memanipulasi informasi (angka, kata, nama, lokasi., tanggal, dll) yang sering dibutuhkan oleh berbagi program berbeda. Pembuat program baru bisa menggunakan kode pada software library untuk melakukan tugas tertentu, bukan sebaliknya dengan menulis penuh program untuk melakukan tugas / operasi yg diinginkan. Implementasi dari libarary sering kali memberi keuntungan dalam menyelesaikan kasus yang tidak biasa.

2. Keuntungan dan masalah software reuse
Keuntungan software reuse.
a. Meningkatkan kepercayaan
Software yang akan digunakan kembali telah di tes dan dicoba pada sistemnya, sehingga lebih bisa dipercaya dari software baru. awal pembuatan dari software mendeteksi berbagai kesalahan desain dan implementasi. Ini kemudian diperbaiki, yang megurangi tingkat kegagalan saat software di gunakan kembali.
b. Mengurangi resiko
Jika sotware telah ada, ada pengurangan biaya dalam pembuatan software. Ini adalah factor yang penting untuk manajemen proyek untuk mengurang estimasi biaya proyek disisi kesalahan software. Hal ini lebih terlihat saat sejumlah besar komponen software digunakan kembali.
c. Lebih efektif untuk para spesialis
Para spesialis tidak perlu melakukan pekerjaan yang sama pada proyek berbeda. Para spesialis bisa menggunakan software sebelumnya dengan mengkapsulasi program mereka.
d. Standar pelaksanaan
Beberapa standar, seperti standar user interface, bisa diimplementasikan sebagai standard reusable component. Sebagai contoh interface menu bisa diimplementasikan memggunakan reusable component, semua aplikasi menyajikan format menu yang sama. Standar interface ini meningkatkan keyakinan user untuk mengurangi kesalahan ketika medapati interface yang familiar.
e. Percepatan pengembangan
Membawa software ke pasaran secepat mungkin adalah lebih penting dari semua biaya pengembangan. Reuse softrware dapat mempercepat produksi karena waktu pengembangan dan pengesahan software bisa dikurangi.

Masalah software reuse.
a. Meningkatkan biaya perawatan
Biaya perawatan mungkin akan bertambah saat reuse elemen dari suatu sistem memjadi semakin tidak sesuai dengan perubahan system.
b. Kekurangan tool pendukung
Toolset mungkin tidaksupport pembangunan software dengan model reuse. Ini mungkin sulit atau tidak mungkin untuk mengintegrasi tool – tool ini dengan sistem component library.
c. Sindrome Not-Invented-here
Beberapa software engineer kadang – kadang lebih suka menulis ulang reuse component sebagian dengan alasan dapat meningkatkan kegunaan reusable component, sebagian melakukan dengan kepercayaan bahwa fakta menulis original software adalah lebih menantang dari menggunakan software orang lain.
d. Membuat dan merawat komponen library
Menyusun sejumlah reusable componenet library dan menjamin pengembang bisa mengunakan library ini bisa menjadi mahal. Teknik umum kita untuk mengklasifikasi, mengkatalog, dan megambil komponen software adalah belum tepat.
e. Menemukan, mengerti dan mengadaptasikan komponen reusable
Komponen software harus ditemukan di library, dimengerti dan, kadang, diadaptasikan untuk bekerja di lingkungan baru. Engineer harus yakin untuk menemukan komponen di library sebelum mereka akan menyertakan komponen sebagai bagian dari proses pembangunan software mereka.
Software library adalah contoh yang bagus sebagai abstraksi. Programmer mungkin memutuskan untuk membuat abstraksi internal sehingga bagian dari program mereka bisa digunakan kembali, atau mungkin membuat library untuk digunakan sendiri. Untuk penggunaan code yang sudah ada, beberapa hal seperti interface, atau jalur komunikasi, harus didefinisikan. Ini umumnya termasuk penggunaan subroutine, object, class, atau prototype. Praktik seperti ini di formalisasi dan distandarisasi oleh software product line engineering. Praktek yang umum adalah pengunaan versi terdahulu dari program yg ada sebagai titik mulai dari versi selajutnya juga disebut dengan software reuse.
3. Landasan software reuse (reuse landscape)
Meskipun reuse sering disederhanakan sebagai sebuah komponen sistem, ada banyak pendekatan berbeda untuk menggunakan kembali software. Reuse dimungkinkan untuk selang level dari fungsi simple sampai aplikasi komplit. landscape reuse memberi landasan pemahaman dalam pengaplikasian reuse.

[gambar 1]

a. Design patterns (Pola desain) : Abstraksi umum yang terjadi dalam memperesentasikan aplikasi dalam sebuah desain yang menunjukkan astraksi umum, objek konkret dan interaksi.
b. Component-based development (pembangunan berbasis komponen) : system dibangun dengan mengintegrasikan komponen yang sesuai dengan model standar komponen.
c. Aplication framework (Kerangka aplikasi) : koleksi dari abstrak dan class konkret yang bisa diadaptasikan dan diperluas untuk membuat aplikasi system.
d. Legacy system wrapping : kebijaksaaan sistem yang bisa disatukan dengan mendefisniskan seset interface dan menyediakan akses ke kebijaksanaan system ini melalui interface.
e. Service oriented system (system berorientasi service) : sistem yang dibangun dengan menghubungkan share service yang mungkin disediakan pihak luar.
f. Application product lines : sebuah tipe aplikasi yang umum pada arsitekture software sehingga bisa diadaptasiakan dengan cara berbeda utuk costumer berbeda.
g. Program libraries (Program library) : Library Class dan function yang mengimplementasikan code yang siap digunakan.
h. Program generators : Sebuah generator system yang bisa menghsilkan system atau software dengan menspesifikasikan type parameter / hasil yang diinginkan.
Beberapa meyebut penggunaan ulang kode adalah termasuk juga mengkopi beberapa atau sebagian code dari program yang sudah ada ke program baru. Dengan menyadari nilai dari produk baru, mereka bisa bersedih hati kemudian hari dengan adanya banyak code yg sama disebabkan cut dan paste programming yang membuat kebutuham memory lebih besar. Banyak penelitian yg telah dilakukan untuk membuat reuse lebih cepat, mudah, lebih sistematik, dan dalam sebuah kesatuan proses normal pemrograman. Ini adalah tujuan utama dibalik penemuan pemrograman berbasis objek (object oriented programaing), dimana menjadi salah satu bentuk yang paling umum dari penggunaan ulang program yang formal (formalized reuse). Dimana kemudian melahirkan penemuan yang disebut generic programming.
Alat terbaru yang lain disebut dengan software generator, program yang bisa membuat program baru dari sebuah tipe yang ditentukan. Didasarkan pada sekumpulan parameter yang user pilih. Bidang study dari system seperti ini disebut generative progrmaing dan net progrmaing.
Just little thing,,, wish for better