Revisi Elaboration [bacaan lagi]

Catatan Review IF3262/Proyek Perangkat Lunak
Review : Akhir Fase Elaboration
Bahan : Dokumen Pembangunan Perangkat Lunak Versi Elaboration
Reviewer : Fazat Nur Azizah
Tanggal : 26 April 2007
Kategori : Bookstore
Domain : Transportation
Judul : TranSoft
Review Umum
Ringkasan:
- Daftar kebutuhan: masih ada beberapa kalimat yang bermasalah.
- Diagram use case: ada use case dan aktor yang tidak dijelaskan lebih lanjut.
- Hasil perancangan: Diagram sekuens perancangan masih terlalu sama dengan diagram tahap
analisis.
1. Pendahuluan
1.1. Tujuan Penulisan Dokumen
Lihat catatan pada dokumen.
1.2. Lingkup Masalah
OK.
1.3. Referensi
OK.
1.4. Aturan Penomoran
OK, tapi sebaiknya tambahkan penjelasan pengantar dari tabel yang ada.
1.5. Deskripsi Umum Dokumen (Ikhtisar)
OK!
2. Kebutuhan Perangkat Lunak
2.1. Deskripsi Umum Sistem
Gambar 2-1 sangat detil sehingga jangan-jangan lebih baik untuk subbab 3.5 Deskripsi
Arsitektur?
2.2. Fitur Utama Perangkat Lunak
2.2.1. Kebutuhan Fungsional
- Daftar kebutuhan seharusnya tidak diberi nama. Kode harus, tapi nama tidak perlu.
- Beberapa kesalahan dalam kalimat kebutuhan:
o TSF-F-07: ”Menerima tanggapan…”: seharusnya ”Mencatat tanggapan….”
o TSF-F-08: ”Membuat laporan…” seharusnya ”Mencetak…”?
o TSF-F-10, TSF-F-13, TSF-F-17: ”Memperoleh…” seharusnya ”Mencatat….”
o TSF-F-15: Apakah benar bahwa sistem Anda yang akan ”mengurangi kendaraan”?
Bukankah hanya menghapus datanya saja?
o TSF-F-23, TSF-F-24, TSF-F-27: Kata-kata yang sudah menjurus pada teknis
implementasi pada software seharusnya dihindari, misalnya apakah menggunakan
webservice atau database relasional.
o Dst. Lihat catatan di dokumen.
2.2.2. Kebutuhan Non-Fungsional
Lihat catatan di dokumen.
2.3. Model Use Case
2.3.1. Diagram Model Use Case
- Pada diagram use case, ada use case yang tidak dideskripsikan lebih lanjut: ‘Report’.
Karena use case ini tidak dijelaskan lebih lanjut, kebutuhan untuk menyiapkan report
bagi manager ditangani oleh use case mana?
2
- Pada diagram use case, ada aktor yang tidak dideskripsikan lebih lanjut: ‘Report
Supplier’.
- Penamaan use case ‘Complaint’: complaint adalah kata benda, seharusnya tidak
digunakan untuk keseluruhan nama use case. Ganti misalnya ‘Send complaint’.
2.3.2. Definisi Aktor
- Deskripsi aktor ‘Administrator’: hanya basisdata aplikasi yang dikelola? Bagaimana
dengan fitur aplikasi?
- Berdasarkan deskripsi aktor ‘Manager’, ‘Cashier’ dan ‘Operator’ memberikan laporan.
Tapi hal ini tidak dijelaskan dalam diagram use case (adanya ’Report Supplier’, itu pun
tidak tampak lagi).
2.3.3. Definisi Use Case
Lihat catatan pada dokumen.
2.3.4. Skenario Use Case
- Untuk semua skenario alternatif: berikan keterangan singkat merupakan skenario
alternatif untuk apa.
- Exception: jika sudah tidak bisa ditangani aplikasi, lantas apa yang dilakukan?
- Pastikan bahwa penggunaan kata pada skenario menunjukkan aksi yang secara eksplisit
bisa dilakukan oleh aktor atau sistem. Contoh: kalimat ’menerima …’, ’memperoleh
notifikasi…’ tidak menunjukkan aksi yang secara eksplisit bisa diverifikasi dilakukan
aktor (masih mengulangi kesalahan dari dokumen fase inception).
2.4. Spesifikasi Tambahan
Beberepa tips:
- Tambahkan penjelasan mengenai implementasi dari kebutuhan non-fungsional dalam use
case-use case yang tersebut sebelumnya.
- Jika memang diperlukan penjelasan mengenai exception yang bersifat umum (terjadi pada
sebagian besar use case) dapat diletakkan di sini.
2.5. Glossary
Teliti jika ada istilah-istilah yang memerlukan penjelasan lebih lanjut.
3. Model Analisis
3.1. Realisasi Use Case Tahap Analisis
- Periksa lagi keterunutan diagram sekuens dengan skenario. Pastikan bahwa hal-hal yang
tidak berada di dalam skenario, tidak dimasukkan dalam diagram sekuens.
- Berikan penjelasan singkat pada masing-masing diagram apa maksudnya dan mewakili use
case dan skenario yang mana.
- Pada beberapa diagram sekuens, tipe dari kelas tidak disebutkan.
- Lihat catatan di dokumen.
3.2. Diagram Kelas Keseluruhan
Tampaknya masih menggunakan versi dokumen fase inception karena banyak yang tidak
selaras dengan diagram-diagram kelas sebelumnya. Perbaiki!
3.3. Kelas Analisis
- Berikan penjelasan singkat tentang tabel-tabel (beri nomor dan nama pada tabelnya) yang
ada di bagian ini.
- Daftar tanggung jawab kira-kira sama dengan message yang dikirimkan oleh suatu kelas ke
kelas lain dalam diagram sekuens. Jadi, silakan diperbaiki.
- Kalau dilihat pada bagian operation and attribute pada bagian perancangan, sebenarnya ada
banyak kelas yang terlihat sudah diidentifikasi atributnya. Seharusnya atribut ini juga sudah
muncul di fase analisis.
3.4. Paket Analisis
Berikan penjelasan tentang tabel-tabel yang ada.
3.4.1. Identifikasi Kelas Analisis
OK.
3.4.2. Identifikasi Kelas Analisis Tiap Paket
3
OK.
3.5. Deskripsi Arsitektur
- Gambarnya sama saja dengan gambar 2.1 di subbab 2.1. Pilih akan diletakkan di mana
gambar ini. Saran: di subbab 2.1 lebih global (lebih mendekati business process-nya seperti
apa dan tidak memasukkan konsep-konsep teknologi di dalamnya).
- Beri penjelasan mengenai arsitekturnya.
4. Model Perancangan
4.1. Realisasi Use Case Tahap Perancangan
- Untuk tiap diagram, beri penjelasan misalnya diagram kelas dan sekuens yang ada pada
subbab bersangkutan merupakan hasil refinement dari diagram kelas dan sekuens mana pada
tahap analisis.
- Kebanyakan diagram sekuens masih sama saja dengan diagram sekuens pada tahap analisis.
Hal yang minimum berbeda adalah: nama message pada diagram sekuens tahap analisis
seharusnya sudah mulai diubah menjadi nama fungsi berikut parameter yang terlibat di
diagram sekuens perancangan.
- Pada model perancangan, tipe kelas (entity, boundary, control) sudah tidak kelihatan lagi.
- Lihat catatan di dokumen.
4.2. Diagram Kelas Keseluruhan
Tidak ada. Diagramnya sudah harus dalam notasi kelas perancangan.
4.3. Kelas Perancangan
Tidak ada tabel untuk mapping dari kelas analisis ke kelas perancangan.
4.3.1. Operasi dan Atribut
OK.
4.3.2. Algoritma/Query
Beri penjelasan kalau memang tidak ada.
4.3.3. Diagram Statechart
Buat diagram statechart untuk yang perubahan statusnya rumit saja. Tidak perlu semua.
4.4. Perancangan Antarmuka
Beri keterangan tambahan pada masing-masing antarmuka.
4.5. Coding Standard dan Naming Convention
- Tidak ada standar yang digunakan?
- Bagian Indentasi perlu diperjelas maksudnya apa.
4.6. Deployment Diagram
Beri penjelasan mengenai deployment diagram.
5. Lampiran
Rencana iterasi tidak ada.
6. Lain-Lain
- Daftar Halaman Perubahan (hlm. 3): seharusnya diisi tiap halaman yang berubah dan
perubahan yang terjadi.
- Pada penulisan teks di dokumen, jenis paragraf yang digunakan: ada yang takuk (awal
paragraf menjorok ke dalam), ada yang lurus. Pilih salah satu gaya saja.
- Pada penulisan tabel yang berpindah halaman, sebaiknya header tabel dan caption tabel
tetap disertakan.

 

Things to do bwt MPPL dari Fajrin

Daftar Isi Final Project Report
(Yang bagian utama ini bagi-bagi saja.. Perasaan sih sebagian udah pernah dibuat)

1. Project Objective
2. Summary of Project Results
3. Original and Actual Start and End Dates
4. Original and Actual Budget
5. Project Assessment (Mengapa proyek ini dikerjakan? Apa saja yang dihasilkan? Berhasilkan proyek ini? Apa yang baik dan yang kurang pas proyek ini?)
6. Transition Plan
7. Annual Project Benefits Measurement Approach

Lampiran (Nah yang bagian ini, yuk kita susun dan tentukan bareng2…)

A. Project Management Documentation (untuk yang sudah dicentang, mohon yang menyimpannya untuk menyetor ke Fitra (kalau Fitra belum punya))
• Business case  v
• Project charter  v
• Team contract  x (PJ Zaky)
• Scope statement  v
• WBS  v
• Baseline and actual Gantt chart  ? (sudah belum sih? di siapa? Kalau belum tetapkan saja..)
• List of prioritized risks  x (katanya memang ga.. tapi sepertinya bisa dibuat..)
• Milestone reports  ? (sudah belum sih? di siapa? Kalau belum tetapkan saja..)
• Status reports  still in progress tiap minggu
• Contract files  ? (sudah belum sih? di siapa? Kalau belum tetapkan saja..)
• Lessons-learned reports  x (PJ Fajrin – template ada di Fajrin)
• Final presentation  x (gatau kayak gimana??)
• Client acceptance form  x (gatau kayak gimana??)
• Product leaflet  x (gatau kayak gimana??)
• Product manual  x (gatau kayak gimana?? Yang kuingat, harus ada manual untuk setiap actor yang kita definisikan)

