Bab Ketiga Menulis Aspek Teknikal Projek - ftsm.ukm.my · Rekabentuk Perisian ... Menulis Aspek...

Bab Ketiga: Menulis Aspek Teknikal Projek

Bab Ketiga Menulis Aspek Teknikal Projek

MODEL, METOD, NOTASI DAN TEKNIK

ModelMetodNotasiTeknikMetod atau notasi mana yang sesuai digunakan?

PROSES SEMASA DAN DAN PERNYATAAN KEPERLUAN

Analisis keperluan dan spesifikasi keperluanKeperluan datang dari mana? Masalah? Pelanggan/Pengguna?Analisis Keperluan daripada Sumber PrimerAnalisis Keperluan Berasaskan Sumber SekunderNotasi bagi Pernyataan KeperluanSelepas Pernyataan Keperluan Disediakan

PERSPEKTIF MENYEDIAKAN DOKUMEN KEPERLUAN PERISIAN

Model dan Notasi bagi Spesifikasi Keperluan dan Spesifikasi Rekabentuk Perisian

MENYEDIAKAN DOKUMEN REKABENTUK PERISIAN

Strategi dalam merekabentuk perisianMemilih notasi bagi rekabentuk perisian

ISBN 978-983-41293-6-1

43


Senarai semak dokumen spesifikasi keperluan dan rekabentuk

MENYEDIAKAN DOKUMEN IMPLEMENTASI MENYEDIAKAN DOKUMEN PENGUJIAN ORGANISASI LAIN BAGI DOKUMEN TEKNIKAL

ISBN 978-983-41293-6-1

44


Bab Ketiga Menulis Aspek Teknikal Projek

Dalam bab ini, kita akan membincangkan tentang beberapa aspek teknikal projek. Bahagian pertama akan membincangkan tentang empat istilah teknikal yang sering digunakan, iaitu model, metod, notasi dan teknik. Bahagian kedua hingga kelima pula membincangkan tentang kaedah menulis dokumen projek dari aspek teknikalnya iaitu bermula daripada dokumen pernyataan keperluan dan spesifikasi perisian, diikuti oleh dokumen rekabentuk perisian, dokumen implementasi dan akhirnya dokumen pengujian perisian, seperti dalam rajah 3.1. Rajah tersebut adalah struktur yang biasa digunakan apabila menyediakan dokumen teknikal projek. Namun begitu, jika anda menggunakan teknik tertentu dalam projek anda seperti menggunakan teknik pemprosesan bahasa (juga dikenali dengan nama teknik pengkompil) dalam pembinaan perisian, maka struktur yang berbeza mungkin digunakan. Bahagian terakhir dalam bab ini membincangkan struktur-struktur lain yang boleh ada dalam sesuatu dokumen teknikal projek anda.

Rajah 3.1: Struktur Aspek Teknikal

Proses Bisnes Semasa

Pernyataan Keperluan

Spesifikasi

Rekabentuk

Implementasi

Pengujian



Spesifikasi

Rekabentuk

Implementasi

Pengujian

MODEL, METOD, NOTASI DAN TEKNIK Model Model adalah perwakilan abstrak bagi suatu keadaan sebenar. Model menggambarkan dan terhad kepada aspek yang relevan bagi fenomena yang dikaji. Model mengabaikan perincian yang tidak diperlukan atau tidak relevan. Perincian yang tidak diperlukan, tidak bermakna tidak penting.

Aspek: Suatu keadaan sebenar adalah sangat kompleks. Oleh itu kita tidak akan memodelkan keseluruhan keadaan tersebut, sebaliknya beberapa aspek berkaitan fenomena tersebut sahaja yang dimodelkan.

ISBN 978-983-41293-6-1

45


Terhad: Had menunjukkan sempadan. Oleh kerana kita telah kenalpasti aspek tertentu sahaja yang akan dimodelkan, maka seterusnya, sempadan antara aspek yang dimodelkan dengan persekitarannya yang tidak dimodelkan juga perlu ditunjukkan.

Relevan: Apabila kita telah memilih aspek yang ingin dimodelkan dan hadnya, maka rasional pemilihan aspek tersebut perlu dinyatakan.

Apabila jurutera membangunkan suatu produk, mereka biasanya membina model produk tersebut terlebih dahulu. Misalnya bagi membangunkan sebuah rumah, jurutera biasanya membina model bagi rumah tersebut, mungkin dalam bentuk model 3-dimensi atau model 2-dimensi, seperti yang ditunjukkan dalam Rajah 3.2. Tujuan model ini dibina adalah bagi membolehkan pelanggannya benar-benar memahami pelbagai aspek tentang rumah yang akan dibina.

(a) Model 3D Sebuah Rumah

(b) Model 2D Sebuah Rumah – Pelan Lantai

Rajah 3.2: Model Sebuah Rumah Sumber: eplans.com 2006

ISBN 978-983-41293-6-1

46


Begitu juga, jurutera perisian perlu membina model bagi perisian yang hendak dibangunkan. Model perisian merujuk kepada perwakilan abstrak bagi perisian yang ingin dihasilkan. Tidak ada satu model perisian yang berupaya mewakilkan keseluruhan aspek perisian. Ini kerana terdapat pelbagai aspek bagi suatu perisian seperti: storan data yang terlibat, hubungan antara storan, perincian bagi storan, proses yang ada, hubungan antara proses, maklumat input dan output bagi proses, pengguna yang terlibat, cara interaksi dengan perisian, antaramuka, kaitan antara antaramuka dengan proses, kelakuan perisian berdasarkan masa dan pelbagai aspek lagi. Ramai pelajar yang terkeliru tentang istilah model perisian ini. Mereka kadang-kala menganggapnya sama dengan model proses perisian (software process model). Model proses perisian sebenarnya adalah metodologi yang digunakan bagi membangunkan perisian. Namun, banyak buku kejuruteraan perisian yang menamakan metodologi ini sebagai model, seperti model airterjun dan model evolusi. Ada juga pelajar yang terkeliru antara model dengan prototaip perisian. Mereka menyebut tentang pembangunan model perisian, sedangkan yang dimaksudkan ialah membangunkan satu prototaip perisian. Prototaip perisian ialah perisian yang telah siap dibina berdasarkan spesifikasi yang disediakan. Namun ianya belum bersedia untuk dipasarkan atau digunakan oleh sasaran penggunanya.

Metod Metod dalam kejuruteraan perisian adalah kaedah yang boleh digunakan bagi memodelkan suatu perisian. Suatu metod akan mempunyai perkara berikut:

• satu set notasi. • satu penerangan berkenaan proses pemodelan. • satu set garis panduan untuk menggunakan metod tersebut.

Ada metod yang digunakan dalam beberapa fasa dalam kitar hayat perisian, manakala ada juga yang memfokus kepada satu fasa sahaja. Sebagai contohnya metod analisis berstruktur adalah metod yang boleh digunakan bagi fasa analisis keperluan perisian dan juga fasa rekabentuk perisian. Sebahagian besar metod turut disokong dengan alatan CASE (Computer-Aided Software Engineering). Senarai alatan CASE ada disenaraikan dalam Lampiran A. Sepanjang pengajian anda di dalam bidang ini, pasti anda telah mempelajari sekurang-kurangnya beberapa metod yang standard dalam pembangunan perisian, seperti metod yang disediakan dalam metodologi berstruktur dan metodologi berorientasi objek. Beberapa metod yang terdapat dalam metodologi berstruktur akan dibincangkan di dalam Bab 4.

ISBN 978-983-41293-6-1

47


Notasi Setiap metod dalam pembangunan perisian biasanya disokong oleh satu set notasi yang boleh digunakan untuk mewakilkan pelbagai perspektif perisian. Anda hendaklah memastikan bahawa notasi digunakan adalah notasi yang piawai, dan bukannya notasi yang direka sendiri. Sebagai contohnya, dalam metod analisis berstruktur (dalam metodologi berstruktur), antara notasi yang biasa digunakan ialah Rajah Aliran Data dan Rajah Hubungan Entiti. Dalam metod bersepadu (yang merupakan sebahagian daripada metodologi berorientasi objek), antara notasi yang digunakan ialah Rajah Kelas dan Rajah Aktiviti. Teknik Teknik digunakan sebagai cara untuk menyelesaikan suatu masalah. Sebagai contoh, bagi menjadikan suatu mesej yang dihantar tidak dapat difahami oleh orang lain, kita boleh menggunakan teknik ekripsi seperti RSA. Bagi menjimatkan ruang untuk menyimpan imej, format JPG menggunakan suatu teknik perwakilan data. Banyak masalah yang melibatkan pembuatan keputusan boleh diselesaikan dengan menggunakan teknik cerdas seperti rangkaian neural dan algoritma genetik. Pembangunan perisian bertujuan untuk menyelesaikan suatu masalah. Bagi menyelesaikan masalah tersebut, kita perlu memilih teknik yang paling sesuai. Selepas teknik tersebut dikenalpasti, kita perlu membina algoritma berasaskan kepada teknik tersebut. Pemilihan teknik yang baik akan memastikan kita dapat menyelesaikan masalah dengan betul dan berkesan. Metod atau notasi mana yang sesuai digunakan? Clements et al (2003) mengesyorkan beberapa perkara yang perlu ditonjolkan dalam senibina sesuatu sistem dengan kepentingan yang berbeza seperti berikut:

a) Jika perisian yang ingin dibina memerlukan prestasi tinggi, anda perlu: • memberi perhatian kepada dekomposisi tugas kepada proses yang

