SOFTWARE PROCESS MODEL

Linear SequentialModel/ Waterfall Model

Model ini adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Berikut ini ada dua gambaran dari waterfall model. Sekalipun keduanya menggunakan nama-nama fase yang berbeda, namun sama dalam intinya. Fase-fase dalam Waterfall Model menurut referensi Pressman:

Fase-fase dalam Waterfall Model menurut referensi Sommerville :

1. Requirements analysis and definition: Mengumpulkan kebutuhan secara lengkap kemudian kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap. 2. System and software design: Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap. 3. Implementation and unit testing: desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit. 4. Integration and system testing: Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing). 5. Operation and maintenance: mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya. Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya. Masalah dengan waterfall : 1. Perubahan sulit dilakukan karena sifatnya yang kaku. 2. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi. 3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.

V-Model
Model yang sama dengan Waterfall dengan memberikan gambaran hubungan antara setiap langkah dengan tingkat pemenuhan kebutuhan. Semakin proses menuju ke akhir proses, kebutuhan semakin dipenuhi. Kebutuhan diwakili dengan proses pengujian

RAD (Rapid Application Development)

RAD adalah model proses pembangunan PL yang incremental. RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini. Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90 hari.

Kelemahan dalam model ini: 1. 2. 3. 4. Tidak cocok untuk proyek skala besar Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini Resiko teknis yang tinggi juga kurang cocok untuk model ini

Fase-fase di atas menggambarkan proses dalam model RAD. Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir bersamaan dalam batasan waktu yang sudah ditentukan. 1. Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi? kebutuhan dari system 2. Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut analisis kebutuhan dan data

3. Process Modelling : objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis. 4. Application Generation: RAD menggunakan component program yang sudah ada atau membuat component yang bisa digunakan lagi, selama diperlukan. 5. Testing and Turnover: karena menggunakan component yang sudah ada, maka kebanyakan component sudah melalui uji atau testing. Namun component baru dan interface harus tetap diuji.

Prototyping Model
Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software. Proses pada model prototyping yang digambarkan pada gambar 1, bisa dijelaskan sebagai berikut: Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan Perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype. Evaluasi prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

Prototype adalah cara yang dapat diterapkan dalam model apapun. Menjawab situasi sulit ketika klien tidak dapat menjelaskan keinginan/kebutuhannya, pengembang ragu terhadap algoritma/teknik yang digunakan, adaptasi dengan SO baru. Model ini menolong pengembang dan klien untuk memahami lebih baik kebutuhan sistem, tapi problem yang mungkin muncul:

1. 2.

Klien menghendaki prototype (yg dibangun secara cepat) menjadi produk yang berfungsi dan lengkap. Pengembang menganggap prototype cukup untuk dikembangkan jadi produk padahal banyak ketidaksesuaian yg dikompromikan. Misal. SO kurang tepat, bahasa pemrograman tidak mendukung sepenuhnya.

Model ini dapat berhasil jika ada kesepakatan dengan klien bahwa protopying digunakan untuk memastikan kebutuhan secara lengkap. Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari prototype , membantu mendapatkan kebutuhan detil lebih baik namun demikian prototype juga menimbulkan masalah: 1. Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya. 2. Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana. Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

Prototyping merupakan salah satu metode pengembangan perangat lunak yang banyak digunakan. Dengan metode prototyping ini pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem.Prototyping dapat diartikan sebagai proses yang digunakan untuk membantu pengembang perangkat lunak dalam membentuk model dari perangkat lunak yang harus dibuat.

