Model Proses Perangkat Lunak

Model Proses Preskriptif

Model proses preskriptif awalnya diusulkan untuk meredakan kekacauan pengembangan perangkat lunak. Sejarah telah menunjukkan bahwa model-model tradisional telah membawa sejumlah struktur yang berguna untuk pekerjaan rekayasa perangkat lunak dan telah menyediakan peta jalan cukup efektif untuk tim perangkat lunak. Namun, pekerjaan rekayasa perangkat lunak dan produk yang menghasilkan tetap di "tepi kekacauan."

Implikasi filosofis dari argumen ini adalah signifikan untuk rekayasa perangkat lunak. Jika proses model preskriptif berusaha untuk terstruktur dan ketertiban, mereka tidak pantas untuk dunia perangkat lunak yang tumbuh subur pada perubahan. Namun, jika kita menolak model proses tradisional (dan urutan mereka menyiratkan) dan menggantinya dengan sesuatu yang kurang terstruktur, kita membuat tidak mungkin untuk mencapai koordinasi dan koherensi dalam pekerjaan perangkat lunak?

Tidak ada jawaban mudah untuk pertanyaan-pertanyaan ini, tetapi ada alternatif yang tersedia untuk engineer perangkat lunak. Pada bagian berikut, saya memeriksa pendekatan proses preskriptif dimana rangka dan konsistensi proyek adalah masalah yang dominan. Saya menyebutnya "preskriptif" karena mereka meresepkan satu set proses kegiatan elemen-kerangka, tindakan rekayasa perangkat lunak, tugas, produk kerja, jaminan kualitas, dan mengubah mekanisme kontrol untuk setiap proyek. Setiap model proses juga mengatur aliran proses (juga disebut alur kerja) yaitu, dengan cara di mana proses elemen yang saling terkait satu sama lain.

Semua model proses perangkat lunak dapat mengakomodasi kegiatan kerangka kerja umum dijelaskan pada Bab 1, tetapi masing-masing berlaku penekanan yang berbeda untuk kegiatan ini dan mendefinisikan aliran proses yang memanggil setiap kegiatan kerangka (serta tindakan rekayasa perangkat lunak dan tugas) dengan cara yang berbeda.

A. Waterfall Model

Ada kalanya persyaratan untuk masalah dipahami dengan baik ketika pekerjaan mengalir dari komunikasi melalui penyebaran secara cukup linear. Situasi ini kadang-kadang ditemui ketika adaptasi didefinisikan dengan baik atau perangkat tambahan untuk sistem yang ada harus dibuat (misalnya, sebuah adaptasi untuk software akuntansi yang telah diamanatkan karena perubahan peraturan pemerintah). Hal ini juga dapat terjadi pada sejumlah upaya pengembangan baru, tapi hanya jika persyaratan didefinisikan dengan baik dan cukup stabil.

Model air terjun, 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. Sebuah variasi dalam representasi model air terjun disebut V-model yang. Terwakili dalam, 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 (tindakan jaminan mutu) yang memvalidasi masing-masing model dibuat sebagai tim pindah ke sisi kiri. Pada kenyataannya, tidak ada perbedaan mendasar antara siklus hidup klasik dan model V-. V-model yang menyediakan cara untuk memvisualisasikan bagaimana verifikasi dan validasi tindakan yang diterapkan untuk pekerjaan rekayasa sebelumnya.

Model air terjun adalah paradigma tertua untuk rekayasa perangkat lunak. Namun, selama tiga dekade terakhir, kritik model proses ini telah menyebabkan bahkan pendukung bersemangat untuk mempertanyakan kemanjurannya. Di antara masalah yang kadang-kadang ditemui ketika model air terjun diterapkan adalah:

1. Proyek nyata jarang mengikuti aliran sekuensial bahwa model mengusulkan. Meskipun model linier bisa mengakomodasi iterasi, ia melakukannya secara tidak langsung. Akibatnya, perubahan dapat menyebabkan kebingungan sebagai hasil tim proyek.
2. Hal ini sering sulit bagi pelanggan untuk menyatakan semua persyaratan eksplisit. Model air terjun 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 proyek. Sebuah kesalahan besar, jika tidak terdeteksi sampai program kerja ditinjau, bisa menjadi bencana.

Dalam sebuah analisis menarik dari proyek yang sebenarnya, Bradac [Bra94] menemukan bahwa sifat linear dari siklus hidup klasik mengarah ke "menghalangi negara" di mana beberapa anggota tim proyek harus menunggu anggota lain dari tim untuk menyelesaikan tugas-tugas tergantung. Bahkan, waktu yang dihabiskan menunggu dapat melebihi waktu yang dihabiskan untuk pekerjaan produktif! Negara-negara memblokir cenderung lebih umum pada awal dan akhir dari proses sekuensial linier.

B. Model Proses Incremental

Ada banyak situasi di mana persyaratan perangkat lunak awal didefinisikan cukup baik, tetapi ruang lingkup keseluruhan upaya pengembangan menghalangi proses murni linear. Selain itu, mungkin ada kebutuhan mendesak untuk menyediakan satu set terbatas fungsi perangkat lunak untuk pengguna dengan cepat dan kemudian memperbaiki dan memperluas fungsi yang di rilis software kemudian. Dalam kasus tersebut, Anda dapat memilih model proses yang dirancang untuk menghasilkan perangkat lunak secara bertahap.

Model inkremental menggabungkan elemen dari proses linear dan sejajar arus dibahas dalam Bagian 2.1. Mengacu pada Gambar 2.5, model inkremental berlaku urutan linear dalam mode terhuyung sebagai waktu berjalan kalender. Setiap urutan linier menghasilkan penyampaian "bertahap" dari perangkat lunak [McD93] dengan cara yang mirip dengan kenaikan yang dihasilkan oleh aliran proses evolusi (Bagian 2.3.3).

Sebagai contoh, perangkat lunak pengolah kata yang dikembangkan menggunakan paradigma tambahan mungkin memberikan manajemen dasar berkas, mengedit, dan fungsi produksi dokumen selisih pertama; lebih canggih editing dan produksi dokumen kemampuan 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 dikenal, yang lain tidak diketahui) tetap tidak terkirim. Produk inti digunakan oleh pelanggan (atau mengalami rinci evaluasi). 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 lengkap diproduksi.

Model proses inkremental berfokus pada penyampaian produk operasional dengan kenaikan masing-masing. Kenaikan awal adalah versi dilucuti-down dari produk akhir, tetapi mereka memberikan kemampuan yang berfungsi pengguna dan juga menyediakan platform untuk evaluasi oleh pengguna.

Pembangunan inkremental sangat berguna ketika staf tidak tersedia untuk implementasi lengkap dengan tenggat waktu bisnis yang telah ditetapkan untuk proyek tersebut. Kenaikan awal 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. Misalnya, 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.

C. Model Proses Evolusioner

Software, seperti semua sistem yang kompleks, berkembang selama periode waktu. Bisnis dan produk persyaratan sering berubah sebagai hasil pengembangan, pembuatan jalan garis lurus untuk produk akhir tidak realistis; tenggat waktu pasar yang ketat membuat penyelesaian produk perangkat lunak yang komprehensif tidak mungkin, tapi versi terbatas harus diperkenalkan untuk memenuhi tekanan kompetitif atau bisnis; seperangkat produk inti atau sistem persyaratan dipahami dengan baik, tetapi rincian produk atau sistem ekstensi belum didefinisikan. Dalam situasi ini dan yang sejenis, Anda membutuhkan model proses yang telah secara eksplisit dirancang untuk mengakomodasi produk yang berkembang dari waktu ke waktu.

