Kualitas Perangkat Lunak

Berbagai macam definisi kualitas perangkat lunak (software quality) tergantung dari mana pemakai (user) memandang dan melihat sesuai dengan kebutuhannya. Menurut Crosby (1979:34) mendefinisikan kualitas atau mutu sebagai “conformance to requirements”. Selama seseorang dapat berdebat tentang perbedaan antara kebutuhan, keinginan dan kemauannya, definisi kualitas harus mempertimbangkan perspektif pemakai tersebut. Kunci utama pertanyaan untuk sebuah definisi kualitas adalah siapa pemakainya, apa yang penting bagi merekadan bagaimana prioritasnya tentang metode apa yang dibangun, dibungkus untuk mendukung sebuah produk?

Software Quality didefinisikan sebagai: kesesuaian yang diharapkan pada semua software yang dibangun dalam hal fungsi software yang diutamakan dan unjuk kerja software, standar pembangunan software yang terdokumentasi dan karakteristik yang ditunjukkan oleh software. Definisi ini menekankan pada 3 hal yaitu:

1. kebutuhan software adalah fondasi ukuran kualitas software, jika software. Tidak sesuai dengan kebutuhan yang ditentukan maka kualitaspun kurang

2. jika menggunakan suatu standar untuk pembangunan software maka jika software tidak memenuhi standar tersebut maka dianggap kurang berkualitas

3. seringkali ada kualitas yang secara langsung diutarakan (tersirat) seperti  kemudahan penggunaan dan pemeliharaan yang baik. Kualitas software dipertanyakan jika tidak memenuhi kebutuhan ini.

Pengukuran Kualitas Perangkat Lunak

Sistem dari kualitas perangkat lunak terintegrasi dalam tiga disiplin aplikasi yaitu: pemodelan proses pengembangan (process), pemodelan pengukuran produk (product), dan pemodelan manajemen dan interaksi manusia (human). Pemahaman suatu disiplin melibatkan pembangunan model, pengujian model dan pelajaran untuk dipahami dalam aplikasi yang nyatal. Pengembang kualitas prima perangkat lunak harus berhadapan dengan unsur-unsur matriks berikut:

Model [M] [M*PROCESS] [M*PRODUCT] [M*HUMAN]

Testing [T] Process Product Human = [T*PROCESS] [T*PRODUCT]   [T*HUMAN]

Data [D] [D*PROCESS] [D*PRODUCT] [D*HUMAN]

Unsur-unsur perangkat lunak utama dari sistem kualitas perangkat lunak ditunjukkan pada gambar di bawah. Pengintegrasian dari semua unsur-unsur system kualitas memerlukan suatu model. Permasalahannya untuk diperbaiki oleh dua model berikut (1) penanganan kompleksitas dalam disiplin dari sistem kualitas dantunsur-unsurnya dan (2) penunjukan beberapa kelemahan dari model existing process. Kompleksitas proses pengembangan dan dokumentasinya serta perubahan dokumentasi selama pemeliharaan adalah permasalahan penting dalam peningkatan kualitas. Dokumentasi yang dievaluasi sering sangat banyak dan kompleks. Oleh karena itu, hubungan kompleksitas antara produk data teknis, dokumentasi perencanaan, pengujian kebutuhan dan tahapan unsur-unsur life cycle pengembangan yang berbeda mengakibatkan dokumentasi ini sulit untuk dievaluasi dalam meyakinkan semua aktivitas telah cukup dikerjakan. Dokumentasi menyediakan komunikasi antar semua kelompok terkait dengan pengembangannya dan kendali proses proyek tersebut. Schweiggert mencatat beberapa pertimbangan untuk krisis dokumentasi:

“Software in the application process must be constantly adapted and altered. The

maintenance programmer usually does not have the time alteration to

documentation. Often suitable tools are not available either. This causes the

quality of documentation to suffer”

Metoda tradisional untuk verifikasi kualitas, seperti checklist bisa gagal dalam proses pengembangan software yang kompleks. Audit dan review tidak bisa dilakukan tanpa menggunakan bantuan dan alat yang membantu mengidentifikasi pemenuhan standar dan prosedur. Lebih dari itu, kompleksitas proses pengembangan dan perubahan yang tak terkontrol dari unsur-unsur proses secara negatif berdampak pada kualitas. Lifecycle pengembangan software yang berbeda dapat diusulkan. Hal ini dapat memungkinkan adanya perbedaan motivasi, kekuatan dan kelemahan. Tidak ada model lifecycle yang universal disesuaikan dengan lingkungan pengembangannya. Dalam model lifecycle tradisional, hubungan antara tahapan unsur-unsur lifecycle pengembangan software yang berbeda tidaklah cukup terwakili. Oleh karena itu, sulit untuk menguraikan efek segala perubahan dalam kebutuhannya yang ditetapkan atas kualitas, keselamatan dan sasaran hasil dari perangkat lunak. Lebih dari itu, keberadaan komputer dapat membantu untuk aplikasi model proses yang tidak fleksibel dan sulit untuk ditangani karena kekompleksitasnya. Dalam lifecycle pengembangan software, Identifikasi hubungan antara kelompok organisasi sangat penting untuk beberapa

pertimbangan berikut: (1) Pengembangan Proses harus berhadapan dengan kompleksitas dan perubahan kebutuhan, pengujian metoda, teknologi, ukuran dan lain lain; (2) Kesalahan perangkat lunak yang dihasilkan baik dalam suatu tahapan proses pengembangan software maupun sebagai alat penghubung antara dua tahapan; (3) Dukungan kuat dari manajemen puncak merupakan suatu faktor utama dalam mempengaruhi proses pengembangan tersebut. Menururut Wahono (2006), Deras masuknya produk perangkat lunak dari luarnegeri di satu sisi menguntungkan pengguna karena banyaknya pilihan produk dan harga. Namun di sisi lain cukup mengkhawatirkan karena di Indonesia tidak ada institusi yang secara aktif bertugas membuat standard dalam pengukuran kualitas perangkat lunak yang masuk ke Indonesia. Demikian juga dengan produk-produk perangkat lunak lokal, tentu akan semakin meningkat daya saing internasionalnya apabila pengembang dan software house di Indonesia mulai memperhatikan masalah kualitas perangkat lunak ini. Kualitas perangkat lunak (software quality) adalah tema kajian dan penelitian turun temurun dalam sejarah ilmu rekayasa perangkat lunak (software engineering). Kajian dimulai dari apa yang akan diukur (apakah proses atau produk), apakah memang perangkat lunak bisa diukur, sudut pandang pengukur dan bagaimana menentukan parameter pengukuran kualitas perangkat lunak. Bagaimanapun juga mengukur kualitas perangkat lunak memang bukan pekerjaan mudah. Ketika seseorang memberi nilai sangat baik terhadap sebuah perangkat lunak, orang lain belum tentu mengatakan hal yang sama. Sudut pandang seseorang tersebut mungkin berorientasi ke satu sisi masalah (misalnya tentang reliabilitas dan efisiensi perangkat lunak), sedangkan orang lain yang menyatakan bahwa perangkat lunak itu buruk menggunakan sudut pandang yang lain lagi (usabilitas dan aspek desain).