bekerjasama. • mengendalikan volum komunikasi antara proses dan kekerapan

capaian data. • berupaya menganggar jangkaan kependaman dan throughputs. • mengenalpasti kemungkinan sekatan prestasi. • memahami kesilapan cabangan rangkaian atau pemproses.

ISBN 978-983-41293-6-1

48


b) Jika perisian yang ingin dibina memerlukan ketepatan tinggi, berikan perhatian kepada cara unsur data ditakrif dan digunakan.

c) Jika perisian yang ingin dibina memerlukan keselamatan yang tinggi,

anda perlu: • menyatakan dengan jelas penggunaan hubungan dan kekangan

komunikasi antara bahagian. • menyatakan bahagian sistem yang mudah diceroboh. • jika boleh, perkenalkan komponen yang khas dan boleh dipercayai.

d) Jika perisian yang ingin dibina perlu menyokong keubahsuaian dan kemudahalihan, anda perlu berhati-hati apabila memisahkan perhatian antara bahagian dalam sistem.

e) Jika perisian ingin dibina secara menokok, iaitu menghasilkan subset

yang lebih besar secara berturutan, maka anda perlu pastikan hubungan kebergantungan antara modul mesti dikekalkan terurai (iaitu tidak berselirat).

Keperluan pengguna biasanya ditulis dalam bahasa tabii, namun, bagi spesifikasi keperluan perisian, ianya mungkin ditambah dengan penerangan formal atau semi-formal. Dengan memilih notasi tertentu, keperluan dan aspek tertentu senibina perisian boleh dijelaskan dengan lebih tepat daripada bahasa tabii. Secara praktikal, Sommerville (2001) mengatakan jurutera keperluan tidak perlu mengekang diri mereka kepada model yang disyorkan dalam mana-mana metod tertentu. Contohnya beliau sendiri telah membangunkan model aliran data semasa menggunakan metod berorientasi-objek. Walau apapun notasi yang anda gunakan, yang penting adalah notasi tersebut boleh menyatakan keperluan dengan setepat mungkin (SE2004, SWEBOK). Walaupun tiada metod atau notasi tertentu yang wajib diikuti, sebagai pelajar sebaiknya anda gunakan metod yang standard yang telah dipelajari. Namun begitu, anda boleh juga menggunakan metod lain yang ditetapkan atau dicadangkan oleh penyelia anda. Anda tidak sepatutnya mencipta notasi sendiri sedangkan notasi yang standard telah disediakan oleh pakar untuk anda gunakan. Begitu juga, apabila menggunakan suatu notasi yang piawai, anda perlu mematuhi syarat penggunaannya. Jika anda gunakan metod tertentu, maka sepatutnya notasi yang disarankan oleh metod itu digunakan.

ISBN 978-983-41293-6-1

49


PROSES SEMASA DAN PERNYATAAN KEPERLUAN Setelah memahami beberapa istilah dan kepelbagaian notasi, kita akan lihat pula kandungan teknikal penting yang perlu ada dalam suatu dokumen projek Sains Komputer. Rajah 3.3 berikut menunjukkan perkara asas yang perlu.





Analisis keperluan dan spesifikasi keperluan Dalam kebanyakan buku Kejuruteraan Perisian, terdapat bab yang bertajuk “Analisis Keperluan”. Namun apabila kita menulis dokumentasi, tidak sepatutnya kita memberi tajuk “Analisis Keperluan” kerana analisis adalah frasa perbuatan. Sebaiknya kita memberi tajuk hasil dari aktiviti itu iaitu “Spesifikasi Keperluan” atau boleh juga “Pernyataan dan Spesifikasi Keperluan”. Manakala proses analisis itu kebiasaannya tidak direkodkan, melainkan ada kepentingan.


Spesifikasi Perisian

Analisis Keperluan

Rajah 3.3: Proses analisis keperluan Dalam Kejuruteraan Perisian, terdapat metod bagi proses mendapat dan menganalisis keperluan. Metod VORD (Viewpoint-Oriented Requirements Definition) (Kotonya and Sommerveille, 1996, 1998) adalah kaedah untuk mendapatkan keperluan berorientasi viewpoint, manakala kaedah berorientasi objek adalah kaedah untuk mendapatkan keperluan berorientasi objek. Bagi pencerapan keperluan berasaskan metod formal, VDM atau Z boleh digunakan. Sebagai tambahan, kaedah seumpama VORD adalah kaedah khusus untuk mendapatkan keperluan, manakala kaedah seumpama kaedah berorientasi objek dan kaedah formal, turut meliputi fasa kejuruteraan perisian yang lain seperti fasa rekabentuk. Ada juga usaha yang dijalankan bagi mengumpul sebanyak mungkin kaedah yang terlibat dalam fasa ini seperti ReadySET (Requirement and Specification). Kaedah-kaedah yang diterima pakai oleh masyarakat pembangun perisian biasanya disokong dengan alatan CASE. Dengan adanya alatan CASE, penyediaan bahan untuk dokumen spesifikasi keperluan lebih terkawal dan kemas. Bagi alatan CASE untuk VORD, ianya menyediakan templat-templat untuk diisi oleh penspesifikasi yang menggunakan kaedah tersebut. Alatan

ISBN 978-983-41293-6-1

50


CASE bagi kaedah formal seperti VDM ataupun Z terdiri daripada fungsi-fungsi seperti penyemak jenis, penyemak sintaks dan pembukti teorem. Sebahagian alatan CASE ini boleh dimuat-turun secara percuma dari Internet. Penggunaan alatan CASE tidak menjamin spesifikasi keperluan yang dihasilkan betul dari segi penggunaan notasinya; bayangkan pula jika tidak menggunakan alatan ini. Sehubungan itu, sama ada menggunakan alatan CASE, lebih-lebih lagi jika tidak, anda perlu mengetahui notasi-notasi yang ada bagi kaedah yang digunakan dalam mencerap keperluan. Gunakan kaedah yang pernah dipelajari. Jika terdapat alatan CASE yang menyokong kaedah tersebut, sebaiknya digunakan. Keperluan datang dari mana? Masalah? Pelanggan/Pengguna? Setelah anda berjaya memilih projek yang bersesuaian, adakah anda akan mendapatkan keperluan daripada sumber sebenar, sekunder atau imaginasi?

• Sumber sebenar adalah seperti mereka yang berkepentingan (stakeholder) kepada perisian, pakar domain khasnya untuk sistem pakar, persekitaran operasian dan organisasi jika sistem akan mengambilalih sistem sedia ada.

• Sumber sekunder bermaksud anda merujuk dokumen yang telah tersedia

tanpa bertemu dengan sumber asal. Contohnya anda ingin membangunkan sistem pakar bagi menentukan penyakit padi. Maka anda hanya merujuk buku berkaitan penyakit padi.

• Manakala sumber imaginasi adalah maklumat yang telah anda ketahui

serba sedikit, dan anda mengembangkannya melalui imaginasi. Contohnya anda ingin membuat sistem maklumat pelajar Sekolah Kebangsaan Ceruk To'kun. Dengan membuat pelbagai andaian berdasarkan imaginasi anda, anda pun hadir dengan spesifikasi keperluan perisian.

Sebaiknya dalam melaksanakan projek, anda mendapatkan keperluan daripada sumber sebenar dan disokong dengan sumber sekunder. Elakkan daripada menggunakan imaginasi anda semata-mata. Tidak dinafikan, bagi projek yang menggunakan sumber sebenar, anda akan mengorbankan sejumlah masa untuk mendapatkan temujanji dan pelbagai hal lagi. Analisis Keperluan daripada Sumber Primer Bagi melakukan analisis keperluan berasaskan sumber primer, anda perlu membuat kajian secara langsung kepada masalah yang hendak dianalisis. Sebagai contohnya, bagi membangunkan satu sistem maklumat bagi keperluan bisnes, anda perlu terlebih dahulu memahami proses bisnes semasa. Proses

ISBN 978-983-41293-6-1

51


bisnes semasa ini boleh jadi merupakan satu proses manual atau proses semi-automatik atau proses yang melibatkan penggunaan suatu sistem berkomputer. Sekiranya anda ingin memperbaiki sistem berkomputer yang telah ada, maka sistem berkomputer sedia ada itu perlu difahami sedalamnya. Contohnya dalam pembinaan Sistem Pengurusan Fail, anda perlu mengetahui:

• Siapakah yang terlibat dalam pengurusan tersebut? • Apakah peranan dan proses kerja mereka? • Adakah pengurusan itu melibatkan suatu polisi? • Apakah dokumen input dan output yang terlibat dalam sistem sedia ada

tersebut? • Apakah data yang terlibat? • Berapakah hayat data tersebut?

Bagi mendapatkan jawapan bagi persoalan di atas, anda perlu melakukan temubual dengan pihak syarikat, mencerap proses kerja sebenar dan memeriksa dokumen sedia ada. Keseluruhan aspek sistem sedia ada perlu diperhatikan. Kesemua perkara ini kemudiannya perlu didokumenkan. Rajah 3.4 menunjukkan satu contoh dokumen proses bisnes bagi pengurusan fail Syarikat ABC yang telah disediakan oleh seorang pelajar.

SISTEM SEMASA PENGURUSAN FAIL SYARIKAT ABC Dalam pengurusan fail, sistem yang diguna pakai di Syarikat ABC adalah masih menggunakan sistem secara manual. Analisis ini merangkumi tinjauan terhadap sistem manual yang digunakan oleh Syarikat ABC yang mana maklumat yang diperolehi akan dianalisis dalam merekabentuk sistem yang baru. Secara umumnya, terdapat lima kategori yang terlibat dalam sistem ini iaitu:

