MODEL-MODEL PROSES PERANGKAT LUNAK

1. THE SPIRAL MODEL.

Model spiral adalah sebuah perangkat lunak model proses evolusi yang sifat iteratif sama seperti prototipe dengan aspek dikendalikan dan sistematis dari waterfall model. Ini memberikan potensi perkembangan pesat dari versi yang semakin lebih lengkap dari perangkat lunak.

Dengan menggunakan model spiral, perangkat lunak yang dikembangkan dalam serangkaian rilis perubahan. Selama iterasi awal, rilis mungkin akan sebuah model atau prototipe. Iterasi kemudian, versi yang semakin lebih lengkap dari sistem rekayasa.

(1.1)

Untuk ilustrasi, saya menggunakan kegiatan kerangka kerja umum dibahas sebelumnya. Setiap kegiatan kerangka merupakan salah satu segmen dari jalur spiral diilustrasikan pada Gambar 2.7. Sebagai proses evolusi ini dimulai, tim perangkat lunak yang melakukan kegiatan yang tersirat oleh sirkuit sekitar spiral searah jarum jam, dimulai di pusat. Risiko (Bab 28) dianggap sebagai setiap putarannya dibuat. Jangkar titik pencapaian-gabungan dari produk dan kondisi kerja yang dicapai sepanjang jalur spiral-dicatat untuk setiap lulus evolusi.

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 ini. Setiap melewati hasil wilayah perencanaan penyesuaian dengan rencana proyek. Biaya dan jadwal disesuaikan berdasarkan umpan balik yang berasal dari pelanggan setelah ditawarkan.

Tidak seperti model proses lain yang berakhir ketika perangkat lunak yang disampaikan, model spiral dapat disesuaikan untuk menerapkan seluruh kehidupan perangkat lunak komputer. Oleh karena itu, rangkaian pertama sekitar spiral mungkin merupakan "proyek pengembangan konsep" yang dimulai pada inti spiral dan berlanjut selama beberapa iterasi sampai pengembangan konsep selesai. Jika konsep ini untuk dikembangkan menjadi produk yang sebenarnya, proses hasil luar pada spiral dan "rancangan pengembangan produk baru" dimulai. Produk baru akan berkembang melalui sejumlah iterasi sekitar spiral. Kemudian, sirkuit sekitar spiral dapat digunakan untuk mewakili "rancangan peningkatan produk." Pada intinya, spiral, ketika ditandai dengan cara ini, tetap operatif sampai perangkat lunak yang tersebut pensiun. Ada kalanya proses ini tidak aktif, tapi setiap kali perubahan dimulai, proses dimulai pada titik entri yang sesuai (misalnya, peningkatan produk).

Tapi seperti paradigma lainnya, model spiral bukanlah obat mujarab. Mungkin sulit untuk meyakinkan pelanggan (terutama dalam situasi kontrak) bahwa pendekatan evolusi dapat dikontrol. Hal ini menuntut keahlian penilaian risiko yang cukup besar dan bergantung pada keahlian ini untuk sukses. Jika risiko utama tidak ditemukan dan berhasil, masalah pasti akan terjadi.

2.      THE UNIFIED PROCESS

(1.2)

Tahap awal meliputi komunikasi pelanggan dan kegiatan perencanaan. Dengan bekerja sama dengan para pemangku kepentingan, kebutuhan bisnis untuk perangkat lunak diidentifikasi; arsitektur kasar untuk sistem ini diusulkan; dan rencana untuk, sifat inkremental iteratif proyek berikutnya dikembangkan. Kebutuhan bisnis mendasar dijelaskan melalui serangkaian kasus penggunaan awal yang menggambarkan fitur dan fungsi masing-masing kelas utama dari pengguna keinginan. Arsitektur pada saat ini tidak lebih dari garis tentatif subsistem utama dan fungsi dan fitur yang mengisi mereka. Kemudian, arsitektur akan disempurnakan dan diperluas menjadi satu set model yang akan mewakili pandangan yang berbeda dari sistem. Perencanaan sumber daya mengidentifikasi, menilai risiko utama, mendefinisikan jadwal, dan menetapkan dasar untuk fase yang akan diterapkan sebagai kenaikan software dikembangkan.

Fase elaborasi meliputi kegiatan komunikasi dan pemodelan model proses generik (Gambar 2.9). Elaborasi memurnikan dan memperluas kasus penggunaan awal yang dikembangkan sebagai bagian dari tahap awal dan memperluas representasi arsitektur mencakup lima pandangan yang berbeda dari perangkat lunak-model use case, model persyaratan, model desain, model pelaksanaan, dan model penyebaran. Dalam beberapa kasus, elaborasi menciptakan "dasar arsitektur executable" [Arl02] yang merupakan "potongan pertama" executable system. Baseline arsitektur menunjukkan kelayakan arsitektur tetapi tidak menyediakan semua fitur dan fungsi yang diperlukan untuk menggunakan sistem. Selain itu, rencana tersebut ditinjau pada puncak dari fase elaborasi untuk memastikan bahwa ruang lingkup, risiko, dan tanggal pengiriman tetap wajar. Modifikasi rencana sering dilakukan saat ini.

