Catatan Kuliah ku

efisien menghemat/mengurangi kebutuhan baik dari segi waktu maupun biaya.
efektif tepat dan sesuai dengan kebutuhan.

yang harus di perhatikan setelah itu adalah layer/lapisan selanjutnya, yaitu Process Model. pemilihan process model dalam pengembangan software juga harus diperhatikan. dengan memperhatikan biaya yang kita punya, terus lama waktu pembuatan software dll kita harus memilih process model yang tepat. model proses yang bisa kita gunakan bisa berupa waterfall, RAD, prototype dll yang bisa anda lihat lebih lengkap disini.

selanjutnya layer methode dan tools (nah yang ini belum dibahas di kampus :P )

Untuk memenuhi syarat layer yang paling bawah (Quality Focus) dibutuhkan Framework action.
Framework action adalah urutan/tahapan2 yang harus di lalui/dikerjakan agar software yang dibuat berkualitas dan sesuai dengan yang di butuhkan user.

(nah sudah tau sekarang apa itu Framework action kan ^^)
mari kita bahas apa saja tahapan2 tersebut.

Framework Action

secara garis besar, berkut adalah tahapan-tahapan dalam framework action

1. COMUNICATION : pengembang software bertemu dengan user untuk membicarakan keinginan user, fitur-fitur apa saja yang dinginkan user, dll.

2. PLANING : pada tahap ini, kita menentukan berapa jumlah tenaga kerja yang dibutuhkan, biaya, teknologi apa saja yang dibutuhkan, tools apa saja. dll. pada tahap ini kita membuat Road Map, yang bertujuan untuk menentukan list pekerjaan pada tiap tiap bulannya. misalnya waktu pengerjaan software 3 bulan, pada roadmap ditentukan pada bulan pertama minggu pertama apa saja yang dikerjakan, minggu kedua apa yang dikerjakan, minggu ketiga dst.

3. MODELLING : pada tahap ini dibagi menjadi 2 bagian,
a. Analysis requirment (menganalisa fungsi (DFD), dan Data (DFD))
b. Design, menentukan struktur menu, database dan interface.
4. CONSTRUCTION : membuat software berdasarkan design yang sudah dibuat.

untuk artikel kali ini akan membahas tahap pertama comunication/requirment terdapat bagian bagian nya lagi. jadi kita ga sembarangan aja mencari informasi kebutuhan user tadi. agar software yang kita buat pun sesuai dengan kebutuhan user.

Requirment

tahapan requirment dibagi menjadi : Inception (permulaan), Elicitation (perolehan), Negosiation, Validasi

1. Inception
pada tahap ini kita mengetahui basic problem (permasalahan dasar) dari si user. apa masalah mereka selama ini, dan kemudian mengetahui siapa yang menginginkan/membutuhkan solusi.
mengetahui solusi yang di inginkan.
pada tahap ini juga diharuskan sudah membangun sebuah komunikasi awal yang efektif antar software enginer dan user.

2. Elicitation
tahap inilah tahap yang paling lama dalam tahapan Requirment. dimana tahapan ini bertujuan untuk mengumpulkan semua data dari stake holder (yang berkepentigan dengan software yang dibuat)
misalnya : software akademik kampus, yang berkepentingan adalah mahaiswa, dosen, karyawan, dekan, masyarakat, bank (untuk pembayaran spp)
pada tahap ini juga mengetahui stak holder apa saja yang bisa menggunakan sistem (misalnya mahaiswa bisa menggunakan sistem pengisian KRS, pemilihan dosen, tapi tidak bisa menggunakan sistem pengisian nilai) *gawat juga kalau mahaiswa bisa mengisi nilai sendiri :P

