REKAYASA PERANGKAT LUNAK

Dr. Ratna Wardani Prodi PTI Fakultas Teknik Universitas Negeri Yogyakarta

Pendidikan dan Latihan Profesi Guru

Materi
1 2 3
Tentang Kurikulum Rekayasa Perangkat Lunak

Tools Pengembangan

TENTANG KURIKULUM

IEEE Computing Curricula 2005

Pembagian Domain Keilmuan

Rekayasa Perangkat Lunak

Kata Kunci

Level SMK di bidang RPL

Pemahaman yang salah tentang RPL

Apa yang Dipelajari dalam RPL

Kendala

REKAYASA PERANGKAT LUNAK

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

Analisis Sistem

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

Analisis Sistem

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 tingkattingkat yang merepresentasikan aliran informasi yang bertambah dan fungsi ideal.

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)

Aplikasi Cash Register:
Data yang menjadi masukan PL

Cash Register

Pelangga n 1. Menyerahkan barang

2. 3. 4. 5. 6. Mencatat data penjualan Memberikan pembayaran Mencatat data pembayaran Mencetak struk Menerima struk, barang, dan kembalian

Kasir
Data yang menjadi keluaran PL

lingkup/konteks perangkat lunak

sumber/tujuan data (entitas eksternal)

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)

penjualan

pembayaran

Kasir

Aplikasi Cash Register

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

e1 [nil]

S1
e2 [t_process t_user] Pre(Initial()) Get(eMule-installer.exe, http:// sourceforge.net, t_user <= 10 ) Post(S2 S3) e3 [t_process > t_user]

S2
Pre(S1 S3) NormalDL(eMule-installer.exe, http://sourceforge.net, t_user <= 10 ) Post(S4) e4 [t_process t_user]

S3
Pre(S1) Retry(eMule-installer.exe, http://sourceforge.net, t_user <= 10 ) Post(S2 S5)

e5 [true]

e6 [t_process > t_user]

S4
Pre(S2) SaveTo(eMule-installer.exe, http://sourceforge.net, MyDirectory, true ) Post(End)

S5
Pre(S3) BackgroundDL(eMuleinstaller.exe, http:// sourceforge.net, t_process > 10 ) Post(S6) e7 [true]

S6
Pre(S5) SendEmail(eMule-installer.exe, ratna@uny.ac.id, true ) Post(End)

Model to Design

procedural design
EntityRelationship Diagram Data Flow Diagram Data Dictionary

interface design architectural design

State-Transition Diagram

data design

Model to Design

Data design mengubah model informasi (entity relationship

data dictionary) menjadi struktur data

diagram dan

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
I. II. III. IV. V.

VI.
VII.

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

SADT

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)

Aplikasi Cash Register:
Data yang menjadi masukan PL

Cash Register

Pelanggan
1. 2. 3. 4. 5. 6. Menyerahkan barang Mencatat data penjualan Memberikan pembayaran Mencatat data pembayaran Mencetak struk Menerima struk, barang, dan kembalian

Kasir
Data yang menjadi keluaran PL

lingkup/konteks perangkat lunak

sumber/tujuan data (entitas eksternal)

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)

penjualan

pembayaran

Kasir

Aplikasi Cash Register

struk

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)

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

1 2 3
Basis Data

Diagram Aliran Data (DAD)

Kasir
penjualan 1 Catat Data Penjualan Jual Barang

Workstation

Pelanggan
1. Menyerahkan barang

Kasir
1. Catat data penjualan

1. Baca kode barang 2. Cari dan tampilkan Spesifikasi data barang Proses 3. Baca banyak barang 4. Hitung dan tampilkan jumlah 5. Rekam data penjualan ke basis data; update stok barang

Kamus Data
1. barang yang dibeli 2. penjualan = kode_brg + banyak 3. Barang = @kode_brg + nama_brg + harga + stok 4. Jual = @no_faktur + @kode_brg + banyak

Sketsa Tampilan Layar

Entry Penjualan Barang Kode Barang Nama Barang Harga (Rp.) Banyaknya Jumlah (Rp.)
Rekam

BRG-101 KERTAS A4 80 GR. 27,500 2 55,000

Workflow Pembayaran
5 6 7
Basis Data

Diagram Aliran Data (DAD)

Kasir
penjualan Barang

Workstation

Spesifikasi 1. Hitung dan tampilkan total Proses 1. Memberikan 1. Akhiri 2. Baca jumlah bayar pembayaran penjualan 3. Hitung dan tampilkan 2. Menerima struk, 2. Catat data jumlah kembalian barang dan pembayaran; 4. Rekam data pemkembalian cetak struk bayaran ke basis data 5. Cetak struk

Pelanggan

Kasir

pembayaran struk

1 Catat Data Penjualan

total Jual

2 Catat Data Pembayaran & Cetak Struk Bayar

Kamus Data
1. barang yang dibeli 2. penjualan = kode_brg + banyak 3. Barang = @kode_brg + nama_brg + harga + stok 4. Jual = @no_faktur + @kode_brg + banyak 5. uang 6. pembayaran = jml_bayar 7. Bayar = @no_faktur + tanggal + total 8. struk = no_faktur + tanggal + {nama_brg + harga + banyak + jumlah} + total + bayar + kembali 9. struk, barang dan kembalian total = no_faktur + {kode_brg + nama_brg + harga + banyak} + total

Sketsa Tampilan Layar

Entry Penjualan Barang Entry Pembayaran Total Kode (Rp.) Barang Nama Barang Jumlah Bayar Harga (Rp.) Kembali Banyaknya Jumlah (Rp.) 55,000 BRG-101 60,000 KERTAS A4 80 GR. 27,500 5,000 2 55,000 X

Rekam Cetak Struk Pembayaran

47

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)

Data Store 1. Barang = @kode_brg + nama_brg + harga + stok 2. Bayar = @no_faktur + tanggal + total 3. Jual = @no_faktur + @kode_brg + 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

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)

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