I. Pegawai Bertanggungjawab; terdiri daripada penyelia bahagian yang telah dilantik,

II. Pegawai Penerima; semua Pegawai bahagian, III. Pihak Pengurusan; terdiri daripada Pengarah bahagian dan, IV. Pihak Pentadbir; terdiri daripada pegawai atau kerani yang diberi kuasa

menjalankan tugas rasminya di dalam urusan untuk mengendalikan pengurusan fail bermula dari pendaftaran fail hingga fail ditutup.

Antara proses yang terlibat adalah seperti berikut: a) Proses Pendaftaran Fail Pegawai yang bertanggungjawab atau diberi kuasa di dalam urusan berkaitan fail di setiap bahagian atau unit akan memberikan nama tajuk fail kepada pihak pentadbiran di bilik fail untuk mewujudkan fail baru. Kerani di bilik fail akan memeriksa rekod di buku log daftar fail bagi mempastikan sama ada tajuk fail tersebut sudah didaftarkan atau tidak. Jika pendaftaran fail belum wujud, kerani di bilik fail akan membuka fail baru dengan memberikan nombor rujukan. Nombor rujukan yang diberikan mengikut format dan kategori-kategori tertentu iaitu:

ABC(kew)200 adalah untuk unit kewangan. ABC(stor)200 untuk unit stor. ABC(PTD)100 untuk pihak pengurusan.

Kemudian ia akan didaftarkan pada buku log daftar fail sebelum fail tersebut diserahkan kepada

ISBN 978-983-41293-6-1

52


pegawai berkenaan. b) Proses Penutupan/ Penjilidan Fail Kerani di bilik fail akan memantau perubahan fizikal terhadap setiap fail yang telah didaftarkan. Jika ketebalan fail melebihi 1 inci atau kandungan di dalam fail tersebut melebihi 100 helai muka surat, fail berkenaan akan ditutup dan jilid baru akan dibuka. Maklumat rekod berkaitan penutupan dan penjilidan fail dikemaskini dalam buku log rekod fail. c) Proses Pergerakan Fail Kerani di bilik fail merekodkan maklumat pegawai penerima atau lokasi fail semasa di dalam buku log keluar fail apabila fail diserahkan kepada pegawai penerima. Maksud pegawai penerima di sini adalah mereka yang akan menggunakan fail tersebut untuk menjalankan tugas rasmi. Kerani di bilik fail akan mengesahkan penerimaan apabila fail dikembalikan semula. d) Proses Pendaftaran Surat Masuk Pendaftaran surat menyurat masuk menggunakan borang Am 10-Pin. 3/80. Pendaftaran ini adalah untuk merekodkan kemasukan surat rasmi dari jabatan kerajaan atau organisasi bukan kerajaan. Borang ini mengandungi butiran seperti tarikh penerimaan, nombor fail kementerian, tarikh surat, daripada siapa, perkara dan dirujukkan kepada siapa. Kakitangan yang berkenaan di unit pentadbiran ibu pejabat Syarikat ABC ditugaskan untuk merekodkan maklumat tertentu mengenai surat tersebut di dalam borang pendaftaran surat menyurat masuk. Contoh borang Am 10-Pin. 3/80 ditunjukkan seperti di dalam rajah 1.

Rajah 1: Contoh Borang Am 10- Pin. 3/80

f) Proses Pendaftaran Surat Keluar Kakitangan yang ditugaskan di unit pentadbiran ibu pejabat Syarikat ABC akan merekodkan maklumat tertentu surat rasmi jabatan ini di buku log surat keluar. Buku ini mengandungi butiran rekod seperti nombor rujukan surat, kepada siapa akan dihantar, cara penghantaran surat dan harga stem. g) Proses Penyediaan Laporan Semasa Kakitangan yang bertanggungjawab akan menyediakan laporan secara manual jika diperlukan oleh pihak pengurusan Syarikat ABC. Di antara laporan-laporan adalah seperti berikut:

• Senarai fail yang telah didaftarkan,

ISBN 978-983-41293-6-1

53


• Senarai fail yang masih aktif termasuk jilid fail dan, • Senarai fail yang telah ditutup termasuk jilid fail.

Rajah 3.4: Contoh Satu Dokumen Proses Bisnes

Daripada dokumen dalam Rajah 3.4 di atas, kelihatannya dokumen proses bisnes sistem pengurusan fail ini telah dinyatakan dengan terperinci. Namun begitu, masih terdapat beberapa perkara yang masih perlu dijelaskan lagi iaitu:

• Apakah format nombor rujukan fail? • Adakah nama kakitangan yang bertugas untuk membuka atau menutup

fail juga perlu direkodkan? • Bolehkah seseorang meminjam lebih daripada satu fail pada satu-satu

masa? • Berapa lamakah fail boleh dipinjam?

Bagi mendapatkan jawapan kepada masalah tersebut, anda mungkin perlu mengadakan perbincangan dengan pihak syarikat beberapa kali, sehinggalah anda mendapat kesemua maklumat yang diperlukan bagi proses bisnes tersebut. Setelah kita memahami proses bisnes semasa, barulah kita boleh sediakan pernyataan keperluan. Pernyataan keperluan dinyatakan dengan ciri berikut:

• Menggunakan ayat yang lengkap dan nahu yang betul. • Menggunakan idiom bagi sektor bisnes tersebut. Contoh bagi Sistem

Tempahan Hotel, antara idiom yang mungkin adalah seperti check-in, check-out, room-service dan wake-up call.

• Menggunakan perkataan “hanya”, “perlu”, “akan”, “mesti” dan kata kunci lain yang bersesuaian.

• Menepati format yang disediakan. Rajah 3.5 menunjukkan cara menulis sebahagian daripada pernyataan keperluan bagi Sistem Pengurusan Fail yang dinyatakan dalam Rajah 3.4.

ISBN 978-983-41293-6-1

54


• Terdapat dua jenis pengguna iaitu pengguna biasa dan pihak pentadbir. • Maklumat setiap pengguna yang berdaftar dengan sistem mesti direkodkan. • Setiap pengguna dibekalkan dengan kata nama dan katalaluan yang unik untuk

menggunakan sistem ini. • Apabila satu fail baru dibuka, maklumat fail, tarikh buka fail dan si pembuka fail

(iaitu pihak pentadbir) mesti direkodkan. • Apabila satu fail ditutup, tarikh tutup fail dan si penutup fail (iaitu pihak pentadbir)

mesti direkodkan. • Pengguna biasa boleh meminjam fail dan melihat laporan. • Satu fail hanya boleh dipinjam oleh satu orang pada satu-satu masa. • Apabila fail dipinjam, maklumat si peminjam dan tarikh pinjaman mesti direkodkan. • Apabila fail dipulang, tarikh pemulangan mesti direkodkan. • Satu fail hanya boleh dipinjam tidak lebih dua minggu daripada tarikh pinjaman. • Apabila tempoh peminjaman tamat, peminjam akan diberi peringatan. • Surat baru yang ingin difailkan, mestilah direkodkan maklumatnya, si pembuka surat

(pihak pentadbir) dan tarikh surat diterima.

Rajah 3.5: Contoh Pernyataan Keperluan

Analisis Keperluan Berasaskan Sumber Sekunder Kadangkala anda dikehendaki untuk membuat satu projek yang pernyataan masalahnya telahpun disediakan oleh pihak lain ataupun telah sedia terdokumen. Sebagai contohnya:

• Mengimplementasi satu algoritma sedia ada, contohnya mengimplementasikan Kaedah Jacobi, Kaedah Pengunduran Berlebihan Berturut-turut atau Algoritma Semut.

• Mengubahsuai algoritma sedia ada bagi meningkatkan kecekapannya ataupun membolehkan algoritma ini diimplementasi bagi senario yang lain. Sebagai contohnya untuk mengimplementasikan Kaedah Jacobi bagi mesin selari.

• Membangun semula satu perisian piawai, sebagai contohnya penyunting teks atau pemproses kata atau membangunkan yang baru.

Sebagai contohnya, anda dikehendaki untuk mengaplikasikan Algoritma Semut bagi mendapatkan jarak terdekat antara dua tempat bagi lebuh raya di Malaysia. Langkah pertama yang perlu anda lakukan ialah dengan mengkaji serta mendapatkan maklumat tentang Algoritma Semut daripada buku atau kertas penyelidikan. Selepas membuat rujukan, anda perlu menulis semula maklumat tentang algoritma tersebut dengan menyertakan sumber rujukan yang telah dipetik. Rajah 3.6 menunjukkan contoh penulisan yang dilakukan oleh seorang pelajar tentang Algoritma Semut.

ISBN 978-983-41293-6-1

55


ALGORITMA SEMUT Algoritma ini diasaskan oleh Marco Dorigo dalam tesisnya dalam tahun 1992. Algoritma ini diilhamkan oleh satu kajian mengenai koloni semut dalam pencarian makanan. Kelakuan yang paling menarik tetang koloni ini ialah bagaimana serangga yang dianggap hampir buta ini berjaya menggunakan jalan terpendek bagi perjalanan mereka dari sumber makanan dan balik semula ke sarang mereka. Satu sifat semulajadi semut yang perlu diketahui ialah mereka menggunakan feromon, iaitu satu bahan kimia yang dihasilkan oleh setiap semut semasa bergerak dari satu tempat ke tempat yang lain. Feromon ini kemudiannya digunakan oleh semut yang lain sebagai panduan bagi semut yang lain untuk melalui laluan tersebut. Sekiranya seekor semut terpaksa memilih beberapa laluan, ia akan memilih satu laluan dengan kesan feromon yang paling tinggi. Untuk memperjelaskan lagi senario ini, perhatikan Rajah 1 berikut:

Rajah 1 : Senario perjalanan suatu koloni semut

Pertimbangkan Rajah 1 a, b dan c. Rajah 1(a) menunjukkan satu laluan bagi koloni semut daripada sarang di A, dan sumber makanan di F. Perhatikan jarak laluan ABCE adalah lebih pendek dari laluan ABDE. Pada masa t=0, terdapat 30 ekor semut di A dan F. Andaikan semut-semut di A akan bergerak ke F, dan semut-semut di F akan bergerak ke A secara rawak pada purata 1 per unit masa dan meninggalkan kesan feromon berketumpatan 1. Andaikan bahawa semua semut di A telah sampai ke B dan semut-semut di F telah sampai ke E. Setiap semut di B bebas memilih laluan samada ke BC atau BD, manakala semut-semut di E bebas memilih laluan ED atau EC kerana tidak terdapat sebarang kesan feromon di laluan tersebut. Andaikan separuh daripada semut akan melalui keempat-empat laluan BC, BD, ED dan EC seperti Rajah 1(b). Pada ketika ini, kesan feromon di keempat-empat laluan tersebut ialah 15. Pada masa t=1, sekumpulan 30 ekor semut yang baru akan tiba di B daripada A. Semut-semut ini akan mendapati telah ada 15 kesan feromon pada laluan BD yang ditinggalkan oleh semut-semut sebelum ini. Sementara itu, di laluan BC, terdapat 30 kesan feromon yang ditinggalkan oleh kesemua jumlah semut yang pernah melalui laluan BC (15 kesan feromon) dan EC (15 kesan feromon). Oleh itu, kebarangkalian semut yang melalui laluan BC adalah lebih tinggi daripada laluan BD kerana kesan feromon yang lebih tinggi di laluan tersebut, seperti yang ditunjukkan pada Rajah 1(c). Lama-kelamaan laluan ini akan dipilih oleh koloni tersebut sebagai laluan mereka mencari makanan, iaitu sinonim dengan laluan terpendek.

PERINCIAN ALGORITMA SEMUT

Bahagian ini akan membincangkan tentang Algoritma Semut, berdasarkan artikel yang dibincangkan mengenai penyelesaian masalah jurujal jalanan oleh Dorigo (Dorigo et al, 1997). Antara parameter yang terlibat ialah:

τij(t), iaitu tahap ketepuan feromon di pinggir (i,j) pada masa t. tabu, ialah senarai bandar yang telah dilawati oleh semut dij, panjang laluan di antara bandar i dan j. Jarak antara dua bandar i dan j diperolehi daripada

jarak Euclidean iaitu:

dij = [(xi-xj)2+(yi-yj)2]1/2. (1)

ISBN 978-983-41293-6-1

56


ηij, ukuran heuristik bagi menentukan kebarangkalian, nilainya disetkan dengan 1/dij kebarangkalian peralihan pergerakan setiap agen dari bandar i ke bandar j untuk agen ke-k adalah

berdasarkan:

(2)

Jika bandar j didapati telah dilawati, maka kebaran gkalian agen bergerak ke bandar j adalah 0. α dan β adalah parameter yang membenarkan trade-off antara kesan feromon dan jarak. Jika β bernilai kecil, agen akan mementingkan kesan feromon di setiap laluan bagi mencari jarak terpendek. Jika α adalah kecil, agen akan mencari bandar yang paling dekat (tanpa mengambilkira kesan feromon).

Setiap kali melakukan pergerakan ke sesuatu bandar, setiap agen akan melakukan kemaskini nilai feromon secara lokal. Agen yang berjaya mencari jarak terpendek pula akan melakukan kemaskini nilai feromon secara global (selepas habis lawatan ke semua bandar). Formula untuk pengemaskinian feromon adalah τij (t+1) = (1-ρ) . τij (t) + ρ ∆τij (t) ; dengan ρ merupakan pekali yang mewakili kadar pemeruapan dan ∆τij bernilai:

(3) dan Q merupakan satu nilai pemalar positif.

Rajah 3.6: Perincian Tentang Algoritma Semut

Jika projek anda melibatkan pembangunan semula suatu perisian sedia ada, selain daripada merujuk kepada dokumen tentang perisian tersebut, anda mungkin juga perlu melakukan tinjauan pengguna bagi mendapatkan pandangan mereka tentang ciri-ciri tambahan atau pembaikan yang perlu dilakukan ke atas perisian tersebut. Sebagai contohnya, katakan anda dikehendaki untuk membangun semula perisian pemproses kata. Anda boleh mendapat maklumat awal tentang keperluan perisian tersebut dengan mengkaji dokumen berkaitan dengan perisian yang sedia ada. Selain itu anda boleh melakukan satu soal-selidik kepada pengguna pemproses kata untuk mendapatkan pandangan mereka tentang fitur lain yang mungkin diperlukan. Hasil daripada soal-selidik ini boleh dijadikan asas bagi memperbaiki pernyataan keperluan yang sedia ada. Proses ini ditunjukkan dalam Rajah 3.7.

ISBN 978-983-41293-6-1

57


Dapatkan keperluan perisian daripada dokumen sedia ada

Lakukan soal-selidik bagi

mendapat pandangan pengguna

Rajah 3.7: Proses pembaikian perisian sedia ada

Sediakan dokumen pernyataan keperluan baru

Notasi bagi Pernyataan Keperluan Pernyataan keperluan tidak mempunyai notasi tertentu dan kebiasaannya ia dinyatakan dalam bahasa tabii dan disokong oleh pelbagai rajah biasa. Anda boleh gunakan rajah seperti rajah aliran kerja, rajah aliran dokumen, carta aliran, atau sebarang notasi lain bagi membantu memahami proses semasa ini. Proses bisnes semasa dan pernyataan keperluan dinyatakan selepas bab Kajian Latar. Sekiranya bab dua adalah Kajian Latar, maka proses bisnes dan pernyataan keperluan boleh berada dalam bab ketiga.

1. Pengenalan 2. Proses Bisnes Semasa atau Penerangan Berkenaan

Algoritma Tertentu 3. Pernyataan Keperluan

Selepas Pernyataan Keperluan Disediakan Langkah selanjutnya adalah untuk menganalisis keperluan tersebut. Seperti yang telah dinyatakan sebelum ini, anda boleh menggunakan metod tertentu untuk menganalisis keperluan atau menggunakan cara anda sendiri. Antara metod yang boleh digunakan untuk memproses keperluan adalah VORD, SSADM dan Pendekatan Bersepadu. Proses analisis keperluan itu tidak perlu direkodkan. Sebaliknya hasil analisis itu yang perlu didokumenkan. Hasil daripada analisis keperluan adalah:

• Spesifikasi keperluan pengguna • Spesifikasi keperluan perisian • Spesifikasi keperluan perkakasan

ISBN 978-983-41293-6-1

58


Spesifikasi keperluan yang dihasilkan perlu memenuhi keseluruhan pernyataan keperluan. Namun, pernyataan keperluan tidak semestinya mengautomasikan keseluruhan proses semasa. Kemungkinan ada bahagian yang ingin dikekal proses secara manual. Contohnya dalam kes pengurusan latihan industri, umpukan pelajar kepada penyelia di fakulti agak rumit kerana ianya melibatkan sejarah umpukan, jarak syarikat, bilangan pelajar, kesihatan penyelia dan seumpamanya. Sehubungan itu, proses umpukan ini dikekalkan sebagai proses manual. Begitu juga, bagi suatu rekabentuk perisian, mungkin ianya tidak merangkumi semua apa yang dispesifikasikan akibat daripada masalah-masalah seperti kekurangan teknik. Apatah lagi di bahagian implementasi, adalah mungkin anda tidak dapat mengimplementasi sepenuhnya apa yang direka bentuk. Hubungan ini dapat diilustrasikan menggunakan operator hubungan superset seperti berikut: Pernyataan keperluan ⊇ spesifikasi keperluan ⊇ rekabentuk ⊇ implementasi Namun begitu, penulis dapati, terdapat pelajar yang menspesifikasikan sesuatu yang tidak dinyatakan dalam pernyataan keperluan, mengimplemen sesuatu yang tidak dinyatakan dalam rekabentuknya, atau menyediakan rekabentuk yang melampaui apa yang dispesifikasikan. Dari manakah datangnya maklumat tersebut? Keadaan begini menunjukkan pelajar tidak mematuhi apa yang dirancangnya. Ia tidak sepatutnya berlaku! Soalan yang sebaiknya kita tanyakan kepada diri kita ialah:

• Adakah pernyataan keperluan yang disediakan, boleh diberikan kepada pihak ketiga, dan cukup untuk pihak tersebut menyediakan spesifikasi?

• Adakah spesifikasi keperluan yang disediakan mencukupi untuk membina rekabentuk?

• Adakah rekabentuk yang dihasilkan, boleh diberikan kepada pihak ketiga, untuk mengimplemen perisian yang dimahukan?

Soalan-soalan begini diharap dapat membantu anda menilai sendiri sama ada dokumen yang direkodkan ‘cukup’ untuk pergi ke langkah seterusnya. PERSPEKTIF Sebelum meneruskan perbincangan berkenaan dokumen keperluan perisian dan dokumen rekabentuk, satu istilah ingin dijelaskan di sini iaitu perspektif. Selain perspektif, ada juga yang menggunakan istilah view. Maksudnya adalah sama iaitu sudut pandangan. Di dalam menyatakan suatu senibina, spesifikasi atau model sistem, anda perlu jelas dari perspektif apakah perkara tersebut

