Model ini diawali dengan penentuan kebutuhan oleh user. Pengembang akan mengumpulkan informasi-informasi mengenai kebutuhan user tersebut dan kemudian membuat sebuah prototype dari perangkat lunak yang akan dikembangkan. Model ini sangat cocok bagi user awam, sehingga dengan adanya prototype pemahaman mereka akan terbantu dan mereka mempunyai landasan dan acuan dalam tahapan selanjutnya, misalnya pada tahapan pengujian perangkat lunak.
McLeod dan Schell (2007) mendifiniskan 2 (dua) tipe dari prototype yaitu:
1. 1. Evolutionary Prototype
2. 2. Requirements Prototype
Evolutionary prototype yaitu, prototype yang secara terus menerus dikembangkan hingga prototype tersebut memenuhi fungsi dan prosedur yang dibutuhkan oleh sistem. Berikut gambar dari tahapan evolutionary prototype:

Gambar: Evolutionary Prototyping Model.
1. Analisis kebutuhan user, pengembang dan pengguna atau pemilik sistem melakukan diskusi dimana pengguna atau pemilik sistem menjelaskan kepada pengembang tentang kebutuhan sistem yang mereka inginkan.
2. Membuat prototype, pengembang membuat prototype dari sistem yang telah dijelaskan oleh pengguna atau pemilik sistem.
3. Menyesuaikan prototype dengan keinginan user, pengembang menanyakan kepada pengguna atau pemilik sistem tentang prototype yang sudah dibuat, apakah sesuai atau tidak dengan kebutuhan sistem.
4. Menggunakan prototype, sistem mulai dikembangkan dengan prototype yang sudah dibuat.
Requirement prototype merupakan prototype yang dibuat oleh pengembang dengan mendifiniskan fungsi dan prosedur sistem dimana pengguna atau pemilik sistem tidak bisa mendefinisikan sistem tersebut. Berikut ini langkah-langkah dari requirement prototype :

Gambar: Requirement Prototype Model
1. Analisis kebutuhan user, pengembang dan pengguna atau pemilik sistem melakukan diskusi dimana pengguna atau pemilik sistem menjelaskan kepada pengembang tentang kebutuhan sistem yang mereka inginkan.
2. Membuat prototype, pengembang membuat prototype dari sistem yang telah dijelaskan oleh pengguna atau pemilik sistem.
3. Menyesuaikan prototype dengan keinginan user, pengembang menanyakan kepada pengguna atau pemilik sistem tentang prototype yang sudah dibuat, apakah sesuai atau tidak dengan kebutuhan sistem.
4. Membuat sistem baru, pengembang menggunakan prototype yang sudah dibuat untuk membuat sistem baru.
5. Melakukan testing sistem, pengguna atau pemilik sistem melakukan uji coba terhadap sistem yang dikembangkan
6. Menyesuaikan dengan keinginan user, sistem disesuaikan dengan keinginan user dan kebutuhan sistem, jika sudah sesuai sistem siap digunakan.
7. Menggunakan sistem.
Kelebihan dari teknik pengembangan prototyping yaitu :
1. Menghemat waktu pengembangan.
2. Menghemat biaya pengembangan.
3. Pengguna atau pemilik sistem ikut terlibat dalam pengembangan, sehingga kemungkinan-kemungkinan terjadinya kesalahpahaman dalam sistem bisa diminimalisir.
4. Implementasi akan menjadi mudah, karena pengguna atau pemilik sistem sudah mempunyai gambaran tentang sistem.
5. Kualitas sistem yang dihasilkan baik.
6. Memungkinan tim pengembang sistem memprediksi dan memperkirakan pengembangan-pengembangan sistem selanjutnya.
Sedangkan kelemahannya adalah :
Pengguna atau pemilik sistem bisa terus menerus menambah kompleksitas sitem hingga sistem menjadi sangat kompleks, hal ini bisa menyebabkan pengembang meninggalkan pekerjaanya sehingga sistem yang dikerjaan tidak akan pernah terselesaikan.

Mungkin selama ini kita sudah sering mendengar kata Software, namun belum tahu definisinya. berikut ini merupakan pengertian software berdasarkan hasil kesepakatan dalam forum Internasional, sebagaimana berikut :

Menurut IEEE :

Software adalah Program komputer, prosedur, dan dokumentasi kemungkinan terkait dan data yang berkaitan dengan pengoperasian sistem komputer.

Komponen dari Softaware ada 4 berdasarkan IEEE dan ISO, yaitu :

1. Program Komputer ( Code )
2. Prosedur
3. Dokumentasi
4. Data yang diperlukan untuk mengoperasikan perangkat lunak (Software).

Kualitas produk adalah :

1. Kesesuaian dengan kebutuhan

2. Kelayakan untuk digunakan

3. Bebas dari error dan failure

4. Kepuasan customer

Faktor-faktor yang mempengaruhi kualitas sebuah software adalah

