Rekayasa Perangkat Lunak (2). pdf

Rekayasa Perangkat Lunak/SI-TI

BAB I
PENGEMBANGAN SISTEM INFORMASI
Sistem Informasi
1. Suatu sistem adalah kombinasi sumber daya (entitas) untuk mengkonversi input menjadi
output (informasi).
2. Dalam setiap sistem, masing-masing bagian sistem saling berkoordinasi untuk
menyelesaikan suatu tugas, pekerjaan ataupun fungsi.
3. Informasi yang dihasilkan ditujukan ke bagian dalam organisasi yang relevan.ataupun
pihak yang membutuhkan informasi.

Pengembangan Sistem Informasi
1. Suatu proses pengaplikasian teknologi informasi untuk suatu tujuan atau menyelesaikan
suatu masalah.
2. Memilah suatu masalah yang besar dan kompleks menjadi beberapa bagian kecil yang
dapat diatur.

Beberapa Bentuk

PENDEKATAN DALAM

PENGEMBANGAN SISTEM INFORMASI
Pendekatan Berorientasi Proses
1.
2.
3.
4.
5.

Fokus pada alur, penggunaan dan transformasi data dalam suatu sistem informasi.
Menggunakan representasi grafik seperte Data Flow Diagram dan Bagan.
Data mengalir dari sumber ke tujuan melalui beberapa tahapan diantaranya.
Struktur data tidak dispesifikasikan.
Kerugian: Berkas Data bergantung pada bentuk aplikasi.

Pendekatan Berorientasi Data
1. Menggambarkan bentuk organisasi data yang tidak bergantung pada aplikasi.
2. Model data menggambarkan data dan hubungan bisnis antar data.
3. Aturan bisnis menggambarkan bagaimana organisasi merepresentasikan
memproses data.

dan

SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)
Fase Utama
1.
2.
3.
4.

Perencanaan : (Mengapa Mengembangkan Sistem ?)
Analisis
: (Siapa, apa, kapan dan dimana sistem ?)
Perancangan : (Bagaimana kerja sistem?)
Implementasi : (Bagaimana Sistem Dipasang/diinstal?)

Oleh : Wahju Tjahjo S.

1

Rekayasa Perangkat Lunak/SI-TI

Perencanaan
1.
2.
3.
4.
5.

Mengidentifikasikan Nilai Bisnis.
Analisis Kelayakan.
Membuat Rencana Kerja.
Mengatur Staff.
Mengontrol dan Mengarahkan Proyek.

Analisis
1.
2.
3.
4.

Analisis.
Mencari informasi yang terkait dengan sistem.
Menentukan model proses.
Menentukan model data.

Perancangan
1.
2.
3.
4.
5.

Perancangan Proses secara Fisik.
Perancangan Arsitektur Sistem.
Perancangan Interface.
Perancangan Basis Data dan Berkas.
Perancangan Program.

Implementasi
1. Construction.

2. Instalation.
Process

Product

Planning
Project Plan
Analysis
System Proposal
Design
System
Specification
Implementation
New System and
Maintenance Plan

Alternatif SDLC
1.
2.
3.

4.
5.
6.

Pengembangan secara Pararel
Rapid Application Development (RAD)
Pengembangan Bertahap
Pengembangan secara Prototype
Model Spiral
Model Paket

Oleh : Wahju Tjahjo S.

2

Rekayasa Perangkat Lunak/SI-TI

RAPID APPLICATION DEVELOPMENT
CASE Tool
1. Join Application Development

2. Menggunakan Bahasa Pemrograman Generasi ke 4 / Visualisasi
3. Manggunakan Pembangkit Code (Code Generator)

Tiga Kategori RAD




Pengembangan bertahap
o Deretan Versi
Prototype
o System Prototyping
Throw-Away Prototyping
o Perancangan Prototipe

Oleh : Wahju Tjahjo S.

3

Rekayasa Perangkat Lunak/SI-TI

MEMPEROLEH INFORMASI
Interviews
Lima langkah dalam melakukan Interview :
1. Memilih yg akan diinterview
2. Merancang pertanyaan untuk Interview
3. Menyiapkan Interview
4. Melaksanakan Interview
5. Follow-Up Interview

Memilih Yg Akan Di Interview



Berbasis pd kebutuhan Informasi
Menari dari beberapa perspektif:
i. Manager
ii. User
iii. Idealnya, seluruh yang berhubungan dengan sistem (stakeholder)

Tipe Pertanyaan
Tipe Pertanyaan
Pertanyaan Closed-Ended

Pertanyaan Open-Ended

Pertanyaan Probing

Contoh
Berapa jumlah pesanan melalui telepon?
Bagaimana cara memesan?
Informasi tambahan apa yang diperlukan
pada sistem yang baru?
Bagaimana pendapat anda tentang sistem
yang ada?
Masalah apa yang sering dihadapi seharihari?
Bagaimana memutuskan tipe pemasaran
apa yang harus dilaksanakan?
Kenapa?
Dapatkah Anda memberikan conoth?

Dapatkah dijelaskan lebih detail lagi?

Merancang Pertanyaan Interview
Interview tidak terstruktur
 Luas, mmeberikan Informasi yang masih global
Interview terstruktur
 Informasi yang lebih spsesifik

Strategi Dalam Bertanya

Langkah Persiapan Interview
1. Menyiapkan Perencanaan Interview Global
 Menyusun/mengumpulkan pertanyaan
 Mengantisipasi jawaban dan follow-up
2. Konfirmasi area knowledge
3. Menentukan prioritas apabila waktu tidak mencukupi
Oleh : Wahju Tjahjo S.

4

Rekayasa Perangkat Lunak/SI-TI

4. Menyiapkan yang diinterview
 Jadwal
 Menjelaskan alas an melakukan Interview
 Menjelaskan ruang lingkup diskusi

Melaksanakan Interview
1.
2.
3.
4.
5.

Profesional dan tidak bias
Merekam semua Informasi
Mengerti semua issue dan istilah-istilah
Membedakan antara opini dan kenyataan
Memberikan kesempatan yg ditanya untuk menyanyakan beberapa hal yg belum jelas dr
pertanyaan
6. Berterima kasih atas jawaban yg telah diberikan
7. Berakhir pada waktu yg tepat

Follow-up Interview
1. Menyiapkan beberapa catatan hasil interview
2. Menyiapkan Laporan hasil Interview
3. Memperhatikan kendala-kendala yg muncul ketika interview dan kemungkinan pertanyaan
baru.

JOINT APPLICATION DESIGN
1.
2.
3.
4.

Pertama dilakukan oleh team IBM sekitar tahun 1970
Pertemuan terstruktur yang dihadiri oleh sekitar 10 – 20 peserta
Dilaksanakan sekitar 30 – 60 menit per agenda
Sering dilakukan break

Langkah Dalam JAD
1.
2.
3.
4.
5.

Memilih peserta (participant)
Merancang pertemuan (session)
Menyaipakan pertemuan (session)
Pelaksanaan pertemuan (session)
Follow-up

Key Idea JAD
1. Memungkinkan adanya kerjasama yang lebih intensif antara manager, user dan
pengembang
2. Dapat mengurangi informasi yang tidak sesuai/jelas hingga 50%
3. Menghindari kebutuhan user yang terlalu spesifik ataupun yang tidak jelas

Setting JAD
1.
2.
3.
4.
5.

Mengatur tempat duduk berbentuk U-Shaped
Menghindari gangguan-gangguan
Whiteboard/flip chart
Prototyping tools
e-JAD

