CBOP - PENDEKATAN ORIENTASI OBJEK UNTUK PEMBANGUNAN PERISIAN

Soalan 1(a)

Ringkasan Laporan Susan Lily
“HOW TO AVOID USE-CASE PITFALLS”


1.0 Pengenalan
Kes Guna ialah merujuk kepada kes guna suatu sistem untuk hasilan output bagi pengguna-pengguna tertentu dan kepentingannya boleh melihat kepada kejadian-kejadian utama.
Contoh: Sistem Kedai Vedio - Pelanggan = sewa Video dan Pekedai = Beli Video baru
Setiap kejadian pula perlu ada set kes guna. Contoh: Jika pelanggan hendak sewa video, kes guna yang diperlukan oleh pekedai kepada pelanggan baru dengan pelanggan lama adalah berbeza.
Kes guna yang diperlukan oleh pekedai ini dinamakan ' Senario' manakala Setiap Kes Guna mempunyai pelbagai senario lain atau variasi daripada senario utama.
Penulisan ““kes guna” yang efektif bukanlah satu perkara yang boleh diambil mudah bagi beliau. ““kes guna”semakin bertambah popular bagi sistem dokumentasi dan keperluan perisian. Dengan nota grafik yang mudah serta senang dilayari dengan bahasa biasa ,”kes guna”amat tertarik kepada pembangunan kumpulan yang dengan pengalaman sedikit dalam spesifikasi formal keperluan.Dengan kemudahan ini amat mudah dielakkan. Walaupun projek kumpulan ini punyai masalah dengan memulakan “kes guna”, kebanyakan dari merekatelah menemui masalah yang biasa di dalam membawa mereka ke usaha yang lebih besar.
1.1Pengenalan Umum Isu Oleh Susan Lily
Secara ringkasnya ,Susan Lily membincangkan masalah-masalah yang berlaku terhadap kes guna yang berlaku di dalam sistem komputer.Di dalam tulisannya ,Susan Lily bukanlah menyalahkan tentang penggunaan “Use-Case’ ini, tetapi lebih kepada memberikan gambaran tentang masalah-masalah yang timbul di dalam penggunaannya. Untuk itu beliau telah menggariskan beberapa pandangan dan cadangan bagi mangatasi masalah tersebut.

2.0Isu-Isu Utama yang dibincangkan
10 Masalah Kes guna
1. Lingkungan system tidak ditafsir atau stabil
2. Kes guna ditulis dari pandangan system(bukan pelakon)
3. Nama pelakon tidak konsisten.
4. Terlalu banyak kes guna.
5. HubunganKes guna pelakon dipasang secara jaringan.
6. Spesifikasi kes guna terlalu panjang
7. Spesifikasi kes guna mengelirukan.
8. Kes guna tidak menggambarkan kepentingan fungsi dengan betul.
9. Pelanggan tidak memehami kes guna.
10. Kes guna tidak pernah habis.
Lingkungan Sistem yang Tidak stabil atau Tidak Konsisten kemungkinan adalah masalah sejagat yang utama yang telah diperhatikan dalam proek percubaan ““kes guna” buat kali pertama. Apabila sistem menjadi keliru, sukar untuk tahu apa yang masuk dan keluar. Kamu boleh selesaikan dengan;
- Terlalu banyak use-cases (pifall4)
- Campuradukkan hubungan pelagak(pelakon) “kes guna”(Pitfall 5)
- Spesifikasi “kes guna” dan besar yang cuba untuk mendapati kepelbagaian level skop (Pitfalls 6 dan 7)
- Gunakan “kes guna” yang tidak boleh disiapkan kerana kumpulan tersebut sedang cuba untuk “ memanaskan lautan”.(Pitfall 10)

