Model-model SDLC

SDLC

 Software Development Life Cycle (SDLC) meruakan siklus yang menggambarkan perangkat lunak yang dibangun.

Contoh Model SDLC adalah:

1. Waterfall

2. Linear Squential

3. Prototyping

4. RAD (Rapid Application Development)

5. Incremental

6. Win-win spiral

Salah satu contoh SDLC yang paling awal adalah Waterfall.Jadi pada model ini pengujian menjadi tahapan yang harus dilakukan setelah sebuah perangkat lunak dibangun.

1. Model  Waterfall

Ciri – ciri model waterfall seperti aliran air terjun:

Tahapan nya adalah/ Daur hidup PL:

1. Analisis kebutuhan

Maksudnya : untuk mengumpulkan kebutuhan user yang berkaitan dengan perangkat lunak yang dibangun peran analisis sebagai penjembatan antara keinginan user dengan programmer, mampu melihat konsekuensi dari kebutuhan user, kemudian kebutuhan tersebut di dokumentasikan.

2. Desain

Maksudnya : Tahapan ini untuk menerjemahkan keinginan urser menjadi desain.

3. Coding

Maksudnya : pada tahapan ini programmer menerjemahkan desain ke dalam bahasa pemrograman

4. Pengujian

Maksudnya: setelah program aplikasi selesai dibuat , maka dilakukan tahap pengujian.

5. Implementasi

Maksudnya : Perangkat lunak yang telah lolos uji di Implementasi.

6. Perawatan

Maksudnya : perangkat lunak yang telah di implementasi di harapkan bisa di pakai terus menerus.PL harus dirawat dengan memperhatikan hal-hal :

a. Mampu menangani perkembangan dat , seiring berjalannya waktu

b. Mampu menangani ancaman kerusakan oleh virus atau program penyusup lainnya.

c.Mampu menangani perbaikan jiika suatu saat terjadi error.

d. Bisa menambah fitur baru, dll.

Masalah pada waterfall :

- Partisi projek ke stages yang berbeda tidak flexible menyebabkan sulitnya untuk merespon perubahan kebutuhan pengguna. Oleh sebab itu model ini hanya cocok digunakan apabila pengguna sudah dimengerti dengan baik.

Kekurangan model air terjun adalah kesulitan mengakomodasi perubahan setelah proses sedang berlangsung.

Masalah dengan waterfall :

1. Perubahannya sulit karena sifatnya kaku

2. Karena sifatnya kaku , cocok ketika kebutuan dikumpulakan secara lengkap

3. Waterfall digunakan untuk rekayasa sistem yang benar dan proyek dikerjakan di beberapa tempat berbeda dan dibagi menjadi beberapa subbagian.

2. Prototype

Prototype adalah sebuah 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

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.

Karakteristik metode prototyping meliputi langkah-langkah :

1. Pemilahan fungsi

2. Penyusunan Sistem Informasi

3. Evaluasi

4. Penggunaan Selanjutnya

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

SISTEM YANG BERMANFAAT DARI PROTOTIPE (SYSTEMS THAT BENEFIT FROM PROTOTYPING)

Sejak kebutuhan (baca Spesifikasi Fungsi) pada umumnya berhubungan dengan pandangan user terhadap sistem, hanya dengan prototipe tampilan bagi user sudah cukup untuk memeriksa yang dibutuhkan. Menu-menu, bentuk tampilan input, tampilan keluaran, atau laporan yang dicetak, pertanyaan-pertanyaan, pesan-pesan merupakan calon yang ideal untuk prototipe.

Di lain pihak, perhitungan yang rumit, kumpulan update data dan realtime, dan sistem yang bersifat scientific sangat sulit untuk dijadikan model.

Sistem yang paling sesuai untuk prototipe adalah satu dari banyak hal yang bergantung pada sistem input/output dari user. Sistem dengan transaksi on-line dikendalikan melalui menu, layar, formulir, laporan, daftar dan perintah.

