MODUL

REKAYASA
PERANGKAT
LUNAK STMIK DHARMAPALA RIAU
 I. INTRODUCTION
TO SOFTWARE
ENGINEERING

1. What and Why Sofware

Engineering ?
1.1 Software Engineering (Rekayasa
Perangkat Lunak)
 Ekonomi dari semua bangsa-bangsa maju tergantung pada
perangkat lunak
 Semakin banyak sistem yang dikendalikan oleh perangkat
lunak
 Rekayasa Perangkat Lunak mempunyai kaitan dengan
teori, metode, dan perkakas (tools) untuk pengembangan
perangkat lunak profesional
 Rekayasa Perangkat Lunak sudah menjadi bagian yang
penting untuk menghadirkan pendapatan nasional pada
semua negara maju
1.2 Software Costs
(Biaya-Biaya Perangkat Lunak)

 Biaya-biaya perangkat lunak sering mendominasi

biaya-biaya sistem. Biaya-biaya perangkat lunak
pada suatu PC sering lebih besar dari harga
perangkat keras.
 Biaya-biaya perawatan perangkat lunak lebih
besar dibanding dengan pengembangan perangkat
lunak, karena sistem dengan masa pakai lama,
biaya pemeliharaan mungkin beberapa kali biaya-
biaya pengembangan.
 Rekayasa Perangkat Lunak mempunyai kaitan
dengan biaya-biaya pengembangan perangkat
lunak yang ekonomis.
1.3 FAQs about Software Engineering
(Pertanyaan-pertanyaan Seputar SE)

 Apakah software itu?

 Apakah software engineering itu?
 Apa perbedaan antara software engineering dan computer science?
 Apa perbedaan antara software engineering dan system engineering?
 Apakah software process itu?
 Apakah software process model itu?
FAQs about Software Engineering (Lanjutan)

 Apa saja yang merupakan biaya-biaya rekayasa perangkat

lunak itu?
 Apa saja metode rekayasa perangkat lunak itu?
 Apakah CASE (Computer-Aided Software Engineering) itu?
 Apa saja atribut dari perangkat lunak yang baik?
 Apakah yang merupakan tantangan kunci dalam
menghadapi rekayasa perangkat lunak?
What is software?

 perintah (program komputer) yang bila dieksekusi

memberikan fungsi dan unjuk kerja seperti yang
diinginkan;
 struktur data yang memungkinkan program
memanipulasi informasi secara proporsional; dan
 dokumen yang menggambarkan operasi dan
kegunaan program.
 Produk Perangkat lunak mungkin :
 Generic(Umum) - yang dikembangkan untuk dijual ke
bidang pelanggan berbeda;
 Bespoke/Custom (Pesanan) - dikembangkan untuk
pelanggan tunggal menurut spesifikasi mereka.
What is software engineering?

 Software engineering adalah suatu disiplin rekayasa (rancang-bangun)

yang terkait dengan semua aspek produksi perangkat lunak.
 Engineer perangkat lunak mengadopsi pendekatan sistematis dan
terorganisir untuk pekerjaan mereka dan menggunakan teknik dan
tools yang disesuaikan dengan masalah yang dihadapi untuk
dipecahkan, batasan pengembangan, dan sumber daya tersedia.
IEEE Definition
(IEEE = Institute of Electrical and Electronic Engineers)

Software engineering adalah:

1. Aplikasi dari sebuah pendekatan yang bersifat kuantifiabel, disiplin, dan
sistematis bagi pengembangan, operasi, dan pemeliharaan perangkat
lunak.
2. Studi tentang pendekatan-pendekatan seperti pada (1)
Bidang Penelitian Software Engineering mengacu pada kedua hal tsb.
What is the difference between software engineering
and computer science?

 Computer science mempunyai kaitan dengan theory and fundamentals; software

engineering mempunyai kaitan dengan practicalities of developing and delivering
useful software.

 Computer science sekarang ini tidak cukup lengkap untuk bertindak sebagai
tiang penyokong software engineering.
 What is the difference between software
engineering and system engineering?

 System engineering mempunyai kaitan dengan semua aspek

pengembangan sistem berbasis-komputer yang mencakup
perangkat keras, perangkat lunak ,dan yang terkait
dengan proses bisnis.
 Software engineering berkonsentrasi pada komponen
perangkat lunak sistem yang lebih besar.
 System engineers mencakup spesifikasi sistem, desain
arsitektur, pengintegrasian, dan penyebaran.
What is a software process?

 Software process merupakan himpunan aktivitas tujuan

pengembangan atau evolusi perangkat lunak.
 Aktivitas umum dalam semua proses perangkat lunak
adalah:
 Specification (Spesifikasi)- hal-hal yang diperlukan oleh sistem
dan
batasan pengembangannya.
 Development (Pengembangan)- produksi sistem perangkat lunak.

 Validation (Pengesahan) - pemeriksaan perangkat lunak sesuai

dengan keinginan pelanggan.
 Evolution (Evolusi) - pengubahan perangkat lunak sesuai dengan
permintaan pelanggan.
What is
a software process model?
 Software process model merupakan representasi
sederhana suatu software process, yang
diperkenalkan dari suatu perspektif spesifik.
 Contoh perspektif proses adalah
 Workflow Perspektif - Urutan aktivitas
 Data-Flow Perspektif - Arus Informasi
 Role/Action Perspektif – Peran dan Aksi
 Proses umum model
 Waterfall
 Evolutionary development
 Formal transformation
 Integration from reusable components
What are the costs of software engineering?

 Perkiraan kasar adalah 60% untuk biaya pengembangan,

sedangkan 40% untuk biaya pengujian. Untuk custom sofware,
biaya-biaya evolusi sering melebihi biaya-biaya pengembangan.

 Biaya-biaya berubah-ubah tergantung pada jenis sistem yang

dikembangkan dan kebutuhan atribut sistem seperti
kehandalan dan reliabilitas sistem.

 Distribusi biaya-biaya tergantung pada model pengembangan

yang digunakan.
What are software engineering
methods?
Software engineering methods merupakan
pendekatan terstruktur dalam pengembangan
perangkat lunak yang meliputi model sistem, notasi,
aturan, desain advice, dan panduan proses.
 Model Descriptions (Uraian Model)
Uraian tentang model grafis yang harus diproduksi.
 Rules (Aturan-aturan)
Batasan yang berlaku pada model sistem.
 Recommendations (Rekomendasi)
Rekomendasi untuk praktik desain yang baik.
 Process guidance (Panduan Proses)
Aktivitas yang mengikuti.
What is CASE (Computer-Aided
Software Engineering)?
 CASE adalah System software yang digunakan untuk mendukung
otomatisasi aktivitas proses perangkat lunak. CASE sering digunakan
untuk mendukung metode.

 Upper-Case

Tools untuk mendukung aktivitas proses awal kebutuhan dan desain.

 Lower-Case

Tools untuk mendukung aktivitas selanjutnya seperti programming,

debugging, dan testing.
What are the attributes of good
software?
Software perlu memiliki fungsi kebutuhan dan kemampuan yang
diperlukan oleh pemakai dan harus maintainable, dependable ,
efficient, dan usable.
 Maintainability
Software harus dapat ditingkatkan dan diubah sesuai dengan
kebutuhan.
 Dependability
Software harus dapat dipercaya (trustworthy).
 Efficiency
Software seharusnya tidak membuat penggunaan sumber
daya sistem menjadi boros.
 Usability
Software harus dapat dipakai oleh para pemakai yang
direncanakan.
What are the key challenges facing
software engineering?
Tantangan : mengatasi sistem warisan (legacy systems),
meningkatnya heterogenitas (Heterogenity) sistem,
dan tuntutan permintaan percepatan
penyerahan(Delivery) sistem.
 Legacy systems
Sistem warisan (sistem lama) harus dirawat dan
dibaharui.
 Heterogenity
Sistem terdistribusikan dalam bentuk campuran antara
perangkat keras dan lunak.
 Delivery
Adanya peningkatan tekanan untuk penyerahan
perangkat
1.4 Professional and Ethical
Responsibility
 Software engineering melibatkan tanggung-jawab lebih luas dibanding hanya
aplikasi kecakapan teknis.
 Software engineer harus bertindak secara etis,bertanggung jawab, dan jujur
jika mereka diharapkan untuk terhormat sebagai seorang profesional.
 Perilaku etis tidak hanya sekedar menegakkan hukum saja tetapi harus lebih
dari itu (lih. hal. berikutnya).
Issues of professional responsibility

 Confidentiality (Kerahasiaan)
Engineer seharusnya menghormati kerahasiaan dari
klien mereka tanpa tergantung dengan ya atau
tidaknya suatu persetujuan kerahasiaan formal
ditandatangani.
 Competence (Kemampuan)
Engineer mestinya tidak salah menggambarkan
tingkatan kemampuannya. Mereka mestinya tidak
dengan sadar menerima pekerjaan yang di luar
kemampuannya.
Issues of professional responsibility
(lanjutan)
 Intellectual property rights (Hak milik intelektual)
Engineers harus sadar akan hukum lokal yang
mengatur penggunaan dari properti intelektual
seperti hak paten, hak cipta, dll. Mereka
harus seksama untuk memastikan bahwa
intelektual properti klien harus dilindungi.
 Computer misuse (Penyalahgunaan Komputer)
Software engineers mestinya tidak menggunakan
kecakapan teknis mereka untuk menyalahgunakan
komputer orang lain. Penyalahgunaan komputer
dari yang relatif sepele (misal untuk bermain
game) sampai yang serius (pemberian virus).
***
2 The
Software
Product
2.1 The Evolving Role of Software

Peran Perangkat Lunak saat ini:

 Berfungsi sebagai sebuah produk
 mengantarkan potensi penghitungan yang dibangun oleh perangkat lunak
komputer. Perangkat lunak sebagai transformer informasi yang
memproduksi, mengatur, memperoleh, memodifikasi, menampilkan atau
memancarkan informasi, sehingga pekerjaan menjadi semakin mudah

 Berfungsi sebagai kendaraan yang mengantarkan sebuah produk

 Dasar untuk kontrol komputer (sistem operasi), komunikasi informasi
(jaringan) dan penciptaan serta kontrol dari program-program lain (piranti
dan lingkungan perangkat lunak)
2.2 Evolution of Software

1st Era
2st 3st 4st
• Batch Era
• Multiuser • Era
Distributed • Era desk-top
Powerful
orientation • Real-time systems systems
• Limited • Database • • Object-oriented
technologies
distribution • Product Embedded • Expert systems
• Custom software ‘intelligence’ • Artificial neural
software • Low networks
cost • Parallel
hardware computing
• Network
computers

1950 1960 1970 1980 1990 2000

2.3 Serangkaian masalah perangkat lunak sehubungan
dengan evolusi sistem berbasis komputer

 Kemajuan perangkat keras terus berlanjut melampaui

kemampuan engineer dalam membangun perangkat
lunak yang sesuai dengan perangkat keras yang ada.
 Kemampuan engineer untuk membangun program baru tidak
dapat memenuhi kebutuhan akan program baru dan tidak
dapat membangun program yang cukup cepat untuk memenuhi
kebutuhan bisnis dan pasar.
 Pemakaian komputer yang tersebar luas membuat
masyarakat semakin tergantung pada operasi perangkat
lunak yang reliabel. Kerusakan ekonomi yang besar dan
potensi penderitaan manusia dapat muncul bila terjadi
kegagalan perangkat lunak.
 Kita masih berjuang untuk membangun perangkat lunak
komputer dengan reliabilitas dan kualitas yang tinggi.
 Kemampuan kita untuk mendukung program yang ada
terhambat oleh buruknya desain serta sumber daya yang
tidak memadai.
2.4 Software Characteristics

Perangkat lunak lebih merupakan elemen

logika dan bukan merupakan elemen fisik,
sehingga perangkat lunak memiliki ciri yang
berbeda dari perangkat keras.
 Perangkat lunak dibangun dan dikembangkan,
tidak dibuat dalam bentuk yang klasik
(manufaktur).
 Perangkat lunak tidak pernah usang.

 Sebagianbesar perangkat lunak dibuat secara

custom-built, serta tidak dapat dirakit dari
komponen yang sudah ada.
Failure Curve of Hardware

kematian
Tingkat segera
kegagalan usang

Waktu
Failure Curve for Software
(idealized)

Tingkat
kegagalan
pada tingkat yang sama
sampai usang

Waktu
Actual Failure Curve for Software
laju kegagalan
meningkat sehubungan
dengan efek sampingan
Tingkat
kegagalan

perubah
an
kurva
kurva
aktual
ideal
Waktu
2.5 Software Components

 Komponen perangkat lunak adalah informasi yang

tersimpan dalam dua bentuk dasar, yaitu
komponen yang tidak bisa dieksekusi (non
machine executable) dan yang dapat dieksekusi
mesin (machine executable).
 Reusability
merupakan suatu ciri penting dari
komponen perangkat lunak kualitas tinggi.
2.6. Software Myths

 Software Miths (mitos-mitos perangkat lunak) adalah

asumsi- asumsi permasalahan yang kebenarannya tidak
dapat dipertanggungjawabkan berkaitan dengan
pengembangan perangkat lunak
 Tiga kelompok yang terkait dalam pengembangan perangkat
lunak
 Management : manajer yang bertanggungjawab terhadap
pengembangan perangkat lunak
 Customer : pelanggan yang memesan perangkat lunak
 Practitioner’s : praktisi yang mengembangkan perangkat
lunak
2.6.1 Management Myths

 Dengan memiliki buku berisi standard dan prosedur yang

banyak untuk pengembangan perangkat lunak, maka
pekerjaan pasti lancar.
 Buku-bukuitu memang lengkap, tapi apakah digunakan ?
Apakah praktisi perangkat lunak sadar dengan keberadaannya.
Apakah cocok dengan pengembangan yang modern ? Apakah
benar-benar lengkap ?
 Untuk menghasilkan perangkat lunak yang berkualitas,
maka
kita perlu membeli komputer terbaru.
 Untuk mendapatkan perangkat lunak yang berkualitas, CASE
tools lebih penting daripada perangkat keras.
 Bila terlambat maka tambahlah jumlah programer
 Penambahan programmer semakin menambah keterlambatan.
2.6.2 Customer Myths

 Tujuan sistem secara umum cukup untuk memulai menulis program,

rincian belakangan saja.
 Definisi awal yang buruk merupakan sebab utama gagalnya kerja perangkat
lunak
 Rincian kebutuhan sistem sangat penting:
 fungsi
 performance
 antar-muka
 batasan rancangan
 kriteria validasi
 dll
 Perangkat lunak bersifat fleksibel, perubahan kebutuhan mudah
diakomodasi oleh pengembang perangkat lunak
 Dampak perubahan sangat bergantung pada tahap mana perubahan terjadi
2.6.3 Practitioner’s Myths

 Program selesai, pekerjaan selesai

 50% - 70% usaha dihabiskan setelah program
diserahkan ke user untuk pertama kalinya.
 Kualitas hanya bisa diketahui setelah
program berjalan (running)
 Kualitas dapat dijaga sejak PL dikembangkan.
 Yangdiserahkan ke user adalah
program
 Yang diserahkan adalah program, dokumen, dan
data.
3. The
Software
Process
3.1 Software Engineering Layers

Tools

Methods

Process

Quality
3.2 A Generic View of
Software Engineering
 Engineering meliputi kegiatan analisis, desain, konstruksi,
verifikasi, dan manajemen kesatuan teknik atau sosial.
 Pertanyaan-pertanyaan yang harus dimunculkan dan
dijawab:
 Apa masalah yang akan dipecahkan?

 Karakteristik
entitas yang manakah yang dipakai untuk
menyelesaikan masalah tersebut?
 Bagaimanakah entitas (dan pemecahan) tersebut diadakan?
 Bagaimanakah entitas tersebut dibangun?

 Pendekatan apakah yang akan dipakai untuk menemukan

kesalahan-kesalahan yang dibuat dalam desain dan kontruksi
dari entitas tersebut?
 Bagaimanakah entitas tersebut ditopang selama proses adaptasi
yang lama, pada saat koreksi, serta ketika perbaikan dibutuhkan
3.3 General Phase to Software
Engineering
 Definition phase  berfokus pada ‘apa’ (what):
 informasi yang akan diproses
 fungsi dan perfomance yang dibutuhkan
 tingkah laku sistem yang diharapkan
 interface yang akan dibangun
 batasan sistem yang sukses
 Development phase  berfokus pada ‘bagaimana’ (how):
 data dikonstruksikan
 fungsi-fungsi diimplementasikan
 detail prosedur akan diimplementasikan
 interface dikarakterisasi
 rancangan akan diterjemahkan ke dalam
pemrograman
 pengujian dilakukan
 Maintenance phase  berfokus pada ‘perubahan’ (change):
 dihubungkan dengan koreksi kesalahan
 ketika lingkungan perangkat lunak berkembang
 sehubungan dengan perubahan kebutuhan pelanggan
3.4 Changes in Phase Development

 Correction (Koreksi)
 membetulkan cacat atau kerusakan
 Adaptation (Adaptasi)
 modifikasi perangkat lunak karena perubahan kebutuhan fungsional
original (CPU, OS, aturan bisnis, karakteristik produk eksternal, dll)
 Enhancement (Perkembangan)
 memperluas perangkat lunak sehingga melampaui kebutuhan fungsi
originalnya
 Prevention (Pencegahan)
 pencegahan sebagai antisipasi perubahan karena usia perangkat lunak
3.5 Umbrella
Activities
 Software project tracking and control
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Document preparation and production
 Reusability management
 Measurement
 Risk management
3.6 Software Development Stages

 Requirements Analysis &

Specification
 Conceptual/System Design
 Detailed/Program Design
 Implementation/Coding
 Unit & Integration Testing
 System Testing
 System Delivery
 Maintenance
3.7. The Software Process

Common Process Framework

Framework Activities
Task Sets

Umbrella Activities
3.7.1 Five Process Maturity Levels (SEI=Software
Engineering Institute)

 Level 1: Initial
Software process yang ditandai seperti ad hoc dan chaotic
(kesemrawutan).
 Level 2: Repeatable
Tracking / penelusuran masalah biaya, jadwal, dan fungsionalitas proyek-
proyek terdahulu.
 Level 3: Defined
Pendokumentasian, standarisasi, dan pengintegrasian software proses
pada perangkat lunak organisasi besar.
 Level 4: Managed
Pengukuan detail dan kualitas produksi perangkat lunak.
 Level 5: Optimizing
Penambahan proses melalui umpan balik kuantitatif, gagasan inovatif
pengujian, dan teknologi.
3.8. Software Process Models

 Linier Sequential Model

 Waterfall Model
V Model
 RAD Model
 Prototyping Model
 Evolutionary Model
 Incremental Model
 Spiral
Model
 Component Assembly Model
 Concurrent Development Model
 Formal Model
 Fourth Generation Techniques
3.8.1. Linier Sequential Model

System/Information
Engineering

Analysis Design Code Test

3.8.1.1 Waterfall Model

 Sebuah pendekatan pengembangan perangkat

lunak yang sistematik dan sekuensial.
 Disebut juga ‘Classic Life Cycle’.
 Paradigma yang sudah lama sekali, tetapi masih
banyak yang memakai karena dianggap masih
sesuai dengan keadaan sekarang.
Waterfall Model Diagram

Requirement
s
definition
System and
software design

Implementatio
n and unit
testing
Integr ation
and system
testing
Operation
and
maintenance
Modified Waterfall Model (M.Kochanski)

Sashimi Waterfall with Spiral Introduction

Waterfall with Subprojects

3.8.1.2 V Model

Validate requirem ents O P E R AT I O N

REQUIREMENTS & MAINTENANC
A N A LY S I S

ACCEPTAN CE
TESTING
SY ST E M
DE S I G N

SYSTEM
Verify design
T E ST IN G

P R O GR A M UNI T & I N TE -
D ES I G N G R AT I O N T E S T I N G

CODING
3.8.1.3 RAD Model

 RAD = Rapid Application Development

 Adaptasi dari waterfall model yang:
 menekankan siklus pengembangan perangkat lunak yang sangat
pendek;
 menggunakan pendekatan konstruksi berbasis komponen.
 Menciptakan sistem fungsional yang utuh dalam waktu 60-90 hari.
RAD Model Diagram

t e a m # 3

b u s in e s s
m o d e lin g

t e a m # 2
d at a
m o d e lin g
business

t e a m # 1 m o d e lin g process
m o d e lin g
data
b u s in e s s m o d e lin g a p p lic a tio n
generation
m o d e lin g
process testing
data &
m o d e lin g m o d e lin g tu rn o v e r

a p p lic a tio n
generation
proces s

m o d e lin g testing
&
a p p lic a tio n tu rn o v e r
g e n e ra tio n

testing
&
tu rn o v e r

6 0 - 9 0 hari
RAD Model Phases

 Business Modelling
Memodelkan fungsi-fungsi bisnis untuk menjawab
pertanyaan- pertanyaan:
Informasi apa yang mengendalikan proses bisnis ? Informasi apa yang
dimunculkan? Ke mana infomasi itu pergi? Siapa yang memprosesnya?
 Data Modelling
Aliran informasi yang didefinisikan pada fase business modelling
ditransformasikan ke dalam serangkaian obyek data.
 Process Modelling
Mentransformasikan obyek data pada suatu fungsi yang
menghasilkan aliran
informasi yang dibutuhkan.
 Application Generation