3.0Contoh-Contoh yang ditunjukkan
Contoh masalah untuk ini dan yang seterusnya adalah sistem tempahan tiket bagi permainan baseball yang dikomputeriskan.Pengguna boleh lihat jadual musim dan tiket yang disimpan di pondok pusat tiket atau mereka mungkin memanggil 800 nombor dan kerani phone akan simpan tiket untuk mereka. Pengguna boleh bayar melalui kad kredit atau pada masa tiket diambil di stadium di hari perlawanan.

http://www.ddj.com/dept/architect/184414560.
Diagram kes guna ini ada sistem lingkungan yang bercampuraduk. Model cuba untuk menunjukkan kedua-dua pengguna dari perniagaan dan pengguna sistem. Spesifikasi text Tempahan Tiket menjadi keliru kerana set interaksi antara Pengguna telefon dan bisnes adalah set yang berbeza interaksinya antara lain-lain pelagak(pelakon) dan sistem komputer.
Masalah berkaitan berlaku apabila lingkungan sistem hilang dari diagram. Masalah ini sering datang apabila model kes guna menggunakan perkakasan modeling secara visual(spt Rational Rose, Perkakasan objek oriented utama di pasaran) yang tidak meletakkan lingkungan sistem dalam diagram.
Masalah yang telah digambarkan bukanlah satu komen kes guna; lebihkurang, mereka adalah perwakilan kepada kesusahan dalam aplikasi mereka
Ditemukan oleh pelatih-pelatih yang tidak pernah menggunakannya sebelum ini-dan kebanyakan kumpulan pembangunan kes guna adalah dari kalangan ahli yang tidak berpengalaman.
Tambahanpula, pengguna,pengguna akhir dan pakar yang melibatkan diri dalam keperluan kerja tersebut biasanya tidak punyai pengalaman asas dengan kes guna.
4.0 Cara Mengatasi Masalah
Masalah ini boleh diatasi dengan keluar dari skop dan melabelkan linhgkungan sistem ikut susunan.Contohnya lingkungan sistem boleh mewakili sistem komputer, dengan Pondok Pengguna dan Kerani Telefon sbg pelagak(pelakon) yang menggunakan Kes guna Tempahan Tiket. Atau lingkungan sistem boleh mewakili keseluruhan syarikat. Pelagak,Pengguna Telefon adalah pengguna bagi tiket bisnes tetapi tidak kepada sistem komputer. Kedua-duanya adalah model yang sah dari segi undang-undang; pilihan antara mereka bergantung pada samada kamu cuba untuk menafsirkan kehendak sistem komputer atau memberika kerja pada kes guna dalam proses modeling atau di selenggara semula.

