Archive for 2014-04-20

Model Pengembangan Software

Model Pengembangan Software  Menurut Ian Sommerville
A.    Model Waterfall
Pada tahun 1960-an dan 1970-an, proyek pengembangan perangkat lunak merupakan pekerjaan yang sangat memakan biaya dan waktu karena pengembangan  perangkat lunak ini difokuskan pada perencanaan dan pengendalian (Basili dan Musa, 1991). Kemunuclan model waterfall adalah untuk membantu mengatasi kerumitan yang terjadi akibat proye-proyek pengembangan perangkat lunak (Boehm, 1976). Seperti yang terlihat pada gambar di bawah, sebuah model air terjum memacu tim pengembang untuk merinci apa yang seharusnya perangkat lunak lakukan (mengumpulkan dan menentukan kebutuhan system) sebelum system tersebut dikembangkan.


Tahapan-tahapan utama dari model ini memetakan kegiatan-kegiatan pengembangan dasar yaitu :
1.      Analisis dan definisi persyaratan. Pelayanan, batasan dan tujuan sistem ditentukan melalui konsultasi dengan user system. Persyaratan ini kemudian didefinisikan secara rinci dan berfungsi sebagai spesifikasi system.
2.      Perancangan system dan perangkat lunak. Proses perancangan system membagi persyaratan dalam system perangkat keras atau lunak. Kegiatan ini menentukan arsitektur system secara keseluruhan. Perancangan perangkat lunak melibatkan identifikasi dan deskripsi abstraksi system perangkat lunak yang mendasar dan hubungan-hubungannya.
3.      Implementasi dan pengujian unit. Pada tahap ini, perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujuan unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.
4.      Integrasi dan pengujian system. Unit program atau program individual diintegrasikan dan diuji sebagai system yang lengkap untuk menjamin bahwa persyaratan system telah dipenuhi. Setelah pengujian system, perangkat lunak dikirim kepada pelanggan.
5.      Operasi dan pemeliharaan. Biasanya (walau tidak seharushya), ini merupakan fase siklus hidup yang paling lama. Sistem diinstal dan dipakai. Pemeliharaan mencakup koreksi dari berbagai error yang tidak ditemukan pada tahap-tahap terdahulu, perbaikan atas implementasi unit system dan pengembangan pelayanan system, sementara persyaratan-persyaratan baru ditambahkan.  
Model Waterfall

B.     Pengembangan Evolusioner
Pengembangan evolusioner berdasarkan pada ide untuk mengembangkan implementasi awal, memperlihatkan kepada user untuk dikomentari, dan memperbaiki versi demi versi sampai system yang memenuhi persyaratan diperoleh. Tidak ada kegiatan spesifikasi, pengembangan, dan validasi yang terpisah, alih-alih kegiatan-kegiatan ini dilakukan pada saat yang bersamaan dengan umpan balik yang cepat untuk masing-masing kegiatan. Ada dua jenis pengembangan evolusioner:
1.      Pengembangan eksploratori. Tujuan proses ini adalah bekerja dengan pelanggan untuk menyelidiki persyaratan mereka dan mengirimkan sistem akhir. Pengembangan dimulai dengan bagian-bagian sistem yang dipahami. Sistem berubah dengan adanya tambahan fitur-fitur baru sesuai usulan pelanggan.
2.      Prototipe yang dapat dibuang (throw-away). Tujuan pengembangan evolusioner adalah untuk memahami persyaratan pelanggan dan dengan demikian mengembangkan definisi persyaratan yang lebih baik untuk sistem. Prototipe berkonsentrasi pada eksperimen, dengan persyaratan pelanggan yang tidak dipahami dengan baik.

