Review Rekayasa Perangkat Lunak
Nisa’ul Hafidhoh
[email protected]
Software Process • Sekumpulan aktivitas, aksi dan tugas yang dilakukan untuk mengembangkan PL – Aktivitas untuk mencapai tujuan umum (komunikasi dengan stakeholder) – Aksi meliputi serangkaian tugas (eg: desain arsitektur) yang menghasilkan produk utama (eg: model arsitektur) – Tugas fokus pada tujuan khusus yang menghasilkan keluaran yang terukur (eg: unit testing)
2
Common Process Framework • Communication
–Komunikasi dan kolaborasi dengan pelanggan untuk memahami tujuan dan mengumpulkan kebutuhan • Planning
–Menetapkan rencana kerja, risiko teknis, kebutuhan sumber daya, produk kerja yang dihasilkan, dan mendefinisikan jadwal kerja • Modeling
–Pembuatan model untuk membantu pengembang dan pelanggan memahami kebutuhan dan desain perangkat lunak • Construction
–Mengembangkan desain, code generation and testing • Deployment
–PL dikirim ke penguna untuk di evaluasi dan diberi feedback
3
Software Process Model • Prescriptive Models – The Waterfall Model – Incremental Models – Evolutionary Process Models (Prototyping, Spiral) • Specialized Process Models – Component-based development – Formal method model – Aspect-oriented programming
• The Unified Process • Agile Method (XP, Scrum, Crystal, Agile Modelling dll) 4
Analisis Perangkat Lunak • Proses pembangunan perangkat lunak untuk merepresentasikan kebutuhan perangkat lunak (perilaku, data, fungsi, dll) agar mudah dipahami • Dua model analisis yang biasa digunakan: – Terstruktur • Process oriented model (DFD) • Data oriented model (ERD) • Behavior model (Statechart Diagram)
– Berorientasi objek • Scenario based model (Use Case D., Activity D.) • Class based model (Class Diagram) • Behavior model (Sequence D., Interaction D.) 5
Analisis Terstruktur • Yang dimodelkan pada analisis terstruktur: – Pemodelan fungsi dan proses: DFD – Pemodelan data: ERD – Pemodelan perilaku: STD
• Keterkaitan antar model analisis: – Data store (DFD) vs. the entity / relationship (ERD) – Process (DFD) vs. action (STD) 6
Review DFD • Yang dimodelkan: – Proses dan aliran data antar proses – Proses pada DFD level 1 sesuai kebutuhan fungsionalitas PL
• Elemen DFD: – Data Flow, dilengkapi dengan label untuk menunjukkan data apa yang mengalir – Proses, yang menangani data – Data store, berada di dalam sistem – External/Outside entities/Terminator, Orang atau organisasi yang terletak di luar sistem dan pencetus atau penerima data. 7
Studi Kasus Bank Nusantara memiliki 3 jenis karyawan dengan tugas sebagai berikut : • Customer service : bertugas melayani nasabah dalam pembukuan rekening • Teller : bertugas melayani nasabah dalam melakukan transaksi penyetoran dan penarikan serta transfer. • Back office : bertugas melakukan verifikasi dan memposting data semua transaksi yang terjadi pada hari yang bersangkutan. 8
Context Diagram
0 Pelayanan Bank
Context Diagram CS
NASABAH
0 Pelayanan Bank
TELLER
BO
Context Diagram Data nasabah
CS
Daftar nasabah NASABAH
Dokumen pendukung
0 Pelayanan Bank
Info transaksi
TELLER
Data transaksi Informasi rekening nasabah Laporan harian Laporan per jenis Laporan nasabah baru
BO
Overview Diagram Data nasabah Dokumen pendukung
1 Pembukaan Rekening
Nasabah
Info transaksi
2 Pencatatan Transaksi
Informasi rekening nasabah
Daftar nasabah Data transaksi 3 Verifikasi & Posting
Transaksi Rekening
Laporan harian Laporan per jenis Laporan nasabah baru
Contoh Level 2
Nasabah
Info Transaksi
2.2 Validasi Transaksi
2.1 Input Setoran
Transaksi Rekening
Informasi transaksi setoran
2.3 Cetak Transaksi
Informasi rekening nasabah
Kesalahan Umum • Eksternal entity hanya muncul pada context diagram / diagram level 0 sebagai sumber / penerima data. • Data store baru mulai muncul saat overview diagram / level 1. • Data store bukanlah status dari sistem / proses. • Data flow adalah data yang berjalan dalam sistem bukan proses yang ada dalam sistem, bukan pula status sistem. • Penamaan data store sebaiknya menggunakan kata benda yang menggambarkan data secara ringkas dan penuh makna. • Proses bukanlah eksternal entity, penamaan sebaiknya menggunakan kata kerja atau kata kerja yang 14 dibendakan
Review ERD • Yang dimodelkan: – Data dan hubungannya
• Elemen ERD: – Objek Data – Atribut – Hubungan antar objek data
15
Review STD • Yang dimodelkan: – Aspek dinamis dalam PL – Status dan kondisi yang menyebabkan perubahan
• Elemen: – State – Event – Condition 16
Contoh STD inisialisasi Pembayaran dikembalikan Terima koin baru
Terima koin baru
Menunggu koin Koin sah terdeteksi
Permintaan pengembalian koin
Terima permintaan
Minuman dikeluarkan Terima koin baru
Menunggu masukan pilihan Pembayaran mencukupi Keluarkan minuman
Kembalikan pembayaran
Mengembalikan pembayaran
Minuman tersedia = 0 Kembalikan pembayaran
Mengeluarkan minuman
17
Perancangan Perangkat Lunak • Perancangan: mengumpulkan kebutuhan stakeholder, keperluan bisnis dan pertimbangan teknologi untuk memformulasikan suatu produk / sistem • Memodelkan aktivitas dan persiapan untuk tahap konstruksi (coding dan testing) • Goal : Memodelkan SOLUSI yang siap diimplementasikan (membuat program) * SEPA 8th ed, Roger S. Pressman
18
Yang dimodelkan? – Desain Arsitektur: Struktur Modul – Desain Antarmuka: • User interface (UI) • external interface untuk sistem lain, devices, networks • internal interface antar berbagai modul
– Desain Data: struktur data, arsitektur basis data – Desain Procedural / component level: algoritma
* SEPA 8th ed, Roger S. Pressman 19
Analysis to Design [1] • Transformasi model analisis terstruktur
* SEPA 5th ed, Roger S. Pressman 20
Analysis to Design [2] • Transformasi model analisis OO
* SEPA 8th ed, Roger S. Pressman
21
Elemen Desain PL • • •
•
•
Desain data / kelas Menciptakan model dari data dan objek yang diwakili pada abstraksi tingkat tinggi Desain arsitektur Menggambarkan tata letak keseluruhan dari perangkat lunak Desain antarmuka Menceritakan bagaimana informasi mengalir masuk dan keluar dari sistem dan bagaimana hal itu dikomunikasikan antara komponen didefinisikan sebagai bagian dari arsitektur Termasuk antarmuka pengguna, antarmuka eksternal, dan antarmuka internal Desain elemen komponen Menjelaskan detail internal tiap komponen perangkat lunak dengan cara definisi struktur data, algoritma, dan spesifikasi antarmuka Desain elemen deployment Menunjukkan bagaimana fungsi perangkat lunak dan subsistem akan dialokasikan dalam lingkungan komputasi fisik yang akan mendukung perangkat lunak 22
Desain Data • Pembuatan model data / informasi yang direpresentasikan pada abstraksi level tinggi (user’s view of data) menjadi representasi yang lebih spesifik dengan implementasi. Apa yang dihasilkan dari perancangan data ?
Struktur data Skema basis data Rancangan detil tiap tabel: Nama, deskripsi, volume, field, key, dll
23
Desain Data [2] Bagaimana tahapan merancang data (sederhana) ?
Review ERD Petakan menjadi skema basis data Entity tabel Relasi: N ke M jadi tabel 1 ke N jadi tabel 1 ke 1 dititipkan
24
Desain Arsitektur • Arsitektur PL adalah struktur yang terdiri atas komponen PL, properti komponen yang tampak dari luar dan hubungan antar komponen. [Bass, Clements, Kazman ‘03] • Gaya arsitektur PL: – Arsitektur – Arsitektur – Arsitektur – Arsitektur – Arsitektur
Data-Centered Data Flow Call & Return OO berlayer
25
Desain Antarmuka • Elemen-elemen perancangan antarmuka untuk perangkat lunak menjelaskan Bagaimana arus informasi masuk dan keluar dari sistem, dan bagaimana arus informasi tersebut berkomunikasi diantara komponen yang didefinisikan sebagai bagian dari arsitektur
• Desain antarmuka Inter-modular – Dikendalikan oleh aliran data antara modul
• Desain antarmuka eksternal – Antarmuka antar aplikasi – Antarmuka antar perangkat lunak dan produsen dan / atau konsumen informasi non-manusia
• Desain antarmuka manusia-komputer – Komunikasi antara manusia dan mesin 26
Pengujian • proses menganalisa suatu entitas software untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang tidak diinginkan (defect/errors/bugs) dan mengevaluasi fitur-fitur dari entitas software
• Metode Pengujian PL – Blackbox Testing • Disebut juga specification-based atau functional testing, tidak perlu mengetahui struktur software, hanya menguji fungsionalitas PL sudah berjalan sesuai yang diharapkan.
– Whitebox Testing • Harus mengetahui struktur dan implementasi dari software, meyakinkan bahwa semua statement / kondisi dieksekusi minimum satu kali. 27
