15. PRESENTASI TUGAS KELOMPOK
1.2. Konsep Penilaian
Daftar Pustaka : 1. Kung, David C., 2014. Object Oriented Software Engineering: An Agile
Methodology, McGraw-Hill
2. Pressman, Roger S. 2010. Software Engineering : A Practitioner's
Approach,7th, McGraw-Hill
3. Schach, Stephen R. 2010. Object Oriented and Classical Software Engineering, 8th, McGraw-Hill 4. Sommerville, Ian. 2010. Software
Engineering, 9th, Pearson Education
15. PRESENTASI TUGAS KELOMPOK
1.1. Ruang Lingkup Tugas
Tugas yang diberikan akan dibagi menjadi beberapa tahap pengerjaan antara lain meliputi materi berikut :
Analisa kebutuhan
Pemodelan kebutuhan dengan : o Activity Diagram
o Usecase Diagram o Class Diagram
Tahapan analisa merupakan tahap yang kritis dan sangat penting, karena kesalahan di dalam tahap ini akan menyebabkan juga kesalahan di tahap selanjutnya.
Digunakan untuk mendefinisikan dan menggambarkan kebutuhan pemakai secara detil, waktu spesifik dan hambatan biaya mengikuti perencanaan sistem dan dilanjutkan rancangan sistem general
Ada tiga faktor yang harus dipenuhi ketika melakukan analisis kebutuhan ini, yaitu lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisis. Detail maksudnya adalah berhasil mengumpulkan informasi yang terperinci. Semua data dari analisis kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang dipikirkan oleh pihak analisis.
Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan menghasilkan spesifikasi perangkat lunak tersebut. Analisa kebutuhan ini terdiri dari lima langkah pokok:
1) Mempelajari dan memahami persoalan 2) Mengidentifikasi kebutuhan pemakai
3) Mendefinisikan kebutuhan perangkat lunak 4) Membuat dokumen spesifikasi kebutuhan 5) Mengkaji ulang (review) kebutuhan
Sehingga pada cakupan analisa kebutuhan, tiap kelompok mengidentifikasi hal berikut:
1. Menuliskan permasalahan yang ditemui dalam kasus pengembangan perangkat lunak
Pada tahap ini, masalah yang akan dibuat perangkat lunaknya dipelajari sehingga dapat ditentukan:
Mendefinisikan deskripsi sistem yang akan dibangun o Mendefinisikan Stakeholder dan pengguna
Siapa pemakai yang akan menggunakan perangkat lunak serta Pekerjaan apa dari pemakai yang akan dibantu oleh perangkat lunak o Mendefinisikan pekerjaan apa saja dari pengguna yang akan
diselesaikan dengan bantuan sistem o Mendefinisikan Lingkungan Sistem
Dimana perangkat lunak akan digunakan
Mendefinisikan Tujuan serta Ruang Lingkup
Dari dan sampai mana cakupan pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannya
Mendefinisikan permasalahan, kendala/keterbatasan yang ditemui
Apa yang menjadi kendala atau keterbatasannya dilihat dari sisi teknologi yang akan digunakan atau dari sisi hukum dan standar
2. Menentukan Kebutuhan Perangkat Lunak
Pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional dan non fungsional (kebutuhan antarmuka dan unjuk kerja perangkat lunak)
Kebutuhan fungsional : deskripsi aktivitas dan layanan yang harus disediakan sebuah sistem (inputs, outputs, processes, stored data)
Kebutuhan non-fungsional : deskripsi dari fitur, karakteristik dan batasan lain yang menentukan kepuasan system (Performance, ease of learning and use, budgets, deadlines, documentation, security, internal auditing controls)
Akibat ketidaktepatan penentuan kebutuhan fungsional & non-fungsional :
biaya lebih tinggi dari perkiraan
implementasi lebih lambat dari rencana
ketidakpuasan user
harga perawatan dan peningkatan system lebih tinggi
system tidak terpecaya dan cenderung bermasalah
reputasi staf TI dipertanyakan
3. Membuat pemodelan berdasarkan kebutuhan yang sudah dipahami
Pemodelan adalah bagian penting dari analisis dan perancangan sistem. kita telah mempelajari pada matakuliah sebelumnya tentang banyak model terutama UML. Analis membangun model untuk menggambarkan kebutuhan sistem dan berkomunikasi dengan user dan Desainer. Dengan mengembangkan model dan meninjaunya dengan user, seorang analis menunjukkan pemahaman tentang kebutuhan user. Jika user melihat menemukan kesalahan, hal itu menjadi masukan pada model sebelum menjadi dasar pada kegiatan berikutnya yaitu perancangan dan implementasi.
Beberapa alasan utama untuk membangun dan menggunakan model :
Mempelajari dari pemodelan
Mengurangi kompleksitas dengan abstraksi (penyederhanan)
Mengingat seluruh detil
Alat berkomunikasi dengan tim pengembang
Alat berkomunikasi dengan berbagai user dan stakeholders
Dokumentasi apa yang sudah/akan dibangun/ditingkatkan
Tugas kelompok adalah membuat pemodelan berikut : a. Activity Diagram (Diagram Aktifitas)
Pada saat kita mengumpulkan informasi tentang proses bisnis, kita perlu mendokumentasikannya dalam alur kerja (workflow). Alur kerja adalah urutan langkah kerja yang menyelesaikan satu transaksi bisnis atau permintaan pelanggan. Alur kerja mungkin sederhana atau kompleks. Alur
kerja yang kompleks dapat terdiri dari banyak langkah kerja dan dapat mencakup user dari berbagai bagian di organisasi. Salah satu cara efektif untuk menangkap informasi ini adalah dengan activity diagram UML.
Diagram aktivitas menggambarkan berbagai aktivitas user (atau sistem), orang atau komponen yang melengkapi setiap aktivitas, dan aliran berurutan dari aktivitas ini.
b. Usecase Diagram (diagram usecase)
Dalam pembuatan suatu perangkat lunak, biasanya dibutuhkan suatu cerita user/scenario (user story) jalannya sistem yang akan dibangun. Skenario ini menggambarkan interaksi diantara actor dengan sistem. Tujuan utama skenario adalah :
Menggambarkan apa yang dibutuhkan oleh sofware
Sebagai dasar dalam pembuatan perancangan dari sofware
Untuk membatasi serangkaian kebutuhan yang dapat divalidasi ketika sofware dibangun
Melakukan identifikasi cerita user dan use case adalah kegiatan kunci (key task) ketika analis ingin mendefinisikan kebutuhan fungsional (functional requirement) karena ini memberikan dasar untuk membuat list, fungsi apa yang perlu dilakukan oleh sistem. Hampir semua pendekatan terbaru pada pengembangan sistem dimulai dengan kegiatan functional requirement didasarkan kepada cerita user atau use case. Konsep ini sama dengan menentukan tujuan user, yang menunjukkan daftar fungsi yang diingakan sampai detail.
User story fokus pada siapa (who ?) , apa (what ?) , dan mengapa (why ?) untuk setiap fungsi. Template standar untuk user story dapat dibuat seperti ini:
“Sebagai <<peran >>, saya ingin <<tujuan/keinginan>> sehingga
<<alasan/keuntungan>>
Contoh :
Bagian terakhir dari user story adalah kriteria penerimaan (acceptance criteria) , artinya fitur/fungsi tersebut nantinya harus ada agar user puas dengan implementasi yang dihasilkan. Perlu diingat kriteria penerimaan itu fokus pada fungsionalitas, bukan pada fitur atau perancangan interface user.
Cara lain analis mengidentifikasi dan mendefinisikan use case adalah dengan pendekatan user goal technique, yaitu meminta user untuk menggambarkan tujuan mereka pada saat menggunakan sistem baru atau sistem yang diperbaiki.
Pertama-tama Analis mengidentifikasi semua user, mengelompokkannya berdasarkan jenis user, dan kemudian melakukan wawancara terstruktur dengan setiap user. Dengan fokus pada satu jenis user pada suatu waktu, analis dapat secara sistematis mengatasi masalah untuk mengidentifikasi use case. Selama wawancara, analis memandu user untuk mengidentifikasi bagaimana sistem komputer dapat membantu user melakukan tugas mereka. Tujuan utamanya adalah untuk mengidentifikasi apa yang dapat dilakukan sistem untuk meningkatkan kinerja dan produktivitas user.
Tujuan lainnya adalah menyederhanakan tugas user.
Identifikasi use case menggunakan User Goal Technique:
1) Identifikasi semua user potensial untuk sistem baru.
2) Klasifikasi user potensial dalam hal peran fungsionalnya (mis., Pengiriman, pemasaran, Penjualan)
3) Selanjutnya mengklasifikasikan user potensial berdasarkan tingkat organisasi (mis., Operasional, manajemen, eksekutif).
4) Lakukan wawancara setiap jenis user untuk menentukan tujuan spesifik yang akan mereka inginkan ketika menggunakan sistem baru. Dimulai dengan tujuan yang saat ini mereka miliki dan kemudian buat mereka membayangkan fungsi-fungsi inovatif yang mereka pikir akan menambah nilai. Dorong mereka untuk menyatakan setiap tujuan dalam bentuk kata benda-kata kerja imperatif(mengandung nilai permintaan), seperti Tambah pelanggan, Perbarui pesanan, dan buat laporan akhir /bulan.
5) Buat daftar use case awal yang disusun berdasarkan jenis user.
6) Cari duplikat use case yang sama dan perbaiki inkonsistensi.
7) Identifikasi di mana berbagai jenis user ada yang membutuhkan use case yang sama.
8) Review daftar yang telah lengkap untuk masing-masing jenis user dan juga kepentingan stakeholders .
c. Class Diagram
Class Diagram adalah salah satu jenis diagram yang paling berguna di UML, karena dapat dengan jelas memetakan struktur sistem tertentu dengan memodelkan kelas, atribut, operasi serta hubungan antar objek. Class Diagram menggambarkan serta deskripsi atau penggambaran dari class, atribut, dan objek disamping itu juga hubungan satu sama lain seperti pewarisan, containmet, asosiasi dan lainnya. Class Diagram mampu memberikan kita pandangan yang lebih luas mengenai suatu sistem dengan cara menunjukkan kelas serta hubungan-hubungannya. Diagram class dapat dikatakan bersifat statis, alasannya karena class diagram tidak menggambarkan apa yang terjadi jika mereka berhubungan melainkan menggambar hubungan apa yang terjadi.
1.2. Konsep Penilaian
Penilaian akan dilakukan oleh dosen dan juga bersama peer group lainnya. Untuk penilaian mencakup 2 keluaran dari tugas yaitu video presentasi dan juga laporan akhir dalam bentuk cetak. Komponen penilaian akan menyertakan nilai-nilai kebudiluhuran yang telah diuraikan pada pertemuan awal. Penilaian bersama peer group baik internal maupun eksternal dari kelompok kerja akan difasilitasi oleh kuesioner penilaian.
Latihan
Setiap kelompok diminta untuk :
menyiapkan topik pembahasan pengembangan perangkat lunak
menyiapkan bahan presentasi
menyiapkan laporan tugas dalam bentuk hardcopy keseluruhan