1. Kualitas Program Komputer / Code
2. Kualitas dari Prosedur
3. Kualitas dari Dokumentasi
4. Kualitas dari data yang diperlukan.

Setiap softaware yang telah dibuat, semuanya memiliki kemungkinan untuk terjadi error atau punya error. Errornya dapat disebabkan karena rendahnya kualitas dari software, namun sangat penting bagi kita untuk mencari tahu apa saja penyebab dari error tersebut.

Selain itu bisa juga terjadi karena terdapat masalah pada masing-masing komponennya, misalakan :

1. Karena kodenya yang bermasalah / error
2. Prosedurnya yang error
3. Dokumentasinya yang error
4. Error Pada data Software.

Berikut ini 9 penyebab terjadinya Error pada Software :

1. Dokumen Requirement yang kurang tepat
2. Kegagalan komunikasi antara Developer dan Client
3. Penyimpangan pada Software Requirement.
4. Kesalahan pada Logical Desain
5. Kesalahan Coding
6. Ketidak sesuaian dengan dokumentasi dan petunjuk koding
7. Pemotongan / percepatan pada proses pengujian (Testing)
8. Kesalahan Prosedur
9. Kesalahan pada Dokumentasi

Kesalahan Perangkat Lunak :

1. Software error : bagian code yang sebagiannya atau keseluruhannya salah, yang diakibatkan oleh kesalahan gramatical, logical, atau kesalahan lain yang dibuat oleh analis sistem, programmer atau anggota lain yang terlibat dalam tim pengembangan PL

2. Software defect : bagian PL yang tidak memenuhi dokumentasi pengembangan PL

3. Software fault : software error yang menyebabkan kesalahan fungsional

4. Software failure : kesalahan PL yang terjadi ketika user meminta bagian PL yang fault. Sumbersoftware failure adalah software error.

Alasan memperhatikan kualitas PL : karena kualitas adalah :

1. Masalah persaingan

2. Penting supaya dapat survive

3. Penting untuk global marketing

4. Mengefektifkan biaya

5. Mempertahankan customer dan meningkatkan keuntungan

Faktor kualitas PL dikelompokkan menjadi tiga kategori :

• Faktor operasi produk

Correctness : daftar sistem PL yang memberikan output yang benar sesuai dengan spesifikasi kebutuhan PL

Reliability : maksimum terjadi failure yang dibolehkan

Efficiency : berhubungan dengan sumber daya hardware untuk
melakukan semua fungsi sistem PL dalam melayani kebutuhan

Integrity : berhubungan dengan security sistem, pencegahan akses untuk orang-orang yang tidak berhak, pembedaan user yang dapat melakukan create, read, update, delete (CRUD)

Usability : berhubungan dengan sumber daya pegawai yang diperlukan untuk melatih pegawai baru dan mengoperasikan sistem PL

• Faktor revisi produk

Maintainability : mendefinisikan usaha yang diperlukan user dan personil perawatan untuk mengidentifikasi alasan software failure dan membuktikan keberhasilan perbaikan

Flexibility : kemampuan dan usaha yang diperlukan untuk mendukung aktivitas adaptive maintenance

Testability : berhubungan dengan testing

• Faktor transisi produk

Portability : adaptasi sistem PL dengan lingkungan lain yang mencakup perbedaan hardware, sistem operasi, dll

Reusability : berhubungan dengan penggunaan modul asli PL yang didesain untuk project baru yang dibangun

Interoperability : fokus pada pembuatan interface dengan sistem PL lain atau dengan peralatan perusahaan lain

Jenis-jenis maintenance Perangkat Lunak :

· Corrective maintenance : koreksi error-error yang muncul pada saat PL mulai digunakan

· Adaptive maintenance : adaptasi terhadap perubahan-perubahan, new release, tidak merubah fungsi atau unjuk kerja

· Perfective maintenance : PL masih OK, tapi dibutuhkan fungsi-fungsi / fitur-fitur baru

· Preventive maintenance : reverse engineering dan re-engineering

Parameter kualitas Perangkat Lunak :

• Parameter teknis (objektif) : solusi teknis

Correctness : ukuran tingkat defect

Reliability : ukuran failure

Capability : ukuran requirement coverage

Performance : ukuran kecepatan dan penggunaan sumber daya

Maintainability : ukuran change log

• Parameter user (subjektif) : solusi non teknis

Usability : berapa % user senang dengan interface dan kemudahan penggunaan

Installability : jumlah masalah instalasi yang dilaporan per instalasi

Documentation : berapa % user senang dengan dokumentasi

Availability : berapa % user melaporkan masalah akses

Biaya kualitas PL

Standarisasi, sertifikasi, dan penilaian sistem SQA :

• Tujuan :
• Pengetahuan profesional internasional
• Perbaikan koordinasi kualitas sistem organisasi dengan organisasi lain yang sejenis
• Penilaian pencapaian kualitas sistem sesuai dengan skala umum

Standar yang digunakan :

- Standar manajemen kualitas : SEI CMM, ISO 9001, dan ISO 9000-3