Model tersebut dapat berupa tiga bentuk: 1. Bentuk prototype di atas kertas/model berbasis komputer yang menggambarkan interaksi manusia yang mungkin terjadi. 2. Working prototype, yang mengimplementasikan sebagian dari fungsi yang ditawarkan perangkat lunak. 3. Program jadi yang melakukan sebagian atau seluruh fungsi yang akan dilakukan, tapi masih ada fitur yang masih dikembangkan. Sering terjadi seorang pelanggan hanya mendefinisikan secara umum apa yang dikehendakinya tanpa menyebutkan secara detal output apa saja yang dibutuhkan, pemrosesan dan data-data apa saja yang dibutuhkan. Sebaliknya disisi pengembang kurang memperhatikan efesiensi algoritma, kemampuan sistem operasi dan interface yang menghubungkan manusia dan komputer. Untuk mengatasi ketidakserasian antara pelanggan dan pengembang , maka harus dibutuhakan kerjasama yanga baik diantara keduanya sehingga pengembang akan mengetahui dengan benar apa yang diinginkan pelanggan dengan tidak mengesampingkan segi-segi teknis dan pelanggan akan mengetahui proses-proses dalm menyelasaikan sistem yang diinginkan. Dengan demikian akan menghasilkan sistem sesuai dengan jadwal waktu penyelesaian yang telah ditentukan. Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturanaturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan. Prototype akan dihilangkan sebagian atau seluruhnya dan perangkat lunak aktual aktual direkayasa dengan kualitas dan implementasi yang sudah ditentukan. Prototyping merupakan Javascript Framework yang dibuat untuk lebih memudahkan proses dalam membangun aplikasi berbasis web. Metode protyping sebagai suatu paradigma baru dalam pengembangan sistem informasi, tidak hanya sekedar suatu evolusi dari metode pengembangan sistem informasi yang sudah ada, tetapi sekaligus merupakan revolusi dalam pengembangan sistem informasi manajemen. Karakteristik metode prototyping meliputi langkah-langkah : 1. Pemilahan fungsi 2. Penyusunan Sistem Informasi 3. Evaluasi 4. Penggunaan Selanjutnya Ada 2 Jenis Prototype : Jenis I : Suatu Sistem yang akan menjadi sistem operasional Jenis II : Suatu model yang dapat dibuang yang berfungsi sebagai cetak biru bagi sistem operasional.

Jenis-jenis prototyping meliputi: 1. Feasibility prototyping 2. Requirement prototyping 3. Desain Prototyping 4. Implementation prototyping

Teknik-teknik prototyping meliputi: 1. Perancangan Model 2. Perancangan Dialog 3. Simulasi Tahapan-tahapan Prototyping Tahapan-tahapan dalam Prototyping adalah sebagai berikut: 1. Pengumpulan kebutuhan Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat. 2. Membangun prototyping Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output). 3. Evaluasi protoptyping Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangi langkah 1, 2 , dan 3. 4. Mengkodekan sistem

Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai. 5. Menguji sistem Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain. 6. Evaluasi Sistem. Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Juka ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5. 7. Menggunakan sistem Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan . Keunggulan dan Kelemahan Prototyping Keunggulan prototyping adalah: 1. Adanya komunikasi yang baik antara pengembang dan pelanggan 2. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan 3. Pelanggan berperan aktif dalam pengembangan sistem 4. Lebih menghemat waktu dalam pengembangan sistem 5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya. Kelemahan prototyping adalah : 1. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangja waktu lama. 2. penegmbang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan algoritma dan bahasa

pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan cetak biru sistem . 3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik Prototyping bekerja dengan baik pada penerapan-penerapan yang berciri sebagai berikut:

Resiko tinggi Yaitu untuk maslaha-masalah yang tidak terstruktur dengan baik, ada perubahan yang besar dari waktu ke waktu, dan adanya persyaratan data yang tidak menentu. Interaksi pemakai penting. Sistem harus menyediakan dialog on-line antara pelanggan dan komputer. Perlunya penyelesaian yang cepat. Perilaku pemakai yang sulit ditebak. Sitem yang inovatif. Sistem tersebut membutuhkan cara penyelesaian masalah dan penggunaan perangkat keras yang mutakhir. Perkiraan tahap penggunaan sistem yang pendek.

Evolutionary Software Process Models

Bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir dari proses . Dua model dalam evolutionary software process model adalah:

1. Incremental Model (Original: Mills)

1. Kombinasikan element-element dari waterfall dengan sifat iterasi/perulangan. 2. Element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna. 3. Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan. 4. Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup. 5. Mampu mengakomodasi perubahan secara fleksibel. 6. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.

Masalah dengan Incremental model: 1. Cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding) 2. Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment 2. Spiral Model (Original: Boehm)

Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor : 1. Objective settings (menentukan tujuan): menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.

2. Risk assessment and reduction (Penanganan dan pengurangan resiko) : setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan. 3. Development and Validation (Pembangunan dan pengujian): Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok. 4. Planning: Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya. Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian sector berikut pada model variasi spiral di bawah ini:

1. Customer communication: membangun komunikasi yang baik dengan pengguna/customer. 2. Planning: mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek. 3. Risk analysis: identifikasi resiko managemen dan teknis Engineering: pembangunan contoh-contoh aplikasi, misalnya prototype 4. Construction and release : pembangunan, test, install dan support. 5. Customer evaluation: mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi.

Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.

Component Assembly Model

Menggabungkan berbagai karakteristik dari spiral model. Pembuatan aplikasi dengan pendekatan model ini dibangun dari komponen-komponen perangkat lunak yang sudah dipaketkan sebelumnya dengan cakupan aktivitas sebagai berikut: 1. Mengidentifikasi calon-calon komponen (kelas objek) 2. Melihat komponen-komponen dalam pustaka 3. Mengekstrak komponen jika ada 4. Membangun komponen jika tidak ada 5. Menyimpan komponen baru pada pustaka 6. Mengkontruksi iterasi ke-n dari sistem

Object Technologies -- kerangka kerja teknis untuk sebuat model proses komponen dasar untuk rekayasa software Model komponen rakitan banyak tidak bekerja dari sifat dari model spiral adalah evolusi yang alami meminta sebuah pedekatan secara berulang untuk membuat suatu software memimpin penggunaan kemabali software Keuntungan: permintaan software digunakan kembali --> biaya berkurang --> pengurangan waktu daur pembuatan The Concurrent Development Model

Model concurrent development disebut rekayasa terjadi pada waktu yang sama--> Menyediakan sebuah bagian akurat dari bagian yang ada dari sebuah proyek o Fokus pada kegiatan rekayasa waktu yang sama dalam proses rekayasa software Seperti prototipe,model analisa,spesifikasi kebutuhan dan rancangan. Membuat skema sebagai rangkaian dari kegiatan teknis yang umum, tugas, dan bagian yang terkait. Dijelaskan sebagai rangkaian dari event yang transisi dari bagian ke bagian untuk Setiap suatu kegiatan rekayasa software

Dua cara meningkatkan konkruen : o aktivitas sistem dan komponen terjadi simultan dan bisa dimodelkan menggunakan pendekatan orientasi bagian sebuah tipe aplikasi client/server yang diimplementasikan dengan banyak komponen, setiapnya bisa dirancang dan dianggap konkruen.

Aplikasi: semua tipe dari pembuatan software Model pembangunan yang bersamaan, kadang-kadang disebut concurrent engineering, telah digambarkan dalam cara berikut oleh Davis dan Sitaram [DAV94]: Manajer proyek yang melacak status proyek dalam bentuk fase utama [dari kehidupan klasik siklus] tidak tahu tentang status proyek-proyek mereka. Ini adalah contoh perusahaan berusaha untuk melacak sangat kompleks kegiatan set terlalu sederhana menggunakan model. Perhatikan bahwa walaupun. . . [a besar] Proyek ini dalam tahap pengkodean, ada personil pada proyek yang terlibat dalam kegiatan biasanya dikaitkan dengan banyak tahapan pembangunan secara simultan. Misalnya . . . personil persyaratan menulis, merancang, coding, pengujian, dan pengujian integrasi [semua pada saat yang sama]. Model proses rekayasa perangkat lunak oleh Humphrey dan Kellner [[HUM89], [KEL89]] telah menunjukkan concurrency yang ada untuk kegiatankegiatan yang terjadi selama setiap satu fase. Kellner yang lebih baru kerja [KEL91] menggunakan statecharts [notasi yang mewakili negara bagian dari suatu proses] untuk mewakili hubungan bersamaan ada kegiatan antara dikaitkan dengan peristiwa tertentu (misalnya, sebuah persyaratan berubah selama perkembangan akhir), tetapi gagal untuk menangkap kekayaan concurrency yang ada di semua pengembangan perangkat lunak dan kegiatan pengelolaan dalam proyek. Model proses yang konkuren dapat digambarkan secara skematik sebagai rangkaian besar kegiatan teknis, tugas, dan negara-negara terkait. Sebagai contoh, rekayasa kegiatan yang ditetapkan untuk model spiral dapat dilakukan dengan menerapkan tugas berikut: prototyping dan / atau analisis pemodelan, persyaratan spesifikasi, Dan design.9