Mengkonstruksi perangkat lunak dengan memakai komponen yang ada (bila
memungkinkan) atau menciptakan komponen yang dapat dipakai lagi.
 Testing and Turnover
Menguji komponen baru.
3.8.2 Prototyping Model
Dipakai jika:
 Sistem mempunyai resiko tinggi
 tidak jelas permasalahannya
 Lebih fokus pada perancangan dialog user - komputer
 bagaimana membuat dialog yang baik, ramah,
mudah ?
 Sistem diminati oleh banyak pemakai
 mencari kesepakatan (dasar untuk menyamakan
persepsi)
 User ingin cepat selesai
 user tidak sabar menunggu
 prototipe segera memperlihatkan bentuk kerja
sistem
 Masa pakai singkat
 sistem hanya dipakai beberapa kali saja
 Ingin menunjukkan inovasi
 pengembang dapat menunjukkan kecanggihan
 Kebutuhan berubah-ubah
Types of Prototyping

 Evolutionary prototyping
Dimulai dari model, kemudian dikembangkan dan akhirnya dipakai.
 Throw-away prototyping
Hanya dikembangkan sebagai model untuk mencari blue-print.
Evolutionary Prototyping

Prototype
Requirements

Prototype
Programming

Reviews

Validates?

Release
Throw-away prototyping

Prototype System
Requirements Programming

System
Prototype Testing
Programming

Validates?
Reviews
Reviews

Validates?

Release
Prototyping Speciality

 Frekuensi komunikasi user – developer meningkat

 pengembang akan selalu meminta pendapat user
 Membantu analis dalam
 menentukan kebutuhan user yang sebenarnya
 meminimalkan salah persepsi
 Peran user meningkat
 evaluasi oleh user berkali-kali
 user bisa memberikan masukan setiap saat
 Pengembangan lebih cepat
 program bisa langsung dibuat
 user melihat perkembangan tahap demi tahap
 Implementasi mudah
 user sudah mengenal perangkat lunak yang
dikembangkan
 user tidak akan merasa asing
 sejak awal user sudah merasa memiliki
Prototyping Weakness

 User sibuk
 user & pengembang harus sama-sama memiliki komitmen
menyediakan waktu untuk bertemu.
 User sulit melakukan evaluasi
 bentuk prototipe sering berubah, disesuaikan
dengan kebutuhan
user.
 User ingin cepat selesai
 bentuk program sudah terlihat sejak awal.
 user merasa tidak akan lama lagi selesai.
 pengembang sering mengabaikan dokumentasi.
 User berharap terlalu banyak
 keseringan evaluasi & komunikasi membuat user menjadi
berubah keinginan dan tidak pasti dengan kebutuhan.
 Prototipe bekerja tidak efisien
 lebih mementingkan keberhasilan.
3.8.3 Evolutionary Model
3.8.3.1 Incremental Model

 Incremental Model merupakan gabungan antara

model linier sekuensial dan prototyping.
 Setiaplinier sekuen menghasilkan produk yang
deliveriables.
 Increment pertama merupakan produk inti (core),
yang mengandung persyaratan/kebutuhan dasar.
 Penambahan dilakukan pada increment-increment
berikutnya.
Incremental Model Diagram

system/information
engineering

delivery of
analysis design code test
1st increment

delivery of
increment 2 analysis design code test
2nd increment

delivery of
increment 3 analysis design code test
3rd increment

delivery of
increment 4 analysis design code test
4th increment
3.8.3.2 Spiral Model

 Evolutionary process (pengembangan bertingkat)

 Menggabungkan keunggulan prototyping dan
waterfall
 Memungkinkan dikembangkannya perangkat
lunak
secara bertahap (incremental) dan cepat.
 Terbagi atas 6 tahapan
 customer communication
 planning
 riskanalysis
 engineering
 construction & release
 customer evaluation
Spiral Model Diagram

Planning analisa resiko

berdasarkan evaluasi
Integration and test Risk Analysis
user
plan
development plan analisa resiko
menentukan
berdasarkan
tujuan, development plan
kebutuhan
alternatif,
awal
batasan sistem Requirements
dan budget
Customer prototipe awal
Communication
Engineering

prototipe tingkat
berikutnya
Project
Entry Point produk-jadi
Customer
Evaluation Construction
& Release
3.8.3.3 Component Assembly
Model

identify candidate
components

look up components construct n- th

in library iteration of system

extract components put new

if available components in
library

build components if
unavailable

Engnniegeriinngeering,
e

contruction & release customer evaluation

entry point Customer

risk analysis communication

planning
3.8.3.4 Concurrent Development Model

none
Analysis activity

Under
development

A waiting Under
changes review

Under
revision
baselined

done
Konkurensi Tercapai dengan Cara:

 aktivitassistem dan komponen yang berlangsung

secara simultan dan dapat dimodelkan dengan
menggunakan pendekatan orientasi keadaan;
 aplikasi
klien/server khusus yang
diimplementasikan dengan banyak komponen yang
masing-masing bisa dirancang dan direalisasikan
secara konkuren.
3.8.4 Formal Model

 mencakup sekumpulan aktivitas yang membawa

kepada spesifikasi matematis perangkat lunak
komputer;
 memungkinkan software engineer untuk
mengkhususkan, mengembangkan, dan mem-
verifikasi sistem berbasis komputer dengan
menggunakan notasi matematis yang tepat;
 Variasi dari pendekatan ini disebut clean-room
software engineering.
Formal method akan dibahas pada bab tersendiri
3.8.5 Fourth Generation Techniques
(4GT)
 Terkait dengan penggunaan tools.
 Pengembang software mendefinisikan karakteristik
software secara 'high level'; tool secara otomatis akan
membangkitkan kode.
 4GT mempercepat proses pengembangan perangkat
lunak.
 Proses perancangan dan dokumentasi baik.
 Masih dipertanyakan beberapa pihak: efisiensi kode
yang
dihasilkan, kemudahan (relatif).
4GT
Techniques
requirements
gathering

design strategy

implementation
using 4GL

testing

***
 4. Konsep Manajemen Proyek
1.
P
4.1 Peop erangkat
le
Para Pemain (Stakeholder)
Lunak
2.
3.
Pemimpin Tim
Tim Perangkat Lunak
4. Tiga Organisasi Tim (Mantei)
5. Faktor-faktor dalam Perencanaan Struktur Tim RPL (Mantei)
6. Pengaruh Karakteristik Proyek pada Struktur Tim
7. Masalah Koordinasi dan Komunikasi
8. Teknik Koordinasi Proyek (Kraul dan Streeter)
2. Problem
1. Ruang Lingkup Masalah
2. Dekomposisi Masalah
3. Proses
1. Menggabungkan Masalah dan Proses
2. Dekomposisi Proses
3. Contoh Dekomposisi (simple project)
69
4. Contoh Dekomposisi (complex project)
 Konsep Manajemen Proyek
Perangkat Lunak
 Manajemen Proyek Perangkat Lunak merupakan
suatu aktivitas pelindung (umbrella activity)
untuk mengelola proyek perangkat lunak, yang
difokuskan pada 3P: People (manusia); Problem
(masalah) dan Process (proses)
 People:semua orang yang terlibat dalam proyek
perangkat lunak
 Problem: menentukan ruang lingkup dan batasan
proyek
perangkat lunak sekaligus teknik pemecahannya.
 Process:
kerangka kerja yang komprehensif dalam
70 pembangunan perangkat lunak
4.1 People

4.1.1 Para Pemain (Stakeholder)

 Senior managers: yang menentukan isu-isu bisnis yang sering
memiliki pengaruh penting dalam proyek.
 Project (technical) managers: yang harus merencanakan,
memotivasai, mengorganisasi, dan mengontrol sebuah produk
atau aplikasi.
 Practitioners: yang menyampaikan keteranpilan teknik yang
diperlukan untuk merekayasa sebuah produk atau aplikasi.
 Customers: yang menentukan jenis kebutuhan bagi
perangkat
lunak yang akan direkayasa.
 End users: yang akan memakai perangkat lunak.
71
4.1.2 Pemimpin
Tim
 Pemimpin tim (team leaders): seseorang yang
memimpin sebuah proyek perangkat lunak.
 Syarat : Model Kepemimpinan MOI (Weinberg):
 Motivasi: kemampuan untuk memberi dorongan
pada staf teknis untuk menghasilkan sesuatu
dengan kemampuan terbaiknya.
 Organisasi: kemampuan untuk membentuk proses
yang sedang berlangsung yang memungkinkan
konsep dasar diterjemahkan ke dalam suatu hasil
akhir.
 Gagasan dan Inovasi: kemampuan untuk
mendorong manusia untuk menciptakan dan
72
dalam suatu
bertindak ikatan
kreatif yang dibangun
meskipun merekauntuk suatu
bekerja di
produk perangkat lunak yang spesifik.
4.1.3 Tim Perangkat Lunak

 Alternatif pemanfaatan SDM pada proyek perangkat

lunak:
 n individu diberi m tugas fungsional yang berbeda (m >
n), ada individu yang merangkap kombinasi kerja.
 n individu diberi m tugas yang berbeda (m < n), secara tidak
langsung terbentuk tim informal.
n individu dibagi menjadi t tim, setiap tim mempunyai tugas
yang spesifik.
 Struktur
tim yang terbaik berdasarkan gaya
manajemen, jumlah orang, tingkat keahlian,
kompleksitas masalah.
4.1.4 Tiga Organisasi Tim
(Mantei) Democratic Decentralized (DD); tidak ada pimpinan yang tetap,
keputusan diambil secara bersama-sama, hubungan horizontal.
 Controlled Decentralized (CD); ada pimpinan untuk setiap 'task' dan sub-
pimpinan untuk 'sub-task', terjadi komunikasi horizontal & vertikal.
 Controlled Centralized (CC); ada team leader untuk top-level problem
solving & koordinasi internal, koordinasi vertikal

74
4.1.5 Faktor-faktor dalam Perencanaan
Struktur Tim RPL (Mantei)
 Tingkat kesulitan masalah
 Besarnya program (dalam LOC atau FP)
 Team lifetime
 Tingkat modularitas program
 Kualitas dan reliabilitas program
 Batas waktu pengembangan
 Tingkat sosialisasi (sosiabilitas) proyek

75
4.1.6 Pengaruh Karakteristik Proyek
pada Struktur
Te a m type: D D C D C C

Tim Difficulty
high x
low x x
Size
large x x
small x
Te a m lifetime
short x x
long x
Modularity
high x x
low x
Reliability
high x x
low x
Delivery date
strict x
lax x x
Sociability
high x
low x x
76
4.1.7 Masalah Koordinasi dan Komunikasi

Ada banyak hal yang menyebabkan proyek perangkat lunak bermasalah,

penyebabnya diantaranya adalah:
 Scale (skala): skala proyek yang demikian besar, sehingga koordinasi sulit.
 Uncertainty (ketidakpastian): perubahan-perubahan yang terus-menerus.
 Interoperability (interoperabilitas): perangkat lunak yang dibuat harus
dapat
berkomunikasi dengan perangkat lunak yang lain.

77
4.1.8 Teknik Koordinasi Proyek
(Kraul dan Streeter)
 Pendekatan impersonal, formal.
Dokumen, memo teknis, milestone proyek, schedule, error
tracking report, dll
 Prosedur interpersonal, formal.
Difokuskan pada jaminan kualitas kegiatan, diantaranya
inspeksi desain dan kode.
 Prosedur interpersonal, informal.
Group meeting untuk bertukar informasi dan problem
solving, requirement gathering dan pengembangan staff.
 Komunikasi elektronik.
E-mail, E-BB, web sites, video conference.
 Jaringan interpersonal.
78
Diskusi informal dengan orang di luar proyek.
4.2 Problem
 Manajer proyek perangkat lunak berhadapan
dengan dilema awal proyek, yaitu menentukan
perkiraan kuantitatif dan rencana organisasi
tetapi informasi yang akurat belum tersedia.
 Requirement analysis yang lengkap dibutuhkan
untuk melakukan estimasi, tetapi memerlukan
waktu yang lama dan kadang-kadang
kebutuhan berubah-ubah pada saat proyek
berjalan.
Solusi: definisikan scope (ruang lingkup) dengan
benar dan segera.
79
4.2.1 Ruang Lingkup Masalah
 dibatasi oleh:
 Context
Bagaimana perangkat lunak yang dibangun dapat
memenuhi sebuah sistem, produk, atau konteks
bisnis yang lebih besar, serta apa batasan yang
ditentukan sebagai hasil dari konteks tersebut?
 Information Objectives
Obyek data pelanggan apa yang dihasilkan sebagai
output dari perangkat lunak, dan obyek data apa
yang diperlukan sebagai input?
 Function dan performance
80
Fungsi apa yang dilakukan oleh perangkat lunak
untuk mentransformasi input data menjadi output?
4.2.2 Dekomposisi Masalah
 Dekomposisi masalah disebut juga partitioning (pembagian), merupakan
aktivitas yang mendudukkan inti dari analisis kebutuhan perangkat
lunak.
 Dekomposisi dilakukan dalam 2 area:
 Fungsionalitas yang harus dihasilkan
 Proses yang akan dipakai untuk menghasilkan sesuatu
 Manusia cenderung melakukan dekomposisi jika menghadapi masalah
yang kompleks

81
4.3 Proses
 Fase-fase generik dan menandai proses perangkat lunak: definisi,
pembangunan, dan pemeliharaan
 Fase generik dijalankan menggunakan salah satu model rekayasa
perangkat lunak.
 Project manager harus memilih model rekayasa yang paling tepat
berdasarkan karakteristik masalah, tim, dan kriteria proyek.

82
 4.3.1 Menggabungkan Masalah dan
Proses
 Tahap awal project planning dimulai dengan penggabungan
problem dan process.
 Setiap fungsi yang akan direkayasa harus melampaui
sejumlah aktivitas yang sudah ditentukan
 Misal organisasi mengadopsi kerangka aktivitas sbb:
 Customer communication – membangun komunikasi yang efektif
antara pengembang dan pelanggan
 Planning – menentukan sumber daya, ketepatan waktu, dan
informasi proyek yang lain
 Risk analysis – menentukan resiko-resiko manajemen dan teknis
 Engineering – membangun aplikasi perangkat lunak
 Construction and release – membangun, menguji, menginstal,
dan memberikan dukungan kepada pemakai (dokumen dan
pelatihan)
83
 Customer evaluation – umpan balik pelanggan

 Selanjutnya dibuat matriksnya.

84
4.3.2 Dekomposisi Proses
 Memilih paradigma rekayasa perangkat lunak
yang paling baik sesuai dengan tingkat
relativitas dari perangkat lunak.
 Bila proyek relatif kecil dan mirip dengan proyek
sebelumnya, maka dapat dipilih pendekatan linier
sekuensial
 Bila masalah dapat dipecah-pecah dan batasan
waktu yang ketat, maka dapat dipilih model RAD.
 Bila batas waktunya ketat, tetapi fungsionalitas
tidak dapat optimal, maka dapat dipilih strategi
pertambahan. dll
 Sekali model dipilih, kerangka kerja umum
85
dengan model.Process Framework) harus disesuaikan
(CPF=common
4.3.3 Contoh Dekomposisi
(simple project)
 Membuat daftar klarifikasi
 Bertemu dengan customer untuk klarifikasi

 Bersama-sama menentukan scope

 Review scope
 Penyempurnaan scope berdasarkan berbagai kendala

86
4.3.4 Contoh Dekomposisi
(complex project)
 Mengkaji kebutuhan customer
 Merencanakan dan menjadwal sebuah pertemuan formal dengan
customer
 Melakukan penelitian untuk menentukan pemecahan yang
diusulkan
 Mempersiapkan dokumen kerja serta agenda untuk pertemuan
formal
 Mengadakan pertemuan
 Secara bersama-sama mengembangkan spesifikasi detail yang
merefleksikan data, fungsi, dan karakteristik yang berhubungan
dengan perilaku perangkat lunak
 Mengkaji setiap spesifikasi detail tersebut untuk upaya perbaikan,
konsistensi, dan mengurangi ambiguitas
 Mencantumkan spesifikasi detail ke dalam sebuah dokumen ruang
lingkup
 Mengkaji dokumen ruang lingkup dengan semua pendapat yang
ada.
 Memodifikasi dokumen ruang lingkup sesuai dengan kebutuhan.
87
***
5. Proses Perangkat Lunak dan Metrik Proyek

1. Domain Metrik
1. Tujuan Umum Pengukuran
2. Determinan Kualitas dan Efektivitas Perangkat Lunak
2. Pengukuran Perangkat Lunak
1. Size-Oriented Metrics
2. Function-Oriented Metrics
1. Function Points
2. Penghitungan Metrik Function Points
3. Feature Points
4. Penentuan Kompleksitas Transformasi Function Points
3. Penyatuan Pendekatan Metrik yang Berbeda
4. Kualitas Perangkat Lunak
1. Faktor yang Mempengaruhi Kualitas
2. Faktor yang Mempengaruhi Kualitas (Gilb)
5.5 Penyatuan Metrik-metrik dlm Proses Perangkat Lunak 88
Proses Perangkat Lunak dan Metrik Proyek

 Measure (mengukur); kuantitatif luasan, jumlah,

dimensi, kapasitas, atau ukuran dari atribut sebuah
proses atau produk.
 Measurement (pengukuran); kegiatan menentukan
sebuah measure.
 Metrics (IEEE): ukuran kuantitatif dari tingkat di
mana sebuah sistem, komponen, atau proses memiliki
atribut tertentu
 Indikator adalah sebuah metrik atau kombinasi dari
metrik yang memberikan pengetahuan ke dalam proses
perangkat lunak, sebuah proyek perangkat lunak, atau
produk perangkat lunak.
89
5.1 Domain Metrik

 Pengukuran perangkat lunak dilakukan pada proses dan proyek

perangkat lunak.
 Indikator proses memungkinkan:
 Software engineer memperoleh pengetahuan tentang reliabilitas sebuah
proses yang sedang berlangsung.
 Manajer dan pelaksana memperkirakan hal-hal yang harus dikerjakan dan
yang tidak
 Indikator proyek, memungkinkan manajer proyek:
 Memperkirakan status proyek
 Menelusuri resiko-resiko potensial
 Menemukan area masalah sebelum menjadi kritis
 Menyesuaikan aliran kerja atau tugas-tugas
 Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas.
90
5.1.1 Tujuan Umum Pengukuran
 Mengetahui kualitas perangkat lunak; baik
atau jelek
 Menilai produktifitas pembuatan perangkat lunak;
kecepatan pembuatan, ukuran perangkat lunak
 Menilai manfaat dari penerapan sebuah metoda;
mencari paradigma andalan
 Dasar untuk melakukan perkiraan; pedoman di
masa mendatang
 Membantu untuk memastikan apakah dibutuhkan
91
peralatan baru atau pelatihan tambahan?
5.1.2 Determinan Kualitas dan
Efektivitas Perangkat Lunak
Product

B u d it io
tic
ct e e r

Co
ara tom

si n n s
ris

n
es
Ch Cu s

s
Process

People Technology
Development

92
Environment
5.2 Pengukuran Perangkat Lunak

 Size-Oriented Metrics: metrik yang berorientasi pada besar fisik ukuran

perangkat lunak
 Function-Oriented Metrics: metrik yang berorientasi pada fungsionalitas dan
utilitas perangkat lunak, menggunakan:
 Function Points
 Feature Points

93
5.2.1 Size-Oriented Metrics
 Normalisasikualitas dan produktivitas dengan
mengukur besar-kecilnya (LOC/KLOC)
perangkat lunak, sehingga diperoleh:
 Error per KLOC
 Defect (cacat) per KLOC
 Rupiah (Rp) per LOC
 Halaman dokumentasi per KLOC

 Metrik lain dapat diturunkan:

 Error per orang-bulan
 LOC per orang-bulan
 Rupiah (Rp) per halaman dokumentasi
94
Contoh (size-oriented metrics)

Project LOC Effort $(000) pp.doc. Errors Defects People

alpha 12,100 24 168 365 134 29 3

beta 27,200 62 440 1224 321 86 5

gamma 20,200 43 314 1050 256 64 6

.. .. .. .. .. .. .. ..

95
Kontroversi Size-Oriented Metrics

 Metrik size-oriented tidak diterima secara universal;

kontroversi terletak pada pemakaian LOC.
 Pendukung: LOC merupakan artifak proyek
pengembangan perangkat lunak yang mudah dihitung.
 Penentang: LOC tergantung bahasa pemrograman,
LOC tidak mendukung desain yang baik tetapi
program singkat, tidak dapat dengan mudah
mengakomodasi bahasa non-prosedural, dan
pemakaiannya membutuhkan tingkat detail yang sulit
dicapai.
96
5.2.2 Function-Oriented Metrics

 Mengukur secara tidak langsung.

 Ditekankan pada fungsional & utilitas program.
 Diusulkan pertama kali oleh Albrecht, dengan usulan
cara perhitungan yang disebut: function point
(FP).
 FP diturunkan dengan menggunakan hubungan empiris
berbasis pada sesuatu yang terukur dari domain
informasi dan berhubungan dengan kompleksitas PL.
(lihat berikut)
97
5.2.2.1 Function Points

Domain Informasi:
 Jumlah input dari user: jumlah user input yang
dibutuhkan aplikasi
 Jumlah output untuk user: jumlah semua keluaran
baik laporan maupun kesalahan (ke printer/layar)
 Jumlah input inquiry: masukan on-line yang
mengakibatkan keluaran on-line
 Jumlah file
 Jumlah interface eksternal: semua interface
yang
dibaca oleh mesin untuk memindahkan informasi ke
sistem lain.
98
5.2.2.2 Penghitungan Metrik Function
Point Weighting Factor
s measurement parameter count simple averagecomplex

number of user inputs x 3 4 6 =

number of user outputs x 4 5 7 =

number of user inquiries x 3 4 6 =

number of files x 7 10 15 =

number of external interfaces x 5 7 10 =

FP= total x [0.65 + 0.01 x  Fi]
total
Domain kompleksitas
99
Fi (i = 1 s/d 14) adalah ‘complexity adjustment values’
berdasarkan respon yang diperoleh dari pertanyaan-pertanyaan
Pertanyaan-Pertanyaan

Untuk menghitung Fi, pertanyaan-pertanyaan di bawah ini dijawab dengan memberi nilai antara 0 s/d
5

 Apakah sistem memerlukan backup dan recovery?

 Apakah diperlukan fasilitas komunikasi data?

 Apakah diperlukan fasilitas ‘distributed processing’?

 Apakah kinerja sangat penting?

 Apakah sistem akan dijalankan pada lingkungan yang sudah ada yang sudah terpakai secara penuh?

 Apakah memerlukan pemasukan data secara ‘on-line’?

 Apakah pemasukan data ‘on-line’ terjadi pada transaksi input thd layar atau operasi ganda?

 Apakah file master di’update’ secara on-line?

 Apakah input,output, file secara inquiry begitu kompleks?

 Apakah proses internal begitu kompleks?

 Apakah kode yang dibuat harus dapat digunakan ulang?

 Apakah konversi dan instalasi termasuk dalam perancangan?

 Apakah sistem dirancang untuk dapat diinstall pada berbagai organisasi yang berbeda?

 Apakah aplikasi dirancang untuk memberikan fasilitas perubahan dan kemudahan pemakaian bagi user ?
100
5.2.2.3 Feature Points
 Seperti function point dengan penambahan
karakteristik perangkat lunak lain: algorithma.
 Boeing telah mengembangkan function point
extension untuk sistem-sistem real time yang
disebut 3D function point.
 Untuk menghitung 3D function point hubungan
berikut dipakai
 Index = I + O + Q + F + E + T + R
Keterangan : I = input O = output
Q = inquiry, F = internal data structure
E = external file, T = transformation,
101
R = transition.
5.2.2.4 Penentuan Kompleksitas
Transformasi Function Points
Semantic
Statements
1-5 6 - 10 11 +

Processing
Steps

1 - 10 low low average

11 - 20 low average high

21 + average high high

102
 Perhitungan 3D function point index

103
 5.3 Penyatuan Pendekatan
Metrik yang Berbeda
Banyaknya LOC yang dibutuhkan untuk membangun 1
FP

104
5.4 Kualitas Perangkat Lunak
5.4.1 Faktor yang Mempengaruhi Kualitas
McCall dan Cavano mendefinisikan satu set quality factors yang merupakan
tahap awal untuk mengembangkan metrik untuk pengukuran kualitas
perangkat lunak:
 product operation (using it),
 product revision (changing it), dan
 product transition
(porting it). (dibahas di Bab
Matriks Teknis PL)

105
 5.4.2 Faktor yang Mempengaruhi Kualitas
(Gilb)
 Correctness: perangkat lunak bekerja dengan baik & benar ( correctness =
kesalahan / kloc )

 Maintainability: mudah dirawat; mttc (mean time to change) kecil

 Integrity: tahan gangguan; tingkat sekuriti yang baik

 Usability: mudah digunakan

106
5.5 Penyatuan Metrik-metrik dalam
Proses Perangkat Lunak
software
engineering
process

software data
project collection measures

data
collection metrics
software

product data
collection indicators

107

***
 6. Perenc. Proyek Perangkat Lunak (Software
Project Planning)
1. Observasi pada Estimasi
2. Tujuan Perencanaan Proyek
3. Ruang Lingkup Perangkat Lunak
1. Rangkaian Pertanyaan SW Scope

1. Contoh Rangkaian Pertanyaan Pertama

2. Contoh Rangkaian Pertanyaan Kedua

3. Contoh Rangkaian Pertanyaan Ketiga

2. Contoh Scoping

1. Penjelasan Gambar

2. Dekomposisi Pernyataan

3. Kesimpulan Contoh Scoping

4. Sumber Daya
1. Sumber Daya Manusia

2. Reusable Software Resources

3. Environmental Resources

5. Estimasi Proyek Perangkat Lunak

1. Teknik Dekomposisi

1. Software Sizing

2. Problem-based Estimation

3. Contoh Estimasi Berbasis-LOC

4. Contoh Estimasi Berbasis FP

5. Contoh Estimasi Berbasis Proses

2. Empirical Estimation Models

1. Beberapa Model Estimasi

108
2. COnstructive COst MOdel (COCOMO)

3. Persamaan Perangkat Lunak

 Perenc. Proyek Perangkat Lunak

 Project planning adalah serangkaian aktivitas-aktivitas kolektif dalam proses

manajemen proyek perangkat lunak.
 Estimation adalah aktivitas pertama dalam project planning
 Estimation menjadi dasar bagi aktivitas perencanaan proyek yang lain.
 Project planning menjadi peta jalan bagi kesuksesan rekayasa perangkat lunak

109
6.1 Observasi pada Estimasi

 Estimasi pada project planning meliputi estimasi

sumber daya, biaya, dan jadwal pengembangan
perangkat lunak.
 Hal-hal yang mempengaruhi estimasi:
 Project
complexity (kompleksitas proyek); berpengaruh
terhadap ketidakpastian yang inheren dalam perencanaan
 Projectsize (ukuran project); berpengaruh terhadap akurasi
estimasi
 Structural
uncertainty (ketidakpastian struktural);
berpengaruh terhadap resiko estimasi
110
6.2 Tujuan Perencanaan Proyek

 menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat

estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya,
dan jadwal.
 Tujuan project planning dapat tercapai melalui proses penemuan informasi
yang menunjuk ke estimasi yang dapat dipertanggungjawabkan.

111
6.3. Ruang Lingkup Perangkat Lunak
(Software Scope)

Fungsi (functions)
Kinerja (perfomance)
Batasan(constraints)
Antarmuka (interface)
Keandalan (reliability)

112
6.3.1. Rangkaian Pertanyaan SW Scope
 Lingkup PL yang akan dibuat ditentukan melalui
pertemuan-pertemuan antara customer dengan
developer
 Untuk menjembatani jurang komunikasi antara
customer dengan developer, Gause & Weinberg
mengusulkan 3 rangkaian pertanyaan berikut:
 Rangkaian pertanyaan pertama adalah sekumpulan
pertanyaan bebas konteks yang memusatkan pada
customer, sasaran keseluruhan PL yang dibuat,
dan keuntungan yang akan diperoleh.
 Rangkaian pertanyaan kedua adalah sekumpulan
pertanyaan yang memungkinkan analis mendapatkan
pemahaman yang lebih baik atas problem, dan
customer dapat menyuarakan persepsinya atas suatu
113
pertanyaan
solusi. yang memusatkan pada efektivitas
dari pertemuan itu sendiri (disebut meta-
 Rangkaian pertanyaan ketiga adalah pertanyaan-
questions).
6.3.1.1 Contoh Rangkaian Pertanyaan Pertama

 Siapa di belakang permintaan pekerjaan ini?

 Siapa yang akan menggunakan solusi ini?

 Keuntungan ekonomis apa yang diperoleh dari solusi ini?

 Adakah sumber daya lain untuk solusi ini?

114
6.3.1.2 Contoh Rangkaian Pertanyaan Kedua

 Bagaimana anda mengkarakterisir keluaran “yang

baik” yang akan dimunculkan oleh solusi ini?
 Problem apa saja yang akan dihadapi oleh solusi
ini?
 Dapatkan anda menunjukkan kepada kami (atau
menjelaskan) lingkungan di mana solusi ini akan
dipakai?
 Adakah
batasan atau isu kinerja khusus yang akan
mempengaruhi cara pendekatan terhadap solusi?
115
6.3.1.3 Contoh Rangkaian Pertanyaan Ketiga

 Apakah anda orang yang tepat untuk menjawab pertanyaan-pertanyaan

ini? Apakah jawaban anda “resmi”?
 Apakah pertanyaan-pertanyaan kami relevan untuk problem yang anda
punya?
 Apakah saya terlalu banyak pertanyaan?
 Apakah ada orang lain yang dapat memberikan informasi-informasi
tambahan?
 Apakah ada hal-hal lain yang harus kami tanyakan kepada anda?

116
6.3.2. Contoh Scoping

conveyor line
motion
2

ID No. ID No. ID No. ID No.

4
bar code
shunt

SORTING
117
STATION 5
control
connection
6.3.2.1 Penjelasan Gambar
 Conveyor Line Sorting System (CLSS) menyortir box-box
yang bergerak pada ban berjalan.
 Setiap box diidentifikasi dengan bar code yang
menyatakan nomor part.
 Box-box tersebut akan disortir ke dalam 6 wadah
berdasarkan nomor part.
 Box-box tersebut melewati stasiun sortir yang berisi
pembaca bar code dan sebuah PC (Personal Computer).
 PC di stasiun sortir dihubungkan dengan mekanisme
langsiran (shunt) yang akan menyortir box-box tersebut
ke dalam wadah-wadah yang sesuai.
 Box-box tersebut lewat dengan urutan yang acak dan
berjarak sama.
 PL CLSS menerima informasi masukan dari pembaca bar
ban berjalan.
118

code dengan interval waktu sesuai dengan kecepatan

6.3.2.1 Penjelasan Gambar(lanj)
 Data bar code tersebut akan didekodekan ke dalam format
identifikasi box.
 PL akan melakukan look-up pada basis data part number
yang berisi maksimum 1000 entry untuk menentukan lokasi
wadah yang sesuai bagi box yang saat itu di stasiun sortir.
 Lokasi wadah yang sesuai diberikan pada sorting shunt
yang
akan menempatkan box tersebut pada wadah yang sesuai.
 Sebuah catatan (record) yang berisi wadah tujuan dari
setiap box dibangkitkan untuk recovery nantinya dan
pelaporan.
 PL CLSS juga menerima masukan dari sebuah
tachometer
pulsa yang akan dipakai untuk sinkronisasi sinyal kontrol ke
119
mekanisme
tersebut shunting.
dengan benar.
 Berdasarkan pada jumlah pulsa yang akan dibangkitkan
antara stasiun sortir dan shunt, PL akan menghasilkan
6.3.2.2 Dekomposisi Pernyataan
 Dekomposisi dari pernyataan di atas, dapat diekstrak
menjadi fungsi-fungsi penting dari PL yang akan dibuat;
yaitu:
 read bar code input (membaca input bar code)
 read pulse tachometer (membaca pulsa tachometer)
 decode part code data (mengkodekan bagian data
kode)
 do database look-up (mengerjakan look-up database)
 determine bin location (menentukan lokasi kotak
penyimpanan
 produce control signal for shunt (memproduksi sinyal
kontrol untuk shunt)
120
rekaman tujuan kotak)
 maintain record of box destinations (memelihara
6.3.2.3 Kesimpulan Contoh Scoping

 Kinerja sistem ini ditentukan oleh kecepatan ban

berjalan. Pemrosesan setiap box harus selesai
sebelum box berikutnya tiba di pembaca bar code.

 Kendala-kendala yang membatasi PL CLSS adalah

meliputi perangkat keras yang harus diakses
(pembaca bar code, shunt, PC), memori yang
tersedia, dan konfigurasi keseluruhan dari lini ban
berjalan tersebut.
121
6.3.2.3 Kesimpulan Contoh Scoping (lanj)

 Interface : PL yang dibuat berinteraksi dengan

elemen-elemen lain dari sistem berbasis komputer
ini. Konsep interface mempunyai arti;
(1) hardware yang mengeksekusi PL dan perangkat lain yang
secara tidak langsung dikontrol oleh PL tersebut.
(2) software yang telah ada dan harus dilink dengan
software
yang baru (dibuat) tersebut.
(3) orang yang menggunakan PL tersebut via keyboard atau I/O
devices lainnya.
(4) prosedur-prosedur yang mengawali atau mengakhiri
(mengikuti) PL tersebut sebagai urutan operasi yang
122 sekuensial.
6.4 Sumber Daya

People

Reusable Software
Components

Hardware/Softwar
e Tools
123
6.4.1 Sumber Daya Manusia

 Diperlukan keahlian untuk menyelesaikan pengembangan PL; baik dari segi

posisi organisasional (misal: manager, senior software engineer, dsb) maupun
spesialisasi (misal: telekomunikasi, basis data, dsb).
 Sedangkan jumlah banyaknya personil yang dibutuhkan ditentukan setelah
estimasi beban kerja (development effort).

124
6.4.2 Reusable Software Resources

 Off-the-shelf components; memanfaatkan yang telah

dibuat pada proyek internal sebelumnya.
 Full-experience components; mereview spesifikasi,
kode, desain atau pengujian data dari proyek
sebelumnya
 Partial-experience components; aplikasi, kode, desain
atau data dari proyek sebelumnya dihubungkan
dengan proyek sekarang
 New components; pembuatan komponen baru
125
6.4.3 Environmental Resources

 Lingkungan yang mendukung proyek PL, disebut juga software engineering

environment (SEE); meliputi
 hardware
 software
 hardware & software khusus

126
6.5. Estimasi Proyek Perangkat Lunak
(Software project estimation)
 Ada 2 teknik dalam melakukan estimasi proyek perangkat lunak, yaitu:

Decomposition Techniques
Empirical Estimation Models

127
6.5.1. Teknik Dekomposisi
(Decomposition techniques)
 Dekomposisi masalah : memecah-mecah masalah yang
kompleks menjadi serangkaian masalah yang lebih kecil.
 Ketelitian estimasi proyek PL diprediksi pada sejumlah
hal:
(1) derajat ketepatan estimasi ukuran produk yang
akan
dibuat,
(2) kemampuan menterjemahkan ukuran terestimasi
tersebut ke dalam beban kerja, waktu kalender, dan
rupiah,
(3) derajat rencana proyek yang mencerminkan
kemampuan tim software, dan
128
(4) kestabilan persyaratan-persyaratan produk dan
lingkungan yang mendukung upaya software
6.5.1.1 Software Sizing

 Dalam kontek project planning, size mengacu pada

hasil-hasil proyek PL yang dapat dikuantifikasi.
 Putnam & Myers mengusulkan 4 cara untuk
pengukuran problem;
 Fuzzy-logic sizing; menggunakan teknik reasoning
aproksimasi
 Function point sizing; mengembangkan estimasi karakteristik
domain informasi
 Standard component sizing; menggunakan komponen-
komponen standar yang ada.
 Change sizing; memodifikasi PL dengan banyak cara,
menggunakan suatu rasio kerja setiap perubahan, sehingga
ukuran perubahan dapat diperkirakan

129
6.5.1.2 Problem-based Estimation
 Data LOC dan FP dipakai dalam dua hal selama estimasi proyek PL:
(1) sebagai suatu estimation variable yang dipakai untuk “memberi
ukuran” pada setiap elemen PL yang akan dibuat, dan
(2) sebagai baseline metrics yang dikumpulkan dari proyek terdahulu
dan dipakai bersama-sama dengan estimation variable untuk
menghitung proyeksi biaya dan beban kerja.

130
 6.5.1.2 Problem-based Estimation
(lanj)
 Tanpa memandang variabel estimasi yang dipakai, project planner mulai
dengan mengestimasi rentang nilai untuk setiap fungsi atau nilai domain
informasi.
 Dengan menggunakan data historis atau intuisi, ditentukan ukuran nilai
yang optimistik (sopt), rata-rata (sm), dan yang pesimistik (spess).
 Kemudian dihitung nilai yang diharapkan (three-point atau expected
value) sbb.
 EV = (sopt + 4 sm + spess)/6

131
6.5.1.3 Contoh Estimasi Berbasis-LOC
 Rekayasa : Software CAD yang dapat menerima
data geometrik 2-D dan 3-D dari seorang engineer.
Engineer akan berinteraksi dan mengkontrol
sistem CAD tersebut melalui user interface yang
akan mencerminkan karakteristik perancangan
interface human-machine yang baik.
 Semua data geometrik dan informasi pendukung
lainnya akan disimpan dalam suatu basis data
CAD.
 Modul-modul analisis - design akan dibuat untuk
menghasilkan keluaran yang akan memperagakan
(display) pada berbagai graphics devices.
 Software akan dirancang guna mengontrol dan
berinteraksi dengan devices periferal yang
132
 6.5.1.3 Contoh Estimasi Berbasis-LOC
(lanj)

 Kita asumsikan fungsi-fungsi utama PL tersebut adalah:

 user interface and control facilities (UICF)
 two-dimensional geometric analysis (2DGA)
 three-dimensional geometric analisys (3DGA)
 database management (DBM)
 computer graphics display facilities (CGDF)
 peripheral control (PC)
 design analysis modules (DAM)

133
 6.5.1.3 Contoh Estimasi Berbasis-LOC
(lanj)
Function Estimated LOC

user interface and control facilities (UICF) 2.300

two-dimensional geometric analysis (2DGA) 5.300

three-dimensional geometric analysis (3DGA) 6.800

database management (DBM) 3.350

computer graphics display facilities (CGDF) 4.950

peripheral control (PC) 2.100

design analysis modules (DAM) 8.400

estimated lines of code 33.200

134
6.5.1.4 Contoh Estimasi Berbasis FP
est.
Information Domain Value opt. likely pess. count weight FP-count

number of inputs 20 24 30 24 4 96
number of outputs 12 15 22 16 5 80
number of inquiries 16 22 28 22 4 88
number of files 4 4 5 4 10 40
number of external interfaces 2 2 3 2 7 14

count-total 318

135
 6.5.1.4 Contoh Estimasi Berbasis FP(lanj)

F a c t o r V a l u e
B a c k u p a n d r e c o v e r y 4
D a t a c o m m u n i c a t i o n 2
D i s t r i b u t e d 0
p r o c e s s i n g 4
P e r f o r m a n c e critical 3
E x i s t i n g o p e r a t i o n e n v i r o n m e n t 4
O n - l i n e d a t a e n t r y 5
I n p u t t r a n s a c t i o n o v e r m u l t i p l e 3
s c r e e n s 5
M a s t e r files u p d a t e d o n - l i n e 5
I n f o r m a t i o n d o m a i n v a l u e s c o m p l e x 4
i n t e r n a l p r o c e s s i n g c o m p l e x 3
C o d e d e s i g n e d f o r r e u s e 5
C o n v e r s i o n / i n s t a l l a t i o n i n d e s i g n 5
M u l t i p l e i n s t a l l a t i o n s 1 .1 7
A p p l i c a t i o n d e s i g n e d f o r c h a n g e
C o m p l e x i t y=a c
d jo uus nt m
t -e tn ot tf aa cl t ox r [ 0 , 6 5 + 0 , 0 1 x  F ]
F P e s t i m a t e d
i

136 = 3 7 2
F P e s t i m a t e d
6.5.1.5 Contoh Estimasi Berbasis Proses

 Sederetan kegiatan proses software harus dikerjakan untuk masing-

masing fungsi.
 Fungsi-fungsi dan kegiatan-kegiatan proses PL yang terkait dapat
dinyatakan dalam tabel berikut.

137
 c
u pl r
st a i
COMMON PROCESS o n s e ng i n e e r in g
ni k
FRAMEWORK m
n
er
ACTIVITIES g
a
co
n
m a
m l
un y
ic s
ati i
on s

Software Engineering Tasks

Product Functions
Text input
Editing & formatting
Automatic copy edit
Page layout capability
Automatic indexing & TOC
File management
Document production

138
6.5.2 Empirical Estimation Models

 Model estimasi untuk software komputer dengan

menggunakan formula-formula yang diturunkan secara
empirik untuk memprediksi beban kerja sebagai
fungsi dari LOC atau FP.
 Data empirik yang mendukung model-model estimasi
tersebut diturunkan dari sample proyek yang terbatas.
 Model-model estimasi mempunyai struktur sbb.

E  A  B  (ev)C
dengan A , B, dan C adalah konstanta yang diturunkan
secara empirik
E a d a l a h eff ort d a l a m o r a n g b u l a n
ev adalah variabel estimasi (dalam L O C atau FP)
139
6.5.2.1 Beberapa Model Estimasi

LOC-Oriented
E  5,2 (KLOC ) 0,91
E  5,5  0,73 (KLOC )1,16
Walston-Felix model
Bailey-Basili model
Boehm simple model

E  3,2 (KLOC )1,05 Doty model untuk

KLOC > 9
E  5,288 (KLOC )1,047
Albrecht and Gaffney model
FP-Oriented
Kemerer model
E   13,39  0,0545 (FP )
Matson, Barnett, and Mellichamp
140
E  60,62 7,728 10 8(FP)3 model
6.5.2.2 COnstructive COst MOdel
(COCOMO)
Model mempunyai bentuk hirarki (berdasarkan
Boehm) sbb:

Model 1. Basic COCOMO Model

Menghitung development effort (dan cost) sebagai fungsi
dari ukuran program yang dinyatakan dalam estimasi LOC.

E = abKLOCbb

D = cbEdb

141
dengan E adalah effort (usaha) dalam orang-bulan dan D
adalah waktu pengembangan dalam bulan kronologis.
 Dengan mengambil nilai pada Untuk menghitung durasi proyek:
contoh CAD, maka biaya per- D = 2,5 E0,35
person: E = 2,5 (95)0,35
E = 2,4 (KLOC)1,05 E = 12,3 month
E = 2,4 (33,2)1,05
E = 95 person-
month Jumlah orang
yang disetujui:
• Organic – proyek perangkat lunak yanEg =sedEe/rDha=na9d5an/1re2la,3tif
142 =ke~ci8l

• p e r so n
 Model 2. Intermediate COCOMO Model

Menghitung usaha pengembangan PL sebagai fungsi

ukuran program dan serangkaian pengendali biaya
yang menyangkut penilaian yang subyektif terhadap
produk, hardware, personil, dan atribut proyek.

E = aiKLOCbi x EAF

dengan E adalah effort dalam orang-bulan dan EAF

adalah faktor penyesuaian usaha dengan harga
berkisar antara 0,9 sampai 1,4.
143
 Model 2. Intermediate COCOMO Model (lanj)

Software Project ai bi
organic 3,2 1,05
semi-detached 3,0 1,12
embedded 2,8 1,20
• Organic – proyek perangkat lunak yang sederhana dan relatif
kecil
• Semi-detached – proyek perangkat lunak menengah
• Embedded – proyek perangkat lunak yang kompleks
seperti PL penerbangan
144
 Model 3. Advanced COCOMO
Model
Menghubungkan semua karakteristik model
intermediate dengan penilaian terhadap pengaruh
pengendali biaya pada setiap langkah (analisis,
perancangan, pemrograman, dll) dari proses rekayasa
perangkat lunak.

145
6.5.2.3 Persamaan Perangkat Lunak
 Persamaa PL : model multivariasi yang mengasumsikan
distribusi khusus effort sepanjang hidup proyek
pengembangan perangkat lunak.
 Dihasilkan (estimasi) dari data produktivitas 4000 proyek
perangkat lunak yang sejaman.
 Didefinisikan sbb:
E = [LOC x B0,333/P]3 x (1/t4)
keterangan :
E= effort dalam person-month atau person-year t
= durasi proyek dalam bulan atau tahun
B = faktor skill khusus (pertumbuhan skill). Untuk
program kecil
(KLOC=5 sampai 15) B=0,16; untuk program lebih besar dari 70
KLOC, B=0,39
P = parameter produktivitas
146 tmin
 =8,14(LOC/P)
Waktu pengembangan
0,43 minimum didefinisikan:
***
 7. PENGELOLAAN RISIKO

Definisi Konseptual Risiko

7.1 Strategi Risiko: Reaktif vs Proaktif
2. Karakteristik Risiko
3. Identifikasi Risiko
4. Proyeksi Risiko
5. Pengurangan (Mitigation), Monitoring, dan
Manajemen Risiko (RMMM)
7.6 Safety Risks & Hazards
147
 Definisi Konseptual Risiko
(Robert Charette)
• Risiko berkaitan dengan kejadian yang akan
datang.
• Risiko melibatkan perubahan, seperti
perubahan dalam pemikiran, opini, tindakan,
atau tempat.
• Risiko melibatkan pilihan dan ketidakpastian
dalam pilihan itu sendiri.

148
 Dalam konteks rekayasa perangkat lunak :
• risiko apa saja yang dapat menyebabkan proyek PL
serba salah?

• Bagaimana perubahan-perubahan dalam persyaratan-

persyaratan pelanggan, teknologi pengembangan,
komputer target, dan entitas lain yang berkaitan
dengan keberhasilan proyek secara keseluruhan?

• Metode-metode dan tool-tool apa yang harus

dipakai, berapa orang yang harus dilibatkan,
seberapa jauh penekanan terhadap kualitas yang
149 dipandang cukup memadai?
 7.1 Strategi Risiko: Reaktif vs Proaktif
• Strategi reaktif : tim PL tidak melakukan sesuatu
sampai sesuatu yang tidak diinginkan terjadi.
Kemudian tim akan bertindak untuk mengatasi
masalah tersebut secepatnya. Cara ini kadang-kadang
disebut “fire fighting mode”.
• Strategi proaktif : kegiatan menanggulangi risiko
sudah diawali jauh sebelum kerja teknis dimulai.
Dalam hal ini, risiko-risiko yang potensial diidentifikasi,
probabilitas dan pengaruh proyek diperkirakan, dan
dibuat prioritas berdasarkan tingkat pentingnya.
Kemudian tim membuat rencana untuk mengelola
risiko-risiko tersebut.
150
 7.2. Karakteristik Risiko
Ketidakpastian - kejadian yang mencirikan
suatu risiko dapat terjadi atau tidak,
yaitu tidak ada risiko kemungkinan 100%.
Kerugian - jika risiko menjadi kenyataan,
akibat yang tidak diinginkan atau kerugian
akan diperoleh.

151
 Dalam menganalisis risiko, adalah sangat
penting untuk mengkuantifikasi tingkat
ketidakpastian dan tingkat kerugian yang
ditimbulkan oleh masing-masing risiko.

Untuk itu perlu dipertimbangkan berbagai

kategori risiko.
1. Kategori Risiko
2. Kategori Risiko Menurut R. Charette

152
 7.2.1 Kategori Risiko
 risiko proyek : potensi muncul dari
pembiayaan, jadwal, personal, sumber daya,
pelanggan, persyaratan, kompleksitas,
ukuran, dan ketidakpastian struktural.
 risiko teknis : yang disebabkan oleh
ambiguitas, spesifikasi, ketidakpastian teknik,
keusangan teknik, dan teknologi yang
leading edge.
 risiko bisnis : risiko pasar, risiko strategi,
pemasaran, risiko manajemen, dan risiko
153
biaya.
 7.2.2 Kategori Risiko Menurut R. Charette

• Know risks : risiko yang dapat ditemukan

setelah evaluasi yang hati-hati pada rencana
proyek, lingkungan bisnis & teknis proyek yang
sedang dikerjakan, dan sumber-sumber informasi
handal lainnya.

• Predictable risks : risiko yang diesktrapolasi

dari pengalaman proyek-proyek sebelumnya.

• Unpredictable risks : risiko-risiko yang sangat

154 sulit diketahui sebelumnya.
 Ada 2 tipe risiko untuk masing-masing kategori di
atas.
• Generic risks : risiko yang mengancam setiap
proyek PL.
• Product specific risks : risiko-risiko yang hanya
dapat diidentifikasi dengan pemahaman yang
jelas pada teknologi, SDM, dan lingkungan yang
spesifik bagi proyek tersebut. Untuk mengiden-
tifikasi risiko tipe ini, rencana proyek &
pernyataan tentang lingkup PL yang akan dibuat
diperiksa.
155
 7.3. Identifikasi Risiko
Identifikasi risiko adalah upaya sistematis untuk menentukan
ancaman-ancaman pada rencana proyek (estimasi, jadwal,
pembebanan sumber-sumber, dsb.).

Salah satu metoda untuk mengidentifikasi risiko adalah dengan

membuat sebuah risk item checklist. Dari checklist tersebut
dapat dilakukan pembandingan dengan pengalaman proyek
sebelumnya.
Bila deviasinya sama atau lebih besar, atau banyaknya
jawaban negatif, maka risiko proyek tersebut dapat dikatakan
tinggi.

Checklist tersebut dapat dipakai untuk mengidentifikasikan dan

memusatkan perhatian pada suatu subset dari known &
156 predictable risks dalam subkategori umum berikut.
7.3.1 Item Identifikasi Risiko
 7.3.1 Item Identifikasi Risiko
 Ukuran produk : risiko yang timbul sehubungan dengan ukuran
perangkat lunak yang direkayasa.
 Dampak bisnis : berkaitan dengan batasan yang dibebankan oleh
manajemen atau pasar.
 Karakteristik pelanggan : berhubungan dengan kecerdikan
pelanggan dan kemampuan perekayasa untuk berkomunikasi
dengan pelanggan.
 Definisi proses : risiko yang berkaitan dengan masalah-masalah
proses dan teknis rekayasa.
 Lingkungan pengembangan : berhubungan dengan
ketersediaan
dan kualitas tools yang digunakan dalam rekayasa.
 Teknologi yang akan dibangun : risiko sehubungan dengan
157
kompleksitas sistem dan ‘kebaruan’ teknologi.
 Jumlah dan pengalaman staf : risiko sehubungan dengan
 7.3.2. Komponen-komponen & Penggerak Risiko
Penggerak risiko yang mempengaruhi komponen-komponen risiko PL -
kinerja, biaya, support, dan jadwal, harus diidentifikasi.

7.3.2.1 Komponen Risiko

• Performance risk
Derajat ketidakpastian bahwa produk akan memenuhi persyaratan-
persyaratannya dan sesuai untuk pemakaian yang
diperuntukkannya.
• Support risk
Derajat ketidakpastian bahwa PL akan mudah dikoreksi, diadaptasi,
dan ditingkatkan.
• Cost risk
Derajat ketidakpastian bahwa anggaran proyek akan terjaga (tetap).
• Schedule risk
158 Derajat ketidakpastian bahwa jadwal proyek tidak akan berubah
dan
 7.3.2.2 Penggerak Risiko
Dampak dari setiap penggerak risiko pada komponen risiko
dibagi (dikelompokkan) ke dalam salah satu dari empat
kategori berikut;
 kecil sekali (negligible),
 kecil (marginal),
 kritis (critical), dan
 bencana (catastrophic).
Tabel berikut ini yang dikembangkan oleh Angkatan
Udara AS merupakan pedoman untuk menunjukkan
konsekuensi potensial kesalahan (label 1) dan
konsekuensi potensial jika hasil akhir yang diinginkan
tidak tercapai (label 2).
159
 U

160
 7.4. Proyeksi Risiko
Proyeksi risiko, atau disebut juga estimasi risiko, mencoba
untuk menentukan peringkat setiap risiko berdasarkan dua
hal;
• Kemungkinan atau probabilitas bahwa risiko tersebut
nyata ada,
• Akibat (konsekuensi) pada problem-problem yang
terkait pada risiko tersebut bila benar terjadi.
7.4.1 Kegiatan Proyeksi Risiko
7.4.2 Pembuatan Tabel

161
Risiko
7.4.3 Penilaian Risiko
 7.4.1 Kegiatan Proyeksi Risiko
• Menetapkan suatu skala yang mencerminkan
kemungkinan yang dibayangkan pada suatu
risiko,
• Melukiskan akibat-akibat dari risiko tsb.
• Mengestimasi dampak risiko pada proyek dan
produk, dan
• Mencatat akurasi keseluruhan dari proyeksi
risiko tsb sehingga tidak akan terjadi salah
pengertian.
162 Untuk memudahkan digunakan tabel berikut.
 7.4.2 Pembuatan Tabel
Risiko
Teknik sederhana untuk proyeksi risiko adalah
dengan Tabel Risiko (lihat tabel).
Setelah semua risiko yang mungkin (terpikirkan)
serta probabilitas kemunculannya dan tingkat
dampaknya, tertuliskan semua, tahap selanjutnya
adalah mengurutkan berdasarkan resultan
probabilitas dan dampak (merupakan kegiatan
penentuan prioritas).
Tahap selanjutnya adalah menentukan cut-off
line.
163
 RMMM

60%

70%

Cut-off

80%

80%

60%

PS : Product Size
BU : Business Risk
CU : Customer Risk
TE : Technology Risk
DE : Development
ST : Staff Risk
Risk
164
 Risiko-risiko di atas garis cut-off harus ditangani
dengan seksama.
Risiko-risiko di bawah garis cut-off dievaluasi
kembali untuk menentukan prioritas tahap kedua.
Penggerak-penggerak risiko (bukan dampaknya)
dapat dinilai berdasarkan skala probabilitas
kualitatif dengan nilai-nilai: impossible,
improbable, probable, dan frequent.

165
 Pengaruh Probabilitas dan Dampak
impact
Risiko thd Perhatian Manajemen

very high low

Faktor risiko
dengan
pengaruh tinggi
tetapi
probabilitas
rendah, tidak
boleh
menyerap high
sebagian besar
perhatian management
manajemen. concern

very low
0

1.0

166
probability of
occurrence
 7.4.3 Penilaian Risiko
Tingkat referen resiko adalah tingkat degradasi
kinerja, pembengkakan biaya, kesulitan
dukungan, dan melesetnya jadual atau
kombinasinya yang menyebabkan proyek
diterminasi.
Tingkat referen resiko ini memiliki nilai tunggal
yang disebut referent point yang merupakan titik
impas untuk meneruskan atau menghentikan
proyek sama-sama dapat diterima. Titik-titik ini
kemudian dibuat prediksinya (lihat gambar). Bila
167
suatu kombinasi resiko jadwal dan biaya jatuh
pada daerah kurva yang tertutup akan
 Proyeksi melesetnya jadwal Titik referen (nilai biaya,nilai waktu)

168
Proyeksi membengkaknya jadwal
 7.5. Pengurangan (Mitigation), Monitoring, dan
Manajemen Risiko (RMMM)
Semua kegiatan analisis risiko mempunyai satu
tujuan tunggal : membantu tim proyek dalam
pengembangan suatu strategi untuk menghadapi
risiko.
Strategi yang efektif harus mempertimbangkan 3 isu
berikut:
• menghindari risiko (risk avoidance),
• monitoring risiko (risk monitoring),
• manajemen risiko dan perencanaan kemungkinan
(risk management & contingency planning).
169
 7.5.1 Menghindari Risiko (risk avoidance)
Bila tim PL mengadopsi cara proaktif, maka
penghindaran risiko selalu merupakan strategi yang
terbaik.
Hal ini dicapai dengan mengembangkan rencana untuk
mengurangi/menghindari risiko (risk mitigation).
Misal : pergantian staf (turnover) yang tinggi
merupakan salah satu risiko proyek (ri),
yang digambarkan dalam bentuk triplet
sbb :
[ri, li, xi]
170
dan pengaruhpada
Berdasarkan (xi ) dari
data risiko tersebut
historis diprediksi
dan intuisi,
pada biaya dan jadwal proyek.
kritis kemungkinan (li)
 Untuk mengurangi risiko ini, manajemen proyek
harus mengembangkan suatu strategi untuk
mengurangi turnover. Langkah-langkah yang
mungkin diambil adalah sbb.
1. Adakan pertemuan dengan staf untuk menentukan
sebab-sebab turnover (misal kondisi kerja yang
jelek, gaji rendah, pasar tenaga kerja yang
kompetitif).
2. Ambil tindakan untuk mengurangi sebab-sebab
tersebut sebelum proyek mulai.
3. Begitu proyek mulai, misalkan turnover akan terjadi,
maka kembangkan teknik-teknik untuk menjamin
171 kontinuitas bila seseorang meninggalkan
pekerjaannya.
 4. Organisir tim proyek sehingga informasi
mengenai setiap kegiatan pengembangan
tersebar luas.
5. Tentukan standar dokumentasi dan tetapkan
mekanisme untuk memastikan bahwa dokumen-
dokumen tersebut dibuat dengan tepat.
6. Laksanakan kajian antarteman terhadap semua
pekerjaan tersebut sehingga lebih dari satu
orang yang terbiasa dengan pekerjaan itu.
7. Tentukan backup anggota staf pada setiap
teknologi kritis.
172
 7.5.2 Monitoring Risiko (risk monitoring)
Sebagaimana proyek bergerak maju, kegiatan risk monitoring mulai.
Manajer proyek memantau faktor-faktor yang dapat memberikan
indikasi apakah risiko kemungkinan menjadi nyata atau kurang nyata?
Dalam contoh staff turnover, faktor-faktor berikut harus dipantau.
• Perilaku umum dari anggota tim berdasarkan pada tekanan-
tekanan proyek.
• Derajat kesatuan tim (kekompakan).
• Hubungan interpersonal di antara anggota tim.
• Masalah-masalah potensial yang berkaitan dengan
kompensasi dan keuntungan.
• Ketersediaan (availability) pekerjaan-pekerjaan di dalam
173
perusahaan tersebut dan di luar.
 7.5.3 Manajemen Risiko dan Perencanaan Kemungkinan

Risk management & contingency planning

mengasumsikan bahwa upaya pengurangan
(mitigation) telah gagal dan risiko telah menjadi
kenyataan.
Saat proyek sudah benar-benar berjalan dan jika
strategi mitigasi juga dijalankan, maka backup
telah tersedia (ada), informasi terdokumentasi,
dan pengetahuan telah disebarkan pada tim.
Selain itu, manajer proyek dapat secara temporer
melakukan pemusatan kembali sumber-sumber
174
(dan menyesuaikan kembali jadwal proyek).
 7.6 Safety Risks & Hazards (keselamatan & bahaya)

Risiko tidak hanya terbatas pada proyek PL itu sendiri.

Risiko dapat muncul setelah PL sukses dibuat
dan diserahkan kepada pelanggan.
Risiko-risiko ini secara tipikal berkaitan dengan akibat-
akibat dari kegagalan PL di lapangan.
Walaupun probabilitas kegagalan pada sistem yang
direkayasa dengan baik adalah kecil, suatu fault yang
tidak terdeteksi pada sistem kontrol atau monitoring
yang berbasis komputer dapat menyebabkan
kerugian yang besar.
175
 Software safety & hazard analysis adalah kegiatan
software quality assurance yang memusatkan
perhatian pada identifikasi dan penilaian hazard-
hazard yang potensial yang dapat memberi
dampak negatif pada PL dan menyebabkan seluruh
sistem gagal.
***

176
 8. PROJECT SCHEDULING &
TRACKING
1. Konsep Dasar
1. Penyebab Keterlambatan Proyek PL
2. Prinsip-prinsip Dasar
2. Hubungan Manusia dan Kerja
1. Contoh
2. Distribusi Effort
3. Penentuan Rangkaian Tugas Proyek PL
1. Rangkaian Tugas (Task Set)
2. Beberapa Tipe Proyek
3. Tingkat Kesulitan
4. Penentuan Kriteria Adaptasi
5. Penghitungan Nilai Task Set Selector
6. Contoh Perhitungan TSS
7. Contoh Perhitungan TSS utk Proyek Pengembangan Aplikasi
Baru
8. Memilih Task-task Rekayasa PL
9. Contoh task-task utama rekayasa perangkat lunak
4. Rincian Task-task Utama
5. Penentuan Task Network
6. Penjadwalan
8.1 Konsep Dasar
8.1.1 Penyebab Keterlambatan Proyek PL
• Batas penyerahan yang tidak realistis yang ditetapkan oleh
seseorang di luar grup rekayasa PL dan memaksakannya
pada manajer dan praktisi dalam grup tsb.
• Perubahan kebutuhan pelanggan yang tidak tercermin
dalam jadwal.
• Memandang rendah jumlah sumber daya yang akan
diperlukan untuk mengerjakan pekerjaan tsb.
• Resiko-resiko yang dapat diprediksi dan/atau resiko-resiko
yang tidak dapat diprediksi yang belum dipertimbangkan
ketika proyek dimulai.
• Kesulitan-kesulitan teknis yang belum dapat diramalkan
• Kesulitan-kesulitan manusia yang tidak dapat
diprediksi sebelumnya.
• Miskomunikasi di antara staf proyek yang
mengakibatkan keterlambatan.
• Ketidakmampuan manajer proyek untuk mengetahui
bahwa proyek tidak mengikuti jadwal dan tidak
melakukan tindakan yang dapat mengatasi masalah
tsb.
Batas waktu yang agresif (tidak realistik) adalah sebuah
kenyataan. Seringkali batas waktu tersebut ditetapkan
berdasarkan alasan-alasan yang disetujui oleh orang
yang menetapkan batas waktu tersebut, tetapi
seharusnya juga disetujui oleh orang yang
mengerjakannya.
8.1.2 Prinsip-prinsip Dasar
Realitas RPL : ada ratusan tugas kecil yang harus
dikerjakan untuk mencapai tujuan yang lebih besar.
Tugas manajer proyek : menentukan tugas-tugas proyek,
mengindentifikasi tugas-tugas yang kritis, dan menelusuri
kemajuannya untuk memastikan bahwa penundaan dapat
direorganisasi setiap hari.
Solusi : manajer harus mempunyai jadwal yang telah
ditetapkan dengan derajat resolusi yang memungkinkan
manajer memonitor kemajuan dan mengontrol proyek
tersebut.
Penjadwalan proyek PL : suatu kegiatan mendistribusikan
beban kerja terestimasi sepanjang durasi proyek yang telah
direncanakan dengan mengalokasikan beban kerja pada
tugas-tugas rekayasa PL. Prinsip-prinsip dasarnya sbb
Prinsip-prinsip Dasar
1. Compartmentalization (pembagian). Proyek harus
dibagi-bagi ke dalam sejumlah tugas dan aktivitas yang
dapat ditangani. Untuk melakukan ini, baik produk
maupun proses harus didekomposisi.

2. Interdependency (saling ketergantungan). Saling

ketergantungan dari setiap tugas dan aktivitas yang
dibagi-bagi harus ditentukan. Beberapa tugas harus
dikerjakan berurutan; yang lain dapat dikerjakan secara
bersamaan. Beberapa kegiatan tidak dapat dimulai
karena harus menunggu hasil dari kegiatan lain.
Beberapa kegiatan lainnya dapat bekerja secara bebas.
3. Time allocation (alokasi waktu). Masing-masing tugas
yang akan dijadwalkan harus dialokasikan dalam
sejumlah satuan kerja (misalnya kerja orang-hari).
Selain itu harus ditetapkan waktu mulai dan waktu
selesai.
4. Effort Validation (validasi kerja). Dengan alokasi waktu,
manajer harus menjamin bahwa tidak terjadi alokasi
yang melebihi jumlah staf yang ada dalam suatu waktu.
5. Defined responsibilities (batasan tanggungjawab).
Setiap tugas yang dijadwalkan harus ditugaskan kepada
satu anggota tim tertentu.
6. Defined outcomes (batasan keluaran). Setiap tugas
yang dijadwalkan harus memiliki keluaran tertentu.
7. Defined milestones (tonggak ukur). Setiap tugas atau
grup tugas harus terkait dengan project milestone.
8.2 Hubungan Manusia dan Kerja
8.2.1 Contoh
Misal ada 4 orang SE, masing-masing mampu
menghasilkan 5000 LOC/th bila bekerja sendiri-
sendiri dalam proyek individual.
Bila ke-4 SE tersebut ditempatkan pada
sebuah tim untuk proyek (mis 1
tahun) terdapat 6 jalur komunikasi.
Masing-masing jalur komunikasi tsb butuh waktu
yang harus disisihkan dari waktu membuat PL.
Krn overhead yang berkaitan dgn komunikasi untuk
masing-masing jalur komunikasi diasumsikan produktivitas
tim perjalur berkurang dengan 250 LOC/th.
Produktivitas tim menjadi :
4*5000 – 6*250 = 18.500 LOC/th
atau berkurang
(1500/2000) x 100% = 7,5%
dari yang diharapkan shg dpt menyebabkan
proyek terlambat.
Misal bila 2 bln sebelum penyerahan, ditambahkan lagi 2
SE shg jumlah jalur menjadi 14. Diasumsikan per SE
tambahan: 840 LOC / 2 bln shg produktivitas tim
menjadi :
4*5000 + 2*840 – 14*250 = 18.180 LOC/th (vs 18.500).
Suatu hubungan empirik yang menyatakan jumlah LOC (L)
dengan effort (E) dan waktu pengembangan (t), adalah;
L = P x (E/B)1/3 t4/3
dengan P adalah parameter produktivitas (antara 2000
sampai 28.000), B adalah faktor keahlian khusus (antara
0,16 sampai 0,39; lih 6.5.2.3). Bila persamaan tersebut
ditata lagi akan diperoleh :
E = L3/(P3t4)

Misal sebuah proyek PL real time membutuhkan usaha

33.000 LOC dan 12 person-year. Bila 8 orang ditugaskan
dalam tim, maka proyek akan terselesaikan kira-kira dalam
1,3 tahun. Tetapi jika waktu penyelesaian diulur 6 bln lagi
(diselesaikan dalam 1,75 tahun) dengan rumus di atas
diperoleh E = 3,8 person-year, artinya tenaga kerja dapat
dikurangi hingga 4 orang saja. Mana yg menguntungkan?
8.2.2 Distribusi Effort
Distribusi beban kerja yang dianjurkan dalam phase-phase
definisi & pengembangan adalah 40 - 20 - 40; 40% atau
lebih beban kerja dialokasikan untuk tugas-tugas front-end
(analisis & design); 40% dipakai dalam back-end testing
dan 20% untuk coding.
Distribusi effort tergantung pada karakteristik proyek. Effort
yang dihabiskan dalam perencanaan proyek jarang
mencapai lebih dari 2% atau 3%.

Analisis persyaratan-persyaratan dapat menghabiskan 10%

sampai 25% effort. Sedangkan effort yang dihabiskan
dalam analisis atau pembuatan prototype tergantung pada
ukuran dan kompleksitas proyek; 20% s/d 25% biasanya
dihabiskan untuk perancangan PL.
Karena beban kerja juga diberikan dalam software
design, kesulitan-kesulitan yang akan dihadapi
dalam coding juga akan berkurang; kisaran antara
15% s/d 20% dari effort keseluruhan dapat dicapai.

Testing dilanjutkan dengan debugging dapat

mencapai 30% s/d 40%. Kekritisan PL sering
dipengaruhi oleh jumlah testing yang diperlukan.
Untuk PL yang human-rated persentasenya bahkan
lebih tinggi.
8.3. Penentuan Rangkaian Tugas
Proyek PL
8.3.1 Rangkaian Tugas (Task Set)
Sejumlah model proses: linier sequensial,
iterative, evolutionary, dsb, penuh dengan
sekumpulan task yang memungkinkan tim PL
menentukan, mengembangkan, dan pada
akhirnya memelihara PL komputer.
Tidak ada satu set tunggal yang cocok untuk
semua proyek. Oleh karena itu proses PL yang
efektif harus menentukan sekumpulan task set,
masing-masing dirancang untuk memenuhi
kebutuhan-kebutuhan tipe proyek yang berbeda.
Task set adalah sekumpulan task-task pekerjaan
rekayasa PL, milestones, dan deliverables yang
harus dipenuhi untuk menyelesaikan proyek.

Task set yang dipilih harus memberikan disiplin

yang cukup untuk mencapai kualitas PL yang
tinggi, tetapi harus tidak membebani tim proyek
dengan kerja yang tidak perlu.

Task set dirancang untuk mengakomodasi

berbagai tipe proyek dan tingkat kesulitan (degree
of rigor) yang berbeda.
8.3.2 Beberapa Tipe Proyek
• Proyek-proyek pengembangan konsep.

• Proyek-proyek pengembangan aplikasi baru.

• Proyek-proyek peningkatan kemampuan aplikasi

yang sudah ada.
• Proyek-proyek perawatan aplikasi.

• Proyek-proyek reengineering.
8.3.3 Tingkat Kesulitan
Degree of rigor (tingkat kesulitan) adalah suatu
fungsi dari berbagai karakteristik proyek.
Terdapat 4 degree of
rigor. o casual,
o structured,
o strict,
o quick reaction.
Manajer proyek harus mengembangkan suatu cara yang
sistematis untuk pemilihan degree of rigor yang sesuai
untuk suatu proyek.
Untuk memenuhi hal tersebut, kriteria adaptasi
proyek didefinisikan dan nilai task set selector
dihitung, sbb.
8.3.4 Penentuan Kriteria Adaptasi
Kriteria adaptasi dipakai untuk menentukan degree of rigor
bagi proses PL yang akan dipakai pada proyek.
Sebelas kriteria adaptasi (grade 1-5) untuk proyek PL:
• ukuran proyek,
• jumlah user,
• kekritisan misi yang diemban,
• umur (lamanya) aplikasi tersebut akan dipakai,
• kestabilan dalam persyaratan,
• kemudahan komunikasi customer/developer,
• kemapanan (maturity) teknologi yang dipakai,
• kendala-kendala pada kinerja,
• karakteristik embedded/nonembedded,
• project staffing, dan
• reengineering factors.
Masing-masing kriteria adaptasi diberi grade
antara 1 s/d 5. Grade1 merepresentasikan suatu
proyek yang membutuhkan subset yang kecil pada
task-task proses dan persyaratan-persyaratan
metodologi dan dokumentasi adalah minimal.

Grade 5 merepresentasikan suatu proyek yang

memiliki satu set task-task proses lengkap yang
harus dipergunakan, seluruh persyaratan-
persyaratan metode, dan dokumentasinya
substansial.
5. Penghitungan Nilai Task Set Selector(TSS)
Memilih task set yang sesuai untuk sebuah proyek
dengan langkah-langkah berikut.
• Periksa masing-masing kriteria adaptasi dan beri
grade yang sesuai berdasarkan karakteristik
proyek.
• Periksa faktor bobot (nilai berkisar antara 0.8 s/d
1.2) yang diberikan pada masing-masing
kriteria. Faktor bobot menunjukkan tingkat
pentingnya (relatif) dari kriteria adaptasi tertentu
pada tipe PL yang dibuat terhadap lingkungan
lokal.
• Kalikan grade dengan faktor bobot dan dengan
entry point multiplier (bernilai 0 atau 1; yang
menunjukkan relevansi kriteria adaptasi dengan
tipe proyek) untuk tipe proyek yang sedang
dikerjakan.

Grade * weighting_factor * entry_point_multiplier

• Hitung task set selector dengan mengambil nilai

rata-rata dari product. Lihat tabel berikut.
8.3.6 Contoh Perhitungan TSS
Adaptation Criteria Grad Weight Entry Point Multiplier Produc
e Conc. NDev. Enhan. Maint. Reeng. t
Size of project 1.20 0 1 1 1 1
Number of users 1.10 0 1 1 1 1
Business criticality 1.10 0 1 1 1 1
Longevity 0.90 0 1 1 0 0
Stability of requirements 1.20 0 1 1 1 1
Ease of communication 0.90 1 1 1 1 1
Maturity of technology 0.90 1 1 0 0 1
Performance constraints 0.80 0 1 1 0 1
Embedded/nonembedded 1.20 1 1 1 0 1
Project staffing 1.00 1 1 1 1 1
Interoperability 1.10 0 1 1 1 1
Reengineering factors 1.20 0 0 0 0 1

Task set selector (TSS)

Ta s k S et Selector Va l u e Degree of Rigor

T S S < 1.2 casual
1.0 < T S S < 3.0 st ruct u re d
T S S > 2.4 strict
8.3.7 Contoh Perhitungan TSS untuk Proyek
Pengembangan Aplikasi Baru

Adaptation Grad Weig Entry Point Produc

Criteria e ht Conc. Multiplier
NDev. Enhan. Maint. Reeng. t
Size of project 2 1.20 1 2.4

Number of users 3 1.10 1 3.3

Business criticality 4 1.10 1 4.4

Longevity 3 0.90 1 2.7

Stability of requirements 2 1.20 1 2.4

Ease of communication 2 0.90 1 1.8

Maturity of technology 2 0.90 1 1.8

Performance constraints 3 0.80 1 2.4

Embedded/nonembedded 3 1.20 1 3.6

Project staffing 2 1.00 1 2.0

8.3.8 Memilih Task-task Rekayasa PL
Untuk membuat jadwal proyek, task set harus
didistribusikan pada garis waktu proyek.
Task set tergantung pada tipe proyek dan degree
of rigor.
Masing-masing tipe proyek dapat didekati dengan
menggunakan model proses (linier sekuensial, iterative,
atau evolutionary).
Dalam beberapa hal, suatu tipe proyek dapat beralih,
secara perlahan, menuju tipe proyek lainnya (sebagai
contoh, proyek pengembangan konsep baru dapat
dilanjutkan menjadi proyek pengembangan aplikasi
baru, dst).
9.Contoh task-task utama rekayasa perangkat lunak
untuk pengembangan konsep adalah;
• concept scoping,
• preliminary concept planning,
• technology risk assessment,
• proof of concept,
• concept implementation,
• customer reaction to concept.

Sifat dasar dari task-task pengembangan konsep

adalah
iterative.
Bila model proses linier yang dipilih, maka dapat dilihat
gambar berikut.
 Project Engineering/ Customer
Planning Release
Definition
Construction Evaluation
Concept development

1.1 Concept scoping 1.4 Proof of concept 1.6 Customer reaction

1.2 Preliminary concept planning 1.5 Concept implementation

1.3 Technology risk assessment

New Application
Development Projects

Application
Enhancement Projects

Application
Maintenance

Reengineering
 Preliminary concept
planning Technology risk
assessment
Plannin
g

Project
Definitio Engineerin
n g/
Concept scoping Constructi
on Proof of concept

Customer reaction

Releas
Customer e
Evaluati
Concept implementation
on
8.4 Rincian Task-task Utama
Task-task utama dapat dipakai untuk menentukan
jadwal makroskopik bagi suatu proyek.
Jadwal makroskopik tersebut harus dirinci lagi untuk
menghasilkan jadwal proyek terinci.
Rincian tersebut dapat dimulai dengan
mendekomposisi task-task utama ke dalam set-set
subtask.
Contoh task refinement untuk proyek pengembangan
konsep: concept scoping task, dengan
menggunakan process design language.
Tugas I.1 Penentuan Ruang Lingkup Konsep
1. Mengindentifikasi kebutuhan, keuntungan,
dan pelanggan potensial
2. Menentukan kejadian output/kontrol dan input
yang
diharapkan, yang mengendalikan aplikasi
Memulai Tugas I.1.2
1. Mengkaji deskripsi kebutuhan yang
ditulis
2. Memperoleh daftar output/input yang
tampak pada dokumen
dst ..........
8.5 Penentuan Task Network
Task-task dan subtask-subtask mempunyai saling
ketergantungan berdasarkan pada urutan
pengerjaannya.
Selain itu bila lebih dari satu orang bekerja pada
proyek tersebut, ada kemungkinan task-task
dikerjakan secara paralel, task konkuren ini harus
dikoordinasikan.
Task network adalah representasi grafis dari aliran
task untuk suatu proyek.
 Contoh Task Network

I.3a I.5a
Tech. Rsik Concept
Asses Impl
sment eme
nt
I.6
I.1 I.2 I.3b I.4 I.5b Integr
Custo
Concep Concept Tech. Rsik Proof of Conce ate
mer
t pt a,b,
Reacto
i
scopn ig pa
l nnn
ig Assessment Concept Implem c
n
ent

I.3c I.5c
Tech. Rsik Conce
pt
Assessment Implem
8.6 Penjadwalan
Penjadwalan proyek PL tidak berbeda dengan
penjadwalan multitask engineering effort lainnya.

Tool-tool & teknik-teknik umum untuk penjadwalan

proyek dapat dipakai untuk proyek PL dengan
sedikit modifikasi.

Program Evaluation and Review Technique

(PERT) dan Critical Path Method (CPM) adalah
dua metoda penjadwalan proyek yang dapat
dipakai pada proyek pengembangan PL.
 Work tasks week 1 week 2 week 3 week 4 week 5
1.1.1 Identify need and benefits
Meet with customers
Identify needs and project constraints
Establish product statement
Milestone: product statement defined
Tracking the Schedule
Tracking dapat dipenuhi dengan sejumlah cara yang
berbeda.
• Adakan pertemuan berkala untuk membahas status
proyek; setiap anggota tim melaporkan kemajuan dan
masalah-masalah yang dihadapi.
• Evaluasi hasil semua review yang dilakukan
selama
proses rekayasa PL.
• Tentukan apakah formal project milestone telah
dipenuhi sesuai dengan tanggal yang telah terjadwal?
• Bandingkan waktu mulai sebenarnya dengan waktu
mulai terjadwal untuk masing-masing proyek task.
• Pertemuan informal dengan para praktisi untuk
mendapatkan penilaian subyektifnya atas kemajuan
8.7 Project Plan
Setiap langkah dalam proses rekayasa PL harus
menghasilkan suatu hasil kerja yang dapat
diperiksa dan dapat bertindak sebagai dasar untuk
langkah berikutnya.
Software project plan dihasilkan di akhir dari
planning tasks.
Dia memberikan informasi tentang cost dan
jadwal yang akan dipakai selama proses rekayasa
PL.
Project Planning Content
I. Pendahuluan
A. Tujuan Rencana
B. Ruang Lingkup dan Tujuan Proyek
1. Pernyataan Ruang Lingkup
2. Fungsi-Fungsi Utama
3. Isu-isu Kinerja
4. Batasan Manajemen dan Teknis
II. Estimasi Proyek
A. Data Historis yang Digunakan untuk Estimasi
B. Teknik-teknik Estimasi
C. Estimasi Usaha, Biaya, Durasi
III. Strategi Manajemen Risiko
A. Tabel Risiko
B. Pembahasan Risiko untuk Dikelola
C. Rencana RMMM untuk setiap Risiko
IV. Jadwal
V. Sumber Daya Proyek
VI. Staf Organisasi
VII. Pelacakan dan Mekanisme Kontrol
VIII. Lampiran
***
 9. Software Quality
Assurance
1. Ruang Lingkup
2. Konsep Kualitas
1. Kualitas
2. Kontrol Kualitas
3. Jaminan Kualitas
4. Biaya Kualitas
3. Aktivitas SQA
4. Kajian Perangkat Lunak (Software Review)
5. Dampak Defects Software thd. Biaya
6. Kajian Teknik Formal (Formal Technical Review)
7. Review
1. Review Meeting
2. Laporan Review
3. Pedoman Review
8. Reliabilitas Perangkat Lunak
1. Reliabilitas (kehandalan)
2. Pengukuran Reliabilitas & Availabilitas
9. Software Safety & Hazard Analysis
10. Rencana SQA
 9.1 Ruang Lingkup
 Tujuan utama dari rekayasa perangkat lunak adalah
menghasilkan perangkat lunak yang berkualitas tinggi
 Jaminan kualitas perangkat lunak adalah aktivitas
pelindung yang diaplikasikan pada seluruh proses
perangkat lunak, yang meliputi:
 pendekatan manajemen kualitas
 teknologi rekayasa perangkat lunak yang efektif (metode)
 kajianteknik formal yang diaplikasikan pada keseluruhan
proses perangkat lunak
 strategi pengujian multitiered
 kontrol dokumentasi perangkat lunak dan perubahan yang
dibuat untuknya
 proseduruntuk menjamin kesesuaian dengan standar pengem-
bangan perangkat lunak
 mekanisme pengukuran dan pelaporan
9.2 Konsep Kualitas
9.2.1 Kualitas
 Kualitas (menurut American Heritage Dictionary) adalah
sebuah karakteristik atau atribut dari sesuatu yang dapat
diukur, dibandingkan dengan standar yang diketahui.
 Berdasarkan pada sifat pengkurannya, ada dua jenis kualitas
yang ada, yaitu kualitas desain dan kualitas konformansi.

1. Kualitas desain mengacu pada karakteristik tertentu yang

ditentukan oleh desainer terhadap item tertentu. Desain berkualitas
bila produk yang dihasilkan sesuai dengan spesifikasi yang
ditentukan. Kualitas desain mencakup syarat, spesifikasi dan desain
sistem.
2. Kualitas konformansi adalah tingkat spesifikasi desain yang
terus diikuti selama pembuatan. Semakin tinggi tingkat
konformansi, semakin tinggi tingkat kualitas konformasi.
Kualitas konformansi difokuskan pada implementasi, jika
implementasi mengikuti desain, dan sistem yang dihasilkan
memenuhi persyaratan dan kinerja, maka kualitas konformasi
9.2.2 Kontrol Kualitas

 Kontrol kualitas merupakan serangkaian

pemeriksaan, kajian, dan pengujian yang
digunakan pada keseluruhan siklus
pengembangan untuk memastikan bahwa
setiap produk memenuhi persyaratan yang
ditetapkan.
 Kontrol kualitas mencakup loop (kalang)
umpan balik pada proses yang menciptakan
produk kerja dengan membandingkan output
dari setiap proses dengan spesifikasi yang
telah ditetapkan.
9.2.3 Jaminan Kualitas
 Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen.

 Tujuan jaminan kualitas adalah untuk memberikan data yang diperlukan

oleh manajemen untuk menginformasikan masalah kualitas produk,
sehingga dapat memberikan kepastian dan konfidensi bahwa kualitas
produk dapat memenuhi sasaran.
9.2.4 Biaya Kualitas
 Biaya kualitas menyangkut semua biaya yang diadakan untuk menampilkan kualitas yang
berhubungan dengan aktivitas.
 Biaya kualitas dapat dibagi ke dalam biaya yang dihubungkan dengan pencegahan, penilaian,
dan kegagalan.

 Biaya pencegahan meliputi

 perencanaan kualitas
 kajian teknis formal (FTR)
 perlengkapan pengujian
 pelatihan
 Biaya penilaian meliputi
 inspeksi dalam suatu proses dan
interproses
 pemeliharaan dan kalibrasi
peralatan
 pengujian
 Biaya kegagalan meliputi
Internal (sebelum penyerahan produk)
 pengerjaan kembali
 perbaikan
 analisis mode kegagalan
Eksternal (setelah penyerahan produk)
 resolusi keluhan
 penggantian dan pengembalian
produk
9.3 Aktivitas
SQA
 Jaminan kualitas perangkat lunak terdiri dari berbagai tugas
yang berhubungan dengan dua konstituen yang berbeda:
 perekayasa perangkat lunak yang mengerjakan kerja teknis
 kelompok SQA yang bertanggungjawab terhadap perencanaan
jaminan kualitas, kesalahan, penyimpanan rekaman, analisis,
dan pelaporan
 Aktivitas oleh kelompok SQA:
 menyiapkan rencana SQA untuk suatu proyek;
 berpartisipasi dalam deskripsi proses pengembangan proyek;

 mengkaji aktivitas perangkat lunak untuk memverifikasi

pemenuhan proses perangkat lunak yang sudah ditentukan;
 meng-audit produk kerja perangkat lunak yang ditentukan untuk
membuktikan kesesuaian dengan produk kerja yang ditentukan
tersebut sebagai bagian dari proses perangkat lunak;
 memastikan bahwa deviasi pada kerja dan produk kerja perangkat
lunak didokumentasi dan ditangani sesuai prosedur
pendokumentasian;
e
 mencatat ketidakssesuaian dan melaporkannya kepada manajem n
9.4 Kajian Perangkat Lunak (Software
Review)
 Software reviews adalah sebuah filter untuk
proses rekayasa perangkat lunak.
 Reviews dilaksanakan di berbagai titik selama
pengembangan perangkat lunak dan membantu
menemukan error yang kemudian dapat
dihilangkan.
 Software reviews membantu untuk memurnikan
produk kerja perangkat lunak yang terjadi
sebagai suatu hasil dari analisis, desain, dan
coding.
 FTR (Formal Technical Review) atau disebut
walkthrough adalah filter yang paling efektif
untuk meningkatkan kualitas PL.
9.5 Dampak Defects Software thd. Biaya

 Dalam kontek proses PL, istilah defect dan fault adalah sinonim.
Keduanya menyatakan secara tidak langsung suatu problem kualitas
yang ditemukan setelah PL dirilis kepada end users.
 Sasaran utama dari FTR adalah menemukan errors selagi proses
PL berjalan sehingga tidak menjadi defect setelah PL dirilis.
 Keuntungan sesungguhnya dari FTR adalah menemukan error
sedini mungkin sehingga error tsb tidak menjalar ke langkah
berikutnya dalam proses PL.
 Sejumlah studi menunjukkan bahwa kegiatan desain mengintrodusir
error antara 50% dan 65% dari seluruh error (dan pada akhirnya,
seluruh defect) selama proses PL.
 FTR telah menunjukkan bahwa sampai 75% efektif dalam
menemukan cacat-cacat desain.
 Dengan mendeteksi dan menghapus sejumlah besar persentase error,
proses review secara subtansial mengurangi biaya pada langkah-
langkah selanjutnya dalam phase-phase pengembangan dan
maintenance.
9.6 Kajian Teknik Formal
(Formal Technical
Review)
 FTR adalah aktivitas jaminan kualitas perangkat
lunak yang dilakukan oleh perekayasa perangkat
lunak.
 Tujuan FTR adalah:
 menemukan error dalam fungsi, logika, atau
implementasinya dalam berbagai representasi
perangkat lunak;
 memverifikasi bahwa perangkat lunak yang direview
memenuhi syarat;
 memastikan bahwa perangkat lunak tersebut telah
direpresentasikan sesuai dengan standard yang telah
ditentukan sebelumnya;
 untuk mencapai perangkat lunak yang dikembangkan
dengan cara yang seragam;
 membuat proyek lebih mudah dikelola.
9.7 Review
9.7.1 Review Meeting
 Review meeting (pertemuan kajian) adalah
pertemuan tim review produk kerja perangkat lunak
yang terdiri dari 3 sampai 5 orang guna mengkaji dan
mengevaluasi perangkat lunak yang telah dihasilkan.
 Diakhir review, tim harus memutuskan apakah:
 menerima hasil kerja tersebut tanpa modifikasi lebih
lanjut.
 menolak hasil kerja tersebut karena adanya kesalahan
yang fatal, atau
 menerima hasil kerja tersebut secara sementara
(error2 kecil telah ditemukan dan harus dikoreksi;
tetapi tidak perlu direview lagi).
9.7.2 Laporan Review
 Ada 2 dokumen yg dihasilkan dalam review meeting
yaitu daftar masalah review (review issues list) dan
laporan rangkuman review (review summary report).
 Review summary report memuat jawab dari 3
pertanyaan berikut:
(1) apa yg telah direview,
(2) siapa yg telah mereviewnya, dan
(3) apa yang telah ditemukan & apa
kesimpulannya.
 Review issues list berisi hal2 yang berguna
dlm:
(4) mengidentifikasi area problem, dan
(5) bertindak sebagai action item checklist
9.7.3 Pedoman Review

 Review produk, bukan produser

 Menetapkan agenda dan tetap menjaganya
 Membatasi perdebatan dan bantahan
 Menetapkan area masalah, tetapi tidak mencoba untuk
menyelesaikan setiap masalah yang dicatat
 Buat catatan tertulis
 Membatasi jumlah peserta dan lakukan persiapan
awal
 Buat sebuah daftar utk setiap work product yang
direview.
 Alokasikan sumber-sumber daya dan jadwal waktu
untuk FTR.
9.8 Reliabilitas Perangkat Lunak
9.8.1 Reliabilitas (kehandalan)
 Reliabilitas perangkat lunak didefinisikan
sebagai probabilitas operasi komputer bebas
kegagalan dalam suatu lingkungan tertentu
dan waktu tertentu. Misal suatu PL memiliki
reliabilitas 0,96 pada 8 jam eksekusi,
berarti apabila PL tsb dieksekusi 100 kali
selama 8 jam dia akan beroperasi dg benar
96 kali.

 Kehandalan perangkat lunak dapat diukur,

diarahkan, dan diestimasi dengan
menggunakan data pengembangan historis.
9.8.2 Pengukuran Reliabilitas & Availabilitas

 Dalam kenyataannya, semua kegagalan

perangkat lunak dapat dilacak dari problem-
problem desain atau implementasi.
 Untuk sebuah sistem berbasis komputer,
pengukuran sederhana kehandalan adalah
berupa Mean Time Between Failure (MTBF),
MTBF = MTTF + MTTR
(MTTF : mean time to failure dan
MTTR : mean time to repair)
 Software availability adalah
probabilitas
bahwa sebuah program
beroperasi
berdasarkan persyaratannya
Availability = {MTTF/(MTTF + MTTR)} x 100%
9.9 Software Safety & Hazard
Analysis  Keamanan perangkat lunak dan analisis risiko
adalah aktivitas SQA yang memfokuskan pada
identifikasi & penilaian hazard (risiko)
potensial yang mungkin berpengaruh negatif
terhadap perangkat lunak dan
menyebabkan seluruh sistem menjadi gagal
(fail).
 Bilarisiko dapat diidentifikasi pada awal
proses rekayasa perangkat lunak, maka ciri-
ciri desain perangkat lunak dapat ditetapkan
9.10 Rencana SQA
 SQA plan adalah peta jalan untuk membangun
jaminan kualitas perangkat lunak. SQA plan
berfungsi sebagai template bagi aktivitas SQA
yang dibangun untuk setiap proyek perangkat
lunak.
 Rencana SQA dicatat dalam dokumen produk
kerja yang mencakup: dokumen proyek
(rencana proyek); model (ERD); dokumen
teknis (spesifikasi, rencana pengujian);
dokumen pemakai (file-file help).

***
10. SOFTWARE CONFIGURATION MANAGEMENT
1. Pendahuluan
1. Perubahan
2. Tujuan SCM
3. Software Maintenance vs Software Configuration
Management
4. Informasi dan Perubahan
2. Software Configuration Management
1. Sumber Dasar Perubahan
2. Baseline
3. SCI Baseline dan Database Proyek
10.3 Software Configuration Item (SCI)
4. SCM Process
1. Tanggung Jawab SCM
2. Pertanyaan Seputar SCM
3. Tugas SCM
5. Identifikasi Objek dalam SC
1. Tipe Objek
2. Keunikan Objek
3. Hubungan Antar-Objek
4. Evolusi Objek
6. Kontrol Versi (Version Control)
1. Versi PL
2. Komponen
3. Varian
4. Hub Objek Konfigurasi, Komponen, Varian, dan Versi
7. Kontrol Perubahan
1. Proses Kontrol Perubahan
2. Kontrol Akses & Sinkronisasi
8. Audit Konfigurasi
1. Proses Audit Konfigurasi
2. Pertanyaan dalam Proses Audit Konfigurasi
3. Pelaporan Status Konfigurasi (Status Accounting)
10.9 Software Configuration Management (SCM) Standards
10.1.
Pendahuluan
10.1.1 Perubahan
 Perubahan adalah hal yang tidak dapat dihindarkan ketika
perangkat lunak komputer sedang dibuat.
 Perubahan2 tersebut meningkatkan tingkat kebingungan
di antara para software engineer yang berkerja pada
proyek tersebut.
 Kebingungan muncul bila perubahan2 tersebut tidak
dianalisis sebelum perubahan tersebut dilaksanakan;
dicatat sebelum diimplementasi, dilaporkan kepada yang
ingin mengetahui, atau dikontrol dengan suatu cara
yang akan meningkatkan kualitas & mengurangi error.
 Software configuration management (SCM) adalah
kegiatan payung (umbrella activities) yang dilaksanakan
selama proses perangkat lunak.
10.1.2 Tujuan
SCM
 Karena perubahan dapat terjadi kapan saja, maka
kegiatan SCM dibuat untuk;
1) mengidentifikasi perubahan,
2) mengontrol perubahan,
3) mengimplementasikan perubahan dengan benar,
dan
4) melaporkan perubahan kepada pihak-pihak yang
mempunyai kepentingan.
10.1.3 Software Maintenance vs Software Configuration
Management
 Penting untuk dibedakan dengan jelas antara
