Metodologi Pengembangan Software Klasik dan Yang Lain

7.1. Metodologi Pengembangan Software Klasik dan Yang Lain

Empat model proses pengembangan software yang akan dibicarakan adalah :  Model Software Development Life Cycle (SDLC)

 Model Prototyping  Model Spiral  Model Object Oriented

The Software Development Life Cycle model (model SDLC) adalah model klasik (masih berlaku sekarang), tetapi memberikan yang paling komprehensif deskripsi proses yang tersedia. Model ini menampilkan bangunan utama blok untuk seluruh proses pembangunan, yang digambarkan sebagai sebuah urutan linier. Dalam tahap awal dari proses pengembangan perangkat lunak, dokumen desain produk disusun, dengan versi pertama dari program komputer selesai dan disajikan untuk evaluasi hanya pada cukup tahap akhir dari proses. The Model SDLC dapat berfungsi sebagai kerangka kerja bagi model lain disajikan.

Model prototyping didasarkan pada penggantian satu atau lebih SDLC model tahap oleh proses evolusi, di mana prototipe perangkat lunak digunakan untuk komunikasi antara pengembang dan pengguna dan pelanggan. Prototipe yang disampaikan kepada perwakilan pengguna untuk evaluasi. The pengembang kemudian melanjutkan pengembangan suatu prototipe yang lebih canggih, yang juga disampaikan untuk evaluasi. Proses evolusi terus sampai proyek software selesai atau prototipe perangkat lunak telah mencapai tahap yang diinginkan. Dalam hal ini, seluruh proses pembangunan dapat dilaksanakan sesuai dengan metodologi yang berbeda, misalnya klasik SDLC model.

Model spiral menyediakan metodologi untuk menjamin kinerja yang efektif pada setiap fase SDLC model. Ini melibatkan proses yang berulang-ulang yang mengintegrasikan komentar pelanggan dan persyaratan perubahan, analisis resiko dan resolusi, dan perencanaan sistem perangkat lunak dan rekayasa kegiatan. Salah satu atau iterasi lebih dari model spiral mungkin diperlukan untuk menyelesaikan masing-masing proyek fase SDLC. Tugas rekayasa terkait mungkin dilakukan menurut model apapun satu atau kombinasi dari mereka.

Model berorientasi objek menggabungkan kembali besar-besaran perangkat lunak oleh mengintegrasikan modul-modul yang dapat digunakan kembali ke dalam sistem perangkat lunak baru. Dalam kasus dimana tidak modul perangkat lunak dapat digunakan kembali (disebut objek atau komponen) yang tersedia, pengembang dapat melakukan suatu prototipe atau proses SDLC untuk menyelesaikan baru mengembangkan sistem perangkat lunak. Semua empat model akan disajikan secara rinci dalam empat bagian berikutnya. Diskusi rinci dari metodologi masing-masing tersedia dalam Model berorientasi objek menggabungkan kembali besar-besaran perangkat lunak oleh mengintegrasikan modul-modul yang dapat digunakan kembali ke dalam sistem perangkat lunak baru. Dalam kasus dimana tidak modul perangkat lunak dapat digunakan kembali (disebut objek atau komponen) yang tersedia, pengembang dapat melakukan suatu prototipe atau proses SDLC untuk menyelesaikan baru mengembangkan sistem perangkat lunak. Semua empat model akan disajikan secara rinci dalam empat bagian berikutnya. Diskusi rinci dari metodologi masing-masing tersedia dalam

7.1.1. Model SDLC

Model ditunjukkan dalam gambar menyajikan tujuh fase proses sebagai berikut :

Definisi Kebutuhan Analisis Perancangan Koding

Operasional &

Installasi &

Testing Sistem

Pemeliharaan Konversi

Gambar 7.1. Model Waterfall (dalam arah mendatar)

Gambar 7.1. menyajikan proses tujuh tahap sebagai berikut :  Persyaratan

perangkat lunak untuk dikembangkan, pelanggan harus menetapkan persyaratan mereka. Di banyak kasus sistem perangkat lunak adalah bagian dari sistem yang lebih besar. Informasi tentang bagian lain dari sistem diperluas membantu kerjasama antara tim dan mengembangkan antarmuka komponen.

 Analisis. Upaya utama di sini adalah untuk menganalisis implikasi persyaratan ' untuk membentuk model perangkat lunak sistem awal.  Desain. Tahap ini melibatkan definisi rinci dari output, input dan pengolahan prosedur, termasuk struktur data dan database, perangkat lunak struktur, dll  Coding. Pada tahap ini, desain diterjemahkan ke dalam kode. Coding melibatkan kegiatan jaminan kualitas seperti inspeksi, tes unit dan integrasi tes.  Sistem tes. Sistem tes dilakukan setelah tahap pengkodean selesai. Tujuan utama pengujian adalah