Keuntungan dari prototipe

    Menghasilkan syarat yang lebih baik dari produksi yang dihasilkan oleh metode ‘spesifikasi tulisan’.

    User dapat mempertimbangkan sedikit perubahan selama masih bentuk prototipe.

    Memberikan hasil yang lebih akurat dari pada perkiraan sebelumnya, karena fungsi yang diinginkan dan kerumitannya sudah dapat diketahui dengan baik.

    User merasa puas. Pertama, user dapat mengenal melalui komputer. Dengan melakukan prototipe (dengan analisis yang sudah ada), user belajar mengenai komputer dan aplikasi yang akan dibuatkan untuknya. Kedua, user terlibat langsung dari awal dan memotivasi semangat untuk mendukung analisis selama proyek berlangsung.

Hal yang diabaikan dalam membuat prototype :

- Efisiensi

- Kualitas

- Kemudahan di kembang

- Kcocokan dwngan lingkungan sebenarnya

3. RAD (Rapid Application Development)

Rapid Application Development adalah seperangkat strategi yang terintegrasi yang ada dalam suatu kerangka kerja meneyeluruh yang disebut Information Engineering (IE).

RAD (Rapid Application Development) adalah sistem pemrograman yang memungkinkan programmer membuat program dengan cepat. Secara umum, Sistem RAD menyediakan sejumlah alat-bantu untuk membuat antarmuka pengguna grafis (graphical user interfaces) yang biasanya membutuhkan usaha dan waktu yang lama untuk membuatnya. Dua sistem RAD yang paling populer untuk Windows adalah Visual Basic dan Delphi. RAD Mempunyai 4 Unsur Penting : Manajemen, Manusia, Metodologi, dan Peralatan. RAD adalah penggabungan beberapa metode atau teknik terstruktur. RAD menggunakan metode prototyping dan teknik terstruktur lainnya untuk menentukan kebutuhan user dan perancangan sistem informasi.

Proses pengembangan, meliputi

1. Mempelajari apakah proyek pengembangan sistem memenuhi kriteria

2. Mempelajari aktivitas bisnis perusahaan, menentukan area bisnis serta fungsi yang menjadi prioritas

3. Membuat model dari fungsi-fungsi yang menjadi prioritas

4. Memilih protype mana yang direview

5. Implementasi Sistem Informasi

Pengembangan skuensial linear , adaptasi kecepatan tinggi dari skuensial linear.

Pendekatan RAD:

1. Pemodelan bisnis

2. Pemodelan data

3. Pemodelan proses

4. Pemodelan aplikasi

Kelemahan RAD

1. Untuk proyek dengan skala besar, RAD sumber daya manusia cukup untuk membentuk sejumlah tim RAD

2. RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen

3. Akan menimbulkan masalah jika sistem tidak dibuat secara modular

4. RAD tidak cocok utnuk sistem yang mempunyai resiko tinggi

4. Incremental model

Model incremental menggabungkan elemen-elemen model sekuensial linier (diimplementasikan secara berulang) dengan filosofi prototype interatif. Model ini memakai urutan-urutan linier di dalam model yang membingungkan, seiring dengan laju waktu kalender. Setiap urutan linier menghasilkan pertambahan perangkat lunak yang kemudian dapat disampaikan kepada pengguna.

Pada saat model incremental (pertambahan) ini digunakan, pertambahan pertama sering merupakan produk inti (core product), yaitu sebuah model pertambahan yang dipergunakan, tetapi beberapa muka tambahan (beberapa diketahui dan beberapa tidak) tetap tidak disampaikan. Produk inti tersebut dipergunakan oleh pelanggan (atau mengalami pengkajian detail). Sebagai hasil dari pemakaian dan/atau evaluasi maka dikembangkan rencana bagi pertambahan selanjutnya. Rencana tersebut menekankan modifikasi produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan penyampaian fitur serta fungsional tambahan. Proses ini mengikuti penyampaian setiap pertambahan sampai bisa menghasilkan produk yang lengkap.

Model proses incremental tersebut, seperti model prototype dan pendekatan-pendekatan evolusioner yang lain, bersifat iterative. Tetapi tidak seperti model prototype, model pertambahan berfokus pada penyampaian produk operasional dalam setiap pertambahannya. Pertambahan awal ada di versi stripped down dari produk akhir, tetapi memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk evaluasi oleh pemakai.