Apa yang diukur?

Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat lunak, adalah apa yang sebenarnya mau kita ukur. Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan perangkat lunak ( process) dan hasil produk yang dihasilkan (product). Dan penilaian ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat dikembangkan sesuai dengan yang diharapkan oleh pengguna. Dari sudut pandang produk, pengukuran dapat dilakukan dengan cara sebagai berikut:

Parameter dan metode pengukuran menurut Kelvin dalam Wahono (2006), When you can measure what you are speaking about, and express it in numbers, you know something about it. But when you can not measure it, when you can not express it in numbers, your knowledge is of a meagre and unsatisfactory kind. Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh manusia. Untuk itu perlu ditentukan parameter atau atribut pengukuran. Menurut taksonomi McCall, atribut tersusun secara hirarkis, dimana level atas (high-level attribute) disebut faktor (factor), dan level bawah (low-level attribute) disebut dengan kriteria (criteria). Faktor menunjukkan atribut kualitas produk dilihat dari sudut pandang pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari sudut pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan sebab akibat (cause-effect). Tabel berikut menunjukkan daftar lengkap faktor dan kriteria dalam kualitas perangkat lunak menurut McCall

Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria

dalam suatu faktor sesuai dengan bobot (weight) yang telah ditetapkan. Rumus

pengukuran yang digunakan adalah:

Fa = w1c1 + w2c2 + … + wncn

Dimana:

Fa adalah nilai total dari faktor a

wi adalah bobot untuk kriteria i

ci adalah nilai untuk kriteria i

Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai

berikut:

Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor

Tahap 2: Tentukan bobot (w) dari setiap kriteria (biasanya 0 <= w <= 1)

Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <=10)

Tahap 4: Berikan nilai pada tiap kriteria

Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + … + wncn

Contoh pengukuran perangkat lunak

Untuk mempermudah pemahaman, akan diberikan sebuah contoh pengukuran kualitas perangkat lunak dari faktor usabilitas (usability). Yang akan diukur adalah dua buah perangkat lunak yang memiliki fungsi untuk mengkontrol peralatan elektronik (electronic device). Perangkat lunak yang pertama bernama TukangKontrol, sedangkan kedua bernama Caktrol. Contoh dan hasil pengukuran dapat dilihat pada Table 3 dan 4.

Dari penghitungan yang ada di Tabel 4, dapat kita simpulkan bahwa dari faktor usabilitas, kualitas dari perangkat lunak bernama TukangKontrol lebih baik daripada Caktrol. Nilai total TukangKontrol untuk faktor usabilitas adalah 16.8, sedangkan Caktrol adalah 10.2 (dari maksimum total nilai 20).

Mengapa Software Quality Engineering perlu dipikirkan?

Penerapan suatu rumusan pemrograman sederhana jawaban bisa diperkenalkan cara yang berikut:

RISK= F (1/quality)

Atau kualitas yang ditingkatkan untuk mengurangi resiko

Suatu metode di mana hasil dari resiko dari kualitas yang pudar dapat dimanifestasikan lebih banyak, bagaimanapun untuk seorang pemakai yang berpengalaman dikenali dalam contoh berikut:

- Kerugian Sosial atau profesional (nformasi/data, waktu, uang, pekerjaan dll.)

- Kerugian kesehatan atau kehidupan ( contoh: pasien over-X-rayed dalam suatu

   rumah sakit)

Jelaslah bahwa sebagai pemakai mungkin akan bermimpi untuk mengharapakan adanya bug-free yang merupakan tingkatan paling tinggi kualitasnya dengan harga yang serendah-rendahnya. Akan tetapi seberapa besar hal tersebut terjadi, tergantung dari SQE oleh perusahaan pengembangan software. Paling mungkin ada suatu kesempatan untuk tidak membeli perangkat lunak yang jelas ada cacat produksinya. Rendahnya kualitas perangkat lunak merupakan resiko yang didapat suatu organisasi yang membelinya dan terkadang suatu pengembang ataupun supplier tidak ambil pusing bahkan tidak mau disalahkan. Berdasarkan pengalaman, resiko yang paling besar sebagai hasil dari rendahnya kualitas perangkat lunak sering didapatkan oleh pemakai dan hanya sedikit yang didapatkan oleh penyalur perangkat lunak. Karena itu harus ada suatu kompromi antara developer atau supplier dan pemakai tentang perangkat lunak yang akan dibeli sehingga diharapkan tidak ada yang dirugikan dari transaksi yang terjadi. Menentukan Kualitas Perangkat Lunak Dipandang dari sudut hipotesis, para ahli dalam membuat dan menentukan kualitas perangkat lunak sebaiknya menerapkan, mengukur, mengevaluasi dan meningkatkan mutu perangkat lunak sepanjang lifecycle-nya. Pengetahuan yang luas tentang rekayasa perangkat lunak memerlukan suatu pendekatan yang terstruktur dan sistematis dengan mempertimbangkan pengalaman yang diperolehnya. Jika mungkin, disesuiakan dengan praktek industri sebenarnya. Suatu pendekatan terstruktur tidak terbatas pada tiga komponen utama yang terpusat pada inti pengetahuan perangkat lunak. Contohnya komponen Quality Requirements didapatkan dengan adanya prasyarat:

- Kualitas kebutuhan (Quality requirements)

- Pengukuran kualitas dan instrument evaluasi (Quality measurement and

   evaluation instruments)

- Implementasi kualitas dalam lifecycle (In-lifecycle quality implementation)

Pengetahuan dalam mendapatkan komponen Quality requirement (QR) sangat diperlukan terutama bagi kalangan ahli software dalam mempertimbangkan dan memperoleh kebutuhan yang berkualitas sehingga benar-benar didapatkan high-level stakeholder’s requirements. Karena itu untuk mendapatkan kemudian untuk QR digambarkan pengukuran kualitas dalam gambar di bawah ini:

Model dekomposisi yang diusulkan didasarkan pada model kualita

s dari ISO/IEC 9126 dalam konjungsi dengan standar TL 9000, dimana kontribusi dari penggunaan QR adalah untuk menetapkan kebutuhan mutu eksternal (External Quality requirements), yang mana pada gilirannya berperan untuk menetapkan kebutuhan mutu internal (Internal Quality requirements). Model tersebut didokumentasikan dengan baik sehingga relatif mudah untuk dipelajari dan digunakan akan tetapi sedikit statis dalam perubahannya. Karena itu, ahli SQ yang baik seharusnya mengetahuinya tidak hanya apa? tetapi juga bagaimana? Pendekatan ini ditujukan oleh model tersebut untuk proses praktis dalam melukiskan dan mengendalikan kualitas kebutuhan

Pada gambar di atas, anak panah dengan garis yang tidak putus-putus menunjukkan alur tentang ” bagaimana”, yaitu menanyakan tentang eksekusi dekomposisi kebutuhan. Yang ada dalam kotak berisi tentang pertanyaan ” apa ” , yaitu menggambarkan kebutuhan apa yang diakibatkan oleh proses dekomposisi. Sedangkan anak panah dengan garis putus-putus menandai adanya alur pokok dari traceability kebutuhan. Pengetahuan teoritis dan praktis yang menjawab pertanyaan diatas membutuhkan ahli yang berkompeten tentang SQ untuk mengatur proses definisi dan analisis kebutuhan. Komponen dari The Quality measurement and evaluation instruments memiliki tujuan untuk mendidik para ahli SQ tentang keberadaan

model kebutuhan dan mengukur pemilihan perangkat lunak dalam proses mendukung aktivitasnya. Demikian juga, dua unsur tersebut sebaiknya didokumentasikan sehingga mudah untuk dipelajari walau sedikit statis. Rancang bangun merupakan bagian dari pengetahuan dimana pemetaan tentang suatu instrumen ke dalam tahapan lifecycle perangkat lunak trlihat pada gambar di bawah sangat sedikit didokumentasikan dan memerlukan riset lebih lanjut .

Komponen terakhir dari hasil lifecycle quality implementation diakibatkan oleh dua Komponen yang sebelumnya di mana pengetahuan dasar telah didaptkan. Implementasi sekarang memerlukan aplikasi yang praktis tidak sekedar denganpengetahuan tersebut tetapi juga dalam proses pengembangan perangkat lunak.

REFERENSI :

http://rpl07.wordpress.com/2007/06/21/pengukuran-perangkat-lunak-menggunakan-metrik-size-oriented-dan-metrik-function-oriented-oleh-arif-m-5105-100-139/

Pengujian Perangkat Lunak

Dalam strategi pengujianperangkat lunak dapat digambarkan dengan ilustrasi berikut: Sebuah perangkat lunak dimulai daripenentuan kebutuhan perangkat lunak, kemudian prose dilanjutkan ke dalam bentukrancangan, dan akhirnya ke pengkodean. Strategi pengujian serupa dengan haltersebut, dimulai dengan unit testing di pusat spiral di mana masing-masingmodul/unit dari perangkat lunak yang diimplementasikan dalam source codemenjadi sasaran pengujian. Kemudian dilakukan integration testing dengan focuspengujian adalah desain dan kontruksi arsitektur perangkat lunak. Selanjutnyadilakukan validation testing dengan sasaran pengujian adalah kesesuaian dengankebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir padalingkaran terluar spiral sampai pada system testing, di mana perangkat lunakdan keseluruhan sistem diuji.

    A. PendekatanStrategis ke Pengujian Perangkat lunak

Pengujianmerupakan rangkaian aktivitas yang dapat direncanakan sebelumnya dan dilakukansecara sistematis. Strategi uji coba perangkat lunak memudahkan para perancanguntuk menentukan keberhasilan system yg telah dikerjakan. Hal yg harusdiperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harusdirencanakan dengan baik dan berapa lama waktu, upaya dan sumber daya ygdiperlukan Strategi uji coba mempunyai karakteristik sbb :

a  . Pengujian mulai pada tingkat modul yg paling bawah,dilanjutkan dgn modul di atasnya kemudian hasilnya dipadukan

b   . Teknik pengujianyang berbeda mungkin menghasilakn sedikit perbedaan (dalam hal waktu)

    c. Pengujiandilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatukelompok pengujian yang independen.

d  . Pengujian dandebugging merupakan aktivitas yang berbeda, tetapi debugging termasuk dalamstrategi pengujian.

Validasi dan validasi

Verifikasi dan validasi merupakandua istilah yang sering dikaitkan dengan tahapan pengujian perangkat lunak.Verifikasi mengacu pada serangkaian aktivitas untuk memastikan bahwa perangkatlunak mengimplementasikan fungsi tertentu secara benar, sedangkan validasimengacu pada serangkaian aktivitas untuk memastikan bahwa perangkat lunak yangtelah dibuat sesuai denga kebutuhan konsumen.

Definisi V&V mencakupserangkaian aktivitas dari penjaminan kualitas perangkat lunak (SQA) yangmeliputi kajian teknis formal, audit kualitas dan control, monitoring kinerja,simulasi, studi feasibilitas, kajian dokumentasi, kajian basisdata, analisisalgoritma, pengujian pengembangan, pengujian kualifikasi, dan pengujianinstalasi.

Pengorganisasian Pengujian Perangkat Lunak

Proses pengujian sebuah perangkat lunaksebaiknya melibatkan pihak yang memang secara khusus bertanggung jawab untukmelakukan proses pengujian secara independen. Untuk itulah diperlukanIndependent Test Group (ITG).

Peran dari ITG adalah untuk menghilangkan“conflict of interest” yang terjadi ketika pengembang perangkat lunak berusahauntuk menguji produknya sendiri.

Walaupun seperti itu, sering terjadibeberapa kesalahan pemahaman berkaitan dengan peran ITG, antara lain:

a. Pengembangtidak boleh melakukan pengujian sama sekali. Pendapat ini tidak 100% benar,Karena dalam banyak kasus, pengembang juga melakukan proses unit testing danintegration test.

b. Perangkatlunak dilempar begitu saja untuk diuji secara sporadic. Hal tersebut adalahsalah karena pengemmbang dan ITG bekerja sama pada kesalahan proyek untukmemastikan pengujian akan dilakukan. Sementara pengujian dilakukan, pengembangharrus memperbaiki kesalahan yang ditemukan.

