tugas 1

EVOLUSI MODEL PERANGKAT LUNAK PADA PROSES

Ada pengakuan yang berkembang bahwa perangkat lunak, seperti semua sistem yang kompleks, berkembang selama periode waktu [GIL88]. kebutuhan bisnis dan produk sering berubah sebagai hasil pengembangan, pembuatan jalan langsung ke produk akhir tidak realistis; tenggat waktu pasar yang ketat membuat penyelesaian produk perangkat lunak yang komprehensif mungkin, tetapi versi terbatas harus diperkenalkan untuk memenuhi tekanan kompetitif atau bisnis; seperangkat produk inti atau persyaratan sistem dipahami dengan baik, tetapi rincian produk atau sistem ekstensi belum didefinisikan. Dalam situasi ini dan yang sejenis, insinyur perangkat lunak membutuhkan model proses yang telah secara jelas dirancang untuk menampung produk yang berkembang dari waktu ke waktu.

Model secara berurutan linier (Bagian 2.4) dirancang untuk pengembangan lurus ine. Pada dasarnya, pendekatan air terjun ini mengasumsikan bahwa sistem yang lengkap akan disampaikan setelah urutan linear selesai. Prototyping Model (Bagian 2.5) dirancang untuk membantu pelanggan (atau pengembang) dalam persyaratan pemahaman. Secara umum, tidak dirancang untuk memberikan sistem produksi. Sifat evolusi perangkat lunak tidak dipertimbangkan dalam salah satu dari ini pola pikir rekayasa perangkat lunak klasik.

model evolusi yang berulang. Mereka dicirikan dengan cara yang memungkinkan para insinyur perangkat lunak untuk mengembangkan versi semakin lebih lengkap dari perangkat lunak.

Dalam Inkremental Model

Model inkremental menggabungkan elemen dari model secara berurutan linier (diaplikasikan secara berulang) dengan filosofi iteratif prototyping. Mengacu pada Gambar 2.7, model inkremental berlaku urutan linear secara bergiliran sebagai waktu kalender. Setiap urutan linier menghasilkan deliverable "kenaikan" dari perangkat lunak [MDE93]. Misalnya, perangkat lunak pengolah kata yang dikembangkan menggunakan paradigma tambahan mungkin memberikan manajemen dasar berkas, mengedit, dan fungsi produksi dokumen selisih pertama; editing dan produksi dokumen kemampuan lebih canggih dalam selisih kedua; ejaan dan tata bahasa memeriksa selisih ketiga; dan halaman lanjutan tata letak kemampuan dalam selisih keempat. Perlu dicatat bahwa aliran proses untuk peningkatan apapun dapat menggabungkan paradigma prototyping.

Ketika model inkremental digunakan, kenaikan pertama sering merupakan produk inti. Artinya, persyaratan dasar ditangani, tapi banyak fitur tambahan (beberapa diketahui, orang lain tidak diketahui) tetap tidak terkirim. Produk inti digunakan oleh pelanggan (atau mengalami ulasan rinci). Sebagai akibat dari penggunaan dan / atau evaluasi, rencana dikembangkan untuk peningkatan selanjutnya. Rencananya membahas modifikasi dari produk inti untuk lebih memenuhi kebutuhan pelanggan dan pengiriman fitur tambahan dan fungsionalitas. Proses ini diulang setelah pengiriman setiap kenaikan, sampai produk yang lengkap dihasilkan.

Model proses inkremental, seperti prototyping (Bagian 2.5) dan pendekatan evolusioner lainnya, adalah berulang di alam. Tapi tidak seperti prototyping, model inkremental berfokus pada pengiriman produk operasional dengan kenaikan masing-masing. Awal kenaikan yang dipreteli versi dari produk akhir, tetapi mereka memberikan kemampuan yang melayani pengguna dan juga menyediakan platform untuk evaluasi oleh pengguna. pembangunan inkremental sangat berguna ketika staf tidak tersedia untuk implementasi lengkap dengan batas waktu bisnis yang telah ditetapkan untuk proyek tersebut. Awal bertahap dapat diimplementasikan dengan lebih sedikit orang. Jika produk inti diterima dengan baik, maka staf tambahan (jika diperlukan) dapat ditambahkan untuk menerapkan kenaikan berikutnya. Selain itu, kenaikan dapat direncanakan untuk mengelola risiko teknis. Sebagai contoh, sistem utama mungkin memerlukan ketersediaan hardware baru yang sedang dikembangkan dan yang tanggal pengiriman tidak pasti. Ini mungkin untuk merencanakan kenaikan awal dengan cara yang menghindari penggunaan perangkat ini, sehingga memungkinkan fungsi parsial yang akan dikirimkan ke pengguna akhir tanpa penundaan banyak sekali.

 

Dalam Spiral Model

 

Model spiral, awalnya diusulkan oleh Boehm [BOE88], adalah model proses software evolusi bahwa pasangan sifat iteratif dari prototyping dengan aspek dikendalikan dan sistematis dari model secara berurutan linier. Ini memberikan potensi perkembangan pesat dari versi tambahan dari perangkat lunak. Menggunakan model spiral, perangkat lunak dikembangkan dalam serangkaian rilis inkremental. Selama iterasi awal, rilis inkremental mungkin model kertas atau prototipe. Selama iterasi kemudian, versi semakin lebih lengkap dari sistem rekayasa diproduksi.

 

Sebuah model spiral dibagi menjadi sejumlah kegiatan kerangka, juga disebut
daerah tugas. Biasanya, ada antara tiga dan enam wilayah tugas. Gambar 2.8 menggambarkan model spiral yang berisi enam wilayah tugas:

 

 