kegiatan pada tahapan Elicitation yaitu
- set meeting/pertemuan antara Software enginering dengan client/user
- buat aturan dan sanksi untuk mempersiapakn meeting bagi pihak (baik S.E maupun user) yang tidak mengikuti meeting, yang sering terlambat menghadiri meeting dll.
- mempersiapkan agenda meeting
- ada fasilitator yang memoderatori meeting agar meeting benar-benar berkualitas
- ada peralatan meeting. seperti laptop, infokus, spidol, flipchart dll.

tujuan pada bagian elicitation adalah mempertemukan stake holder, mencarikan solusi, baik berupa technical (software/hardware) maupun solusi proses, mengetahui semua kebutuhan software.
apabila dari masing2 kebutuhan stake holder ada yang bertentangan masuk ke tahap selanjutnya, yaitu negosiation.

Negosiation
mencari win win solution antar stake holder untuk mencapai kesepakatan yang sama-sama menguntungkan (atau setidaknya tidak merugikan pihak manapun). setelah mencapai kesepakatan maka kita membuat laporan yang berbentuk proposal yang akan di proses pada tahap selanjutnya, tahap validasi.

Validasi
ini merupakan tahap terakhir. dimana laporan/proposal yang sudah jadi di cek dan ditanyakan kembali pada stake holder.
pada tahap validasi S.E (software engginer) melakukan review pada semua proses yang sudah dilakukan, mengetahui error yang ada, menemukan informasi yang ilang/tertinggal, mengetahui kalau ada yang tidak konsisten, mengetahui kalo ada yang tidak realistis.

jika sudah disepakati, proposal inilah panduan/pegangan si software enginering dalam membuat software, jika ada permintaan baru oleh user, maka bisa jadi biayanya pun akan bertambah lagi.

jika proposal sudah di validasi langkah selanjutnya
membuat Use Case diagram

dengan menentukan aktor dan usecase nya
aktor orang,bagian/sistem lain yang bisa berinteraksi dengan sistem
usecase aksi yang bisa dilakukan aktor dalam sistem
usecase diagram diagram yang menggambarkan aktor dan hubungan dengan usecase yang bisa dilakukan.
misalnya
aktor mahasiswa, usecasenya mengisi krs, melihat nilai, melihat jadwal dll.
aktor dosen, usecasenya melihat jadwal, mengisi nilai, melihat nilai dll.

usecase spesification penjelasan lebih rinci tetang suatu usecase.
misalnya usecase mengisi KRS
aktor : mahasiswa
kondisi awal : sudah autodebet
main scenario : 1. mahsiswa membuka tampilan login.
2. mahasiswa memasukkan username dan password
3. mahasiswa mebuka tampilan isi KRS
4. mahasiswa mengisi KRS
5. mahasiswa menyimpan KRS dst..


selesai.. :) untuk tahap selanjutnya insyaAllah di lanjutkan dah ntar.

A. WATERFALL MODEL

waterfall model/linier sequential, Pengembangan software pada model ini menggunakan beberapa tahapan yang akan lumayan menyita waktu. Dimana jika suatu tahapan belum diselesaikan, maka tahapan yang lain belum bisa dikerjakan.

Tahap yang pertama communication/requirement dimana si pengembang software akan bertemu dengan klien lalu menanyakan apa saja yang diinginkan si klien pada software yang akan dibuat. Apa saja kendala yang dihadapi selama ini sehingga software yang dibuat akan menjadi solusi yang tepat yang bisa mempermudahkan pekerjaan. Kalau semua informasi sudah didapat dan kebutuhan klien sudah diketahui, maka lanjut ketahap berikutnya.

Tahap selanjutnya Desain, yaitu membuat blue print atau bentuk rancangan software yang akan dibuat. Pada tahap ini si pembuat software akan sering kembali ke klien untuk menanyakan (konfirmasi) apa bener software yang ingin dibuat adalah seperti ini (kembali ke tahap communication). Kemudian jika ada perubahan maka software tersebut di desain lagi sampai desain tersebut memang benar-benar sudah sesuai dengan apa yang dibutuhkan oleh klien.

Tahap berikutnya jika desain sudah selesai adalah tahap Implementation. Pada tahap ini software sudah mulai dibuat berdasarkan desain (blueprint) yang telah di buat. Fitur-fitur yang diinginkan si klien sudah mulai di implementasikan dalam bentuk baris-baris koding. Nah pada tahap ini terkadang si pembuat software masih sering kembali ke klien untuk mendiskusikan hal-hal mengenai software tersebut misalnya seperti basis datanya, template/tampilan software, warna dll. Sehingga software yang dibuat bisa nyaman digunakan klien. Setelah semua desain di implementasikan dalam baris-baris koding dan membetuk sebuah software.

Setelah software sudah jadi maka tahap selanjutnya adalah verification. Jangan senang dulu kalau software sudah selesai, karena masih ada tahap verifikasi dimana user diminta untuk menguji software yang kita buat. Apakah sudah bekerja dengan baik ataukah masih ada error dan bug. Jika masih ada error maka terpaksa si pembuat software harus kebali lagi ketahap implementasi dan memperbaiki error tersebut. Ketika software sudah di uji dan tidak ada error maka software diberikan kepada klien sepenuhnya dan pembuat software pun mendapatkan bayarannya.

Walau kita telah mendapat bayaran bukan berarti kita sudah lepas pekerjaannya. Ternyata masih ada langkah selanjutnya. Yaitu Maintenance. Software yang telah dibuat tadi telah digunakan dan tidak ada error. Tetapi beberapa tahun kemudian bisa jadi adanya kebutuhan baru yang membutuhkan perombakan pada software. Misalnya penggantian basis datanya, atau penambahan fitur agar bisa di akses secara online dll. Pada initinya tahapan maintenance kita merombak software sesuai dengan keubutuhan klien, tapi bukan membuat kembali dari awal software tersebut, hanya sekedah menambah fitur-fitur, menambah panjang data pada basis datanya dll.

Kelebihan waterfall
• Dituntut bekerja secara disiplin
• Kelengkapan dokumen
• Maintnance mudah karena dokumen lengkap

Kekurangan waterafall
• Jika komunikasi tidak lancer maka konsumen susah menjelaskan apa saja yang diinginkan pada software yang ingin dibuat
• Proses lambat karena alur linier (searah)
• Konsumen tidak dapat melihat hasilnya hingga akhir tahapan
• Personil tidak bekerja optimal, karena ada waktu tunggu tahapan selesai.

B. INCREMENTAL MODEL

Proses kerjanya adalah satu set pekerjaan dikerjakan dahulu (communication – deployment) baru diberi penambahan lagi. Produk pertamanya adalah core product. Setelah itu, increment dengan menambah fitur-fitur lainnya sehingga lama-lama program menjadi bagus. Jadi prinsipnya bisa digambarkan seperti pengulangan waterfall model.

Kelebihan Incremental Model
• Personil bekerja optimal
• Cocok jika jumlah anggota tim pengembang/pembangun tidak cukup
• Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah selesai dibangun. Contohnya pemasukan data karyawan
• Mampu mengakomodasi perubahan secara fleksibel
• Mengurangi trauma karena perubahan sistem. Klien dibiasakan perlahan-lahan menggunakan produknya bagian per bagian
• Memaksimalkan pengembalian modal investasi konsumen
• Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar

Kekurangan Incremental Model
• kemungkinan tiap bagian tidak dapat diintegrasikan
• hanya cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding
• Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung
• mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment

C. THE RAD MODEL

Rapid Aplication Development (RAD) adalah sebuah metode untuk mengembangkan software yang diciptakan untuk mengurangi waktu yang dibutuhkan untuk mendesain serta mengimplementasikan sistem, sehingga dihasilkan siklus pengembangan yang sangat pendek.
Model RAD ini merupakan adaptasi dari model sekuensial linier. RAD dapat mengurangi waktu pembuatan software dengan cara mengerjakan pembuatan software dengan membagi pekerjaan berdasarkan komponen-komponen tertentu. pendekatan RAD meliputi fase – fase berikut

1. Bussiness modeling
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 modeling
aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut (analisis kebutuhan dan data)

3. Prosess modelling
objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis.

4. Aplication 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.

Keunggulan:
1. Waktu pengembangan yang lebih singkat dan
2. Biaya yang relatif lebih murah

Kelemahan:

1. Tidak cocok untuk proyek skala besar karena RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik
2. Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
3. Sistem yang tidak bisa dimodularisasi tidak cocok untuk model
4. Resiko teknis yang tinggi juga kurang cocok untuk model ini.
5. RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.

D. PROTOTYPING MODEL

Model prototype memiliki 3 tahapan yang pertama adalah listen to customer. Pada tahap ini hapir sama dengan tahap communication pada model waterfall. Hanya saja pada model prototype tidak menanyakan dengan detail apa saja yang diinginkan klien. Namun hanya obrolan ringan saja membahas tentang keingin klian pada software yang akan dibuat, kebutuhan umum dll.
Langkah selanjutnya adalah build, software yang berbentuk prototype di buat, yang mana nantinya akan di berikan ke klien lalu klien akan mengomentari apa saja yang ingin di tambahkan/dikurangi.

Langkah selanjutnya adalah customer test dimana klien dapat menyoba software yang telah di buat. Namun yang di test disini bukanlah software yang sebenarnya, hanyalah berupa prototype. Apabila ada keinginan customer untuk menambah fitur-fitur nya maka proses kembali ketahap listen to customer kemudian software tersebut di build dan dibuat prototypenya sampai software sudah benar-benar sesuai dengan yang diharapkan klien.

Kelebihan Prototype
• Umpan balik balik terhadap hasil dapat diperoleh lebih cepat.
• Mengurangi biaya pengembangan dan pemeliharaan
• Dapat bereksperimen dengan perancangan alternatif
• Dapat memperbaiki masalah penggunaan sebelum dibuat programnya
• Perancangan dapat tetap berpusat pada pengguna
• Penentuan kebutuhan lebih mudah diwujudkan
• Adanya komunikasi yang baik antara pengembang dan pelanggan
• Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan
• Pelanggan berperan aktif dalam pengembangan sistem
• Lebih menghemat waktu dalam pengembangan sistem
• Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

Kekurangan
• Informasi tentang keinginan klien tidak terlalu detil sehingga terkadang prototype yang dibuat tidak sesuai dengan keinginan klien sehingga diharuskan merombak ulang
• Terkadang konsumen tidak menyadari bahwa prototype yang diberi pengembang adalah contoh (bukan software yang sebenarnya) sehingga menyebabkan klien kecewa.
• Proses analisis dan perancangan terlalu singkat
• Mengesampingkan alternatif pemecahan masalah
• Bisanya kurang fleksible dalam mengahadapi perubahan
• Prototype yang dihasilkan tidak selamanya mudah dirubah
• Prototype terlalu cepat selesai

E. SPIRAL MODEL

Boehm (1988) mengusulkan sebuah model yang secara explisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum.

Model yang diusulkan Boehm berbentuk spiral dan merupakan kombinasi dari Prototyping Model dengan Waterfall Model. Setiap tahapan model ini selalu dilakukan Risk Analisys dan verifikasi atau testing.

Pada model ini secara garis besar dibagi menjadi 4 proses pada tiap iterasinya.
1) Determine objectives (menetukan 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 Analysis and reduction (menganalisa dan mengurangi resiko)
setiap resiko dianalisis secara detil pada sektor ini. Langkah langkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidak cocokan kebutuhan. dll
Risk Analysis yang dilakukan adalah :
• Project risk, mempengaruhi rencana proyek, contoh kekurangan sumber daya
• Technical risk, mempengaruhi tahap aktual, contoh : personil tidak terlatih di tahap tersebut
• Bussines risk, mempengaruhi keinginan perusahaan untuk membuat software, contoh : software tidak diperlukan

3) Engineering/Development and Validation (pembangunan dan pengujian)
Setelah melakukan 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) Plan next phase
Penentuan rencana-rencana untuk tahap selanjutnya. Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicaraka kembali dan rencana dibuat untuk tahap selanjutnya
Pada setiap iterasi spiral tidak mesti menggunakan model yang sama disetiap iterasinya. Bisa saja terjadi perubahan pada iterasi ke2 misalnya menggunakan model prototype sedangkan pada tahap1 (iterasi pertama) menggunakan waterfall.
Kelebihan nya.
• Merupakan kombinasi antara model prototype dan waterfall.
• Memiliki risk analysis yang berguna untuk mengetahui apa saja resiko yang bisa terjadi sehingga kita dapat memikirkan solusi untuk resiko tersebut.
• Adanya prototype memudahkan komunikasi dengan konsumen

Kekurangan Spiral Model
• Biasanya pihak pengembang dan perusahaan berada pada satu pihak yang sama
• Tahapan analisa resiko sewaktu-waktu dapat membatalkan proses rekayasa, jika pihak pengembang adalah pihak di luar perusahaan, maka timbulah masalah hukum

F. COMPONENT BASED DEVELOPMENT MODEL

Component based development model sangat mirip dengan konsep pemrograman berorienatasi objek (PBO). Dimana pada pemrograman berorientasi objek, kita ketahui ada banyak class yang dibangun dan menjadi komponen dalam suatu software. Class-class tersebut bersifat reusable, artinya bisa digunakan kembali.
Model ini bersifat iteratif atau berulang-ulang prosesnya.
Secara umum proses yang terjadi dalam model ini adalah:
1. Identifikasi class-class yang akan digunakan kembali dengan menguji class tersebut dengan data yang akan dimanipulasi dengan aplikasi/software dan algoritma yang baru

2. Class yang dibuat pada proyek sebelumnya disimpan dalam class library, sehingga bisa langsung diambil dari library yang sudah ada. Jika ternyata ada kebutuhan class baru, maka class baru dibuat dengan metode berorientasi objek.

3. Bangun software dengan class-class yang sudah ditentukan atau class baru yang dibuat, integrasikan.

Kelebihan model component based developed model
• Mampu mengurangi siklus waktu pengembangan software, 70%
• biaya produksi berkurang sampai 84% karena pembangunan komponen berkurang..
• Pembangunan software dengan menggunakan komponen yang sudah tersedia dapat menggunakan komponen COTS (Commercial off-the-shelf) – yang bisa didapatkan dengan membeli atau komponen yang sudah dibangun sebelumnya secara internal
• Menggunakan model reuse, pada komponen yang sudah mewakili kebutuhan umum
Kekurangan
• Model ini bersifat iteratif atau berulang-ulang prosesnya.
• Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.

G. THE FORMAL METHOD MODEL

Model ini jarang sekali digunakan, sedangkan sederetan aktifitas dinyatakan dalam bentuk matematik.
Kelebihan format methods model
• Cocok untuk membuat software yang mementingkan keselamatan, software yang dihasilkan biasanya bersifat defect-free.
Kelemahan formatmethods model
• Memerlukan waktu dan biaya yang banyak
• Software developer yang memiliki latar belakang ilmu pengetahuan yang dibutuhkan model ini sedikit
• Sulit digunakan bila costumer tidak mengerti secara teknis penerapan model ini

H. UNIFIED PROCESS MODEL