c. Pengujitidak terlibat pada proyek sampai tahap pengujian dimulai. Hal tersebut salahkarena ITG merupakan bagian dari tim proyek pengembangan perangkat lunak dimanaia terlihat selama spesifikasi proses dan tetap terlinat pada keseluruhanproyek besar.

B. Masalah-Masalah Strategis

Masalah-masalah berikut harus diselesaikanbila pengujian ingin berlangsung sukses:

    1  . Menspesifikasikan kebutuhan produkpada kelakuan yang terukur sebelum pengujian dimulai. Strategi pengujian yangbaik tidak hanya untuk menenmukan kesalahan, namun juga unutk menilai kualitasprogram.

    2. Menspesifikasikan tujuan pengujiansecara eksperangkat lunakisit. Sasaran spesifik dari pengujian harus dinyatakandalam bentuk yang terukur

   3. Mengidentifikasikan kategori useruntuk perangkat lunak dan membuat profilnya masing-masing. Beberapa kasus yangmenggambarkan scenario interaksi bagi masing-masing kategori dapat mengurangikerja pengujian dengan memfokuskan pengujian pada penggunaan actual produk.

    4. Membangun rencana pengujian yangmenegaskan rapid cycle testing. Umpan balik yang muncul dari rapid cycletesting dapaat digunakan untuk mengontrol kualitas dan strategi pengujian yangsesuai.

    5. Membangun perangkat lunak yang tangguhyang dirancang untuk menguji dirinya sendiri. Perangkat lunak dapatmendiagnosis jenis-jenis kesalahan tertentu dan mengakomodasi pengujianotomatis dan pengujian regresi.

   6. Menggunakan tinjauan formal yang efektif sebagai filter sebekum pengujian.Kajian teknis formal dapat mengungkap kesalahan seefektif pengujian sehinggadapat mengurangi jumlah kerja pengujian.

   7. Mengadakan tinjauan formal dapatmengungkap inkonsistensi, penghapusan, dan kesalahan seketika dalam pendekatanpengujian.

   8. Membangun pendekatan yang meningkatsecara berkelanjutan untuk proses pengujian. Strategi pengujian harus terukur.Metric yang terkumpul selama pengujian harus digunakan sebagai bagian daripendekatan control proses statistical bagi pengujian perangkat lunak.

    C. PengujianUnit

Unit testing (uji coba unit) fokusnya pada usahaverifikasi pada unit terkecil dari desain perangkat lunak, yakni modul. Ujicoba unit selalu berorientasi pada white box testing dan dapat dikerjakanparalel ayau beruntun dengan modul lainnya.

PertimbanganPengujian Unit

Interface modul diuji untuk memastikan bahwa informasisecara tepat mengalir masuk dan keluar dari inti program yang diuji. Strukturdata local diuji untuk memastikan bahwa data yang tersimpan secara temporaldapat tetap menjaga integritasnya selama semua langkah langkah di dalamsuatu algoritma dieksekusi. Kondisi batas diuji untuk memastikan bahwa modulberoperasi dengan tepat pada batas yang ditentukan untuk membatasipemrosesan. Semua jalur independen(jalur dasar) yang melalui struktur controldipakai sedikirnya satu kali. Dan akhirnya penanganan kesalan diuji.

Prosedur Pengujian Unit

sumber telah dikembangkan, ditunjang kembali dandiverifikasi untuk sintaksnya, maka perancangan test case dimulai. Peninjauankembali perancangan informasi akan menyediakan petunjuk untuk menentukan testcase. Karena modul bukan program yg berdiri sendiri maka driver (pengendali)dan atau stub perangkat lunaK harus dikembangkan untuk pengujian unit.

Driver adlprogram yg menerima data untuk test case dan menyalurkan ke modul yg diuji danmencetak hasilnya.

Stub melayanipemindahan modul yg akan dipanggil untuk diuji

     D. Pengujian Integrasi

Pengujian terintegrasi adl teknik yg sistematis untukpenyusunan struktur program, pada saat dikerjakan uji coba untuk memeriksakesalahan yg nantinya digabungkan dengan interface. Metode pengujian:

    1. Top down integration

Merupakan pendekatan inkrmental untuk penyusunanstruktur program. Modul dipadukan dgn bergerak ke bawah melalui kontrol hirarkidimulai dari modul utama. Modul subordinat ke modul kontrol utama digabungkanke dalam struktur baik menurut depth first atau breadth first.

Proses integrasi:

   a. Modul utama digunakan sebagai test driver danstub yg menggantikan seluruh modul yg secara langsung berada di bawah modulkontrol utama.

     b. Tergantung pada pendekatan perpaduan yg dipilih(depth / breadth)

     c. Uji coba dilakukan selama masing-masing moduldipadukan

     d. Pada penyelesaian masing-masing uji coba stub yglain dipindahkan dgn modul sebenarnya.

     e. Uji coba regression yaitu pengulangan pengujianuntuk mencari kesalahan lain yg mungkin muncul.

     2. Buttom up integration

Pengujian buttom up dinyatakan dgn penyusunan ygdimulai dan diujicobakan dgn atomic modul (modul tingkat paling bawah pdstruktur program). Karena modul dipadukan dari bawah ke atas, proses ygdiperlukan untuk modul subordinat yg selalu diberikan harus ada dan diperlukanuntuk stub yg akan dihilangkan.

Strategi pengujian

      a. Modul tingkat bawah digabungkan ke dalam clusteryg memperlihatkan subfungsi perangkat lunak

      b. Driver (program kontrol pengujian) ditulisuntuk mengatur input test case dan output

      c. Clusterdiuji

     d. Driver diganti dan cluster yg dikombinasikandipindahkan ke atas pada struktur program

    E. Pengujian Validasi

Setelah semua kesalahan diperbaiki maka langkahselanjutnya adalah validasi terting. Pengujian validasi dikatakan berhasil bilafungsi yg ada pada perangkat lunak sesuai dgn yg diharapkan pemakai. Validasiperangkat lunak merupakan kumpulan seri uji coba black box yg menunjukkansesuai dgn yg diperlukan.

Kemungkinan kondisi setelah pengujian:

     1. Karakteristikperformansi fungsi sesuai dgn spesifikasi dan dapat diterima

     2. Penyimpangandari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.

Pengujian BETA dan ALPHA