ISBN 978-983-41293-6-1

59


dinyatakan. Oleh kerana perisian adalah sesuatu yang “soft” (dengan mengambil kata asalnya, software), maka isu perspektif ini kurang difokuskan, walaupun sebenarnya rekabentuk tersebut menunjukkan sudut pandangan tertentu. Cuba kita analogikan perspektif senibina perisian ini dengan perspektif senibina satu rumah. Sebelum satu rumah dibina, beberapa dokumen rekabentuk perlu dihasilkan. Dokumen ini dihasilkan untuk tujuan dan orang yang berbeza. Pertama sekali ialah pelan senibina rumah. Selain daripada model 3D, pelan lantai, pelan dari sudut pandangan hadapan, atas, kiri, kanan dan belakang juga perlu disediakan. Pelan-pelan ini dihasilkan oleh arkitek. Di dalam pelan ini, kedudukan bilik-bilik, saiznya, bilik air, sehingga kedudukan mangkuk tandas pun ada sekali. Rajah 3.2 (berada pada awal bab) menunjukkan model 3D sebuah rumah dan pelan lantainya. Rajah 3.8 pula memberikan penjelasan tentang rumah yang sama tetapi dalam perspektif yang berbeza.

(a) Spesifikasi sebuah rumah

(b) Rekabentuk Sebuah Rumah dari Sudut Pandangan Belakang

Rajah 3.8: Model Sebuah Rumah Sumber: eplans.com 2006

ISBN 978-983-41293-6-1

60


Namun, maklumat dalam pelan yang ada ini tidak mencukupi untuk membina rumah tersebut. Maklumat lain diperlukan bagi membolehkan tukang rumah membina rumah. Maklumat yang diperlukan adalah seperti kedudukan dan saiz tiang-tiang, kedudukan dan saiz beam, jenis bata dan seumpamanya. Maklumat seterusnya ini disediakan oleh jurutera. Begitu juga dengan reka bentuk mekanikal seperti plumbing, elektrikal, talian telefon perlu juga disediakan. Pelan-pelan mekanikal ini pula disediakan oleh jurutera-jurutera yang berkaitan. Seterusnya tukang rumah akan membina rumah, plumber akan memasang paip-paip berkaitan, juru elektrik akan membuat pendawaian, yang kesemuanya berdasarkan pelan-pelan mekanikal tersebut. Bagi pembangunan projek perisian, berbanding projek binaan rumah sebenar, ialah

Projek Binaan Rumah Sebenar Projek Perisian Diuruskan oleh Pemaju Perumahan Diuruskan oleh anda seorang

dengan dikawal selia oleh penyelia. Arkitek: menyediakan pelan-pelan rumah.

Anda: menyediakan spesifikasi perisian.

Jurutera: menyediakan dokumen dari aspek binaan dan mekanikal rumah

Anda: menyediakan dokumen rekabentuk perisian.

Jurueletrik, plumber, buruh kasar: membangunkan rumah tersebut secara fizikal.

Anda: membina perisian.

Majlis Perbandaran: menilai hasil binaan untuk diberikan CF

Anda: melakukan pengujian untuk tujuan mengesahkan binaan.

Oleh kerana anda berada di semua fasa, dan melakukan tugas di setiap fasa tersebut, maka kadang kala anda gagal untuk melihat kepentingan dan perbezaan setiap dokumen yang dihasilkan. Anda perlu keluar sebentar daripada menjadi ‘anda’, dan melihat proses penghasilan perisian ini dari perspektif ‘orang luar’. Dengan memahami makna perspektif bagi suatu reka bentuk, maka apabila anda menyediakan satu rekabentuk, pastikan anda mengetahui dari perspektif manakah ianya dihasilkan. Dalam pemodelan perisian, teknik yang berbeza menekankan aspek yang berbeza bagi satu sistem yang sama. Biasanya perspektif tersebut boleh bertindan, namun kecil.

ISBN 978-983-41293-6-1

61


MENYEDIAKAN DOKUMEN KEPERLUAN PERISIAN Seperti yang telah dinyatakan sebelum ini, suatu dokumen keperluan perisian terdiri daripada tiga elemen teknikal iaitu:

• Spesifikasi keperluan pengguna Dokumen ini dinyatakan dalam bahasa tabii dan rajah. Dokumen ini dilihat dari perspektif pengguna sistem. Ianya meliputi maklumat tentang servis yang akan disediakan oleh sistem, dan dalam keadaan apa sepatutnya ia beroperasi. Keperluan bukan fungsian dinyatakan di sini.

• Spesifikasi keperluan sistem Dokumen ini dinyatakan dalam bentuk model-model. Dokumen ini dilihat dari perspektif pembangun sistem. Ianya meliputi keperluan fungsian; menyatakan servis sistem dan kekangan dengan terperinci. Keperluan bukan fungsian juga boleh diperincikan di sini.

Spesifikasi

• Spesifikasi rekabentuk perisian

Dokumen ini dinyatakan dalam bentuk model-model, penjelasan abstrak bagi rekabentuk perisian. Sebahagian penulis, mendokumenkan terus spesifikasi rekabentuk perisian di dalam dokumen rekabentuk ini.

Secara umum, organisasi bagi dokumen Keperluan Perisian adalah seperti berikut (Sommerville, 2001):

1 Pengenalan 1.1 Tujuan dokumen keperluan 1.2 Skop produk 1.3 Takrifan, akronim dan abreviasi 1.4 Rujukan 1.5 Ringkasan dokumen

2 Penerangan Umum 2.1 Perspektif produk 2.2 Fungsi-fungsi produk 2.3 Ciri-ciri pengguna 2.4 Kekangan umum 2.5 Andaian dan kebergantungan

3 Keperluan Spesifik 3.1 Takrifan keperluan pengguna

3.1.1 servis yang disediakan untuk pengguna

ISBN 978-983-41293-6-1

62


3.1.2 keperluan bukan fungsian sistem 3.2 Senibina Sistem. 3.3 Spesifikasi keperluan sistem. 3.4 Model sistem (terdiri daripada rajah konteks, rajah

aliran data, model objek). 4 Apendiks

Format yang di atas hanyalah satu panduan. Jika penyelia anda telah menyediakan panduan, anda perlu mengikutinya. Jika tidak, selain daripada yang di atas, anda boleh juga mengikut panduan yang disediakan oleh IEEE atau mana-mana buku Kejuruteraan Perisian. Tiga perkara dalam dokumen keperluan perisian yang akan dibincangkan dengan lebih lanjut dalam bahagian ini ialah; Senibina Sistem, Spesifikasi Keperluan Sistem dan Model Sistem. Sekiranya anda menyediakan dokumen teknikal ini dalam suatu penulisan ilmiah seperti disertasi atau tesis, maka dokumen keperluan perisian boleh berada bersama dengan bab bagi dokumen proses bisnes semasa dan pernyataan keperluan. Namun, jika jumlah muka surat terlalu tebal, iaitu mencecah 50 muka surat, lebih baik sekiranya anda pecahkan bab tersebut kepada dua bab yang berasingan. Bagi kes pembinaan suatu sistem atau aplikasi yang menggunakan satu algoritma atau formula saintifik khusus, maka anda perlu menceritakan dengan terperinci berkenaan algoritma atau formula tersebut dalam bab ketiga ini juga. Model dan Notasi bagi Spesifikasi Keperluan dan Spesifikasi Rekabentuk Perisian Sistem dimodelkan daripada perspektif yang berbeza. Bagi setiap perspektif tersebut, terdapat beberapa jenis model yang sesuai digunakan. Perspektif tersebut boleh dibahagikan kepada empat iaitu:

• perspektif luaran. • perspektif dinamik; juga dikenali sebagai perspektif kelakuan sistem. • perspektif statik. • perspektif maklumat.

Kedua-dua perspektif statik dan maklumat juga dikenali sebagai perspektif struktur sistem. Bagi setiap jenis model, terdapat notasi yang standard bagi menyatakannya. Secara umumnya notasi bagi menyatakan model boleh dikelaskan kepada empat berdasarkan bentuknya iaitu seperti dalam Jadual 3.1.

ISBN 978-983-41293-6-1

63


Jadual 3.1: Bentuk Notasi Bagi Spesifikasi Keperluan Sistem Bentuk

Notasi/Bahasa Spesifikasi

Pendekatan Contoh Notasi

Bahasa tabii berstruktur

• Menggunakan bentuk standard atau templat

VORD template

Bahasa penerangan rekabentuk

• Menggunakan bahasa seperti bahasa pengaturcaraan dengan fitur abstrak

Program Description Language (PDL)

• Menakrif model operasian sistem

Notasi bergrafik • Bahasa bergrafik, ditambah dengan anotasi teks

• Menakrif keperluan fungsian sistem

VORD Event scenario UML Use-case

Spesifikasi bermatematik

• Menggunakan notasi berasaskan konsep matematik seperti mesin keadaan-terhingga dan set.

Z Specification VDM

Manakala notasi bagi jenis model yang mewakili keempat-empat perspektif disenaraikan seperti dalam Jadual 3.2 hingga Jadual 3.5.

Jadual 3.2: Notasi Bagi Model Berdasarkan Perspektif Luaran Jenis dan Peranan Model Notasi untuk Spesifikasi

Keperluan dan Rekabentuk Model Konteks; • Memodelkan persekitaran atau