lunak sebanyak mungkin sehingga mencapai tingkat yang dapat diterima dari kualitas perangkat lunak sekali koreksi telah selesai. Sistem tes dilakukan oleh pengembang perangkat lunak sebelum perangkat lunak diberikan kepada pelanggan. Dalam banyak kasus pelanggan melakukan tes perangkat lunak independen ("penerimaan tes ") untuk meyakinkan dirinya sendiri bahwa pengembang

untuk

mengungkap

sebagai

kesalahan

perangkat perangkat

 Instalasi dan

lunak yang disetujui, sistem terinstal untuk melayani sebagai firmware, yaitu, sebagai bagian dari informasi sistem yang merupakan komponen utama dari sistem diperluas. Jika sistem informasi baru untuk menggantikan sistem yang ada, sebuah software konversi proses harus dimulai untuk memastikan bahwa organisasi kegiatan tersebut berjalan tanpa gangguan selama tahap konversi.

 Reguler operasi dan pemeliharaan. Operasi software Reguler dimulai sekali instalasi dan konversi telah selesai. Sepanjang operasi normal periode, yang biasanya berlangsung selama beberapa tahun atau sampai generasi perangkat lunak baru muncul di tempat kejadian, pemeliharaan diperlukan. Pemeliharaan menggabungkan tiga jenis layanan: perbaikan – perbaikan perangkat lunak kesalahan diidentifikasi oleh pengguna selama operasi; adaptif – menggunakan fitur-fitur software yang ada untuk memenuhi persyaratan baru; dan perfektif - menambahkan fitur kecil baru untuk meningkatkan kinerja perangkat lunak.

Jumlah fase dapat bervariasi sesuai dengan karakteristik proyek. Dalam kompleks, model berskala besar, beberapa tahap dibagi, menyebabkan mereka nomor untuk tumbuh sampai delapan, sembilan atau lebih. Dalam proyek-proyek yang lebih kecil, mungkin beberapa tahap terserap, mengurangi jumlah tahapan untuk enam, lima atau bahkan empat fase. Pada akhir setiap fase, keluaran diperiksa dan dievaluasi oleh pengembang dan, dalam banyak kasus, oleh pelanggan juga. Kemungkinan hasil penelaahan dan evaluasi meliputi:  Persetujuan output fasa dan melanjutkan ke tahap berikutnya, atau  Tuntutan untuk memperbaiki, mengulang atau mengubah bagian dari fase terakhir, dalam tertentu

kasus, kembali ke fase awal yang diperlukan. Lebar garis yang menghubungkan kotak persegi panjang dalam ilustrasi mencerminkan probabilitas relatif dari hasil yang berbeda. Jadi, yang paling umum proses yang dilakukan adalah urutan linear (tidak ada atau hanya koreksi kecil). Kita harus dicatat, bagaimanapun, bahwa model tersebut menekankan langsung pengembangan kegiatan dan tidak menunjukkan saham pelanggan dalam pengembangan proses. Model air terjun klasik kasus, kembali ke fase awal yang diperlukan. Lebar garis yang menghubungkan kotak persegi panjang dalam ilustrasi mencerminkan probabilitas relatif dari hasil yang berbeda. Jadi, yang paling umum proses yang dilakukan adalah urutan linear (tidak ada atau hanya koreksi kecil). Kita harus dicatat, bagaimanapun, bahwa model tersebut menekankan langsung pengembangan kegiatan dan tidak menunjukkan saham pelanggan dalam pengembangan proses. Model air terjun klasik

7.1.2. Model Prototipe

Metodologi prototyping melakukan penggunaan :  Dikembangkan menggunakan teknologi informasi, penamaan, penggunaan aplikasi tingkat lanjut yang memperkenankan kita menghasilkan program dengan cepat dan pengembangan yang mudah terhadap prototipe software

 Dikombinasikan dengan partisipan yang aktif dalam proses pengembangan oleh pelanggan dan dan user yang mampu dalam memeriksa dan mengevaluasi prototipe.

Menentukan Kebutuhan Oleh Pelanggan

Merancang Prototipe

Menerapkan Prototipe

Mengevaluasi Prototipe

Oleh Pelanggan

Kebutuhan

Permintaan atas Perbaikan,

Terpenuhi

Perubahan, Tambahan

Testing Sistem dan Persetujuan Penerimaan

Konversi Sistem

Operasional Sistem dan Pemeliharaan

Gambar 7.2. Model Prototyping

Keuntungan prototyping :  Proses pengembangan lebih cepat

 Berperan penting dalam menghemat sumber daya pengembangan (orang /hari)  Lebih baik dalam memenuhi kebutuhan dan mengurangi resiko terhadap kegagalan proyek  Lebih mudah dan cepat dalam memahami sistem baru

Kerugian prototyping :  Berkurangnya fleksibilitas dan adaptasi terhadap perubahan dan penambahan  Berkurangnya persiapan terhadap kejadian tidak terduga dari sebuah kesalahan

7.1.3. Model Spiral

