MODEL EVOLUSI PERANGKAT LUNAK
Ada perkiraan yang berkembang bahwa perangkat lunak, seperti semua sistem yang kompleks, berkembang selama periode waktu [GIL88]. Kebutuhan bisnis dan produk sering berubah selama proses pengembangan produk, membuat jalan yang lurus untuk 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 SLT atau sistem ekstensi belum akan de fi ned. Dalam situasi ini dan yang sejenis, insinyur peranti lunak membutuhkan model proses yang telah dirancang secara eksplisit untuk mengakomodasi produk yang berkembang dari waktu ke waktu. Model sekuensial linier (Bagian 2.4) dirancang untuk garis lurus pembangunan. Pada dasarnya, pendekatan Waterfallini mengasumsikan bahwa sistem yang lengkap akan disampaikan setelah urutan linear selesai. Prototipe Model (Bagian 2.5) dirancang untuk membantu pelanggan (atau pengembang) dalam memahami persyaratan. Secara umum, tidak dirancang untuk memberikan sistem produksi. Sifat evolusioner perangkat lunak tidak dipertimbangkan dalam salah satu dari paradigma 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 software
2.7.1 The Incremental Model
Model inkremental menggabungkan elemen dari model sekuensial 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 dokumen fungsi produksi dalam 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 proses aliran untuk peningkatan apapun dapat menggabungkan paradigma prototyping.
Ketika model inkremental digunakan, kenaikan pertama merupakan produk inti. Artinya, persyaratan dasar ditangani, tapi banyak fitur tambahan (beberapa diketahui, orang lain tidak diketahui) tetap tidak terkirim. Produk inti digunakan oleh customer (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 tambahan, sampai produk yang lengkap dihasilkan.
Proses Model inkremental, seperti prototyping (Bagian 2.5) dan pendekatan evolusioner lainnya, berulang secara alami. Tapi tidak seperti prototyping, model inkremental berfokus pada pengiriman produk operasional dengan kenaikan masing-masing. Awal kenaikan yang dipreteli versi produk akhir, tetapi mereka memberikan capability yang melayani pengguna dan juga menyediakan platform untuk evaluasi oleh pengguna. Pembangunan inkremental sangat berguna ketika susunan kepegawaian tidak tersedia untuk implementasi lengkap dengan batas waktu bisnis yang telah ditetapkan untuk proyek tersebut. Awal bertahap dapat diimplementasikan dengan 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 yang banyak.
2.7.2 The Spiral Model
Model spiral,awalnya diusulkan oleh Boehm [BOE88 ], adalah model proses software evolusi bahwa pasangan sifat berulang dari prototipe dengan aspek dikendalikan dan sistematis dari model sekuensial linier. Ini memberikan potensi perkembangan pesat dari versi tambahan dari perangkat lunak. Menggunakan model spiral, peranti lunak dikembangkan dalam serangkaian rilis inkremental. Selama perulangan awal, rilis inkremental mungkin model kertas atau prototipe. Selama perulangan selanjutnya, 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:
• komunikasi Pelanggan -tugas yang dibutuhkan untuk membangun komunikasi yang efektif antara pengembang dan pelanggan.
• Perencanaan-tugas yang dibutuhkan untuk de sumber fi ne, jadwal, dan informasi terkait proyek-lainnya.
• Risiko analisis-tugas yang dibutuhkan untuk menilai risiko baik teknis dan manajemen.
• Teknik-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi.
• Pembangunan dan Perilisan -tugas yang dibutuhkan untuk membangun, menguji, menginstal, dan memberikan dukungan pengguna (misalnya, dokumentasi dan pelatihan).
• evaluasi dari pelanggan -tugas yang dibutuhkan untuk memperoleh umpan balik pelanggan berdasarkan evaluasi representasi perangkat lunak yang dibuat selama tahap rekayasa dan dilaksanakan selama tahap instalasi.
Masing-masing daerah dihuni oleh satu set tugas pekerjaan, disebut tugas set, 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 memuat tugas pekerjaan lagi yang didefinisikan untuk mencapai tingkat yang lebih tinggi dari formalitas. Dalam semua kasus, Aktivitas Umbrella (misalnya, perangkat lunak con fi gurasi management 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 merepresentasikan titik awal untuk berbagai jenis proyek. Sebuah "konsep pengembanganproyek" dimulai pada inti spiral dan akan terus (beberapa iterasi terjadi di sepanjang jalur spiral yang batas-batas daerah yang diarsir tengah) sampai konsep pembangunan 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 bernomer 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 masuk yang sepatutnya (misalnya, peningkatan produk).
Model spiral adalah pendekatan realistis untuk pengembangan sistem berskala besar dan software. Karena software berkembang saat 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 menyatukannya menjadi kerangka berulang yang lebih realistis proyek berulang. Model spiral menuntut pertimbangan langsung risiko teknis di semua tahap-proyek dll dan, jika diterapkan dengan benar, harus mengurangi risiko sebelum mereka menjadi bermasalah.
Tapi seperti paradigma lain, model spiral bukanlah obat mujarab. Ini 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 paradigma sekuensial atau prototyping linear. Ini akan memakan waktu beberapa tahun sebelum kemujaraban dari paradigma penting ini dapat ditentukan dengan kepastian yang mutlak.
2.7.3 The Winwin Spiral Model
Model spiral dibahas dalam Bagian 2.7.2 menunjukkan aktivitas kerangka kerja yang membahas komunikasi pelanggan. Tujuan dari kegiatan ini adalah untuk memperoleh persyaratan proyek dari pelanggan. Dalam 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 masuk ke dalam proses negosiasi, di mana pelanggan dapat diminta untuk menyeimbangkan keberfungsiannya, kinerja, dan produk atau sistem karakteristik lainnya terhadap biaya dan waktu ke pasar.
Negosiasi terbaik berusaha untuk "win-win" result.7 Artinya, pelanggan menang dengan mendapatkan sistem atau produk yang terpenuhi es mayoritas kebutuhan pelanggan dan pengembang menang dengan bekerja untuk anggaran dan tenggat waktu yang realistis dan dapat dicapai.
Model spiral BOEHEM’sWinwin ini [BOE98] mendefinisikan serangkaian kegiatan negosiasi pada awal sekitar spiral. Daripada kominikasi hanya pada satu pelanggan, kegiatan berikut didefinisikan:
1. Identifikasi sistem atau kunci subsistem “stakeholders”
2. Determinasi dari stakeholder “win condition”
3. Negosiasi stakeholder' win kondisi untuk mendamaikan mereka ke dalam satu set 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. Model ral yang Winwin SPI diilustrasikan pada Gambar 2.9.
Selain penekanan pada negosiasi awal, model spiral WinWin memperkenalkan tiga tonggak proses, disebut jangkar poin [BOE96], yang membantu pem- lish menyelesaikan 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.
Yang 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 persyaratan sistem / produk. Anchor point kedua, arsitektur siklus hidup (LCA), menetapkan tujuan--tujuan yang harus dipenuhi sebagai sistem dan perangkat lunak arsitektur didefinisikan. Misalnya, sebagai bagian dari LCA, tim proyek perangkat lunak harus menunjukkan bahwa mereka telah mengevaluasi penerapan off-the-rak dan perangkat lunak dapat digunakan kembali komponen dan dianggap dampaknya terhadap keputusan arsitektur. Kemampuan operasional awal (IOC) adalah yang ketiga. jangkar titik dan merupakan serangkaian tujuan yang terkait dengan penyusunan perangkat lunak untuk instalasi / distribusi, persiapan lokasi sebelum instalasi, dan dikan asisten dibutuhkan oleh semua pihak yang akan menggunakan atau mendukung perangkat lunak.
2.7.4 The Concurrent Pengembangan Model
model pembangunan bersamaan, kadang-kadang disebut concurrent engineering, telah dijelaskan dengan cara berikut oleh Davis dan Sitaram [DAV94]:manajer proyek yang melacak status proyek dalam hal fase utama [dari siklus hidup klasik] tidak tahu status proyek-proyek mereka. Ini adalah contoh dari mencoba untuk melacak set yang sangat kompleks dari kegiatan menggunakan model terlalu sederhana. Perhatikan bahwa meskipun. . . [besar] proyek dalam tahap coding, ada personel pada proyek yang terlibat dalam kegiatan biasanya terkait dengan banyak tahapan pembangunan 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 [[HUM89], [KEL89]] telah menunjukkan concurrency yang ada untuk kegiatan yang terjadi selama satu fase. Pekerjaan lebih baru Kellner ini [KEL91] menggunakan statecharts [notasi yang perwakilan- sents negara dari proses] untuk mewakili ada hubungan bersamaan antara kegiatan- kegiatan yang berhubungan dengan acara spesifik (misalnya, persyaratan berubah selama perkembangan akhir), tapi gagal untuk menangkap kekayaan concurrency yang ada di semua kegiatan pengembangan perangkat lunak dan manajemen dalam proyek. . . . Kebanyakan model proses pengembangan perangkat lunak didorong oleh waktu; nanti itu, kemudian dalam proses pembangunan Anda. [Sebuah proses sewa Model concur-] didorong oleh kebutuhan pengguna, keputusan manajemen, dan hasil kajian.
Model proses konkuren dapat direpresentasikan secara skematis sebagai rangkaian kegiatan utama teknis, tugas, dan negara-negara terkait. Misalnya, kegiatan engineering didefinisikan untuk model spiral (Bagian 2.7.2) dilakukan dengan menerapkan tugas-tugas berikut: prototyping dan / atau pemodelan analisis, persyaratan tertentu fi kasi, dan design.9
Gambar 2.10 memberikan gambaran skema satu kegiatan dengan concur- proses sewa Model. Kegiatan-analisis-mungkin dalam salah satu dari states10 mencatat pada waktu tertentu. Demikian pula, kegiatan lain (misalnya, desain atau pelanggan tion komunikasi) dapat direpresentasikan dengan cara analog. Semua kegiatan yang ada secara bersamaan namun berada di negara-negara yang berbeda. Misalnya, di awal proyek kegiatan komunikasi pelanggan (tidak ditampilkan dalam gambar) telah menyelesaikan iterasi pertama dan ada di negara perubahan menunggu. Kegiatan analisis (yang ada di negara none sementara komunikasi pelanggan awal selesai) sekarang membuat transisi ke negara pembangunan di bawah. Namun, jika pelanggan menunjukkan bahwa perubahan dalam persyaratan harus dilakukan, kegiatan analisis bergerak dari negara di bawah pembangunan ment ke negara perubahan menunggu. Konkuren model proses mendefinisikan serangkaian acara yang akan memicu tions transisi dari negara ke negara untuk setiap kegiatan rekayasa perangkat lunak. Misalnya,
selama tahap-tahap awal desain, inkonsistensi dalam model analisis terungkap. Ini menghasilkan acara model analisis koreksi yang akan memicu analisis aktivitas dari negara dilakukan ke negara perubahan menunggu. Model proses konkuren sering digunakan sebagai paradigma untuk pembangunan aplikasi client / server11 (Bab 28). Sebuah sistem client / server ditimbulkan dari satu set komponen fungsional. Bila diterapkan client / server, model proses konkuren mendefinisikan kegiatan dalam dua dimensi [SHE94]: dimensi sistem 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) aplikasi client / server khas diimplementasikan dengan banyak komponen, yang masing-masing dapat dirancang dan direalisasikan bersamaan.
Pada kenyataannya, model proses konkuren ini berlaku untuk semua jenis perangkat lunak ngunan bangan dan memberikan gambaran yang akurat tentang keadaan saat ini proyek. Daripada membatasi kegiatan rekayasa perangkat lunak untuk urutan peristiwa, mendefinisikan suatu jaringan dari aktivitas. Setiap aktivitas di jaringan ada bersamaan dengan kegiatan- kegiatan lainnya. Peristiwa yang dihasilkan dalam kegiatan tertentu atau di beberapa tempat lain di transisi memicu jaringan kegiatan antara negara-negara dari suatu kegiatan.
Ada perkiraan yang berkembang bahwa perangkat lunak, seperti semua sistem yang kompleks, berkembang selama periode waktu [GIL88]. Kebutuhan bisnis dan produk sering berubah selama proses pengembangan produk, membuat jalan yang lurus untuk 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 SLT atau sistem ekstensi belum akan de fi ned. Dalam situasi ini dan yang sejenis, insinyur peranti lunak membutuhkan model proses yang telah dirancang secara eksplisit untuk mengakomodasi produk yang berkembang dari waktu ke waktu. Model sekuensial linier (Bagian 2.4) dirancang untuk garis lurus pembangunan. Pada dasarnya, pendekatan Waterfallini mengasumsikan bahwa sistem yang lengkap akan disampaikan setelah urutan linear selesai. Prototipe Model (Bagian 2.5) dirancang untuk membantu pelanggan (atau pengembang) dalam memahami persyaratan. Secara umum, tidak dirancang untuk memberikan sistem produksi. Sifat evolusioner perangkat lunak tidak dipertimbangkan dalam salah satu dari paradigma 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 software
2.7.1 The Incremental Model
Model inkremental menggabungkan elemen dari model sekuensial 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 dokumen fungsi produksi dalam 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 proses aliran untuk peningkatan apapun dapat menggabungkan paradigma prototyping.
Ketika model inkremental digunakan, kenaikan pertama merupakan produk inti. Artinya, persyaratan dasar ditangani, tapi banyak fitur tambahan (beberapa diketahui, orang lain tidak diketahui) tetap tidak terkirim. Produk inti digunakan oleh customer (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 tambahan, sampai produk yang lengkap dihasilkan.
Proses Model inkremental, seperti prototyping (Bagian 2.5) dan pendekatan evolusioner lainnya, berulang secara alami. Tapi tidak seperti prototyping, model inkremental berfokus pada pengiriman produk operasional dengan kenaikan masing-masing. Awal kenaikan yang dipreteli versi produk akhir, tetapi mereka memberikan capability yang melayani pengguna dan juga menyediakan platform untuk evaluasi oleh pengguna. Pembangunan inkremental sangat berguna ketika susunan kepegawaian tidak tersedia untuk implementasi lengkap dengan batas waktu bisnis yang telah ditetapkan untuk proyek tersebut. Awal bertahap dapat diimplementasikan dengan 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 yang banyak.
2.7.2 The Spiral Model
Model spiral,awalnya diusulkan oleh Boehm [BOE88 ], adalah model proses software evolusi bahwa pasangan sifat berulang dari prototipe dengan aspek dikendalikan dan sistematis dari model sekuensial linier. Ini memberikan potensi perkembangan pesat dari versi tambahan dari perangkat lunak. Menggunakan model spiral, peranti lunak dikembangkan dalam serangkaian rilis inkremental. Selama perulangan awal, rilis inkremental mungkin model kertas atau prototipe. Selama perulangan selanjutnya, 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:
• komunikasi Pelanggan -tugas yang dibutuhkan untuk membangun komunikasi yang efektif antara pengembang dan pelanggan.
• Perencanaan-tugas yang dibutuhkan untuk de sumber fi ne, jadwal, dan informasi terkait proyek-lainnya.
• Risiko analisis-tugas yang dibutuhkan untuk menilai risiko baik teknis dan manajemen.
• Teknik-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi.
• Pembangunan dan Perilisan -tugas yang dibutuhkan untuk membangun, menguji, menginstal, dan memberikan dukungan pengguna (misalnya, dokumentasi dan pelatihan).
• evaluasi dari pelanggan -tugas yang dibutuhkan untuk memperoleh umpan balik pelanggan berdasarkan evaluasi representasi perangkat lunak yang dibuat selama tahap rekayasa dan dilaksanakan selama tahap instalasi.
Masing-masing daerah dihuni oleh satu set tugas pekerjaan, disebut tugas set, 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 memuat tugas pekerjaan lagi yang didefinisikan untuk mencapai tingkat yang lebih tinggi dari formalitas. Dalam semua kasus, Aktivitas Umbrella (misalnya, perangkat lunak con fi gurasi management 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 merepresentasikan titik awal untuk berbagai jenis proyek. Sebuah "konsep pengembanganproyek" dimulai pada inti spiral dan akan terus (beberapa iterasi terjadi di sepanjang jalur spiral yang batas-batas daerah yang diarsir tengah) sampai konsep pembangunan 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 bernomer 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 masuk yang sepatutnya (misalnya, peningkatan produk).
Model spiral adalah pendekatan realistis untuk pengembangan sistem berskala besar dan software. Karena software berkembang saat 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 menyatukannya menjadi kerangka berulang yang lebih realistis proyek berulang. Model spiral menuntut pertimbangan langsung risiko teknis di semua tahap-proyek dll dan, jika diterapkan dengan benar, harus mengurangi risiko sebelum mereka menjadi bermasalah.
Tapi seperti paradigma lain, model spiral bukanlah obat mujarab. Ini 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 paradigma sekuensial atau prototyping linear. Ini akan memakan waktu beberapa tahun sebelum kemujaraban dari paradigma penting ini dapat ditentukan dengan kepastian yang mutlak.
2.7.3 The Winwin Spiral Model
Model spiral dibahas dalam Bagian 2.7.2 menunjukkan aktivitas kerangka kerja yang membahas komunikasi pelanggan. Tujuan dari kegiatan ini adalah untuk memperoleh persyaratan proyek dari pelanggan. Dalam 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 masuk ke dalam proses negosiasi, di mana pelanggan dapat diminta untuk menyeimbangkan keberfungsiannya, kinerja, dan produk atau sistem karakteristik lainnya terhadap biaya dan waktu ke pasar.
Negosiasi terbaik berusaha untuk "win-win" result.7 Artinya, pelanggan menang dengan mendapatkan sistem atau produk yang terpenuhi es mayoritas kebutuhan pelanggan dan pengembang menang dengan bekerja untuk anggaran dan tenggat waktu yang realistis dan dapat dicapai.
Model spiral BOEHEM’sWinwin ini [BOE98] mendefinisikan serangkaian kegiatan negosiasi pada awal sekitar spiral. Daripada kominikasi hanya pada satu pelanggan, kegiatan berikut didefinisikan:
1. Identifikasi sistem atau kunci subsistem “stakeholders”
2. Determinasi dari stakeholder “win condition”
3. Negosiasi stakeholder' win kondisi untuk mendamaikan mereka ke dalam satu set 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. Model ral yang Winwin SPI diilustrasikan pada Gambar 2.9.
Selain penekanan pada negosiasi awal, model spiral WinWin memperkenalkan tiga tonggak proses, disebut jangkar poin [BOE96], yang membantu pem- lish menyelesaikan 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.
Yang 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 persyaratan sistem / produk. Anchor point kedua, arsitektur siklus hidup (LCA), menetapkan tujuan--tujuan yang harus dipenuhi sebagai sistem dan perangkat lunak arsitektur didefinisikan. Misalnya, sebagai bagian dari LCA, tim proyek perangkat lunak harus menunjukkan bahwa mereka telah mengevaluasi penerapan off-the-rak dan perangkat lunak dapat digunakan kembali komponen dan dianggap dampaknya terhadap keputusan arsitektur. Kemampuan operasional awal (IOC) adalah yang ketiga. jangkar titik dan merupakan serangkaian tujuan yang terkait dengan penyusunan perangkat lunak untuk instalasi / distribusi, persiapan lokasi sebelum instalasi, dan dikan asisten dibutuhkan oleh semua pihak yang akan menggunakan atau mendukung perangkat lunak.
2.7.4 The Concurrent Pengembangan Model
model pembangunan bersamaan, kadang-kadang disebut concurrent engineering, telah dijelaskan dengan cara berikut oleh Davis dan Sitaram [DAV94]:manajer proyek yang melacak status proyek dalam hal fase utama [dari siklus hidup klasik] tidak tahu status proyek-proyek mereka. Ini adalah contoh dari mencoba untuk melacak set yang sangat kompleks dari kegiatan menggunakan model terlalu sederhana. Perhatikan bahwa meskipun. . . [besar] proyek dalam tahap coding, ada personel pada proyek yang terlibat dalam kegiatan biasanya terkait dengan banyak tahapan pembangunan 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 [[HUM89], [KEL89]] telah menunjukkan concurrency yang ada untuk kegiatan yang terjadi selama satu fase. Pekerjaan lebih baru Kellner ini [KEL91] menggunakan statecharts [notasi yang perwakilan- sents negara dari proses] untuk mewakili ada hubungan bersamaan antara kegiatan- kegiatan yang berhubungan dengan acara spesifik (misalnya, persyaratan berubah selama perkembangan akhir), tapi gagal untuk menangkap kekayaan concurrency yang ada di semua kegiatan pengembangan perangkat lunak dan manajemen dalam proyek. . . . Kebanyakan model proses pengembangan perangkat lunak didorong oleh waktu; nanti itu, kemudian dalam proses pembangunan Anda. [Sebuah proses sewa Model concur-] didorong oleh kebutuhan pengguna, keputusan manajemen, dan hasil kajian.
Model proses konkuren dapat direpresentasikan secara skematis sebagai rangkaian kegiatan utama teknis, tugas, dan negara-negara terkait. Misalnya, kegiatan engineering didefinisikan untuk model spiral (Bagian 2.7.2) dilakukan dengan menerapkan tugas-tugas berikut: prototyping dan / atau pemodelan analisis, persyaratan tertentu fi kasi, dan design.9
Gambar 2.10 memberikan gambaran skema satu kegiatan dengan concur- proses sewa Model. Kegiatan-analisis-mungkin dalam salah satu dari states10 mencatat pada waktu tertentu. Demikian pula, kegiatan lain (misalnya, desain atau pelanggan tion komunikasi) dapat direpresentasikan dengan cara analog. Semua kegiatan yang ada secara bersamaan namun berada di negara-negara yang berbeda. Misalnya, di awal proyek kegiatan komunikasi pelanggan (tidak ditampilkan dalam gambar) telah menyelesaikan iterasi pertama dan ada di negara perubahan menunggu. Kegiatan analisis (yang ada di negara none sementara komunikasi pelanggan awal selesai) sekarang membuat transisi ke negara pembangunan di bawah. Namun, jika pelanggan menunjukkan bahwa perubahan dalam persyaratan harus dilakukan, kegiatan analisis bergerak dari negara di bawah pembangunan ment ke negara perubahan menunggu. Konkuren model proses mendefinisikan serangkaian acara yang akan memicu tions transisi dari negara ke negara untuk setiap kegiatan rekayasa perangkat lunak. Misalnya,
selama tahap-tahap awal desain, inkonsistensi dalam model analisis terungkap. Ini menghasilkan acara model analisis koreksi yang akan memicu analisis aktivitas dari negara dilakukan ke negara perubahan menunggu. Model proses konkuren sering digunakan sebagai paradigma untuk pembangunan aplikasi client / server11 (Bab 28). Sebuah sistem client / server ditimbulkan dari satu set komponen fungsional. Bila diterapkan client / server, model proses konkuren mendefinisikan kegiatan dalam dua dimensi [SHE94]: dimensi sistem 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) aplikasi client / server khas diimplementasikan dengan banyak komponen, yang masing-masing dapat dirancang dan direalisasikan bersamaan.
Pada kenyataannya, model proses konkuren ini berlaku untuk semua jenis perangkat lunak ngunan bangan dan memberikan gambaran yang akurat tentang keadaan saat ini proyek. Daripada membatasi kegiatan rekayasa perangkat lunak untuk urutan peristiwa, mendefinisikan suatu jaringan dari aktivitas. Setiap aktivitas di jaringan ada bersamaan dengan kegiatan- kegiatan lainnya. Peristiwa yang dihasilkan dalam kegiatan tertentu atau di beberapa tempat lain di transisi memicu jaringan kegiatan antara negara-negara dari suatu kegiatan.
0 Response to "MODEL EVOLUSI PERANGKAT LUNAK"
Post a Comment