Jika kamu bekerja sebagai alat, kamu perlu berusaa memastikan lingkungan sistem jadi nyata. Biarpun tidak di diagram, ia sepatutnya di kepala. Letakkan pelagak(pelakon) dan kes guna di diagram sebagaimana diagram(imaginasi) kotak berada di sana.
Gunakan templat yang seragam bagi spesifikasi kes guna anda. Ketika nota diagram kes guna di seragamkan sebagai sebahagian dari (Object Managemant Group’s Limited Modeling Language )(UML)sedangkan bahasa kes guna yang natural tidak. Bagi memastikan projek anda berjaya dalam penulisan , ciptakan templat untuk dokumentasikan mereka (sebaiknya sebelum kamu sebenarnya memerlukannya). Templat menyediakan keseimbangan antara kes guna dan mengalakkan pemurnian projek.
Dengan tiadanya piawaian industri, pelbagai spesifikasi templat kes guna telah dicadangkan., denagn kesamaan set atau medan. Nama kes guna adalah nama yang muncul di bawah (atau di dalam) diagram kes guna yang oval. Pelagak(pelakon) adalah pelakon utama yang menandakan kes guna. Tujuannya satu diskripsi yang ringkas kegunaan /tujuan kes guna, dari perpektif pelakon utama atau pelakon-pelakon.
5.0Kesimpulan.
Secara keseluruhannya,isu-isu perbincangan Susan Lily ini membangkitkan mengenai pemasalahan yang timbul akibat dari penggunaan “kes guna” di dalam sistem komputer.
Walaubagaimanapun, mudahnya format itu tidak boleh mengelak fakta bahawa analisa keperluan dan spesifikasi bukanlah tujuan utama mereka Banyak pasukan telah menemui masalah yang sama dalam percubaan pertama mereka bekerja dengan kes guna ini.Walaubagaimanapun diutarakan juga tip-tip sebagai panduan.
• Gunakan senarai semak analisa bagi membantu mengesan masalah kes guna yang biasa.
• Tunjukkan bahan untuk “beritahu sebuah cerita.” Kadangkala persembahkan bahan grafik, berbanding tekt linear sahaja adalah mencabar. Dicadangkan analisa secara meluas-utama, diikuti ujian penilian yang mendalam, dari sekumpulan kecil kes guna yang berkait. Seperti, pembentang akan persembahkan bahagian diagram kes guna yang berkaitan dengan pelakon atau satu persatu proses bisnes, kemudian terus kepada spesifikasi yang teliti. Analisa kemudian berbalik kepada diagram untuk mempertimbangkan kaitan lain kes guna. Jangan sama sekali menggunakan susunan mengikut abjad sebagai strategi persembahan.
• Pertimbangkan teknik analisa ynag bukan biasa untuk membuat analisa model. Beliausuka menggunakan “Yellow Sticky Wall Review”(nama yang telah digunakan beberapa tahun lalu di IBM Object Technology University) untuk analisa yang biasa dari model grafik. Digram telah dicetak dan dipaparkan di dinding di lokasi analisa. Semua penganalisa menulis komen pada nota-nota kuning dan letakkan pada diagram berhampiran model yang sebenar.


Soalan 1(b)


Soalan 2.

Sejarah CMM
CMM telah dibangunkan oleh SEI (Software Engineering Institute), sebuah yayasan penyelidikan dan pembangunan kerajaan yang dijalankan oleh Carnegie Mellon University. Sumber definasi ialah dari ;
The Capability Maturity Model: Guidelines for Improving the Software Process, (Carnegie Mellon University/Software Engineering Institute), published in 1995 by Addison-Wesley.

Banyak organisasi telah bermotivasi untuk memperbaiki proses pembangunan perisian mereka dengan bantuan CMM(Capability Maturity Model) untuk perisian. Kebanyakan orang yang pernah mendengar mengenai CMM mengetahui tiga perkara. Ianya menjelaskan lima tahap proses kematangannya,lebih tinggi adalah lebih baik dan kebanyakan dari kita berada di tahap 1. Walaubagaimanapun, ramai yang telah biasa menyalahanggapkan CMM:bagaimana strukturnya, bagaimana perlu diaplikasikannya,bagaimana memajukan satu tahap ke tahap yang lain dan sebagainya.