Pertemuan (Session) JAD
1.
2.
3.
4.

Diselenggarakan pada 5 – 10 hari terakhir untuk periode 3 bulanan
Menyiapkan pertanyaan sebagaimana Interview
Menyiapkan agenda formal
Memfasilitasi akrifitas-aktifitas
a. Menjaga pertemuan agar tetap pada pokok bahasan dan terkendali
b. Membantu untuk menjelaskan istilah teknis
c. Merekam input dari kelompok
d. Membantu memecahkan isu-isu yang ada
5. Menindak lanjuti pertemuan berikutnya

Oleh : Wahju Tjahjo S.

5

Rekayasa Perangkat Lunak/SI-TI

Bentuk Ruang Pertemuan JAD

Mengatur Permasalahan Dalam JAD
1.
2.
3.
4.
5.
6.
7.
8.

Reducing domination
Encouraging non-contributors
Side discussions
Agenda merry-go-round
Violent agreement
Unresolved conflict
True conflict
Use humour

KUESIONER
Langkah Dalam Menyusun Kuesioner
1.
2.
3.
4.

Selecting participants, Using samples of the population
Designing the questionnaire, Careful question selection
Administering the questionnaire, Working to get good response rate
Questionnaire follow-up, Send results to participants

Merancang Kuesioner Yang Baik








Begin with non-threatening and interesting questions
Group items into logically coherent sections
Do not put important items at the very end of the questionnaireDo not crowd a page with
too many items
Avoid abbreviations
Avoid biased or suggestive items or termsNumber questions to avoid confusion
Pretest the questionnaire to identify confusing questions
Provide anonymity to respondents

Document Analysis






Provides clues about existing “as-is” system
Typical documents
o Forms
o Reports
o Policy manuals
Look for user additions to forms
Look for unused form elements

Observation
1. Users/managers often don’t remember everything they do
2. Checks validity of information gathered other ways
3. Behaviours change when people are watched
Oleh : Wahju Tjahjo S.

6

Rekayasa Perangkat Lunak/SI-TI

4. Careful not to ignore periodic activities
o Weekly … Monthly … Annual

Criteria for Selecting the Appropriate Techniques








Type of information
Depth of information
Breadth of information
Integration of information
User involvement
Cost
Combining techniques

Tabel Perbandingan Setiap Teknik
Tipe
Informasi
Kedalaman
Informasi
Luasnya
Informasi
Integrasi
Informasi
Keterlibatan
User
Biaya

Interview

JAD

As-Is
Improve
To-Be
High

As-Is
Improve
To-Be
High

Questionnaire Document Observation
Analysis
As-Is
As-Is
As-Is
Improve
To-Be
Medium
Low
Low

Low

Medium

High

High

Low

Low

High

Low

Low

Low

Medium

High

Low

Low

Low

Mediu

Low Medium

Low

Low

Low Medium

Oleh : Wahju Tjahjo S.

7

Rekayasa Perangkat Lunak/SI-TI

BAB II
KARAKTERISTIK PERANGKAT LUNAK
1. PL selalu berkembang dan terencana.
2. PL tidak pernah usang. Sedangkan PK memiliki keausan yang tinggi, ada getaran, panas
atau debu.
3. PL dibuat karena kebutuhan.

KOMPONEN PERANGKAT LUNAK
1. Dibuat melalui sederetan/kumpulan perintah.
2. Struktur database.
3. Rancangan/disain perangkat lunak.

JENIS APLIKASI PERANGKAT LUNAK
System Software
Adalah kumpulan program yang ditulis untuk menunjang membuatan program. Misal :
kompiler, editor, utilitas file.

Real Time Software
Adalah PL yang digunakan untuk mengontrol proses input data sampai menghasilkan
laporan.

Bussines Software
PL yang banyak digunakan dalam dunia bisnis. Misal : SPSS, MYOB, Access, Corel,
Flash.

Engineering and Scientific Software
PL yang digunakan dalam bidang teknik dan rekayasa. Misal : GIS, Astronomi,
Vulkanologi, Arc View.

Embeded Software
PL yang digunakan untuk mengontrol suatu proses dam pabrik, biasanya disimpan
dalam ROM.

PERANGKAT LUNAK
Merupakan kumpulan program dan dokumentasi yang saling berkaitan. Produk perangkat lunak
dibuat untuk pelanggan tertentu ataupun untuk pasar umum. Produk perangkat lunak tersebut :
1. Generik – dibuat untuk dijual ke suatu kumpulan pengguna yang berbeda.
2. Bespoke (custom) – dibuat untuk suatu pengguna tunggal sesuai dengan spesifikasinya.

REKAYASA PERANGKAT LUNAK
1. Adalah suatu disiplin rekayasa yang berkonsentrasi terhadap seluruh aspek produksi
perangkat lunak.
2. Mengadopsi pendekatan yang sistematis dan terorganisir terhadap pekerjaannya dan
menggunakan tool yang sesuai serta teknik yang ditentukan berdasarkan masalah yang
akan dipecahkan, kendala pengembangan dan sumber daya yang tersedia.

PROSES PERANGKAT LUNAK
Sekumpulan aktifitas yang memiliki tujuan untuk pengembangan atau pun evolusi perangkat
lunak. Aktifitas generik dalam semua proses perangkat lunak adalah :
 Spesifikasi : apa yang dilakukan oleh perangkat lunak dan batasan pengembangannya ?.
 Pengembangan : proses memproduksi sistem perangkat lunak.
 Validasi : pengujian perangkat lunak terhadap keinginan penggunak.
 Evolusi : perubahan perangkat lunak berdasarkan perubahan keinginan.

Oleh : Wahju Tjahjo S.

8

Rekayasa Perangkat Lunak/SI-TI

MODEL PROSES PERANGKAT LUNAK
Suatu representasi proses perangkat lunak yang disederhanakan, dipresentasikan dari
perspektif khusus. Contoh perspektif proses :
 Perspektif Alur-kerja (workflow) - barisan kegiatan.
 Perspektif Alur Data (Data flow) - alur informasi.
 Perspektif Peran/Aksi - siapa melakukan apa.

MODEL PROSES GENERIK






Waterfall (Air terjun).
Pengembangan secara evolusi.
Transformasi formal.
Model Spiral.
Integrasi dari komponen yang reusable.

BIAYA REKAYASA PERANGKAT LUNAK




Sekitar 60% untuk biaya pengembangan, 40% biaya pengujian. Untuk perangkat lunak
berbasis pengguna (custom), biaya evolusi biasanya melebihi biaya pengembangan.
Biaya beragam tergantung pada tipe sistem yang akan dikembangkan dan kebutuhan
sistem seperti unjuk kerja dan kehandalan sistem.
Distribusi biaya bergantung pada model pengembangan yang digunakan.

METODE REKAYASA PERANGKAT LUNAK
Pendekatan terstruktur pengembangan PL termasuk :
1. Deskripsi Model : deskripsi pemodelan dengan grafik.
2. Aturan
: Batasan yang digunakan pada model sistem.
3. Rekomendasi : nasihat bentuk perancangan yang baik.
4. Petunjuk proses : Aktifitas yang harus diikuti.

ATRIBUT PERANGKAT LUNAK YANG BAIK
PL seharusnya memberikan pengguna kebutuhan fungsionalitas dan unjuk kerja yang dapat di
rawat, berguna.
1.
2.
3.
4.

Maintanability : PL harus dapat memenuhi perubahan kebutuhan.
Dependability : PL harus dapat dipercaya.
Efisiensi
: PL harus efisien dalam penggunaan resource.
Usability
: PL harus dapat digunakan sesuai dengan yang direncanakan.

PROSES PERANGKAT LUNAK
Suatu proses model adalah suatu representasi abstrak suatu model. Proses model
menampilkan suatu deskripsi suatu proses dari beberapa perspektif tertentu. Proses PL
merupakan aktifitas yang saling terkait (koheren) untuk menspesifikasikan, merancang,
implementasi dan pengujian sistem perangkat lunak.

MODEL PROSES PL YANG GENERIC






Model Air terjun (Water fall)
o Memisahkan dan membedakan antara spesifikasi dan pengembangan
Pengembangan yang berevolusi
o Spesifikasi dan pengembangan saling bergantian
Pengembangan sistem Formal
o Menggunakan suatu model sistem matematika yang ditransformasikan ke
implementasi,
Pengembangan berbasis Re-use (penggunaan ulang)
o Sistem dibangun dari komponen yang sudah ada.

Oleh : Wahju Tjahjo S.

9

Rekayasa Perangkat Lunak/SI-TI

MODEL AIR TERJUN (WATER FALL)
Fase Model Air Terjun :
1.
2.
3.
4.
5.

Analisis Kebutuhan dan pendefinisiannya.
Perancangan sistem dan Perangkat Lunak.
Implementasi dan unit testing.
Integrasi dan pengujian sistem.
Pengoperasian dan perawatan.

Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance

Masalah pada Model Air Terjun :




Partisi proyek ke stages yang berbeda tidak fleksibel.
Hali ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan pengguna.
Oleh sebab itu model ini hanya cocok digunakan apabila kebutuhan pengguna sudah di
mengerti dengan baik.

PENGEMBANGAN YANG BEREVOLUSI
(EVOLUTIONARY DEVELOPMENT)
Pengembangan yang berdasarkan penyidikan :
Tujuannya untuk mengaktifkan pengguna dan memperolah model final berasal dari initial
spesifikasi awal. Seharusnya diawali dengan kebutuhan yang sudah dimengerti.
Oleh : Wahju Tjahjo S.

10

Rekayasa Perangkat Lunak/SI-TI

Throw-away prototyping :
Tujuannya adalah untuk memahami kebutuhan sistem. Biasanya diawali dengan
pemahaman kebutuhan yang minim.

Permasalahan dalam model pengembangan yang berevolusi :




Kekurangan visibilitas proses.
Model sistem biasanya tidak terstruktur.
Membutuhkan kemampuan khusus (misal : bahasa pemrograman untuk rapid
prototyping).

Pemakaian model pengembangan yang berevolusi :




Untuk sistem interaktif yang kecil atau menengah.
Untuk salah satu bagian dari sistem yang besar (misal User Interface).
Untuk sistem yang digunakan tidak terlalu lama (short lifetime).

PENDEKATAN PENGEMBANGAN SISTEM FORMAL
Berbasiskan pada transformasi spesifikasi secara matematik melalui representasi yang berbeda
untuk suatu program yang dapat dieksekusi. Trasformasi menyatakan spesifikasi program.
Menggunakan pendekatan ‘Cleanroom’ untuk pengembangan PL.

PENGEMBANGAN MENGGUNAKAN
KONSEP RE-USE (PENGGUNAAN ULANG)

Oleh : Wahju Tjahjo S.

11

Rekayasa Perangkat Lunak/SI-TI

PROSES DENGAN METODE ITERASI
Metode Iterasi dapat digunakan pada setiap model proses generik. Terdapat dua pendekatan:
 Pengembangan Incremental
 Model Spiral

Model Pengembangan Incremental
1. Pengembangan sistem berdasarkan model sistem yang dipecah sehingga model
pengembangannya secara increament/bertahap.
2. Kebutuhan pengguna diprioritaskan dan priritas tertinggi dimasukkan dalam awal
increment.
3. Setelah pengembangan suatu increment dimulai, kebutuhan dibekukan dulu hingga
increment berikutnya dimulai.

Keuntungan :
1. Nilai penggunan dapat ditentukan pada setiap increament sehingga fungsionalitas sistem
disediakan lebih awal.
2. Increment awal berupa prototype untuk membantu memahami kebutuhan pada
increment berikutnya.
3. Memiliki resiko lebih rendah terhadap keseluruhan pengembagan sistem.
4. Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji.

MODEL PENGEMBANGAN SPIRAL
Proses direpresentasikan sebagai model spiral (bukan berupa barisan aktfitas yang dapat di
track mundur). Setiap loop dalam model spiral menyatakan fase proses. Tidak terdapat fase
tertentu seperti spesifikasi atau perancangan, tetapi loop dalam spiral ditentukan pada apa yang
dibutuhkan.

Sektor pada Model Spiral
1. Menentukan Tujuan, Mengidentifikasikan spesifikasi tujuan setiap fase.
2. Menilai Resiko dan Pengurangannya, Resiko dinial dan aktifitas ditempatkan untuk
mengurangi resiko kunci.
3. Pengembangan dan validasi, Suatu model pengembangan sistem dipilih dari model
generik.
4. Perencanaan, Project di review dan fase spiral berikutnya direncanakan.

Oleh : Wahju Tjahjo S.

12

Rekayasa Perangkat Lunak/SI-TI

SPESIFIKASI PERANGKAT LUNAK
Proses untuk menentukan pelayanan (servis) apa yang dibutuhkan dan kendala-kendala
pengoperasian sistem serta pengembangannya.

Proses Rekayasa Kebutuhan





Studi Kelayakan
Analisis kebutuhan
Spesifikasi Kebutuhan
Validasi spesifikasi

Perancangan dan Implementasi Perangkat Lunak
1.
2.
3.
4.
5.
6.

Proses konversi sistem spesifikasi ke sistem yang dapat dieksekusi langsung.
Perancangan Perangkat Lunak.
Perancangan Struktur Perangkat Lunak.
Implementasi.
Translasi struktur ke dalam bentuk program.
Aktifitas perancangan dan implementasi berhubungan dekat dan dapat saling
berinteraksi.

Aktifitas dalam Perancangan







Perancangan Arsitektur
Spesifikasi Abstrak
Perancangan Interface
Perancangan Komponen
Perancangan Struktur Data
Perancangan Algoritma

Oleh : Wahju Tjahjo S.

13

Rekayasa Perangkat Lunak/SI-TI

Proses Perancangan Perangkat Lunak

Metode Perancangan




Pendekatan sistematis untuk merancang perangkat lunak.
Perancangan biasanya didokumentasikan dengan Model Grafik.
Beberapa model yang dapat digunakan :
o Data Flow Model
o Model relasi atribut entitas
o Model terstruktur
o Model Object

EVOLUSI SISTEM





Perangkat lunak pada dasarnya sangat fleksibel dan mudah berubah.
Karena adanya perubahan kebutuhan melalui perubahan proses bisnis dan teknologi,
maka perangkat lunak yang mendukung kegiatan bisnis tersebut juga mengalamai
perubahan.
Walaupun demikian diharapkan perubahan proses bisnis tersebut berdampak pada
perubahan yang sedikit terhadap perangkat lunak (re-engineering).

Oleh : Wahju Tjahjo S.

14

Rekayasa Perangkat Lunak/SI-TI

BAB III
ANALISIS KEBUTUHAN
Merupakan proses menemukan, memperbaiki, memodelkan dan menspesifikasikan. Terdiri dari
lima langkah pokok :
1. Identifikasi Masalah
2. Evaluasi dan sintesis
3. Pemodelan
4. Spesifikasi
5. Review
Dalam menemukan Area permasalahan, perlu adanya komunikasi yang intensif dengan user.
Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari salah interpretasi

PERTANYAAN FOKUS PADA DASAR PERMASALAHAN
1. Menemukan yang membutuhkan software tersebut:
a. Siapa yang membutuhkan sistem (serta personal di belakangnya) ?
b. Siapa yang akan menggunakan solusi
c. Apa yang akan menjadi keuntungan ekonomis dari solusi yang baik
d. Adakan sumber lain dari solusi yang dibutuhkan
2. Bentuk solusi yang diinginkan
a. Bagaimana user mengkarakteristikkan suatu output sistem yang baik yang akan
dihasilkan oleh solusi yang benar
b. Masalah-masalah apa yang akan dicarikan solusinya?
c. Lingkungan solusi yang akan digunakan
d. Adakah isu atau kendala khusus yang berdampak kepada solusi
3. Efektifitas
a. Mendapatkan person yang benar/berhak atas jawaban pertanyaan,
b. Apakah pertanyaan yang diajukan relevan dengan permasalahan
c. Adakah personal lain yang dapat menambah informasi
d. Adakah hal lain yang perlu ditambahkan?

JENIS KEBUTUHAN
1. Kebutuhan Fungsional
Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap
input dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistem
dilihat dari kacamata pengguna)
2. Kebutuhan Non-Fungsional
Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses
pengembangan, standard, dll. Contoh: kehandalan, waktu respon dan kebutuhan
storage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O,
representasi sistem dll.

Domain Kebutuhan
Kebutuhan yang berasal dari domain aplikasi sistem dan merefleksikan karakteristik domain.
Secara Prinsip, spesifikasi Kebutuhan harus :
1. Lengkap : Mendeskripsikan semua fasilitas yang diinginkan.
2. Konsisten : Tidak adanya konflik dan kontradiksi.

Oleh : Wahju Tjahjo S.

15

Rekayasa Perangkat Lunak/SI-TI

Tipe Non-Fungsional

PROSES REKAYASA KEBUTUHAN

STUDI KELAYAKAN
Studi Kelayakan memutuskan apakah sistem software yang akan dibuat sudah
mencakup seluruh aspek permasalahan.
Melakukan studi untuk menguji apakah sistem :
 sudah sesuai dengan tujuan organisasi.
 dapat dikembangkan dengan teknologi terkini dan dana yang tersedia.
 dapat diintegrasikan dengan sistem lain yang sudah digunakan.

Implementasi Studi Kelayakan
Berbasiskan pada penilaian informasi (apa yg dibutuhkan), pengumpulan informasi dan
penulisan laporan. Pertanyaan ke personal di organisasi :
 Apa yang akan terjadi apabila sistem tidak diimplementasikan?
 Masalah proses apa yang ada ?
 Apa yang dapat dibantu oleh sistem ?
 Masalah apa yang akan muncul pada proses Integrasi ?
Oleh : Wahju Tjahjo S.

16

Rekayasa Perangkat Lunak/SI-TI




Adakah teknologi baru yang dibutuhkan? Skill yang dibutuhkan ?
Fasilitas apa yang harus didukung oleh sistem ?

Permasalahan pada Analisis Kebutuhan






Pengguna (stakeholders) tidak mengetahui apa yang mereka butuhkan.
Pengguna menjelaskan kebutuhan dengan cara mereka sendiri sehingga sulit untuk
dipahami.
Pengguna yang berbeda memiliki konflik kebutuhan.
Faktor politik dan organisasi yang dapat mempengaruhi kebutuhan sistem.
Perubahan kebutuhan selama proses analisis. Stakeholder baru mungkin akan merubah
lingkungan bisnis.

PROSES ANALISIS KEBUTUHAN

PEMODELAN SISTEM
Dapat dilakukan dalam beberapa cara, seperti model structural, state machine, state chart dan
lain-lain. Pemodelan tersebut dapat pula direpresentasikan sebagai formaliasi sudut pandang
pengguna (viewpoint-oriented).

Viewpoint-Oriented Elicitation
Stakeholder merepresentatikan sudut pandang suatu masalah dalam beberapa cara. Analisis
Multi perspektif adalah penting jika tidak terdapat suatu cara yang benar untuk menganalisa
kebutuhan sistem.
Contoh : Sistem ATM Bank
Sistem ATM dapat menyediakan pelayanan bank secara otomatis. Pelayanan tersebut
mencakup: penarikan tunai, pengiriman pesan untuk permintaan layanan, pemensanan, dan
transfer.

Autoteller Viewpoint









Bank customers
Representatives of other banks
Hardware and software maintenance engineers
Marketing department
Bank managers and counter staff
Database administrators and security staff
Communications engineers
Personnel department

Oleh : Wahju Tjahjo S.

17

Rekayasa Perangkat Lunak/SI-TI

V ie w p oin t
i d e n t if i c a t io n

V ie w p oin t
st r u c t u r i n g

V i ew p o i n t
d o c u m e n ta t io n

V ie w p oin t
s y s te m m a p p i n g

Identifikasi Viewpoint:


Menemukan viewpoint sebagai penerima layanan sistem dan mengidentifikasikan
layanan yang disediakan untuk masing-masing viewpoint.



Pembentukan Struktur Viewpoint


Mengelompokkan viewpoint yang saling berhubungan secara hierarki. Layanan umum
disediakan pada level yang lebih tinggi dalam hierarki

Dokumentasi Viewpoint


Memperbaiki deskripsi viewpoint dan layanan yang teridentifikasi.

Viewpoint System Mapping


Transformasi analisis ke perancangan berorientasi objek.

Oleh : Wahju Tjahjo S.

18

Rekayasa Perangkat Lunak/SI-TI

Viewpoint Service Information
ACCO UN T
HO LD ER
S e r vi c e l is t
W i th dra w c a sh
Q u e r y ba l a nc e
O r d er c he q ue s
S e n d m e s sa g e
T r a ns a c ti on l is t
O r d er st at em e n t
T r a ns f e r f u nd s

F O RE I G N
C U S TO M E R

BAN K
TE LL ER

S e r vi ce l is t

S e r vi c e l is t

W i th dr aw c a sh
Q u e r y ba la nc e

R u n d ia g no st ic s
A d d c a sh
A d d pa p er
S e n d m e s sa g e

Bentuk Standard VORD
Viewpoint Templete

Service Templete

R e fe r e n c e : C u st om e r

R e fe re n c e :

C a s h w it hd ra w a l

A ttr i b u te s: A c c o un t nu m be r
P IN
S t art t ra n sa c ti on
E ve n ts:
S e l ec t s e rvi ce
C a nc e l
t ra n sa c ti on
En d tra n sa c ti on

R a tio n a le :

To im p rove c u st om e r s e rvi c e
a nd re du c e p ap erw o rk

S e r vi c e s:

C a s h w it hd raw a l
B a la n c e e n qu iry

S u b -V Ps :

A c c o un t ho ld e r
F orei gn
c us to m e r

S p e c i fi c ati on : U s e rs c ho os e th is s e rvi c e by
p re s si ng t he c a s h w i th dra w a l
b ut to n. The y t he n e nt e r t he
a m ou nt re q ui re d. Th is is
c on firm e d a n d, if fu nd s a ll ow ,
t he b a la n c e is d e li ve re d .
V P s:

C u st om e r

D e l iv e r c a s h w it hi n 1 m i nu te
N o n -fu n c t.
re q u i re m e n ts : o f a m ou nt be i ng c o nfi rm e d
Pr ov id e r :

Fi ll e d in la te r

Skenario
Penggambaran bagaimana sistem akan digunakan membantu dalam menemukan kebutuhan
dengan mempermudah dalam penggambaran proses dibandingkan pernyataan abstrak
kebutuhan sistem. Menambahkan detail ke outline deskripsi kebutuhan.

Deskripsi dalam Skenario






Sistem State pada awal scenario.
Alur Normal kejadian-kejadian di sistem.
Apa yang dapat berkembang dan bagaimana menanganinya.
Aktifitas-aktifitas yang bersamaan terjadi.
System state setelah proses selesai.

Skenario Kejadian



Skenario kejadian dapat digunakan untuk menggambarkan bagaimana sistem merespon
ke suatu kejadian tertentu seperti awal transaksi.
VORD dapat berupa diagram untuk menggambarkan scenario kejadian.
o Data yang dikirim dan disediakan.
o Kontrol Informasi.
o Pengecualiaan Proses.
o Kejadian berikutnya.

Oleh : Wahju Tjahjo S.

19

Rekayasa Perangkat Lunak/SI-TI

Notasi :
1.
2.
3.
4.

Elips menyatakan data yang disediakan oleh dan dikirim ke viewpoint.
Data keluar dari sisi kanan setiap kotak.
Eksepsi ditunjukkan di bawah maisng-masing box.
Nama kejadian berikutnya berada di box dengan garis panah tebal.

Pada contoh di atas, eksepsi adalah :




Timeout: Pelanggan salah memasukkan nomor PIN selama waktu yang diberikan.
Invalid Card : Kartu tidak diknal oleh sistem dan dikembalikan.
Stolen Card : Kartu sudah diregister sebagai kartu yang sudah dicuri/hilang dan akan
diambil oleh sistem (tidak dikembalikan).

VALIDASI KEBUTUHAN



Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai dengan
yang diinginkan pengguna
Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan
penambahan biaya yang besar
o Memperbaiki definisi kebutuhan stelah software dikirim akan menyebabkan
peningkatan biaya hingga 100 kali.

Pengujian Pendefinisian Kebutuhan






Validasi. Apakah sudah sesuai dengan yang diinginkan.
Konsistensi. Adakah konflik dengan kebutuhan lainnya.
Lengkap: Apakah sudah termasuk semua fungsi yang dibutuhkan.
Realisasi: Dapatkan kebutuhan diimplementasikan ke dana dan teknologi yang tersedia.
Dapat diverifikasi: Dapatkah spesifikasi kebutuhan dicek.

Teknik Validasi Kebutuhan Review
1. Prototyping
2. Test-Case Generator
3. Analisis Konsistensi Otomatis

Oleh : Wahju Tjahjo S.

20

Rekayasa Perangkat Lunak/SI-TI

MANAJEMEN PERUBAHAN KEBUTUHAN

Outline Spesifikasi Kebutuhan Software
1. Pendahuluan
a. Referensi Sistem
b. Deskripsi Umum Sistem
c. Kendala Proyek Pengembangan Software
2. Deskripsi Informasi
a. Informasi representasi Alur
i. Alur Data
ii. Alur Kontrol
b. Representasi Isi Informasi
c. Deskripsi Interface Sistem
3. Deskripsi Fungsional
a. Partisi Fungsional
b. Deskripsi Fungsional
i. Deskripsi proses secara naratif
ii. Keterbatasan Sistem
iii. Performa yang dibutuhkan
iv. Perancangan kendala
v. Support diagram
c. Deskripsi Kontrol
i. Spesifikasi Kontrol
ii. Perancangan Kendala
4. Deskripsi Lingkungan
a. System State
b. Events dan Aksi
5. Kriteria Validasi
a. Performance Bound
b. Kelas Test
c. Respon Software yang diharapkan
d. Pertimbangan-pertimbangan khusus
6. Daftar Kepustakaan
7. Appendiks

Oleh : Wahju Tjahjo S.

21

Rekayasa Perangkat Lunak/SI-TI

BAB IV
MANAJEMEN PROYEK PENGEMBANGAN SOFTWARE



Memfokuskan pada aktifitas pengembangan software sesuai dengan jadwal
penyelesaian dan organisasi pengembangan software.
Manajemen proyek dibutuhkan karena pengembangan software memiliki kendala pada
biaya dan jadwal yang ditentukan oleh pengembang.

AKTIFITAS DALAM MANAJEMEN







Pembuatan Proposal.
Perencanaan dan penjadwalan Proyek.
Pembuatan rencana biaya proyek.
Monitoring dan review proyek.
Pemilihan dan evaluasi proyek.
Pembuatan Laporan dan presentasi.

PENGUATAN PROYEK




Penentuan Personal dalam Proyek
o Dana proyek terbatas untuk pembiayan staff yang tinggi
o Dimungkinkan tidak tersedianya staff yang memiliki kemampuan sesuai dengan
yang diinginkan
o Pengembangan kemampuan(skill) pegawai pada proyek software
Menuntut kemampuan manager dalam menentukan staff sesuai dengan standar tenaga
IT internasional

PERENCANAAN PROYEK




Merupakan aktifitas manajemen proyek yang membutuhkan waktu paling lama
Merupakan aktifitas berkelanjutan dari tahap initial hingga pengiriman software sehingga
secara regular harus diperbaharui ketika terdapat informasi baru,
Beberapa tipe perencanaan (rencana validasi, rencana perubahan managemen, rencana
pengembangan dan training staff, rencana perawatan) harus pula dikembangkan untuk
mendukung perencanaan proyek utama yang memiliki kendala terhadap waktu dan
biaya

JENIS-JENIS PERENCANAAN
Jenis
Perencanaan Kualitas
Perencanaan Validasi
Perencanaan Perubahan
Manajemen
Perencanaan Perawatan
Perencanaan pengembangan staff

Deskripsi
Menentukan standar dan prosedur penentuan
kualitas software yang digunakan
Menentukan teknik, jadwal, dan sumber daya yang
digunakan untuk validasi software
Menggambarkan struktur dan prosedur perubahan
manajemen
Memprediksi kebutuhan, biaya dan usaha perawatan
sistem
Menggambarkan bagaimana perencanaan
pengembangan kemampuan dan ketrampilan staff
untuk menunjang proyekS

PROSES MANAJEMEN PROYEK
Mendefinisikan kendala proyek
Menentukan penilaian awal terhadap parameter proyek
Menentukan proyek milestone dan pengiriman
while proyek belum selesai ataupun dibatalkan loop
Menyusun jadwal proyek
Initiasi aktifitas sesuai dengan jadwal
Oleh : Wahju Tjahjo S.

22

Rekayasa Perangkat Lunak/SI-TI

delay (untuk sementara)
review perkembangan proyek
revisi parameter dan estimasi proyek
apply revisi ke jadwal
negosiasikan kembali kendala proyek dan pengiriman
if (terdapat masalah) then
initiasi review teknis dan kemungkinan revisi
end if
end loop

STRUKTUR PERENCANAAN PROYEK
1.
2.
3.
4.
5.
6.
7.