Kegiatan-analisis-mungkin dalam salah satu dari states10 dicatat pada waktu tertentu. Demikian pula, kegiatan lainnya (misalnya, desain atau komunikasi pelanggan) dapat dinyatakan dalam cara yang analog. Semua kegiatan ada secara bersamaan tetapi berada di negara yang berbeda. Sebagai contoh, di awal proyek komunikasi pelanggan Aktivitas (tidak ditampilkan pada gambar) telah menyelesaikan iterasi pertama dan ada di perubahan menunggu negara. Kegiatan analisis (yang ada dalam negara tidak ada sementara komunikasi pelanggan awal selesai) sekarang membuat sebuah transisi ke dalam pembangunan di bawah negara. Namun, jika pelanggan menunjukkan bahwa perubahan dalam persyaratan harus dilakukan, kegiatan analisis bergerak dari pembangunan di bawah negara ke negara perubahan menunggu. Model proses yang concurrent mendefinisikan sebuah rangkaian peristiwa yang akan memicu transisi dari negara bagian untuk masing-masing kegiatan rekayasa perangkat lunak. Sebagai contoh, selama tahap-tahap awal desain, sebuah inkonsistensi dalam model analisis terungkap. Ini menghasilkan model analisis peristiwa koreksi yang akan memicu aktivitas analisis dari negara yang dilakukan ke negara perubahan menunggu. Model proses yang konkuren sering digunakan sebagai paradigma untuk pengembangan dari client/server11 aplikasi . Seorang klien / server yang terdiri sistem dari serangkaian komponen fungsional. Ketika diterapkan ke klien / server, model proses concurrent mendefinisikan kegiatan dalam dua dimensi [SHE94]: sebuah sistem dimensi dan dimensi komponen. Masalah tingkat sistem ditangani dengan menggunakan tiga kegiatan: desain, perakitan, dan penggunaan. Dimensi komponen disapa dengan dua kegiatan: desain dan realisasi. Concurrency dicapai dalam dua cara: (1) sistem dan kegiatan komponen terjadi secara simultan dan dapat dimodelkan menggunakan pendekatan yang berorientasi negara yang telah dijelaskan sebelumnya; (2) khas klien / server Aplikasi ini diimplementasikan dengan banyak komponen, yang masingmasing dapat dirancang dan menyadari secara bersamaan. Pada kenyataannya, proses konkuren model ini berlaku untuk semua jenis pengembangan perangkat lunak dan memberikan gambaran yang akurat tentang keadaan sekarang dari suatu proyek. Alih-alih membatasi kegiatan rekayasa perangkat lunak ke urutan peristiwa, itu mendefinisikan sebuah jaringan kegiatan. Masing-masing kegiatan pada jaringan ada bersamaan dengan kegiatan lain. Acara yang dihasilkan dalam suatu kegiatan atau di tempat lain dalam kegiatan memicu jaringan di antara negara-negara transisi dari suatu kegiatan.

Formal Model
Menggunakan notasi Matematika yang teliti untuk menentukan desain dan menguji sistem berbasis komputer. formal methode dapat diterapkan di berbagai aspek atau properti dari sistem yang kompleks. formal methode digunakan untuk spesifikasi detail,design dan verifikasi pada bagian-bagian sistem yang bersifat critical (misal avionics atau aerospace systems), serta pada safety critical system (contoh hearts monitor, ATM,banking)

Model metode formal mencakup sekumpulan aktivitas yang membawa kepada spesifikasi matematis perangkat lunak komputer. Metode formal memungkinkan perekayasa perangkat lunak untuk mengkhususkan, mengembangkan, dan memverifikasi sistem berbasis komputer dengan menggunakan notasi matematis yang tepat. Variasi di dalam pendekatan ini, disebut juga clean-room Rekayasa perangkat lunak, sedang diaplikasikan oleh banyak organisasi pengembang perangkat lunak. Meskipun belum menjadi pendekatan utama, model metode formal sudah menawarkan janji perangkat lunak yang bebas cacat/kesalahan; tetapi perhatian tentang kemampuan aplikasinya di dalam lingkungan bisnis sudah mulai disuarakan : 1. Pengembangan model formal banyak memakan waktu dan mahal 2. Karena beberapa pengembang perangkat lunak perlu mempunyai latar belakang yang diperlukan untuk mengaplikasikan metode formal, maka diperlukan pelatihan yang ekstensif. 3. Sulit untuk menggunakan model-model sebagai sebuah mekanisme komunikasi bagi pemakai yang secara teknik belum canggih. Model metode formal mencakup sekumpulan aktivitas yang membawa kepada spesifikasi matematis perangkat lunak komputer. Metode formal memungkinkan perekayasa perangkat lunak untuk mengkhususkan, mengembangkan, dan memverifikasi sistem berbasis komputer dengan menggunakan notasi matematis yang tepat. Variasi di dalam pendekatan ini, disebut juga clean-room rekayasa perangkat lunak, sedang diaplikasikan oleh banyak organisasi pengembang perangkat lunak.