Model evolusi yang berulang. Mereka dicirikan dengan cara yang memungkinkan Anda untuk mengembangkan versi semakin lebih lengkap dari perangkat lunak. Dalam paragraf berikut, saya hadir dua model proses evolusi umum.

a. Prototyping

Seringkali, pelanggan 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 algoritma, adaptasi dari sistem operasi, atau bentuk interaksi manusia-mesin harus mengambil. Dalam hal ini, dan banyak situasi lainnya, prototyping sebuah paradigmmay menawarkan pendekatan yang terbaik.

Meskipun prototyping dapat digunakan sebagai model proses yang berdiri sendiri, itu lebih sering digunakan sebagai teknik yang dapat diterapkan dalam konteks salah satu dari model proses mencatat dalam bab ini. Terlepas dari cara di mana itu diterapkan, paradigma prototyping membantu Anda dan pemangku kepentingan lainnya untuk lebih memahami apa yang harus dibangun ketika persyaratan yang kabur.

Prototyping paradigma dimulai dengan komunikasi. Anda bertemu dengan pemangku kepentingan lainnya untuk menentukan tujuan keseluruhan untuk perangkat lunak, mengidentifikasi persyaratan apa pun 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 persyaratan. 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.

Idealnya, prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat lunak. Jika prototipe kerja 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.

Prototipe dapat berfungsi sebagai "sistem pertama." Salah satu yang Brooks merekomendasikan Anda membuang. Tapi ini mungkin pandangan ideal. Meskipun beberapa prototipe dibangun sebagai "buangan," yang lain evolusi dalam arti bahwa prototipe perlahan berkembang menjadi sistem yang sebenarnya.

Kedua stakeholder dan engineer perangkat lunak seperti paradigma prototyping. Pengguna bisa merasakan sistem yang sebenarnya, dan pengembang bisa membangun sesuatu segera. Namun, prototyping dapat menjadi masalah karena alasan berikut:

1. Stakeholder melihat apa yang tampaknya menjadi versi kerja perangkat lunak, tidak menyadari bahwa prototipe diadakan bersama-sama sembarangan, tidak menyadari bahwa terburu-buru untuk mendapatkannya bekerja Anda belum dianggap kualitas perangkat lunak secara keseluruhan atau kemampuan pemeliharaan jangka panjang. Ketika diberitahu bahwa produk harus dibangun kembali sehingga tingkat kualitas yang tinggi dapat dipertahankan, stakeholder menangis busuk dan permintaan yang "sedikit perbaikan" diterapkan untuk membuat prototipe produk bekerja. Terlalu sering, manajemen pengembangan perangkat lunak mengalah.
2. Sebagai seorang engineer perangkat lunak, Anda sering membuat kompromi implementasi untuk mendapatkan prototipe bekerja dengan cepat. Sebuah sistem operasi yang tidak pantas atau bahasa pemrograman dapat digunakan hanya karena tersedia dan dikenal; 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 integral dari sistem.

Meskipun masalah dapat terjadi, prototyping 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 persyaratan. Hal ini kemudian dibuang (setidaknya sebagian), dan perangkat lunak aktual direkayasa dengan mata ke arah kualitas.

b. Spiral

Awalnya diusulkan oleh Boehm Barry [Boe88], Model Spiral adalah sebuah perangkat lunak model proses evolusi yang pasangan sifat iteratif dari prototipe dengan aspek dikendalikan dan sistematis dari model air terjun. Menggunakan model spiral, software dikembangkan dalam serangkaian rilis evolusi. Selama iterasi awal, rilis mungkin model atau prototipe. Selama iterasi kemudian, versi semakin lebih lengkap dari sistem rekayasa diproduksi.