konteks sistem.

• Rajah Konteks

• Menunjukkan hubungan sistem dengan komponen luaran.

Jadual 3.3: Notasi Bagi Model Berdasarkan perspektif Dinamik

Jenis dan Peranan Model

Notasi untuk Spesifikasi Keperluan dan Rekabentuk

Model pemprosesan data; • Memodelkan bagaimana data

diproses dalam fasa yang berbeza.

• Rajah Aliran Data • Rajah Peralihan

Keadaan • Rajah Kes Guna • Rajah Interaksi • Rajah Urutan • Rajah Aktiviti • Bahasa spesifikasi

formal

ISBN 978-983-41293-6-1

64


Jadual 3.4: Notasi Bagi Model Berdasarkan Perspektif Statik

Jenis dan Peranan Model Notasi untuk Spesifikasi Keperluan dan Rekabentuk Model senibina; • Rajah Dekomposisi • Menunjukkan sub-sistem bagi

sistem.

Jadual 3.5: Notasi Bagi Model Berdasarkan Perspektif Maklumat Jenis dan Peranan Model Notasi untuk Spesifikasi Keperluan dan Rekabentuk Model Komposisi; • Rajah Hubungan Entiti • Memodelkan bagaimana entiti

sistem terdiri daripada entiti lain. • Kamus Data

Model Klasifikasi; • Hirarki/ Kelas Objek • Memodelkan bagaimana entiti

mempunyai ciri-ciri yang sama. • Rajah Kelas

Apabila menyediakan dokumen spesifikasi, maka sebaiknya anda nyatakan:

• perspektif bagi model yang dihasilkan itu. • jenis model yang digunakan. • notasi yang digunakan.

Apabila anda memodelkan perisian, pilih sekurang-kurangya satu notasi bagi setiap perspektif. Pilih notasi yang bersesuaian dengan tabii projek anda. Juga diingatkan kembali, notasi yang anda gunakan mestilah notasi yang berada dalam metod yang telah anda pilih. Jenis model dan notasi yang dinyatakan dalam jadual di atas adalah yang biasa diajar di peringkat sarjanamuda. Namun, terdapat pelbagai lagi jenis model dan notasi yang tidak disenaraikan dalam buku ini. Bagi kes algoritma atau formula saintifik, maka notasi yang disenaraikan dalam Jadual 3.1 hingga 3.5 di atas tidak begitu sesuai digunakan. Anda boleh gunakan sahaja bahasa tabii, formula saintifik berkaitan serta rajah-rajah grafikal yang dapat membantu anda menjelaskan dengan lebih lanjut berkenaan algoritma tersebut.

ISBN 978-983-41293-6-1

65


MENYEDIAKAN DOKUMEN REKABENTUK PERISIAN RekabentukRekabentuk

Setelah anda menghasilkan spesifikasi keperluan, tindakan yang seterusnya adalah untuk menghasilkan rekabentuk. Dokumen rekabentuk ini biasanya menjadi satu bab tersendiri dalam penulisan ilmiah anda. Seperti yang telah dinyatakan sebelum ini, rekabentuk tidak terperinci atau disebut juga spesifikasi rekabentuk, boleh dinyatakan dalam spesifikasi keperluan. Manakala rekabentuk terperinci dinyatakan dalam dokumen yang seterusnya. Namun lebih baik, jika anda terus hasilkan dokumen terperinci agar tidak keliru dengan spesifikasi keperluan. Strategi dalam merekabentuk perisian Anda boleh menggunakan strategi bagi menghasilkan satu rekabentuk perisian; strategi umum atau strategi khusus, yang juga dikategorikan sebagai metod. Sekiranya anda memilih menggunakan metod tertentu, maka pastikan anda menggunakan metod tersebut dengan betul. Ini boleh dilakukan kerana metod mempunyai set notasinya sendiri yang perlu anda patuhi. Jadual 3.6 menyenaraikan metod yang boleh anda gunakan untuk mereka bentuk perisian.

Jadual 3.6: Metod Reka bentuk Perisian Metod Penerangan

Pecah-dan-Jajah dan Penghalusan Langkah demi langkah Strategi Atas-bawah lawan Bawah-Atas Abstraksi Data dam Penyembunyian Maklumat Penggunakan Heuristik Penggunaan Patern dan Bahasa Patern

Strategi Umum

Penggunaan Pendekatan Iteratif dan Incremental Rekabentuk Berorientasi Fungsi

Pendekatan yang digunakan ialah dekomposisi rekabentuk berpusat kepada mengenalpasti fungsi-fungsi utama bagi perisian dan memperincikan fungsi tersebut dalam gaya atas-bawah.

(Rekabentuk Berstruktur)

Rekabentuk begini biasanya menghasilkan Rajah Aliran Data dan Penjelasan Proses yang berkaitan serta Carta Struktur.

Rekabentuk Berorientasi Objek

Pendekatan ini berasaskan pengecaman kepada objek yang terlibat (kata nama = objek; kata perbuatan = metod; kata sifat = atribut). Pewarisan dan polimorfisma adalah peranan utama.

Rekabentuk Berpusatkan Struktur

Rekabentuk ini bermula daripada struktur data yang akan dimanipulasi oleh aturcara. Bukannya fungsi

ISBN 978-983-41293-6-1

66


Data yang dilaksanakan oleh aturcara. Struktur data bagi input dan output dikenalpasti (contohnya menggunakan Rajah Struktur Jackson) dan kemudian membangunkan struktur kawalan bagi aturcara Rajah Struktur Data tersebut.

Rekabentuk Berasaskan Komponen

Dalam pendekatan ini, komponen perisian dilihat sebagai satu unit yang bebas. Apabila membina komponen, ciri boleh guna-semula perlu diberi perhatian. Metod Formal dan Rigorous Lain-lain Metod Metod Transformational

Memilih notasi bagi rekabentuk perisian Notasi yang anda pilih bagi menjelaskan rekabentuk perisian perlulah berkait dengan metod yang anda pilih. Seperti juga spesifikasi keperluan dan rekabentuk, jenis notasi dibahagikan mengikut pandangan rekabentuk iaitu; pandangan statik dan pandangan dinamik. Dalam menghasilkan dokumen rekabentuk perisian, anda perlu menyatakan kedua-dua pandangan ini. Tidak banyak pilihan bagi menggambarkan konteks bagi sistem yang ingin dibangunkan. Satu notasi yang popular adalah seperti dalam Jadual 3.7. Notasi dan bahasa dalam Jadual 3.8 digunakan untuk menjelaskan kelakuan dinamik perisian dan komponennya. Kebanyakan notasi ini berguna semasa menyatakan rekabentuk terperinci. Kebanyakan notasi bagi menyatakan ciri statik perisian adalah dalam bentuk grafik. Notasi ini menyatakan dan mewakili aspek struktur bagi rekabentuk perisian, iaitu menjelaskan berkenaan komponen utama dan bagaimana ianya berhubungan. Lihat jadual 3.9 dan 3.10.

Jadual 3.7: Notasi Bagi Model Berdasarkan Perspektif Luaran Jenis dan Peranan Model Notasi untuk

Rekabentuk Terperinci Model Konteks; Memodelkan persekitaran atau konteks sistem. Menunjukkan hubungan sistem dengan komponen luaran.

• Rajah Konteks

ISBN 978-983-41293-6-1

67


Jadual 3.8: Notasi Bagi Model Berdasarkan Perspektif Statik Jenis dan Peranan Model

Notasi untuk Rekabentuk Terperinci

Model senibina; • Bahasa Penerangan Senibina Menunjukkan sub-sistem bagi sistem.

• Bahasa Penerangan Antaramuka

• Rajah Komponen • Kad CRC • Rajah Deployment • Rajah Struktur

Jackson • Carta Struktur

Jadual 3.9: Notasi Bagi Model Berdasarkan Perspektif Maklumat

Jenis dan Peranan Model


Model Komposisi; Memodelkan bagaimana entiti sistem terdiri daripada entiti lain.

• Rajah Hubungan Entiti

Model Klasifikasi; Memodelkan bagaimana entiti mempunyai ciri-ciri yang sama.

• Rajah Kelas • Rajah Objek

Jadual 3.10: Notasi Bagi Model Berdasarkan perspektif Dinamik Jenis dan Peranan Model


Model pemprosesan data; Memodelkan bagaimana data diproses dalam fasa yang berbeza.

• Rajah Aliran Data • Rajah Peralihan

Keadaan • Rajah Carta

Keadaan • Rajah Kolaborasi • Rajah Urutan • Rajah Aktiviti • Rajah dan Jadual

Keputusan • Carta Alir • Kod-Pseudo

Setelah anda mengetahui pelbagai perspektif dan notasi yang mewakili perspektif tersebut, maka dicadangkan organisasi bagi dokumen Rekabentuk Perisian adalah seperti berikut:

ISBN 978-983-41293-6-1

68


1 Pengenalan 1.1 Tujuan dokumen rekabentuk 1.2 Skop produk 1.3 Takrifan, akronim dan abreviasi 1.4 Rujukan 1.5 Ringkasan dokumen

2 Penerangan Umum 2.1 Kekangan umum 2.2 Andaian dan kebergantungan

3 Model Rekabentuk 3.1 Model Pandangan Luaran 3.2 Model Pandangan Dinamik 3.3 Model Pandangan Statik 3.4 Model Pandangan Maklumat