• komunikasi pelanggan

-tasks diperlukan untuk membangun komunikasi yang efektif antara pengembang dan pelanggan.
• perencanaan

-tasks diperlukan untuk menentukan sumber daya, jadwal, dan proyek-lain
informasi terkait.

• Analisis resiko

-tasks diperlukan untuk menilai baik teknis dan manajemen risiko.

• Teknik

-tasks yang dibutuhkan untuk membangun satu atau lebih representasi dari
aplikasi.

• Konstruksi dan rilis

-tasks diperlukan untuk membangun, menguji, menginstal, dan memberikan dukungan pengguna (misalnya, dokumentasi dan pelatihan).

 

Model spiral dibahas dalam bagian ini adalah variasi pada model yang diusulkan oleh Boehm. Untuk informasi lebih lanjut tentang model spiral asli, lihat [BOE88]. Lebih banyak diskusi baru-baru ini model spiral Boehm dapat ditemukan di [BOE98].

 

• evaluasi pelanggan

-tasks diperlukan untuk memperoleh umpan balik pelanggan berdasarkan pada evaluasi penggambaran perangkat lunak yang dibuat selama rekayasa tahap dan dilaksanakan selama tahap instalasi.

 

 

 

Masing-masing daerah yang dihuni oleh sekumpulan tugas pekerjaan, disebut tugas himpunan, yang disesuaikan dengan karakteristik proyek yang akan dilakukan. Untuk proyek-proyek kecil, jumlah tugas pekerjaan dan formalitas mereka rendah. Untuk yang lebih besar, proyek-proyek yang lebih penting, masing-masing daerah tugas yang memuat tugas pekerjaan lagi yang didefinisikan untuk mencapai tingkat yang lebih tinggi dari formalitas. Dalam semua kasus, kegiatan payung (misalnya, perangkat lunak manajemen konfigurasi dan jaminan kualitas perangkat lunak) mencatat dalam Bagian 2.2 diterapkan.

Sebagai proses evolusi ini dimulai, tim rekayasa perangkat lunak bergerak di sekitar spiral searah jarum jam, dimulai di pusat. Rangkaian pertama sekitar spiral mungkin mengakibatkan pengembangan spesifikasi produk; melewati berikutnya sekitar spiral dapat digunakan untuk mengembangkan prototipe dan versi kemudian semakin lebih canggih dari perangkat lunak. Setiap melewati hasil wilayah perencanaan penyesuaian untuk rencana proyek. Biaya dan jadwal disesuaikan berdasarkan umpan balik yang berasal dari evaluasi pelanggan. Selain itu, manajer proyek menyesuaikan jumlah yang direncanakan iterasi yang dibutuhkan untuk menyelesaikan perangkat lunak.

Tidak seperti model proses klasik yang berakhir ketika perangkat lunak disampaikan, model spiral dapat disesuaikan untuk menerapkan seluruh kehidupan perangkat lunak komputer. Pandangan alternatif dari model spiral dapat dianggap dengan memeriksa entri proyek titik sumbu, juga ditunjukkan pada Gambar 2.8. Masing-masing kubus ditempatkan di sepanjang sumbu dapat digunakan untuk mewakili titik awal untuk berbagai jenis proyek. Sebuah "konsep pengembangan proyek" dimulai pada inti spiral dan akan terus (beberapa iterasi terjadi di sepanjang jalur spiral yang batas-batas daerah yang diarsir pusat) sampai pengembangan konsep selesai. Jika konsep ini untuk dikembangkan menjadi produk yang sebenarnya, proses berlangsung melalui kubus berikutnya (titik masuk proyek pengembangan produk baru) dan "proyek pembangunan baru" dimulai. Produk baru akan berkembang melalui sejumlah iterasi sekitar spiral, mengikuti jalan yang batas wilayah yang memiliki shading agak lebih ringan dari inti. Pada intinya, spiral, ketika ditandai dengan cara ini, tetap operatif sampai software tersebut pensiun. Ada kalanya proses ini tidak aktif, tapi setiap kali perubahan dimulai, proses dimulai pada titik entri yang sesuai (misalnya, peningkatan produk).

Model spiral adalah pendekatan realistis untuk pengembangan sistem berskala besar dan software. Karena software berkembang sebagai proses berlangsung, pengembang dan pelanggan lebih memahami dan bereaksi terhadap resiko pada setiap tingkat evolusi. Model spiral menggunakan prototyping sebagai mekanisme pengurangan risiko tetapi, yang lebih penting, memungkinkan pengembang untuk menerapkan pendekatan prototyping pada setiap tahap dalam evolusi produk. Ia memelihara pendekatan bertahap sistematis yang disarankan oleh siklus hidup klasik tapi menggabungkan menjadi kerangka berulang yang lebih realistis mencerminkan dunia nyata. Model spiral menuntut pertimbangan langsung risiko teknis pada semua tahap proyek dan, jika diterapkan dengan benar, harus mengurangi risiko sebelum mereka menjadi bermasalah.

Tapi seperti paradigma lain, model spiral bukanlah obat mujarab. Mungkin sulit untuk meyakinkan pelanggan (terutama dalam situasi kontrak) bahwa pendekatan evolusioner dapat dikontrol. Hal ini menuntut cukup keahlian penilaian risiko dan mengandalkan keahlian ini untuk sukses. Jika risiko utama tidak ditemukan dan berhasil, masalah pasti akan terjadi. Akhirnya, model belum digunakan secara luas sebagai pola pikir secara berurutan atau prototyping linear. Ini akan memakan waktu beberapa tahun sebelum khasiat paradigma penting ini dapat ditentukan dengan kepastian yang mutlak.