SW-CMM
The Capabality Maturity Model untuk perisian ,juga dikenali sebagai (CMM dan SW-CMM)telah menjadi satu model digunakan oleh kebanyakan organisasi untuk mengenalpasti cara terbaik membantu mereka di dalam meningkatkan kematangan pembangunan perisian.
Pada Tahun 2000,SW-CMM telah dipertingkatkan kepada CMMI( Capabality Maturity Model Integration). Pihak SEI tidak lagi terus menjaga model SW-CMM. Ia beroperasi berkaitan dengan kaedah-kaedah, bahan-bahan latihan sahaja.
Sebab-sebab Mengapa SW-CMM Diwujudkan dan Digunapakai
Banyak organisasi menggunakan SW-CMM merasakan bahawa perniagaan mereka tidak menerima kesan yang banyak sejak CMMI (Capability Maturity Modul Integrated)diperkenalkan. Untuk memperjelaskan mengenai hal berkaitan, SW-CMM akan menyelesaikan sebarang masalah melalui kaedah berikut;
a- SEI tidak akan menghasilkan apa-apa jua peningkatan terhadap model atau latihan SW-CMM. SEI akan menyediakan pengenalan untuk umum bagi latihan SW-CMM bagi dua tahun selepas pengumuman CMMI V1.1. SEI juga tidak akan mengambil pertukaran rakan kekananan untuk memberikan laluan kepada pengenalan SW-CMM melangkaui dua tahun masa untuk memilih mana-mana organisasi yang memerlukan penghantaran serta instructor baru akan diperkenalkan.
b- Untuk penilaian ,SEI telah mengumumkan SCAMPISMV1.1 sebagai pertukaran kepada CBA IPI and SCESM.SEI tidak akan mengeluarkan mana-mana pembaharuan kepada kaedah CBA IPI dan SCE pada masa-masa hadapan.Ketua Penilaian CBA IPI dan Ketua Penilaian SCE akan diberi latihan dalam jangkamasa berkenaan ;namun demikian mereka ini perlu di pindahkan ke SCAMPI dalam jangkamasa 2 tahun latihan berkenaan.SCAMPI kemudiannya akan menjadi pilihan tunggal.
c- Data darp SEI-diberikuasa penilaian bagi pihak lawan SW-CMM akan meneruskan menerima dan menggunakan sebahagian dari rekod profil komuniti oleh SEI, bersama dengan data dari pihak penilai CMMI yang diberi kuasa.Data-data ini akan digabungkan oleh SEI ke proses komuniti yang sesuai .
Lima Tahap Pembangunan SW-CMM iaitu;
24.1 Tahap 1 - Peringkat Permulaan (Initial)
Di Peringkat Permulaan, organisasi lazimnya tidak menyediakan suatu persekitaran yang stabil untuk membangun dan memelihara perisian. Apabila sesuatu organisasi kurang tadbir baik amalan-amalan, faedah-faedah perisian baik kejuruteraan amalan-amalan dijejaskan oleh perancangan tidak berkesan dan tindak balas didorong sistem-sistem komitmen.
Semasa satu krisis, projek-projek dengan lazimnya meninggalkan dirancang prosedur-prosedur dan kembali menjadi untuk pengekodan dan ujian. Kemajuan bergantung keseluruhannya kepada mempunyai seorang pengurus yang luar biasa dan satu pasukan perisian berpengalaman dan berkesan. Sekali sekala, perisian mampu dan kuat pengurus-pengurus boleh bertahan tekanan-tekanan mengambil jalan pintas dalam proses perisian; tetapi apabila mereka meninggalkan projek, mereka menstabilkan pengaruh meninggalkan mereka. Walaupun satu proses kejuruteraan kukuh tidak boleh mengatasi ketidakstabilan dicipta oleh ketiadaan tadbir baik amalan-amalan.
Proses perisian kebolehan Tahap 1 buah organisasi adalah tidak dijangka kerana proses perisian adalah dengan sentiasa berubah atau terubah sebagai mencatat kemajuan kerja itu (ie., proses adalah ad hoc). jadual-jadual, belanjawan, kefungsian, dan kualiti produk umumnya tidak dijangka. Prestasi bergantung kepada kemampuan individu dan berbeza dengan mereka kemahiran-kemahiran semula jadi, pengetahuan, dan motivasi. Stabil ada beberapa proses-proses perisian keterangan dalam, dan prestasi boleh diramal tetapi secara individu lebih suka keupayaan organisasi.
24.2 Tahap 2 - Tahap Kebolehulangan (Repeatable)
Di Tahap Kebolehulangan, dasar-dasar untuk penyelenggaran satu perisian projek dan prosedur-prosedur untuk melaksanakan dasar-dasar yang adalah mantap. Perancangan dan menguruskan projek-projek baru berdasarkan kepada berpengalaman dengan projek-projek yang sama. Satu matlamat dalam mencapai Tahap 2 adalah untuk diinstitusikan pengurusan efektif proses-proses untuk perisian projek-projek, yang membenarkan pertubuhan-pertubuhan untuk mengulangi berjaya amalan-amalan dibangunkan tentang terdahulu projek-projek, walaupun proses-proses khusus dilaksanakan oleh projek-projek mungkin berbeza. Satu proses yang berkesan boleh digambarkan seperti yang dipraktikkan, didokumenkan, dikuatkuasa, terlatih, diukur, dan bolehkan memperbaiki.
Projek-projek dalam Tahap 2 buah organisasi telah memasang asas pengurusan perisian kuasa. Projek realistik perjanjian-perjanjian berdasarkan kajian-kajian memerhati di projek-projek dahulu dan di keperluan-keperluan projek semasa. Pengurus-pengurus perisian untuk satu projek jalan kos-kos perisian, jadual-jadual, dan kefungsian; masalah-masalah di mesyuarat perjanjian-perjanjian adalah dikenal pasti bila mereka timbul. Syarat-syarat perisian dan produk-produk kerja itu dibangunkan untuk memuaskan mereka adalah baselined, dan integriti mereka adalah terkawal. Projek perisian piawai-piawai adalah didefinisikan, dan organisasi memastikan mereka adalah diikuti betul-betul. Perisian kerja-kerja projek dengan subkontraktornya, jika mana-mana, untuk menubuhkan seorang yang kuat pelanggan pembekal hubungan.
Proses perisian kebolehan Tahap 2 buah organisasi dapat dirumuskan seperti berdisiplin kerana perancangan dan penjejakan projek perisian adalah kejayaan-kejayaan stabil dan terdahulu boleh diulangi. Proses projek adalah di bawah kawalan yang berkesan satu pengurusan projek sistem, penurut realistik rancangan berdasarkan ke atas prestasi projek-projek dahulu.
24.3 Tahap 3 - Ditakrifkan Rata(Defined)
Di Ditakrifkan Rata, standard proses bagi membangun dan memelihara perisian seberang organisasi adalah didokumenkan, termasuklah kedua-dua kejuruteraan perisian dan pengurusan proses-proses, dan proses-proses ini disepadukan ke dalam satu koheren seluruh. Proses standard ini adalah dirujuk untuk seluruh perisian standard CMM sebagai itu organisasi itu proses. Proses-proses ditubuhkan di Tahap 3 digunakan (dan berubah, sebagai sesuai) untuk membantu pengurus-pengurus perisian dan kakitangan teknikal menjalankan lebih dengan berkesan. Mengeksploitasikan organisasi kejuruteraan perisian berkesan amalan-amalan apabila menstandardkan proses-proses perisiannya. Terdapat sekumpulan iaitu berwajib proses perisian organisasi aktiviti-aktiviti, eg., satu perisian kejuruteraan proses kumpulan, atau SEPG [Fowler90]. Satu organisasi luas program latihan adalah dilaksanakan bagi menjamin bahawa kakitangan dan pengurus-pengurus telah pengetahuan dan kemahiran-kemahiran diperlukan untuk memenuhi mereka ditugaskan tugas-tugas.
Projek-projek tukang jahit perisian standard organisasi proses untuk membangunkan mereka sendiri-sendiri ditakrifkan proses perisian, yang merupakan ciri-ciri unik projek. Proses mengikut potongan badan ini adalah dirujuk untuk di CMM sebagai itu project's ditakrifkan proses perisian. Satu ditakrifkan proses perisian mengandungi satu koheren, bersepadu susunan kejuruteraan perisian dan pengurusan jelas proses-proses. Satu proses yang jelas boleh digambarkan sebagai termasuk menyanggupi kriteria, input-input, piawai-piawai dan prosedur-prosedur untuk mempersembahkan kerja itu, diverifikasi mekanisme-mekanisme (seperti melihat ulasan), pengeluaran, dan kriteria penyiapan. Kerana proses perisian adalah baik ditakrifkan, pengurusan mempunyai tanggapan yang baik ke dalam kemajuan teknikal di semua projek.
Proses perisian kebolehan Tahap 3 buah organisasi dapat dirumuskan seperti standard dan kejuruteraan perisian konsisten kerana berdua dan aktiviti-aktiviti pengurusan adalah stabil dan kebolehulangan. Produk yang dalam tempoh mantap baris-baris, kos, jadual, dan kefungsian adalah di bawah kawalan, dan kualiti perisian adalah menjejak. Proses ini keupayaan berdasarkan kepada bersama satu, organisasi luas pemahaman tentang aktiviti-aktiviti, tugas-tugas, dan tanggungjawab-tanggungjawab di satu ditakrifkan proses perisian.
24.4 Tahap 4 - Tahap Terurus(Managed)
Di Tahap Terurus, organisasi menetapkan matlamat kualiti kuantitatif untuk kedua-dua produk-produk perisian dan proses-proses. Produktiviti dan kualiti adalah diukur untuk proses perisian yang penting aktiviti-aktiviti seberang semua projek sebagai sebahagian satu program pengukuran organisasi. Satu organisasi luas proses perisian pangkalan data adalah digunakan untuk mengumpul dan menganalisis data boleh didapati daripada projects' ditakrifkan proses-proses perisian. Proses-proses perisian adalah instrumented dengan ukuran-ukuran jelas dan konsisten di Aras 4. Ukuran-ukuran ini mewujudkan yayasan kuantitatif untuk menilai proses-proses perisian projek-projek dan produk-produk.
Projek-projek mencapai kawalan yang lebih produk-produk mereka dan proses-proses secara penyempitan variasi dalam prestasi proses mereka untuk terjatuh dalam tempoh sempadan-sempadan kuantitatif yang diterima. Perubahan bermakna dalam prestasi proses boleh dibezakan dari variasi rawak (bunyi), terutamanya produk yang dalam tempoh mantap baris-baris. Risiko-risiko terlibat dalam memindahkan atas keluk pembelajaran satu permohonan baru domain dikenali dan dengan berhati-hati terurus.
Proses perisian kebolehan Tahap 4 buah organisasi dapat dirumuskan seperti kerana proses boleh diramalkan adalah diukur dan beroperasi dalam tempoh boleh diukur had-had. Peringkat ini berjalan berkesanggupan membenarkan sebuah organisasi untuk meramalkan tren-tren dalam proses dan kualiti produk batasan yang dikalangan kuantitatif had-had ini. Bila had-had ini adalah melebihi, tindakan diambil untuk membetulkan keadaan. Produk-produk perisian adalah kualiti seperti yang diramalkan tinggi.
24.5 Tahap 5 - Mengoptimakan Tahap(Optimising)
Di Mengoptimakan Tahap, keseluruhan organisasi adalah tertumpu di kemajuan proses yang berterusan. Organisasi mempunyai cara untuk mengenalpasti kelemahan-kelemahan dan mengukuhkan proses proaktif, dengan matlamat bagi pencegahan kejadian kecacatan-kecacatan. Data di keberkesanan proses perisian adalah digunakan untuk melaksanakan faedah kos penganalisisan teknologi-teknologi baru dan cadangan perubahan untuk proses perisian organisasi. Inovasi-inovasi yang guna kejuruteraan perisian terbaik amalan-amalan adalah dikenal pasti dan bertukar seluruh organisasi.
Projek perisian pasukan-pasukan dalam Tahap 5 buah organisasi menganalisis kecacatan-kecacatan untuk menentukan sebab-sebab mereka. Proses-proses perisian adalah dinilai untuk mencegah jenis-jenis terkenal kecacatan-kecacatan daripada berulang-ulang, dan pengajaran belajar adalah disebarkan untuk projek-projek lain.