Perkembangan pertambahan, khususnya berguna pada saat staffing, tidak bisa dilakukan dengan menggunakan implementasi lengkap oleh batasan waktu bisnis yang sudah disepakati untuk proyek tersebut. Jika produk inti diterima dengan baik, maka staf tambahan (bila dibutuhkan) bisa ditambahkan untuk mengimplementasi pertambahan selanjutnya. Sebagai tambahan, system mayor yang sedang pada masa perkembangan serta waktu penyampaiannya belum pasti, mungkin membutuhkan keberadaan perangkat keras yang baru. Bisa juga rencana tertentu dibuat untuk menghindari pemakaian perangkat lunak ini, sehingga memungkinkan fungsionalitas partial disampaikan kepada pemakai tanpa harus banyak tertunda.

Contoh Penggunaan Incremental Model

Misalnya, perangkat lunak pengolah kata yang dikembangkan dengan menggunakan paradigma penambahan akan menyampaikan manajemen file dasar, editing serta fungsi penghasilan dokumen pada penambahan pertama; kemudian editing dan kemampuan penghasilan dokumen yang lebih canggih pada pertambahan kedua; pengecekan spelling dan tata bahasa pada pertambahan ketiga; serta kemampuan pengaturan halaman tingkat lanjut pada tahap pertambahan keempat. Harus dicatat bahwa aliran proses untuk berbagai pertambahan tersebut dapat menggabungkan paradigma prototype.

Kelebihan Penggunaan Incremental Model

·   Merupakan model dengan manajemen yang sederhana

·   Pelanggan tidak perlu menunggu sampai seluruh system dikirim untuk mengambil keuntungan dari system tersebut. Inkremen yang pertama sudah memenuhi persyaratan mereka yang paling kritis, sehingga perangkat lunak dapat segera digunakan.

·   Pelanggan dapat memakai inkremen yang pertama sebagai bentuk prototype dan mendapatkan pengalaman yang dapat menginformasikan persyaratan untuk inkremen system berikutnya

·   Resiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah dapat ditemukan pada beberapa inkremen, bias saja beberapa inkremen diserahkan dengan sukses kepada pelanggan.

·   Karena layanan dengan prioritas tertinggi diserahkan pertama dan inkremen berikutnya diintegrasikan dengannya, sangatlah penting bahwa layanan system yang paling penting mengalami pengujian yang paling ketat. Ini berarti bahwa pelanggan akan memiliki kemungkinan kecil untuk memenuhi kegagalan perangkat lunak pada inkremen system yang paling kecil.

Kekurangan Penggunaan Incremental Model

·   Inkremen harus relative lebih kecil (tidak lebih dari 20.000 baris kode) dan setiap inkremen harus menyediakan sebagian dari fungsional system

·   Adanya kesulitan untuk memetakan persyaratan pelanggan pada inkremen dengan ukuran yang benar

5. Spiral model

Model ini juga cukup baru ditemukan, yaitu pada sekitar tahun 1988 oleh Barry Boehm pada artikel A Spiral Model of Software Development and Enhancement. Spiral model adalah salah satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki oleh model prototyping dan digabungkan dengan aspek sistimatis yang dikembangkan dengan model waterfall. Tahap desain umumnya digunakan pada model Waterfall, sedangkan tahap prototyping adalah suatu model dimana software dibuat prototype (incomplete model), “blue-print”-nya, atau contohnya dan ditunjukkan ke user / customer untuk mendapatkan feedback-nya. Jika prototype-nya sudah sesuai dengan keinginan user / customer, maka proses SE dilanjutkan dengan membuat produk sesungguhnya dengan menambah dan memperbaiki kekurangan dari prototype tadi.

Model ini juga mengkombinasikan top-down design dengan bottom-up design, dimana top-down design menetapkan sistem global terlebih dahulu, baru diteruskan dengan detail sistemnya, sedangkan bottom-up design berlaku sebaliknya. Top-down design biasanya diaplikasikan pada model waterfall dengan sequential-nya, sedangkan bottom-up design biasanya diaplikasikan pada model prototyping dengan feedback yang diperoleh. Dari 2 kombinasi tersebut, yaitu kombinasi antara desain dan prototyping, serta top-down dan bottom-up, yang juga diaplikasikan pada model waterfall dan prototype, maka spiral model ini dapat dikatakan sebagai model proses hasil kombinasi dari kedua model tersebut. Oleh karena itu, model ini biasanya dipakai untuk pembuatan software dengan skala besar dan kompleks.