4 Apendiks Format yang di atas hanyalah satu cadangan. Anda perlu menggunakan cadangan atau panduan yang dinyatakan oleh penyelia atau institusi tempat anda belajar, sekiranya ada. Bagaimana pula dokumen rekabentuk jika anda mengimplemen satu algoritma? Kebiasaannya algoritma tersebut adalah salah satu fungsi terpenting dalam perisian yang dibina. Andaikan Ahmad membina perisian yang boleh diilustrasikan seperti rajah 3.9. Ilustrasi perisian ini tidak mengikuti mana-mana notasi piawai. Ini hanyalah lukisan penulis. Perhatikan dalam perisian tersebut terdapat pelbagai proses, yang mana salah satunya adalah proses X. Andaikan proses X ini adalah satu algoritma yang kompleks manakala proses lain adalah proses biasa seperti proses cetak dan buka fail.

ProsesX

ProsesX

Maka dalam dokumen rekabentuk ini Ahmad bukan sahaja perlu

Rajah 3.9: Ilustrasi MyPerisian

menjelaskan rekabentuk perisian, tetapi juga rekabentuk bagi algoritma proses X tersebut. Oleh kerana algoritma adalah hampir kepada pengaturcaraan, maka Ahmad boleh gunakan pseudokod untuk menjelaskannya. Selain itu struktur data yang digunakan seperti: tatasusunan, senarai pepaut, jadual cincang dan seumpamanya, juga perlu dinyatakan di sini.

ISBN 978-983-41293-6-1

69


Dokumen rekabentuk ini boleh berada dalam bab selepas bab spesifikasi. Namun, ia bergantung juga kepada jumlah muka surat yang terhasil. Jika ianya terlalu tebal, lebih baik anda dokumenkan ia dalam bab tersendiri. Senarai semak dokumen spesifikasi keperluan dan rekabentuk Apakala saja anda telah menyiapkan dokumen spesifikasi mahupun rekabentuk, satu perkara yang mesti anda lakukan adalah menyemak spesifikasi dan rekabentuk yang dihasilkan. Perkara utama yang perlu disemak ialah; • penggunaan notasi yang betul. • keseimbangan rekabentuk. Kedua-dua isu ini akan dibincangkan dalam bab empat. MENYEDIAKAN DOKUMEN IMPLEMENTASI ImplementasiImplementasi Dokumen implementasi adalah berkenaan perlaksanaan perisian. Tiada model piawai untuk mewakili perlaksanaan perisian. Namun begitu, tiga aspek yang boleh dipertimbangkan bagi mewakili perlaksanaan perisian ialah: • kod sumber perisian; iaitu aturcara atau lebih baik lagi pseudokod. • langkah-langkah instalasi; ini termasuk langkah-langkah yang diperlukan

untuk mengkonfigurasi perisian. • perlaksanaan dan penggunaan; seperti panduan pengguna. Kod Sumber Perisian Sekiranya sistem anda mengimplemen satu algoritma khas, maka algoritma tersebut perlu dinyatakan dalam dokumen ini. Sekiranya anda tidak menggunakan sebarang algoritma khas, sebaliknya satu proses yang rumit telah anda hasilkan, maka algoritma proses yang rumit itu perlu dijelaskan dalam dokumen ini. Algoritma ini boleh dinyatakan dalam bentuk pseudokod atau carta alir. Berbanding dengan algoritma yang dinyatakan dalam dokumen rekabentuk, algoritma yang dinyatakan dalam bab implementasi adalah lebih terperinci, sehingga menjelaskan pembolehubah penting yang terlibat. Selain itu, anda perlu juga menyatakan semua takrifan struktur data penting yang telah dibina. Struktur Fail Selain daripada fail aturcara sumber, suatu perisian yang besar biasanya melibatkan beberapa jenis fail yang lain dan disimpan dalam direktori yang berbeza. Contohnya, bagi Sistem Pemarkahan Aturcara C, terdapat beberapa kategori fail yang perlu dijana dan dicapai iaitu: fail nota, fail skema jawapan, fail

ISBN 978-983-41293-6-1

70


soalan, fail jawapan dan fail markah. Fail ini perlu distrukturkan simpanannya. Sekiranya fail disimpan dalam satu direktori sahaja, maka penamaannya perlu dijelaskan. Contohnya

Penamaan bagi fail jawapan pelajar adalah: <nombor matrik>.<x><y> yang mana x adalah nombor bab dan y adalah nombor soalan dalam bab tersebut.

Jika ia disimpan dalam direktori yang berbeza, maka strukturnya perlu ditunjukkan. Rajah 3.10 menunjukkan struktur fail bagi kes ini.

Rajah 3.10: Struktur Fail bagi Sistem Pemarkahan Aturcara C Langkah-langkah Instalasi Sekiranya perisian yang anda bangunkan memerlukan konfigurasi yang khas dan langkah-langkah khusus untuk dilancarkan, maka anda perlu nyatakan konfigurasi tersebut. Contohnya, bagi satu aplikasi yang melibatkan pemprosesan selari, anda perlu nyatakan bagaimana untuk mengkonfigur perisian dan perkakasan yang terlibat. Boleh juga anda andaikan pernyataan ini seperti fail readMe. Kandungan dalam readMe file seperti yang dicadangkan oleh (Engst tanpa tarikh) berikut:

Bab 1

Soalan 1 Soalan ke-mNota

SkemaJawapan

JawapanSoalan

Pelajar 1 Pelajar 2 Pelajar n…

… …

markah

Subjek C

KandunganBab ke-y…… …

Sepertisubdirektori

Soalan 1

Sepertisubdirektori

Bab 1

Bab 1

Soalan 1 Soalan ke-mNota

SkemaJawapan

JawapanSoalan

Pelajar 1 Pelajar 2 Pelajar n…

… …

markah

Subjek C

KandunganBab ke-y…… …

Sepertisubdirektori

Soalan 1

Sepertisubdirektori

Bab 1

ISBN 978-983-41293-6-1

71


Nama Produk dan nombor versi Nama Organisasi Perkara baru dan istimewa dalam keluaran ini Keperluan perkakasan dan perisian Arahan instalasi dan konfigurasi Tip memulakan dan dokumentasi Masalah-masalah yang mungkin dialami Sejarah versi Maklumat hubungan Tarikh, atau tarikh hakcipta Lain-lain maklumat bersesuaian

Contoh langkah-langkah konfigurasi adalah seperti berikut:

Jika anda biasa menggunakan csh, tambah baris seperti berikut dalam fail .cshrc anda: setenv PVM_ROOT $HOME/pvm3 setenv PVM_ARCH ’$PVM_ROOT/lib/pvmgetarch’ set path=($path $PVM_ROOT/lib) Jika anda biasa menggunakan sh atau ksh, tambah baris seperti berikut dalam fail .profile anda: export PVM_ROOT=$HOME/pvm3 export PVM_DPATH=$HOME/pvm3/lib/pvmd export PVM_ARCH=’$PVM_ROOT/lib/pvmgetarch’ export PATH=$PATH:$PVM_ROOT/lib

Panduan Pengguna Apabila menyediakan dokumen seperti panduan pengguna, perkara yang perlu diliputi adalah:

• antara muka dan labelnya. • arahan penggunaan; bagi fungsi utama jelaskan bagaimana boleh

menggunakannya. • mesej aplikasi; mesej-mesej ralat dan amaran yang dihasilkan oleh

aplikasi perlu disenaraikan dan dijelaskan maksudnya/sebabnya. Paparkan beberapa antaramuka yang utama dan jelas berbeza antaranya bagi perisian anda. Bagi setiap antaramuka tersebut, labelkan seksyen-seksyen utama. Rajah 3.11 berikut adalah contoh satu antaramuka utama bagi Sistem Pengurusan Pusat Sumber.

ISBN 978-983-41293-6-1

72


Ruang kemasukan maklumat bahan

Ruang mengedit abstrak

Senarai bahan

Bar ikon

Bar menu

Rajah 3.11: Contoh antara muka utama

Jelaskan arahan pengguna bagi menggunakan ciri-ciri utama yang disediakan. Senaraikan ciri-ciri sokongan piawai yang ada seperti; save, save as, open, close dan seumpamanya. Terdapat beberapa bentuk arahan pengguna yang diterima pakai oleh pengguna Teknologi Maklumat yang elok anda gunakan. Ayat-ayat ini anda boleh temui dalam kebanyakan manual pengguna mahupun dalam menu bantuan sesuatu perisian. Contoh:

Bagi menyimpan dokumen dengan cepat, klik Save pada toolbar Standard. Bagi menyimpan dokumen dalam lokasi atau format yang berbeza, lakukan langkah-langkah berikut:

1. Pada menu File, klik Save As. 2. Pada kotak File name, tuliskan nama baru bagi fail. 3. Klik senarai Save as type dan kemudian klik format fail yang

anda ingini. 4. Klik Save.

Diingatkan hanya fungsi utama sahaja anda jelaskan dengan terperinci cara menggunakannya. Bagi ciri-ciri umum anda boleh senaraikan cara

ISBN 978-983-41293-6-1

73


menggunakannya dalam bentuk jadual seperti dalam Jadual 3.11, menggunakan arahan ringkas yang standard seperti berikut:

• Menggunakan menu; <File><Save> bermaksud klik menu File, kemudian klik submenu Open.

• Menggunakan ikon; klik Save pada toolbar Standard. • Menggunakan Shortkey; <Ctrl>+<s>; maksud semasa menekan kekunci

Ctrl, tekan pula kekunci s.

Jadual 3.11: Ciri-Ciri Umum Fungsi Langkah-langkah Shortkey