software maintenance dan software configuration
management.
 Software Maintenance adalah serangkaian aktivitas
rekayasa perangkat lunak yang terjadi setelah
perangkat lunak diserahkan ke pelanggan dan telah
dioperasikan.
 Software configuration management adalah
serangkaian kegiatan tracking & control yang dimulai
ketika suatu proyek perangkat lunak dimulai dan
berakhir ketika perangkat lunak sudah tidak
beroperasi lagi.
10.1.4 Informasi dan
Perubahan
 Keluaran dari proses perangkat lunak adalah informasi yang
dapat dibagi ke dalam 3 kategori utama;
1) program komputer (baik dalam bentuk source code
maupun executable),
2) dokumen2 yang menjelaskan program komputer tersebut
(yang ditargetkan baik untuk technical practitioners
maupun users), dan
3) data (yang diisikan dalam program atau dikeluarkan dari
program).
 Item2 yang terdiri dari semua informasi yang dihasilkan
sebagai bagian dari proses perangkat lunak secara kolektif
disebut Software Configuration Items (SCI).
 Selama proses - rekayasa SCI berkembang dengan pesat.
System specification menghasilkan sebuah software project
plan dan software requirements specification (juga dokumen2
yang terkait dengan hardware), yang secara berurutan akan
menghasilkan dokumen2 untuk menciptakan suatu hirarki
informasi.
 Perubahan masuk ke dalam proses rekayasa. Perubahan
dapat terjadi kapan saja, untuk suatu alasan. Ini sesuai dengan
Hukum 1 system engineering [BER80] yang menyatakan:
“Tidak masalah dimana anda berada dalam siklus kehidupan
sistem, sistem akan berubah, dan keinginan untuk
mengubahnya akan selalu ada selama siklus hidup tersebut”.
10.2. Software Configuration
Management
10.2.1 Sumber Dasar Perubahan
 Terdapat 4 sumber dasar perubahan.
 Bisnis baru atau kondisi pasar yang mendiktekan perubahan2 dalam
produk atau aturan2 bisnis.
 Keinginan pelanggan baru yang meminta modifikasi data yang
dihasilkan oleh sistem informasi; fungsionalitas yang diberikan oleh
produk, atau layanan yang diberikan oleh suatu sistem berbasis
komputer.
 Reorganisasi dan/atau perampingan bisnis yang menyebabkan perubahan
prioritas proyek atau struktur tim rekayasa perangkat lunak.
 Kendala2 anggaran atau jadwal yang menyebabkan redefinisi sistem atau
produk.
 SCM adalah sekumpulan kegiatan yang telah dikembangkan
untuk menangani perubahan2 selama siklus hidup dari perangkat
lunak komputer.
 SCM dapat dipandang sebagai kegiatan SQA yang dipakai