Spiral model dibagi menjadi beberapa framework aktivitas, yang disebut dengan task regions. Kebanyakan aktivitas2 tersebut dibagi antara 3 sampai 6 aktivitas. Berikut adalah aktivitas-aktivitas yang dilakukan dalam spiral model:

Customer communication. Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.

Planning. Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.

Analysis risk. Aktivitas analisis resiko ini dijalankan untuk menganalisis baik resiko secara teknikal maupun secara manajerial. Tahap inilah yang mungkin tidak ada pada model proses yang juga menggunakan metode iterasi, tetapi hanya dilakukan pada spiral model.

Engineering. Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.

Construction & Release. Aktivitas yang dibutuhkan untuk develop software, testing, instalasi dan penyediaan user / costumer support seperti training penggunaan software serta dokumentasi seperti buku manual penggunaan software.

Customer evaluation. Aktivitas yang dibutuhkan untuk mendapatkan feedback dari user / customer berdasarkan evaluasi mereka selama representasi software pada tahap engineering maupun pada implementasi selama instalasi software pada tahap construction and release.

Satu lingkaran dari bentuk spiral pada spiral model dibagi menjadi beberapa daerah yang disebut dengan region. Region tersebut dibagi sesuai dengan jumlah aktivitas yang dilakukan dalam spiral model. Tentunya lingkup tugas untuk project yang kecil dan besar berbeda. Untuk project yang besar, setiap region berisi sejumlah tugas-tugas yang tentunya lebih banyak dan kompleks daripada untuk project yang kecil. SE berjalan dari inti spiral berjalan mengitari sirkuit per sirkuit. Sebagai contoh untuk sirkuit pertama dilakukan untuk pembangunan dari spesifikasi dari software dengan mencari kebutuhan dari customer. Untuk sirkuit pertama harus menjalani semua aktivitas yang didefinisikan. Setelah 1 sirkuit terlewati lanjut ke tugas selanjutnya misalnya membangun prototype. Tugas ini juga harus mengitari 1 sirkuit dan begitu terus selanjutnya sampai project selesai.

Tidak seperti model-model konvesional dimana setelah SE selesai, maka model tersebut juga dianggap selesai. Akan tetapi hal ini tidak berlaku untuk spiral model, dimana model ini dapat digunakan kembali sepanjang umur dari software tersebut. Pada umumnya, spiral model digunakan untuk beberapa project seperti Concept Development Project (proyek pengembangan konsep), New Product Development Project (proyek pengembangan produk baru), Product Enhancement Project (proyek peningkatan produk), dan Product Maintenance Project (proyek pemeliharaan proyek). Keempat project tersebut berjalan berurutan mengitari sirkuit dari spiral. Sebagai contoh setelah suatu konsep dikembangkan dengan melalui aktivitas2 dari spiral model, maka dilanjutkan dengan proyek selanjutnya yaitu pengembangan produk baru, peningkatan produk, sampai pemeliharaan proyek. Semuanya melalui sirkuit2 dari spiral model.

Kekurangannya ada pada masalah pemikiran user / customer dimana mereka pada umumnya tidak yakin bahwa pendekatan evolusioner ini dapat terus dalam ambang kontrol yang bagus. Dibutuhkan kombinasi kemampuan manajerial dan teknis tersendiri untuk mengontrol model ini sehingga dengan sendirinya dapat meyakinkan user / customer tersebut. Mengenai analisis resiko yang terdapat pada model ini dibutuhkan kemampuan expert tersendiri agar tahap ini dapat berjalan dengan baik. Dibutuhkan kemampuan manajemen yang tinggi untuk melakukan perkiraan resiko, karena jika ada resiko yang luput untuk dievaluasi, dikhawatirkan dapat muncul di kemudian hari yang dapat menghambat proses SE. Kesimpulannya, model ini sebetulnya cukup populer, tetapi masih kalah populer dibandingkan model2 yang lama yaitu waterfall atau prototype akibat belum banyak penggunaan model ini yang dapat meyakinkan pemikiran user / customer.

Aktifitasnya:

1. Komunikasi dengan pemakai

2. Perencanaan

3. Analisis resiko

4. Rekayasa

5. Konstruksi dan pelepasan

6. Evaluasi

Kelemahannnya

1. Sulit untuk meyakinkan pemakai

2. Memerlukan tanaga ahli

3. Belum terbukti apakh metode ini cukup efisien

Proses bentuk spiral:

1. Tiap loop mewakili 1 proses

2. Loop paling dalam focus pada kelayakan dari sistem

3. Loop selanjutnya definisi kebutuhan berkaitan dengan desain sistem , dst.

Spiral model menentukan tujuan

- Penanganan and penanggulangan resiko

- Pembangunan dan pengujian

- Planning

- Risk analisis

- Engineering

- Construction and release

- Customer evaluation

Win-win Spiral

- Perluasan spiral model

- Fase tertentu dapat diulang oleh pembuat project

- tanpa harus mengulang dari awal

Kesimpulan:

1. Pada model spiral, resiko sangat di pertimbangkan

2. Resiko adalah yang mungkin menyebabkan kesalahan

3. Pendekatan yang realistis untuk PL berskala besar.

Ruang Lingkup Software Engineering

Software requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak.

Software design mencakup proses penentuan arsitektur, komponen, antarmuka, dan karakteristik lain dari perangkat lunak.

Software construction berhubungan dengan detil pengembangan perangkat lunak, termasuk algoritma, pengkodean, pengujian, dan pencarian kesalahan.

Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.

Software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan.

Software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu.

Software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak.

Software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL.

Software engineering process berhubungan dengan definisi, implementasi, pengukuran, pengelolaan, perubahan dan perbaikan proses RPL.

Software quality menitikberatkan pada kualitas dan daur hidup perangkat lunak.

Software Engineering

Rekayasa perangkat lunak (RPL, atau dalam bahasa Inggris: Software Engineering atau SE) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan sebagainya

Rekayasa perangkat lunak juga bisa diartikan sebagai ilmu yang mempelajari tehnik pembuatan software yang baik dengan pendekatan tehnik (Engineering approach)

MODEL SOFTWARE ENGINEERING

Krisis software tidak dapat hilang dalam satu satu malam, di mana tidak ada suatu pendekatan yang baik dalam mengatasi krisis software, namun gabungan dari metode untuk semua fase dalam pengembangan siftware seperti peralatan yang lebih baik untuk mengautomatisasi metode-metode ini, tehnik yang lebih baik untuk mengontrol kualitas, dan filosofi untuk koordinasi kontrol, serta manajemen dipelajari dalam suatu disiplin ilmu yang kita sebut software engineering.

Definisi :

Menurut Fritz Badar, software engineering adalah disiplin ilmu yang menerapkan prinsip-prinsip engineering agar mendapatkan software yang ekonomis yang dapat dipercaya dan bekerja lebih efisien pada mesin yang sebenarnya.

Software engineering terdiri dari 3 elemen kunci, yaitu :

            1. Metode,

            2. Peralatan (tools),

            3. Prosedur,

yang memungkinkan manajer mengontrol proses pengembangan software dan memberikan praktisi dasar yang baik untuk pembentukan software berkualitas tinggi.

            1. Metode Software Enginnering

Metode software engineering memberikan tehnik-tehnik bagaimana membentuk software. Metode ini terdiri dari serangkaian tugas :◊ Perencanaan & estimasi proyek

·         Analisis kebutuhan sistem dan software

·         Desain struktur data

·         Arsitektur program dan prosedur algoritma

·         Coding

·         Testing dan pemeliharaan

2. Peralatan Software Engineering

Peralatan software engineering memberikan dukungan atau semiautomasi untuk metode. Contohnya :

·         CASE (Case Aided Software Engineering), yaitu suatu software yang menggabungkan software, hardware, dan database software engineering untuk menghasilkan suatu lingkungan software engineering.

·         Database Software Engineering, adalah sebuah struktur data yang berisi informasi penting tentang analisis, desain, kode dan testing.

·         Analogi dengan CASE pada hardware adalah : CAD, CAM, CAE

3. Prosedur Software Engineering

Terdiri dari :

·          urut-urutan di mana metode tersebut diterapkan

·          dokumen

·          laporan-laporan

·          formulir-formulir yang diperlukan

·          mengontrol kualitas software

·          mengkoordinasi perubahan yang terjadi pada software

Dalam penguasaan atas model software engineering atau software engineering paradigm, dikenal ada 3 metode yang luas dipergunakan, yaitu :

1. Classic Life Cycle Pradigm - Model Water Fall - Model Siklus Hidup Klasik  

Keterangan :

            A. System Engineering and Analysis