Apabila PERANGKAT LUNAK dibuat untuk pelanggan makadapat dilakukan aceeptance test sehingga memungkinkan pelanggan untukmemvalidasi seluruh keperluan. Test ini dilakukan karena memungkinkan pelanggan menemukan kesalahan yg lebih rinci danmembiasakan pelanggan memahami PERANGKAT LUNAK yg telah dibuat.

Pengujian Alpha

Dilakukan pada sisi pengembang oleh seorang pelanggan.Perangkat Lunak digunakan pada setting yg natural dgn pengembang “yg memandang”melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian

Pengujian Beta

Dilakukan pada satu atau lebih pelanggan oleh pemakaiakhir perangkat lunak dalam lingkungan yg sebenarnya, pengembang biasanya tidakada pada pengujian ini. Pelanggan merekan semua masalah (real atau imajiner) ygditemui selama pengujian dan melaporkan pada pengembang pada interval waktutertentu.

     F. Pengujian Sistem.

Pada akhirnya PERANGKAT LUNAK digabungkan dgn elemensystem lainnya dan rentetan perpaduan system dan validasi tes dilakukan. Jikauji coba gagal atau di luar skope dari proses daur siklus pengembangan system,langkah yg diambil selama perancangan dan pengujian dapat diperbaiki.Keberhasilan perpaduan PERANGKAT LUNAK dan system yg besar merupakan kuncinya.

Sistem testing merupakan rentetan pengujian ygberbeda-beda dgn tujuan utama mengerjakan keseluruhan elemen system ygdikembangkan.

Recovery Testing

Adalah system testing yg memaksa PERANGKAT LUNAKmengalami kegagalan dalam bermacam-macam cara dan apakah perbaikan dilakukandgn tepat.

Security Testing

Adalah pengujian yg akan melalukan verifikasi darimekanisme perlindungan yg akan dibuat oleh system, melindungi dari hal-hal ygmungkin terjadi.

Strees Testing

Dirancang untuk menghadapi situasi yg tidak normalpada saat program diuji. Testing ini dilakukan oleh system untuk kondisi seperti volume data yg tidak normal (melebihiatau kurang dari batasan) atau fekuensi.

      G. Debugging

Debugging bukan merupakanpengujian, namun merupakan konsekuensi dari pengujian yang berhasil. Jikasebuah kasus uji berhasil menemukan kesalahan, maka proses debugging bertujuanuntuk menghilangkan kesalahan tersebut.

Debugging merupakan proses yangsulit untuk dilakukan karena adanya beberapa karakteristik bug seperti:

     1. Gejala dan penyebab dari bug bisa sajasangat jauh, gejala dapat muncul pada bagian tertentu dari program danpenyebabnya bisa saja berada pada bagian lain yang sangat jauh dari tempatmunculnya gejala.

      2. Gejala dapat hilang ketika kesalahanyang lain diperbaiki

      3. Gejala dapat ditimbulkan oleh sesuatuyang tidak salah(mis. Pembulatan yang tidak akurat).

      4. Gejala dapat disebabkan oleh masalahtiming.

      5. Kemungkinan sulit untuk memproduksikondisi onput secara akurat.

      6. Gejala dapat terjadi tiba-tiba.

    7. Gejala dapat disebabkan oleh sesuatuyang didistribusikan melewati sejumlah tugas yang bekerja pada prosesor yangberbeda-beda.

Terdapat 3 jenis pendekatandebugging, antara lain:

    a. Brute Force

Merupakan teknik yang paling seringdigunakan dan paling tidak efisien dalam mengisolasi penyebab kesalahan. Denganprinsip “biarkan computer menemukan kesalahan”, maka seluruh sumber dayacomputer digunakan dengan tujuan untuk menemukan penyebab kesalahan

    b. Backtracking

Merupakan pendekatan yang dimulaidari penemuan gejala kemudian menelusuri balik hingga ke penyebab.

    c. Cause Elimination

Dimanifestasikan oleh induksi ataudeduksi dan menggunakan konsep partisi biner. Data yang berhubungan dengankesalahan yang muncul dikumpulkan untuk mengisolasi penyebab. Kemudian dibuatsebuah hipotesis dan data digunakan untuk membuktikan hipotesis tersebut.Daftar rangkaian penyebab yang mungkin dibuat dan dilakukan pengujian untukmengeliminasi penyebab-penyebab tersebut. Jika pengujian menunjukkan kebenaranhipotesis untuk suatu penyebab, maka data diperbaiki untuk mengisolasi bug.Sekali bug ditemukan, bug harus diperbaiki. Namun, perbaikan pada bug dapatmemunculkan kesalahan lain, maka ada beberapa pertimbangan sebelum bugdihilangkan antara lain:

     1) Apakah penyebab bug ada pada bagianlain dari program?

     2) Apakah “bug yang lain” mungkin terjadipada saat perbaikan dilakukan?

     3) Apakah yang telah dilakukan untukmencegah bug pada tempat pertama?

Referensi:

http://agusnurkhomarudin.blogspot.com/2012/07/strategi-pengujian-perangkat-lunak.html

Tipe-tipe Diagram UML

Tipe-Tipe Diagram dalam UML

1. Use Case Diagram

Use case diagram digunakan untuk membantu menentukan fungsionalitas dan fitur – fitur perangkat lunak dari sudut pandang pengguna.

Akan tetapi secara umum, tujuan dibuatnya diagram use case yaitu untuk :

• Memutuskan dan mendeskripsikan kebutuhan – kebutuhan fungsional sistem
• Memberikan deskripsi jelas dari apa yang seharusnya dilakukan sistem
• Menyediakan basis untuk melakukan pengujian pada system.
• Menyediakan kemampuan untuk dapat melacak kebutuhan fungsionalitas menjadi kelas – kelas dan operasi – operasi actual pada system.

Komponen - Komponen

Pada penggambaran model ini, tedapat beberapa komponen diantaranya sebagai berikut:

1. Actor

Aktor merepresentasikan pengguna sistem, dapat berupa manusia atau system lain yang berhubungan dengan sistem yang sedang dibangun. Aktor juga dapat disebut sesuatu atau seseorang yang berinteraksi dengan sistem. Maksud dari berinteraksi yaitu, aktor mengirim atau menerima pesan ke atau dari system, dan juga bertukar informasi dengan system.

2. Use case

Use case merepresentasikan spesifik penggunaan sistem

oleh aktor. Use case menspesifikasikan perilaku sistem atau bagian

sistem dan deskripsi sekumpulan aksi termasuk varian – varian yang

dilakukan sistem untuk menghasilkan nilai atau informasi.

Ciri - Ciri

