Review Rekayasa Perangkat Lunak. Nisa ul Hafidhoh

Transkripsi

1 Review Rekayasa Perangkat Lunak Nisa ul Hafidhoh

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 Context Diagram 0 Pelayanan Bank

10 Context Diagram CS NASABAH 0 Pelayanan Bank TELLER BO

11 Context Diagram Data nasabah CS NASABAH Dokumen pendukung 0 Pelayanan Bank Daftar nasabah Info transaksi TELLER Data transaksi Informasi rekening nasabah Laporan harian Laporan per jenis Laporan nasabah baru BO

12 Overview Diagram Data nasabah Dokumen pendukung 1 Pembukaan Rekening Daftar nasabah Data transaksi Nasabah 3 Verifikasi & Posting Laporan harian Laporan per jenis Laporan nasabah baru Info transaksi 2 Pencatatan Transaksi Transaksi Rekening Informasi rekening nasabah

13 Contoh Level 2 Nasabah 2.1 Input Setoran Informasi transaksi setoran Info Transaksi 2.2 Validasi Transaksi Transaksi Rekening Informasi rekening nasabah 2.3 Cetak Transaksi

14 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 dibendakan 14

15 Review ERD Yang dimodelkan: Data dan hubungannya Elemen ERD: Objek Data Atribut Hubungan antar objek data 15

16 Review STD Yang dimodelkan: Aspek dinamis dalam PL Status dan kondisi yang menyebabkan perubahan Elemen: State Event Condition 16

17 Contoh STD Minuman dikeluarkan Terima koin baru Koin sah terdeteksi Terima permintaan Pembayaran mencukupi Keluarkan minuman Menunggu koin Menunggu masukan pilihan inisialisasi Terima koin baru Permintaan pengembalian koin Kembalikan pembayaran Minuman tersedia = 0 Kembalikan pembayaran Pembayaran dikembalikan Terima koin baru Mengembalikan pembayaran Mengeluarkan minuman 17

18 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 8 th ed, Roger S. Pressman 18

19 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 8 th ed, Roger S. Pressman 19

20 Analysis to Design [1] Transformasi model analisis terstruktur * SEPA 5 th ed, Roger S. Pressman 20

21 Analysis to Design [2] Transformasi model analisis OO * SEPA 8 th ed, Roger S. Pressman 21

22 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

23 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

24 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

25 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 Data-Centered Arsitektur Data Flow Arsitektur Call & Return Arsitektur OO Arsitektur berlayer 25

26 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

27 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