Pendahuluan
Organisasi Proyek
Analisis Resiko
Kebutuhan akan sumber daya hardware dan software
Work breakdown
Penjadwalan Proyek
Mekanisme pemantauan dan pelaporan

PENGORGANISASIAN KEGIATAN PROYEK
1. Aktifitas pada suatu pengembangan proyek harus diorganisasikan untuk menghasilkan
output yang terukur bagi manajemen dan penentuan progress.
2. Milestones merupakan titik akhir dari aktifitas proses.
3. Deliverable (pengiriman) merupakan hasil proyek yang dikirim ke pelanggan.
4. Pada model proses air terjun (waterfall) boleh didefnisikan progress milestone secara
langsung.

MILESTONE DALAM PROSES REKAYASA KEBUTUHAN

PENJADWALAN PROYEK





Membagi proyek ke dalam bebtuk tugas dan estiamsi waktu serta sumber daya yang
dibutuhkan untuk menyelesaikan tugas tersebut.
Pengorganisasian tugas yang bersamaan untuk membuat jadwal yang optimum.
Meminimumkan ketergantungan tugas untuk menghindari adanya delay yg ditimbulkan
oleh suatu tugas yang menunggu tugas lainnya selesai.
Ditentukan oleh intusi dan pengalaman manajer.

Proses Penjadwalan Proyek

Masalah Dalam Penjadwalan
1. Estimasi kesulitan masalah dan berakibat pada biaya pengembangan solusi menjadi
cukup rumit.
2. Produktifitas tidak berbanding lurus dengan jumlah orang yang mengerjakan tugas.
3. Penambahan personal pada akhir proyek menyebabkan overhead komunikasi.
4. Segala sesuatu yang tidak diharapkan akan terjadi, sehingga membutuhkan suatu
perencanaan contingency.
Oleh : Wahju Tjahjo S.

23

Rekayasa Perangkat Lunak/SI-TI

Diagram Batang Dan Jaringan Kerja
1. Merupakan notasi grafis yang digunakan untuk mengilustrasikan jadwal proyek.
2. Menyatakan suatu breakdown proyek ke dalam tugas-tugas. Tugas seharusnya tidak
terlalu kecil dan diestimasi waktunya selama satu atau dua minggu.
3. Bagan Aktifitas menyatakan ketergantungan dan jalur kritis.
4. Diagram batang menyatakan jadwal yang sesuai dengan waktu kalender.

Durasi Dan Ketergantungan
Tugas
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12

Durasi (hari)
8
15
15
10
10
5
20
25
15
15
7
10

Ketergantungan

T1 (M1)
T2, T4 (M2)
T1, T2 (M3)
T1 (M1)
T4(M5)
T3, T6 (M4)
T5, T7 (M7)
T9 (M6)
T11 (M8)

Jaringan Aktifitas

Oleh : Wahju Tjahjo S.

24

Rekayasa Perangkat Lunak/SI-TI

Timeline Aktifitas

Alokasi Staf

MANAJEMEN RESIKO
1. Manajemen resikon mengidentifikasikan resiko dan menggambarkan minimisasi dampak
resiko.
2. Suatu resiko adalah kemungkinan munculnya dampak yang akan merugikan.
o Resiko proyek berdampak pada jadwal dan sumber daya.
o Resiko produk berdampak pada kualitas dan unjuk kerja software yang
dikembangkan.
o Resiko Bisnis berdampak pada organisasi pengembang software.

Resiko Software
Resiko
Pindahnya Staff

Tipe
Resiko
Proyek

Perubahan Manajemen

Proyek

Oleh : Wahju Tjahjo S.

Deskripsi
Perginya staff berpengalaman sebelum proyek
selesai
Berubahnya manajemen maka berubah pula
prioritas program
25

Rekayasa Perangkat Lunak/SI-TI

Hardware yang tidak
tersedia
Perubahan Kebutuhan

Delay terhadap
spesifikasi
Estimasi ukuran yang
rendah
Unjuk kerja
tool/sumber daya yang
rendah
Perubahan Teknologi
Produk saingan

Proyek
Proyek
dan
Produk
Proyek
dan
Produk
Proyek
dan
Produk
Produk

Bisnis
Bisnis

Harware penting tidak dapat dikirim sesuai dengan
waktu yang sudah ditentukan
Munculnya perubahan kebutuhan yang lebih besar
dibandingkan antisipasinya
Spesifikasi pada interface penting tidak dapat
disediakan tepat waktu
Estimasi ukuran sistem yang terlalu rendah

Tool (CASE) yang digunakan tidak menunjukkan
performa yg baik dalam mengantisipasi masalah
Adanya perubahan teknologi dalam implementasi
software
Produk saingan sudah dipasarkan sebelum software
yang dikembangkan selesai

Proses Manajemen Resiko
1. Identifikasi Resiko, Identifikasi resiko proyek, produk dan bisnis
2. Analisis Resiko, Menilai konsekuensi dan likelihood resiko
3. Perencanaan Resiko, Menggambarkan perencanaan untuk menghindari
meminimisasi dampak resiko
4. Memantau Resiko, Memantau resiko selama proyek pengembangan

dan

Identifikasi Resiko
1.
2.
3.
4.

Resiko Teknologi
Resiko Personal
Resiko Organisasi
Estimasi Resiko

Jenis
Resiko
Teknologi

Personal

Organisasi

Tools
Kebutuhankebutuhan
Estimasi

Kemungkinan Resiko
Kecepatan Database-Engine yang digunakan tidak dapat melakukan proses
transaksi sebanyak yang dinginkan,
Terdapat kerusakan pada komponen software yg digunakan sehingga tidak
sesuai dengan fungsinya
Tidak dimungkinkannya melakukan recruitment staff yang memiliki
kemampuan sesuai dengan yang diingikan
Tidak tersedianya tempat training untuk staff yang dibutuhkan
Organisasi direstrukturisasi sehingga manajemen yg berbeda bertanggung
jawab ke proyek
Masalah dalam keuangan organisasi mengakibatkan menurunkan biayabiaya
Code yang dibangkitkan oleh Tool tidak efisien
CASE tool tidak dapat diintegrasikan
Perubahan kebutuhan mengakibatkan perancangan ulang
Tidak pahamnya pelanggan terhadap dampak perubahan kebutuhan
Perkiraan jumlah waktu yang diperlukan untuk menyelesaikan proyek terlalu
rendah
Perkiraan jumlah perbaikan kerusakan terlalu rendah
Perkiraan ukuran sistem software terlalu rendah

Oleh : Wahju Tjahjo S.

26

Rekayasa Perangkat Lunak/SI-TI

Analisis Resiko
1. Menilai kemungkinan terjadinya resiko dan dampak resiko.
2. Kemungkinan resiko: sangat rendah, rendah, sedang, tinggi, dan sangat tinggi.
3. Dampak resiko: fatal, serius, dapat ditolerir, tidak signifikan.
Risiko
Kemungkinan
Masalah dalam keuangan organisasi mengakibatkan
Rendah
menurunkan biaya-biaya.
Tidak dimungkinkannya melakukan recruitment staff yang
Tinggi
memiliki kemampuan sesuai dengan yang diingikan
Staff penting sakit pada saat jalur kritis
Sedang
Terdapat kerusakan pada komponen software yg
Sedang
digunakan sehingga tidak sesuai dengan fungsinya
Perubahan kebutuhan mengakibatkan perancangan ulang
Sedang
Organisasi direstrukturisasi sehingga manajemen yg
High
berbeda bertanggung jawab ke projek
Kecepatan Database-Engine yang digunakan tidak dapat
Sedang
melakukan proses transaksi sebanyak yang dinginkan
Perkiraan jumlah waktu yang diperlukan untuk
Tinggi
menyelesaikan projek terlalu rendah
CASE tool tidak dapat diintegrasikan
Tinggi
Tidak pahamnya pelanggan terhadap dampak perubahan
Sedang
kebutuhan
Tidak tersedianya tempat training untuk staff yang
Sedang
dibutuhkan
Perkiraan jumlah perbaikan kerusakan terlalu rendah
Sedang
Perkiraan ukuran sistem software terlalu rendah
High
Code yang dibangkitkan oleh Tool tidak efisien
Sedang