• Pola perilaku yang harus dipenuhi sistem
• Sekuen transaksi terhubung yang dilakukan aktor dan sistem
• Memberikan sesuatu yang berharga bagi aktor

Kegunaan

• Memodelkan konteks sistem
• Memodelkan kebutuhan sistem
• Berkomunikasi dengan pemakai akhir dan pakar domain masalah
• Pengujian sistem

3. Relasi

Relasi

Relasi merepresentasikan hubungan yang terjadi antara actor dengan actor, use

case dengan use case, atau actor dengan use case

Jenis Relasi

• Asosiasi

Asosiasi biasanya digunakan untuk menggambarkan hubungan yang

terjadi antara Aktor dengan use case atau Use case dengan use case. terdapat

2 (dua) tipe relasi asosiasi yaitu:

- Include, menggambarkan relasi dimana use case tersebut merupakan

bagian dari use case yang lain.

- Extend, menggambarkan relasi dimana use case tersebut merupakan

pengembangan atau perluasan dari use case yang lain

• Generalisasi

Generalisasi biasanya digunakan untuk mengambarkan hubungan yang

terjadi antara:

- Aktor dengan Aktor

Contoh Diagram Use Case:

Use Case Diagram

Kesimpulan:
Use case diagram membantu kita untuk mendeskripsikan actor ke sistem. Actor dapat disebut sebagai actor karena actor dapat memberi dan menghasilkan ke sistem. Dan actor bukan human saja, tetapi bisa benda atau pun yang lainnya.

2. Class Diagram

Fungsi Class Diagram:

• Digunakan untuk menggambarkan struktur dan perilaku dalam use case
• Memberikan model konseptual dari sistem dalam hal entitas dan hubungan mereka
• Digunakan untuk kebutuhan capture, interaksi pengguna akhir
• Detil diagram kelas yang digunakan untuk pengembang.

Setiap kelas diwakili oleh persegi panjang dibagi menjadi tiga kompartemen

• nama
• atribut
• operasi

Pengubah digunakan untuk menunjukkan visibilitas atribut dan operasi.

• '+' Digunakan untuk menunjukkan visibilitas Umum (orang)
• '#' Digunakan untuk menunjukkan visibilitas Lindung (teman-teman dan diturunkan)
• '-' Digunakan untuk menunjukkan visibilitas Swasta (tidak ada)

Contoh Class Diagram:

From UML Distilled Third Edition

Kesimpulan:
Dapat disebut sebagai class diagram karena atribut yang terdapat dalam class diagram tersebut membedakan atribut class diagram lainnya.

3. Activity Diagram

Fungsi serta peran diagram aktivitas diantaranya :

• Pandangan dalam yang dilakukan di operasi
• Pandangan dalam bagaimana objek – objek bekerja
• Pandangan dalam di aksi – aksi dan pengaruhnya pada objek – objek
• Pandangan dalam dari suatu use – case
• Menggambarkan alur kegiatan secara berurutan
• Menggambarkan logik dari proses bisnis

Penggunaan utama model aktivitas adalah :

• Memodelkan workflow
• Memodelkan operasi

Simbol dalam activity diagram:

Contoh Activity Diagram:

Aktivitas diagram Peminjaman Buku

Kesimpulan:
Diagram aktivitas adalah diagram yang menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem atau proses bisnis. Diagram aktivitas menggambarkan aktivitas sistem bukan apa
yang dilakukan oleh aktor.

4. Sequence Diagram

Fungsi serta peran diagram sekuen diantaranya :

• Overview perilaku sistem,
• Menunjukkan objek – objek yang diperlukan,
• Mendokumentasikan skenario dari suatu diagram use case
• Memeriksa jalur – jalur pengaksesan

Tujuan diagram sekuen adalah sebagai berikut :

• Merupakan diagram yang paling cocok untuk mengembangkan model deskripsi use-case menjadi spesifikasi design.
• Analisa dan desain, memfokuskan pada identifikasi method didalam sebuah sistem.

Simbol dalam Sequence Diagram:

Contoh Sequence Diagram:

Kesimpulan:

Sequence Diagram adalah diagram yang menggambarkan interaksi objek dan mengindikasikan (memberi petunjuk atau tanda) komunikasi diantara objek-objek tersebut.

Sequence diagram digunakan untuk menggambarkan perilaku pada sebuah scenario dan mendeskripsikan bagaimana entitas dalam system berinteraksi, termasuk pesan yang

digunakan saat interaksi. Semua pesan dideskripsikan dalam urutan pada eksekusi. Sequence diagram berhubungan erat dengan Use Case diagram, dimana 1 Use Case akan menjadi 1 Sequence Diagram.

5. Collaboration Diagram

Kegunaan dari diagram ini diataranya yaitu :

• Pandangan dalam dari perilaku sistem, berfokus pada link – link di antara objek – objek.
• Ilustrasi dari suatu diagram use – case
• Menyatakan objek – objek yang diperlukan untuk merealisasikan suatu layanan
• Memeriksa jalur – jalur pengaksesan

Diagram Kolaborasi Adalah Diagram Interaksi

Diagram kolaborasi menekankan pada objek yang saling berinteraksi. Diagram

sekuen dan kolaborasi sama – sama menunjukkan interaksi (aspek dinamis). Diagram

sekuen fokus pada waktu sementara diagram kolaborasi fokus pada ruang. Sebagaimana

diagram sekuen, diagram kolaborasi juga dapat digunakan untuk mengilustrasikan eksekusi

satu operasi, use – case atau skenario interaksi di sistem.

berikut ini adalah langkah - langkah untuk membuat diagram kolaborasi:

• Lebih dulu tempatkan objek – objek yang berpartisipasi di interaksi sebagai simpul – simpul di graph.
• Setelah itu, buat link yang menghubung objek – objek sebagai busur di graph.
• Kemudian beri link ini dengan pesan yang dikirim dan diterima objek.

Simbol:

Contoh Diagram Kolaborasi:

Kesimpulan:

Diagram kolaborasi mendefinisikan peran – peran yang dimainkan ketika satu tugas dilakukan. Diagram kolaborasi menyatakan komunikasi di antara objek yang menunjukkan pesan yang ada, urutan pesan dan hubungan antar objek. Atau suatu diagram yang memperlihatkan / menampilkan interaksi yang terdapat disekitar objek ( seperti halnya sequence diagram ) dan hubungannya terhadap yang lainnya. Diagram kolaborasi atau collaboration diagram lebih menekankan kepada peran setiap objek dan tidak berfokus pada waktu penyampaian setiap pesan / message.

