SOFTWARE MODEL EVOLUSI PROSES

Ada tumbuhnya pengakuan bahwa perangkat lunak, seperti semua sistem yang kompleks,berkembang selama lebih dari satu periode waktu. kebutuhan bisnis dan produk sering berubah sebagaimana pengembangan hasil, membuat jalan yang lurus untuk produk akhir yang tidak realistis.

pasar yang ketat membuat tenggat waktu penyelesaian produk perangkat lunak yang komprehensif tidak mungkin, tapi versi terbatas harus diperkenalkan untuk memenuhi tekanan kompetitif atau bisnis.

seperangkat produk atau sistem persyaratan inti telah dimengerti dengan baik, tetapi rincian produk atau sistem ekstensi belum didefinisikan. Pada situasi sejenis ini , teknisi software membutuhkan model proses yang telah secara jelas dirancang untuk memuat produk yang berkembang dari waktu ke waktu.

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

model evolusi berulang dicirikan dengan cara yang memungkinkan teknisi perangkat lunak untuk mengembangkan versi perangkat lunak yang semakin lebih lengkap .

2.7.1    MODEL INCREMENTAL / TAMBAHAN

Model inkremental menggabungkan elemen dari model sekuensial linier (diterapkan berulang-ulang) dengan filosofi iteratif prototyping. Yang Model inkremental berlaku urutan linear secara bergiliran sebagai waktu kalender berlangsung. Setiap urutan linier menghasilkan penyampaian " increment" dari perangkat lunak. Misalnya, perangkat lunak pengolah kata yang dikembangkan menggunakan inkremental Paradigma mungkin memberikan manajemen file, mengedit, dan produksi dokumen dasar fungsi dalam selisih pertama; editing yang lebih canggih dan produksi dokumen kemampuan dalam selisih kedua; ejaan dan tata bahasa memeriksa ketiga kenaikan; dan halaman lanjutan tata letak kemampuan dalam selisih keempat. Harus mencatat 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 dikenal, orang lain tidak diketahui) tetap tidak terkirim. Produk inti digunakan oleh pelanggan (Atau mengalami ulasan rinci). Sebagai akibat dari penggunaan dan / atau evaluasi, perencanaan adalah dikembangkan untuk peningkatan selanjutnya. Rencananya membahas modifikasi inti produk untuk lebih memenuhi kebutuhan pelanggan dan pengiriman tambahan fitur dan fungsionalitas. Proses ini diulang setelah pengiriman setiap kenaikan, sampai produk yang lengkap dihasilkan.

Incremental model proses, seperti prototyping (Bagian 2.5) dan evolusi lainnya pendekatan, adalah berulang di alam. Tapi tidak seperti prototyping, incremental Model 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. pengembangan 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, awalnya diusulkan oleh Boehm [BOE88], adalah software model evolusi proses yang berpasangan sifat iteratif dari prototipe dengan dikendalikan aspek sistematis dari model sekuensial linier.hal Ini memberikan potensi pengembangan versi tambahan yang cepat dari perangkat lunak. Menggunakan model spiral, perangkat lunak dikembangkan dalam serangkaian rilis inkremental. Selama iterasi awal, rilis inkremental mungkin menjadi 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 tugas  regions.6 Biasanya, ada antara tiga dan enam wilayah tugas. Gambar 2.8 menggambarkan model spiral yang berisi enam wilayah tugas:

• Pelanggan komunikasi-tugas yang dibutuhkan untuk membangun komunikasi yang efektif
antara pengembang dan pelanggan.
• Perencanaan-tugas yang dibutuhkan untuk mendefinisikan sumber daya, jadwal, dan lainnya projectrelated informasi.
• Risiko analisis-tugas yang dibutuhkan untuk menilai baik teknis dan manajemen risiko.
• Teknik-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi.
• Pengembangan dan melepaskan-tugas yang dibutuhkan untuk membangun, menguji, menginstal, dan memberikan dukungan pengguna (misalnya, dokumentasi dan pelatihan)

• Pelanggan evaluasi-tugas yang dibutuhkan untuk memperoleh umpan balik pelanggan berdasarkan