- Standar proses proyek : IEEE 1012, ISO / IEC 12207

Pembangunan dan rencana kualitas

• Jadwal
• Kebutuhan manpower dan sumber daya hardware
• Evaluasi risiko
• Persoalan organisasi : anggota tim, sub kontraktor, dan rekanan
• Metodologi proyek, tools pengembangan, dll
• Rencana penggunaan ulang perangkat lunak (PL)
• Penilaian aktivitas daur hidup proyek ada dua tahap, yaitu :

Tahap siklus hidup pengembangan : mendeteksi kesalahan desain dan programming

• Review
• Pendapat ahli
• Pengujian PL
• Jaminan kualitas untuk pekerjaan sub kontraktor dan kesediaan pelanggan

Tahap operasi maintenance

- Corrective maintenance

- Adaptive maintenance

- Functionality improvement maintenance

• Komponen pre-maintenance :

- Maintenance kontrak review

- Rencana maintenance

• Komponen infrastruktur Softwate Quality Accurance :

- Prosedur maintenance dan instruksi

- Dukungan perlengkapan kualitas

- Maintenance pelatihan staf, pelatihan ulang, dan sertifikasi

- Tindakan preventive dan corrective maintenance

- Manajemen konfigurasi

- Kontrol dokumentasi maintenance dan laporan kualitas

• Kontrol manajerial komponen Softwate Quality Accurance :

- Kontrol maintenance servis

- Metriks maintenance kualitas

- Biaya maintenance kualitas

Definisi Software Quality Accurance (SQA) :

Menurut IEEE

• Pola yang terencana dan sistematis dari semua tindakan yang diperlukan untuk menyediakan kepercayaan yang cukup terhadap suatu item atau produk disesuaikan ke kebutuhan teknis

Kumpulan aktivitas yang didesain untuk mengevaluasi proses di mana produk dihasilkan

Tujuan SQA :

Software development (process-oriented)

• Menjamin suatu level penerimaan bahwa PL sesuai dengan requirement fungsional
• Menjamin suatu level penerimaan bahwa PL sesuai dengan jadwal managerial dan kebutuhan biaya
• Menginisialisasi dan mengatur aktivitas perbaikan dan peningkatan efisiensi pengembangan PL dan aktivitas SQA

Software maintenance (product oriented)

• Menjamin dengan level penerimaan bahwa aktivitas perawatan PL akan sesuai dengan kebutuhan fungsional
• Menjamin dengan level penerimaan bahwa aktivitas perawatan PL akan sesuai dengan jadwal dan kebutuhan biaya
• Menginisialisasi dan mengatur aktivitas perbaikan dan peningkatan efisiensi perawatan PL dan aktivitas SQA

http://nasrul-its.blogspot.com/2012/02/what-is-software-quality.html

http://dimas347.wordpress.com/2009/06/28/software-quality-management/

Rapid Application Development Model

Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan.^[1] Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.^[1]

Penerapan

Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :

1. Component based construction ( pemrograman berbasis komponen bukan prosedural).

2. Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.

3. Pembangkitan kode program otomatis/semi otomatis.

4. Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.

Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.

Kelebihan RAD

1. Hasil pengembangan bisa lebih cepat dibandingkan SDLC lainnya

2. Memerlukan biaya yang lebih sedikit

3. Mementingkan dari segi bisnis dan teknik

4. Berkonsentrasi pada sudut pandang user

5. Menyediakan kemungkinan perubahan secara cepat sesuai permintaan user

6. Menghasilkan jarak kesesuaian yang kecil antara kebutuhan user dan spesifikasi system

7. Waktu, biaya, dan effort minimal

Kelemahan/Kekurangan RAD

Beberapa hal (kelebhan dan kekurangan) yang perlu diperhatikan dalam implementasi pengembangan menggunakan model RAD :

1. Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar.

2. Model ini cocok untuk proyek dengan skala besar.

3. Model RAD memerlukan komitmen yang kuat antara pengembang dan pemesssan, bahkan keduanya bisa tergabung dalam 1 tim

4. kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan model ini kurang bagus.

5. sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.

6. penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan dan ini memerlukan kerja keras.

7. proyek bisa gagal karena waktu yang disepakati tidak dipenuhi

8. risiko teknis yang tinggi juga kurang cocok untuk model ini.

Fase-fase RAD

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

• Bagian dari pemodelan bisnis yang didefinisikan ke dalam sekumpulan objek data.

• Karakteristik (atribut) dari setiap objek diidentifikasikan dan hubungannya

3. Prosess modeling

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

• Objek data akan diimplementasikan pada fungsi bisnis.

• Deskripsi proses dibangun untuk penambahan modifikasi, penghapusan, atau pengambilan kembali objek data.

4. Aplication generation

• RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional.

• Melakukan penggunaan kembali komponen yang ada (jika mungkin)

• Atau membuat kembali penggunaan kembali komponen jika dibutuhkan.

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.