Pendekatan evolusioner terhadap pengembangan perangkat lunak seringkali lebih efektif dari pendekatan air terjun dalam menghasilkan sistemyang memenuhi kebutuhan langsung dari pelanggan. Keuntungan proses perangkat lunak yang berdasarkan pada pendekatan evolusioner adalah bahwa spesifikasi dapat dikembangkan secara inkremental. Sementara user mendapat pemahaman yung lebih baik dari masalahmereka, sistem perangkat lunak dagat merefleksikannya.  Namun demikian, dari sudut pandang rekayasa dan manajemen, ada tiga masalah dengan cara ini:
1.      Proses tidak bisa dilihat. Manajer memerlukan hasil reguler untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat, tidaklah efektif dari segi biaya jika dihasilkan dokumen yang merefleksikan setiap versi sistem.
2.      Sistem seringkali memiliki struktur yang buruk. perubahan yang terus-menerus cenderung merusak struktur perangkat lunak. penyesuaian perubahan perangkat lunak menjadi kian sulit dan mahal.
3.      Mungkin diperlukan alat bantu dan teknik khusus. Keperluan ini memungkinkan pengembangan yang cepat tetapi mungkin tidak kompatibel dengan alat bantu atau teknik lain dan relatif hanya sedikit orang yang memiliki keahlian untuk memakainya.
Untuk sistem kecil (kurang dari 100.000 baris kode) atau sistem berukuran menengah (sampai 500.000 baris kode) dengan waktu hidup yang pendek, pendekatan evolusioner untuk pengembangan  merupakan pendekatan yang paling baik. Akan tetapi, untuk sistem yang besar dan memiliki waktu hidup yang lama, masalah-masalah dengan pengembangan evolusioner bisa menimbulkan masalah yang besar. Untuk sistem-sistem ini, direkomendasikan proses campuran, yang memakai fitur-fitur terbaik dari model air terjun dan pengembangan evolusioner. cara ini bisa melibatkan pengembangan prototipe yang dapat dibuang dengan menggunakan pendekatan evolusiner unfuk menangani ketidakpastian pada spesifikasi sistem. Sistem ini bisa diimplementasi kemudian dengan tn"nggunutun pendekatan yang lebih terstruktur. Bagian-bagian sistem yang dipahami dengan baik dapat dispesifikasi dan dikembangkan dengan menggunakan proses yang berdasarkan pada model air terjun. Bagian sistem yang lain, seperti interface untuk dispesifikasi sebelumnya, harus dikembangkan dengan pendekatan perffograman eksploratori.



C.     Pengembangan Sistem Formal
Pengembangan sistem formal merupakan pendekatan terhadap pengembangan  perangkat lunak yang memiliki kesamaan dengan model air terjun, tetapi proses pengembangannya didasarkan pada transformasi matematis dari spesifikasi system menjadi program yang dapat dijalankan.
Pengembangan system formal
Perbedaan kritis antara pendekatan ini dan model air terjun adalah :
1.      Spesifikasi persyaratan perangkat lunak diperbaiki menjadi spesifikasi formal yang rinci yang dinyatakan dalam notasi matematis
2.      Proses pembangunan perancangan, , imprementasi, dan pengujian unit digantikn oleh proses pengembangan transformasional di mana spesifikasi formal diperbaiki, melalui serangkaian transformasi, menjadi program.
Pada proses transfoirnasi, representasi matematis formal dari sistem secara sistematis diubah menjadi representasi sistem yang lebih rinci, tetapi tetap benar secara matematis. Setiap langkah menambahkan perincian sampai speiifikasi formal diubah menjadi program yang ekivalen. Transformasikan sampai cukup dekat sehingga usaha verifikasi transformasi tidak berlebihan. oengan demikian dapat dijamin, dengan menganggap tidak adanya error verifikasi, bahwa program merupakan implementasi yang benar dari spesifikasi.
Keuntungan pendekatan transformasional dibandingkan dengan penyetujuan bahwa suatu program telah memenuhi spesifikasinya adalah bahlwa jarak Antara setiap transformasi lebih kecil dari pada jarak antara spesifikasi dan program. Bukti program sangat panjang dan tidak praktis untuk sistem berskala besar. Pendekatan transformasional yang terdiri dari serangkaian langkah yang lebih kecil akan lebih mudah ditelusuri. Namun demikian,pemilihan transfomasi apa yang akan dipakai merupakan pekerjaan yang membutuhkan keahlian dan membuktikan hubungan transformasi adalah sesuatu yang sulit.
Contoh yang paling dikenal tentang proses pengembangan formal ini adalah proses Cleanroom yang aslinya dikembangkan oleh IBM (Mills er al., 1987; Selby et al1987; Linger, 1994; Prowell et al, 1999). Proses Cleanroom bergantung pada pengembangan perangkat lunak incremental dansetiap tahap dikembangkan dan kebenarannya didemonstrasikan dengan menggunakan pendekatan formal. Tidak ada pengujian kesalahan pada proses dan pengujian system difokuskan pada penilaian keandalan system.
Pendekatan Cleanroom dan pendekatan lain bagi  pengembangan formal yang berdasarkan pada metode B (Wordsworth, 1996) telah diterapkan dengan sukses.  Ada sedikit kesalahan pada system yang dikirimkan dan biaya pengembangan tidak berbeda secara signifikan dari biaya pendekatan lain. Pendekatan ini terutama disesuaikan dengan pengembang system  yang memiliki persyaratan keselamatan keandalan, atau keamanan yang ketat. Pendekatan formal menyederhanakan pembuatan kasus keselamatan atau keamanan yang menunjukkan kepada pelanggan atau badan sertifikasi bahwa sistem tersebut telah memenuhi persyaratan keselamatan atau keamanan.
Di luar domain khusus ini, proses yang berdasarkan pada transformasi formal tidak digunakan secara luas.  Cara ini memerlukan keahlian khusus dan sesungguhnya untuk sebagian besar system, proses ini tidak memberikan keuntunganbiaya atau kualitas yang signifikan dibandingkan dengan pendekatan yang lain. Alasan utamanya adalah bahwa interaksi sistem tidak menerima spesifikasi system dan hal ini menyita bagian sangat besar dari usaha pengembangan sebagian besar sistem perangkat lunak.