pada evaluasi representasi perangkat lunak yang dibuat selama rekayasa tahap dan dilaksanakan selama tahap instalasi. Masing-masing daerah yang dihuni oleh satu set tugas pekerjaan, disebut tugas set, yang disesuaikan dengan karakteristik proyek yang akan dilakukan. Untuk proyek-proyek kecil, sejumlah tugas kerja dan formalitas mereka rendah. Untuk yang lebih besar, proyek-proyek yang lebih kritis, masing-masing daerah tugas yang memuat tugas pekerjaan lagi yang didefinisikan untuk mencapai tingkat yang lebih tinggi formalitas. Dalam semua kasus, kegiatan payung (misalnya, konfigurasi perangkat lunak manajemen dan jaminan kualitas perangkat lunak) mencatat dalam Bagian 2.2 diterapkan. Sebagai proses evolusi ini dimulai, perangkat lunak tim teknik bergerak di sekitar spiral searah jarum jam, dimulai di pusat. Rangkaian pertama sekitar spiral mungkin mengakibatkan pengembangan spesifikasi produk; berikut melewati sekitar spiral dapat digunakan untuk mengembangkan prototipe dan kemudian semakin versi yang lebih canggih dari perangkat lunak. Setiap melewati wilayah perencanaan hasil penyesuaian dengan rencana proyek. Biaya dan jadwal yang disesuaikan berdasarkan umpan balik yang berasal dari evaluasi pelanggan. Selain itu, menyesuaikan manajer proyek jumlah direncanakan iterasi yang dibutuhkan untuk menyelesaikan perangkat lunak.

Tidak seperti proses model klasik yang berakhir ketika perangkat lunak disampaikan, spiral
Model dapat disesuaikan untuk menerapkan seluruh kehidupan perangkat lunak komputer. Sebuah alternatif Pemandangan dari model spiral dapat dianggap dengan memeriksa titik masuk proyek axis, 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 sepanjang jalan spiral yang batas berbayang wilayah tengah) sampai pengembangan konsep selesai. Jika konsep ini untuk dikembangkan menjadi produk yang sebenarnya, proses hasil melalui kubus berikutnya (baru proyek pengembangan produk entry point) dan sebuah "proyek pengembangan baru" dimulai. Produk baru akan berkembang melalui nomor 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 aktif, tapi setiap kali perubahan dimulai, proses dimulai pada tepat entry point (misalnya, peningkatan produk).

Model spiral adalah pendekatan realistis untuk pengembangan sistem skala besar dan perangkat lunak. 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 menerapkan pendekatan prototyping pada setiap tahap dalam  evolusi produk. Saya t mempertahankan pendekatan bertahap sistematis yang disarankan oleh siklus hidup klasik tapi menggabungkan menjadi kerangka berulang yang lebih realistis mencerminkan dunia nyata. Itu 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 dikontrol. Hal ini menuntut cukup keahlian penilaian risiko dan bergantung pada ini 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 SPIRAL WINWIN

Tujuan dari kegiatan ini adalah untuk memperoleh proyek persyaratan dari pelanggan. Pada konteks yang ideal, pengembang hanya meminta pelanggan apa yang dibutuhkan dan pelanggan memberikan detail yang cukup untuk melanjutkan. Sayangnya, hal ini jarang terjadi. Pada kenyataannya, pelanggan dan pengembang masukkan dalam proses negosiasi, di mana pelanggan dapat diminta untuk menyeimbangkan fungsi, kinerja, dan produk lainnya atau sistem karakteristik terhadap biaya dan waktu ke pasar.

Negosiasi terbaik berusaha untuk result.7 "menang-menang" Artinya, pelanggan menang dengan mendapatkan sistem atau produk yang memenuhi sebagian dari kebutuhan pelanggan dan pengembang menang dengan bekerja untuk anggaran dan tenggat waktu yang realistis dan dapat dicapai.

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

1. Identifikasi sistem atau kunci subsistem ini "stakeholder." 8
2. Penentuan stakeholder '"menang kondisi."
3. Negosiasi kondisi menang pemangku kepentingan untuk mendamaikan mereka ke dalam

seperangkat kondisi win-win untuk semua pihak (termasuk tim proyek software).

Menjalankan langkah-langkah awal mencapai hasil menang-menang, yang menjadi kriteria utama untuk melanjutkan ke perangkat lunak dan sistem definisi. The Winwin spiral Model diilustrasikan pada Gambar 2.9. Selain penekanan ditempatkan pada negosiasi awal, model spiral WinWin memperkenalkan tiga tonggak proses, disebut jangkar poin [BOE96], yang membantu membangun selesainya satu siklus sekitar spiral dan memberikan tonggak keputusan sebelum hasil proyek software.