selama proses perangkat lunak.
10.2.2
Baseline
 Perubahan adalah kenyataan hidup dalam pengembangan perangkat
lunak. Pelanggan ingin memodifikasi persyaratan2. Pengembang
ingin memodifikasi metode2 teknis. Manager ingin memodifikasi cara
pendekatan proyek.
 Baseline adalah sebuah konsep SCM yang membantu dalam kontrol
perubahan2 tanpa secara serius menghalangi perubahan2 yang dapat
dijustifikasi.
 IEEE mendifinisikan baseline sebagai:
Suatu spesifikasi atau produk yang telah direview secara formal
dan disetujui bersama, yang selanjutnya berfungsi sebagai dasar
bagi pengembangan lebih lanjut, serta dapat diubah hanya melalui
prosedur2 kontrol perubahan formal.
 Dalam konteks rekayasa perangkat lunak, baseline adalah milestone
dalam rekayasa perangkat lunak yang ditandai dengan penyampaian
(delivery) SCI dan persetujuan (approval) SCI tersebut yang
diperoleh lewat suatu FTR.
Baseline

system engineering
System Specification

requirements analysis

Software Requirements Specification

software design

Design Specification

coding

Source Code

testing

Test Plans/Procedures/Data

release

Operational System
10.2.3 SCI Baseline dan Database
Proyek
modified
Project
SCIs database

approved
Software Formal
engineering SCIs technical SCIs
tasks reviews
stored

SCIs

Perlu
extracted
modifikasi?
SCM
controls
SCIs
Jalur modifikasi
10.3 Software Configuration Item
(SCI)
 SCI merupakan informasi yang diciptakan sebagai bagian dari
proses rekayasa perangkat lunak.
 SCI berikut menjadi target bagi teknik2 CM dan membentuk
sekumpulan baseline.
1. System Specification
2. Software Project Plan
3. Software Requirement Specification
a. Graphical analysis model
b. Process specifications
c. Prototype(s)
d. Mathematical specification
4. Preliminary User Manual
5. Design Specification
a. Data design description
b. Architectural design description
c. Modul design descriptions
d. Interface design descriptions
e. Object description
Software Configuration Item (lanj)
6. Source Code Listing
7. Test Specification
a. Test plan & procedure
b. Test cases & recorded results
8. Operation & Installation Manuals
9. Executable Program
a. Module executable code
b. Linked modules
10. Database Description
a. Schema & file structure
b. Initial content
11. As-built User Manual
12. Maintenance
Documents
a. Software problem
reports
b. Maintenance requests
c. Engineering change
orders
10.4. SCM
Process
10.4.1 Tanggung Jawab SCM
SCM adalah sebuah elemen penting dari SQA
 Tanggung jawab utamanya adalah mengontrol
perubahan.
 SCM juga bertanggung jawab untuk :
 mengidentifikasi individual SCI & berbagai versi
perangkat lunak,
 meng-audit software configuration untuk
memastikan
bahwa dia telah dikembangkan dengan
benar, dan
 melaporkan semua perubahan yang telah dilakukan
pada konfigurasi tersebut.
 10.4.2 Pertanyaan Seputar
SCM
 Diskusi mengenai SCM memperkenalkan sekumpulan pertanyaan
kompleks sebagai berikut.
 Bagaimana suatu organisasi mengidentifikasi dan menangani
berbagai versi yang ada dari sebuah program (dan
dokumentasinya) dalam suatu cara yang akan
memungkinkan perubahan ditampung secara efisien?
 Bagaimana suatu organisasi mengontrol perubahan sebelum
dan setelah perangkat lunak dirilis ke pelanggan?
 Siapa yang mempunyai tanggung jawab (otoritas)
untuk approving (menyetujui) & prioritizing
(memprioritaskan) perubahan?
 Bagaimana kita yakin bahwa perubahan2 tersebut telah dilakukan
dengan benar?
 Mekanisme apa yang dipakai untuk memberitahu yang lain
bahwa perubahan telah dilakukan?
 10.4.3 Tugas
SCM
 Pertanyaan2 tersebut membawa kepada definisi 5 tugas
(task) SCM :
 identifikasi,
 kontrol versi,
 kontrol perubahan,
 auditing konfigurasi, dan
 pelaporan.
10.5 Identifikasi Objek dalam
SC
10.5.1 Tipe Objek
 Untuk mengontrol & menangani SCI2, masing2 item harus
diberi nama berbeda dan kemudian diorganisir dengan
menggunakan metode berorientasi objek.
 Dua tipe objek dapat diidentifikasi: basic objects (obyek
dasar) & aggregate objects (kumpulan obyek).
 Sebuah basic object adalah sebuah “unit of text” yang
telah diciptakan oleh seorang software engineer
pada saat (selama) analisis, design, coding, atau
testing.
 Sebuah aggregate object adalah sekumpulan basic object
dan aggregate objects lainnya.
10.5.2 Keunikan
Objek
Setiap object mempunyai sekumpulan fitur yang berbeda
yang mengidentifikasikannya secara unik;
 sebuah nama (object name),
 suatu deskripsi (object description),
 suatu daftar sumber daya (resources list) dan
 suatu realisasi (realization)
10.5.2 Keunikan Objek
(lanj)
 Object name adalah sebuah string karakter yang
mengidentifikasi object secara tidak samar.
 Object description adalah sebuah list item2 data yang
mengidentifikasi:
 tipe SCI (misal dokumen, program, data) yang
direpresentasikan oleh object;
 suatu project identifier; dan informasi perubahan
dan/atau versi.
 Resources adalah entitas yang disediakan,
diproses,
diacu atau sebaliknya diperlukan oleh object.
 Realisasi adalah sebuah pointer pada “unit of text” untuk
suatu basic object dan null untuk suatu aggregate object.
10.5.3 Hubungan Antar-
Objek
 Configuration object identification juga harus
mempertimbangkan hubungan yang ada antara “named
objects”
 Sebuah object dapat diidentifikasi sebagai <part-of> suatu
aggregate
object.
 Hubungan <part-of> menentukan sebuah hirarki object2.
 Hubungan di antara object2 dalam suatu hirarki objek tidak hanya
sepanjang direct path dari hirarchical tree, tetapi dalam beberapa
hal, object2 diinterrelasikan melewati cabang2 dari object hirarchy.
 Interrelationships antara configuration objects dapat
direpresentasikan dengan sebuah module interconection
language (MIL).
 MIL menggambarkan interdependencies di antara configuration
objects dan memungkinkan suatu versi dari suatu sistem
dikonstruksi secara otomatis.
Gambar : Configuration Objects

Data Model

Design specification

data design
architectural design
module design
interface design

Module N

interface description
algorithm description
PDL

Test specification

test plan
test procedure
Source code
test cases
10.5.4 Evolusi
Objek
 Skema identifikasi untuk objek2 perangkat lunak harus
mengenali bahwa objek2 berevolusi selama proses
perangkat lunak.
 Sebelum suatu objek dijadikan baseline, dia boleh
berubah berkali-kali, dan bahkan setelah suatu baseline
ditetapkan, perubahan2 mungkin cukup sering.
 Dimungkinkan untuk menciptakan sebuah evolution graph
untuk suatu object. Evolution graph menggambarkan
sejarah perubahan dari object (lihat gbr).
 Dimungkinkan juga perubahan2 dapat dilakukan pada
sembarang versi, tetapi tidak perlu pada semua versi.
Grafik
Evolusi
obj obj

1.3 1.4
obj obj obj

1.0 1.1 1.2

obj obj

2.0 2.1

obj obj
1.1.1 1.1.2
10.6 Kontrol Versi (Version
Control)
 Clemm[CLE89] menggambarkan version control dalam
konteks SCM sbb:
Configuration management mengijinkan seorang user
untuk menentukan konfigurasi alternatif dari sistem
software melalui pemilihan versi2 yang sesuai. Hal ini
didukung oleh atribut2 yang terkait dengan masing2 versi
software, dan kemudian juga mengijinkan suatu
konfigurasi ditentukan (dan dikonstruksi) dengan
menggambarkan serangkaian atribut yang diinginkan.
10.6.1 Versi
PL
 Atribut2 yang dikemukakan di atas dapat sesederhana
seperti hanya sebuah nomor versi tertentu yang terkait
pada masing2 objek atau sekompleks seperti suatu string
dari variable boolean (switches) yang menunjukkan tipe
tertentu dari perubahan2 fungsional yang telah dilakukan
pada sistem.
 Salah satu representasi dari versi2 yang berlainan dari
suatu sistem adalah evolution graph (lihat gbr).
 Masing2 node pada graph tersebut adalah sebuah
aggregate object, yaitu satu versi lengkap (utuh) dari
perangkat lunak.
10.6.2
Komponen
 Masing2 versi perangkat lunak adalah sekumpulan SCI
(source code, dokumen2, data) dan setiap versi dapat
terdiri dari variant2 yang berbeda.
 Untuk melukiskan konsep ini, pikirkan sebuah versi dari
sebuah program sederhana yang tersusun dari
komponen2 1, 2, 3, 4, dan 5 (lihat gbr).
 Komponen 4 hanya dipakai bila software
diimplementasikan dengan menggunakan display warna.
Komponen 5 diimplementasikan bila tampilan yang
dipakai monochrome.
 Oleh karena itu, dua variant dari versi tersebut dapat
ditentukan: (1) komponen2 1, 2, 3, dan 4; (2) komponen2
1, 2, 3, dan 5.
Grafik Evolusi Revisi Perangkat Lunak

obj obj

1.3 1.4
obj obj obj

1.0 1.1 1.2

obj obj

2.0 2.1

obj obj
1.1.1 1.1.2
1

2 3
variants

4 5
components
10.6.3
Varian
 Untuk membangun varian yang sesuai dari suatu versi
tertentu dari suatu program, masing2 komponen dapat
diberikan suatu “attribute-tuple”, yaitu sebuah lis dari fitur2
yang akan menentukan suatu komponen tertentu harus
dipakai bila suatu varian tertentu dari suatu versi
perangkat lunak dibuat.
 Satu atau lebih atribut diberikan untuk masing2 varian.
Sebagai contoh, suatu atribut ‘color’ dapat dipakai untuk
menentukan komponen yang harus disertakan bila
color display yang harus didukung.
 Cara lain untuk mengkonseptualisir hubungan antara
