KERTAS PENERANGAN KPD 1013_K3.pdf

BAHAGIAN PENDIDIKAN DAN LATIHAN TEKNIKAL VOKASIONAL KEMENTERIAN PENDIDIKAN MALAYSIA ARAS 5 & 6, BLOK E14, KOMPLEKS E, PU...

BAHAGIAN PENDIDIKAN DAN LATIHAN TEKNIKAL VOKASIONAL KEMENTERIAN PENDIDIKAN MALAYSIA ARAS 5 & 6, BLOK E14, KOMPLEKS E, PUSAT PENTADBIRAN KERAJAAN PERSEKUTUAN KERTAS PENERANGAN (INFORMATION SHEET) KOD DAN NAMA IT-010-3:2016 APPLICATION DEVELOPMENT PROGRAM TAHAP DAN SEMESTER 3 (SEMESTER 1) KOD DAN TAJUK KPD 1013 INTRODUCTION TO APPLICATION SYSTEM KURSUS DEVELOPMENT NO.DAN TAJUK K3 STRUCTURE THE SYSTEM REQUIREMENT KOMPETENSI NO. KOD KSKV KPD1013 / KP(3/4) Muka Surat : 1 Drp : 14 NO. KOD NOSS IT-010-3:2016-C01/ P(3/4) TAJUK/TITLE : STRUCTURE THE SYSTEM REQUIREMENT TUJUAN/PURPOSE : Kertas penerangan ini adalah bertujuan menerangkan mengenai : 1. Konsep kejuruteraan keperluan (RE) 2. Menerangkan kaedah yang sesuai bagi keperluan sistem 3. Menentukan fungsi Keperluan Software Spesifikasi (SRS) mengikut standard 4. Pengenalan kepada Pengurusan Projek 5. Keperluan perlaksanaan aliran aplikasi mockup prototaip 6. Kaedah Pengujian unit dan kebolehgunaan  Muka Surat / Page : 2 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 PENERANGAN/INFORMATION : 3.1 Overview of Requirement Engineering (RE) Konsep Kejuruteraan Keperluan Kejuruteraan Keperluan ialah proses mengenal pasti perkhidmatan/servis dan kekangan sistem yang hendak dibangunkan. Kejuruteraan keperluan boleh ditakrifkan sebagai proses mengenal pasti, menganalisis dan memodelkan keperluan perisian. Keperluan perisian perlu mengenal pasti fungsi-fungsi yang perlu pada sistem tanpa mengambil kira bagaimana ia akan dilaksanakan. Empat aktiviti utama dalam kejuruteraan keperluan iaitu: i. Mengenal pasti keperluan/elisitor (elicitation) (Requirements Elicitation) Mendapatkan maklumat keperluan sistem dan memahami kehendak pengguna terhadap sistem yang hendak dibangunkan. ii. Keperluan analisis (Requirements Analysis) Menganalisis setiap keperluan yang telah dikumpulkan. Hasil analisis akan diterjemahkan dalam bentuk model. iii. Takrifan dan keperluan spesifikasi (Requirement Specification) Merekodkan keperluan sistem dengan jelas dan terperinci dalam bentuk dokumen iv. Penentusahan keperluan/ pengurusan keperluan (Requirements Management) Memastikan spesifikasi keperluan adalah sama dengan keperluan sistem yang sebenar, memenuhi piawaian dan boleh digunakan sebagai asas bagi reka bentuk peringkat awal. Dalam konteks pembangunan perisian, kejuruteraan keperluan adalah proses yang pertama sekali dilaksanakan. Rajah di bawah menunjukkan proses kejuruteraan keperluan. Apa yang berlaku jika Keperluan Kejuruteraan adalah salah? 1. Menyebabkan sistem yang dibina dan diserahkan lambat dan kos yang lebih daripada yang dijangkakan. 2. Pelanggan dan pengguna akhir tidak berpuas hati dengan sistem disebabkan tidak dapat menggunakan kemudahakan sistem mengikut perjanjian yang dipersetujui. 3. Sistem ini mungkin tidak boleh dipercayai dan terdedah kepada kesilapan dan tergendala 4. Berlaku kesilapan sistem tetap dan kemalangan yang boleh mengganggu operasi normal syarikat.  Muka Surat / Page : 3 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 5. Jika sistem tersebut terus digunakan, kos penyelenggaraan dan perkembang sistem adalah sangat tinggi. 6. Reputasi kakitangan IT dalam pasukan dipengaruhi kerana sebarang kegagalan, tidak kira siapa yang bersalah, akan dilihat sebagai satu kesilapan oleh pasukan. Siapakah yang terlibat dengan RE adalah bergantung kepada projek kerumitan satu pasukan:  Jurutera Perisian (Software Engineer)  Penganalisa Sistem (System Analyst)  Penganalisa Perniagaan (Business Analyst)  Keperluan Penentu (Requirements Specifier)  Keperluan Penilai (Requirements Reviewer)  Pemegang Berkepentingan Lain (Other Stakeholders) 3.1.1 Mengenal Pasti Keperluan / Elisitor ( Requirement Elicitation) 1. Mengenal pasti keperluan merupakan langkah pertama bagi Keperluan dalam Kejuruteraan. 2. Ia meliputi aktiviti mendapatkan keperluan daripada pengguna ataupun diperolehi daripada keperluan sistem. Rajah di bawah menunjukkan gambaran mengenai proses Mengenal Pasti Keperluan. 3. Keperluan yang dikenalpasti boleh dibahagikan kepada dua kategori, i. Keperluan Fungsi ii. Keperluan bukan Fungsi. 4. Keperluan Fungsi ialah huraian mengenai fungsi atau perkhidmatan/servis sistem. a. Contoh keperluan fungsi bagi Sistem Pendaftaran Pelajaran Melalui Internet ialah:  Antara muka pengguna yang digunakan ialah Windows 10 atau yang serasi dengannya  Pengguna akan diberi pilihan-pilihan berikut:.....  Jika bekalan elektrik terputus secara tiba-tiba, dokumen yang belum disimpan boleh dicapai semula. 5. Keperluan bukan Fungsi ialah huraian mengenai kekangan yang ada pada sistem. i. Contoh keperlua bukan Fungsi bagi Sistem Pendaftaran Pelajaran Melalui Internet ialah:  Masa penghantaran data sekurang-kurangnya 1Mb sesaat.  Masa tindak balas bagi pendaftaran mata pelajaran ialah 3 saat  Reka bentuk sistem hendaklah berasaskan kaedah UML. 6. Keperluan bukan Fungsi boleh diklasifikasikan kepada tiga jenis iaitu: i. Keperluan Produk  Muka Surat / Page : 5 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Keperluan yang menentukan keadaan tertentu tingkah laku seperti masa pelaksanaan, kebolehpercayaan dan sebagainya. ii. Keperluan Organisasi Keperluan yang merupakan rentetan daripada dasar dan prosedur organisasi seperti proses piawai, keperluan pelaksanaan dan sebagainya. iii. Keperluan Luaran Keperluan yang terbit daripada faktor luaran sistem dan proses pembangunan seperti keperluan untuk membolehkannya berinteraksi dengan sistem luaran, keperluan undang-undang dan sebagainya. 7. Keperluan Perisian i. Analisis hubungan yang merupakan input untuk menyediakan takrifan keperluan ii. Pada peringkat ini, pembangun perlu memahami persekitaran bagi sistem perisian yang akan dibangunkan iii. Bagaimana sistem akan berinteraksi dengan persekitarannya. iv. Keperluan Perisian merupakan Keperluan bukan Formal dan mempunyai maklumat yang terlalu terperinci. v. Keperluan perisian perlu mengandungi ciri-ciri penting yang perlu ada pada sesuatu produk perisian, keputusan dari analisis pasaran dan sebagainya. 8. Keperluan Pengguna i. Merupakan satu proses analisis hasil daripada kehendak persekitaran dan maklumat-maklumat yang diperolehi daripada pengguna, pakar bidang dan pelanggan. ii. Mekanisme yang digunakan seperti temu ramah, borang soal selidik dan pemerhatian ke atas persekitaran pengoperasian. iii. Bagi mengesahkan ketepatan hasil analisis, pembangun menyampaikan dalam bentuk yang mudah difahami oleh pemberi maklumat. iv. Penyampaian dalam bentuk dokumen ringkas, senario, prototaip atau model  Muka Surat / Page : 6 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 9. Keperluan dari Sistem Lain i. Pembangun perlu mendapatkan keperluan sistem dengan menemu ramah pengguna sistem yang berinteraksi dengan sistem yang akan dibangunkan. 10. Keperluan Antara Muka i. Pembangun perlu mendapatkan keperluan bagi membangunkan antara muka pengguna. ii. Keperluan interaksi di antara manusia dengan sistem amat penting. iii. Analisis tugas perlu dilaksanakan bagi mendapatkan keputusan secara terperinci mengenai bagaimana pengguna akan berinteraksi dengan sistem yang akan dibangunkan. 11. Kekangan Sistem i. Kekangan proses membangunkan perisian perlu dikenal pasti. ii. Kekangan yang biasa dihadapi ialah kos, ciri-ciri perkakasan yang akan berantara muka dengan sistem, sistem sedia ada yang akan berinteraksi dengan sistem yang akan dibangunkan dan keperluan mudah alih yang lain. 3.1.2 Analisis Keperluan (Requirement Analysis) 1. Analisis Keperluan diperolehi hasil daripada analisis dari pelbagai sumber. 2. Analisis ini diperlukan demi untuk mendapatkan takrifan keperluan yang tepat. 3. Analisis yang dilaksanakan mestilah mencukupi dari segi tahap yang boleh diterima bagi risiko yang berkaitan dengan teknikal dan kos, kesempurnaan, ketepatan dan kurang kesamaran dalam hasil. 4. Pelbagai kaedah analisis yang boleh digunakan dalam membantu proses menganalisis keperluan. 5. Rajah di bawah menunjukkan aktiviti-aktiviti utama dalam Analisis Keperluan:  Muka Surat / Page : 7 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 6. Aktiviti-aktiviti utama dalam Analisis Keperluan ialah: a. Penilaian ke atas Masalah i. Dilaksanakan untuk menilai kemungkinan dan masalah-masalah seperti kesamaran, tidak lengkap dan tidak tekal. ii. Keperluan perisian bagi iii. Sistem yang akan berinteraksi dengannya. b. Klasifikasi Keperluan i. Keperluan perlu dikelaskan mengikut kategori keutamaan seperti “mandatori”, “tidak perlu” atau “penting”. ii. “mandatori” bermakna sistem yang dibangunkan tidak akan diterima oleh pelanggan jika ia tidak memenuhi keperluan tersebut. Ini merupakan keperluan yang wajib ada pada sistem. iii. Keperluan juga dinilai berdasarkan kestabilannya. Pembangun perlu mengelaskan keperluan yang mudah berubah (bergantung kepada perubahan ke atas persekitaran) dan keperluan yang tetap dalam kelas yang berbeza. iv. Keperluan tetap ialah keperluan yang stabil manakala keperluan tidak tetap ialah keperluan yang mungkin berubah semasa sistem dibangunkan atau setelah sistem dibangunkan atau setelah sistem dilaksanakan. v. Keperluan yang tidak tetap boleh dibahagikan kepada empat jenis iaitu:  Muka Surat / Page : 8 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14  Keperluan berubah-ubah  Keperluan yang mudah berubah disebabkan perubahan yang berlaku ke atas persekitaran yang mengubah operasi organisasi.  Contohnya: Sistem rawatan hospital, kaedah rawatan yang digunakan mudah berubah, bergantung kepada jenis penyakit, maklumat rawatan yang berbeza perlu dikumpulkan semula apabila timbulnya kes penyakit yang baru.  Keperluan baru muncul  Keperluan yang baru muncul, ekoran daripada kefahaman pelanggan terhadap sistem semasa sistem sedang dibangunkan.  Contohnya: sistem penyimpanan maklumat pesakit, pada asalnya pelanggan (pihak hospital) mungkin hanya menyimpan biodata pesakit dalam bentuk teks sahaja, setelah memahami tentang kemudahan capaian imej dalam pangkalan data, pelanggan mungkin meminta supaya pembangun menyediakan kemudahan penyimpanan imej filem sinar-X dalam bentuk digital.  Keperluan Penting  Keperluan penting yang wujud ekoran daripada perkembangan teknologi maklumat.  Perubahan ini perlu diambil kira kerana akan merubah proses organisasi atau menimbulkan satu cara kerja yang baru.  Contohnya: Sistem penyimpanan imej filem sinar-X pesakit, biasanya filem sinar-X akan dihasilkan bagi setiap pesakit yang menjalani pemeriksaan sinar-X. Filem tersebut kemudiannya diimbas untuk membolehkan imejnya disimpan dalam bentuk digital. Ekoran bentuk digital dapat dihasilkan terus tanpa perlu diimbas dari filemnya. Dengan itu, aktiviti pemeriksaan sinar-X akan berubah.  Keperluan Keserasian  Keperluan Keserasian yang bergantung kepada sistem atau proses dalam organisasi.  Muka Surat / Page : 9 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14  Jika sistem atau proses berubah, keperluan yang serasi dengannya juga perlu diubah.  Contohnya: sistem perisian yang digunakan oleh sesebuah organisasi mestilah serasi dengan sistem pengoperasian yang dipilih.  Jika pihak organisasi bercadang untuk menukar sistem pengoperasiannya, misalnya daripada DOS (Disk Operating Systems) kepada Windows 10, besar kemungkinan sistem perisian yang sedang dibangunkan tidak boleh beroperasi sepenuhnya dengan sistem pengoperasian yang baru. c. Penilaian ke atas Kemungkinan dan Risiko i. Penilaian meliputi kemungkinan teknologi (contohnya, bagaimana keperluan tersebut boleh dipenuhi dengan teknologi terkini), kemungkinan pengoperasian (contohnya, adakah perisian yang dibangunkan boleh digunakan oleh kakitangan yang sedia ada dalam persekitaran yang dirancangkan) dan kemungkinan ekonomi (seperti adakah kos untuk melaksanakan sistem yang akan dibangunkan boleh diterima oleh pengguna) d. Pengesahan Keperluan i. Semua keperluan yang telah dikumpulkan mestilah disemak supaya ia lengkap, tekal dan bertepatan dengan kehendak pengguna. ii. Keperluan-keperluan yang telah dikenal pasti mestilah dilaporkan dalam bentuk yang mudah difahami. iii. Terdapat dua alternatif digunakan untuk melaporkan keperluan sistem iaitu:  Model Analisis  Model-model dibina setelah keperluan dianalisis bagi mentakrifkan ciri-ciri khusus perlu ada pada fungsi sistem yang hendak dibangunkan.  Ia meliputi antara muka di antara setiap fungsi dan antara muka dengan persekitaran.  Dipersembahkan dalam bentuk yang lebih mudah difahami dibandingkan dengan huraian dalam bentuk teks.  Ciri-ciri model yang baik ialah  Mudah difahami dan tidak kompleks  Muka Surat / Page : 10 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14  Murah untuk dibina dan diubah suai jika dibandingkan dengan kos untuk membangunkan sistem sebenar.  Memudahkan huraian yang kompleks daripada keadaan sebenar.  Pelbagai jenis model analisis yang boleh digunakan, antaranya ialah:  Model Aliran Data  Model gabungan  Model objek  Model tindak balas stimulus  Model Aliran Data  Model Aliran Data digunakan untuk menunjukkan bagaimana data diproses pada setiap peringkat.  Teknik yang menggunakan model aliran data ialah DFD (Data Flow Diagram) atau Gambar rajah Aliran Data.  DFD juga dikenali sebagai “carta buih”, satu teknik bergrafik yang menggambarkan aliran maklumat dan juga perubahan bentuk data yang digunakan sebagai pergerakan data daripada input kepada output.  Prototaip  Dibina untuk mendapatkan pandangan daripada pelanggan dan pengguna.  Tujuan pembinaannya adalah untuk mendapatkan pandangan lebih jelas tentang keperluan sistem.  Prototaip dibangunkan jika pengguna sukar menggambarkan secara visual bagaimana perisian beroperasi.  Mekanisme paling efektif untuk menggambarkan keadaan bagaimana sistem seharunya beroperasi.  Prototaip yang dibangunkan akan diserahkan untuk kegunaan pengguna jika perisian melibatkan pelbagai jenis dan kategori pengguna  Prototaip digunakan untuk meminimumkan risiko pembangunan perisian dengan keperluannya yang tidak mencukupi.  Muka Surat / Page : 11 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 3.1.3 Takrifan dan Spesifikasi Keperluan (Requirement Specification) 1. Takrifan Keperluan adalah keterangan berorientasikan pelanggan mengenai fungsi sistem dan desakan terhadap operasi sistem. 2. Spesifikasi Keperluan adalah keterangan yang tepat dan terperinci mengenai fungsi dan desakan sistem. 3. Ia bertujuan sebagai alat komunikasi dan dasar kontrak di antara pembangun sistem dan pelanggan. 4. Spesifikasi Keperluan diwakilkan oleh Model Sistem yang dibina dalam proses Analisis Keperluan. 5. Spesifikasi ini jika ditulis dalam bahasa biasa akan menimbulkan beberapa masalah iaitu: a. Kefahaman penulis dan pembaca b. Pelbagai maksud untuk berbagai-bagai perkataan c. Struktur bahasa 6. Alternatif lain penulisan spesifikasi yang boleh digunakan antaranya ialah: a. Bahasa biasa berstruktur a. Bahasa berperihalan reka bentuk b. Bahasa spesifikasi keperluan c. Notasi grafik d. Spesifikasi Matematik 7. Borang yang menyokong bahasa biasa berstruktur mempunyai spesifikasi tersendiri. Antara ciri spesifikasi ini ialah: a. Takrifan fungsi atau entiti b. Keterangan mengenai input dan dari mana ia datang c. Keterangan mengenai output dan ke mana ia pergi d. Petunjuk kepada entiti-entiti lain yang diperlukan e. Prasyarat dan pascasyarat f. Kesan sampingan 8. Contoh Spesifikasi Keperluan berdasarkan borang  Muka Surat / Page : 12 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 9. Spesifikasi Antara Muka a. Hampir semua sistem beroperasi dalam persekitaran yang memerlukan antara muka dengan sistem-sistem lain. b. Tiga jenis antara muka yang perlu ditakrifkan di dalam spesifikasi keperluan ialah: i. Antara muka Prosedur – beberapa servis diperlukan dari sub-sistem ii. Antara muka Data – Aliran data antara sub-sistem iii. Antara muka Perwakilan – Perwakilan data yang khusus mungkin perlu digunakan. 10. Pengesanan Keperluan a. Pengesanan keperluan adalah suatu ciri spesifikasi keperluan yang menunjukkan keupayaan untuk mengesan keperluan-keperluan yang saling berhubung kait.  Muka Surat / Page : 13 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 b. Alatan CASE menyediakan kemudahan ini dan teknik pengesanan yang biasa digunakan ialah: i. Memberi nombor yang unik untuk setiap keperluan ii. Membina rujuk-silang pada setiap keperluan menggunakan nombor unik iii. Membina matriks rujuk-silang untuk keseluruhan dokumen keperluan. 3.1.4 Pengurusan Keperluan (Requirement Management) 1. Pengurusan keperluan adalah proses mengenal pasti dan kemudian memantau keperluan semua pihak berkepentingan yang terlibat dalam sesuatu projek, dan memastikan bahawa keperluan ini dipenuhi. 2. Ia bertujuan untuk mendapatkan, menyimpan, menyebarkan, dan mengurus maklumat berkaitan dengan keperluan, termasuklah perubahan dan kawalan versi (change and version control), mengesan keperluan (requirement tracing) dan pemantauan status keperluan (requirement status tracking). 3. Salah satu cabaran utama, seorang pengurus projek dalam Pengurusan Keperluan adalah keperluan untuk membuat pelarasan proses-proses apabila berlaku perubahan keperluan. 4. Aspek asas dalam Pengurusan Keperluan adalah keperluan untuk berkomunikasi dengan berkesan. Jika salah satu pihak berkepentingan mengubah sesuatu keperluan, pengurus projek perlu mengenal pasti bagaimana perubahan tersebut memberi kesan kepada keperluan orang lain yang terlibat dalam projek ini dan berbincang tentang perubahan tersebut dengan mereka untuk mendapatkan persetujuan. 5. Pengurus projek mesti mempunyai satu proses untuk mengemaskini keperluan, sama ada dengan mencatat dalam log atau dokumentasi lain atau dengan memasukkan maklumat ke dalam perisian pengurusan projek syarikat atau perisian berasaskan web. Terdapat juga program-program perisian dan aplikasi berasaskan web yang direka khusus untuk pengurusan keperluan Link bagi contoh aplikasi Pengurusan Keperluan ialah: http://rmblog.accompa.com/2012/05/requirements-management-tools/  Muka Surat / Page : 14 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 6. Lima Peringkat Pengurusan Keperluan, pengurus projek dan pihak berkepentingan utama akan menilai keperluan pada setiap langkah proses. Langkah-langkah ini adalah seperti berikut i. Kenalpasti / Siasatan Biasanya, langkah pertama ialah pencarian fakta atau penyiasatan. Matlamat sebenar (goals) perlu dikenalpasti, dan keperluan-keperluan (requirements) yang memenuhi matlamat tersebut dapat ditentukan. Apa- apa halangan atau kekangan yang mungkin wujud perlu dikenalpasti dan cadangkan penyelesaian disediakan. ii. Kemungkinan (Feasibility) Ia melibatkan aktiviti untuk menentukan projek ini boleh dilaksanakan berdasarkan kekangan yang ada seperti kos, sumber manusia, perkakasan dan perisian, keupayaan organisasi dan kepakaran teknologi. iii. Rekabentuk Pada fasa rekabentuk, biasanya akan ada perubahan kepada keperluan yang perlu disampaikan, dipersetujui oleh pihak berkepentingan dan seterusnya ditangani oleh mereka yang bertanggungjawab. Satu lagi bahagian penting dalam pengurusan keperluan adalah menentukan jika perubahan ini akan memberi kesan kepada kos atau skop projek. iv. Pembinaan dan Pengujian Keperluan projek mungkin perlu sedikit perubahan dan penyelarasan semasa peringkat ujian kepada pengurusan keperluan dan perubahan ini hendaklah didokumenkan dengan sewajarnya. v. Penyerahan (Release) Setelah produk itu akhirnya diluluskan, ia dikeluarkan untuk penggunaan. Pada fasa ini, pengurusan keperluan masih berterusan, iaitu untuk naik taraf aplikasi, add-ons, penambahbaikan, dan memenuhi kehendak pemasaran dan jualan. Ini akan didokumenkan dan ditangani semasa fasa pembangunan untuk versi yang seterusnya. 3.2 Function of Software Requirement Spesification (SRS) according to standard Spesifikasi Keperluan Perisian (SRS) adalah perihalan mengenai sistem perisian yang akan dibangunkan. Ia meletakkan keperluan fungsian dan tidak berfungsi, dan mungkin termasuk satu set use case yang menggambarkan interaksi pengguna yang diperlukan oleh perisian tersebut. Kelebihan SRS:  Menetapkan asas untuk perjanjian antara pelanggan dan kontraktor atau pembekal (dalam projek yang dipacu oleh pasaran, peranan ini boleh dimainkan oleh bahagian pemasaran dan pembangunan) mengenai apa yang produk perisian harus dilakukan serta apa yang tidak dijangka untuk melakukan.  Membenarkan penilaian terhadap keperluan sebelum reka bentuk dapat dimulakan dan dikurangkan dengan reka bentuk semula kemudian.  Menyediakan asas yang realistik untuk menganggarkan kos, risiko, dan jadual produk.  Membantu mencegah kegagalan projek perisian. Matlamat khusus SRS adalah: i. Memudahkan ulasan ii. Menggambarkan skop kerja iii. Menyediakan rujukan kepada pereka perisian (iaitu bantuan navigasi, struktur dokumen) iv. Memberi rangka kerja untuk menguji kes-kes penggunaan primer dan sekunder v. Menyediakan platform untuk penambahbaikan berterusan (melalui spesifikasi atau soalan yang tidak lengkap) Rujukan: Software requirements specification https://en.wikipedia.org/wiki/Software_requirements_specification C3P3 Project Brief (Penerangan Projek) 3.3 PENGENALAN KEPADA PENGURUSAN PROJEK Pengurusan projek merupakan satu pengurusan yang melibatkan pembangunan,perubahan dan inovasi dalam kerja operasi. Ia merangkumi aktiviti seperti merancang dan pengawalan sesuatu projek dengan bergantung kepada kekangan belanjawan supaya projek dapat disempurnakan dalam tempoh masa yang ditetapkan. Pengurusan projek merupakan satu disiplin dalam merancang, mengatur,menyelaras serta mengurus sumber-sumber bagi tujuan mencapai serta menjayakan matlamat serta objektif yang ditetapkan bagi pelaksanaan sesuatu projek. 3.3.1 DEFINISI PROJEK Projek didefinasikan sebagai sebagai satu aktiviti operasi yang wujud hanya sekali-sekala dalam tempoh masa yang tertentu. “Projek adalah satu usaha sementara terdiri daripada beberapa siri aktiviti dan tugas yang dibuat untuk mencipta satu produk atau perkhidmatan yang unik.” PMI (Project Management Institute) Projek didefinisikan sebagai satu aktiviti operasi yang wujud hanya sekali sekala dalam tempoh masa yang tertentu. Projek merupakan aktiviti yang besar dan akan mempengaruhi masa depan syarikat. Contohnya seperti projek pembinaan kemudahan, bangunan kilang, pusat membeli belah dan pemasangan sistem komputer. Projek mempunyai objektif yang spesifik yang perlu diselesaikan di dalam spesifikasi tertentu, menentukan tarikh mula dan tamat, dilakukan oleh manusia atau sumber bukan manusia (duit, bahan dll), dirancang, dilaksanakan dan dikawal, dengan sumber yang terhad (budget, orang, peralatan, masa dll yang terhad). Syarikat yang melaksanakan sesuatu projek biasanya akan membahagikan projek mereka kepada beberapa fasa atau peringkat untuk membolehkan kawalan pengurusan yang lebih baik. Semua fasa projek ini dikenali sebagai Kitar Hayat Projek (Project Life Cycle). 3.3.2 Definisi Pengurusan Projek “ Pengurusan projek merupakan satu cabang daripada bidang pengurusan, dimana ianya merupakan gabungan antara perancangan, pengorganisasian, pengarahan dan pengawalan” (The Practice of Construction Management 4 edition - Barry Fryer) Pengurusan projek merupakan satu pengurusan yang melibatkan pembangunan, peribahan dan inovasi dalam kerja operasi. Ia merangkumi aktiviti seperti merancang dan pengawalan sesuatu projek dengan bergantung kepada kekangan belanjawan supaya projek dapat disempurnakan dalam tempoh masa yang ditetapkan.  Muka Surat / Page : 17 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 3.3.3 PROJECT BRIEF CONTENT FOR DEVELOPMENT TIMELINE Selepas proses perancangan, proses penjadualan diperlukan untuk menganggarkan jangkamasa yang diperlukan untuk menyiapkan setiap aktiviti projek. Anggaran tempoh masa menyiapkan projek ditetapkan dengan membuat perbandingan dengan objektif projek syarikat. Dengan kata lain Penjadualan adalah penentuan aktiviti-aktiviti,jangka masa,penjadualan untuk tenaga kerja dan sumbersumber lain (bahan peralatan) yang di perlukan untuk mencapai tarikh siap sesuatu projek. Apakah yang akan berlaku sekiranya masa yang ditetapkan melebihi masa yang dihadkan? Jika keadaan ini berlaku, tempoh persiapan projek mesti dikurangkan samada dengan menambah sumber tenaga kerja atau dengan menggunakan cara lain yang boleh menyiapkan projek dengan cepat. Selain dari menambah sumber tenaga kerja, salah satu cara yang boleh digunakan untuk menyiapkan projek dengan cepat ialah dengan kerja lebih masa (overtime). Dengan cara ini kos menyiapkan projek akan meningkat. Macamana kita mengatasi masalah peningkatan kos, akan dijelaskan pada unit yang seterusnya. Kepentingan Penjadualan Penjadualan perlu dilakukan untuk :- a) Menentukan dan menghubungkaitkan antara aktiviti dengan aktiviti yang lain b) Mengenalpasti hubungan sebelumnya antara aktiviti. Hubungan ini akan ditunjukkan melalui teknik CPM/PERT yang melibatkan graf rangkaian. c) Menetapkan jangkamasa untuk menyiapkan penyenggaraan setiap aktiviti. Anggaran tempoh perlaksanaan projek perlu dibuat untuk mengelak kerugian dari segi masa dan kos. d) Mengoptimumkan penggunaan sumber tenaga dan bahan mentah dengan lebih cekap. Contoh hubungan aktiviti melalui rangkaian ditunjukkan oleh rajah di bawah :- Menghidupkan komputer memasang perisian P1 P2 P3 Rajah A: Hubungan aktiviti melalui rangkaian Carta Gantt Carta Gantt yang merupakan salah satu teknik penjadualan yang popular. Carta Gantt juga dikenali sebagai carta bar dimana setiap aktiviti projek akan ditunjukkan bersama tempoh masa perjalanannya. Rajah B merupakan contoh carta Gantt. Carta Gantt merupakan perwakilan grafik dalam sebuah projek yang menunjukkan setiap tugas sebagai jalur mendatar, yang mana panjang jalur mendatar adalah bersamaan dengan masa yang diperuntukan bagi setiap aktiviti yang telah ditetapkan  Muka Surat / Page : 18 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Kepentingan Carta Gantt Dalam Melaksanakan Projek Carta Gantt digunakan kerana ia dapat membantu pengurus mengenalpasti : a) Semua aktiviti yang telah dirancang. a) Pelaksanaan aktiviti pekerjaan yang ditunjukkan b) Anggaran masa untuk aktiviti-aktiviti direkodkan c) Jangkamasa keseluruhan projek dilaksanakan Rajah B: Contoh carta Gantt Cadangan Aktiviti: Berdasarkan petikan dibawah, berikan pendapat anda.  Muka Surat / Page : 19 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 3.3.4 Project Brief Content for Modules number Modul Dari Stephen Schach, “Classical and Object-Oriented Software Engineering”, chapter 6: a module consists a single block of code that can be invoked in the way that a procedure, function, or method is invoked 1. Modul adalah sebahagian daripada program. 2. Program terdiri daripada satu atau lebih modul yang dibangunkan secara bebas dan tidak digabungkan sehingga program dikaitkan (linked). 3. Modul tunggal boleh mengandungi satu atau beberapa rutin. 4. Pengenalan kepada modularity ini membolehkan pengaturcara untuk menggunakan semula kod yang telah ditulis dengan aplikasi baru. 5. Modul dicipta dan disatukan dengan pengkompil (compilers) 6. Sebagai contoh, Sistem Aplikasi dan Produk dalam Pemprosesan Data (Systems, Applications and Products in Data Processing - SAP) – merupakan perisian enterprise resource planning (ERP) - terdiri daripada beberapa modul besar (contohnya, kewangan, supply chain dan gaji serta beberapa modul lain), yang mungkin dilaksanakan dengan sedikit penyesuaian atau tiada. 7. Contoh klasik dari aplikasi berasaskan modul ialah Microsoft Word, yang mengandungi modul yang diperbadankan (incorporated) dari Microsoft Paint yang membantu pengguna membuat lukisan atau angka. 3.5 PROJECT BRIEF CONTENT FOR TASK ASSIGNATION (STRUKTUR AGIHAN TUGAS) Struktur agihan tugas adalah satu teknik yang digunakan untuk membahagikan tugas projek kepada unit-unit tugas yang lebih kecil supaya mudah diurus. Konsep yang sama juga digunakan dalam reka bentuk perisian, dengan sebuah sistem perisian dipecahkan kepada unit yang lebih kecil. Tujuan utama pemecahan ini adalah untuk mengurangkan kerumitan dan memudahkan pengawasan proses pembangunan. Ia juga boleh digunakan sebagai asas untuk membuat anggaran kos, jadual dan pengagihan tugas kepada ahli projek. Struktur agihan tugas projek mengenal pasti semua tugas yang perlu dilaksanakan sepanjang pembangunan projek. Struktur ini termasuklah tugas pembangunan perisian, pemasangan, penyelenggaraan, pengurusan, latihan, perolehan dan penyediaan dokumen. Jika di kemas kini secara tetap, ia adalah satu alatan yang sangat berguna kepada pengurusan. Contoh struktur agihan tugas projek ialah: Id. Tugas Keterangan Status Pelaksana 1 Pengurusan Berjalan Pengurus 2 Pembangunan Perisian Berjalan 2.1 Analisis keperluan Selesai Ali, Ahmad 2.2 Reka bentuk perisian Berjalan 2.2.1 Reka bentuk seni bina Selesai Farhan 2.2.2 Reka bentuk terperinci Berjalan Farhan, Fadli 2.2.3.1 Reka bentuk logik Berjalan Ali 2.2.3.2 Reka bentuk skrin 2.2.3.3 Reka bentuk data 2.2.4 Semakan reka bentuk 2.3 Pengkodan 2.4 Integrasi 3 Perolehan  Muka Surat / Page : 20 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Struktur agihan tugas ini akan bersandar dengan Penjadualan Projek dimana setiap tugasan perlu dilaksanakan mengikut ketetapan jadual supaya tidak berlaku kelewatan masa menyiapkan projek. Faktor ini bergantung kepada jenis projek, kekangan masa, kualiti dan pengalaman ahli kumpulan projek. Fungsi Kerja (Job Functions) Pengagihan tugas perlu diberi kepada pekerja atau kumpulan yang mempunyai kebolehan dan kepakaran dalam bidang tugas yang berkaitan. Fungsi Kerja ditakrifkan sebagai tugas asas yang seorang pekerja individu bertanggungjawab. Tugas-tugas ini berbeza-beza dari satu kedudukan ke depan, walaupun dalam kumpulan pekerja yang sama. Personel Projek Tujuan: Untuk menentukan jadual projek dan juga menganggarkan kos dan usaha, kita perlu mengetahui berapa ramai yang akan terlibat dalam projek, apa tugas yang dilakukan, apakah keupayaan dan pengalaman/kemahiran yang perlu ada. Perlu diingatkan tidak semua tugas dilakukan oleh orang yang sama. Pembahagian tugas berdasarkan: i. saiz projek ii. kepakaran staf iii. pengalaman staf Apabila sudah menentukan peranan staf, maka kita perlu tentukan jenis orang yang diperlukan bagi memikul peranan tugas tersebut dalam kumpulan projek Cadangan soalan kendiri Terlalu Ramai Jeneral dan Tidak Cukup Askar 22/12/2011 Apabila berbincang mengenai projek lewat siap, inilah ungkapan yang sering disebut “Terlalu ramai jeneral (ketua) tetapi askar (staf) tidak cukup”. Adakah persoalan ini betul? Soalnya sebagai pengurus projek, tidak kiralah swasta atau kerajaan, Adakah kita membuat analisa berapa ahli pasukan projek atau staf yang diperlukan, dan apa kemahiran mereka untuk laksana projek dengan jayanya? Jika dilaksana, apa asas atau penanda aras untuk analisis tersebut? Tidak punya staf yang mencukupi atau mempunyai staf yang cukup tetapi dengan kemahiran berlainan dari apa yang diperlukan boleh menyebabkan kegagalan projek. *Petikan telah diambil dari https://pengurusanprojek.wordpress.com/ dan telah diubahsuai mengikut kesesuaian Berdasarkan situasi berikut, nyatakan justifikasi anda.  Muka Surat / Page : 21 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Organisasi Projek Semua ahli projek bekerjasama antara satu sama lain Struktur organisasi bagi projek bergantung kepada: a) Latarbekalang dan cara bekerja ahli pasukan b) Bilangan orang dalam pasukan c) Corak pengurusan pelanggan dan pembangunan Rajah A: contoh struktur organisasi yang popular Cadangan latihan pemahaman 1. Mengapakah organisasi projek perlu dibentuk? Rujukan: http://www.tutorialspoint.com/software_engineering/software_project_management.htm Carlos Coronel and Steven Morris (2014) Database Systems: Design, Implementation, & Management, New York http://www.radford.edu/~cshing/340/lectures/Rob&Coronel/ Mewujudkan Sistem Aplikasi : Kepentingan Keperluan Pengguna (User Requirements) http://www.ukm.my/wadahict/mewujudkan-sistem-aplikasi-kepentingan-keperluan-pengguna- user-requirements/ Job functions https://www.reference.com/business-finance/job-function-mean- d242a5f76f1c6623 Module https://www.webopedia.com/TERM/M/module.html 3.4 CHECK APPLICATION PROTOTYPE (C3K5 &C3K5) 3.4.1 KEPERLUAN PERLAKSANAAN ALIRAN APLIKASI MOCKUP PROTOTAIP Dalam kertas penerangan pertama, proses pembangunan prototaip telah dijelaskan iaitu proses menghasilkan lakaran, wireframe, mockup dan prototaip. Sebaik sahaja sebuah projek diterima, modul perlu dipecahkan. Pecahan ini memerlukan rekabentuk antaramuka yang tersendiri kerana mungkin terdapat perbezaan dari segi fungsi bagi setiap modul tersebut. Sebagai contoh sebuah sistem yang menguruskan maklumat Projek Tahun Akhir Pelajar yang ditampilkan sebagai kajian kes di bawah : KAJIAN KES: Anda diminta untuk membangunkan sebuah sistem pengurusan permohonan bagi tajuk projek tahun akhir. Sistem ini membolehkan pensyarah mencadangkan tajuk dan memilih pelajar yang memohon untuk menjadi pelajar seliaan projek tahun akhir. Sistem ini juga membolehkan pelajar melihat senarai tajuk dan penyelia bagi projek tahun akhir. Selain itu, pelajar juga boleh menyemak status permohonan tajuk. Pelajar hanya boleh memohon tiga tajuk sahaja dalam satu masa dan perlu mengesahkan tajuk selepas penyarah menerima permohonan. Terdapat dua modul utama yang dikenalpasti dalam sistem ini iaitu modul pengurusan pensyarah dan modul untuk pengurusan pelajar. Pensyarah perlu log masuk dan mencadangkan tajuk untuk dibuka kepada pemohon tajuk iaitu pelajar. Pelajar pula menggunakan sistem untuk membuat permohonan dan semakan terhadap tajuk Projek Tahun akhir mereka. Oleh yang demikian, kita dapat pecahkan sistem tersebut kepada dua modul yang besar iaitu modul pensyarah dan modul pelajar. Modul yang kecil boleh dipecahkan lagi mengikut fungsi yang disediakan dalam modul tersebut. Apabila pecahan modul dikenalpasti, lakaran terhadap paparan modul itu akan dilakukan dan seterusnya membangunkan wireframe. Walaubagaimanapun, praktis penghasilan papan cerita dilihat telah cukup untuk menggabungkan elemen lakaran dan juga wireframe kerana papan cerita bukan sahaja menampilkan kedudukan elemen yang ada pada antaramuka, tetapi juga turut menampilkan penerangan terhadap kandungannya. Berikut adalah papan cerita bagi muka hadapan sistem serta muka hadapan setiap modul utama.  Muka Surat / Page : 23 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Papan cerita Halaman Utama Sistem Papan cerita Halaman Utama Modul Pensyarah  Muka Surat / Page : 24 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Papan cerita Halaman Utama Modul Pelajar Sitemap adalah salah satu elemen yang turut dibangunkan dalam proses pembangunan aplikasi. Sitemap akan dirancang dan dibangunkan bagi melihat secara keseluruhan bagaimana kandungan setiap halaman yang dihubungkan ke halaman lain. Sitemap adalah sebuah gambarajah berhirarki yang digunakan untuk menjelajah keseluruhan halaman sistem tersebut. Sitemap biasanya menggunakan kotak yang mewakili halaman dan anak panah atau garisan yang menunjukkan hubungan. Contoh Sitemap  Muka Surat / Page : 25 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Berbeza pula dengan User Flow Diagram. User Flow Diagram di bangunkan untuk menggambarkan penjelajahan yang akan dialami oleh pengguna. Kadangkala warna dan bentuk elemen seperti bentuk proses dan anak panah menunjukkan maksud yang tertentu. Contoh User Flow  Muka Surat / Page : 26 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Kemudian mockup direkabentuk sebelum aplikasi prototaip dibangunkan. Seperti yang telah dimaklumkan sebelum ini, secara umumnya Mockup bertujuan untuk mendapatkan keseimbangan bentuk, struktur, saiz, kesesuaian bahan, keselamatan, penggunaan dan cara pembinaan. Dalam pembangunan laman web, Mockup dibangunkan bagi menentukan penampilan sebenar sebagai contoh dari segi style dan Font, kedudukan dan saiz grafik, susunan struktur maklumat, elemen atau bahan yang akan ditampilkan kepada pengguna. Mockup penting untuk menguji penerimaan penampilan antaramuka pengguna atau User Interface (UI). Setelah penampilan dikenalpasti dan dipersetujui, aplikasi prototaip sudah boleh mula dibangunkan. 3.4.2 PENGUJIAN UNIT DAN KEBOLEHGUNAAN Apabila aplikasi prototaip dihasilkan, aplikasi tersebut perlu diuji. Seperti yang telah sedia maklum, prototaip merupakan satu versi ringkas yang akan digunakan sebagai simulasi oleh pengguna sebenar untuk menguji sejauh mana produk yang akan dihasilkan menepati kehendak pengguna. Pengujian terhadap antaramuka yang telah disiapkan adalah untuk meningkatkan lagi persembahan rekabentuk antaramuka. Persepsi terhadap antaramuka sangat subjektif kerana tiada formula yang tertentu yang dapat mengukur antaramuka yang terbaik. Walaubagaimanapun, pengujian sangat diperlukan bagi memastikan sistem yang dibangunkan berfungsi dengan baik. Antara elemen yang diuji ialah : i. Butang navigasi dan arahan ii. Input pengguna dan Output kepada pengguna iii. Sejauh mana pengguna mudah mempelajari dan mudah faham semasa menggunakan sistem tanpa atau dengan bantuan sokongan yang disediakan 3.4.3 PENGUJIAN UNIT (UNIT TESTING) Pengujian unit dilakukan terhadap unit terkecil yang dinamakan modul. Modul boleh terdiri daripada satu fungsi atau prosedur. Setiap modul perlu diuji dari beberapa aspek seperti pengendali ralat, antaramuka, laluan logik, struktur data, nilai sempadan dan kelas data.  Pengendali ralat : menangani ralat daripada berlaku semasa pelaksanaan  Antaramuka : menyemak parameter masuk dan keluar daripada modul atur cara  Laluan logik : memastikan setiap penyataan diuji sekurang-kurangnya sekali  Muka Surat / Page : 27 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14  Struktur data : Data yang tersimpan dapat mengekalkan integrasi semasa perlaksanaan  Nilai sempadan dan kelas data : Memastikan modul berfungsi dengan baik pada nilai sempadan. Kelas data yang sah dan tidak sah juga diuji. 3.4.4 PENGUJIAN KEBOLEHGUNAAN (USABILITY TESTING) Kebolehgunaan terhadap aplikasi yang dibangunkan hanya boleh ditentukan apabila pengujian kebolehgunaan dilaksanakan. Pembangun boleh melihat pengguna berinteraksi dengan aplikasi dan pengguna akan menjawab soalan-soalan yang disediakan seperti ;  Adakah pengguna boeh menggunakan aplikasi tanpa bantuan dan arahan?  Adakah rekabentuk aplikasi mudah dan ringkas?  Adakah pengguna mengalami gangguan teknikal semas menggunakan aplikasi ini?  Adakah pengguna boleh mengawal sepenuhnya fungsi dalam aplikasi ini?  Adalah laras bahasa atau penggunaan simbol cukup difahami oleh pengguna? Jika banyak soalan yang dijawab oleh pengguna adalah ‘Ya’ ia boleh dikatakan sebagai kebolehgunaan telah tercapai. Pengujian ini penting untuk mengukur tahap kepuasan pengguna dan mengurangkan kos sokongan dan juga dokumentasi. Pengujian kebolehgunaan boleh dilakukan untuk menguji fungsi dan penerimaan pengguna terhadap antaramuka. Pengujian antaramuka perlu mengambilkira 5 prinsip asas rekabentuk interaksi iaitu konsistensi, kebolehan membuat pemerhatian, boleh dipelajari, kebolehan untuk menjangka dan maklumbalas.  Konsistensi Konsistensi merujuk kepada kedudukan setiap elemen dalam setiap halaman. Semua elemen perlu kekal pada kedudukan yang sama supaya pengalaman pengguna tidak terganggu untuk menggunakan aplikasi tersebut. Sebagai contoh apabila merujuk kepada papan cerita kajian kes yang diberi tadi, kedudukan untuk KELUAR sistem adalah sama bagi kedua-dua modul dan akan konsisten pada setiap halaman yang berkaitan.  Kebolehan membuat pemerhatian Kebolehan membuat pemerhatian merujuk kepada sejauh mana pengguna berasa selesa dan selamat untuk menggunakan sebarang elemen tanpa ragu-ragu. Contohnya elemen untuk menerima dan menolak permohonan oleh pensyarah jelas dan mesejnya  Muka Surat / Page : 28 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 mudah sampai kepada pengguna tersebut. Oleh yang demikian, pengguna dapat menggunakan aplikasi tanpa sebarang keraguan.  Boleh dipelajari Boleh dipelajari penting bagi pengalaman pengguna buat kali pertama menggunakan aplikasi. Sejauh mana pengguna boleh mengingati cara untuk mengendalikan aplikasi tersebut perlu diambilkira.  Kebolehan untuk menjangka Kebolehan untuk menjangka pula ialah pengguna dapat menjangka apa yang akan berlaku apabila menggunakan sebarang elemen dalam aplikasi. Sebagai contoh apabila pengguna memilih fungsi untuk Cadang Tajuk, pengguna dapat menjangka untuk mengisi sesuatu bagi mencadangkan tajuk projek akhir. Pengguna akan dibawa ke halaman untuk memasukkan tajuk Projek Tahun Akhir yang akan dipaparkan dalam senarai yang akan dipohon oleh pelajar nanti.  Maklumbalas Maklumbalas bertujuan untuk melakukan penambahbaikan pada rekabentuk interaksi yang dihasilkan. 3.4.5 KAEDAH PENILAIAN Antara kaedah penilaian yang boleh digunakan dalam menjalankan pengujian sistem ialah sola selidik. Soal selidik boleh dibangunkan untuk menilaian kebolehgunaan produk berdasarkan prinsip asas rekabentuk di atas. Pilihan jawapan dalam soal selidik boleh ditampilkan dalam dua jenis iaitu bentuk Skala Likert ataupun bentukSkala Guttmen. Skala Likert digunakan untuk melihat sejauh mana persetujuan pengguna terhadap produk yang dibangunkan. Jenis ini menampilkan skala yang mewakili maksud seperti 5 = Amat setuju 4 = Setuju 3 = Tidak setuju 2 = Sangat tidak setuju 1 = Tidak pasti Skala Guttman pula bertujuan untuk mendapatkan data yang lebih jelas, tegas dan konsisten iaitu menampilkan pilihan ‘Ya’ yang mewakili setuju dan ‘Tidak’ untuk tidak atau kurang bersetuju.  Muka Surat / Page : 29 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Nama produk yang dinilai : Sistem Pengurusan Projek Tahun Akhir Kategori : Sistem Pengurusan Maklumat Versi (*jika ada) : - Fungsi utama : Memohon tajuk projek dan menyemak permohonan Tarikh : 12 Disember 2015 Prinsip asas Penilaian Tandakan (/) jika Ya dan (x) jika Tidak Ya Tidak (/) (x) Konsisten Adakah fungsi navigasi sentiasa berada di sebelah kiri? Kebolehan Nama atau ikon yang membuat digunakan pada butang atau pemerhatian navigasi aman mudah untuk difahami. Boleh dipelajari Saya mudah untuk memahami sistem ini tanpa perlu diajar berulang kali. Kebolehan untuk Apabila menekan sesuatu menjangka butang atau hyperteks, saya boleh menjangka apa akan dipaparkan selepas itu. Maklum balas Adakah anda selesa dengan penggunaan hyperteks pada fungsi manipulasi senarai seperti PADAM/ BATAL/ TERIMA/TOLAK? Contoh Borang Soal Selidik Untuk Menilai Kebolehgunaan Produk  Muka Surat / Page : 30 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Daripada hasil soal selidik, rumusan perlu dilakukan bagi mengetahui keputusan pengujian. Prinsip asas Penilaian Jumlah Peratus (%) Ya Tidak Ya Tidak (/) (x) (/) (x) Konsisten Adakah fungsi navigasi 20 0 100 0 sentiasa berada di sebelah kiri? Kebolehan Nama atau ikon yang 18 2 90 10 membuat digunakan pada butang pemerhatian atau navigasi aman mudah untuk difahami. Boleh Saya mudah untuk 19 1 95 5 dipelajari memahami sistem ini tanpa perlu diajar berulang kali. Kebolehan Apabila menekan 19 1 95 5 untuk sesuatu butang atau menjangka hyperteks, saya boleh menjangka apa akan dipaparkan selepas itu. Maklum balas Adakah anda selesa 9 11 45 55 dengan penggunaan hyperteks pada fungsi manipulasi senarai seperti PADAM/ BATAL/ TERIMA/TOLAK? Contoh Rumusan Borang Soal Selidik Untuk Menilai Kebolehgunaan Produk  Muka Surat / Page : 31 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Bagi pengujian paparan dan rekabentuk, penilaian kuantitatif diperlukan bagi mengukur keberkesanan sesuatu produk. Kaedah yang sesuai ialah temubual dan juga soal selidik. Tajuk Sistem Sistem Pengurusan Projek Tahun Akhir Objektif Sistem Membangunkan sistem permohonan dan semakan tajuk projek tahun akhir dia atas talian. Sasaran Pensyarah dan pelajar semester 7 Kategori Pensyarah/Pelajar Pengguna Tandakan (/) sekiranya anda setuju dan tandakan (x) sekiranya Tidak Setuju Kategori Kriteria Ya (/) Tidak (x) Rekabentuk skrin 1. Pemilihan warna dan ikon yang sesuai dan menarik 2. Tidak mengandungi kesalahan ejaan 3. Laras bahasa yang digunakan mudah difahami Interaktiviti 1. Fungsi Terima/Tolak/Sah/Batal pengguna berfungsi dengan baik 2. Paparan tajuk yang disahkan disenaraikan pada tempat yang betul  Muka Surat / Page : 32 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Kategori Kriteria Ya (/) Tidak Ya (/) Tidak (x) % (x) % Rekabentuk skrin 1. Pemilihan warna dan 25 5 83 17 ikon yang sesuai dan menarik 2. Tidak mengandungi 30 0 100 0 kesalahan ejaan 3. Laras bahasa yang 30 0 100 0 digunakan mudah difahami Interaktiviti 1. Fungsi 30 0 100 0 pengguna Terima/Tolak/Sah/Ba tal berfungsi dengan baik 2. Paparan tajuk yang 30 0 100 0 disahkan disenaraikan pada tempat yang betul Purata 97 3 RUMUSAN PENILAIAN PENGGUNA TERHADAP PAPARAN DAN REKABENTUK SKRIN SISTEM PENGURUSAN PROJEK TAHUN AKHIR 3% Ya Tidak 97% Contoh Rumusan Yang Membuktikan Antaramuka Pengguna Yang Dibangunkan Telah Mematuhi Kesesuaian Terhadap Pengalaman Pengguna  Muka Surat / Page : 33 NO. KOD / CODE NO. IT-010-3:2016-C01/ P(3/4) Drpd / of : 14 Pengujian unit dan kebolehgunaan boleh dilaksanakan secara lebih formal apabila melibatkan produk yang komersial dan produk yang dibangunkan kepada sesebuah organisasi yang besar dan penggunaan sistemnya lebih meluas. Hanya boleh dilaksanakan pada aplikasi prototaip yang sedang menanti masa untuk pemasangannya. Pengujian dilakukan pada sesi one-to-one terhadap pengguna yang betul-betul menggunakan perisian tersebut. Pengujian ini paling teliti dan mengambil kira pelbagai komponen seperti penggunaan setiap butang arahan dan navigasi dalam sistem tersebut. Pengguna mungkin akan diberikan satu tugasan untuk diselesaikan dengan menggunakan sistem tersebut tanpa bantuan mana-mana kumpulan pembangun. Sesi akan dirakam dengan perisian tertentu bagi memastikan apa yang pengguna betul-betul telah laksanakan. Jika antaramuka pengguna tidak menepati dan sukar difahami, pengguna mungkin akan gagal menyiapkan tugasan dan sistem akan dianggap sebagai gagal. SOALAN/QUESTION : 1. Nyatakan definisi UI dan UX. 2. Bagaimana cara untuk menguji kebolehfungsian sesuatu aplikasi? 3. Apakah maksud unit testing dan usability testing? 4. Apakah 5 prinsip asas rekabentuk interaksi? 5. Apakah kaedah pengujian yang boleh dilakukan terhadap fungsi antaramuka? RUJUKAN/REFERENCE : 1. Denis et al, 2006, System Analysis And Design (Third Edition: Bab 10), Penerbitan Wiley, (ms 305-348) 2. Suhaimi et al, 1999, Kejuruteraan Perisian (Bab 2-5) Penerbitan UTM, (ms 21- 114) 3. Alan et al, human – Computer Interaction (Second Edition, Bab 10-11) Penerbitan Prentice Hall (ms 378-441) 4. S.G Chua et al, 2016, Sains Komputer Tingkatan 4 (Bab 3) Penerbitan Oxford Fajar (ms 314-342) 5. Roger S. Pressman, Software Engineering – A Practitioner Approach (Eight Edition : Bab 15 & 22) Penerbitan McGraw-Hill Enternational Edition (ms 322 & 473)