B. Product-Related Documentation  Katanya ini mengikuti PPL (PJ Fitra)
• Survey and results
• Summary of user inputs
• Intranet site content
• Intranet site design documents
• Test plans and reports
• Intranet site promotion information
• Intranet site roll-out information
• Project benefits measurement information

Terus buat UAS MPPL maupun PPL:
1. Menurut saya, semua anggota sebaiknya mengetahui tentang semua dokumen yang sudah disebutkan di atas. Jadi, pas hari jumat tanggal 11 ntar juga semua dokumen di atas (kecuali yang bener-bener belum bisa dibuat) dimasukin ke dalam satu folder terus semua anggota ngopi folder itu
2. UAS akan diadakan perorangan dengan dua tipe soal (persentasenya belum tahu seperti apa), tipe pertama adalah pemahaman akan materi MPPL itu sendiri (ya knowledge area, project management, dan lain-lain), dan tipe kedua adalah soal-soal berhubungan dengan proyek yang kita kerjakan (nah untuk inilah perlu hal yang saya sebutkan di poin sebelumnya) – termasuk ada juga evaluasi tentang kuliah ini (misalnya di kelompok kita siapa paling GB, siapa paling kerja keras, bagaimana perkuliahannya, dan sebagainya)

 

Things to do bwt PPL dari Fajrin

Bikin things to do yang sama seperti yang MPPL ya.. di-list aja… misalnya:

1. Pengubahan database ke dalam metode spatial dan temporal database atau dengan penanganan fungsi khusus untuk mengatur hal ini (PJ Fajrin dan Dadan)

Untuk hal ini, kami butuh asumsi (diputuskan saja), jika kendaraan itu tersedia, dalam kenyataannya kan dia tuh sebenernya berada di posisi/cabang tertentu, nah misalnya kendaraan pickup ada di cabang Jakarta, nah misalnya ada cabang Solo yang ingin mesan kendaraan tersebut misalnya minggu depan, pada kasus seperti ini:
 apakah pesanan tidak bisa dilakukan? – jadi asumsinya, kendaraan harus masih berada di cabang yang sama dengan cabang tempat online
 atau pesanan bisa dilakukan? – jadi asumsinya, selalu ada petugas yang mengantarkan kendaraan ke tempat pesanan mulai dilakukan (dalam waktu dari sekarang sampai minggu depan itu..)

Saya (Fajrin) lebih memilih opsi kedua

2. Use case masing-masing disempurnakan – hal yang perlu disempurnakan antara lain notifikasi, alert yang menyatakan yakin atau tidak (do you really want to delete blabla? Yes or no) (PJ ya penanggungjawab masing-masing use case)