Dampak
Fatal
Fatal
Serius
Serius
Serius
Serius
Serius
Serius
Dapat ditolerir
Dapat ditolerir
Dapat ditolerir
Dapat ditolerir
Dapat ditolerir
Tidak
Signifikan

Perencanaan Risiko





Mempertimbangkan setiap risiko dan mengembangkan strategi untuk mengatur risiko
tersebut.
Strategi penghindaran, Kemungkinan risiko muncul dikurangi.
Strategi minimisasi, Dampak risiko pada projek ataupun produk harus dikurangi.
Perencanaan Contigency, Jika terjadi risiko, rencana contingency dilakukan untuk
antisipasi risiko.

Manajemen Strategi Risiko
Risiko
Masalah Keuangan
Organisasi
Masalah Recruitment
Staff yg sakit

Rusaknya komponen
Perubahan Kebutuhan
Restrukturisasi
Organisasi
Unjuk Kerja Database
Rendahnya perkiraan
waktu pengembangan

Strategi
Membuat suatu dokumen singkat yang diajukan ke manajer senior
untuk menggambarkan bahwa pentingnya projek terhadap
kemajuan bisnis organisasi
Memberitahukan ke pelanggan bahwa sulitnya memperoleh
sumber daya sehingga dimungkinkan terjadinya penundaan
Mengorganisasikan pekerjaan sehingga yang menangani setiap
tugas terdiri dari lebih dari satu orang ataupun bagian lainnya
dapat memahmi proses bagian lain
Mengganti komponen yg rusak dengan yg tersedia di pasaran yg
sudah diketahui kehandalannya.
Mengatur informasi yang dapat ditelusuri untuk menilai dapak
perubahan kebutuhan,
Membuat suatu dokumen singkat yang diajukan ke manajer senior
untuk menggambarkan bahwa pentingnya projek terhadap
kemajuan bisnis organisasi
Melihat kemungkinan pembelian database yang memiliki untuk
kerja tinggi
Menggunakan program generator ataupun pembelian komponenkomponen

Memantau Risiko
1. Menilai setiap risiko yang teridentifikasi secara regular untuk memutuskan apakah
kemungkinan munculnya risiko tersebut akan lebih banyak/sedikit.
2. Menilai apakah dampak risiko tersebut sudah berubah.
3. Setiap risiko harus didiskusikan pada pertemuan manajemen progress.
Oleh : Wahju Tjahjo S.

27

Rekayasa Perangkat Lunak/SI-TI

Faktor-faktor Risiko
Tipe Risiko
Teknologi
Personal
Organisasi
Tools
Kebutuhan
Estimasi

Indikator Potensial
Pengiriman produk hardware/software yang terlambat karena adanya
masalah teknologi
Rendahnya moral staff, kurangnya team work, dan ketersediaan pekerjaan
Gossip di organisasi, kurangnya aksi dari senior manajemen, reward &
punishment
Adanya komentar kerusakan CASE tool, butuhnya spesifikasi komputer
yang tinggi,
Complaints dr pelanggan, berubahnya kebutuhan
Tidak adanya kesesuaian terhadap jadwal, tidak adanya laporan yang jelas
terhadap kerusakan.

Oleh : Wahju Tjahjo S.

28

Rekayasa Perangkat Lunak/SI-TI

BAB V
OBJECT ORIENTED ANALYSIS AND DESIGN
1. Fokus pada object dimana sistem dibagi ke dalam beberapa object yang ada di
dalamnya.
2. Function (behavior) dan data (state) yang berhubungan ke suatu object tunggal adalah
self-contained atau encapsulated pada satu tempat.

Keuntungan Object-Oriented
1. Reusability.
2. Modularity.
3. Maintainability.
Object adalah suatu abstraksi dari sesuatu dalam suatu domain masalah, menyatakan
kemampuan sistem untuk :
 menyimpan informasi tentang object tsb,
 berinteraksi dengan object tsb,
 atau keduanya
Object adalah entitas suatu sistem software yang menyatakan kejadian (instances) dari realworld dan entitas sistem.

Object Class
Class adalah deskripsi dari sekumpulan object yang membagi (share) attributes, methods,
relationship dan semantic yang sama. Object class adalah template untuk object, yang dapat
digunakan untuk membuat object. Object menyatakan suatu kejadian khusus tertentu dari suatu
class.
Contoh:
Class
name: string
address: string 3
dateOfBirth: date
employeeNo: integer
socialecurityNo: string
department: string
manager: string
salary: real
status: {current, left, retired}
taxCode: integer
Join( )
Retire( )
ChnageDetail( )

Object
name: John
address: M Street No.23
dateOfBirth: 02/10/65
employeeNo: 324
socialecurityNo:E342545
department: Sale
manager: Employee1
salary: 2340
status:current
taxCode: 3432
Eployee16.join(02/05/1997)
Eployee16.retire(03/08/2005)
Eployee16.changeDetail(“X Street No. 12”)

Inheritance



Object classes dapat menurunkan atribut dan services dari object class yang lain,
Inheritance menyatakan suatu generalisasi suatu class,

Oleh : Wahju Tjahjo S.

29

Rekayasa Perangkat Lunak/SI-TI

Generalisasi

Library Class Hierarchy

Keuntungan Inheritance
1. Merupakan mekanisme abstraksi yang dapat digunakan untuk mengklasifikasikan
entitas.
2. Merupakan mekanisme re-use pada tahap perancangan dan pemrograman.
3. Grafik Inheritance adalah suatu bentuk gambaran tetang organisasi pada suatu domain
dan sistem.

Oleh : Wahju Tjahjo S.

30

Rekayasa Perangkat Lunak/SI-TI

Multiple Inheritance

1. Suatu object class dapat pula dibentuk dari turunan beberapa super-class.
2. Akan memberikan dampak konflik semantic dimana atribut/service dengan nama yang
sama pada super-class yang berbeda memiliki semantic yang berbeda.
3. Membentuk hierarchy yang lebih kompleks.

Masalah dengan Inheritance



Object class tidak self-contain, sehingga tidak dapat diketahui tanpa referensi ke superclassnya.
Perancang memiliki tendensi untuk melakukan reuse terhadap graph inheritance yang
sudah dibuat sehingga dapat menimbulkan ketidak efisiensian yang signifikan.

Object Agregasi
1. Model agregasi menunjukkan bagaimana class-class dibentuk dari class yang lainnya
2. Similar dengan relasi : part-of dalam model data semantic.

Encapsulation




Private : attributes dan methods dienkapsulasi dalam class sehingga dapat diakses oleh
clien akses tersebut  hanya dapat diakses oleh member class tersebut.
Public : metode mendefinisikan inteface sebagai sarana mengakses class dari clint-nya.
Dapat diakses oleh object manapun.
Protected : hanya dapat diakses oleh object-class turunannya.