komponen, varian2, dan versi2 (revisi2) adalah
merepresentasikannya sebagai “object pool”
variants

components

versions

object
10.6.4 Hub Objek Konfigurasi, Komponen, Varian, dan
Versi
 Hubungan antara configuration object dan komponen2,
varian2, dan versi2 dapat direpresentasikan sebagai
sebuah ruang tiga dimensi.
 Sebuah versi dapat dipilih dari beberapa varian yang ada
(sb vertikal) yang terdiri dari beberapa komponen.
 Sebuah komponen tersusun dari sekumpulan objek2 pada
tingkat level revisi yang sama.
 Sebuah varian adalah sekumpulan objek2 yang berbeda
pada tingkat revisi yang sama, dan oleh karena itu berada
berdampingan secara paralel dengan variant2 lain.
 Sebuah versi baru ditentukan bila perubahan2 besar
(utama) dilakukan pada satu atau lebih object.
10.7 Kontrol
Perubahan
 Untuk proyek pengembangan perangkat lunak yang
besar, perubahan yang tidak terkontrol membawa pada
kekacauan (chaos).
 Change control menggabungkan prosedur manusia dan
tool otomatis guna memberikan sebuah mekanisme untuk
mengontrol perubahan.
 Suatu change request di submit dan dievaluasi untuk
menilai manfaat teknisnya, efek samping yang potensial,
dampak keseluruhan pada configuration objects dan
fungsi2 sistem lainnya.
10.7.1 Proses Kontrol
Perubahan
 Hasil dari evaluasi tersebut dipresentasikan sebagai sebuah Change
Report yang dipakai oleh Change Control Authority (CCA), yaitu
seseorang atau grup yang membuat keputusan akhir terhadap
status dan prioritas dari perubahan tersebut.
 Sebuah Engineering Change Order (ECO) dibuat untuk
setiap perubahan yang telah disetujui.
 ECO menjelaskan perubahan2 yang harus dibuat, kendala2
yang
harus diperhatikan, dan kriteria2 untuk review & audit.
 Objek yang akan diubah di’checked out’ dari basis data
proyek, dilakukan perubahan, dan kegiatan2 SQA yang
bersesuaian dilaksanakan.
 Objek tersebut kemudian di’checked-in’ ke basis data dan
mekanisme version control yang sesuai dipakai untuk menciptakan
versi berikutnya dari perangkat lunak tersebut.
 Proses check-in dan check-out mengimplementasikan dua elemen
penting dari kontrol perubahan, yaitu access control &
10.7.2 Kontrol Akses & Sinkronisasi

 Kontrol akses mengatur perekayasa perangkat lunak yang

mempunyai otoritas untuk mengakses dan memodifikasi suatu
configuration object tertentu (khusus).

 Kontrol sinkronisasi membantu untuk memastikan bahwa

paralel changes yang dilakukan oleh dua orang yang berbeda
tidak saling overwrite satu terhadap lainnya.

 Aliran kontrol akses & sinkronisasi dilukiskan secara skematik

pada gbr berikut.
Change Control

check-in
configuration object
(modified version)
configuration object
(baseline version)

unlock
audit info

ownership
info
software access project
database
engineer control

lock
configuration object
(extracted version) configuration object
(baseline version)

check-out
10.8 Audit
Konfigurasi
 Identifikasi, kontrol versi, dan kontrol perubahan
membantu pengembang perangkat lunak untuk
mempertahankan aturan, bila tidak akan mendatangkan
situasi yang chaotic & fluid.
 Walaupun demikian, bahkan mekanisme kontrol yang
berhasil mentrack perubahan hanya sampai ECO
dibangkitkan.
 Bagaimana kita dapat menjamin bahwa perubahan
tersebut telah diimplementasikan dengan benar?
Jawabnya adalah dua hal: (1) FTR, dan (2) software
configuration audit.
10.8.1 Proses Audit
Konfigurasi
 FTR memusatkan pada ketepatan (correctness) teknis
dari configuration object yang telah dimodifikasi.
 Para reviewer menilai SCI tersebut untuk menentukan
konsistensi terhadap SCI2 lain, penghilangan, dan
potensial side effects. FTR harus dilaksanakan untuk
semua perubahan termasuk yang paling sepele.
 Software configuration audit melengkapi
(menyempurnakan) FTR dengan penilaian suatu
configuration object untuk karakteristik2 yang pada
umumnya tidak dipertimbangkan selama review.
 10.8.2 Pertanyaan dalam Proses Audit
Konfigurasi
 Audit tersebut menanyakan dan menjawab pertanyaan2
berikut:
1. Apakah perubahan yang ditentukan dalam ECO telah
dilakukan? Apakah suatu modifikasi tambahan telah
disertakan?
2. Apakah FTR telah dilakukan untuk menilai ketepatan teknis?
3. Apakah standard2 software engineering telah diikuti dengan
benar?
4. Apakah perubahan tersebut telah ditandai dalam SCI?
Apakah tanggal perubahan dan orang yang membuat
perubahan telah dicatat? Apakah atribut2 configuration object
mencerminkan perubahan tersebut?
5. Apakah prosedur2 SCM untuk pencatatan perubahan, perekaman,
dan pelaporan telah diikuti?
6. Apakah semua SCI yang terkait telah diupdate dengan benar?
10.8.3 Pelaporan Status Konfigurasi (Status
Accounting)
 Setiap kali suatu SCI diberi identifikasi baru atau
diupdate, sebuah Configuration Status Reporting CSR
entry dibuat.
 Setiap kali suatu perubahan disetujui oleh CCA (yaitu,
suatu ECO dikeluarkan), sebuah entry CSR dibuat.
 Setiap kali suatu configuration audit dilakukan, hasil2nya
dilaporkan sebagai bagian dari task CSR.
 Output dari CSR dapat diletakkan dalam basis data on-
line shg pengembang perangkat lunak atau pengelola
(maintainers) dapat mengakses informasi perubahan
dengan keyword category.
 10.9 SCM
Standards
 Beberapa standard SCM awal, seperti MIL-STD-483,
DOD-STD-480A, dan MIL-STD-1521A, memusatkan
pada software yang dikembangkan untuk aplikasi
militer.
 Standar ANSI/IEEE yang lebih baru, seperti
ANSI/IEEE Std. No. 828 - 1983, Std. No. 1042 - 1987,
dan Std. No. 1028 - 1988, dapat dipakai untuk
software komersial dan direkomendasikan baik untuk
organisasi2 rekayasa perangkat lunak besar & kecil.
***
III. METODE
KONVENSIONAL

11. REKAYASA SISTEM BERBASIS KOMPUTER

 11.1 Sistem Berbasis Komputer (Computer-based System)

 Sistem berbasis komputer bertujuan untuk mendukung berbagai

fungsi bisnis atau untuk mengembangkan suatu produk yang
dapat dijual untuk menghasilkan keuntungan bisnis.
 Elemen-elemen sistem berbasis komputer:
1. Perangkat lunak (program komputer, struktur data, dan dokumen
yang berhubungan)
2. Perangkat keras (perangkat elektronik dan elektromekanik)
3. Manusia (user yang memakai perangkat lunak dan perangkat
keras)
4. Basisdata (kumpulan informasi besar dan terorganisir yang
diakses
melalui perangkat lunak)
5. Dokumentasi (manual, formulir, dan informasi deskriptif lainnya)
6. Prosedur (langkah-langkah yang menentukan penggunaan elemen
sistem)
 Rekayasa Perangkat Lunak terjadi sebagai konsekuensi dari
suatu proses yang disebut Rekayasa Sistem Berbasis
Komputer (Rekayasa Sistem)
 Rekayasa Sistem memfokuskan diri pada berbagai elemen,
analisis, desain, dan pengorganisasian elemen-elemen
tersebut ke dalam suatu sistem yang dapat menjadi sebuah
produk, jasa, atau teknologi untuk mentransformasi
informasi atau kontrol. Oleh sebab itu rekayasa sistem
cenderung pada pengembangan sistem berbasis komputer.
 Proses Rekayasa Sistem disebut Rekayasa Informasi bila
konteks kerja berfokus pada sistem informasi bagi
manajemen yang bersifat unik bagi suatu institusi. Hasil
rekayasa ini dapat bersifat masal (menjadi suatu produk
yang dipasarkan masal) hanya bila dapat diterapkan di
berbagai institusi tanpa merubah fungsi-fungsi
transformasi.
11.1.1 KaraKkatraektrerisi stitkiSksiteSmisBterebamssi KBomeprubetradsati insdaKi ooel mh adpaunytaeelermen-elemen
yang berbasis komputer pula.
Sistem Otomasi Pabrik

Sistem Inventori Sistem Pemanukfaturan Sistem Informasi

Sistem Aliran Material Sel Pemanufakturan

Mesin Control Numeric Robot Perangkat Entry Data

11.1.2 Hirarki Rekayasa Sistem

 Rekayasa melingkupi sekumpulan metode dari atas ke bawah

(top-down) dan dari ke bawah ke atas (bottom-up) untuk
mengendalikan hirarki dari sistem makro.
 Proses rekayasa sistem dimulai dengan sebuah world view
(WV).
Semua domain bisnis atau domain produk diuji untuk memastikan
bahwa bisnis atau konteks teknologi yang tepat dapat dibangun.
 Pada domain tertentu, kebutuhan sistem yang ditargetkan (mis.
data, SW, HW, manusia) dianalisis. Kemudian analisis, desain, dan
konstruksi dari elemen yang ditargetkan diinisiasi.
 Pada puncak hirarki, suatu konteks yang lebih luas dibangun, dan
di bagian dasarnya, aktivitas teknik lengkap - yang dilakukan oleh
disiplin rekayasa yang relevan - dilakukan.
 Gambaran sistem :
WV = {D1 D2 D3……Dn}  WV = wold view (sebuah sistem besar)
Di = {E1 E2 E3……En}  Di = domain sistem (sub
sistem)
 11.1.3 Hirarki Rekayasa Perangkat Lunak

Domain Bisnis / Produk

World View

domain interes

Pandangan Domain
elemen sistem

Pandangan Elemen

Pandangan Detail
11.2 Rekayasa Informasi
 Tujuan dari rekayasa informasi (information engineering) adalah
untuk
 menentukan arsitektur yang memungkinkan suatu organisasi
/bisnis (selanjutnya disebut bisnis saja) menggunakan informasi
secara efektif,
 membuat suatu rencana menyeluruh guna
mengimplementasi arsitektur-arsitektur tersebut.
 Tiga arsitektur yang harus dianalisis dan dirancang dalam
konteks
dan tujuan bisnis:
 Arsitektur data
memberikan kerangka kerja untuk kebutuhan informasi dan bisnis atau fungsi
bisnis. Blok bangunan dari arsitektur ini adalah objek data yang digunakan
oleh suatu basisdata dan ditransformasikan untuk memberikan informasi yang
melayani kebutuhan bisnis.
 Arsitektur aplikasi
melingkupi elemen-elemen dari suatu sistem yang mentransformasi objek ke
dalam arsitektur data untuk keperluan bisnis.
 Infrastruktur teknologi
 Untuk memodelkan arsitektur sistem, ditetapkan hirarki
aktivitas rekayasa informasi, mulai dari World View,
Domain View, Element View hingga Detail View.
 WV dicapai melalui information strategy planning (ISP),
dengan memandang bisnis keseluruhan sebagai sebuah entitas
dan memisahkan domain bisnis yang penting untuk
perusahaan
/ institusi keseluruhan
 Pandangan domain yang dikaitkan dengan IE disebut
analisis area bisnis/ Business Area Analysis (BAA)
 BAA adalah pengindentifikasian data lengkap dan persyaratan
fungsi (dalam bentuk proses) dari area bisnis yang dipilih, yang
diindentifikasi selama ISP, dan memastikan interaksi mereka
(dalam bentuk matriks)
 BAA mendefinisikan objek-objek data, hubungan
 11.2.1 Hirarki Rekayasa Informasi

Perusahaan Perencanaan
Strategi Informasi
(World View)
area bisnis

Area Bisnis Analisis Area Bisnis

(Pandangan Domain)

persyaratan
pemrosesan
Desain Sistem
Sistem Informasi
Bisnis
(Pandangan
Elemen)
Perekaya
Perangkat
Konstruksi dan Lunak
Integrasi
(Pandangan
Detail)
11.2.2 Analisis Area
Bisnis
 Gambaran analisis area bisnis adalah sbb.

 BAA membentuk suatu kerangka kerja lengkap untuk membangun

perusahaan / organisasi yang berbasis informasi.
 BAAmenggunakan satu area bisnis pada suatu waktu dan
menganalisisnya secara detail.
 BAA menggunakan diagram dan matriks untuk memodelkan dan
merekam data / aktivitas dalam perusahaan serta untuk
memberikan pemahaman yang jelas tentang relasi antaraspek-aspek
informasi perusahaan secara rinci dan tajam.
 Untuk memodelkan relasi antaraspek-aspek informasi perekayasa
informasi harus menggambarkan penggunaan objek data dan
transformasinya pada masing-masing area bisnis dan
menggambarkan pula mekanisme fungsi dan proses bisnis pada
masing-masing area bisnis dalam mentransformasi objek data.
 Untuk melakukan tersebut, BAA menggunakan sejumlah model:
 model data
 model aliran proses
 diagram dekomposisi proses
 matriks lintas referensi
11.2.3 Pemodelan Data

 Objek : Pelanggan
 Atribut :
 nama
 nama perusahaan  objek :
perusahaan
 klasifikasi pekerjaan dan otoritas
pembelian
 alamat bisnis dan informasi kontak
 pembelian sebelumnya
 status kontak  status kontak terakhir
 tanggal kontak terakhir  rekaman
kontak  tanggal kontak selanjutnya
 sifat kontak yang disepakati
 Atribut nama perusahaan dimodifikasi
untuk menunjuk objek lain yang disebut
‘perusahaan’ yang dapat berisi informasi
tambahan mengenai besar perusahaan,
kebutuhan pembelian, nama kontak yang lain, dsb., yang berguna dalam domain
penjualan.
11.2.4 Pemodelan Proses

 Kegiatan pada suatu area bisnis mencakup serangkaian fungsi bisnis, yang diuraikan ke dalam proses
bisnis yang lebih rinci.

 Contoh : proses yang terjadi dalam fungsi penjualan

 membangun kontak pelanggan
 menyediakan literatur dan informasi yang sesuai
 mengarahkan pertanyaan dan perhatian
 memberi evaluasi produk
 menerima pesanan penjualan
 memeriksa ketersediaan konfigurasi yang dipesan
 menyiapkan pesanan pengiriman
 mengkonfirmasikan konfigurasi, penetapan harga, tanggal pengiriman ke pelanggan
 mengirim pesanan pengiriman ke bagian pengiriman
 tindak lanjut ke pelanggan
 Penjabaran proses tersebut tertuang dalam model sbb.
11.2.5 Pemodelan Aliran Informasi

 Model aliran proses diintegrasikan dengan model data untuk

mengindikasi aliran informasi melalui suatu area bisnis.

Mengkonfir-
masikan Info
pesanan
Memberi
Informasi Menyiapkan
produk Pesanan
pengiriman

Membangun Mengarahkan Menerima Memeriksa

kontak Pertanyaan/ Pesanan Konfigurasi
pelanggan perhatian penjualan ketersediaan

Membangun
Memberi
Kontak
pelanggan
Evaluasi
Tindak
produk
lanjut ke
pelanggan

Model aliran proses untuk fungsi penjualan

• Objek data input dan output yang diperlihatkan untuk masing-masing
proses menunjukkan transformasi informasi untuk menyelesaikan
suatu fungsi bisnis
Info pesanan
Pelanggan utk konfirmasi
Info
Mengkonfir-
produk masikan Info
Memberi Info query Data pesanan
pesanan
Rekaman Informasi
Menyiapkan
kontak produk
Pesanan
pengiriman Data
pengiriman

Info pesanan Pemenuhan

Membangun Mengarahkan Menerima Memeriksa
kontak Pertanyaan/ Pesanan Konfigurasi
pelanggan perhatian penjualan ketersediaan
pesanan

Membangun
Deskripsi Memberi
Kontak
produk Format pelanggan
Evaluasi
konfigurasi Tindak
produk ketersediaan lanjut ke
Deskripsi Info pesanan pelanggan
Produk terevaluasi
Pemenuhan
Pemenuhan pesanan
pesanan

Rekayasa Informasi merupakan suatu pendekatan Rekayasa Sistem yang digunakan untuk
menentukan arsitektur yang memungkinkan organisasi /bisnis menggunakan informasi scr efektif.
11.3 Rekayasa Sistem
 Rekayasa Sistem merupakan suatu aktivitas pemecahan masalah yang
dihadapi sistem.
 Data produk, fungsi, dan perilaku sistem harus ditemukan, dianalisis,
dan dialokasikan ke dalam komponen-komponen rekayasa.
 Perekayasa sistem harus memperjelas dan membatasi persyaratan
sistem dengan mengidentifikasi ruang lingkup fungsi dan kinerja yang
diinginkan.
 Rekayasa Sistem diawali dengan analisis sistem untuk membentuk
model arsitektur sistem dan spesifikasi sistem.
11.3.1 Aktivitas-aktivitas dalam Analisis Sistem

Analisis sistem dilakukan dengan sasaran sebagai berikut:

 mengidentifikasi kebutuhan pelanggan,
 mengevaluasi konsep sistem untuk fisibilitas,
 mengalokasikan fungsi-fungsi untuk perangkat keras, perangkat lunak, manusia,
basisdata, dan elemen sistem yang lain,
 membuat batasan biaya dan jadwal,
 menciptakan definisi sistem yang membentuk pondasi bagi semua kerja rekayasa
subsekuen.
1. Identifikasi Kebutuhan
 Dilakukan dengan cara bertemu dengan pelanggan dan pemakai akhir.
 Hasil dari indentifikasi kebutuhan dispesifikasi dalam suatu dokumen konsep
sistem
2. Studi Fisibilitas
 Fisibilitas ekonomi; evaluasi biaya pengembangan dibobot
dengan pemasukan utama atau keuntungan yang didapat dari
sistem atau produk yang dikembangkan
 Fisibilitas teknis; studi mengenai fungsi, kinerja, dan batasan
yang dapat mempengaruhi kemampuan untuk mencapai sebuah
sistem yang dapat diterima
 Fisibilitas legal; pertimbangan mengenai pelanggaran, kekerasan,
atau liabilitas (pertanggung jawaban) yang dihasilkan dari
pengembangan sistem
 Alternatif; evaluasi mengenai pendekatan alternatif pada
pengembangan sistem atau proyek
3. Analisis Ekonomi
 Analisis biaya keuntungan yang menggambarkan biaya untuk
pengembangan proyek dan membandingkannya dengan
keuntungan yang nyata dan tidak nyata dari suatu sistem.
4. Analisis Teknis
 Analis mengevaluasi kebaikan teknis dari konsep sistem, dan
pada saat yang sama mengumpulkan informasi tambahan
mengenai kinerja, reliabilitas, kemampuan pemeliharaan, dan
produksibilitas.
11.3.2 Pemodelan Arsitektur Sistem
 Untuk mengembangkan model sistem maka digunakan template arsitektur, yang
terdiri dari lima daerah pemrosesan : (1) interface pemakai; (2) input; (3) fungsi
dan kontrol; (4) output; (5) pemeliharaan dan self-test.

Pemrosesan interface pemakai

Fungsi proses
Pemrosesan dan kontrol Pemrosesan
input output

Pemeliharaan dan self-test

Contoh: Diagram konteks arsitektur untuk CLSS

Operator
Stasiun
sorting

Data permintaan Query dan

report
Pembaca Bar code Kode Mekanisme
Bar code Sistem Perintah
Pengurutan langsir pengurutan
Conveyor Line Data pelaporan
terformat
Indikator
Conveyor kecepatan
lain Data mainframe
diagnostik

Operator
Stasiun
sorting

***
 12. KONSEP DAN
PRINSIP
ANALISIS
1. Analisis Persyaratan
2. Prinsip-Prinsip Analisis
3. Area Kerja Analisis
1. Identifikasi dan Perumusan Masalah
2. Evaluasi dan Sintesis
3. Pemodelan Analisis
4. Spesifikasi
5. Kajian
12.1 Analisis Persyaratan
Analisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani
jurang antara alokasi perangkat lunak tingkat sistem dan desain perangkat lunak.
Analisis persyaratan memungkinkan perekayasa sistem menentukan fungsi dan kinerja
perangkat lunak, menunjukkan interface perangkat lunak dengan elemen-elemen sistem
yang lain, dan membangun batasan yang harus dipenuhi oleh perangkat lunak.

Analisis
Persyaratan PL

Elemen2
Perangkat lain
Lunak Desain
PL

Analisis
Persyaratan PL REKAYAS
A SISTEM
12.2 Prinsip-Prinsip
Analisis

1. Prinsip Operasional
 Domain informasi dari suatu masalah harus dipahami
 Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan
 Perilaku perangkat lunak harus direpresentasikan
 Model-model yang menggambarkan informasi, fungsi dan tingkah laku sistem harus dipecah-pecah
secara hirarki
 Proses analisis harus bergerak dari informasi dasar ke detail implementasi