(C). SW-CMM Sebagai Kitarhayat Metodologi Pembangunan Perisian.seperti RUP

Metodologi didefinisikan sebagai kaedah yang digunakan untuk memberikan panduan dan arah tuju yang betul sepanjang proses pembangunan sistem. Pelbagai faedah akan diperolehi apabila menggunakan metodologi yang betul dalam pembangunan sistem dan sebagai contoh yang paling signifikan ialah proses pembangunan sistem akan berlangsung dengan lancar dan produktif kerana setiap aliran fasa diikuti dan pembangunan sistem juga akan berada dalam skop yang betul dan menepati kehendak pengguna

Perbandingan antara SW-CMM dengan RUP tidak banyak perbezaannya kerana kedua-duanya merupakan pendekatan berorientasikan objek dan fasa-fasanya adalah lebih kurang sama. Metodologi RUP ini telah menjadi piawaian dalam pembangunan perisian Berikut dihuraikan serba sedikit berkenaan dengan RUP;


Rational Unified Process (RUP) merupakan satu metodologi rekabentuk perisian yang dibangunkan oleh Rational Software Corporation. RUP secara asasnya mempunyai empat fasa iaitu fasa permulaan (inception), fasa penghuraian (elaboration), fasa pembinaan (construction) dan fasa yang terakhir adalah fasa pemindahan (transition). Setiap fasa mempunyai satu atau lebih ulangan.