Oleh : Wahju Tjahjo S.

31

Rekayasa Perangkat Lunak/SI-TI

Komunikasi Dalam Object
1. Object berkomunikasi dengan object lain melalui pengiriman pesan (messages)
 Suatu pesan adalah suatu metode call dari suatu object pengirim-pesan ke suatu object
penerima pesan
 Suatu pesan terdiri dari: Object referensi yang mengindikasikan penerima pesan, nama
method dan parameter (argumen dari method)
2. Object penerima pesan disebut server ke object pengirim pesan, dan objek pengirim pesan
adalah client dari server.

Object Cohesion Dan Coupling
Cohesion suatu komponen adalah ukuran tentang hubungan antara komponen suatu object
class. Setiap operasi menyediakan fungsi untuk mengubah, melihat, atau menggunakan atribut
object sebagai layanan dasar.
Coupling adalah suatu indikasi kekuatan interkoneksi antara program units. Sistem dengan
coupling yg kuat memiliki interkoneksi yang kuat sehingga setiap program unit sangat
ketergantungan dengan yang lainnya (mis.: shared variables, interchange control function).
Sistem dengan couple yang lemah tidak memiliki ketergantungan yang kuat antar program units.

Polymorphism
1. Kemampuan object yang berbeda untuk menjalankan method yang sesuai untuk
merespon ke pesan yg sama.
Oleh : Wahju Tjahjo S.

32

Rekayasa Perangkat Lunak/SI-TI

2. Pemilihan method yang sesuai tergantung pada class yg digunakan untuk membuat
object.

Contoh:
class Shape {
private String name;
public Shape(String aName) { name=aName; }
public String getName( ) { return name; }
public float calculateArea( ) { return 0.0f; }
} // End Shape class
class Circle extends Shape {
private float radius;
public Circle(String aName) { super(aName); radius = 1.0f; }
public Circle(String aName, float radius) {
super(aName); this.radius = radius;
}
public float calculateArea() { return (float)3.14f*radius*radius; }
} // End Circle class
class Square extends Shape {
private float side;
public Square(String aName) { super(aName); side = 1.0f; }
public Square(String aName, float side) {
super(aName); this.side = side;
}
public float calculateArea() { return (float) side*side; }
} // End Square classpublic class ShapeDemoClient {
public static void main(String argv[ ]) {
Shape c1 = new Circle("Circle C1");
Shape c2 = new Circle("Circle C2", 3.0f);
Shape s1 = new Square("Square S1");
Shape s2 = new Square("Square S2", 3.0f);
Shape shapeArray[ ] = {c1, s1, c2, s2};
for (int i = 0; i < shapeArray.length; i++) {
System.out.println("The area of " + shapeArray[i].getName( )
+ " is " + shapeArray[i].calculateArea( )
+ " sq. cm.");
}
} // End main
} // End ShapeDemoClient1 class

OO Analysis
mencari kebutuhan dari perpektif class dan object yang ditemukan dalam suatu vocabulary dari
domain masalah. Dengan kata lain, world (system) dimodelkan dalam bentuk object dan class.

OO Design
Dekomposisi OO dan suatu notasi untuk menggambarkan model system pada tahap
pengembangan. Struktur dibentuk setelah object yang berhubungan dengan system sudah
didefinisikan.

OO-Analisis
1.
2.
3.
4.
5.
6.

Menganalisa domain masalah.
Menggambarkan proses system.
Identifikasi object.
Spesifikasi atribut.
Mendefinisikan Operation.
Inter-object Communication.

Oleh : Wahju Tjahjo S.

33

Rekayasa Perangkat Lunak/SI-TI

Identifikasi Suatu Object
1. Entitas luar (mis.: system lain, alat, orang) yang menghasilkan / menggunakan informasi
yang digunakan system.
2. Benda (mis.: laporan, tampilan, surat, signal) yang merupakan bagian informasi.
3. Peran (mis: manager, engineer, salesperson) yang dimainka oleh orang yang
berinteraksi dengan system.
4. Tempat(mis.: ruangan) yang menyediakan konteks permasalah dan fungsi keseluruhan
system.
5. Unit organisasi (mis.: divisi, group, team) yang relevan ke aplikasi.

Class Fitting

Oleh : Wahju Tjahjo S.

34

Rekayasa Perangkat Lunak/SI-TI

Object Relations

Package




The Unified Modeling Language (UML) is a standard language for writing software
blueprints.
The UML may be used to visualize, specify, construct, and document the artifacts of a
softwareintensive system.

Building Blocks
1. Things
2. Relationships
3. Diagrams
Things :
 Structural things : classes, interfaces, collaborations, use cases, active classes,
components, nodes.
 Behavioral things : interactions, state machines.
 Grouping things : packages.
 Annotational things : notes.

Sha pe
origin
m ov e()
resize()
display ()

Oleh : Wahju Tjahjo S.

35

Rekayasa Perangkat Lunak/SI-TI

Class Inheritance
< >

Shape
origin : Variant
m ove()
res ize()
dis play()

Rectangle
corner : Point

Circle
radius : Double

Po lygon
point : List

Square

Class – Dependencies A change in specification of one thing may effect another thing that uses
it.

FilpClip
nam e
playOn()
start()
stop()
reset()

Channel

Class – Association
A structural relationship that specifies that objects of one thing are connected to objects of
another.
 Name : name of association.
 Role : a specific role of class in an association.
 Multiplicity, an association represent a structural relationship among objects : zero to
one(0..1), many(0..*) or one or more (1..*).
 Aggregation : a plain association between two classes represents a structural
relationship “whole-a-part”Association, Multiplicity, Aggregation and Role.

Oleh : Wahju Tjahjo S.

36

Rekayasa Perangkat Lunak/SI-TI

Structural Things – Use Case
Specifies the behavior of a system or a part of a system and is a description of a set of
sequences of actions, including variants, that a system performs to yield an observable result of
value to an actor.

Use Case Diagram



One of the five diagrams (activity diag., statechart diag., sequence diag., collaboration
diag.) in the UML for modeling the dynamic aspects of systems.
Central to modeling the behavior of a system, a subsystem, or a class.

P e rf o r m C a rd T r a n sa ct io n
R e t a i l I n st i t u t i o n

P ro c e ss C u st o m e r B i l l

C u st o m e r
R e c o n c i l e T ra n sa c t i o n
S p o n so ri n g
Fin a n cia l

M a n a g e C u st o m e r A c c o u n t

Statechart Diagram
A statechart diagram shows a state machine, consisting of states, transitions, events, and
activities.

Activity Diagram An activity diagram is a special kind of a statechart diagram that shows the flow
from activity to activity within a system.

Oleh : Wahju Tjahjo S.

37

Rekayasa Perangkat Lunak/SI-TI

Sequence Diagram A sequence diagram is an interaction diagram that emphasizes the timeordering of messages.

Component DiagramComponent diagram shows an organization and dependencies of a group
of components.

Oleh : Wahju Tjahjo S.

38

Rekayasa Perangkat Lunak/SI-TI

DEPLOYMENT DIAGRAM
Deployment diagram shows the configuration of run-time node processing and its components.

Oleh : Wahju Tjahjo S.

39

Rekayasa Perangkat Lunak/SI-TI

LAMPIRAN-LAMPIRAN
Berikut ini dilampirkan tabel-tabel yang diperlukan pada saat melakukan rekayasa perangkat
lunak dari tahap survei sampai uji pro