EVOLUTIONARY SOFTWARE PROCESS MODELS

       Banyak yang berpendapat bahwa perangkat lunak, seperti semua sistem yang kompleks, berkembang lebih seiring berjalannya waktu. Berdasarkan pengembangan hasil kebutuhan bisnis dan produk sering berubah, software enginer membutuhkan model proses yang telah secara eksplisit dirancang untuk mengakomodasi produk yang berkembang dari waktu ke waktu.

Model sekuensial linier dirancang untuk pengembangan garis lurus. Pada dasarnya, pendekatan waterfall ini mengasumsikan bahwa sistem yang lengkap akan disampaikan setelah urutan linear selesai. Prototipe Model dirancang untuk membantu pelanggan (atau pengembang) dalam persyaratan pemahaman. Secara umum, tidak dirancang untuk memberikan sistem produksi. Evolusi sifat perangkat lunak tidak dipertimbangkan paradigma rekayasa dalam salah satu dari perangkat lunak klasik ini

 

2.7.1 Model Incremental

Pembangunan inkremental sangat berguna ketika staf tidak tersedia untuk implementasi lengkap dengan batas waktu bisnis yang telah ditetapkan untuk proyek. Awal bertahap dapat diimplementasikan dengan lebih sedikit orang. Jika produk inti diterima dengan baik, maka staf tambahan (jika diperlukan) dapat ditambahkan untuk melaksanakan berikutnya kenaikan. Selain itu, kenaikan dapat direncanakan untuk mengelola risiko teknis. Untuk Misalnya, sistem utama mungkin memerlukan ketersediaan hardware baru yang berada di bawah pengembangan dan yang tanggal pengiriman tidak pasti. Ini mungkin rencana awal increment dengan cara yang menghindari penggunaan perangkat ini, sehingga memungkinkan parsial fungsi yang akan dikirimkan ke pengguna akhir tanpa penundaan banyak sekali.
 

2.7.2 Model Spiral

       Model spiral atau software evolusi pada awalnya dusulkan oleh boehm, yang merupakan model proses dari pasangan sifat etratif dan prototipe. Dan dikendalikan oleh aspek sistematis dari model sekuensial linier. Pada model ini memberikan potensi yang sangat cepat dalam pengembangan versi tambahan dari perangkat lunak. Model spiral ini menggunakan piranti lunak yang dikembangkan dalam serangkaian rilis incremental.Kemudian versi semakin lebih lengkap dari sistem rekayasa diproduksi. Dalam sebuah model spiral ini dibagi menjadi sejumlah kegiatan kerangka.

Terdapat 6 macam dalam permodelan spiral diantaranya:

=>  Pelanggan komunikasi – memiliki tugas untuk membangun komunikasi yang efektif antara pengembang dan pelanggan.

=> Perencanaan – memiliki tugas untuk mendefinisikan sumber daya,jadwal,dan informasi yang terkait dengan proyek lainnya.

=>  Risiko analisis—memiliki tugas untuk menilai baik teknis dan manajemen
risiko.

=>  Teknik—memiliki tugas untuk membangun satu atau lebih representasi dari
aplikasi.

=> Pembangunan dan melepaskan mempunyai tugas untuk membangun, menguji, menginstal, dan
memberikan dukungan pengguna (misalnya, dokumentasi dan pelatihan).

=> Pelanggan evaluasi mempunyai tugas untuk memperoleh umpan balik  dari pelanggan berdasarkan pada evaluasi representasi perangkat lunak yang dibuat selama rekayasa
tahap dan dilaksanakan selama tahap instalasi.

        Model spiral adalah pendekatan realistis untuk pengembangan sistem skala besar. 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 developer untuk menerapkan pendekatan prototyping pada setiap tahap dalam evolusi produk. Pendekatan bertahap sistematis yang disarankan oleh siklus hidup klasik tapi incor-porates menjadi kerangka berulang yang lebih realistis mencerminkan dunia nyata.
       Model spiral itu menuntut pertimbangan langsung risiko teknis pada semua tahap proj-dll. 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 dikontrol. Hal ini menuntut cukup keahlian penilaian risiko dan bergantung pada keahlian untuk sukses. Jika risiko utama tidak ditemukan dan berhasil, masalah akan diragukan lagi terjadi. Akhirnya, model belum digunakan secara luas sebagai linear berurutan atau prototyping paradigma. Ini akan memakan waktu beberapa tahun sebelum khasiat paradigma penting ini dapat ditentukan dengan kepastian yang mutlak.
 

2.7.3 Model WINWIN Spiral

       Tujuan dari kegiatan ini adalah persyaratan proyek dari pelanggan dalam konteks yang ideal,pengembang hanya meminta apa yang dibutuhkan dan pelanggan memberikan detail yang cukup untuk melanjutkannya.sayangnya hal ini jarang terjadi pada kennyataannya pelanggaan  pelanggan dan pengenmbang  memberi masukkan dalam proses negosiasi, di mana pelanggan  meminta untuk menyeimbangkan fungsi,kinerja, dan produk lainnya atau sistem karakteristik terhadap biaya dan waktu ke pasar.

       Negosiasi terbaik berusah untuk tujuan “win-win” " Artinya, pelanggan menang dengan mendapatkan sistem atau produk yang memnuhi sebagian dari kebutuhan pelanggan dan pengembang menang dengan bekerja untuk anggaran dan tenggat waktu yang realistis dan dapat dicapai