6. State Diagram

Digunakan untuk :

• Pandangan untuk melakukan penjinjauan dari perilaku objek secara waktu
• Pandangan yang berkaitan dengan rangsangan eksternal

Konsep utama dari statechart serupa dengan mesin finite-state, yaitu:

1. State

Abstarksi nilai – nilai atribut link dan objek. Himpunan suatu nilai dikelompokan bersama menjadi state berdasarkan properti – property yang mempengauhi perilaku objek. State mempunyai durasi, memerlukan interval waktu. State sering berasosiasi dengan aktifitas yang bekelanjutan.

2. Event (Kejadian)

Merepresentasikan rangsangan eksternal yang memicu transisi ( pesan, timeout, signal ). Kejadian tidak memiliki durasi, suatu kejadian dapat secara logic mendahului atau mengikuti kejadian lain. Atau bahkan dua kejadian tidak berhubungan sama sekali. Kejadian itu sendiri adalah transmisi informasi searah dari satu objek ke objek lain.

3. Transition (Transisi)

Merepresentasikan sebuah perubahan yang terjadi antar state yang disebabkan oleh sebuah event atau kejadian

4. Action

Merepresentasikan atau menggambarkan aksi yang dilakukan tiap – tiap state yang ada.

Simbol:

Contoh State Diagram:

Kesimpulan:

State chart diagram menunjukan atau menggambarkan transisi dan perubahan keadaan dari satu state ke state lainnya. Selain itu, state chart menggambakan mesin state. Diagram ini merupakan perluasan dari diagram state. Satu diagram state dibuat untuk satu kelas objek dimana perilaku dinamisnya pentik dan menunjukan pola aktivitas. Masing – masing state ini berjalan secara bersamaan dan dapat mengubah state secara bebas.

Sumber:
Dari Modul Praktikum Rekayasa Perangkat Lunak dan PPT UML Concepts.

Proses Model-Rekayasa Perangkat Lunak

1.  The Waterfall Model

            Waterfall Model adalah sebuah metode pengembangan software yang bersifat sekuensial. Metode ini dikenalkan oleh Royce pada tahun 1970 dan pada saat itu disebut sebaga isi klus klasik dan sekarang ini lebih dikenal dengan sekuensial linier. Selain itu Model ini merupakan model yang paling banyak dipakai oleh para pengembang software. Inti dari metode waterfall adalah pengerjaan dari suatu system dilakukan secara berurutan atau secara linear. Jadi jika langkah satu belum dikerjakan maka tidak akan bisa melanjutkan kelangkah 2, 3 dan seterusnya.  Secara otomatis tahapan ke-3 akan bisa dilakukan jika tahap ke-1 dan ke-2 sudah dilakukan.

            Keterkaitan dan pengaruh antar tahap ini ada karena output sebuah tahap dalam Waterfall Model merupakan input bagi tahap berikutnya, dengan demikian  ketidak sempurnaan hasil pelaksanaan tahap sebelumnya adalah awal ketidak sempurnaan tahap berikutnya. Memperhatikan karakteristik ini, sangat penting bagi tim pengembang dan perusahaan untuk secara bersama-sama melakukan analisa kebutuhan dan desain system sesempurna mungkin sebelum masuk kedalam tahap penulisan kode program. Secara garis besar metode waterfall mempunyai langkah-langkah sebagai berikut :

·         Analisa

·         Design

·         Code dan Testing

·         Penerapan dan

·         Pemeliharaan

1. Analisa kebutuhan (Requirement Analysis)/(Requirements analysis and definition)

Langkah ini merupakan analisa terhadap kebutuhan sistem.Pengumpulan data dalam tahap ini bisa malakukan sebuah penelitian, wawancara atau study literatur.Seorang system analis akan menggali informasi sebanyak-banyaknya dari user sehingga akan tercipta sebuah system komputer yang bisa melakukan tugas-tugas yang diinginkan oleh user tersebut. Tahapan ini akan menghasilkan dokumen user requirement atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan sistem. Dokumen inilah yang akan menjadi acuan system analis untuk menterjemahkan kedalam bahasa pemprogram.

2. Design sistem (System Design)

Proses desain akan menerjemahkan syarat kebutuhan kesebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada :struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirment. Dokumen inilah yang akan digunakan programmer untuk melakukan aktivitas pembuatan sistemnya.

3. Coding & Testing/penulisan kode Program (Implementation)

Coding merupakan penerjemahan design dalam bahasa yang bisa dikenali oleh komputer.Dilakukan oleh programmer yang akan meterjemahkan transaksi yang diminta oleh user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan suatu sistem.Dalam artian penggunaan computer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap sistem yang telah dibuat tadi. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap system tersebut dan kemudian bisa diperbaiki.

4. Penerapan / pengujian program (Integration & Testing)

Tahapan ini bisa dikatakan final dalam pembuatan sebuah sistem.Setelah melakukan analisa, design dan pengkodean maka sistem yang sudah jadiakan digunakan oleh user.

5. Pemeliharaan (Operation & Maintenance)

Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau system operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional.

A.    Keuntungan The Waterfall Model

ü  Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.

ü  Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi  setiap fase atau tahapan akan mempunyai dokumen tertentu.

ü  Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.

B.    Kelemahan The Waterfall Model

ü  Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.

ü  Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.

ü  Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.

ü  Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.

ü  Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru.

2.   The V-Model

      Model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

Berikut penjelasan masing-masing tahap beserta tahap pengujiannya:

a.      Requirement Analysis & Acceptance Testing

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

Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.

b.      System Design & System Testing

Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.

c.       Architecture Design & Integration Testing

Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti: pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.

d.      Module Design & Unit Testing

Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.

e.      Coding

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

A.    Keuntungan V-Model

ü  Bahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa formal. Contoh : dengan menggunakan objek model ataupun frame-frame • Meminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnya

ü  Penyesuaian yang cepat pada projek yang baru

ü  Memudahkan dalam pembuatan dokumen projek

ü  Biaya yang murah dalam perawatan dan modifikasinya

ü  V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dan tool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.

ü  V Model dikembangkan dan di-maintain oleh publik. User dari V Model berpartisipasi dalam change control board yang memproses semua change request terhadap V Model.

B.    Kerugian V-Model

ü  Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi. V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan keseluruhan organisasi.

ü  Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.

ü  Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang lebih baik.

ü  Toolnya tidak selengkap yang dibicarakan. SDE (Software Development Environment).Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud adalah “software yang mendukung pengembangan atau pemeliharaan / modifikasi dari system IT.