Tahap konstruksi identik dengan kegiatan konstruksi yang ditetapkan untuk proses software generik. Menggunakan model arsitektur sebagai input, tahap konstruksi mengembangkan atau mengakuisisi komponen perangkat lunak yang akan membuat setiap kasus penggunaan operasional bagi pengguna akhir. Untuk mencapai hal ini, persyaratan dan model desain yang dimulai selama fase elaborasi selesai untuk mencerminkan versi final dari kenaikan software. Semua fitur dan fungsi yang diperlukan dan dibutuhkan untuk peningkatan software (yaitu, rilis) yang kemudian diimplementasikan dalam kode sumber. Sebagai komponen sedang dilaksanakan, tes unit dirancang dan dilaksanakan untuk setiap. Selain itu, kegiatan integrasi (komponen perakitan dan pengujian integrasi) dilakukan. Gunakan kasus digunakan untuk menurunkan suite tes penerimaan yang dijalankan sebelum inisiasi tahap  berikutnya.

Fase transisi meliputi tahap terakhir dari kegiatan konstruksi generik dan bagian pertama dari penyebaran generik (pengiriman dan umpan balik) aktivitas. Software diberikan kepada pengguna akhir untuk pengujian beta dan umpan balik pengguna laporan baik cacat dan perubahan yang diperlukan. Selain itu, tim perangkat lunak menciptakan informasi dukungan yang diperlukan (misalnya, buku petunjuk, panduan troubleshooting, prosedur instalasi) yang diperlukan untuk rilis. Pada akhir fase transisi, selisih perangkat lunak menjadi rilis software yang dapat digunakan.

Tahap produksi bertepatan dengan kegiatan penyebaran proses generik. Selama fase ini, penggunaan berkelanjutan dari software ini dipantau, dukungan untuk lingkungan operasi (infrastruktur) yang disediakan, dan laporan cacat dan permintaan untuk perubahan diserahkan dan dievaluasi.

Sebuah alur kerja rekayasa perangkat lunak didistribusikan di seluruh fase. Dalam konteks, alur kerja adalah analog dengan seperangkat tugas (dijelaskan sebelumnya dalam bab ini). Artinya, alur kerja mengidentifikasi tugas-tugas yang diperlukan untuk mencapai suatu tindakan rekayasa perangkat lunak penting dan produk kerja yang dihasilkan sebagai konsekuensi dari berhasil menyelesaikan tugas. Perlu dicatat bahwa tidak setiap tugas diidentifikasi untuk alur kerja dilakukan untuk setiap proyek software. Tim menyesuaikan proses (tindakan, tugas, sub-tugas, dan produk kerja) untuk memenuhi kebutuhannya.

3.      THE WATERFALL MODEL

Model waterfall, kadang-kadang disebut siklus hidup klasik, menunjukkan sistematis,
Pendekatan sekuensial untuk pengembangan perangkat lunak yang diawali dengan spesifikasi pelanggan persyaratan dan berkembang melalui perencanaan, pemodelan, konstruksi, dan penyebaran, yang berpuncak pada dukungan yang berkelanjutan dari perangkat lunak selesai (Gambar 2.3).

(1.3)

Model waterfall adalah paradigma tertua untuk rekayasa perangkat lunak. Namun, selama tiga dekade terakhir, kritik model proses ini menyebabkan pendukung  untuk mempertanyakan kemanjurannya [Han95]. Di antara masalah yang kadang-kadang dihadapi saat model air terjun diterapkan adalah:

1.      proyek nyata jarang mengikuti aliran sekuensial menempatkan model tersebut diusulkan. Meskipun model linier bisa mengakomodasi iterasi, ia melakukannya secara tidak langsung. Akibatnya, perubahan dapat menyebabkan kebingungan sebagai hasil tim proyek.

2.      Biasanya sulit bagi pelanggan untuk menyatakan semua persyaratan secara jelas. Model waterfall membutuhkan ini dan memiliki kesulitan mengakomodasi ketidakpastian natural yang ada pada awal banyak proyek.

3.      Pelanggan harus memiliki kesabaran. Sebuah versi kerja dari program tidak akan tersedia sampai akhir dalam rentang waktu rancangan. Sebuah kesalahan besar, jika tanpa diketahui sampai program kerja ditinjau, bisa menjadi bencana.

Sekarang ini, kerja perangkat lunak yang serba cepat dan tergantung aliran perubahan yang tak pernah berakhir (untuk fitur, fungsi, dan isi informasi). Model waterfall ini sering tidak pantas untuk pekerjaan tersebut. Namun, dapat berfungsi sebagai model proses yang berguna dalam situasi di mana persyaratan tetap dan bekerja  untuk melanjutkan ke penyelesaian secara linear.

4.      PROTOTYPING