Boehem di winwin spiral model Boehm ini Winwin spiral Model [BOE98] mendefinisikan serangkaian kegiatan negosiasi di setiap awal lulus sekitar spiral. Daripada komunikasi pelanggan tunggal aktivitas, kegiatan berikut didefinisikan:

         > Identifikasi sistem atau kunci subsistem ini “stakholder”

      > Penentuan stakholder”menang kondisi”

     > Negosiasi kondisi menang pemangku kepentinganuntuk mendamaikan mereka ke dalam satu set

       Selain penekanan ditempatkan pada negosiasi awal,model spiral win win memperkenalkan tiga pandangan yang berbeda dari kemajuan melintasi spiral. Pertama anchor point yang membantu membangun selesainya satu siklus sekitar spiral dan membangun tonggak keputusan sebelum hasil proyek software

Pada dasarnya, jangkar poin mewakili tiga pandangan yang berbeda dari kemajuan sebagai Proyek melintasi spiral.

1.            Pertama anchor point, tujuan siklus hidup (LCO), mendefinisikan satu set tujuan untuk setiap kegiatan rekayasa perangkat lunak utama. Misalnya, sebagai bagian dari LCO, serangkaian tujuan menetapkan definisi top-level sistem / produk Persyaratan.

2.             Kedua anchor point, siklus hidup arsitektur (LCA), menetapkan tujuan yang harus dipenuhi sebagai sistem dan perangkat lunak arsitektur didefinisikan. Sebagai contoh, sebagai bagian dari LCA, tim proyek perangkat lunak harus menunjukkan bahwa mereka telah dievaluasi penerapan off-the-rak dan komponen perangkat lunak dapat digunakan kembali dan dianggap dampaknya terhadap keputusan arsitektur.

3.                Kemampuan operasional awal (IOC) adalah ketiga jangkar titik dan merupakan serangkaian tujuan yang terkait dengan penyusunan perangkat lunak untuk instalasi / distribusi, persiapan lokasi sebelum instalasi, dan bantuandibutuhkan oleh semua pihak yang akan menggunakan atau mendukung perangkat lunak.
 

2.7.4  Model Pembangunan Bersamaan

       Model pembangunan bersamaan, kadang-kadang disebut concurrent engineering, memiliki digambarkan dengan cara berikut oleh Davis dan Sitaram [DAV94]. Kebanyakan model proses pengembangan perangkat lunak didorong oleh waktu. Kemudian dalam proses pembangunan Anda. [A bersamaan Proses model] didorong oleh kebutuhan pengguna, keputusan manajemen, dan hasil kajian. Gambar 2.10 memberikan gambaran skema satu kegiatan dengan bersamaan model proses. Kegiatan-analisis-mungkin dalam salah satu dari states10 mencatat pada waktu tertentu. Demikian pula, kegiatan lain (misalnya, desain atau pelanggan komunikasi) dapat direpresentasikan dengan cara analog. Semua kegiatan yang ada secara bersamaan tetapi berada di negara-negara yang berbeda. Misalnya, di awal proyek komunikasi pelanggan Kegiatan (tidak ditampilkan dalam gambar) telah menyelesaikan iterasi pertama dan ada di menunggu negara perubahan. Kegiatan analisis (yang ada di negara none sementara komunikasi pelanggan awal selesai) sekarang membuat transisi ke di bawah negara pembangunan. Sebagai contoh, Perlu dicatat bahwa analisis dan desain adalah tugas kompleks yang membutuhkan diskusi substansial. Bagian Tiga dan Empat dari buku ini menganggap topik ini secara rinci. Negara A adalah beberapa modus eksternal diamati perilaku

       Selama tahap-tahap awal desain, inkonsistensi dalam model analisis terungkap. Ini menghasilkan acara model analisis koreksi yang akan memicu aktivitas analisis dari negara dilakukan ke negara perubahan menunggu. Model proses konkuren sering digunakan sebagai paradigma untuk pengembangan klien / server11 aplikasi. Sebuah sistem client / server terdiri dari satu set komponen fungsional. Bila diterapkan client / server, model proses konkuren mendefinisikan kegiatan dalam dua dimensi [SHE94]: sistem dimensi dan dimensi komponen. masalah tingkat sistem ditangani menggunakan tiga kegiatan: desain, perakitan, dan penggunaan. Dimensi komponen ditujukan dengan dua kegiatan: desain dan realisasi. Concurrency dicapai dalam dua cara: (1) Sistem dan komponen kegiatan terjadi secara bersamaan dan dapat dimodelkan menggunakan pendekatan negara-berorientasi dijelaskan sebelumnya; (2) khas client / server aplikasi diimplementasikan dengan banyak komponen, yang masing-masing dapat dirancang dan menyadari secara bersamaan. Pada kenyataannya, model proses konkuren ini berlaku untuk semua jenis pengembangan perangkat lunak dan memberikan gambaran yang akurat tentang keadaan saat ini proyek.

       Dalam aplikasi client / server, fungsi perangkat lunak dibagi antara klien (biasanya PC) dan server (komputer yang lebih kuat) yang biasanya memelihara database terpusat. membatasi kegiatan rekayasa perangkat lunak untuk urutan peristiwa, mendefinisikan jaringan kegiatan. Setiap aktivitas di jaringan ada bersamaan dengan kegiatan lain. Peristiwa yang dihasilkan dalam kegiatan tertentu atau di beberapa tempat lain dalam kegiatan memicu jaringan transisi antara negara-negara dari suatu kegiatan.
 
 
 
 
 
 
 

=>Posted By (201551060, 201551048, 201551057, 20155110)