ü  V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.

ü  V Model terlalu fleksibel dalam arti ada beberapa activity dalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.

3.  Incremental Model 

      Incremental model adalah model pengembangan sistem pada software engineering berdasarkan requirement software yang dipecah menjadi beberapa fungsi atau bagian sehingga model pengembangannya secara bertahap. dilain pihak ada mengartikan model incremental sebagai  perbaikan dari model waterfall dan sebagai standar pendekatan topdown. Model ini memiliki tahapan tahapan untuk perancangan perangkat lunaknya, yaitu: 

1. Requirement , Requirment adalah proses tahapan awal yang dilakukan pada incremental model adalah penentuan kebutuhan atau analisis kebutuhan.
2. Specification, Specification adalah proses spesifikasi dimana menggunakan analisis kebutuhan sebagai acuannya.
3. Architecture Design, adalah tahap selanjutnya, perancangan software yang terbuka agar dapat diterapkan sistem pembangunan per-bagian pada tahapan selanjutnya.
4. Code setelah melakukan proses desain selanjutnya ada pengkodean.
5. Test merupakan tahap pengujian dalam model ini. 

          Tahapan-tahapan tersebut dilakukan secara berurutan. Setiap bagian yang sudah selesai dilakukan testing, dikirim ke pemakai untuk langsung dapat digunakan. Pada incremental model, tiga tahapan awal harus diselesaikan terlebih dahulu sebelum sebelum tahap membangun tiap increment. Untuk mengantisipasi kondisi yang terjadi pada incremental model, diperkenalkan model More Risky Incremental Model. Model ini menerapkan sistem kerja yang paralel. Setelah daftar kebutuhan didapatkan dari pemakai, tim spesifikasi membuat spesifikasi untuk modul pertama. Setelah spesifikasi pertama selesai, tim desain menindak lanjuti. Tim spesifikasi sebelumnya juga langsung membuat spesifikasi untuk model kedua, dan seterusnya. Jadi, tidak harus menunggu modul pertama selesai hingga dikirim ke user.
  

1.    Kelebihan Model Incremental:

ü  Merupakan model dengan manajemen yang sederhana

ü  Pengguna tidak perlu menunggu sampai seluruh sistem dikirim untuk mengambil keuntungan dari sistem tersebut. Increment yang pertama sudah memenuhi persyaratan mereka yang paling kritis, sehingga perangkat lunak dapat segera digunakan.

ü  Resiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah masih dapat ditemukan pada beberapa increment. Karena layanan dengan prioritas tertinggi diserahkan pertama dan increment berikutnya diintegrasikan dengannya, sangatlah penting bahwa layanan sistem yang paling penting mengalami pengujian yang ketat. Ini berarti bahwa pengguna akan memiliki kemungkinan kecil untuk memenuhi kegagalan perangkat lunak pada increment sistem yang paling bawah.

ü  Nilai penggunaan dapat ditentukan pada setiap increment sehingga fungsionalitas sistem disediakan lebih awal.

ü  Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem,

ü  Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji

2.    Kelemahan Model Incremental:

ü  kemungkinan tiap bagian tidak dapat diintegrasikan

ü  Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung

ü  Harus Open Architecture

ü  Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment.

4.  Evolutionary Process Model: Prototype

Prototype model ini digunakan ketika user atau costumer telah mendefinisikan kebutuhan umumm namun belum bisa menyertakan fungsi dan fitur-fitur secara detail. Atau model ini dapat digunakan saat pengembang tidak yakin dengan efisiensi dari algoritma yang dibentuk.

A.    Kelebihan Prototype Model

ü  Jika menggunakan model ini maka dapat menghemat waktu pengembangan

ü  Akan terjalin komunikasi yang baik antara kostumer dan pengembang

ü  Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan

ü  User mnegetahui apa yang diharapkan sehingga penerapan menjadi lebih mudah.

ü  Dalam pengembangan sistem user bisa berpartisipasi secara aktif.

B.    Kekurangan Prototype Model

ü  Proses analisa dan perancangan dalam prototype model terlalu singkat

ü  Biasanya kurang fleksible dalam mengahadapi perubahan

ü  Walaupun pemakai melihat berbagai perbaikan dari setiap versi prototype, tetapi pemakai mungkin tidak menyadari bahwa versi tersebut dibuat tanpa memperhatikan kualitas dan pemeliharaan jangka panjang

ü  Pengembang kadang-kadang membuat kompromi implementasi dengan menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak efisien

5.  Evolutionary Process Model: Spiral

Spiral model merupakan gabungan antara prototype model dan waterfall model. Spiral model didefinisikan dalam aktivitas kerangka kerja oleh team software engineering.

A.    Kelebihan Model Spiral :

ü  Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar

ü  Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses

B.    Kekurangan Model Spiral :

ü Pada saat situasi kontrak akan sulit untuk meyakinkan costumer bahwa penggunaan pendekatan ini akan dapat dikendalikan

ü  Memerlukan tenaga ahli untuk memperkirakan resiko, dan harus mengandalkannya supaya sukses

ü  Model spiral ini merupakan model yang masih baru sehingga belum terbukri apakah model ini efisien atau tidak.

6.  The RAD model

            RAD (Rapid Application Development) adalah model proses yang juga termasuk dalam Incremental Proses Model karena pembangunan dari sistem perangkat lunak dikerjakan dengan tahapan yang terurut mulai dari dasar (awal) sampai tahap paling tinggi (proses akhir pembuatan), tetapi perbedaan nya model ini dibagi menjadi beberapa modul dan dikerjakan secara besama-sama dan sesuai dengan waktu yang ditentukan.

A.    Kelebihan RAD model :

ü  Pengerjaan sistem yang cepat (60 -90 hari)

ü  RAD dapat menggunakan kembali komponen yang ada (reusable object) sehingga  pengembang pengembang tidak perlu membuat dari awal lagi.

ü  Proses pengiriman menjadi lebih mudah karena proses pembuatan berupa potongan- potongan script

B.    Kekurangan RAD model :

ü  Tidak tepat untuk sistem yang berukuran besar.

ü  Pembuatan sistem bisa gagal jika waktu kesepakatan tidak terpenuhi (terlalu cepat atau  permintaan agar diselesaikan lebih cepat dari perjanjian).

ü  Mempunyai banyak resiko karena dikerjakan dalam modul yang berbeda dan dalam waktu  yang hampir bersamaan dan pada tempat yang belum tentu sama.