Karena software merupakan bagian terbesar dari sistem, maka pekerjaan dimulai dengan cara menerapkan kebutuhan semua elemen sistem dan mengalokasikan sebagian kebutuhan tersebut ke software. Pandangan terhadap sistem adalah penting, terutama pada saat software harus berhubungan dengan elemen lain, seperti :

·         Hardware

·         Software

·         Database

            B. Analisis kebutuhan software

Suatu proses pengumpulan kebutuhan software untuk mengerti sifat-sifat program yang dibentuk software engineering, atau analis harus mengerti fungsi software yang diinginkan, performance dan interface terhadap elemen lainnya. Hasil dari analisis ini didokumentasikan dan direview / dibahas / ditinjau bersama-sama customer.

            C. Design

Desain software sesungguhnya adalah proses multi step (proses yang terdiri dari banyak langkah) yang memfokuskan pada 3 atribut program yang berbeda, yaitu :

·         Struktur data

·         Arsitektur software

·         Rincian prosedur

Proses desain menterjemahkan kebutuhan ke dalam representasi software yang dapat diukur kualitasnya sebelum mulai coding. Hasil dari desain ini didokumentasikan dan menjadi bagian dari konfigurasi software.

            D. Coding

Desain harus diterjemahkan ke dalam bentuk yang dapat dibaca oleh mesin

            E. Testing

Segera sesudah objek program dihasilkan, pengetesan program dimulai. Proses testing difokuskan pada logika internal software. Jaminan bahwa semua pernyataan atau statements sudah dites dan lingkungan external menjamin bahwa definisi input akan menghasilkan output yang diinginkan.

           

            F. Maintenance

Software yang sudah dikirim ke customer data berubah karena

·         Software mengalami error

·         Software harus diadaptasi untuk menyesuaikan dengan lingkungan external, misalnya adanya sistem operasi baru atau peripheral baru.

·         Software yang lebih disempurnakan karena adanya permintaan dari customer.

Masalah yang dihadapi dari model siklus hidup klasik adalah :

·         Proyek yang sebenarnya jarang mengikuti aliran sequential yang ditawarkan model ini. Iterasi (Pengulangan) selalu terjadi dan menimbulkan masalah pda aplikasi yang dibentuk oleh model ini.

·         Seringkali pada awalnya customer sulit menentukan semua kebutuhan secara explisit (jelas).

·         Customer harus sabar karena versi program yang jalan tidak akan tersedia sampai proyek software selesai dalam waktu yang lama.

2. Prototype Paradigm

Keterangan :

Seringkali seorang customer sulit menentukan input yang lebih terinci, proses yang diinginkan dan output yang diharapkan. Tentu saja ini menyebabkan developer tidak yakin dengan efisiensi alogoritma yang dibuatnya, sulit menyesuaikan sistem operasi, serta interaksi manusia dan mesin yang harus diambil. Dalam hal seperti ini, pendekatan prototype untuk software engineering merupakan langkah yang terbaik.

(”Prototype sebenarnya adalah suatu proses yang memungkinkan developer membuat sebuah model software.”)

Ada 2 bentuk dari model ini, yaitu :

            A. Paper Prototype

Menggambarkan interaksi manusia dan mesin dalam sebuah bentuk yang memungkinkan user mengerti bagaimana interaksi itu terjadi.

            B. Working Prototype

Adalah prototype yang mengimplementasikan beberapa bagian dari fungsi software yang diinginkan seperti pada pendekatan pengembangan software. Model ini dimulai dengan :

·         Pengumpulan kebutuhan developer dan customer

·         Menentukan semua tujuan software

·         Mengidentifikasi kebutuhan-kebutuhan yang diketahui

Hasil dari pengumpulan kebutuhan diteruskan pada Quick Design. Quick Design ini memfokuskan pada representasi aspek-aspek software yang dapat dilihat oleh user, misalnya format input dan output, selanjutanya dari desain cepat diteruskan pada pembentukan prototype (langkah ke 3). Prototype ini dievaluasi oleh customer / user dan digunakan untuk memperbaiki kebutuhan-kebutuhan software. Proses iterasi terjadi agar prototype yang dihasilkan memenuhi kebutuhan customer, juga pada saat yang sama developer mengerti lebih baik tentang apa yang harus dikerjakan.