Model spiral, sebagaimana telah diubah oleh Boehm (1988, 1998), menawarkan perbaikan metodologi untuk mengawasi proyek-proyek pembangunan besar dan lebih kompleks menampilkan prospek yang lebih tinggi untuk kegagalan, khas banyak proyek dimulai di dua dekade terakhir. Ini menggabungkan model iteratif yang memperkenalkan dan menekankan analisis risiko dan partisipasi pelanggan menjadi elemen utama SDLC dan metodologi prototyping. Berdasarkan model spiral, pengembangan software dirasa sebagai sebuah proses iterasi, dimana masing-masing iterasi mengikuti kegiatan sebagai berikut :

 Perencanaan  Analisa resiko dan pemecahan ulang masalah  Aktifitas keteknikan berdasarkan tahapan proyek : perancangan, koding, testing, installasi dan

mengeluarkan produk.  Evaluasi pelanggan termasuk komentar, perubahan dan penambahan kebutuhan.

Gambar 7.3. Model Spiral (Boehm, 1988)

Model maju spiral, yang Win-Win Spiral Model (Boehm, 1998), meningkatkan model Spiral (Boehm, 1988) lebih jauh lagi. Model canggih tempat ekstra penekanan pada komunikasi dan negosiasi antara pelanggan dan pengembang. Nama model merujuk pada fakta bahwa dengan menggunakan proses, pelanggan "menang" dalam bentuk kesempatan diperbaiki untuk menerima sistem yang paling memuaskan

dalam bentuk meningkatkan kesempatan untuk tinggal di dalam anggaran dan menyelesaikan proyek oleh setuju tanggal. Hal ini dicapai dengan meningkatnya penekanan pada partisipasi pelanggan dan kegiatan rekayasa. Revisi ini dalam proses pembangunan ditunjukkan secara grafik oleh dua bagian dari spiral didedikasikan untuk partisipasi pelanggan: yang pertama berkaitan dengan evaluasi pelanggan dan yang kedua dengan pelanggan komentar dan persyaratan perubahan. Rekayasa aktivitas juga ditunjukkan dalam dua bagian dari spiral: yang pertama adalah didedikasikan untuk desain dan yang kedua untuk konstruksi.

kebutuhan,

dan

pengembang

"menang" "menang"

Dengan mengevaluasi

Gambar 7.4. Model Spiral Lanjut

o Nasabah spesifikasi kebutuhan, komentar dan tuntutan perubahan o Developer kegiatan perencanaan o Developer analisis risiko dan resolusi o Developer desain kegiatan o konstruksi Pengembang kegiatan-kegiatan yang berhubungan dengan coding, pengujian,

instalasi dan lepaskan o Nasabah evaluasi.

7.1.4. Model Obyek Oriented

dengan intensif penggunaan kembali komponen perangkat lunak. Metodologi ini ditandai dengan mudah integrasi modul perangkat lunak yang ada (disebut objek atau komponen) ke baru dikembangkan sistem perangkat lunak. Sebuah perpustakaan komponen perangkat lunak melayani ini Tujuan dengan menyediakan komponen perangkat lunak untuk digunakan kembali.

Model berorientasi

Jadi, menurut model berorientasi objek seperti yang ditunjukkan pada Gambar 7.5, proses pembangunan dimulai dengan urutan analisa berorientasi obyek dan desain. Tahap desain diikuti pembelian komponen yang cocok dari perpustakaan perangkat lunak dapat digunakan kembali, bila tersedia. "Reguler" pembangunan dilakukan sebaliknya. Salinan dari komponen software yang baru dikembangkan kemudian "ditebar" di perpustakaan perangkat lunak untuk digunakan kembali di masa depan. Diharapkan bahwa saham komponen perangkat lunak tumbuh di perpustakaan perangkat lunak dapat digunakan kembali akan memungkinkan penggunaan kembali substansial dan meningkatkan perangkat lunak, sebuah tren yang akan memungkinkan mengambil keuntungan yang lebih besar dari sumber daya sebagai berikut: 

Ekonomi - Biaya mengintegrasikan komponen perangkat lunak dapat digunakan kembali adalah jauh lebih rendah dari biaya pengembangan komponen baru.

 Peningkatan kualitas - komponen software yang digunakan adalah diduga mengandung jauh lebih sedikit cacat dari komponen software yang baru dikembangkan karena deteksi kesalahan oleh pengguna mantan.

Definisi Kebutuhan

Analisis Obyek Oriented

Rancang Obyek Oriented

Survey Penggunaan Ulang Penggunaan Komponen

terhadap komponen library

dalam Librari

Komponen tidak tersedia

Tambahkan ke library

Tidak Diterima Ketersediaan

Definisi Kebutuhan

Komponen

dalam Library

Evaluasi dari

Analisis dan Perancangan

Pelangga

Komponen yang digunakan tersedia

Koding Diterima

Testing Komponen Installasi dan Konversi

Pembangunan Sistem

Testing Sistem

Operasional dan

Pemeliharaan

Gambar 7.5. Model Obyek Oriented

 Waktu Pengembangan lebih pendek – Pengintegrasian komponen perangkat lunak bisa kembali

mengurangi skeduling tekanan. Seperti itu, keuntungan metodologi yang berorientasi, metodologi akan digunakan perangkat lunak.