Blog ini mengandungi koleksi assignment penulis semasa menuntut di sebuah Pusat Pengajian Tinggi, walaubagaimanapun penulis tidak bertanggungjawab terhadap mutu tugasan dan ketepatan fakta yang terdapat di dalamnya. Pengunjung haruslah membuat pertimbangan sendiri...
Himpunan tugasan/assignment akan diupdate dari masa kesemasa... rajin-rajinlah menjengah.... tq

Saturday, September 5, 2009

Pengaturcaraan Berorientasikan Objek | Soalan 2

Soalan 2.

Pengenalan

(A). Sejarah CMM
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.
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.

CMM menyediakan 2 tujuan utama;
a- menyediakan panduan bagi proses usaha penambahbaikan dalam organisasi perisian
b- untuk membantu dengan mengenalpasti mana-mana organisasi yang berkelayakan untuk mengusahakan tugas-tugas pembangunan perisian.

(B).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;
1. Initial(Permulaan/Pembukaan)
Tiada
2. Repeatable(Mudah Berulang)
Keperluan Pengurusan, Perancangan Projek Perisian, Pengesanan Projek Perisian, Pengurusan SubKontrak Perisian, Jaminan Kualiti Perisian, Pengurusan Penyusunan
Perisian.
(Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, Software Configuration Management )

3. Defined(Bermaksud)

Fokus Proses Organisasi, Definasi Proses Organisasi, Program Latihan, Pengurusan Integrasi Perisian, Kejuruteraan Produk Perisian, Kordinasi Kumpulan, Penilian Kerja Kumpulan.
(Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, Peer review)

4. Managed(Terurus)
Pengurusan Proses Kuantitatif, Pengurusan Kualiti Perisian
(Quantitative Process Management, Software Quality Management)

5. Optimising(Berdaya Tinggi)
Pencegahan Kesilapan, Pengurusan Pertukaran Teknologi, Pengurusan Pertukaran Proses
(Defect Prevention, Technology Change Management, Process Change Management )

Semuanya mewakili evolusi level yang tinggi kebolehan proses perisian. Setiap level, kecuali yang pertama bermaksud kepada beberapa kunci proses kawasan KPAs –sekumpulan yang berkaitan dengan latihan proses-kesemuanya perlu diberikan penjelasan sebenar agar dapat memuaskan hati organisasi terbut agar dapat mencapai ke tahap yang dikehendaki
( Table 1).

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

Adalah difahamkan bahawa pembangunan SW-SMM telah diambil oleh kebanyakan organisasi kerana kepercayaan dan kebolehan SW-CMM itu sendiri di dalam mempraktikkan konsep proses pembangunannya dalam bidang perisian. Walaupun perpindahan berlaku dari SW-CMM ke CMMI, ianya merupakan satu tindakan yang sihat dimana evolusi teknologi CMM boleh mencapai peringkat kematangan pelan teknologinya. Namun demikian, masalah dari tarikhakhir fasa SEI untuk SW-CMM dalam peringkat akhir tetapi adalah merupakan satu penjelasan dan di bincangkan sebagai perpindahan yang biasa.Mmereka perlu berhubungan berkomunikasi lebih efektif mengenai peralihan kedua-dua organisasi juga organisasi kecil daripada SW-CMM ke CMMI.Ini akan memberikan mereka sebab dan alasan untuk menjalankan terus pernigaan.Tambahan lagi, satu-satu sebab untuk membuat sebarang penambahbaikian adlah untuk memberikan sokongan terhadap objektif perniagaan.


Telah dilaporkan di dalam
CIO Research Reports magazine's "Improving Software Development" online survey of 1 May 2001, http://www2.cio.com/research/surveyreport.cfm?id=29,
"SW-CMM seems to be a relatively new but growing practice among our site visitors. Roughly 40% of those using SW-CMM have been doing so for one year or less and close to 37% have been using SW-CMM for 2 to 5 years."
Juga beberapa organisasi antarabangsa, meliputi pihak kerajaan, telah mengambil langkah mengambil peluang menggunakan SW.CMM, dan di dalam beberapa negara sedang juga membahaskan samada untuk mengambil nya atau ISO 15504. Institut Kejuruteraan Perisian (SEI) telah baru-baru ini dilawati oleh pelbagai organisasi dari Asia, Eropah , India dan dari Asia Tengah yang mencari rakan niaga untuk menyediakan dan mengambil perkhidmatan SW-CMM ke dalam negara masing-masing.
Akan menjadi satu kemudahan, lebih logic dan perpindahan yang diterima semua pihak bagi mana-mana organisasi untuk mengambil SW-CMM ke CMMI dari pilihan-pilihan lain yang ada sekarang ini.
Justeru itu, jelas sekali bahawa penggunaan SW-CMM adalah merupakan satu alternatf dan pilihan terbaik penggunaannya di dalam pembangunan perisian di mana ianya merupakan satu kitar hayat metodologi yang digunapakai.

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.
,4.http://www2.cio.com/research/surveyreport.cfm?id=29

Pengaturcaraan Berorientasikan Objek | Soalan 1A

Soalan 1(a)

LAPORAN PERBINCANGAN OLEH SUSAN LILY
TAJUK : HOW TO AVOID USE-CASE PITFALLS

PENGENALAN

Apa yang dimaksudkan dengan “Kes guna “

- Kes Guna ialah merujuk kepada kes guna suatu sistem untuk hasilan output bagi pengguna-pengguna tertentu.
- Kes Guna yang penting 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'
- Setiap Kes Guna mempunyai pelbagai senario lain atau variasi daripada senario utama.

Pengenalan 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.

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.

Isu-Isu Utama
Top 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)

Contoh-Contoh
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.

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.

Atasi 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.
Lain-lain tips bagi analisa kes guna;
• 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.


Kesimpulan.
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.

Sila Klik Jika Ingin Bantu