Pada dasarnya, jangkar poin mewakili tiga pandangan yang berbeda dari kemajuan sebagai
Proyek melintasi spiral. Pertama anchor point, tujuan siklus hidup (LCO), mendefinisikan
seperangkat tujuan untuk setiap kegiatan rekayasa perangkat lunak utama. Misalnya, sebagai bagian dari LCO, serangkaian tujuan menetapkan definisi top-level sistem / produk Persyaratan. 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. 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 bantuan dibutuhkan oleh semua pihak yang akan menggunakan atau mendukung perangkat lunak.

2.7.4    MODEL PENGEMBANGAN KONKUREN ( RANGKAP )

Model pengembangan konkuren, kadang-kadang disebut teknik konkuren, telah
digambarkan dengan cara berikut oleh Davis dan Sitaram :

pengelola proyek yang melacak status proyek dalam hal fase utama [dari kehidupan klasik
siklus] tidak tahu status proyek-proyek mereka. Ini adalah contoh dari percobaan melacak
set yang sangat kompleks dari kegiatan menggunakan model yang terlalu sederhana. Perhatikan bahwa meskipun. . . proyek dalam tahap coding, ada personel pada proyek yang terlibat dalam kegiatan biasanya terkait dengan banyak tahapan pengembangan secara bersamaan. Sebagai contoh, . . . personil menulis persyaratan, merancang, coding, pengujian, dan pengujian integrasi
[Semua pada waktu yang sama]. Software proses rekayasa model oleh Humphrey dan Kellner
telah menunjukkan konkuren yang ada untuk kegiatan yang terjadi selama salah satu fase.Karya lain Kellner yang terbaru menggunakan statecharts [notasi yang mewakili keadaan dari proses] untuk mewakili ada hubungan bersamaan antara kegiatan terkait dengan peristiwa tertentu (misalnya, perubahan persyaratan selama pengembangan akhir), tapi gagal untuk menangkap kekayaan konkuren yang ada di semua pengembangan perangkat lunak dan kegiatan manajemen dalam proyek. . . . Kebanyakan model proses pengembangan perangkat lunak didorong oleh waktu . nantinya, proses pengembangan berada di tangan anda. [sebuah model proses konkuren] didorong oleh kebutuhan pengguna, keputusan manajemen, dan hasil kajian.

Model proses konkuren dapat direpresentasikan secara skematis sebagai rangkaian utama
kegiatan teknis, tugas, dan keadaan-keadaan terkait. Misalnya, rekayasa Kegiatan yang ditetapkan untuk model spiral dilakukan dengan menerapkan berikut tugas: prototyping dan / atau pemodelan analisis, persyaratan spesifikasi,dan design. 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 keadaan-keadaan yang berbeda. Misalnya, di awal proyek komunikasi pelanggan Kegiatan (tidak ditampilkan dalam gambar) telah menyelesaikan iterasi pertama dan ada di menunggu keadaan perubahan. Kegiatan analisis (yang ada di keadaan none sementara komunikasi pelanggan awal selesai) sekarang membuat transisi ke di bawah keadaan pengembangan. Namun, jika pelanggan menunjukkan bahwa perubahan persyaratan harus dilakukan, kegiatan analisis bergerak dari pengembangan bawah keadaan ke keadaan perubahan menunggu. Model proses konkuren mendefinisikan serangkaian acara yang akan memicu transisi dari keadaan ke keadaan untuk setiap kegiatan rekayasa perangkat lunak.

Sebagai contoh,selama tahap-tahap awal desain, ketidak sesuaian dalam model analisis terungkap.
Ini menghasilkan acara model analisis koreksi yang akan memicu aktivitas analisis dari keadaan selesai berganti ke keadaan menunggu.

Model proses konkuren sering digunakan sebagai paradigma untuk pengembangan klien / server11 aplikasi (Bab 28). 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. Konkuren dicapai dalam dua cara:

(1) Sistem dan komponen kegiatan terjadi secara bersamaan dan dapat dimodelkan
menggunakan pendekatan keadaan-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. Daripada 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 keadaan-keadaan dari suatu kegiatan.