2. Prinsip Panduan untuk rekayasa persyaratan
 Memahami masalah sebelum membuat model analisis
 Mengembangkan prototipe, sehingga pemakai memahami bagaimana interaksi manusia dan
komputer
 Merekam asal dan alasan untuk setiap persyaratan
 Menggunakan pandangan persyaratan bertingkat
 Memprioritaskan persyaratan
 Mengurangi ambiguitas
12.3 Area Kerja
Analisis
 Analisis persyaratan memberikan model-model yang akan
diterjemahkan ke dalam data, arsitektur, interface, dan desain
prosedural kepada perancang perangkat lunak.
 Analisis persyaratan perangkat lunak dapat dibagi menjadi lima area
kerja:
1) Identifikasi dan Perumusan Masalah

2) Evaluasi dan Sintesis

3) Pemodelan

4) Spesifikasi

5) Kajian
12.3.1 Identifikasi dan Perumusan Masalah
Identifikasi bisa diawali dengan mempelajari spesifikasi sistem dan atau
rencana proyek perangkat lunak. Contohnya :
Pemasok besar suku cadang kendaraan bermotor membutuhkan sistem
kontrol inventaris. Analis merumuskan masalah yang berhubungan
dengan sistem manual yang ada sbb.
 Ketidakmampuan untuk dengan cepat memperoleh status suatu
komponen.
 Dua atau tiga hari berkali-kali memperbarui suatu file kartu.
 Pemesanan kembali secara bertingkat kepada penjual yang sama karena
tidak ada cara untuk menghubungkan para penjual dengan komponen, dsb.
12.3.2 Evaluasi dan Sintesis

 Dalam melakukan analisis, fokus utama analis adalah pada ‘apa’? bukan
‘bagaimana?’.
Data apakah yang diproduksi dan dikonsumsi, batasan apakah yang dipakai?
 Selama aktivitas sintesis, evaluasi, dan solusi analis menciptakan model-
model sistem untuk memahami aliran data dan kontrol, operasi behavioral
dan pemrosesan fungsional, serta muatan informasi.
 Model tersebut berfungsi sebagai dasar bagi desain perangkat lunak dan untuk
membuat spesifikasi perangkat lunak.
 Spesifikasi lengkap belum bisa didapatkan pada tahap ini, pendekatan
alternatif pada analisis persyaratan adalah prototyping.
12.3.3 Pemodelan Analisis
Struktur Model Analisis
DD : mendeskripsikan
semua objek data yang
dikonsumsi PL
ERD : menggambarkan
hub antarobjek data

DFD : merepresentasikan
transformasi data dan Entity Data
fungsi-fungsi tranformasi Relationship Flow
Diagram Diagram
STD : (ERD)
Data (DFD)
menunjukkan perilaku Dictionary
sistem akibat
(DD)
kejadian eksternal
PSPEC : mendeskripsi State
setiap fungsi / Transition
proses pada DFD Diagram
(STD)
CSPEC : deskripsi aspek
kontrol PL
Pemodelan Data

Model data terdiri dari tiga informasi yang saling tergantung:

1. Objek data adalah representasi dari semua informasi gabungan yang
harus dipahami oleh perangkat lunak
 Objek data dapat berupa entitas eksternal (semua sumber data atau yang
mengkonsumsi informasi), suatu benda (laporan atau tampilan), peristiwa (sambungan
telepon) atau event (sebuah alarm), peran (tenaga penjualan), unit organisasi
(bagian akuntansi), atau suatu struktur (file).
2. Atribut adalah properti suatu objek data.
 Atribut digunakan untuk:
 menamai sebuah contoh dari objek data,
 menggambarkan contoh,
 membuat referensi ke contoh yang lain pada tabel yang lain
3. Hubungan adalah relasi antara objek data yang satu dengan yang lainnya.
 Misal: Sensor dan Pintu  hubungan : Sensor menggerakkan Pintu
Objek Data, Atribut dan Hubungan

Objek: Atribut: Hubungan:

Nama
Alamat
Umur
Lisensi Mengemudi
Nomor

memiliki

Merk
Model
Nomor ID
Tipe
Warna
Representasi Tabular Objek Data

Mengikat satu objek data ke data

lain, dalam kasus ini, pemilik
Atribut
penamaan

Atribut
Atribut
pengidentifikasi deskriptif
referensial

Merk Model ID# Tipe Warna Pemilik

Lexus LS400 AB123 Sedan Putih RSP
BMW 750iL X456 Coupe Merah CCD
Ford Taurus YZ276 Sedan Putih LJL
Chevy Corvette Q1234 Sport Hijau BLF
12.3.4 Spesifikasi
Pada prinsipnya Spesifikasi merupakan representasi persyaratan
dari perangkat lunak yang akan dibangun. Diperlukan
pendekatan sbb.
 Teknik spesifikasi yang terfasilitasi (Facilitated
Aplication Specification Techniques = FAST)
 Pertemuan dilakukan di tempat netral yang dihadiri oleh
pengembang maupun pelanggan.
 Tujuannya : identifikasi masalah, pemecahan, negosiasi,
membentuk persyaratan PL.
 Ada fasilitator (sebaiknya konsultan) yang bertugas mengontrol
pertemuan.
 Penyebaran fungsi kualitas
 Quality Function Deployment (QFD) adalah teknik manajemen
kualitas yang menterjemahkan kebutuhan pelanggan ke dalam
persyaratan teknis bagi perangkat lunak
 QFD berkonsentrasi pada pemaksimalan kepuasan pelanggan
Hasil proses spesifikasi dituangkan dalam Dokumen Spesifikasi
12.3.5 Kajian
Kajian digunakan untuk memastikan Spesifikasi sudah lengkap,
konsisten, dan akurat. Contoh pertanyaan kajian :

 Apakah tujuan dan sasaran yang dinyatakan bagi PL tetap

dengan tujuan dan sasaran sistem?
konsisten
 Apakah interface ke semua elemen sistem sudah
digambarkan?
Apakah aliran informasi dan struktur telah didefinisikan dengan tepat
domain masalah?
 bagi
 Apakah diagram telah dipresentasikan dengan
jelas?
Apakah fungsi mayor tetap ada dalam ruang lingkup dan
digambarkan dengan tepat?
 sudah
 Apakah perilaku PL konsisten dengan informasi yang harus diproses
danfungsi yang harus dilakukannya?
 Apakah batasan desain realistis?
 Apakah risiko teknologis
pengembangan sudah
Apakah kriteria validasi dinyatakan secara detil dan memadai
menggambarkan
dipertimbangkan?
untuk sebuah sistem yang berhasil?
 Apakah ada inkonsistensi, penghilangan, atau

redundancy?
 Apakah kontak dengan pelanggan sudah lengkap?
 Apakah pemakai sudah mengkaji manual atau prototype?
***
13. KONSEP DAN PRINSIP
PERANCANGAN
(DESAIN)
13.1 Transformasi Model Analisis ke Model Desain

Entity Data
Relationship Flow Desain
Diagram Diagram
(ERD)
Prosedural
Data (DFD)
Dictionary Desain
(DD) Interface

State
Transition Desain Arsitektur
Diagram
(STD)
Desain Data
13.2 Desain Data
Desain data adalah tahapan pemilihan representasi logis
dari objek data yang telah teridentifikasi dalam Analisis
Persyaratan dan Spesifikasi. Prinsip2nya :
 Prinsip2 analisis sistem yang diterapkan pada fungsi dan
perilaku PL juga perlu diterapkan pada data.
 Semua struktur data dan operasinya harus
teridentifikasi.
 Kamus data harus dibangun untuk merepresentasikan
hub
antarobjek data dan batasan2nya.
 Keputusan desain data tingkat rendah harus dilakukan di akhir
proses desain data.
 Konsep information hiding (penyembunyian informasi suatu
modul agar tidak diakses oleh modul lain yang tidak
berkepentingan) dan perangkaian sangat penting bagi
kualitas PL.
 Pustaka struktur data dan operasi yang berguna
harus dikembangkan agar dapat digunakan kembali.
13.3. Desain Arsitektur PL
Arsitektur merupakan struktur hirarkhi dari komponen program (modul),
interaksinya, dan struktur data yang digunakan. Terdapat bbrp model
desain arsitektur :

 Model Struktural : bdsk struktur komponen program

 ModelKerangka Kerja : berupa peningkatan abstraksi desain
berdasarkan kerangka kerja
 Model Dinamis : menggambarkan perilaku berdasarkan external events
 Model Proses : fokus pada proses
 Model Fungsional : menggambarkan hirarkhi fungsional
 Alat process modeling : Flow Chart, Flow of Document, Data Flow
Diagram, Structured Chart, HIPO Diagram, Pseudocode, Nassi-
Shneiderman Chart, Warnier-Orr Diagram, Michael Jackson Diagram,
Functional Decomposition, Action Diagram, Data Navigation
Diagram, HOS Chart, dsb.

 Alatdata modeling : Entity Relationship Diagram, Network Diagram,

Hierarchical Diagram, Table Normalization, atau gabungannya.

 Alat object modeling : Object Diagram (Coad/Yourdon, Rambaugh,

Firesmith, Booch, dsb.) yang dapat dibangun dengan Oracle
Designer/2000, Microsoft Visual Studio – Enterprise Tools
(Modeler), dsb.

 Alat working modeling : Excelerator, Easycase, Oracle

Designer/2000,
Microsoft Visual Studio - Enterprise Tools (Modeler), dsb.

Studi perbandingan tentang berbagai macam alat tersebut dapat

dijumpai di buku Structured Techniques (James Martin& Carma
McClure).
13.3.1. Modularitas
13.3.1.1 Modularitas dan Kompleksitas Problem

Modularitas diterapkan melalui pembagian PL ke dalam

komponen
– komponen PL yang dapat dipanggil terpisah sehingga bila
terdapat problem, maka problem tsb akan lebih mudah
diselesaikan. Kompleksitas ( C ) problem (p1 dan p2) yang
bergabung menjadi satu, lebih besar dibandingkan bila problem
tersebut dipandang secara terpisah.

C(p1+p2) > C(p1) + C(p2)

Oleh sebab itu modularitas penting dalam desain arsitektur PL.

Namun berkaitan dengan biaya, sebaiknya dihindari kondisi
undermodularity maupun overmodularity. Semakin banyak
modul semakin rendah biaya per-modul tetapi semakin tinggi
biaya integrasinya.
13.3.1.2 Independensi Fungsional

Konsep ini mrpk pertumbuhan langsung dari modularitas, konsep abstraksi PL,
dan Information Hiding. Independensi diukur melalui Kohesi dan Kopling.
 Kohesi
Modul yang kohesif seharusnya hanya melakukan satu hal saja (kohesi tinggi =
fungsional <> koinsidental).
 Kopling
Sehubungan dengan perangkaian dengan modul lain, maka modul yang baik
seharusnya memiliki hubungan yang sederhana (kopling rendah)
13.3.2 Proses Desain Arsitektur

13.3.2.1 Pemetaan Transformasi

Informasi dari ‘dunia eksternal’ mengalir masuk ke dalam PL dan keluar lagi
dalam bentuk informasi dunia eksternal. Misal ketikan keyboard dan bunyi di
saluran telpon akan masuk ke pusat transformasi dan dialirkan ke dunia luar
dalam bentuk tampilan layar. Aliran ini disebut aliran transformasi. Dalam DFD
dapat dijumpai adanya aliran transformasi ini.

Guna menyusun struktur program aliran transformasi dari DFD ini dipetakan
dengan langkah pengkajian thd Context DFD, penentuan pusat transformasi,
pemfaktoran dan penyaringan, dan pemetaan. Contohnya sbb.
Contoh Pemetaan Penjualan
Transformasi

Promosi Penerimaan Persiapan

Pesanan Pengiriman

Mengkonfir-
masikan Info
pesanan
Memberi
Informasi Menyiapkan
produk Pesanan
pengiriman

Membangun Mengarahkan Menerima Memeriksa

kontak Pertanyaan/ Pesanan Konfigurasi
pelanggan perhatian penjualan ketersediaan

Membangun
Memberi
Kontak
pelanggan
Evaluasi
Tindak
produk
lanjut ke
pelanggan
13.3.2.1 Pemetaan Transaksi

Aliran transaksi ditandai dengan pergerakan data sepanjang jalur masuk yang
mengkonversikan informasi dunia eksternal ke dalam suatu transaksi.
Transaksi ini akan menimbulkan jalur aksi. Pusat aliran informasi tempat
banyak jalur aksi berasal disebut pusat transaksi.

 Pemetaan DFD yang mengandung aliran transaksi ke struktur program hampir

sama dengan pemetaan aliran transformasi, namun yang diidentifikasi adalah
pusat transaksinya (lihat contoh)
Contoh Pemetaan Transaksi Kontrol Transaksi
a
b d
b

d a c1

q
p
q r s
r

s p
13.4 Desain Interface

1. Internal : merupakan desain interface antarmodul dalam PL yang dikendalikan oleh

data yang harus mengalir di antara modul-modul. Aliran transformasi dalam DFD
merupakan pijakan utama dalam desain ini selain kemampuan bahasa pemrograman.

2. Eksternal : merupakan interface untuk entitas eksternal (tidak termasuk manusia), misalnya
sensor pada PL Safehome.

3. Manusia – Mesin : merupakan interface antara manusia dengan PL (Human – Computer

Interface). Interface ini memiliki tantangan besar karena berkaitan dengan pengguna
dengan berbagai karakter yang lebih sulit untuk dipelajari. Terdapat tiga kategori
pedoman desain HCI sbb.
a. Interaksi Umum
 Format konsisten

 Berikan umpan balik

 Konfirmasi untuk aksi destruktif (misal

 Hapus) Ijinkan pembatalan (misal Undo)

 Kurangi jumlah informasi yang harus diingat

 Efisiensi dalam dialog, gerakan (tangan),

 pemikiran Perlindungan thd kegagalan

 Kategorikan aktivitas sejenis dan posisinya di

 layar Sediakan Help yang sensitif konteks

 Berikan petunjuk singkat (tools tips) pada setiap button / ikon /

 nama Gunakan perintah dan nama2 yang pendek
b. Output

 Tampilkan informasi yang relevan dg konteks

 Jangan membanjiri pemakai dg informasi

 Gunakan label, singkatan, warna yg standar dan konsisten

 Peliharalah konteks visual saat pengguna melakukan zoom-in / zoom-out

 Pesan kesalahan harus memiliki arti yang jelas

 Gunakan variasi huruf, indentasi, pengelompokan untuk memudahkan

 pemahaman Gunakan jendela untuk tipe-tipe informasi yang berbeda

 Gunakan tampilan alami (bukan angka / grafik) bila memungkinkan

 Geografi layar dioptimalkan shg tidak ada jendela yang ‘hilang’ / sulit ditemukan

 Berikan kemungkinan kustomisasi output (utk advance user)

 Jangan ada informasi / data yang tidak lengkap / hilang
c. Input sebagian
 Minimalkan jumlah aksi input (combo box, list, dsb.)

 Konsisten

 Berikan kemungkinan kustomisasi input (utk advance

 user) Mode input harus fleksibel (mouse / keyboard)

 Non-aktifkan button / ikon yang tidak relevan dengan aksi

 Berikan kesempatan untuk mengontrol aliran interaksi (mengubah, membetulkan,

 mengulang) Sediakan Help

 Jangan meminta aktivitas manual (perhitungan, tanggal, waktu, dsb) bila dapat dilakukan
oleh PL
13.5 Desain Prosedural

Spesifikasi prosedural ditetapkan setelah desain data, arsitektur, dan interface selesai guna
penyusunan algoritma PL.

Desain prosedural diterapkan melalui teknik pemrograman terstruktur yang didasarkan

pada struktur logika algoritma :
 Sekuensial
 Percabangan
 Perulangan
Alat-alat yang dapat digunakan :
Flow Chart, HIPO Diagram, Pseudocode, Nassi-Shneiderman Chart, Warnier-Orr Diagram,
Action Diagram, HOS Chart, dsb.

***
 14.
PENGUJIAN
1.
PERANGKAT
Dasar-dasar Pengujian
2. LUNAK
Teknik Pengujian
3. Strategi Pengujian dan V&V
 14.1 Dasar-dasar Pengujian
Metrik Kualitas PL

Maitainabilty Portability
Flexibility Reusability
Interoperability
TESTABILITY
Revisi Transis
Produ i
k Produk

Operasi
Produk

Correctness, Reliability, Usability, Integrity, Efisiency

Faktor Kualitas PL McCall

Testabilit
y
 Operabilitas
 Observabilitas
 Kontrolabilitas
 Dekomposabilitas
 Kesederhanaan
 Stabilitas
 Kemampuan untuk dapat dipahami

Sebelum melakukan pengujian perlu dipersiapkan Test

Case terlebih dahulu agar diperoleh kemungkinan
tertinggi dalam menemukan kesalahan dengan waktu
dan usaha yang minimum. Desain Test Case dapat
dilakukan melalui berbagai teknik pengujian sbb.
14.2 Teknik Pengujian

 Semua jalur independen pada suatu modul ditelusuri minimal

1 kali
 Semua jalur keputusan logis True / False dilalui
 Semua loop dieksekusi pada batas yang tercantum dan batas
operasionalnya
 Struktur data internal digunakan agar validitas
terjamin.
1.

 Merupakan salah satu teknik White Box

 Merupakan salah satu teknik pengujian struktur kontrol
 Menjamin semua statemen dalam setiap jalur
independen program dieksekusi minimal 1 kali.
Perhitungan jalur independen dapat dilakukan melalui metrik
Cyclomatic Complexity
 Didasarkan pada teori graph.
 Desain prosedural
1
diterjemahkan dalam suatu
grafik alir.
 Dihitung melalui 4 cara
2,3
 V(G) = jumlah region grafik
alir
6
R2  V(G) = jumlah path
4,5  V(G) = E – N + 2
7 R3 8  V(G) = P + 1
E : Edge
R1 N : Node
9
P:
simpul
10 predikat
(IF /
perca
R4 bang
11 Contoh
an) V(G) = 4
V(G)
Ri : > 10 : more troblesome and
less reliable[MART88].
Region
2. Pengujian Struktur Kontrol
Teknik ini merupakan perbaikan dari basis path yang
meliputi :

 Pengujian Kondisi : didasarkan pada struktur

kontrol (=, <, >, not, and, dsb.)
 Pengujian Aliran Data : didasarkan pada
adanya
hubungan antar-statemen pada program.
 Pengujian Loop : berfokus pada validitas konstruksi
loop.
Pengujian ini berfokus pada persyaratan fungsional PL dan
merupakan komplemen dari pengujian White-Box. Hal tsb dapat
dicapai melalui :
1. : dimulai dengan membuat grafik
sekumpulan node yang mempresentasikan objek(misal New File,
Layar baru dg atributnya), link (hubungan antarobjek), node-
weight (misal nilai data tertentu seperti atribut layar, perilaku),
dan link-weight (karakteristik suatu link, misal menu select)
2. : membagi domain input untuk
pengujian agar diperoleh kelas-kelas kesalahan (misal kelompok
data karakter, atau atribut yang lain)
3. : pengujian
berdasarkan nilai batas domain
input.
4.
: disebut juga pengujian back-to-back
yang diterapkan pada pada suatu versi PL atau PL redundan
14.2.3 Pengujian untuk Aplikasi dan Lingkungan
Khusus
1. Pengujian GUI : dilakukan melalui sederetan check list
untuk menguji tampilan.
2. Pengujian Arsitektur Client – Server : berkaitan dengan sifat
pemrosesan terdistribusi, kinerja, kehadiran sejumlah
platform HW yang berbeda, kompleksitas komunikasi data dan
jaringan, kebutuhan akan layanan client multiple, dan
persyaratan koordinasi yang dibebankan pada server.
3. Pengujian Dokumentasi dan Help : didekati dalam 2 fase, yakni
FTR dan live test yang dikaitkan langsung pada penggunaan
nyata.
4. Pengujian Sistem Real Time : berkaitan dengan penanganan
interupsi, timing data, proses paralel. Langkah2 yang dilakukan
meliputi Pengujian Task, Pengujian Perilaku, Pengujian antar-
task, dan Pengujian Sistem.
14.3 Strategi Pengujian dan V&V
1.
mengintegrasikan metode desain test case PL ke dalam
sederetan langkah yang bertujuan untuk menghasilkan perangkat
lunak yang berhasil.
2.
 harus dilakukan pada tiap tahap pengembangan sistem,
 dengan dokumentasi dari tahap sebelumnya.
Verifikasi  are we building the product right :
tepat mengimplementasikan

Validasi  are we building the right product :

persyaratan
pelanggan
User Testing dlm
Alpha Test luar
Beta Test ngu Black-
14.3.1 Proses Pengujian

COMPONENT
TESTING

INTEGRATIO
N USER
TESTING TESTING
1. Component Testing
Pengujian terhadap komponen sistem, seringkali menggunakan teknik pengujian
White-Box.
a. Unit Testing
• pengujian tahap awal
• pengujian komponen secara terpisah
• unit-unit terkecil diuji : function, procedure, subprogram, dll
b. Module Testing (modul memadukan beberapa komponen)
• menguji interaksi antarunit
• menguji perilaku modul
2. Integration Testing
Top-Down, Bottom-Up, dan
Pengujian Regresi

Black-Box maupun sebagian White-Box.

a.
antarmuka

an
b.
•
•

3. User Testing
Black-Box.
a.
14.3.2 Perencanaan Pengujian

and Test

Use

***