Seringkali, customer mendefinisikan satu set tujuan umum untuk perangkat lunak, tetapi tidak mengidentifikasi persyaratan rinci untuk fungsi dan fitur. Dalam kasus lain, pengembang mungkin tidak yakin efisiensi sebuah algoritma, adaptasi dari sistem operasi, atau bentuk interaksi manusia-mesin harus dilakukan. Dalam hal ini, dan beberapa situasi , paradigma prototyping mungkin menawarkan pendekatan yang terbaik.

Prototyping paradigma (Gambar 2.6) dimulai dengan komunikasi. Anda bertemu dengan pemangku kepentingan lainnya untuk menentukan tujuan keseluruhan untuk perangkat lunak, mengidentifikasi Kebutuhan apa saja yang diketahui, dan garis besar daerah di mana definisi lebih lanjut adalah wajib. Sebuah prototipe iterasi direncanakan cepat, dan pemodelan (dalam bentuk "desain cepat") terjadi. Sebuah desain cepat berfokus pada representasi dari aspek-aspek perangkat lunak yang akan terlihat oleh pengguna akhir (misalnya, tata letak interface atau tampilan output format manusia). Desain cepat mengarah ke pembangunan prototipe. Prototipe ini digunakan dan dievaluasi oleh pemangku kepentingan, yang memberikan umpan balik yang digunakan untuk lebih menyempurnakan Kebutuhan. Iterasi terjadi sebagai prototipe disetel untuk memenuhi kebutuhan berbagai pemangku kepentingan, sementara pada saat yang sama memungkinkan Anda untuk lebih memahami apa yang perlu dilakukan.

(1.4)

Idealnya, prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat lunak. Jika prototipenya yang akan dibangun, Anda dapat menggunakan fragmen program yang ada atau menerapkan alat-alat (misalnya, generator laporan dan window manager) yang memungkinkan program kerja yang akan dihasilkan dengan cepat.

Prototyping dapat menjadi masalah karena alasan berikut:

1.              Stakeholder melihat apa yang tampaknya menjadi kerja perangkat lunak, tidak menyadari bahwa prototipe diadakan secara asal saja, tidak menyadari bahwa terburu-buru untuk mengerti kerja kualitas perangkat lunak Anda secara keseluruhan atau kemampuan pemeliharaan jangka panjang. Ketika diberitahu bahwa produk harus dibangun kembali sehingga tingkat kualitas yang tinggi dapat dipertahankan, stakeholder mengaggapnya tidak adil dan menuntut yang "beberapa perbaikan" diterapkan untuk membuat prototipe produk bekerja. Sering kali, manajemen pengembangan perangkat lunak mengalah.

2.                 Sebagai seorang insinyur perangkat lunak, Anda sering membuat kompromi implementasi untuk mendapatkan prototipenya dengan cepat. Sebuah sistem operasi yang tidak pantas atau bahasa pemrograman dapat digunakan hanya karena ia tersedia dan dikenal; sebuah algoritma yang tidak efisien dapat diimplementasikan hanya untuk menunjukkan kemampuan. Setelah beberapa saat, Anda mungkin merasa nyaman dengan pilihan ini dan melupakan semua alasan mengapa mereka tidak pantas. Kurang dari ideal pilihan sekarang telah menjadi bagian utuh dari sistem.’

Meskipun masalah dapat terjadi, prototipe dapat menjadi paradigma yang efektif untuk rekayasa perangkat lunak. Kuncinya adalah untuk menentukan aturan main di awal; yaitu, semua stakeholder harus setuju bahwa prototype dibangun untuk melayani sebagai mekanisme untuk mendefinisikan Kebutuhan. Hal ini kemudian akan dibuang (setidaknya sebagian), dan perangkat lunak aktual direkayasa dengan mata tertuju pada kualitas.

5.      V-MODEL

Salah satu variasi dalam representasi model air terjun yakni V-model yang diwakili dalam Gambar 1.5, V-Model [Buc99] menggambarkan hubungan tindakan jaminan kualitas terhadap tindakan yang terkait dengan komunikasi, pemodelan, dan kegiatan konstruksi awal. Sebagai tim software bergerak ke sisi kiri V, persyaratan masalah dasar yang disempurnakan menjadi representasi semakin lebih rinci dan teknis dari masalah dan solusinya. Setelah kode telah dihasilkan, tim bergerak naik sisi kanan V, pada dasarnya melakukan serangkaian tes (langkah jaminan mutu) yang memvalidasi masing-masing model dibuat sebagai tim pindah ke sisi kiri bawah. Pada kenyataannya, tidak ada perbedaan mendasar antara siklus hidup klasik dan model V-model. V-model yang menyediakan cara untuk memvisualisasikan bagaimana verifikasi dan validasi langkah yang diterapkan untuk pekerjaan rekayasa sebelumnya.

                                                           
                                                                (1.5)

sumber: Pressman, Roger s. 2010. software engineering 7th edition

Posted in: