Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak
Dr. Ratna Wardani Prodi PTI Fakultas Teknik Universitas Negeri Yogyakarta This template can be used as a starter file for presenting training materials in a group setting. Sections Right-click on a slide to add sections. Sections can help to organize your slides or facilitate collaboration between multiple authors. Notes Use the Notes section for delivery notes or to provide additional details for the audience. View these notes in Presentation View during your presentation. Keep in mind the font size (important for accessibility, visibility, videotaping, and online production) Coordinated colors Pay particular attention to the graphs, charts, and text boxes. Consider that attendees will print in black and white or grayscale. Run a test print to make sure your colors work when printed in pure black and white and grayscale. Graphics, tables, and graphs Keep it simple: If possible, use consistent, non-distracting styles and colors. Label all graphs and tables.

Pendidikan dan Latihan Profesi Guru
This is another option for an Overview slides using transitions.

Materi 1 2 3 Tentang Kurikulum Rekayasa Perangkat Lunak
Tools Pengembangan 3 This is another option for an Overview slide.

Tentang Kurikulum Use a section header for each of the topics, so there is a clear transition to the audience.

IEEE Computing Curricula 2005
What will the audience be able to do after this training is complete? Briefly describe each objective how the audience will benefit from this presentation.

Pembagian Domain Keilmuan

Kata Kunci What will the audience be able to do after this training is complete? Briefly describe each objective how the audience will benefit from this presentation.

Level SMK di bidang RPL What will the audience be able to do after this training is complete? Briefly describe each objective how the audience will benefit from this presentation.

Pemahaman yang salah tentang RPL

Apa yang Dipelajari dalam RPL

Kendala What will the audience be able to do after this training is complete? Briefly describe each objective how the audience will benefit from this presentation.

Use a section header for each of the topics, so there is a clear transition to the audience.

Tahapan Proses RPL Tahap umum: Definisi: Apa yang akan dibangun
Analisis sistem Perencanaan Proyek Analisis Kebutuhan Pengembangan: Bagaimana membangunnya Desain perangkat lunak Pemrograman / Coding Pengujian perangkat lunak Pemeliharaan: Bagaimana berdaptasi terhadap perubahan Koreksi Adaptasi Peningatan What will the audience be able to do after this training is complete? Briefly describe each objective how the audience will benefit from this presentation.

Analisis Sistem What will the audience be able to do after this training is complete? Briefly describe each objective how the audience will benefit from this presentation.

Analisis Sistem Elemen:

Analisis Sistem Data Dictionary : deskripsi semua objek data dalam S/W
Entity Relationship Diagram : notasi pemodelan data yang menggambarkan hubungan antar objek data Data Flow Diagram : model fungsional, dengan tujuan menunjukkan transformasi data saat data bergerak melalui sistem menunjukkan fungsi-fungsi yg mentransformasi aliran data State Transition Diagram : model tingkah laku, yg menunjukkan transisi state/tingkah laku sistem akibat kejadian eksternal What will the audience be able to do after this training is complete? Briefly describe each objective how the audience will benefit from this presentation.

Analisis Sistem What will the audience be able to do after this training is complete? Briefly describe each objective how the audience will benefit from this presentation.

Pemodelan Data ERD memungkinkan perekayasa S/W mengidentifikasi objek data dan hubungannya menggunakan notasi grafis (data yg dimasukkan, disimpan, ditransformasi dan dihasilkan suatu aplikasi) ERD hanya berfokus pada data dan bersifat independen thd proses yg mentransformasikan data tersebut Model data terdiri dari tiga informasi utama : Objek data Atribut Hubungan

Objek Data Objek data adalah representasi dari hampir semua informasi gabungan yg harus dipahami perangkat lunak Objek data dapat berupa entitas eksternal, benda, event, unit organisasional, tempat atau suatu struktur Deskripsi objek data menghubungkan objek data dg semua atributnya Objek data dihubungkan satu sama lain berdasarkan konteks masalah yg dianalisis Objek data hanya mengenkapsulasi data, tidak ada referensi pd sebuah objek data ke operasi yg bekerja pada data

Atribut Atribut menentukan properti suatu objek data
Atribut digunakan untuk menamai sebuah contoh dari objek data Menggambarkan contoh Membuat referensi ke contoh lain pada tabel yang lain Contoh : objek data manusia, memiliki atribut : nama, alamat, umur, tinggi badan. Rangkaian atribut yang sesuai untuk suatu objek data ditentukan melalui pemahaman konteks masalah

Hubungan Objek data dihubungkan satu dan lainnya dengan berbagai cara
Contoh : Antara dua objek data buku dan toko buku dapat dibangun suatu hubungan berdasarkan konteks perangkat lunak yg akan dibangun (dg object-relationship pairs) : toko buku memesan buku toko buku menampilkan buku toko buku menjual buku toko buku mengembalikan buku

Kardinalitas Kardinalitas merupakan spesifikasi dari sejumlah peristiwa dari satu objek yg dapat dihubungkan ke sejumlah peristiwa dari objek lain Dua objek dapat dihubungkan sebagai : Satu-ke-satu : suatu kejadian dari objek A dapat berhubungan dg satu dan hanya satu kejadian dari objek B dan sebaliknya Satu-ke-banyak : satu kejadian dari objek A dapat berhubungan dg satu atau lebih kejadian dari objek B, tetapi satu kejadian dari objek B dapat berhubungan dg hanya satu kejadian dari objek B Banyak-ke-banyak : sebuah kejadian dari objek A dapat berhubungan dg satu atau lebih kejadian dari objek B, dan satu kejadian dari objek B dapat berhubungan dg satu atau lebih kejadian dari objek A

Pemodelan Fungsional dan Aliran Informasi
DFD merupakan teknik grafis yang menggambarkan aliran informasi dan transformasi yang diaplikasikan pada saat data bergerak dari input menjadi output. DFD memberikan suatu mekanisme bagi pemodelan fungsional dan pemodelan aliran data DFD dapat menyajikan perangkat lunak pada setiap tingkat abstraksi, karena DFD dapat dipartisi ke dalam tingkat-tingkat yang merepresentasikan aliran informasi yang bertambah dan fungsi ideal.

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)
Kasir Pelanggan lingkup/konteks perangkat lunak sumber/tujuan data (entitas eksternal) Aplikasi Cash Register: 2 4 5 Data yang menjadi masukan PL 1. Menyerahkan barang 2. Mencatat data penjualan 3. Memberikan pembayaran 4. Mencatat data pembayaran 5. Mencetak struk 6. Menerima struk, barang, dan kembalian Data yang menjadi keluaran PL 1 3 6

Aplikasi Cash Register Kasir penjualan pembayaran struk

Pemodelan Tingkah Laku
STD merepresentasikan tingkah laku sistem dengan menggambarkan keadaan dan kejadian yang menyebabkan sistem mengubah keadaan Dalam STD, suatu aksi diambil sebagai akibat dari suatu kejadian khusus

Pemodelan Tingkah Laku

Model to Design

Model to Design Data design
 mengubah model informasi (entity relationship diagram dan data dictionary) menjadi struktur data Architectural design  berisi hubungan antar elemen dalam program Interface design  menjelaskan bagaimana komunikasi di dalam perangkat lunak, dengan sistem, dan dengan manusia yang menggunakannya.  Sebuah interface mengandung maksud sebuah aliran informasi.

Model to Design Procedural design
 mengubah elemen struktural dari arsitektur program menjadi deskripsi prosedural dari komponen perangkat lunak

Model to Design Sebuah desain harus menunjukkan organisasi secara hirarkis Sebuah desain harus bersifat modular; jadi, sebuah perangkat lunak seharusnya dapat dibagi-bagi secara lojik menjadi beberapa elemen yang melakukan fungsi atau subfungsi secara spesifik Sebuah desain harus mengandung abstraksi data dan prosedural Sebuah desain harus mengarah pada modul-modul (prosedur atau subrutin) yang menunjukkan karakteristik fungsional

Model to Design Sebuah desain harus mengarah pada antarmuka yang mengurangi kompleksitas hubungan antar modul dan dengan lingkungan luar Sebuah desain harus diturunkan menggunakan metode yang berulang yang diarahkan oleh informasi yang dihasilkan pada tahap analisis perangkat lunak

Model to Design Proses desain tidak boleh mengalami “tunnel vision”
Desain harus dapat dilacak ke model analisis Tidak melakukan desain pada hal yang sama berulang-ulang Desain harus merepresentasikan masalah pada keadaan nyata Desain harus memperlihatkan keseragaman dan integrasi

Model to Design Desain harus terstruktur untuk mengatisipasi adanya perubahan Desain bukan coding, coding bukan desain Penilaian kualitas desain harus dilaksanakan pada saat desain tersebut dibuat Desain harus di-review untuk meminimasi kesalahan konseptual

Konsep Desain Abstraksi Modularitas Arsitektur software
Hirarki kontrol Pembagian struktural Data struktur Software procedure Penyembunyian informasi

Dokumentasi Desain Lingkup Sistem Desain Data Desain Architectural
Desain Antarmuka Desain Prosedural Catatan Khusus Appendix

Data Design Mengubah objek data yang didefinisikan pada model analisis menjadi struktur data yang ada dalam perangkat lunak Atribut yang dimiliki objek data, hubungan di antara objek data, dan penggunaannya dalam program, semuanya mempengaruhi pemilihan struktur data

Architectural Design Menggunakan karakteristik aliran informasi dalam model analisis untuk menghasilkan struktur program Sebuah data flow diagram dipetakan menjadi struktur program menggunakan dua pendekatan : Transform mapping Transaction mapping Transform mapping : diterapkan untuk sebuah aliran data yang menunjukkan batas yang jelas antara data yang masuk dan yang keluar

Architectural Design DFD dipetakan menjadi sebuah struktur yang mengalokasikan kontrol menjadi input, pemorsesan, dan output bersama dengan hirarki modul Transaction mapping : diterapkan jika sebuah item informasi menyebabkan percabangan DFD dipetakan menjadi sebuah struktur yang mengalokasikan kontrol menjadi sebuah substruktur yang mendapatkan dan mengevaluasi sebuah transaksi

Interface Design Meliputi antarmuka program internal dan eksternal serta desain untuk antarmuka pengguna Desain antarmuka internal dan eksternal diarahkan oleh informasi yang diperoleh dari model analisis

Kasir Pelanggan lingkup/konteks perangkat lunak sumber/tujuan data (entitas eksternal) Aplikasi Cash Register: 2 4 5 Data yang menjadi masukan PL 1. Menyerahkan barang 2. Mencatat data penjualan 3. Memberikan pembayaran 4. Mencatat data pembayaran 5. Mencetak struk 6. Menerima struk, barang, dan kembalian Data yang menjadi keluaran PL 1 3 6

Aplikasi Cash Register Kasir penjualan pembayaran struk

Merupakan pemerincian (break down) dari Diagram Konteks: level-1, 2, dst. Proses-proses yang akan dibuat harus sesuai dengan deskripsi kebutuhan fungsionalnya. Alur dan urutan proses mengikuti mekanisme proses pengolahan data yang nanti akan dilakukan oleh perangkat lunak.

Workflow Penjualan Barang Diagram Aliran Data (DAD)
Kasir Pelanggan Workflow Penjualan Barang 1. Menyerahkan barang 1 1. barang yang dibeli 1. Catat data penjualan 2 2. penjualan Entry Penjualan Barang X Kode Barang BRG-101 = kode_brg 3 3. Barang + nama_brg + harga + stok Nama Barang KERTAS A4 80 GR. Harga (Rp.) 27,500 Banyaknya Jumlah (Rp.) 55,000 + banyak Rekam 1. Baca kode barang 2. Cari dan tampilkan data barang 4. Hitung dan tampilkan jumlah 5. Rekam data penjualan ke basis data; update stok barang 4 4. Jual + banyak 3. Baca banyak barang Diagram Aliran Data (DAD) Catat Data Penjualan Barang Jual Kamus Data Spesifikasi Proses Sketsa Tampilan Layar

Catat Data Pembayaran & Cetak Struk
Workflow Pembayaran Diagram Aliran Data (DAD) Kasir Pelanggan 5 6 1 Catat Data Penjualan penjualan Kasir Barang Jual 7 9 8 pembayaran 1. Hitung dan tampilkan total Spesifikasi Proses 1. Memberikan pembayaran 1. Akhiri penjualan struk 2. Baca jumlah bayar total 3. Hitung dan tampilkan jumlah kembalian 2 Catat Data Pembayaran & Cetak Struk 2. Menerima struk, barang dan kembalian 2. Catat data pembayaran; cetak struk 4. Rekam data pembayaran ke basis data 5. Cetak struk Bayar Kamus Data Sketsa Tampilan Layar 3. Barang + nama_brg + harga + stok 1. barang yang dibeli 2. penjualan = kode_brg + banyak 4. Jual + banyak Entry Penjualan Barang X Kode Barang BRG-101 Nama Barang KERTAS A4 80 GR. Harga (Rp.) 27,500 Banyaknya 2 Jumlah (Rp.) 55,000 Rekam Entry Pembayaran X Total (Rp.) 55,000 Jumlah Bayar 60,000 5. uang Kembali 5,000 6. pembayaran = jml_bayar 7. Bayar + tanggal + total 8. struk = no_faktur + tanggal + {nama_brg + harga + banyak + jumlah} + total + bayar + kembali Cetak Struk Pembayaran 9. struk, barang dan kembalian total = no_faktur + {kode_brg + nama_brg + harga + banyak} + total

Data Store 1. Barang + nama_brg + harga + stok 2. Bayar + tanggal + total 3. Jual + banyak Data Flow 1. pembayaran = jml_bayar 2. penjualan = kode_brg + banyak 3. struk = no_faktur + tanggal + {nama_brg + harga + banyak + jumlah} + total + bayar + kembali 4. total = no_faktur + {kode_brg + nama_brg + harga + banyak} + total

Proses 1: Catat Data Penjualan 1. Baca kode barang 2. Cari dan tampilkan data barang 3. Baca banyak barang; Hitung dan tampilkan jumlah 4. Rekam data penjualan ke basis data; Update stok barang Proses 2: Catat Data Pembayaran & Cetak Struk 1. Hitung dan tampilkan total 2. Baca jumlah bayar; Hitung dan tampilkan jumlah kembalian 3. Rekam data pembayaran ke basis data 4. Cetak struk

Dari DFD yang sudah dibuat, identifikasi data yang akan diolah: Data transaksi penjualan Data transaksi pembayaran Data barang Tentukan data mana yang mewakili entitas: Penjualan, pembayaran  event Barang  things Tentukan relasi antar entitas.

ERD (versi Peter Chen) BARANG PENJUALAN PEMBAYARAN dijual-pd dilunasi-dg 1 n

ERD (versi James Martin (Conceptual Data Model) BARANG PENJUALAN PEMBAYARAN dijual-pd dilunasi-dg

Tools Pengembangan Use a section header for each of the topics, so there is a clear transition to the audience.

Data Flow Diagram Add a case study or class simulation to encourage discussion and apply lessons.

Data Flow Diagrams Symbols
DeMarco & Yourdon System Analysis and Design System – a group of interrelated procedures used for a business function, with an identifiable boundary, working together for some purpose. Source/ Sink Analysis – separation of a whole into its component parts 0.0 Process Design – to create, fashion, execute, or construct according to plan Physical Data Flow Diagrams – show how the current system flows DATA STORE Logical Data Flow Diagrams – show the data flow, structure, and requirements of a new system Data Flow Lines

DeMarco & Yourdon Source/Sink – help to establish the boundaries of the system. A source identifies the origin of data inflow to the system. A sink identifies the outflow of a system, many times as information. Sometimes referred to an entity, a source may be a customer, vendor, employee, or even another system. A single entity can be both a source and a sink. Source/ Sink 0.0 Process DATA STORE Data Flow Lines

DeMarco & Yourdon Processes – are the activities (manual and automated) that transform the inputs, transport data from process to process, stores the data, and produce the outputs of a system. Processes are used on every DFD starting with an over all process on the context level diagram, the system. The system is then decomposed until a primitive level is obtained. The primitive level is the point in which the relevant activities of a process are identified. Source/ Sink 0.0 Process DATA STORE Data Flow Lines

DeMarco & Yourdon Data Store – is the resting place of the data in a system. A data store can be in the form of paper, a disk file or any other media. Normally the word ‘data’ does not appear in the title of a data store. Some examples of data stores are Customer Order, Payment, Invoice, Time Card…… Source/ Sink 0.0 Process DATA STORE Data Flow Lines

DeMarco & Yourdon Data Flow – is the data in motion. Data can move from the outside (source) into a process. Once the inside of a system data must flow from place to place through a process, the flow lines show this movement. The lines are labeled to provide clarity and meaning to the data moving through the system. Source/ Sink 0.0 Process DATA STORE Data Flow Lines

Data Flow Diagrams Levels
DeMarco & Yourdon Context Level DFD Source/ Sink Source/ Sink 0.0 Process Source/ Sink Data Flow Data Flow Data Flow Level 1 DFD 0.0 Process 1.0 Process Data Flow Data Flow Data Flow DATA STORE Source/ Sink 2.0 Process Source/ Sink Data Flow Data Flow Data Flow Data Flow Lines 3.0 Process Data Flow

DeMarco & Yourdon Source Sink Level 2 DFD (and on) Source/ Sink Data Flow 1.1 Process DATA STORE 0.0 Process 1.2 Process Data Flow DATA STORE Data Flow Data Flow Lines

Creating Data Flow Diagrams
Steps: Create a list of activities Construct Context Level DFD (identifies sources and sink) Construct Level 1 DFD (identifies manageable sub process ) Construct Level 2- n DFD (identifies actual data flows and data stores )

Creating Data Flow Diagrams Lemonade Stand Example

Example Steps: The operations of a simple lemonade stand will be used to demonstrate the creation of dataflow diagrams. Create a list of activities Construct Context Level DFD (identifies sources and sink) Construct Level 1 DFD (identifies manageable sub processes ) Construct Level 2- n DFD (identifies actual data flows and data stores )

Example Create a list of activities Think through the activities that take place at a lemonade stand. Customer Order Serve Product Collect Payment Produce Product Store Product

Example Create a list of activities Also think of the additional activities needed to support the basic activities. Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Raw Materials Pay for Labor

Example Create a list of activities Group these activities in some logical fashion, possibly functional areas. Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Raw Materials Pay for Labor

Example Construct Context Level DFD (identifies sources and sink) Create a context level diagram identifying the sources and sinks (users). Context Level DFD Sales Forecast CUSTOMER 0.0 Lemonade System EMPLOYEE Order Production Schedule Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Raw Materials Pay for Labor Product Served Pay Payment Time Worked Received Goods Payment Purchase Order VENDOR

Example Construct Level 1 DFD (identifies manageable sub processes ) Create a level 1 diagram identifying the logical subsystems that may exist. Level 1 DFD 1.0 Sale Sales Forecast Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Raw Materials Pay for Labor Customer Order Product Ordered CUSTOMER Payment 2.0 Production EMPLOYEE Production Schedule Product Served Inventory Received Goods VENDOR 3.0 Procure-ment Purchase Order Order Decisions Payment Pay Time Worked 4.0 Payroll

Example Construct Level 2- n DFD (identifies actual data flows and data stores ) Create a level 2 decomposing the processes in level 0 and identifying data stores. Level 2 DFD CUSTOMER Customer Order Request for Forecast Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Raw Materials Pay for Labor ORDER 1.1 Record Order 1.3 Produce Sales Forecast Severed Order Payment Sales Forecast 1.2 Receive Payment PAYMENT

Example Construct Level 2 (continued) Create a level 2 decomposing the processes in level 0 and identifying data stores. Level 2 DFD Product Order ORDER 2.1 Serve Product Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Raw Materials Pay for Labor Quantity Severed RAW MATERIALS Production Schedule 2.2 Produce Product Quantity Used INVENTORTY Production Data 2.3 Store Product Quantity Produced & Location Stored

Example Construct Level 2 (continued) Create a level 2 decomposing the processes in level 0 and identifying data stores. Level 2 DFD Order Decision PURCHASE ORDER 3.1 Produce Purchase Order Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Raw Materials Pay for Labor Quantity On-Hand RAW MATERIALS Quantity Received Received Goods 3.2 Receive Items RECEIVED ITEMS Payment Approval 3.3 Pay Vendor VENDOR Payment

Example Construct Level 2 (continued) Create a level 2 decomposing the processes in level 0 and identifying data stores. Level 2 DFD Time Worked TIME CARDS 4.1 Record Time Worked Customer Order Serve Product Collect Payment Produce Product Store Product Order Raw Materials Pay for Raw Materials Pay for Labor Employee ID EMPLOYEE Payroll Request 4.2 Calculate Payroll Unpaid time cards PAYROLL Payment Approval 4.3 Pay Employee PAYMENTS Payment

Process Decomposition
1.0 Sale 1.1 Record Order 1.2 Receive Payment 2.0 Production 2.1 Serve Product 2.2 Produce Product 2.3 Store Product 0.0 Lemonade System 3.0 Procure-ment 3.1 Produce Purchase Order 3.2 Receive Items 3.3 Pay Vendor 4.0 Payroll 4.1 Record Time Worked 4.2 Calculate Payroll 4.3 Pay Employee Context Level Level 1 Level 2

Creating Data Flow Diagrams Lemonade Stand Example END

Rekayasa Perangkat Lunak

Presentasi serupa

Presentasi berjudul: "Rekayasa Perangkat Lunak"— Transcript presentasi:

Presentasi serupa

Tentang proyek

Tanggapan

Masuk

Otorisasi melalui jaringan sosial:

Rekayasa Perangkat Lunak

Presentasi serupa

Presentasi berjudul: "Rekayasa Perangkat Lunak"— Transcript presentasi:

Presentasi serupa

Tentang proyek

Tanggapan