Fourth Generation Techniques (4GT)

Menggunakan perangkat bantu yang akan membuat kode sumber secara otomatis berdasarkan spesifikasi dari pengembang perangkat lunak. Hanya digunakan untuk mengembangkan perangkat lunak yang menggunakan bentuk bahasa khusus atau notasi grafik yang diselesaikan dengan syarat yang dimengerti pemakai. Cakupan aktivitas 4GT: 1. Pengumpulan kebutuhan. 2. Translasi kebutuhan menjadi prototype operasional, atau langsung melakukan implementasi secara langsung dengan menggunakan bahasa generasi keempat (4GL) jika aplikasi relatif kecil. 3. Untuk aplikasi yang cukup besar, dibutuhkan strategi perancangan sistem walaupun 4GL akan digunakan. 4. Pengujian. 5. Membuat dokumentasi. 6. Melaksanakan seluruh aktivitas untuk mengintegrasikan solusi-solusi yang membutuhkan paradigma rekayasa perangkat lunak lainnya. Salah satu keuntungan penggunaan model 4GT adalah pengurangan waktu dan peningkatan produktivitas secara besar, sementara kekurangannya terletak pada kesulitan penggunaan perangkat bantu dibandingkan dengan bahasa pemrograman, dan juga kode sumber yang dihasilkannya tidak efisien.

Bentuk teknik generasi keempat (4GT) mencakup serangkaian bantu perangkat lunak yang luas yang secara umum memiliki satu hal, masing-masing memungkinkan perekayasa perangkat lunak untuk mengkhususkan beberapa karakteristik perangkat lunak pada suatu tingkat yang tinggi. Paradigma 4GT untuk rekayasa perangkat lunak berfokus kemampuan spesifikasi perangkat lunak dengan menggunakan bentuk bahasa yang dikhususkan atau sebuah notasi grafik yang menggambarkan masalah yang akan dipecahkan ke dalam bentuk yang dapat dipahami oleh pelanggan. Istilah Fourth-Generation (generasi keempat) mengarah ke perangkat lunak yang umum yaitu, tiap pengembang perangkat lunak menentukan beberapa karakteristik perangkat lunak pada level yang tinggi. Tool akan otomatis menghasilkan sumber berdasarkan spesifikasi tersebut. Teknik 4GT ini menekankan pada kemampuan menentukan perangkat lunak pada level mesin dengan bahasa yang lebih alami atau notasi yang lebih memiliki arti. Metode 4GT ini dimulai dari pengumpulan kebutuhan. Idealnya pelanggan akan menjelaskan kebutuhannya, yang akan langsung ditranslasikan ke prototipe operasional. Tapi, prototipe ini tidak bekerja. Pelanggan mungkin tidak pasti akan hal yang dibutuhkannya atau tidak dapat menentukan informasi yang dapat ditangani tool 4GT. Tool 4GT yang sudah ada tidak cukup canggih untuk mengakomodasikan bahasa alami. Pada saat ini, dialog antara pelanggan dan pengembang yang ada pada metode sebelumnya tetap menjadi bagian penting dari teknik 4GT. Implementasi menggunakan 4GL (Fourth-Generation Language) dapat dihasilkan dari program kode yang sesuai. Tetapi struktur data dengan informasi lainnya harus ada dan dapat diakses oleh 4GL. Untuk aplikasi kecil, adalah mungkin untuk langsung berpindah dari pengumpulan kebutuhan ke implementasi menggunakan bahasa non-prosedural (FourthGeneration Language - 4GL).