Sebuah model spiral dibagi menjadi serangkaian kegiatan kerangka didefinisikan oleh tim rekayasa perangkat lunak. Untuk ilustrasi, saya menggunakan kegiatan kerangka kerja umum dibahas sebelumnya. Setiap kegiatan kerangka merupakan salah satu segmen dari jalur spiral diilustrasikan dalam Sebagai proses evolusi ini dimulai, tim software melakukan kegiatan yang tersirat oleh sirkuit sekitar spiral searah jarum jam, dimulai di pusat. Risiko dianggap sebagai setiap revolusi dibuat. Jangkar titik tonggak kombinasi 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. Setiap melewati hasil wilayah perencanaan penyesuaian dengan rencana proyek. Biaya dan jadwal disesuaikan berdasarkan umpan balik yang berasal dari pelanggan setelah melahirkan. Selain itu, manajer proyek menyesuaikan jumlah direncanakan iterasi yang diperlukan untuk menyelesaikan perangkat lunak.

Tidak seperti model proses lain yang berakhir ketika software 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 "proyek pengembangan produk baru" dimulai. Produk baru akan berkembang melalui sejumlah iterasi sekitar spiral. Kemudian, sirkuit sekitar spiral dapat digunakan untuk mewakili "proyek peningkatan produk." Pada intinya, spiral, ketika ditandai dengan cara ini, tetap operatif sampai perangkat lunak 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 merupakan 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 prototipe sebagai mekanisme pengurangan risiko tetapi, yang lebih penting, memungkinkan Anda untuk menerapkan pendekatan prototyping pada setiap tahap dalam evolusi produk. Ia memelihara pendekatan bertahap sistematis 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 lainnya, model spiral bukanlah obat mujarab. Mungkin sulit untuk meyakinkan pelanggan (terutama dalam situasi kontrak) bahwa pendekatan evolusioner 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.

D. Concurrent Model

Model pembangunan bersamaan, kadang-kadang disebut concurrent engineering, memungkinkan tim software untuk mewakili elemen berulang dan bersamaan dari setiap model proses yang diuraikan dalam bab ini. Sebagai contoh, kegiatan pemodelan yang ditetapkan untuk model spiral dicapai dengan menerapkan satu atau lebih dari berikut tindakan rekayasa perangkat lunak: prototyping, analisis, dan desain.

Model pembangunan bersamaan, kadang-kadang disebut concurrent engineering, memungkinkan tim software untuk mewakili elemen berulang dan bersamaan dari setiap model proses yang diuraikan dalam bab ini. Sebagai contoh, kegiatan pemodelan yang ditetapkan untuk model spiral dicapai dengan menerapkan satu atau lebih dari berikut tindakan rekayasa perangkat lunak: prototyping, analisis, dan desain.

Pemodelan bersamaan mendefinisikan serangkaian acara yang akan memicu transisi dari negara ke negara untuk setiap kegiatan rekayasa perangkat lunak, tindakan, atau tugas. Sebagai contoh, selama tahap awal desain (tindakan rekayasa perangkat lunak utama yang terjadi selama kegiatan modeling), inkonsistensi dalam model persyaratan yang ditemukan. Ini menghasilkan analisis acara koreksi model, yang akan memicu aksi analisis kebutuhan dari negara yang dilakukan ke negara perubahan menunggu.

Pemodelan bersamaan berlaku untuk semua jenis pengembangan perangkat lunak dan memberikan gambaran yang akurat tentang keadaan saat proyek. Daripada membatasi kegiatan rekayasa perangkat lunak, tindakan, dan tugas untuk urutan peristiwa, mendefinisikan jaringan proses. Setiap kegiatan, tindakan, atau tugas pada jaringan ada bersamaan dengan kegiatan lain, tindakan, atau tugas. Peristiwa yang dihasilkan pada satu titik dalam memicu transisi jaringan proses antara negara-negara.

Daftar Pustaka/ Reference

Pressman, Roger S. 2010. Software Engineering A Practitioner's Approach. ed 7. New York: Higher Education. dikutip pada 5 Oktober 2015 21.13 WIB. tersedia pada hal. 38-49. diterjemahkan oleh google tranlate.co.id 

Read More