3.3.1Fasa Permulaan (Inception)
i. Tujuan utama fasa ini adalah untuk menentukan objektif dan skop bagi kajian yang bakal dijalankan selain untuk memastikan tujuan kajian dapat dicapai sebaiknya.
ii. Business Case telah dihasilkan. Ini meliputi kejayaan, risiko-risiko yang bakal dihadapi, sumber-sumber yang diperlukan dan juga perancangan perjalanan projek kajian.
iii. Kesemua perkara telah dikenalpasti dan diklasifikasikan untuk lakaran model kes guna.

3.3.2 Fasa Penghuraian (Elaboration)
i. Fasa ini pula merupakan fasa yang paling penting. Ini kerana ia akan menerangkan tentang pembangunan dan struktur rekabentuk kajian.
ii. Turut bertujuan untuk menganalisa masalah, perancangan projek serta mengenalpasti risiko dan langkah-langkah untuk mengelakkannya.
iii. Asas senibina sistem/kajian telah dipilih dan dikenalpasti.

3.3.3Fasa Pembinaan (Construction)
i. Fasa ini merupakan proses pembuatan/pembinaan kajian yang mana dalam fasa ini segala proses dilakukan untuk menjadikan kajian berjaya dilaksanakan.
ii. Penekanan diberikan untuk mengawal operasi kajian dan juga sumber supaya dapat dioptimumkan jadual dan kualiti serta kos.

3.3.4Fasa Pemindahan (Transition)
i. Fasa ini ialah fasa pemindahan untuk maklumat kepada pengguna setelah kajian selesai dijalankan.
ii. Hasil kajian diuji dahulu keberkesanannya secara keseluruhan



Rujukan;


1.Moore, Geoffrey A., Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, New York, NY: HarperCollins Publishers, Inc., 1995.
2..Paulk, Mark C.; Curtis, Bill; Chrissis, Mary Beth Chrissis, and Weber, Charles, Software Engineering Institute, CMU/SEI-93-TR-24, DTIC Number ADA263403, February 1993.
3. Paulk, Mark C.; Weber, Charles V.; Garcia, Suzanne M. Garcia, Chrissis, Mary Beth; and Bush, Marilyn W., Software Engineering Institute, CMU/SEI-93-TR-25, DTIC Number ADA263432, February 1993.
http://www.ddj.com/dept/architect/184414560.
,4.http://www2.cio.com/research/surveyreport.cfm?id=29