Masalah yang dihadapi oleh prototyping paradigm ini adalah :

·         Customer hanya melihat pada apa yang dihasilkan oleh software, tidak peduli pada hal-hal yang berhubungan dengan kualitas software dan pemeliharaan jangka panjang.

·         Developer seringkali menyetujui apa yang diterangkan oleh customer agar prototype dapat dihasilkan dengan cepat. Akibatnya timbul pemilihan sistem operasi / bahasa pemrograman yang tidak tepat.

3. Fourth Generation Tehnique Paradigm - Model tehnik generasi ke 4 / 4GT

Istilah Fourth Generation Technique (4GT) meliputi seperangkat peralatan software yang memungkinkan seorang developer software menerapkan beberapa karakteristik software pada tingkat yang tinggi, yang kemudian menghasilkan source code dan object code secara otomatis sesuai dengan spesifikasi yang ditentukan developer. Saat ini peralatan / tools 4GT adalah bahasa non prosedur untuk :

·         DataBase Query

·         Pembentukan laporan ( Report Generation )

·         Manipulasi data

·         Definisi dan interaksi layar (screen)

·         Pembentukan object dan source ( Object and source generation )

·         Kemampuan grafik yang tinggi, dan

·         Kemampuan spreadsheet

Keterangan gambar :

·         Model 4GT untuk software engineering dimulai dengan rangkaian pengumpulan kebutuhan. Idealnya, seorang customer menjelaskan kebutuhan-kebutuhan yang selanjutnay diterjemahkan ke dalam prototype. Tetapi ini tidak dapat dilakukan karena customer tidak yakin dengan apa yang diperlukan, tidak jelas dalam menetapkan fakta-fakta yang diketahui dan tidak dapat menentukan informasi yang diinginkan oleh peralatan 4GT.

·         Untuk aplikasi kecil adalah mungkin bergerak langsung dari langkah pengumpulan kebutuhan ke implementasi yang menggunakan bahasa non prosedur fourth generation (generasi ke 4). Tetapi untuk proyek besar, pengembangan strategi desain sistem tetap diperlukan, sekalipun kita menggunakan 4GL. Penggunaan 4GT tanpa desain untuk proyek besar akan menyebabkan masalah yang sama yang ditemui dalam pengembangan software yang menggunakan pendekatan konvensional.

·         Implementasi yang menggunakan 4GL memungkinkan developer software menjelaskan hasil yang diinginkan yang kemudian diterjemahkan ke dalam bentuk source code dan object code secara otomatis.

·      Langkah yang terakhir adalah mengubah implementasi 4GT ke dalam sebuah product. Selanjutnya developer harus melakukan pengetesan, pengembangan dokumentasi dan pelaksanaan semua aktifitas lainnya yang diwujudkan dalam model software engineering.

Masalah yang dihadapi dalam model 4GT adalah adanya sebagian orang yang beranggapan bahwa :

            A. peralatan 4GT tidak semudah penggunaan bahasa pemrograman,

            B. source code yang dihasilkan oleh peralatan ini tidak efisien,

C. pemeliharaan sistem software besar yang dikembangkan dengan 4GT masih

    merupakan tanda tanya.

                        4. Model Kombinasi - Combining Paradigm

Keterangan :

Model ini menggabungkan keuntungan-keuntungan dari beberapa model sebelumnya. Seperti pada model sebelumnya, model kombinasi ini dimulai dengan langkah pengumpulan kebutuhan.

Pendekatan yang dapat diambil adalah pendekatan siklus hidup klasik (Analisis sistem dan analisis kebutuhan software) atau dapat juga menggunakan pendekatan seperti prototyping jika definisi masalahnya tidak terlalu formal.

Jika kebutuhan untuk fungsi dan performance software diketahui dan dimengerti, pendekatan yang dianjurkan adalah model siklus hidup klasik. Sebaliknya, jika aplikasi software menuntut interaksi yang sering antara manusia dan mesin, membutuhkan algoritma yang tidak dapat dibuktikan, atau membutuhkan tehnik output / kontrol, maka pendekatan yang dianjurkan adalah model prototyping.

Pada kasus seperti ini, 4GL dapat digunakan untuk mendapat prototype dengan cepat. Segera sesudah prototype dievaluasi dan disempurnakan, langkah desain dan implementasi dalam siklus hidup klasik diterapkan.