Unified Process (UP) atau kadang disebut sebagai Unified Software Development Process (USDP) adalah kerangka proses pengembangan yang bersifat use-case-driven, berpusat pada arsitektur perangkat lunak, interatif dan tumbuh-kembang (Alhir, 2005). Kerangka pengembangan ini termasuk baru dalam metodologi pengembangan perangkat lunak. UP dapat diaplikasikan pada berbagai skala proyek, mulai dari skala kecil sampai dengan skala besar. Daur hidup UP secara umum akan tampak seperti pada bagan di Gambar dibawah. Bagan ini biasa disebut sebagai “hump chart”. Pada bagan ini terlihat ada empat tahap pengembangan yaitu inception, elaboration, construction dan transition. Selain itu tampak pula sejumlah aktivitas (disciplines) yang harus dilakukan sepanjang pengembangan perangkat lunak, yaitu, business modeling, requirements, analysis and design, implementation, test. Tahap dan aktivitas tersebut akan dilakukan secara iteratif (Ambler, 2005).

Penjelasan singkat untuk empat tahapan dalam UP adalah sebagai berikut
• Inception. Tahapan ini merupakan tahapan paling awal dimana aktivitas penilaian terhadap sebuah proyek perangkat lunak dilakukan. Tujuannya adalah untuk mendapatkan kesepakatan dari stakeholder sehubungan dengan tujuan dan dana proyek.
• Elaboration. Tujuan dari tahap ini adalah untuk mendapatkan gambaran umum kebutuhan, persyaratan dan fungsi-fungsi utama perangkat lunak. Hal ini penting untuk mengetahui secara lebih baik resiko-resiko proyek, baik meliputi resiko arsitektur perangkat lunak, perencanaan, maupun implementasi. Pada tahap ini telah dimulai rancang bangun perangkat lunak secara iterative melalui aktivitas-aktivitas seperti business modeling, requirements, analysis dan design meskipun baru pada tahap awal.
• Construction. Tujuan dari tahapan ini adalah membangun perangkat lunak sampai dengan saat perangkat lunak tersebut siap digunakan. Titik berat tahapan ini adalah pada penentuan tingkat prioritas kebutuhan / persyaratan, melengkapi spesifikasinya, analisis lebih dalam, disain solusi yang memenuhi kebutuhan dan persyaratan, pengkodean dan pengujian perangkat lunak. Jika dimungkinkan versi awal dari perangkat lunak diuji cobakan untuk mendapatkan masukan dari pengguna.
• Transition. Tahap ini difokuskan pada bagaimana menyampaikan perangkat lunak yang sudah jadi pada pengguna. Perangkat lunak akan secara resmi diuji oleh baik oleh penguji (tester) yang kompeten maupun oleh pengguna. Beberapa aktivitas seperti pemindahan pusat data dan pelatihan pengguna dan staf pendukung harus dilakukan pada tahap ini.

Fase RUP
• Inception/insepsi
• Elaboration/elaborasi
• Construction/konstruksi
• Transition/transisi

• Inception
– Menentukan Ruang lingkup proyek
– Membuat ‘Business Case’
– Menjawab pertanyaan “apakah yang dikerjakan dapat menciptakan ‘good business sense’ sehingga proyek dapat dilanjutkan

• Elaboration
– Menganalisa berbagai persyaratan dan resiko
– Menetapkan ‘base line’
– Merencanakan fase berikutnya yaitu construction

• Construction
– Melakukan sederetan iterasi
– Pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan testing

• Transistion
– Membuat apa yang sudah dimodelkan menjadi suatu produk jadi
– Dalam fase ini dilakukan:
• Beta dan performance testing
• Membuat dokumentasi tambahan seperti; training, user guides dan sales kit
• Membuat rencana peluncuran produk ke komunitas pengguna


Kelebihan
• Dapat memanfaatkan kembali komponen-komponen yang telah tersedia/dibuat sehingga dapat meningkatkan produktifitas
• biaya pemeliharaan dapat dioptimalkan atau lebih rendah dengan pengembangan informasi tanpa standard yang jelas.
• memiliki kemampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk pengembangan aplikasi yang lainnya
• mudah untuk mengatur dan memonitor semua proses dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang amat kompleks dapat dilakukan dengan aman dan sesuai dengan harapan semua manajer proyek IT/IS