Pemodelan Fungsional dan Aliran Informasi (Analisis Terstruktur)

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.

Pemodelan Fungsional dan Aliran Informasi

ERD (versi Peter Chen)

BARANG 1

PEMBAYARAN

dijual-pd

PENJUALAN

dilunasi-dg

Pemodelan Fungsional dan Aliran Informasi

ERD (versi James Martin (Conceptual Data Model)

BARANG dijualpd PENJUALAN

PEMBAYARAN dilunasi -dg

TOOLS PENGEMBANGAN

Data Flow Diagram

Data Flow Diagrams Symbols

DeMarco & Yourdon
Source/ Sink

System Analysis and Design

System a group of interrelated procedures used for a business function, with an identifiable boundary, working together for some purpose. 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 Logical Data Flow Diagrams show the data flow, structure, and requirements of a new system

DATA STORE

Data Flow Lines

Data Flow Diagrams Symbols

DeMarco & Yourdon
Source/ Sink

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.

0.0 Process

DATA STORE

Data Flow Lines

Data Flow Diagrams Symbols

DeMarco & Yourdon
Source/ Sink

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.

0.0 Process

DATA STORE

Data Flow Lines

Data Flow Diagrams Symbols

DeMarco & Yourdon
Source/ Sink

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

0.0 Process

DATA STORE

Data Flow Lines

Data Flow Diagrams Symbols

DeMarco & Yourdon
Source/ Sink

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.

0.0 Process

DATA STORE

Data Flow Lines

Data Flow Diagrams Levels

DeMarco & Yourdon Context Level DFD
Source/ Sink
Source/ Sink

Data Flow Data Flow

0.0 Process

Data Flow

Source/ Sink

Level 1 DFD
0.0 Process
Data Flow Data Flow
1.0 Process

Data Flow

DATA STORE

Source/ Sink

Data Flow

2.0 Process

Data Flow

Source/ Sink

Data Flow Lines

Data Flow
3.0 Process

Data Flow

Data Flow Diagrams Levels

DeMarco & Yourdon
Source

Level 2 DFD (and on)

Source/ Sink

Data Flow

1.1 Process

DATA STORE

0.0 Process

Source

Data Flow

1.2 Process

DATA STORE
Data Flow
Sink

Data Flow Lines

Data Flow Diagrams Levels

Project Name Context Level DFD
Data Flow
Prepared by: yourname Date: 01/01/2002

Project Name Level 2 DFD

Prepared by: yourname Date: 01/01/2002

1.1 Process

DATA STORE

Source/ Sink

Data Flow Data Flow

0.0 Process

Project Name
Data Flow
Source/ Sink

Prepared by: yourname Date: 01/01/2002

Data Flow

1.2 Process

Level 2 DFD

Project Name Level 1 DFD

Prepared by: yourname Date: 01/01/2002

Data Flow

Data Flow
1.1 Process DATA STORE

Project Name
1.0 Process

Prepared by: yourname

Date: 01/01/2002

Data Flow
Data Flow Data Flow
Source/ Sink 1.1 Process

1.2 Process

Level 2 DFD

Data Flow Data Flow

2.0 Process

Source/ Sink

Data Flow

Data Flow

Data Flow
DATA STORE

Data Flow
3.0 Process

Data Flow Data Flow

1.2 Process

Data Flow

Creating Data Flow Diagrams

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

Creating Data Flow Diagrams

Lemonade Stand Example

Creating Data Flow Diagrams

Example
The operations of a simple lemonade stand will be used to demonstrate the creation of dataflow diagrams.

Steps:
1. Create a list of activities 2. Construct Context Level DFD (identifies sources and sink) 3. Construct Level 1 DFD (identifies manageable sub processes ) 4. Construct Level 2- n DFD (identifies actual data flows and data stores )

Creating Data Flow Diagrams

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

Creating Data Flow Diagrams

Example
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 1. Create a list of activities

Creating Data Flow Diagrams

Example
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 1. Create a list of activities

Creating Data Flow Diagrams

Example
Create a context level diagram identifying the sources and sinks (users). Customer Order Serve Product Collect Payment Produce Product Store Product
CUSTOMER

2. Construct Context Level DFD (identifies sources and sink)

Context Level DFD

Order Sales Forecast
0.0 Lemonade Production Schedule EMPLOYEE Pay System

Product Served Payment Received Goods Payment

Time Worked Purchase Order

VENDOR

Order Raw Materials Pay for Raw Materials

Pay for Labor

Creating Data Flow Diagrams

Example
Create a level 1 diagram identifying the logical subsystems that may exist. Customer Order Serve Product Collect Payment Produce Product Store Product
VENDOR

3. Construct Level 1 DFD (identifies manageable sub processes )

Level 1 DFD
1.0 Sale

Customer Order Product Ordered Payment

CUSTOMER

Sales Forecast

Product Served Received Goods Purchase Order Payment

2.0 Production

Production Schedule

EMPLOYEE

Inventory
3.0 Procurement

Order Raw Materials Pay for Raw Materials

Pay for Labor

Order Decisions Pay Time Worked

4.0 Payroll

Creating Data Flow Diagrams

Example
Create a level 2 decomposing the processes in level 0 and identifying data stores. Customer Order Serve Product Collect Payment Produce Product Store Product
Payment
1.2 Receive Payment PAYMENT

4. Construct Level 2- n DFD (identifies actual data flows and data stores )

Level 2 DFD
CUSTOMER

Customer Order
ORDER 1.1 Record Order

Request for Forecast

Severed Order

1.3 Produce Sales Forecast

Sales Forecast

Order Raw Materials Pay for Raw Materials

Pay for Labor

Creating Data Flow Diagrams

Example
Create a level 2 decomposing the processes in level 0 and identifying data stores. Customer Order Serve Product Collect Payment Produce Product Store Product 4. Construct Level 2 (continued)

Level 2 DFD
Product Order
ORDER 2.1 Serve Product

Quantity Severed
RAW MATERIALS

Production Schedule
2.2 Produce Product

Quantity Used
INVENTORTY

Order Raw Materials Pay for Raw Materials

Pay for Labor

Production Data
2.3 Store Product

Quantity Produced & Location Stored

Creating Data Flow Diagrams

Example
Create a level 2 decomposing the processes in level 0 and identifying data stores. Customer Order Serve Product Collect Payment Produce Product Store Product 4. Construct Level 2 (continued)

Level 2 DFD
Order Decision
3.1 Produce Purchase Order

PURCHASE ORDER

Quantity On-Hand Quantity Received

RAW MATERIALS

Received Goods
3.2 Receive Items

Payment Approval

RECEIVED ITEMS

Order Raw Materials Pay for Raw Materials

Pay for Labor
Payment

3.3 Pay Vendor

VENDOR

Creating Data Flow Diagrams

Example
Create a level 2 decomposing the processes in level 0 and identifying data stores. Customer Order Serve Product Collect Payment Produce Product Store Product 4. Construct Level 2 (continued)

Time Worked
4.1 Record Time Worked

Level 2 DFD
TIME CARDS

Employee ID
EMPLOYEE

Payroll Request
4.2 Calculate Payroll

Unpaid time cards

PAYROLL

Payment Approval

Order Raw Materials Pay for Raw Materials

Pay for Labor
Payment

4.3 Pay Employe e

PAYMENTS

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 Procurement

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 Employe e

Context Level

Level 1

Level 2

Creating Data Flow Diagrams

Lemonade Stand Example

END