Menyimpan fail <File><Save> <Ctrl>+<s> Mencondongkan teks

Heret mouse atas teks Heret mouse atas teks <Ctrl>+<i> <Format><Font><Font

Style: italic> Adakalanya apabila anda perlu menulis arahan pengguna, beberapa kekunci pada papan kekunci perlu dinyatakan dalam perkataan. Papan kekunci terdiri daripada;

• Kekunci Alfa-Numerik: Terdiri daripada kekunci A hingga Z dan 0 hingga 9; Jika menekan kekunci secara biasa, huruf kecil dihasilkan. Jika menekan kekunci <Shift>, huruf besar dihasilkan. Jika menekan kekunci <Caps Lock>, fungsi kekunci <Shift> diterbalikkan.

• Kekunci Punctuation: Terdiri daripada simbol seperti dalam Jadual 3.12.

• Kekunci "White Space": Terdiri daripada kekunci fungsi <F1> hingga <F12>, <Enter>, <Tab> dan <Space Bar>.

Jadual 3.12: Senarai Istilah Kekunci Punctuation Istilah Melayu Kekunci Istilah Inggeris

Backwards Quote Tanda Kutip Belakang `

Tilt Tilde ~

Exclamation Mark Tanda Seru !

Alias Alias @

Hatch Cincang #

Dollar Sign Tanda dolar $

Percent Peratus %

Up Arrow Panah ke atas ^

ISBN 978-983-41293-6-1

74


Istilah Melayu Kekunci Istilah Inggeris

Ampersand Ampersan &

Asterisk Asterisk *

Open Round Bracket Buka Kurung (

Close round Bracket Tutup Kurung )

Dash Sempang -

Underscore Tanda Pisah _

Equal Sign Tanda Sama Dengan =

Plus sign Tanda Campur/Plus +

Open Square Bracket Buka Kurung Siku [

Close Square Bracket Tutup Kurung Siku ]

Open Curly Bracket Buka Kurung Dakap {

Close Curly Bracket Tutup Kurung Dakap }

Bar Bar |

Reverse Solidus Garis Miring Depan \

Semi-colon Koma Bertitik ;

Colon Titik Bertindih :

Regular Quote Tanda Petik Tunggal ‘

Double Quote Tanda Petik “

Comma Koma ,

Less Than/Open Sharp Bracket

Kurang Daripada/Buka Kurung Sudut

<

Period Noktah .

Greater Than Close Sharp Bracket

Lebih Daripada/Tutup Kurung Sudut

>

Backward Solidus Garis Miring Belakang /

Question Mark Tanda Soal ?

Anda boleh menyenaraikan kesemua mesej yang dihasilkan oleh perisian dengan menggunakan jadual seperti Jadual 3.13. Mesej ini biasanya terdiri daripada mesej ralat dan amaran. Jadual 3.13 adalah satu contoh senarai mesej dan keterangan berkenaannya.

ISBN 978-983-41293-6-1

75


Jadual 3.13: Contoh Senarai dan Keterangan Mesej Mesej Keterangan

Fail tidak dijumpai. Fail input kepada perisian tidak ditemui. Ini mungkin disebabkan ejaan nama fail yang berbeza, atau fail tidak disediakan.

Ralat leksikal: <no.> <pengecam>. <pengecam> dalam baris <no.> mengandungi ralat leksikal. Semak peraturan leksikal untuk pembetulan.

Ralat sintaksis: <no.> <ungkapan> <ungkapan> dalam baris <no.> mengandungi ralat sintaksis. Semak nahu untuk pembetulan.

Ralat semantik: <no.> <ungkapan> <ungkapan> dalam baris <no.> mengandungi ralat semantik. Semak peraturan semantik untuk pembetulan.

Storan jadual melimpah: <no.> <pengecam>

Bilangan token dalam fail input melebihi saiz storan yang disediakan. Token hanya dapat disimpan bagi <pengecam> dalam baris <no.>. Kurangkan bilangan token.

Storan rentetan melimpah: <no.> <rentetan>

Saiz rentetan <rentetan> pada baris <no.> terlalu panjang. Kurangkan saiznya.

Timbunan semantik melimpah: <no.> <ungkapan>

Timbunan semantik hanya dapat digunakan sehingga <ungkapan> pada baris <no.>.

ISBN 978-983-41293-6-1

76


MENYEDIAKAN DOKUMEN PENGUJIAN Pengujian Setelah sistem anda siap, maka ianya perlu diuji. Anda perlu tahu dan sedar akan tujuan pengujian dan bagaimana ianya boleh dilakukan. Seterusnya yang paling penting dalam konteks anda ialah apakah yang perlu didokumenkan. Terdapat dua isu; proses pengujian dan hasil pengujian. Adakah pengujian bagi menyemak ralat sintaks? Adakah ralat-ralat yang terhasil itu perlu direkodkan? Kenapa ingin direkodkan sedangkan ralat tersebut telah dihapuskan? Jika tidak direkodkan, apa lagi perkara dalam pengujian yang perlu direkodkan? Oleh kerana dokumen pengujian adalah antara dokumen yang terakhir, kerap kali pelajar menyediakannya sambil lewa atau langsung tidak menyediakannya. Walaupun anda telah kepenatan menyediakan beberapa dokumen yang lebih penting sebelumnya, anda harus mempunyai momentum untuk meneruskan penyediaan dokumen pengujian ini. Dengan adanya dokumen pengujian, ianya dapat memberi keyakinan kepada anda semasa pembentangan lisan projek ini kelak. Terdapat segelintir pelajar yang begitu risau apabila penilai memberikan data ujian secara rambang bagi menguji perisian mereka. Sekiranya anda mengikuti teknik pengujian yang telah dipelajari, anda pasti yakin semasa pembentangan lisan kelak. Pengujian dilakukan pada paras pengujian yang berbeza iaitu:

• Pengujian Unit/ Pengujian Komponen/ Pengujian Modul; untuk mengesahkan yang komponen berfungsi betul berdasarkan jenis input seperti mana dinyatakan dalam rekabentuk komponen.

• Pengujian Integrasi; untuk mengesahkan komponen sistem bekerja bersama seperti mana dijelaskan dalam spesifikasi sistem dan rekabentuk aturcara.

• Pengujian Fungsi; untuk memastikan yang sistem mempunyai kefungsian seperti mana yang dijelaskan dalam spesifikasi keperluan.

• Pengujian Ketrampilan; untuk memastikan yang keperluan bukan fungsian sistem dipenuhi.

• Pengujian Penerimaan; untuk memastikan yang sistem bertugas seperti mana jangkaan pelanggan.

Dokumentasi satu proses pengujian perisian adalah bertujuan untuk menunjukkan bukti apakah pengujian yang telah diliputi oleh sistem ini. Pembaca dokumen ingin melihat paras pengujian yang telah dilakukan. Sekiranya anda telah menjalankan pengujian komponen, maka yang berikut perlu didokumenkan:

• Senaraikan komponen-komponen yang telah diuji.

ISBN 978-983-41293-6-1

77


• Senaraikan input-input yang digunakan. Pemilihan input mesti merujuk kepada dokumen rekabentuk komponen.

• Sekiranya komponen tidak berfungsi seperti yang dinyatakan dalam rekabentuk komponen, dan anda tidak membetulkannya, nyatakan sebabnya.

• Nyatakan juga paras pengujian yang tidak anda liputi dan berikan alasan. Begitu juga dengan paras pengujian yang lain, anda perlu nyatakan apa yang telah dilakukan, dan bagaimana hasilnya. ORGANISASI LAIN BAGI DOKUMEN TEKNIKAL Seperti yang telah dinyatakan pada awal bagi, sekiranya anda menggunakan teknik tertentu dalam menghasilkan perisian, maka organisasi dokumen teknikal anda mungkin berbeza. Katakan Ahmad membangunkan penyemak struktur bagi Spesifikasi Z untuk projek beliau. Ahmad menggunakan teknik pemprosesan bahasa untuk membangunkan perisian tersebut. Teknik pemprosesan bahasa mempunyai fasa-fasanya tersendiri seperti yang ditunjukkan dalam Rajah 3.12.

Pengurus Jadual-Jadual Simbol

Pengendali Ralat-Ralat

Penganalisa Leksikal

Pengoptimum

Penjana Kod

Penganalisa Sintaksis

Penganalisa Semantik

Penjana Kod Pertengahan

Rajah 3.12: Senibina Pemprosesan Bahasa

ISBN 978-983-41293-6-1

78


Oleh kerana Ahmad hanya membuat penyemak struktur, maka hanya sebahagian fasa sahaja yang diliputi dalam pembangunan projek beliau iaitu sehingga fasa penganalisa sintaksis. Sehubungan itu, organisasi bagi dokumen teknikal Ahmad boleh mengikut jujukan fasa yang tersebut seperti berikut:



Penjana Kod

Pengendali Ralat

Implementasi

Pengujian





Penjana Kod

Pengendali Ralat

ImplementasiImplementasi

Pengujian

Kesimpulannya, anda tidak boleh mengikut sewenang-wenangnya amalan yang sedia ada. Sebaliknya anda perlu memastikan organisasi, teknik mahupun metod yang digunakan bersesuaian dengan tabii projek anda.

ISBN 978-983-41293-6-1

79

Bab Ketiga Menulis Aspek Teknikal Projek - ftsm.ukm.my · Rekabentuk Perisian ... Menulis Aspek...

Documents

Transcript of Bab Ketiga Menulis Aspek Teknikal Projek - ftsm.ukm.my · Rekabentuk Perisian ... Menulis Aspek...