D.    Pengembangan Berorientasi Pemakaian Ulang
Pada sebagian besar proyek perangkat lunak terjadi pemakaian ulang. Hal ini biasanya terjadi secara intormal ketika orang yang bekerja di proyek tersebut mengetahui adanya rancangan atau kode yang mirip dengan yang dibutuhkan. Mereka mencari rancangan atau kode ini, memodifikasinya sebagaimana dibutuhkan, dan menggabungkannya dalam sistem. pada pendekatan evolusioner, pemakaian ulang seringkali dipandang penting untuk pengembangan system yang cepat.
Pemakaian ulang informal ini terjadi dengan mengabaikan proses generik yangdipakai. Namun d"mlkian, dalam beberapa tahun belakangan ini  suatu pendekatan terhadap pengembanganperangkat lunak (rekaya perangkat lunak berdasarkan komponen) yang berdasarkan atas pemakaian  ulang telah muncul dan penggunaannya bertambah luas.
Pendekatan yang berorientasi pemakaian ulang ini bergantung pada sejumlah besar komponen  perangkat  lunak yang dapat dipakai ulang yang bisa didapa dan beberapa kerangka kerangka kerja untuk komponen-komponen ini. Kadangkala komponen-komponen  ini merupakan sistem juga (COTS atau-Commercial Off-The-Shelf systems / Sistem Siap Beli Komersial yang dapat digunakan untuk memberikan fungsionalitas khusus seperti format teks, perhitungan numeric, dll.
Pengembangan berorientasi pemakaian ulang
Sementara tahap spesifikasi persyaratan dan tahap validasi dapat dibandingkan dengan proses lain, tahap pertengahan pada proses berorientasi pemakaian ulang ini ternyata berbeda. Tahap-tahap ini adalah:
1.      Analisis komponen. Jika diketahui spesifikasi persyaratan, komponen-komponen untuk implementasi spesifikasi tersebut akan dicari. Biasanya, tidak ada kesesuaian yang tepat dan komponen yang dapat dipakai hanya memberikan sebagian dari fungsionalitas yang dibutuhkan.
2.       Modifikasi persyaratan. Pada tahap ini, persyaratan dianalisis dengan menggunakan informasi mengenai komponen yang telah didapat. persyarltan kemudian dimodifikasi untuk merefleksikan komponen yang tersedia. Jika modifikasi tidak mungkin dilakukan, maka kegiatan analisis komponen bisa diulang untuk mencari solusi alternatif.
3.      Perancangan sistem dengan  pemakaian arang. pada fase ini, kerangka kerja sistem dirancang, atau kerangka kerja yang telah ada dipakai ulang. Perancang memperhitungkan komponen yang dipakai ulang dan mengatur kerangka kerja untuk menyesuaikan. Beberapa perangkat lunak yang baru mungkin perlu dirancang jika komponen yang dapat dipakai ulang tidak tersedia.
4.      Pengembangan dan integrasi. perangkat runak yang tidak dapat dibeli akan dikembangkan dan komponen dan sistem corS diintegrasikan untuk membentuk sistem. Integrasi sistem, pada model ini, bisa merupakan bagian dari proses pengembangan dan bukan merupakan kegiatan yang terpisah.

Model yang berorientasi pemakaian ulang mempunyai keuntungan nyata yaitu mengurangi besarnya perangkat lunak yang akan dikembangkan, sert-a memperkecil biaya dan risiko. Keuntungan ini biasanya memungkinkan penyelesaian perangkat lunak dengan cepat. Akan tetapi, kompromi persyaratan sangatlah penting dan bisa menghasilkan sistem yang tidak memenuhi kebutuhan sebenarnya dari user. Lebih jauh lagi, kontrol terhadap evolusi sistem akan hilang sementara versi baru dari komponen yang dapat dipakai ulang tidak terkontrol oleh organisasi yang memakai komponen ini.
Saturday, April 26, 2014
Posted by Unknown

- Copyright © 2013 Laboratorium Pemrograman dan Basis Data -Metrominimalist- Powered by Blogger - Designed by Johanes Djogan -