3. Pengintegrasian databaseconnect ke dalam objek masing-masing (PJ Zaky)

4. Pembuatan list untuk menampilkan objek-objek yang berjumlah lebih dari satu (PJ anggota-anggota yang memerlukan penampilan objek lebih dari satu seperti report-nya Fajrin, user-nya Zaky, sama reservation-nya Nashir)

5. Finalisasi dokumen.. PJ Fitra, mengintegrasikan bagian-bagian – ketika menemukan ketidakcocokan, langsung beritahu kepada anggota yang bertanggungjawab akan itu

6. Manajemen Role (user mana bisa mengakses menu bagian mana saja – PJ tentukan ya)

7. User interface – sudah bagus sih.. tapi sepertinya masih bisa diperbagus lagi – PJ tentukan ya)

8. Lain-lain.. (belum kepikiran.. coba liat di notulen tiap asistensi).. Inget ya.. deadlinenya hari jumat tanggal 11 Maret jam 11.00, demonya antara hari Senin-Rabu (14-16 Maret), setelah itu:
4 - 7 Juni : Perbaikan Akhir
8 Juni jam 11.00 : Serah Terima Hasil Proyek
Deliverables:
1. Dokumen (termasuk manual) sudah dijilid dan Leaflet
2. CD berisi: softcopy dokumen, software, dan leaflet
14 Juni : Pengumuman Nilai Akhir

Terus buat UAS MPPL maupun PPL:
1. Menurut saya, semua anggota sebaiknya mengetahui tentang semua fitur program yang sudah disebutkan di atas. Jadi, pas hari jumat tanggal 11 ntar juga semua perbaikan program di atas dimasukin ke dalam satu folder terus semua anggota ngopi folder itu
2. UAS akan diadakan perorangan dengan dua tipe soal (persentasenya belum tahu seperti apa), tipe pertama adalah pemahaman akan materi MPPL itu sendiri (ya knowledge area, project management, dan lain-lain), dan tipe kedua adalah soal-soal berhubungan dengan proyek yang kita kerjakan (nah untuk inilah perlu hal yang saya sebutkan di poin sebelumnya) – termasuk ada juga evaluasi tentang kuliah ini (misalnya di kelompok kita siapa paling GB, siapa paling kerja keras, bagaimana perkuliahannya, dan sebagainya)

 

Demo konstruksi I

Notulen demo PPL konstruksi I, 3 Mei 07
1. cancel reservation by sms
- Belum validasi semuanya
- belum menangani kasus error
- validasi Id no. HP dijadikan prekondisi
- lengkapi program sesuai dengan skenario usecase
- pada sequence diagram. bedakan tanda panah untuk method dan return
- send reservation() –> gak ada trigger

2. Check Vehicle Position by sms
- prekondisi diperbaiki
- isi sms untuk posisi kendaraan ditambah “dimana menuju kemana”
- kasus ID salah dibuat skenario alternatif
- kelas DBConnect dilebur dengan kelas objek

3. Manage Report
- Bikin skenario alternatif
- Aktribut laporan. bikin tabel di bawah ini:
+ per periode. mis tgl sekian sampe tgl sekian
+ per harian (calendar)
+ per bulanan, tahunan (dropdown list)
+ sequence diagram GANTI

4. Update vehicle position
- notifikasi –> tambah tombol BACK

5. Cancel Reservasi Automatic
- gunakan ALERT untuk menghapus/update/dll

 

Deadline MPPL

Tugas 3 IF3261 MPPL
(tugas kelompok, sesuai kelompok PPL)

1. List Activity, berupa daftar aktivitas/work package dari WBS
yang berisi a.l.: Id, Nama, Deskripsi, Predecessor, Resource,
dan ket lain yg perlu
Tambahkanlah Milestone
2. Network Diagram
3. Schedule dalam bentuk Gantt Cart
4. ?Milestone Report? sampai dengan status tgl 22 Maret 2007
(contoh terlampir)

Tugas ini merupakan kelanjutan dari Tugas 1 dan Tugas 2 sebelumnya.
Diperkenankan utk melakukan perubahan/penyempurnaan thd Tugas 1
dan/atau Tugas 2 sebagai acuan dari Tugas 3 ini.

Tugas dikumpulkan sebelum jam 12.00 tgl 23 Maret 2007
di Lab RPL (asisten MPPL) dalam bentuk hardcopy.

Agar diperhatikan

Salam,

Adi Mulyanto