OPTIMIZED-SOFTWARE-ENGINEERING

BAB I
SOFTWARE ENGINEERING
Arti Software Engineering :
Ilmu yang mempelajari tehnik pembuatan software yang baik dengan pendekatan tehnik (Engineering ap-
proach)
Dalam membuat softrare yang baik, ada beberapa cara :
1. Fase Perencanaan (Planning) :
a) Rencana software
b) Analisa kebutuhan software
c) Analisa cost banefit (Salah satu bagian dari studi kelayakan)
2. Fase Pengembangan (Development) :
a) Coding
b) Testing
Macam-macam test program :
i) Unit test (Test per modul)
ii) Integreated test (Test penggabungan dari modul-modul yang telah diuji)
iii) Validated test (Diuji dengan data sebenarnya)
iv) System test (Test dilakukan dengan lingkungan sebenarnya)
v) Topdown test (Test gabungan dari atas ke bawah)
vi) Bottom up test (Test gabungan dari bawah ke atas)
3. Fase Pemeliharaan (Maintenance) :
Jenis-jenis maintenance
a) Koreksi (Corection)
b) Adaptasi (Adaptive)
Software dikembangkan sesuai dengan tuntutan perkembangan jaman
c) Adaptasi yang berkembang pada dewasa ini terbagi atas :
i) Sistem Operasi
Pengarahan sistem operasi yang bersifat multi user. Contoh : UNIX
Sistem operasi yang bersifat jaringan. Contoh : NOVELL
ii) RDBMS - Relational DataBase Management System
Berkembang dalam bentuk bahasa SQL (Structure Query Language).
iii) Bahasa
Mengarah pada perkembangan bahasa generasi ke empat (4GL - Fourth Generation Language)
Bahasa 4GL adalah suatu bahasa yang dibuat untuk meningkatkan produktifitas programmer dan end
user. Contoh :
a) INFORMIX - Dapat dijalankan pada PC dengan minimum RAM 4MB + 640KB dan disk stor-
age > 40MB
b) ORACLE
c) INGRES
B
y

H
e
n
d
r
a
N
e
t
http://www.hendra-jatnika.web.id
Page 1 / 146
d) AS / SET - Digunakan pada IBM AS 400
e) POWER HOUSE - digunakan pada HR 3000
iv) Perfective
Menyempurnakan software yang ada biasanya dilakukan karena permintaan / saran /
kritik user.
B
y

H
e
n
d
r
a
N
e
t
Page 2 / 146
SOFTWARE AND SOFTWARE ENGINEERING
Selama tiga dekade pertama dari era komputerisasi, tantangan utama adalah mengembangkan hardware komputer
yang dapat mengurangi biaya pengolahan dan penyimpanan data. Selama dekade tahun 1980 an, kemajuan yang
pesat dari mikro elektronik menghasilkan kemampuan komputer yang lebih baik pada tingkat biaya yang lebih
rendah. Namun masalah sekarang berbeda. Tantangan utama adalah mengurangi biaya dan memperbaiki kualitas
solusi berbasis komputer (Solusi yang diimplementasikan dengan mempergunakan software). Software
merupakan faktor kunci dalam keberhasilan suatu usaha, software dapat membedakan satu perusahaan dari per-
usahan saingannya.
EVOLUSI PERKEMBANGAN SOFTWARE
Evolusi software
1950 1960 1970 1980 1990 2000
Tahun-tahun awal :
Batch orientation
Limmited distribution
Custummer software
Era kedua :
Multi user
Real time
Database
Era ketiga
Distibuted system
Embedded intellegence
Low cost hardware
Consumer infact
Era keempat :
Expert system
A I Machine
Parallel architecture
TAHUN-TAHUN PERTAMA :
Batch Orientation
Suatu orientasi di mana proses dilakukan setelah data dikumpulkan dalam satuan waktu tertentu, atau proses
dilakukan setelah data terkumpul, lawan dari batch adalah ONLINE atau Interactive Process.
Keuntungan dari Interactive adalah mendapatkan data yang selalu up to date.
Limmited distribution
Suatu penyebaran software yang terbatas pada perusahaan-perusahaan tertentu.
Custom software
Software yang dikembangkan berdaasarkan perusahaan-perusahaan tertentu.
ERA KEDUA :
Multi user
Suatu sistem di mana satu komputer digunakan oleh beberapa user pada saat yang sama.
Real Time
B
y

H
e
n
d
r
a
N
e
t
Page 3 / 146
Suatu sistem yang dapat mengumpulkan, menganalisa dan mentransformasikan data dari berbagai sumber,
mengontrol proses dan menghasilkan output dalam mili second.
Database
Perkembangan yang pesat dari alat penyimpan data yang OnLine menyebabkan muncul generasi pertama
DBMS (DataBase Management System).
Product Software
Adalah software yang dikembangkan untuk dijual kepada masyarakat luas.
ERA KETIGA :
Distributed system
Suatu sistem yang tidak hanya dipusatkan pada komputer induk (Host computer), daerah atau bidang lainnya
yang juga memiliki komputer yang ukurannya lebih kecil dari komputer induk. Lawan dari distributed system
adalah Centralized System.
Embedded Intelegence
Suatu product yang diberi tambahan Intellegence dan biasanya ditambahkan mikroprocessor yang mutak-
hir. Contohnya adalah automobil, robot, peralatan diagnostic serum darah.
Low Cost Hardware
harga hardware yang semakin rendah, ini dimungkinkan karena munculnya Personal Computer.
Consummer Inpact
Adanya perkembangan komputer yang murah menyebabkan banyaknya software yang dikembangkan, soft-
ware ini memberi dampak yang besar terhadap masyarakat.
ERA KEEMPAT :
Expert system
Suatu penerapan A.I. (Artificial Intellegence) pada bidang-bidang tertentu, misalnya bidang kedokteran,
komunikasi, dll.
AI Machine
Suatu mesin yang dapat meniru kerja dari sebagian otak manusia. Misalnya mesin robot, komputer catur.
Parallel Architecture
Arsitektur komputer yang memungkinkan proses kerja LAN paralel, yang dimungkinkan adanya prosesor
berbeda dalam satu komputer
ARTI SOFTWARE
1. Instruksi
Atau program komputer yang ketika dieksekusi akan memberi fungsi dan hasil yang diinginkan.
2. Struktur data
Yang memungkinkan program memanipulasi informasi
3. Dokumen
Yang menggambarkan operasi dan penggunaan program.
SIFAT DAN KARAKTERISTIK SOFTWARE
1. Software merupakan elemen sistem logik dan bukan elemen sistem fisik seperti hardware
B
y

H
e
n
d
r
a
N
e
t
Page 4 / 146
2. Elemen itu tidak aus, tetapi bisa rusak.
3. Elemen software itu direkayasa atau dikembangkan dan bukan dibuat di pabrik seperti hardware
4. Software itu tidak bisa dirakit.
KOMPONEN SOFTWARE
1. Bentuk bahasa
Terbagi 2, yaitu
A. High Level, contoh PASCAL, COBOL, FORTRAN.
B. Middle Level, contoh C
2. Bentuk translator
Terbagi 3 , yaitu :
A. Interpreter
Menerjemahkan dari bahasa tingkat tinggi ke bahasa tingkat rendah secara satu persatu (statemen demi
statemen)
B. Compiler
Menerjemahkan secara keseluruhan, proses lebih cepat dari interpreter
C. Assembler
Menerjemahkan dari bahasa rakitan ke bahasa mesin
3. Bentuk mesin :
LANGUAGE FORM
TRANSLATOR
MACHINE
LANGUAGE
HIGH LEVEL
MIDDLE LEVEL
B
y

H
e
n
d
r
a
N
e
t
Page 5 / 146
APLIKASI SOFTWARE
1. Sistem Software
Adalah sekumpulan program yang ditulis untuk melayani atau menunjang program lainnya. Beberapa sistem
software seperti compiler, editor, komponen-komponen sistem operasi, driver dan prosesor telekomunikasi.
2. Real Time software
Software yang mengukur, menganalisis dan mengontrol kejadian yang sesungguhnya terjadi di dunia. Elemen-
elemen real time software terdiri dari :
A. Komponen pengumpul data
Yang mengumpulkan dan menyusun informasi dari lingkungan external.
B. Komponen analisis
Yang mentransformasikan informasi yang diperlukan oleh aplikasi
C. Komponen kontrol
Yang memberikan respon kepada lingkungan external
D. Komponen monitor
Yang mengkoordinasi semua komponen-komponen lainnya, sehingga respons real time yang berkisar 1
milisecond sampai 1 menit dapat dipertahankan.
Perlu dicatat bahwa istilah real time berbeda dari istilah interactive atau time sharing. Sistem real time harus
memberikan respons pada waktu yang ditentukan, sedangkan pada sistem interactive atau time sharing
respons time biasanya melebihi batas waktu yang ditentukan tanpa merusak hasil.
3. Business software
Software yang palinmg banyak digunakan dalam bidang aplikasi software. Software ini digunakan oleh
manajemen untuk mengambil kepitusan ( Decision Making ) dalam bidang bisnis. Contoh :
DAC EASY ACCOUNTING
FINANCE MANAJER
4. Engineering and sciencetific software
Software yang dicirikan dengan algoritma numerik, aplikasinya berkisar dari astronomi sampai vulkanologi, dari
analis ketegangan otomotif sampai dinamika orbit ruang angkasa. Software ini banyak digunakan dalam
bidang engineering dan science. Contoh
CAD / CAM ( Computer Aided Design / Computer Aided Manufacture - Ssimulasi sistem )
5. Emdebed software
Suatu software disimpan dalam memori tetap - ROM - Read Only Memory, dan digunakan untuk mengontrol
product dan sistem software ini dijalankan dengan berbagai fungsi terbatas.
6. PC software (Personal Computer)
Software yang banyak digunakan di komputer pribadi (PC). Contoh :
Word Processing : WS, WP
Spreadsheet : Lotus, Supercalc
Computer Graphics : Printshop, Print Magic
Games : Paoman, Load Runner
DBMS : Dbase III+, Foxbase, Clipper
Network : LAN, Novell
7. Artificial Intelegence software
B
y

H
e
n
d
r
a
N
e
t
Page 6 / 146
Software yang banyak menggunakan algoritma non numerik dalam memecahkan masalah kompleks yang tidak
dapat dianalisis dengan analisis komputasi biasa. Saat ini bidang AI yang paling aktif adalah expert system
atau knowledge base system. Bidang aplikasi lain dari software AI adalah pengenalan citra dan suara ( image
and voice pattern recognition ), teorema pembuktian dan permainan / games.
KRISIS SOFTWARE
Adalah sekumpulan masalah yang ditemukan dalam pengembangan software computer. Masalahnya tidak hanya
terbatas pada software yang tidak berfungsi sebagaimana mestinya, tetapi krisis software ini terdiri dari masalah
yang berhubungan dengan :
1. Bagaimana mengembangkan software
2. Bagaimana memelihara software ynag ada, yang berkembang dalam jumlah besar
3. Bagaimana mengimbangi permintaan software yang makin besar.
MASALAH
Krisis software oleh beberapa masalah :
1. Estimasi jadual dan biaya yang seringkali tidak tepat
2. Produktivitas orang-orang software yang tidak dapat mengimbangi permintaan software
3. Kualitas software yang kurang baik.
Penyebab :
Masalah yang berhubungan dengan krisis software disebabkan oleh :
1. Karakteristik software itu sendiri
Karakteristik software adalah software yang bersifat logika dibandingkan fisik, oleh karena itu mengukur
software harus merupakan suatu kesatuan, tidak seperti hardware. Software yang bersifat tidak aus ini
menyebabkan kesalahan yang terjadi pada software. Umumnya terjadi pada tahap pengembangan. Manajer
tingkat menengah dan tingkat atas yang tidak mempunyai latar belakang software, seringkali diberi tanggung
jawab untuk mengembangkan software. Padahal tidak semua manajer itu dapat me-manage semua proyek.
Praktisnya : software programmer atau software engineering mendapatkan latihan formal yang sedikit dalam hal
tehnik baru pengembangan software.
2. Kegagalan mereka yang bertanggung jawab dalam pengembangan software.
MITOS SOFTWARE
1. Mitos managements
A. Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang
kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu.
Realitasnya : Walau hasil program sama, produktivitas dan kualitas software harus ditingkatkan dengan
menggunakan pendekatan software developments
B. Kita sudah mempunyai buku yang berisi standarisasi dan prosedur untuk pembentukan software.
Realitasnya : Memang buku tersebut ada, tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah
ketinggalan jaman ( out of date ).
C. Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini
sering disebut Mongolian harde concept.
2. Mitos Langganan / Customer
B
y

H
e
n
d
r
a
N
e
t
Page 7 / 146
A. Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci
akan menyusul kemudian.
Realitasnya : Definisi awal yang buruk adalah penyebab utama kegagalan terhadap usaha-usaha pem-
bentukkan software. Penjelasan yang formal dan terinci tentang informasi fungsi performance interface,
hambatan desain dan kriteria validasi adalah penting. Karakteristik di atas dapat ditentukan hanya setelah
adanya komunikasi antara customer dan developer.
B. Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat
fleksibel. Kenyataannya memang benar bahwa kebutuhan software berubah, tetapi dampak dari peru-
bahan berbeda dari waktu ke waktu.
1kali
1,5-6
kali
60-100
kali
Biaya akibat
perubahan
Definition Development Maintenance
Waktu penyelesaian
Kesimpulan : Jika perubahan mendekati akhir penyelesaian, maka biaya akan lebih besar.
3. Mitos Praktisi
A. Tidak ada metode untuk analisis disain dan testing terhadap suatu pekerjaan, cukup menuju ke depan
terminal dan mulai coding.
Realitasnya : Metode untuk analisis desain dan testing diperlukan dalam pengembangan software.
B. Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi dengan cara
CATCH AS CATCH CAM.
Realitasnya : Diperlukan budget yang besar dalam maintenance software. Pemeliharaan software harus
diorganisir, direncanakan dan dikontrol seolah-olah sebagai suatu proyek besar dalam sebuah organisasi.
MODEL SOFTWARE ENGINEERING
Krisis software tidak dapat hilang dalam satu satu malam, di mana tidak ada suatu pendekatan yang baik dalam
mengatasi krisis software, namun gabungan dari metode untuk semua fase dalam pengembangan siftware seperti
peralatan yang lebih baik untuk mengautomatisasi metode-metode ini, tehnik yang lebih baik untuk mengontrol
kualitas, dan filosofi untuk koordinasi kontrol, serta manajemen dipelajari dalam suatu disiplin ilmu yang kita
sebut software engineering.
Definisi :
Menurut Fritz Badar, software engineering adalah disiplin ilmu yang menerapkan prinsip-prinsip engineering
agar mendapatkan software yang ekonomis yang dapat dipercaya dan bekerja lebih efisien pada mesin yang se-
benarnya.
Software engineering terdiri dari 3 elemen kunci, yaitu :
1. Metode,
2. Peralatan (tools),
3. Prosedur,
yang memungkinkan manajer mengontrol proses pengembangan software dan memberikan praktisi dasar yang
baik untuk pembentukan software berkualitas tinggi.
B
y

H
e
n
d
r
a
N
e
t
Page 8 / 146
1. Metode Software Enginnering
Metode software engineering memberikan tehnik-tehnik bagaimana membentuk software. Metode ini terdiri dari
serangkaian tugas :
Perencanaan & estimasi proyek
Analisis kebutuhan sistem dan software
Desain struktur data
Arsitektur program dan prosedur algoritma
Coding
Testing dan pemeliharaan
2. Peralatan Software Engineering
Peralatan software engineering memberikan dukungan atau semiautomasi untuk metode. Contohnya :
CASE (Case Aided Software Engineering), yaitu suatu software yang menggabungkan software, hard-
ware, dan database software engineering untuk menghasilkan suatu lingkungan software engineering.
Database Software Engineering, adalah sebuah struktur data yang berisi informasi penting tentang
analisis, desain, kode dan testing.
Analogi dengan CASE pada hardware adalah : CAD, CAM, CAE
3. Prosedur Software Engineering
Terdiri dari :
urut-urutan di mana metode tersebut diterapkan
dokumen
laporan-laporan
formulir-formulir yang diperlukan
mengontrol kualitas software
mengkoordinasi perubahan yang terjadi pada software
Dalam penguasaan atas model software engineering atau software engineering paradigm, dikenal ada 3 metode
yang luas dipergunakan, yaitu :
1. Classic Life Cycle Pradigm - Model Water Fall - Model Siklus Hidup Klasik
SISTEM ENGINEERING
ANALYS
DESIGN
CODE
TESTING
MAINTENANCE
Keterangan :
A. System Engineering and Analysis
Karena software merupakan bagian terbesar dari sistem, maka pekerjaan dimulai dengan cara menerapkan
kebutuhan semua elemen sistem dan mengalokasikan sebagian kebutuhan tersebut ke software.
B
y

H
e
n
d
r
a
N
e
t
Page 9 / 146
Pandangan terhadap sistem adalah penting, terutama pada saat software harus berhubungan dengan ele-
men lain, seperti :
Hardware
Software
Database
B. Analisis kebutuhan software
Suatu proses pengumpulan kebutuhan software untuk mengerti sifat-sifat program yang dibentuk software
engineering, atau analis harus mengerti fungsi software yang diinginkan, performance dan interface
terhadap elemen lainnya. Hasil dari analisis ini didokumentasikan dan direview / dibahas / ditinjau
bersama-sama customer.
C. Design
Desain software sesungguhnya adalah proses multi step (proses yang terdiri dari banyak langkah) yang
memfokuskan pada 3 atribut program yang berbeda, yaitu :
Struktur data
Arsitektur software
Rincian prosedur
Proses desain menterjemahkan kebutuhan ke dalam representasi software yang dapat diukur kualitasnya
sebelum mulai coding. Hasil dari desain ini didokumentasikan dan menjadi bagian dari konfigurasi
software.
D. Coding
Desain harus diterjemahkan ke dalam bentuk yang dapat dibaca oleh mesin
E. Testing
Segera sesudah objek program dihasilkan, pengetesan program dimulai. Proses testing difokuskan pada logika
internal software. Jaminan bahwa semua pernyataan atau statements sudah dites dan lingkungan external
menjamin bahwa definisi input akan menghasilkan output yang diinginkan.
F. Maintenance
Software yang sudah dikirim ke customer data berubah karena
Software mengalami error
Software harus diadaptasi untuk menyesuaikan dengan lingkungan external, misalnya adanya sistem
operasi baru atau peripheral baru.
Software yang lebih disempurnakan karena adanya permintaan dari customer.
Masalah yang dihadapi dari model siklus hidup klasik adalah :
Proyek yang sebenarnya jarang mengikuti aliran sequential yang ditawarkan model ini. Iterasi
(Pengulangan) selalu terjadi dan menimbulkan masalah pda aplikasi yang dibentuk oleh model ini.
Seringkali pada awalnya customer sulit menentukan semua kebutuhan secara explisit (jelas).
Customer harus sabar karena versi program yang jalan tidak akan tersedia sampai proyek software sele-
sai dalam waktu yang lama.
B
y

H
e
n
d
r
a
N
e
t
Page 10 / 146
2. Prototype Paradigm
REQUIMENTS GATHERING
"QUICKDESIGN"
BUILD PROTOTYPE
EVALUATED AND REFINEMENTS
ENGINEER PRODUCT
Keterangan :
Seringkali seorang customer sulit menentukan input yang lebih terinci, proses yang diinginkan dan output yang
diharapkan. Tentu saja ini menyebabkan developer tidak yakin dengan efisiensi alogoritma yang dibuatnya,
sulit menyesuaikan sistem operasi, serta interaksi manusia dan mesin yang harus diambil. Dalam hal seperti
ini, pendekatan prototype untuk software engineering merupakan langkah yang terbaik. Prototype sebenarnya
adalah suatu proses yang memungkinkan developer membuat sebuah model software.
Ada 2 bentuk dari model ini, yaitu :
A. Paper Prototype
Menggambarkan interaksi manusia dan mesin dalam sebuah bentuk yang memungkinkan user mengerti
bagaimana interaksi itu terjadi.
B. Working Prototype
Adalah prototype yang mengimplementasikan beberapa bagian dari fungsi software yang diinginkan seperti
pada pendekatan pengembangan software. Model ini dimulai dengan :
Pengumpulan kebutuhan developer dan customer
Menentukan semua tujuan software
Mengidentifikasi kebutuhan-kebutuhan yang diketahui
Hasil dari pengumpulan kebutuhan diteruskan pada Quick Design. Quick Design ini memfokuskan pada
representasi aspek-aspek software yang dapat dilihat oleh user, misalnya format input dan output,
selanjutanya dari desain cepat diteruskan pada pembentukan prototype (langkah ke 3). Prototype ini
dievaluasi oleh customer / user dan digunakan untuk memperbaiki kebutuhan-kebutuhan software. Proses
iterasi terjadi agar prototype yang dihasilkan memenuhi kebutuhan customer, juga pada saat yang sama
developer mengerti lebih baik tentang apa yang harus dikerjakan.
Masalah yang dihadapi oleh prototyping paradigm ini adalah :
Customer hanya melihat pada apa yang dihasilkan oleh software, tidak peduli pada hal-hal yang ber-
hubungan dengan kualitas software dan pemeliharaan jangka panjang.
Developer seringkali menyetujui apa yang diterangkan oleh customer agar prototype dapat dihasilkan
dengan cepat. Akibatnya timbul pemilihan sistem operasi / bahasa pemrograman yang tidak tepat.
3. Fourth Generation Tehnique Paradigm - Model tehnik generasi ke 4 / 4GT
REQUIMENTS GATHERING
"DESIGN STRATEGICS"
IMPLEMENTATION USING 4GT
PRODUCT
B
y

H
e
n
d
r
a
N
e
t
Page 11 / 146
Istilah Fourth Generation Technique (4GT) meliputi seperangkat peralatan software yang memungkinkan seorang
developer software menerapkan beberapa karakteristik software pada tingkat yang tinggi, yang kemudian
menghasilkan source code dan object code secara otomatis sesuai dengan spesifikasi yang ditentukan
developer. Saat ini peralatan / tools 4GT adalah bahasa non prosedur untuk :
DataBase Query
Pembentukan laporan ( Report Generation )
Manipulasi data
Definisi dan interaksi layar (screen)
Pembentukan object dan source ( Object and source generation )
Kemampuan grafik yang tinggi, dan
Kemampuan spreadsheet
Keterangan gambar :
Model 4GT untuk software engineering dimulai dengan rangkaian pengumpulan kebutuhan. Idealnya,
seorang customer menjelaskan kebutuhan-kebutuhan yang selanjutnay diterjemahkan ke dalam prototype.
Tetapi ini tidak dapat dilakukan karena customer tidak yakin dengan apa yang diperlukan, tidak jelas
dalam menetapkan fakta-fakta yang diketahui dan tidak dapat menentukan informasi yang diinginkan oleh
peralatan 4GT.
Untuk aplikasi kecil adalah mungkin bergerak langsung dari langkah pengumpulan kebutuhan ke im-
plementasi yang menggunakan bahasa non prosedur fourth generation (generasi ke 4). Tetapi untuk
proyek besar, pengembangan strategi desain sistem tetap diperlukan, sekalipun kita menggunakan 4GL.
Penggunaan 4GT tanpa desain untuk proyek besar akan menyebabkan masalah yang sama yang ditemui
dalam pengembangan software yang menggunakan pendekatan konvensional.
Implementasi yang menggunakan 4GL memungkinkan developer software menjelaskan hasil yang diing-
inkan yang kemudian diterjemahkan ke dalam bentuk source code dan object code secara otomatis.
Langkah yang terakhir adalah mengubah implementasi 4GT ke dalam sebuah product. Selanjutnya de-
veloper harus melakukan pengetesan, pengembangan dokumentasi dan pelaksanaan semua aktifitas
lainnya yang diwujudkan dalam model software engineering.
Masalah yang dihadapi dalam model 4GT adalah adanya sebagian orang yang beranggapan bahwa :
A. peralatan 4GT tidak semudah penggunaan bahasa pemrograman,
B. source code yang dihasilkan oleh peralatan ini tidak efisien,
C. pemeliharaan sistem software besar yang dikembangkan dengan 4GT masih merupakan tanda tanya.
4. Model Kombinasi - Combining Paradigm
REQUIMENTS
GATHERINGS
PROTOTYPING
PROTOTYPE
APPLY
4GL
EVALUATE
ENGINEER
PRODUCT
CLASSIC LIFE
CYCLE
DAPAT LANGSUNG JIKA PENDEKATANNYA JELAS
Keterangan :
Model ini menggabungkan keuntungan-keuntungan dari beberapa model sebelumnya. Seperti pada model
sebelumnya, model kombinasi ini dimulai dengan langkah pengumpulan kebutuhan.
B
y

H
e
n
d
r
a
N
e
t
Page 12 / 146
Pendekatan yang dapat diambil adalah pendekatan siklus hidup klasik (Analisis sistem dan analisis kebutuhan
software) atau dapat juga menggunakan pendekatan seperti prototyping jika definisi masalahnya tidak terlalu
formal.
Jika kebutuhan untuk fungsi dan performance software diketahui dan dimengerti, pendekatan yang dianjurkan
adalah model siklus hidup klasik. Sebaliknya, jika aplikasi software menuntut interaksi yang sering antara
manusia dan mesin, membutuhkan algoritma yang tidak dapat dibuktikan, atau membutuhkan tehnik output /
kontrol, maka pendekatan yang dianjurkan adalah model prototyping.
Pada kasus seperti ini, 4GL dapat digunakan untuk mendapat prototype dengan cepat. Segera sesudah prototype
dievaluasi dan disempurnakan, langkah desain dan implementasi dalam siklus hidup klasik diterapkan.
Dari model yang disebut di atas dapat diambil suatu kesimpulan, bahwa proses pengembangan software terdiri
dari 3 fase, yaitu :
1. Fase Definisi
2. Fase Pengembangan (Development)
3. Fase Pemeliharaan (Maintenance)
1. Fase Definisi
Fase definisi memfokuskan pada What. Selama definisi ini, developer software berusaha untuk :
Mengidentifikasi informasi apa yang dikerjakan proses
Fungsi dan performance apa yang diinginkan
Interface apa yang dibutuhkan
Hambatan desain apa yang ada, dan
Kriteria validasi apa yang dibutuhkan untuk menetapkan keberhasilan sistem.
A. Sistem Analis
Sistem analis menetapkan peranan dari setiap elemen dalam sistem berbasis komputer, terutama menga-
lokasikan peranan software.
B. Sistem Software Planning
Dalam sistem ini, setelah lingkungan software dialokasikan, maka langkah dari sistem software planning ini
adalah :
Pengalokasian sumber / resource
Estimasi biaya
Penetapan tugas pekerjaan dan jadual.
C. Requirement Analysis
Penetapan lingkup untuk software memberikan petunjuk / arah. Namun definisi yang lebih rinci dari in-
formasi dan fungsi software diperlukan sebelum pekerjaan dimulai.
2. Fase Pengembangan
Fase pengembangan berfokus pada How. Selama pengembangan, developer software berusaha menjelaskan :
Bagaimana struktur data dan arsitektur software yang didesain
Bagaimana rincian prosedur diimplementasikan ( diterapkan )
Bagaimana desain diterjemahkan ke dalam bahasa pemrograman atau bahasa non prosedur, dan
Bagaimana pengetesan akan dilaksanakan.
B
y

H
e
n
d
r
a
N
e
t
Page 13 / 146
A. Desain software ( Software Design )
Desain menterjemahkan kebutuhan-kebutuhan software ke dalam sekumpulan representasi (grafik, tabel,
diagram, atau bahasa yang menjelaskan struktur data, arsitektur software dan prosedur algoritma).
B. Coding
Representasi desain harus diterjemahkan ke dalam bahasa tiruan / artificial language yang menghasilkan
perintah-perintah yang dapat dieksekusi oleh komputer.
C. Software Testing
Segera sesudah software diimplementasikan dalam bentuk yang dapat dieksekusi oleh mesin, software perlu
ditest untuk menemukan kesalahan ( merupakan fungsi logika dan implementasi ).
3. Fase Pemeliharaan
Fase pemelihaaan berfokus pada Change atau perubahan. Ini dapat disebabkan :
A. Perubahan karena software error ( Corective Maintenance )
B. Perubahan karena software disesuaikan / diadaptasi dengan lingkungan external, misalnya munculnya
CPU baru, sistem operasi baru ( Adaptive Maintenance )
C. Perubahan software yang disebabkan customer / user meminta fungsi tambahan, misalnya fungsi grafik,
fungsi matematik, dll ( Perfective Maintenance )
B
y

H
e
n
d
r
a
N
e
t
Page 14 / 146
BAB II
COMPUTER SYSTEM ENGINEERING
Computer system engineering (Rekayasa Sistem Komputer) terdiri atas 2 bagian, yaitu :
1 Hardware engineering
1 Software engineering
Setiap disiplin ini berusaha menunjukkan pengembangan sistem berbasis komputer tehnik engineering. Untuk
hardware komputer telah sedemikian maju dan relatif jenuh. Sebaliknya software komputer mulai berkembang,
dan saat ini menggantikan peranan hardware sebagai elemen sistem yang sulit direncanakan, sedikit kemungkinan
untuk berhasil dengan biaya rendah dan waktu yang cepat, serta paling sukar untuk dikelola.
Apa Sistem itu ?
Sistem adalah sekumpulan elemen yang saling berinteraksi untuk mencapai suatu tujuan. Sedangkan Computer
Based System diorganisir untuk mendapatkan beberapa metode, prosedur atau pengontrolan dengan cara
mengelola informasi.
Elemen-elemen dari sistem berbasis komputer adalah :
1. Software
Program komputer, struktur data dan dokumentasi yang saling berhubungan dan memberikan efek pada metode,
prosedur dan kontrol yang diinginkan.
2. Hardware
Peralatan elektronik, (misalnya CPU, memory) yang memberikan kemampuan komputasi serta peralatan
elektromedia (misalnya sensor, motor, pompa) yang memberikan fungsi external.
3. People / Brainware
User dan operator dari hardware dan software
4. Database
Sekumpulan informasi yang besar, yang diorganisir agar dapat diakses oleh software dan merupakan bagian
integral dari fungsi sistem.
5. Prosedur
Langkah-langkah yang menetapkan pemakaian khusus untuk setiap elemen sistem.
INPUT OUTPUT
DATABASE
PROCEDURE
HARDWARE
SOFTWARE
PEOPLE
DOCUMENT
SYSTEM
Keterangan :
B
y

H
e
n
d
r
a
N
e
t
Page 15 / 146
Computer system engineering adalah suatu aktifitas pemecahan masalah fungsi sistem yang
diinginkan, ditemukan, dianalisis, dan dialokasikan ke elemen-elemen sistem individu.
Computer System Engineering disebut juga Sistem Analis, dimulai dengan :
1. Penetapan tujuan customer
2. Hambatan-hambatan dan representasi fungsi performance yang dapat dialokasikan ke masing-masing elemen
sistem.
Segera setelah fungsi performance, hambatan dan interface ditetapkan, system engineering selanjutnya melakukan
pekerjaan alokasi. Selama pengalokasian fungsi diserahkan kepada satu / lebih elemen sistem (misalnya software,
hardware, people, dll) seringkali alokasi alternatif diusulkan dan dievaluasi.
Fungsi yang dialokasikan maksudnya adalah menentukan mana yang masuk ke hardware, ke software dan ke
brainware
Berikut ini adalah kriteria pemilihan konfigurasi sistem berdasarkan alokasi fungsi dan performance ke elemen
sistem :
1. Project Consideration - Pertimbangan Proyek
1 Dapatkah konfigurasi dihasilkan dengan biaya dan jadual yang ditetapkan lebih awal ?
2. Business Consideration - Pertimbangan Bisnis
1 Dapatkah konfigurasi memberikan solusi yang paling menguntungkan ?
1 Dapatkah dipasarkan dengan sukses ?
Pertimbangan ini yang paling penting.
3. Technical Consideration - Pertimbangan tehnik
1 Apakah ada tehnologi untuk mengembangkan semua elemen sistem ?
1 Dapatkah fungsi performance dijamin ?
1 Dapatkah konfigurasi dipelihara dengan cukup baik ?
4. Manufacturing Evaluation - Evaluasi Pabrikasi
1 Apakah fasilitas dan peralatan manufaktur tersedia ?
1 Apakah ada komponen yang diperlukan dengan segera ?
1 Apakah jaminan kualitas dapat dipercaya ?
5. Human Issues - Hal-hal yang berhubungan dengan manusia
1 Apakah tenaga kerja terlatih untuk pengembangan dan manufaktur tersedia ?
1 Apakah customer mengerti dengan apa yang akan dicapai oleh sistem ?
6. Environmental Interface - Berhubungan dengan lingkungan
1 Apakah konfigurasi yang diusulkan sudah cukup berhubungan dengan lingkungan external dari sistem ?
1 Apakah komunikasi mesin manusia dan manusia mesin sudah ditangani dengan baik ?
7. Legal Consideration - Pertimbangan hukum
1 Apakah pertimbangan yang dihasilkan sudah dilindungi oleh hukum ?
PERTIMBANGAN HARDWARE
Computer System Engineering selalu mengalokasikan satu / lebih fungsi sistem ke hardware komputer.
Elemen-elemen hardware
1. CPU - Cenral Processing Units
B
y

H
e
n
d
r
a
N
e
t
Page 16 / 146
2. Adalah unit yang melakukan pekerjaan aritmatik, logika, dan fungsi pengontrol serta
berinteraksi dengan komponen lainnya. Sekarang ini, beberapa arsitektur komputer ditambahkan ko-prosesor
untuk melakukan fungsi pengolahan khusus ( fungsi kalkulasi ) sehingga performance CPU dapat
ditingkatkan.
3. BUS
4. Adalah alat komunikasi yang menghubungkan elemen satu dengan elemen lainnya untuk pengiriman instruksi,
data dan informasi pengontrolan.
5. Memory
6. Memory memberikan tempat penyimpanan instruksi dan data yang dapat diakses langsung / tidak langsung
melalui perintah yang dieksekusi oleh CPU dan ko-prosesornya.
Memory terbagi menjadi 2 bagian, yaitu :
A. Memori Primer / Primary Memory / Main Memory
Adalah memory yang terdapat di dalam komputer, terdiri atas 2 bagian yaitu :
i. RAM - Random Access Memory
Untuk menyimpan data / instruksi yang bersifat temporary
ii. ROM - Read Only Memory / Firmware
Untuk menyimpan perintah dan / atau data yang permanen.
ROM terbagi atas 2 golongan
a. PROM - Programmabel Read Only Memory
Memory ROM yang dapat ditulis / diprogram dan dapat dihapus dengan cara :
1 EEPROM - Eraseble Electrical Programmabel ROM
Dihapus dengan kejutan listrik tertentu
1 UVPROM - Ultra Violet Programmabel ROM
Dihapus dengan sinar ultra violet
b. MASK ROM
ROM yang terjual sudah diprogram pada saat dibuat oleh pabriknya.
B. Memory Sekunder
Sifat yang menonjol dari memory jenis ini adalah :
i. Waktu akses lambat
ii. Kapasitas besar sekali dibandingkan dengan memory primer
iii. Waktu akses berkisar milidetik dengan kapasitas antara 400.000 sampai 1 billion byte
iv. Contoh : Floppy disk, harddisk, hardcard, optical disk
APLIKASI HARDWARE
Dapat dikelompokan dalam 3 bagian besar, yaitu :
1. Pengelolahan informasi
2. Pengontrolan proses dan aplikasi real time
3. Tambahan intelegensi
REKAYASA HARDWARE
Untuk komputer digital yang dikembangkan dari perancangan elektronik, proses perancangannya terdiri dari 3
tahap :
1. Perencanaan dan spesifikasi
B
y

H
e
n
d
r
a
N
e
t
Page 17 / 146
2. Perencanaan dan implementasi prototype
3. Manufaktur distribusi dan pelayanan
Segera / sesudah analisis dan definisi dijalankan, fungsi dialokasikan ke hardware.
Fase I : Perencanaan dan Spesifikasi
HARDWARE
FUNCTION
DEVELOPMENT
PLANNING
COST
SCHEDULE
REVIEW
DETAILED
REQUIRMENT
ANALYSIS
HARDWARE
SPECIFICATION
REVIEW
Fase I terdiri dari :
1. Perencanaan pengembangan
2. Analisis hardware
Perencanaan pengembangan dilaksanakan untuk menetapkan lingkup-lingkup dari usaha-usaha terhadap
hardware, oleh karena itu menimbulkan beberapa pertanyaan, antara lain :
1. Jenis hardware apa yang terbaik untuk fungsi yang ditentukan?
2. Hardware yang mana yang tersedia untuk dijual, bagaimana biayanya, jenis interface yang diperlukan, dan
apa yang harus dilakukan untuk merancang dan membangun ?
Fase II : Perencanaan dan Implementasi Prototype
DESIGN
ANALYSIS
REVIEW
BUILT & TEST
PROTOTYPE
REVIEW
MANUFACTURING
ANALYSIS
PROTOTYPE
( BELUM SEMPURNA )
DESIGN DRIVING
Kebutuhan analisis dan konfigurasi hardware mulai dirancang, dilakukan tinjauan tehnis demi mendapatkan
spesifikasi rancangan yang benar. Komponen mulai dibuat dan prototype mulai diralat. Prototype diuji untuk
menjamin bahwa prototype telah memenuhi semua persyaratan. Namun prototype sering menghadapi
ketidakmiripan dengan prosedur yang dibuat. Karena itu perlu adanya spesifikasi pabrikasi
Fase III : Manufacture Distribution dan Pelayanan
B
y

H
e
n
d
r
a
N
e
t
Page 18 / 146
MANUFACTURE
QUALITY
ASSURANCE
NETWORK REVIEW
DISTRIBUTION
MAINTENANCE
ORANIZATION
SPARE PART
PRODUCTS
Mulai dihasilkan prosedur-prosedur dengan penekanan pada kualitas produk. Dengan mekanisme distribusi
produk terhadap fase ini, juga dibentuk bagian perbaikan dan maintenance
PERENCANAAN SISTEM
Tahap perencanaan dari siklus hidup software adalah suatu proses definisi, analis, spesifikasi, estimasi dan
review.
SYSTEM
DEFINITION
BUSINESS
NEEDS
SOFTWARE
PLAN
REQUIRE-
MENT
ANALYSIS
HARDWARE
FUNCTIONS
SOFTWARE
FUNCTIONS
COST SCHEDULE
RESOURCES
SOFTWARE
SCOPE
Definisi sistem merupakan langkah pertama dalam fase perencanaan.
Tujuan dari definisi sistem ini adalah :
1. Evaluasi konsep sistem : feasibility, cost benefit, dan businness needs
2. Jelaskan interface, function, dan performance sistem
3. Alokasi fungsi pada hardware, software dan elemen tambahan.
Tujuan dari perencanaan software adalah mengestimasi biaya dan waktu pengembangan. Untuk mencapai ini,
lingkup software harus dimengerti dengan sempurna, dan sumber harus ditentukan dengan tepat.
Analisis kebutuhan software memperjelas :
1. Software interfaces
2. Atribut fungsional
3. Karakteristik performance
4. Kendala desain
5. Kriteria validasi
Timbul pertanyaan :
1. Berapa besar usaha yang akan diberikan pda fase perencanaan ?
10
s
/
d
20 % dari usaha keseluruhan proyek diberikan pada perencanaan dan analisis kebutuhan software.
B
y

H
e
n
d
r
a
N
e
t
Page 19 / 146
2. Siapa yang mengerjakannya ?
Analis yang berpengalaman dan terlatih memperkerjakan hampir semua pekerjaan yang berhubungan dengan
fase perencanaan. Untuk proyek yang sangat besar, dapat dibentuk sebuah tim analis.
3. Mengapa begitu sulit ?
Konsep yang tidak jelas harus ditransformasikan ke dalam elemen yang jelas.
FEASIBILITY STUDI ( STUDI KELAYAKAN )
Semua proyek layak bila sumber dan waktunya tidak terbatas. Kenyataannya, pengembangan sistem berbasis
komputer dibatasi oleh sumber dan waktu.
Ada 4 bidang utama yang menjadi konsentrasi dari feasibility studi, yaitu :
1. Economic Feasibility :
Evaluasi biaya (cost) dan manfaat (benefit) dalam pengembangan sistem.
2. Tehcnical feasibilitu :
Studi tentang fungsi, performance, dan hambatan yang berpengaruh terhadap kemampuan mendapatkan sistem
yang baik.
3. Legal Feasibility :
Penentuan berbagai pelanggaran, kewajiban yang dapat terjadi dari pengembangan sistem.
4. Alternative :
Evaluasi sebagai alternatif untuk mengembangkan sistem
ANALISIS COST BENEFIT
Menggambarkan biaya pengembangan proyek dan mempertimbangkan keuntungan sistem, baik yang tangible
maupun intangible (dapat diukur dan tidak dapat diukur).
Analis cost benefit ini tergantung dari karakteristik sistem yang akan dikembangkan, ukuran relatif proyek
(besar kecil proyek), dan ROI (Return On Invesment) yang diharapkan dari proyek.
Keuntungan dari sistem baru selalu dibandingkan dengan keuntungan dari sistem yang ada.
Contoh soal :
Suatu CAD (Computer Aided Design) akan menggantikan cara manual dalam membuat gambar-gambah tehnik.
Misalkan :
1 t = waktu rata-rata menggambar = 4 jam
1 c = biaya gambar perjam = $20
1 n = banyaknya gambar pertahun = 8000
1 p = persentase gambar yang dihasilkan dengan sistem CAD = 60%
Penurunan waktu gambar menjadi
1
/
4
nya dengan adanya sistem CAD.
Jadi :
Biaya yang dapat ditekan (dihemat) sebesar :
96,000/thn = 60% 8000 20 4
4
1
=
4
1
= p n c t
Bila untuk sistem CAD harus dikeluarkan biaya sebesar :
B
y

H
e
n
d
r
a
N
e
t
Page 20 / 146
1 biaya pengembangan / membeli = $204,000,
1 biaya pemeliharaan = $32,000 per tahun,
maka masa pengembalian / payback periode dari proyek CAD ini adalah :
Biaya pengeluaran (cost ) = biaya penghematan ( benefit )
204,000 + x 32,000 = 96,000 x
64,000 x = 204,000
x = 3.2 tahun
Ini berarti setelah 3.2 tahun, barulah proyek CAD ini memberikan titik impas (break even). Setelah ini barulah
memberikan keuntungan.
Grafik :
3.2
204
307
M
A
S
A

K
E
U
N
T
U
N
G
A
N
(
P
R
O
F
I
T
)
M
A
S
A

K
E
R
U
G
I
A
N
(
L
O
S
S
)
BREAK EVEN
POINT
PENGHEMATAN DENGAN
SISTEM CAD
BIAYA DENGAN
SISTEM CAD
B
I
A
Y
A

P
E
N
G
H
E
M
A
T
A
N

(
D
A
L
A
M

R
I
B
U
A
N
)
PAYBACK PERIODE
(MASA PENGEMBALIAN)
TAHUN
PERENCANAAN SOFTWARE
Untuk melaksanakan pengembangan proyek software dan berhasil, kita harus mengerti :
1. Ruang lingkup pekerjaan yang dilakukan
2. Sumber yang diinginkan
3. Usaha dan biaya
4. Jadual yang dikehendaki
Perencanaan software adalah :
Langkah kedua dalam fase perencanaan, tetapi merupakan langkah pertama dalam proses rekayasa software
yang akan memberikan pengertian kepada 4 hal di atas.
Perencanaan software mengkombinasikan 2 tugas, yaitu :
1. Riset
B
y

H
e
n
d
r
a
N
e
t
Page 21 / 146
2. Estimasi
Tujuan perencanaan software :
Memberikan suatu kerangka yang memungkinkan manajer membuat estimasi yang beralasan tentang sumber,
biaya dan jadual.
Contoh soal :
Dari usaha ini, dihasilkan 2,900 LOC (banyaknya
baris program). 200 LOC digunakan simulasi, dan
testing tidak termasuk bagian dari software yang
dioperasikan.
Produktivitasnya : =
2700 LOC
9.0 per orang per bulan
= 300 LOC per orang per bulan.
Ada 4 orang software engineering yang masing-masing
mampu menghasilkan 4000 LOC per tahun.
Bila mereka dipekerjakan dalam 1 team, maka proyek ada 6 jalur komunikasi yang mungkin (communication
path). Setiap jalur komunikasi memerlukan waktu yang seharusnya digunakan untuk pengembangan Loding
sebesaar 240 LOC per tahun.
Bila proyek 1 tahun tersebut mengalami keterlambatan jadwal dan tinggal 1 bulan lagi, perlu penambahan 3
orang lagi kedalam team tersebut.
Bila dianggap terjadi pengurangan produktivitas team, untuk setiap jalur komunikasi adalah sama, baik untuk
pegawai lama dan baru.
Hitung berapa produktivitas team sebelum dan sesudah penambahan 3 orang tersebut, sekaligus jangka waktunya
berbeda !!!
Jawab :
Jalur komunikasi 4 orang ada 6 jalur (lihat gambar).
Produktivitas sebelum penambahan : = ( 4 4,000 ) - ( 240 6 ) = 16,000 - 1,440 = 14,560 LOC per tahun
Produktivitas setelah penambahan :
1 Jika jalur komunikasinya berbeda :
= ( ) ( ) ( ) 4 4000 3
4000
12
2 6 240 15
240
12
2 + + x
= 16000 + 2000 - ( 1440 + 600 )
= 18000 - 2040
= 16960
1 Jika jalur komunikasinya dianggap sama :
TUGAS USAHA,
per orang per bulan
Requirement 1.5
Design 3.0
Code 1.0
Test 3.5
Usaha yang dihasilkan 9.0
B
y

H
e
n
d
r
a
N
e
t
Page 22 / 146
= ( ) ( ) ( ) 4 4000 3
4000
12
2 6 240 15 + +
= 16000 + 2000 - ( 1440 + 3600 )
= 18000 - 5040
= 12960
PROSES DESAIN SOFTWARE
Desain dalam fase pengembangan merupakan langkah pertama, di mana fase pengembangan merupakan fase
kedua dalam siklus hidup software.
Segera sesudah kebutuhan software ditetapkan, dimulailah fase pengembangan yang terdiri dari 4 langkah
berbeda :
1. Desain awal (preliminary design)
2. Detailed Design (Desain primeir)
3. Coding
4. Testing
Aliran informasi selama fase pengembangan dapat dilihat pada gambar di bawah ini.
FUNCTIONAL
REQUIREMENT
PRELIMINARY
DESIGN
INFORMATION
FLOW& STRUCTURE DETAILED
DESIGN
SOFTWARE
STRUCTURE
CODE & UNIT
TEST
SOFTWARE
PROCEDURE
TESTING TESTED
MODULS
INTEGRATED
VALIDATED SOFTWARE
Kebutuhan software & aliran informasi ( Structure Information Software ) memulai langkah desain awal dengan
menggunakan 1 dari beberapa metode desain struktur software untuk dikembangkan. Struktur software yang juga
disebut Arsitektur Software ini menjelaskan tentang hubungan antar elemen utama dari sebuah program. Desain
terinci menterjemahkan elemen-elemen struktural ke dalam penjelasan software ( prosedur software ).
Source Code dihasilkan dan pengetesan awal dilakukan selama langkah pengkodean dan pengetesan unit hasilnya
berupa model-model program yang sudah ditest.
Langkah terakhir dalam fase pengembangan adalah dilakukannya pengetesan integrasi dan validasi.
Fase pengembangan paling sedikit menyerap 75% dari biaya software baru. Ini berarti pengambilan keputusan
dalam fase ini akan sangat mempengaruhi keberhasilan dalam implementasi software dan kemudahan dalam
pemeliharaan software.
B
y

H
e
n
d
r
a
N
e
t
Page 23 / 146
DEFECT APLICATION MODEL ( DAM )
LANGKAH SEBELUMNYA DARI
"PRELIMINARY DESIGN"
ERROR YANG
DILEWATKAN
ERROR YANG
DIPERKUAT DENGAN
FAKTOR PENGUAT X
ERROR BARU YANG
DIHASILKAN
PERSENTASE
EFISIENSI ERROR
YANG DAPAT
DIDETEKSI
ERROR YANG DITERUSKAN
KE LANGKAH BERIKUTNYA
DAM digunakan untuk memberikan gambaran tentang pembentukan dan pendeteksian error selama desain awal
dari Desain Terinci dan Pengkodean.
Dengan model ini, kita dapat membandingkan besarnya biaya yang dikeluarkan dengan adanya error, baik untuk
review maupun tanpa review.
B
y

H
e
n
d
r
a
N
e
t
Page 24 / 146
Contoh DAM tanpa REVIEW :
Cara Kerja :
2. 6 + ( 4 1,5 ) + 25 = 37
37 0% = 0
37 - 0 = 37
3. 40 + ( 27 3 ) + 25 = 116
116 20% = 2320% = 23,2 23
116 - 23 = 93
4. 93 + 0 + 0
93 50% = 4650% = 46,5 46
93 - 46 = 47
5. 46 + 0 + 0 = 46
46 50% = 2300% = 23
46 - 23 = 23
6. 23 + 0 + 0 = 23
23 50% = 1150% = 11,5 11
23 - 11 = 12
Contoh DAM dengan REVIEW :
0
10
70%
2
1*1.5
25
50%
5
10*3
25
60%
24
0
0
50%
12
0
0
50%
6
0
0
50%
6 12 24
5
10
15
2
1
3
(1)
PRELIMINARY
DESIGN
(2)
DETAILED
DESIGN
(3)
CODE / UNIT
TEST
(4)
INTEGRATED
TEST
(5)
VALIDATED
TEST
(6)
SYSTEM TEST
(3) (14) (36) (12) (6) (7)
3
ERROR LATEN
0
10
%
6
4*1.5
X=1.5
25
0%
10
27*3
X=3
25
20%
93
0
0
50%
46
0
0
50%
23
0
0
50%
23 46 93
10
27
37
6
4
10
(1)
PRELIMINARY
DESIGN
(2)
DETAILED
DESIGN
(3)
CODE / UNIT
TEST
(4)
INTEGRATED
TEST
(5)
VALIDATED
TEST
(6)
SYSTEM TEST
(0) (23) (47) (23) (12) (0)
11
B
y

H
e
n
d
r
a
N
e
t
Page 25 / 146
1. ( 10 + 0 ) 70% = 7
2. 5 + ( 1 1,5 ) + 25 = 28,5
28,5 50% = 1425% = 14,25 14
28,5 - 14 = 14,5 15
3. ( 10 3 ) + 5 + 25 = 60
60 60% = 3600% = 26
60 - 36 = 24
4. 0 + 0 + 24 = 24
24 50% = 1200% = 12
24 - 12 = 12
5. 12 + 0 + 0 = 12
12 50% = 600% = 6
12 - 6 = 6
6. 6 + 0 + 0 = 6
6 50% = 3
6 - 3 = 3
KEGIATAN BIAYA per
ERROR
NON
REVIEW
REVIEW
Selama desain 1 0 x 1 = 0 21 x 1 = 21
Sebelum test ( coding ) 5 23 x 5 = 115 36 x 5 = 180
Selama test ( validated & integrated test ) 10 82 x 10 = 820 21 x 10 = 210
Setelah dipasarkan ( error laten ) 100 11 x 100 = 1100 3 x 100 = 300
Total biaya 2035 711
B
y

H
e
n
d
r
a
N
e
t
Page 26 / 146
Soal Latihan no. 1 :
Diketahui :
5 software engineering masing-masing mampu menyelesaikan 4000 LOC per tahun bila bekerja secara individu.
Mereka bekerja sama dalam 1 team. Bila proyek 1 tahun tersebut mengalami keterlambatan dan tinggal 1 bulan
lagi, perlu tambahan 1 software engineering lagi ke dalam team tersebut. Pengurangan produktivitas team untuk
setiap jalur komunikasi adalah sama ( 200 LOC per tahun ) untuk menunjuk adanya proses belajar bagi staff
baru.
Ditanya :
Hitung produktivitas team sebelum dan sesudah penambahan seorang software engineering !!!
Jawab :
P Sebelum :
= ( 4000 x 5 ) - ( 10 x 200 )
= 20000 - 2000 = 18000 LOC / tahun
P Sesudah
P Jalur sama :
= ( ) ( ) 5 4000 1
4000
12
1 10 200 5 200 + +
= { (20000+333,3) - 3000 }
= 20333,3 - 3000 = 17333,3 LOC / tahun
P Jalur beda :
= 20333 3 2000 5
200
12
1 , ( ) +
= 20333,3 - 2083,3 = 18250 LOC / tahun
B
y

H
e
n
d
r
a
N
e
t
Page 27 / 146
Soal Latihan No. 2a :
Gambar dan buatlah perbandingan biaya, baik untuk Review maupun NonReview dari ilustrasi berikut ini:
1. Pada tahap rancangan awal :
A. Kesalahan yang timbul = 10
B. Efisiensi dengan review = 70%
2. Pada tahap rancangan terinci :
A. Sebanyak 50%, kesalahan dilewatkan, sisanya diperkuat dengan faktor penguat = 2
B. Kesalahan baru yang muncul = 25
C. Efisiensi dengan review = 50%
3. Pada tahap coding / unit test
A. sebanyak 40% kesalahan dilewatkan, dan sisanya diperkuat dengan faktor penguat 3.
B. Efisiensi dengan review 80%, dan non review 50%.
C. Kesalahan baru yang muncul = 20%.
4. Pada tahap selanjutnya dilakukan perbaikan dengan efisiensi masing-masing = 50%
5. Biaya yang harus ditanggung untuk setiap kesalahan adalah :
A. Selama rancangan = 2 satuan harga
B. Sebelum test = 5 satuan harga
C. Selama test = 20 satuan harga
D. Setelah dipasarkan = 60 satuan harga
Jawab :
TABEL PERBANDINGAN BIAYA ANTARA DENGAN REVIEW & NON REVIEW
KEGIATAN BIAYA per
ERROR
NON
REVIEW
REVIEW
Selama desain
Sebelum test ( coding )
Selama test ( validated & integrated test )
Setelah dipasarkan ( error laten )
Total biaya
B
y

H
e
n
d
r
a
N
e
t
Page 28 / 146
Soal Latihan No. 2b :
Gambar dan buatlah perbandingan biaya, baik untuk Review maupun NonReview dari ilustrasi berikut ini:
1. Pada tahap rancangan awal :
A. Kesalahan yang timbul = 10
B. Efisiensi dengan review = 80%
2. Pada tahap rancangan terinci :
A. Sebanyak 60%, kesalahan dilewatkan, sisanya diperkuat dengan faktor penguat = 3
B. Kesalahan baru yang muncul = 20
C. Efisiensi dengan review = 40%
3. Pada tahap coding / unit test
A. sebanyak 30% kesalahan dilewatkan, dan sisanya diperkuat dengan faktor penguat 2.
B. Efisiensi dengan review 75%, dan non review 45%.
C. Kesalahan baru yang muncul = 25%.
4. Pada tahap selanjutnya dilakukan perbaikan dengan efisiensi masing-masing = 60%
5. Biaya yang harus ditanggung untuk setiap kesalahan adalah :
A. Selama rancangan = 3 satuan harga
B. Sebelum test = 10 satuan harga
C. Selama test = 30 satuan harga
D. Setelah dipasarkan = 70 satuan harga
Jawab :
TABEL PERBANDINGAN BIAYA ANTARA DENGAN REVIEW & NON REVIEW
KEGIATAN BIAYA per
ERROR
NON
REVIEW
REVIEW
Selama desain
Sebelum test ( coding )
Selama test ( validated & integrated test )
Setelah dipasarkan ( error laten )
Total biaya
B
y

H
e
n
d
r
a
N
e
t
Page 29 / 146
BAB III KONSEP MANAJEMEN PROYEK
3.1 SPEKTRUM MANAJEMEN
Manajemen proyek Perangkat Lunak (PL) yang efektif berfokus
pada 3 P, dimana harus berurut yaitu
PEOPLE : Elemen terpenting dari suksesnya proyek
PRODUCT /
PROBLEM
: Software yang dikembangkan
PROCESS : Suatu kerangka kerja dari suatu aktifitas dan
kumpulan tugas untuk memgembangkan PL
PROJECT
(tambahan)
: Penggabungan semua kerja untuk membuat
produk menjadi kenyataan
3.2 PEOPLE ( MANUSIA)
SEI telah mengembangkan suatu model kematangan kemampuan
manajemen manusia (People Management Capability Manurity
Model ( PM CMM ) ) untuk mempertinggi kesiapan organisasi PL
dalam membuat aplikasi yang semakin kompleks sehingga menarik,
menumbuhkan, memotivasi, menyebarkan dan memelihara bakat
yang dibutuhkan untuk mengembangkan kemapuan mengembankan
PL mereka.
B
y

H
e
n
d
r
a
N
e
t
Page 30 / 146
Model kematangan manajemen manusia membatasi pada
Rekruitmen
Seleksi
Manajemen unjuk kerja
Pelatihan
Kompensasi
Pemgembangan karir
Desain kerja & organisasi
Perkembangan karir tim /
kultur
Manusia dalam pengembangan PL terdiri dari :
a. Player (Pemain)
- Manajer Senior menentukan isu bisnis yang
mempengaruhi dalam proyek
- Manajer Proyek merencanakan, memotivasi, mengorga-
nisir,mengontrol aplikasi/produk
- Pelaksana mempunyai ketrampilan teknik untuk
merekayasa aplikasi
- Pelanggan menentukan jenis kebutuhan bagi PL
yang akan dibuat
- Pemakai akhir yang berinteraksi dengan PL yang
dibuat
b. Team Leader (Pimpinana Tim)
Manajemen proyek merupakan kegiatan manusia intensif
sehingga memerlukan praktisi yang cakap.
B
y

H
e
n
d
r
a
N
e
t
Page 31 / 146
Model Kepemimpinan (MOI yaitu Motivasi, Organisasi,
gagasan & Inovasi) menurut Jerry Weinberg.
Karakteristik yang menentukan manajer proyek efektif yaitu
- Pemecahan Masalah - Prestasi
- Identitas manajerial - Pengaruh & pembentukan tim
c. The Software Team ( Tim PL)
Sumber daya manusia kepada sebuah proyek yang akan
membutuhkan n manusia yang bekerja selama k tahun , ada
beberapa alternatif untuk menentukan sumber daya
tersebut :
- n orang mengerjakan tugas fungsional berbeda
sebanyak m dengan sedikit kombinasi kerja &
koordinasi tanggung jawab manajer proyek
- n orang mengerjakan tugas fungsional berbeda
sebanyak m (m<n) , seorang pemimpin tim ad hoc dapat
dipilih, koordinasi bertanggung jawab manajer PL
- n orang diatur di dalam tim , setiap orang mengerjakan
>= 1 tugas fungsional, setiap tim mempunyai sebuah
struktur spesifik yang ditentukan untuk semua tim
yang bekerja pada sebuah proyek, koordinasi dikontrol
B
y

H
e
n
d
r
a
N
e
t
Page 32 / 146
oleh tim itu sendiri dan oleh manajer proyek PL (
sistem ini paling produktif)
Mantei, mengusulkan 3 organisasi tim yaitu:
Demokrasi terdesentralisasi (DD)
Tidak memiliki pimpinan permanen dan koordinator dipilih
untuk tugas pendek bila tugas berbeda maka pimpinan
berbeda. Keputusan diambil oleh konsensus kelompok dan
komunikasi secara horizontal
Terkontrol terdesentralisasi (CD)
Tim memiliki pimpinan tertentu dan memiliki pimpinan
skunder untuk sub-sub masalah. Pemecahan masalah
merupakan aktifitas dari kelompok dan implentasi
pemecahan pada sub-sub kelompok. Komunikasi antar
kelompok dan orang bersifat horizontal tetapi komunikasi
secara vertical berjalan bila hirarki kontrol berjalan .
Terkontrol tersentralisasi (CC)
Pemecahan tingkat puncak dan internal tim oleh pimpinan
tim. Komunikasi dilakukan secara vertical.
7 faktor proyek yang harus dipertimbangkan dalam rencanakan
tim RPL yaitu :
1. Kesulitan pada masalah
B
y

H
e
n
d
r
a
N
e
t
Page 33 / 146
2. Ukuran program yang dihasilkan (LOC / function)
3. Waktu tim (umur)
4. Tingkat dimana dapat dimodularitasi
5. Kualitas serta keandalan
6. Kepastian tanggal penyampaian
7. Tingkat sosiabilitas / komunikasi
Pengaruh Karakteristik Proyek pada Struktur Tim
Tipe Tim DD CD CC
Tingkat Kesulitan
o Tinggi x
o Rendah x x
Ukuran
o Besar x x
o Kecil x
Umur Tim
o Singkat x x
o Panjang x
Modularitas
o Tinggi x x
o Rendah x
Keandalan
o Tinggi x x
o Rendah x
Tanggal Pengiriman
o Ketat/pasti x
o Longgar x x
Sosiabilitas
o Tinggi x
o Rendah x x
B
y

H
e
n
d
r
a
N
e
t
Page 34 / 146
Constantine, mengusulkan 4 paradigma organisasional bagi tim RPL
1. Paradigma Tertutup
Membentuk hirarki otoritas tradisional ( mirip tim CC) tetapi
kurang inovatif
2. Paradigma Random
Membentuk tim longgar & tergantung pada inisiatif individual
tim, untuk inovasi sangat baik(unggul) bila unjuk kerja tim
teratur.
3. Paradigma Terbuka
Membentuk tim dengan cara tertentu sehingga banyak
kontrol, inovasi banyak . Cocok untuk masalah yang kompleks
tetapi tidak seefesien tim lainnya
4. Paradigma Sinkron
Mengorganisasikan tim untuk bekerja pada bagian-bagian
kecil masalah dengan komunikasi aktif pada tim
d. Coordinatian & Communication Issue (masalah koordinasi &
komunikasi)
Proyek PL mengalami kesulitan dikarenakan :
Skala usaha pengembangan yang besar sehingga kesulitan
dalam mengkoordinasi anggota tim & Kompleksitas yang
semakin besar
B
y

H
e
n
d
r
a
N
e
t
Page 35 / 146
Ketidakpastian mengakibatkan perubahan terus menurus
pada proyek
Interoperabilitas merupakan ciri dari sistem dan
menyesuaikan dengan batasan sistem
Kraul & Streeter menguji sekumpulan teknik koordinasi
proyek yang dibagi atas
Pendekatan impersonal, formal penyampaian & dokumen
RPL (memo, laporan dll)
Prosedure interpersonal, formal aktifitas jaminan
kualitas yang diterapkan kepada produk kerja RPL
(status pengkajian , perancangan & inpeksi kode)
Prosedure interpersonal, informal pertemuan kelompok
untuk menyebarkan informasi & pemecahan masalah
serta pengembangan staf
Komunikasi teknik, surat elektronis, web sites,
teleconferens, papan buletin elektronik
Jaringan interpersonal diskusi informal pada orang
diluar proyek untuk mendapatkan pengalaman sehinnga
mendukung kerja proyek
B
y

H
e
n
d
r
a
N
e
t
Page 36 / 146
3.3 PROBLEM / PRODUCT
Analisis yang mendetail mengenai kebutuhan PL akan memberikan
informasi untuk menghitung perkiraan kuantitatif & perencanaan
organisasi. Tetapi itu sulit karena informasi yang diberikan
customer tidak lengkap.
Ruang lingkup masalah dibatasi dengan :
- Konteks
PL yang dibangun memenuhi sistem, produk / konteks bisnis
yang lebih besar serta batasan yang menentukan hasilnya
- Tujuan informasi
Objek pelanggan yang dihasilkan sbg output dr PL yang dapat
digunakan sebagai input
- Fungsi & unjuk kerja
PL digunakan untuk mentransformasikan input menjadi
output
Pernyataan ruang lingkup dibatasi (data jumlah pemakai simultan,
ukuran pengiriman, waktu mak respon ), batasan /& jangka waktu
dicatat (biaya produk membatasi jumlah memori) & factor mitigasi
(algoritma yang dibutuhkan software aplikasi (pemograman))
B
y

H
e
n
d
r
a
N
e
t
Page 37 / 146
Dekomposisi Masalah / pembagian masalah diterapkan pada :
- Fungsionalitas yang disampaikan
- Proses yang dipakai
3.4 PROCESS
Proses PL memberikan suatu kerangka kerja dimana rencana
komprehensip bagi pengembangan PL yang dapat dibangun dengan
- Sejumlah kumpulan tugas yang berbeda, kemampuan
penyampaian & jaminan kualitas
- Aktifitas pelindung, jaminan kualitas PL, manajemen
konfigurasi PL & pengukuran
Model PROSES :
1. Sekunsial Linier
Classic Life Cycle / model air terjun
2. Prototipe
Perencanaan kilat untuk konstruksi oleh prototype
3. Rapid Aplication Development (RAD)
Model sekunsial linier yang menekankan siklus pengembangan
yang sangat pendek dengan pendekatan konstruksi berbasis
komponen
4. Inkremental (Pertambahan)
Menggabungkan elemen-elemen model sekunsial linier dengan
filosopi prototype iterative khusus untuk staffing
B
y

H
e
n
d
r
a
N
e
t
Page 38 / 146
5. Spiral
Merangkai sifat iterative dari prototype dengan cara kontrol &
aspek sistematis dari sekunsial linier
6. Rakitan Komponen
Paradigma orientrasi obyek menekankan kreasi kelas yang
mengenkapsulasi data & algoritma yang dipakai untuk
memanipulasi data (gabungan dengan karakter spiral)
7. Perkembangan Komponen
Sering dipakai untuk mengembangkan aplikasi client server
Aktifitas dibagi menjadi :
- dimensi sistem : desain, assembly & pemakai
- dimensi komponen : desain & realisasi
8. Metode Formal
Mengkhususkan, mengembangkan, & menverifikasi sistem
berbasis komputer dengan notasi matematis yang tepat (Clean
room RPL)
9. Teknik Generasi Keempat
Serangkaian alat bantu PL yang secara otomatis memunculkan
kode sumber yang berdasarkan pada spesifikasi perekayasaan
1,2 3 (konvensional) sisanya evolusioner
Harus ditentukan model paling banyak memawakili pelanggan,
karakteristik produk & lingkungan proyek
Serangkaian aktifitas kerja PL :
1. Komunikasi pelanggan
2. Perencanaan
3. Analisa Resiko
4. Rekayasa
B
y

H
e
n
d
r
a
N
e
t
Page 39 / 146
5. Konstruksi dan rilis
6. Evaluasi Pelanggan
Dekomposisi Proses
Bila batasan waktu yang ketat diberikan dan masalah dapat
dipecah-pecah, model RAD mungkin pilihan yang paling tepat.
Tugas kerja yang actual bervariasi sehingga dekomposi proses
dimulai pada saat bagaimana menyesesaikan kerja proses secara
umum.
3.5 PROYEK
Profesional industri sering mengacu pada aturan 90-90 yaitu pada
saat mendiskusikan proyek PL yang sukar maka 90 % dr sistem
yang pertama menyerap 90 % dari usaha & waktu yang diberikan.
10 %terakhir mengambil 90 % lain dari usaha & waktu yang
diberikan.
Dr penyataan tersebut proyek mengalami kesulitan yaitu
1. Kemajuan mengalami kecacatan
2. Tidak ada cara untuk mengkalibrasi kemajuan karena tidak
memperoleh matrik kuantitatif
3. Rencana proyek belum dirancang untuk menakomodasi sumber
daya yang diperlukan pada akhir sebuah proyek
B
y

H
e
n
d
r
a
N
e
t
Page 40 / 146
4. Resiko-resiko belum mempertimbangkan secara eksplisit serta
belum dibuat rencana untuk mengurangi, mengatur & memonitor
5. Jadual yang ada tidak realistis & cacat
Untuk mengatasi masalah tersebut maka diperlukan waktu pada
awal proyek untuk membangun rencana yang realistis guna
memonitor rencana proyek selama berjalan & pada keseluruhan
proyek serta mengontrol kualitas serta perubahannya.
B
y

H
e
n
d
r
a
N
e
t
Page 41 / 146
BAB 4
PROSES PERANGKAT LUNAK & METRIK PROYEK
Lord Kelvin berkata :
Bila Anda dapat mengukur apa yg sedang Anda bicarakan dan
mengekspresikannya dalam angka, berarti Anda memahaminya.
Tujuan pengukuran perangkat lunak adalah :
Untuk menyatakan kualitas produk
Untuk menilai kulitas manusia yg terlibat dalam pembuatan produk.
Untuk menilai keuntungan pemakaian metode & alat bantu yg baru.
Sebagai dasar untuk melakukan perkiraan.
Untuk membantu penyesuaian pemakaian alat bantu yg baru atau
pelatihan tambahan.
Metrik perangkat lunak mengacu pada pengukuran perangkat lunak komputer.
Pengukuran digunakan untuk membantu perhitungan, kontrol kualitas,
perkiraan produktivitas, & kontrol proyek, serta untuk membantu mengambil
keputusan taktis pada saat proyek sudah berjalan.
PENGUKURAN, METRIK, DAN INDIKATOR
Measure (mengukur) :
Mengindikasikan kuantitatif dari luasan, jumlah, dimensi, kapasitas, atau
ukuran dari atribut sebuah proses atau produk.
Measurement (pengukuran) :
Kegiatan menentukan sebuah measure (pengukuran)
Metrics (metrik) :
Ukuran kuantitatif dari tingkat dimana sebuah sistem, komponen, atau proses
memiliki atribut tertentu.
RPL mengumpulkan pengukuran & mengembangkan metrik sehingga diperoleh
suatu indicator.
Indicator (indicator) :
Sebuah metrik atau kombinasi dari metrik yg memberikan pengetahuan
kedalam proses PL, sebuah proyek PL, atau produk itu sendiri.
B
y

H
e
n
d
r
a
N
e
t
Page 42 / 146
Indikator memberikan pengetahuan yang memungkinkan manajer proyek atau
perekayasa PL menyesuaikan proses, proyek, dan produk, untuk membuat
semuanya menjadi lebih baik.
METRIK DALAM PROSES DAN DOMAIN PROYEK
METRIK PROSES
METRIK PROYEK
Metrik harus dikumpulkan sehingga indikator proses dan indikator produk
(proyek) dapat dipastikan.
Indikator proses memungkinkan :
1. sebuah organisasi rekayasa PL memperoleh pengetahuan tentang
reliabilitas sebuah proses yg sedang berlangsung
2. manajer & pelaksana memperkirakan apa yg harus dikerjakan dan yang
tidak.
Indikator proyek memungkinkan manajer proyek PL :
1. memperkirakan status sebuah proyek yg sedang berlangsung
2. menelusuri resiko-resiko potensial
3. menemukan area masalah sebelum masalah menjadi semakin kristis.
4. menyesuaikan aliran kerja atau tugas-tugas.
5. mengevaluasi kemampuan tim proyek untuk mengontrol kualitas hasil
kerja RPL.
METRIK PROSES
Metrik proses digunakan untuk tujuan strategis.
Cara untuk meningkatkan proses perangkat lunak :
mengukur atribut tertentu dari proses
mengembangkan serangkaian metrik yg berarti
menggunakan metrik itu untuk memberikan indikator yg akan membawa
kepada sebuah strategi pengembangan.
B
y

H
e
n
d
r
a
N
e
t
Page 43 / 146
Produk
Karakteristik Kondisi
Pelanggan Bisnis
Manusia Teknologi
Gbr. Determinan untuk kualitas dan efektivitas organisasional PL.
Mengukur reliabilitas proses PL secara tidak langsung yaitu dengan mengambil
serangkaian metrik berdasarkan keluaran yg dapat diambil oleh proses.
Keluaran menyangkut :
pengukuran kesalahan yg ditemukan sebelum pelepasan PL.
cacat yg disampaikan & dilaporkan oleh pemakai akhir.
produk kerja yg dikirim.
usaha manusia yg dilakukan
waktu kalender yg digunakan
konfirmasi jadwal
dll
Pada saat organisasi menjadi lebih nyaman dengan kumpulan & manfaat metrik
proses, derivasi dari indikator sederhana memberikan suatu cara kepada suatu
pendekatan yg lebih teliti yg disebut SSPI (Statistical Software Process
I mprovement).
SSPI menggunakan analisis kegagalan PL untuk mengumpulkan informasi
seputar semua kesalahan & cacat yg terjadi pada saat sebuah aplikasi, sistem,
atau produk dikembangkan dan dipakai.
Kesalahan :
Ketidaksempurnaan pd sebuah produk kerja yg ditemukan oleh perekayasa PL
sebelum PL itu disampaikan kepada pemakai akhir.
Lingkungan
Pengembangan
Proses
B
y

H
e
n
d
r
a
N
e
t
Page 44 / 146
Cacat :
Ketidaksempurnaan pd sebuah produk kerja yg ditemukan oleh perekayasa PL
setelah PL itu disampaikan kepada pemakai akhir.
Analisis kegagalan bekerja dengan cara sbb. :
1. Semua kesalahan & cacat dikategorikan dari awal
2. Biaya untuk mengkoreksi setiap kesalahan & cacat dicatat.
3. Jumlah kesalahan & cacat dari setiap kategori dihitung dan ditata dalam
urutan naik.
4. Biaya keseluruhan dari kesalahan & cacat dalam setiap kategori dihitung.
5. Data resultan dianalisis untuk menemukan kategori yg menelan biaya
besar.
6. Rencana dikembangkan untuk memodifikasi proses guna mengeliminasi
kelas kesalahan & cacat yg paling membutuhkan banyak biaya.
Berdasarkan langkah 1&2 diatas, ditemukan ada 8 penyebab kerusakan dan
sumbernya :
Sumber spesifikasi/persyaratan :
a. Logic 20%
b. Penanganan data 10,5%
c. Standar 6,9%
Sumber desain :
a. Spesifikasi 25,5%
Sumber kode :
a. Interface perangkat lunak 6,0%
b. Interface perangkat keras 7,7%
c. Pemeriksaan kesalahan 10,9%
d. Interface pemakai 11,7%
METRIK PROYEK
Tujuan metrik proyek :
1. untuk meminimalkan jadwal pengembangan dengan melakukan
penyesuaian yg diperlukan untuk menghindari penundaan serta
mengurangi masalah & resiko potensial.
B
y

H
e
n
d
r
a
N
e
t
Page 45 / 146
2. untuk memperkirakan kualitas produk pada basis yg berlaku, dan bila
dibutuhkan, memodifikasi pendekatan teknis untuk meningkatkan
kualitas.
Pengukuran proyek PL bersifat taktis, yaitu bahwa metrik proyek & indikator
yg berasal dari pengukuran digunakan oleh manajer proyek dan tim PL untuk
mengadaptasi aliran kerja proyek & aktifitas teknis.
Selagi sebuah proyek berjalan, pengukuran usaha dan waktu kalender yg
digunakan dibandingkan dengan perkiraan awal (dan jadwal proyek).
Manajer proyek menggunakan data tersebut untuk memonitor & mengontrol
kemajuan.
Selagi PL berjalan dari spesifikasi ke perancangan, metrik teknik dikumpulkan
untuk memperkirakan kualitas desain serta memberikan indikator yg akan
mempengaruhi pendekatan yg akan diambil untuk memunculkan kode & modul
serta pengujian integrasi (integrated test).
Kualitas meningkat ---- kesalahan menjadi minimal
Biaya
berkurang
Kesalahan berkurang -- jumlah kerja ulang berkurang
Model lain dari metrik proyek mengusulkan bahwa setiap proyek seharusnya
mengukur :
input ( pengukuran sumber daya)
output (pengukuran kemampuan penyampaian atau produk kerja yg
diciptakan selama proses RPL)
hasil (pengukuran yg menunjukkan kemampuan penyampaian)
PENGUKURAN PERANGKAT LUNAK
Pengukuran perangkat lunak dibedakan menjadi dua yaitu :
Pengukuran langsung (direct)
o Metrik Size-Oriented
Pengukuran tidak langsung (indirect)
o Metrik Function-Oriented
o Metrik Function Point
B
y

H
e
n
d
r
a
N
e
t
Page 46 / 146
Yang diukur pada pengukuran langsung adalah :
Biaya
Pengaruh
Jumlah baris perintah (LOC) yg diproduksi
Kecepatan eksekusi
Ukuran memori
Kesalahan
Yang diukur pada pengukuran tidak langsung adalah :
fungsi
kualitas
kompleksitas
efisiensi
keandalan
kemampuan pemeliharaan
Metrik Size-Oriented
Proyek LOC Usaha Dolar halaman Kesalahan cacat Manusia
alpha 12,100 24 168 365 134 29 3
betha 27,200 62 440 1224 321 86 5
gamma 20,200 43 314 1050 256 64 6
Produktivitas = KLOC / usaha
Kualitas = kesalahan / KLOC
Biaya = biaya / KLOC
Dokumentasi = halaman / KLOC
Metrik size-oriented tidak diterima sebagai cara terbaik untuk mengukur proses
pengembangan perangkat lunak. Sebagian besar berkisar di seputar pemakaian
LOC.
B
y

H
e
n
d
r
a
N
e
t
Page 47 / 146
Metrik Function-Oriented
Metode pendekatan yg digunakan dapat disebut : Function Point (FP).
FP dihitung dgn melengkapi tabel dibawah ini :
Faktor pembobotan
Parameter
pengukuran
jumlah
sederhana
rata-
rata
kompleks
Jumlah input pemakai
X 3 4 6 =
Jumlah output pemakai
X 4 5 7 =
Jml penyelidikan pemki
X 3 4 6 =
Jumlah file
X 7 10 15 =
Jml interface internal
X 6 7 10 =
Total --------------------------------------------------------------------------------------
FP = jumlah total x [0,65 + 0,01 x jumlah(fi) ]
Jumlah(fi) didapat dari jumlah range jawaban dari 14 pertanyaan berikut :
1. apakah sistem membutuhkan backup & recovery yg reliable ?
2. apakah komunikasi data dibutuhkan ?
3. apakah fungsi pemrosesan didistribusikan ?
4. apakah kinerja penting
5. apakah sistem akan berjalan pd lingkungan operasional yg sudah ada yg
paling banyak digunakan ?
6. apakah sistem membutuhkan entry data online ?
7. apakah entry data online membutuhkan ada transaksi input terhadap layar
atau operasi ganda
8. apakah file master diperbarui secara online ?
9. apakah input, output, file, atau inquery kompleks ?
10.apakah pemrosesan internal kompleks ?
11.apakah kode didesain untuk dapat dipakai kembali ?
12.apakah desain melibatkan konversi dan instalasi
13.apakah sistem didesain untuk instalasi ganda dalam organisasi berbeda ?
B
y

H
e
n
d
r
a
N
e
t
Page 48 / 146
14.apakah aplikasi didesain untuk memfasilitasi perubahan & mempermudah
pemakai untuk menggunakannya ?
range jawaban (skala) untuk pertanyaan diatas antara 0 s/d 5 :
0 : tidak berpengaruh
1 : kurang penting
2 : cukup penting
3 : rata-rata
4 : penting
5 : sangat penting
Lima faktor penting yg mempengaruhi produktivitas perangkat lunak menurut
Basili dan Zelkowitz :
1. faktor manusia
2. faktor masalah
3. faktor proses
4. faktor produk
5. faktor sumber daya
Faktor faktor untuk mengukur kualitas perangkat lunak (4 metrik kualitas):
1. Cara yang benar
2. Maintanabilitas
3. Integritas
4. Usebilitas
Faktor faktor yang mempengaruhi biaya pengembangan PL :
1. kemampuan programmer dan tenaga kerja
2. kekompleksan produk
3. ukuran produk
4. waktu yang tersedia
5. keandalan yang diperlukan
6. teknologi yang dipergunakan
B
y

H
e
n
d
r
a
N
e
t
Page 49 / 146
BAB 5
PERENCANAAN PROYEK PERANGKAT LUNAK
Proses manajemen proyek perangkat lunak dimulai dengan kegiatan project
planning (perencanaan proyek). Yang pertama dari aktifitas ini adalah estimation
(perkiraan). Estimasi membawa resiko yang inheren (dari diri sendiri) dan resiko
inilah yang membawa ketidakpastian. Yang mempengaruhi estimasi :
- Project complexity (kompleksitas proyek)
- Project size (ukuran proyek)
- Struktural uncertainty (ketidakpastian struktural)
Tujuan Perencanaan Proyek Perangkat Lunak :
menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat
estimasi yang dapat dipertanggungjawabkan terhadap sumber daya, biaya dan
jadwal pada awal proyek yang dibatasi oleh waktu.
Aktifitas Perencanaan Proyek PL
1. Menentukan ruang lingkup PL
2. Mengestimasi sumber daya yang dibutuhkan
RUANG LINGKUP PL
Ruang lingkup PL menggambarkan : fungsi, kinerja, batasan, interface dan
reliabilitas.
Fungsi yang digambarkan dlm statemen ruang lingkup dievaluasi untuk
memberikan awalan yang lebih detail pada saat dimulai estimasi. Kinerja
melingkupi pemrosesan dan kebutuhan waktu respon. Batasan mengidentifikasi
batas yang ditempatkan pada PL oleh perangkat keras eksternal, memori atau
sistem lain.
B
y

H
e
n
d
r
a
N
e
t
Page 50 / 146
Informasi yang dibutuhkan (awal pertemuan antara pelanggan dan pengembang)
* Pertanyaan berfokus pada pelanggan, tujuan keseluruhan serta keuntungan.
- Siapa di belakang permintaan kerja ini?
- Siapa yang akan memakai solusi ini?
- Apakah keuntungan ekonomi dari solusi yang sukses?
- Adakah sumber daya lain bagi solusi ini?
* Pertanyaan yang memungkinkan analis memahami masalah lebih baik dan
pelanggan menyuarakan persepsi tentang sebuah solusi.
- Bagaimana Anda (pelanggan) menandai output yg baik yg akan dihasilkan
oleh sebuah solusi yg baik?
- Masalah apa yang dituju solusi ini?
- Dapatkah anda menggambarkan lingkungan dimana solusi akan dipakai?
- Adakah batasan atau isu kinerja khusus yg akan mempengaruhi
PL berinteraksi dengan elemen sistem berbasis komputer. Konsep sebuah
interface diinterpretasi untuk menentukan:
1. Hardware yg mengeksekusi PL dan device yg dikontrol secara tidak
langsung oleh PL
2. Software yg sudah ada dan harus dihubungkan dengan PL yg baru
3. Manusia yg menggunakan PL melalui keyboard atau perangkat I/O lain
4. Prosedur
SUMBER DAYA
1. Manusia
2. Perangkat Lunak
Kategori yg diusulkan BEUNATAN
- Komponen Off-the-self
- Komponen Full-Experience
- Komponen Partial-Experience
- Komponen Baru
3. Lingkungan (Software Engineering Environment - SEE), menggabungkan
PL dan Perangkat Keras.
B
y

H
e
n
d
r
a
N
e
t
Page 51 / 146
Estimasi biaya dan usaha dapat dilakukan dengan cara :
1. Menunda estimasi sampai akhir proyek.
2. Berdasarkan estimasi pada proyek yg mirip sebelumnya.
3. Menggunakan 'teknik dekomposisi' yg relatif sederhana u/ estimasi biaya
dan usaha proyek.
4. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya
PL.
Akurasi estimasi proyek PL didasarkan pada :
1. Tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk
yg akan dibuat.
2. Kemampuan mengestimasi ukuran ke dalam kerja manusia, waktu kalender,
dan dolar.
3. Tingkat dimana rencana proyek mencerminkan kemampuan tim PL.
4. Stabilitas syarat produk serta lingkungan yg mendukung usaha
pengembangan PL.
Putnam dan Myers mengusulkan 4 masalah penentuan ukuran :
- Fuzzy-logic sizing (logika kabur)
Perencana harus mengidentifikasi tipe aplikasi, membuat besarannya dalam
skala kuantitatif kemudian dibandingkan dengan rentang orisinil.
- Function point sizing
Perencana mengembangkan estimasi berdasarkan karakteristik domain
informasi.
- Standard component sizing
PL dibangun dari sejumlah 'komponen standar' yg umum (subsistem, modul,
laporan, program interaktif).
- Change sizing
Digunakan jika PL yang ada harus dimodifikasi dengan banyak cara sebagai
bagian dari proyek.
B
y

H
e
n
d
r
a
N
e
t
Page 52 / 146
Data baris kode (LOC) dan titik fungsi (FP) pada estimasi proyek digunakan sbg :
1. variabel estimasi yg dipakai untuk mengukur masing-masing elemen PL.
2. metrik baseline yg dikumpulkan dari proyek yg lalu dan dipakai dengan
variabel estimasi untuk mengembangakan proyeksi kerja dan biaya.
Expected Value untuk variabel estimasi :
EV = (S
opt
+ 4S
m
+ S
pess
) / 6
EV = Expected value
S
opt
= Estimasi optimistik
S
m
= Estimasi paling sering
S
pess
= Estimasi pesimistik
Apakah estimasi ini benar ? ' Kita tidak yakin!'
Bagaimanapun canggih teknik estimasi harus di-cross-check dengan pendekatan
lain.
Contoh estimasi berbasis LOC
PL CAD akan menerima data geometri dua dan tiga demensi dari seorang
perekayasa yang akan berinteraksi dan mengontrol sistem CAD melalui suatu
interface pemakai. Kajian spesifikasi sistem menunjukkan bahwa PL akan
mengeksekusi Workstation dan harus berinteraksi dengan berbagai periperal
grafis komputer spt mouse, digitizer dan printer laser.
Diketahui :
Perhitungan LOC untuk fungsi analisis geometri 3D (3DGA) :
optimis : 4600
most likely : 6900
pesimistik : 8600
EV = (4600 + 4*6900 + 8600) / 6
= 6800 LOC
B
y

H
e
n
d
r
a
N
e
t
Page 53 / 146
Jumlah tersebut dimasukkan ke dalam tabel, begitu juga untuk perhitungan yang
lain. Sehingga diperoleh :
Tabel perkiraan (estimasi) untuk metode LOC
Fungsi LOC terestimasi
interface pemakai & fasilitas kontrol (UICF) 2.300
analisis geometrik dua demensi (2DGA) 5.300
analisis geometrik tiga demensi (3DGA) 6.800
manajemen databse (DBM) 3.350
fasilitas display grafis komputer (CGDF) 4.950
kontrol periperal (PC) 2.100
modul analisis desain (DAM) 8.400
baris kode terestimasi 33.200
Jika :
Produktifitas rata-rata organisasional = 620 LOC/person-month
Upah karyawan = $8.000 per bulan
Biaya per baris kode = $13
Maka : Tingkat produktifitas = jumlah titik fungsi
jumlah orang-bulan
Jumlah karyawan = 33200 LOC = 53,5 54 orang
620 LOC/bln
Estimasi biaya proyek berdasar LOC
= 33.200 LOC * $ 13
= $ 431.600
Estimasi biaya proyek berdasar upah
= 54 orang * $8.000
= $432.000
B
y

H
e
n
d
r
a
N
e
t
Page 54 / 146
Estimasi berbasis FP (Function Point)
Dekomposisi untuk perhitungan berbasis FP berfokus pada harga domain info
daripada fungsi PL. Perencana proyek memperkirakan input, output, inquiry, file
dan interface eksternal. Untuk tujuan perkiraan tersebut faktor pembobotan
kompleksitas diasumsikan menjadi rata-rata.
Setiap faktor pembobotan kompleksitas diestimasi dan faktor penyesuaian
kompleksitas dihitung seperti dibawah ini :
Faktor Harga
Backup and recovery 4
Komunikasi data 2
Pemrosesan terdistribusi 0
Kinerja kritis 4
Lingkungan operasi yang ada 3
Entri data on-line 4
Transaksi input pada layar ganda 5
File master yang diperbarui on-line secara on-line 3
Nilai kompleks domain informasi 5
Pemrosesan internal yang kompleks 5
Kode yg didesain untuk dapat dipakai lagi 4
Konversi/instalasi dalam disain 3
Instalasi ganda 5
Aplikasi yg didesain bagi perubahan 5
Faktor penyesuaian kompleksitas 1.17
TOTAL 53.17
B
y

H
e
n
d
r
a
N
e
t
Page 55 / 146
Perkiraan harga domain informasi :
Tabel perkiraan harga domain informasi
nilai domain informasi opt likely pess jumlah
estimasi
bobot jumlah FP
jumlah input 20 24 30 24 4 96
jumlah output 12 15 22 16 5 80
jumlah inquiry 16 22 28 22 4 88
jumlah file 4 4 5 4 10 40
jumlah interface eksternal 2 2 3 2 7 14
jumlah total 318
jumlah estimasi (lihat rumus EV)
bobot (lihat kembali bab 4)
jumlah FP = jumlah estimasi * bobot
Total faktor pembobotan = F
i
= 53.17
Total FP = 318
FP terestimasi = jumlah total * ( 0.65 + 0.01 * F
i
)
= 318 * ( 0.65 + 0.01 * 53.17 )
= 375
Diketahui :
Produktifitas = 6.5 LOC/pm (dari historis)
Upah = $ 8.000/m
Biaya FP = $ 8.000 = $ 1.230
65 LOC
Estimasi biaya proyek
= Biaya FP * FP terestimasi
= $ 1.230 * 375
= $ 461.250
B
y

H
e
n
d
r
a
N
e
t
Page 56 / 146
Usaha terestimasi
= Total biaya = $ 461.250 = 58 p/m
upah/p $ 8.000
MODEL COCOMO
Barry Boehm memperkenalkan hirarki model estimasi PL dengan nama COCOMO
(COnstructive COst MOdel = Model Biaya Konstruktif) yang berbentuk sbb :
1. Model COCOMO Dasar
Menghitung usaha pengembangan PL (dan biaya) sbg fungsi dari ukuran
program yg diekspresikan dalam baris kode yg diestimasi (LOC).
2. Model COCOMO Intermediate
Menghitung usaha pengembangan PL sbg fungsi ukuran program dan
serangkaian 'pengendali biaya' yg menyangkut penilaian yg subyektif thd
produk, perangkat keras, personil dan atribut proyek.
3. Model COCOMO Advance
Menghubungkan semua karakteristik versi intermediate dg penilaian thd
pengaruh pengendali biaya pd setiap langkah (analis, perancangan, dll) dari
proses rekayasa PL.
Model COCOMO mendefinisikan 3 kelas proyek PL yi :
1. Model Organik
Ukuran proyek relatif kecil, PL yang dibuat atau dikembangkan lebih simpel
dengan aplikasi kerja yg baik. Misal program analisis termal yang
dikembangkan untuk kelompok transfer panas.
2. Model Semi Detached
Ukuran proyek dan kekompleksan perangkat cukup besar dengan
pengalaman kerja campuran (ada yg telah berpengalaman dan ada yg belum
berpengalaman). Misal sistem pemrosesan transaksi dengan syarat tertentu
untuk perangkat keras terminal dan perangkat lunak database.
3. Model Embedded
Ukuran proyek dan kekompleksan PL yg dikembangkan atau dikerjakan
besar. Misal perangkat lunak kontrol penerbangan untuk pesawat udara.
B
y

H
e
n
d
r
a
N
e
t
Page 57 / 146
Pesamaan COCOMO Dasar
b
b
E = a
b
(KLOC)
d
b
D = c
b
E
Dimana :
E = Effort (usaha yang diaplikasikan - pm)
D = waktu pengembangan (m)
KLOC = jumlah perkiraan baris kode (dalam ribuan)
a
b
, b
b
, c
b
, d
b
= koefisien (lihat tabel)
Tabel Model COCOMO Dasar
Proyek PL a
b
b
b
c
b
d
b
organik 2.4 1.05 2.5 0.38
semi-detached 3.0 1.12 2.5 0.35
embedded 3.6 1.20 2.5 0.32
Model dasar ini dapat diperluas dengan mempertimbangkan kumpulan 'atribut
pengendali biaya' yg dikelompokkan dalam 4 kategori utama :
1. Atribut produk
- ukuran keandalan proyek
- ukuran dari aplikasi database
- kekompleksan produk
2. Atribut perangkat keras
- kendala performansi run-time
- kendala memori
- lingkungan dari violability dari virtual memori
- waktu perputaran yg diperlukan
3. Atribut personil
- kemampuan sistem analis
- kemampuan software engineering
- pengalaman aplikasi
B
y

H
e
n
d
r
a
N
e
t
Page 58 / 146
- pengalaman virtual mesin
- pengalaman bahasa pemrograman
4. Atribut proyek
- pemakaian alat bantu PL
- metode aplikasi software engineering
- jadwal pengembangan
Masing-masing dari 15 atribut di atas dirata-rata dlm sebuah skala 6 titik dg
rentang dari 'sangat rendah' ke 'sangat tinggi' (dlm kepentingan atau harga).
Persamaan COCOMO Intermediate
b
i
E = a
i
(KLOC) * EAF
dimana :
EAF = Effort Adjusment Factor (faktor penyesuaian usaha)
yg mempunyai range antara 0.9 sampai 1.4
a
i
, b
i
= koefisien (lihat tabel)
Tabel Model COCOMO Intermediate
Proyek PL a
i
b
i
organik 3.2 1.05
semi-detached 3.0 1.12
embedded 2.8 1.20
B
y

H
e
n
d
r
a
N
e
t
Page 59 / 146
Contoh estimasi model COCOMO
Kita aplikasikan model dasar pada contoh PL CAD sebelumnya dengan koefisien
seperti pada tabel
b
b
E = a
b
(KLOC)
E = 2.4 (KLOC)
1.05
= 2.4 (33.2)
1.05
= 95 pm
Harga ini jauh lebih tinggi dibanding estimasi sebelumnya karena model
COCOMO mengasumsikan tingkat LOC/pm yang jauh lebih rendah.
Untuk menghitung durasi proyek :
d
b
D = c
b
E
D = 2.5 (E)
0.38
= 2.5 (95)
0.38
= 12.3 bulan
Harga durasi proyek memungkinkan perencana untuk menentukan jumlah orang
yang disetujui (N)
N = E/D
= 95/12.3
= 7,7 8 orang
Kenyataannya, perencana dapat memutuskan hanya menggunakan 4 orang saja
dan pemperpanjang durasi proyek.
Catatan : Hubungan antara usaha dan waktu tidak linier.
B
y

H
e
n
d
r
a
N
e
t
Page 60 / 146
KEPUTUSAN MAKE-BUY
Pada aplikasi PL, dari segi biaya sering lebih efektif membeli dari pada
mengembangkan sendiri. Manajer RPL dihadapkan pada keputusan make-buy
dengan pilihan :
1. PL dapat dibeli (atau lisensi) off-the-self.
2. Komponen PL full-experience dan partial-experience, dapat diperoleh dan
kemudian dimodifikasi dan integrasi untuk memenuhi kebutuhan sendiri.
3. PL dapat dibuat custom-built oleh kontraktor luar untuk memenuhi
spesifikasi pembeli.
Untuk produk PL yang mahal, langkah-langkah di bawah ini dapat dipetimbangkan:
1. Kembangkan spesifikasi untuk fungsi dan kinerja PL yg diperlukan.
2. Perkirakan biaya internal untuk pengembangan dan tanggal penyampaian.
3a. Pilih tiga atau empat calon aplikasi yang paling cocok dengan aplikasi
anda.
3b. Pilih komponen yang reusable yg dapat membantu konstruksi aplikasi yg
diperlukan.
4. Kembnagkan sebuah matriks perbandingan untuk membandingkan calon
PL.
5. Evaluasi masing-masing paket PL berdasarkan kualitas produk
sebelumnya, dukungan penjual, arah proyek, reputasi dsb.
6. Hubungi pemakai PL lain dan mintalah pendapat mereka.
Pada analisis akhir, keputusan make-buy berdasarkan kondisi sbb:
1. Tanggal penyampaian
2. Biaya yang diperlukan
3. Dukungan
B
y

H
e
n
d
r
a
N
e
t
Page 61 / 146
MEMBUAT POHON KEPUTUSAN
Rekayasa atau organisasi PL dapat menggunakan teknik statistik analisis pohon
keputusan dengan pilihan :
1. membangun sistem X dari permulaan
2. menggunakan lagi komponen partial experience yang ada untuk membangun
sistem
3. membeli sebuah produk perangkat lunak yang dapat diperoleh dan
dimodifikasi untuk memenuhi kebutuhan lokal
4. mengkontrakkan pengembangan PL ke vendor luar
Bila sistem dibangun dari permulaan, hanya 70% probabilitasnya sehingga
pekerjaan menjadi sulit. Perencana proyek dapat memproyeksikan usaha
pengembangan yang sulit berbiaya $450.000, usaha yang sederhana diperkirakan
berbiaya $380.000.
Expected value untuk biaya dihitung sepanjang cabang pohon keputusan, adalah :
Expected Cost = (jalur probabilitas)i * (biaya jalur terestimasi)i
dimana i adalah garis edar pohon keputusan.
Contoh :
expected cost
build
= 0.30 ($380 K) + 0.70 ($450 K) = $ 429 K
expected cost
reuse
= 0.40 ($275 K) + 0.60 (0.20 ($310 K) + 0.80 ($490 K))
= $ 382 K
expected cost
buy
= 0.70 ($210 K) + 0.30 ($400 K) = $ 267 K
expected cost
contract
= 0.60 ($350 K) + 0.40 ($500 K) = $ 410 K
Berdasar biaya probabilitas dan proyeksi, expected cost yang paling rendah
adalah pilihan buy
B
y

H
e
n
d
r
a
N
e
t
Page 62 / 146
Catatan : Banyak kriteria yang harus dipertimbangakan, bukan hanya biaya,
seperti pengalaman pengembang/ vendor/ kontraktor, penyesuaian
kebutuhan,kecenderungan perubahan dapat mempengaruhi keputusan akhir!
B
y

H
e
n
d
r
a
N
e
t
Page 63 / 146
BAB 6
Manajemen Resiko
Defenisi konseptual mengenai resiko : (Robert Charette)
1. Resiko berhubungan dengan kejadian di masa yg akan datang.
2. Resiko melibatkan perubahan (spt. perubahan pikiran,
pendapat, aksi, atau tempat)
3. Resiko melibatkan pilihan & ketidakpastian bahwa pilihan itu
akan dilakukan.
Strategi Resiko Reaktif vs Proaktif
Strategi reaktif memonitor proyek terhadap kemungkinan resiko.
Sumber
2
daya dikesampingkan, padahal seharusnya sumber
2
daya
menjadi masalah yang sebenarnya / penting.
Strategi proaktif dimulai sebelum kerja teknis diawali.
Resiko potensial diidentifikasi, probabilitas & pengaruh proyek
diperkirakan, dan diprioritaskan menurut kepentingan, kemudian
membangun suatu rencana untuk manajemen resiko.
Sasaran utama adalah menghindari resiko.
Resiko Perangkat Lunak
Karakteristik resiko :
1. Ketidakpastian
2. Kerugian
Kategori resiko :
Resiko proyek
Resiko teknis
Resiko bisnis
B
y

H
e
n
d
r
a
N
e
t
Page 64 / 146
Kategori resiko oleh Robert Charette :
Resiko yang sudah diketahui
Resiko yang dapat diramalkan
Resiko yang tidak diharapkan
@ Resiko proyek
Resiko proyek mengancam rencana proyek.
Bila resiko proyek menjadi kenyataan maka ada kemungkinan jadwal
proyek akan mengalami slip & biaya menjadi bertambah.
Resiko proyek mengidenifikasi :
- biaya - sumber daya
- jadwal - pelanggan
- personil (staffing & organisasi) - masalah persyaratan
@ Resiko teknis
Resiko teknis mengancam kualitas & ketepatan waktu PL yg akan
dihasilkan. Bila resiko teknis menjadi kenyataan maka
implementasinya menjadi sangat sulit atau tidak mungkin.
Resiko teknis mengidentifikasi :
- desain potensial - ambiquitas
- implementasi - spesifikasi
- interfacing - ketidakpastian teknik
- verivikasi - keusangan teknik
- masalah pemeliharaan - teknologi yg leading edge
@ Resiko bisnis
Resiko bisnis mengancam viabilitas PL yg akan dibangun.
Resiko bisnis membahayakan proyek atau produk.
B
y

H
e
n
d
r
a
N
e
t
Page 65 / 146
5 resiko bisnis utama :
1. pembangunan produk atau sistem yg baik sebenarnya tdk
pernah diinginkan oleh setiap orang (resiko pasar)
2. pembangunan sebuah produk yg tidak sesuai dgn keseluruhan
strategi bisnis bagi perusahaan (resiko strategi)
3. Pembangunan sebuah produk dimana sebuah bagian pemasaran
tidak tahu bagaimana harus menjualnya.
4. Kehilangan dukungan manajemen senior sehubungan dg
perubahan pd fokus atau perubahan pd manusia (resiko
manajemen)
5. Kehilangan hal
2
yg berhubungan dgn biaya atau komitmen
personal (resiko biaya).
@ Resiko yg sudah diketahui
adalah resiko yg dpt diungkap setelah dilakukan evaluasi secara
hati
2
terhadap rencana proyek, bisnis, & lingkungan teknik dimana
proyek sedang dikembangkan, dan sumber informasi reliable lainnya.
seperti :
- tgl penyampaian yg tdk realitas
- kurangnya persyaratan yg terdokumentasi
- kurangnya ruag lingkup PL
- lingkungan pengembangan yg buruk
@ Resiko yg dapat diramalkan
diekstrapolasi dari pengalaman proyek sebelumnya.
Misalnya :
- pergantian staf
- komunikasi yg buruk dgn para pelanggan
- mengurangi usaha staff bila permintaan pemeliharaan
sedang berlangsung dilayani
B
y

H
e
n
d
r
a
N
e
t
Page 66 / 146
@ Resiko yg tidak diharapkan
resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk
diidentifikasi sebelumnya.
Identifikasi Resiko
Identifikasi resiko dalah usaha sistematis untuk menentukan
ancaman terhadap rencana proyek.
Tujuan identifikasi resiko :
untuk menghindari resiko bilamana mungkin, serta menghindarinya
setiap saat diperlukan.
Tipe resiko :
1. resiko generik
merupakan ancaman potensial pd setiap proyek PL.
2. resiko produk spesifik
hanya dapat diidentifikasi dgn pemahaman khusus mengenai
teknologi, manusia, serta lingkungan yg spesifik terhadap
proyek yg ada.
Metode untuk mengidentifikasi resiko adalah menciptakan
checklist item resiko.
Kategori checklist item resiko :
o resiko ukuran produk
o resiko yg mempengaruhi bisnis
o resiko yg dihubungkan dgn karakteristik pelanggan
o resiko definisi proses
o resiko teknologi yang akan dibangun
o resiko lingkungan pengembangan
o resiko yg berhubungan dgn ukuran dan pengalaman staf
B
y

H
e
n
d
r
a
N
e
t
Page 67 / 146
@ Resiko ukuran produk
Resiko yg berhubungan dgn keseluruhan ukuran PL yg akan dibangun
atau dimodifikasi.
Checklist item resiko yg berhubungan dgn ukuran produk (PL) :
ukuran produk diperkirakan dalam LOC atau FP ?
tingkat kepercayaan dlm estimasi ukuran yg diperkirakan ?
ukuran produk yg diestimasi dalam jumlah program, file,
transaksi ?
presentase deviasi dalam ukuran produk dari rata
2
produk
terakhir ?
ukuran database yg dibuat atau digunakan oleh produk ?
jumlah pemakai produk ?
jumlah perubahan yg diproyeksikan ke persyaratan produk ?
sebelum produk ? setelah penyampaian ?
jumlah PL yg digunakan kembali ?
Bila persentasie deviasi besar atau deviasinya sama, tetapi hasil yg
lalu sangat kurang dari yg diharapkan, maka resikonya tinggi.
@ Resiko yg mempengaruhi bisnis
Resiko yg berhubungan dengan batasan yg dibebankan oleh
manajemen atau pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan
pertimbangan bisnis kadang mengalami konflik langsung dengan
kenyataan teknis.
Checklist item resiko yg berhubungan dgn pengaruh bisnis :
B
y

H
e
n
d
r
a
N
e
t
Page 68 / 146
Pengaruh produk terhadap hasil perusahaan ?
Visibilitas produk terhadap manajemen senior ?
Kelayakan deadline penyampaian ?
Jumlah pelanggan yg akan menggunakan produk & konsistensi
kebutuhan relatif mereka dengan produk tersebut ?
Jumlah produk / sistem lain dgn apa produk ini harus dapat
saling dioperasikan ?
Kepintaran pemakai akhir ?
Jumlah dan kualitas dokumentasi produk yg harus diproduksi &
disampaikan kepada pelanggan ?
Batasan pemerintahan pada konstruksi produk ?
Biaya yg berhubungan dgn penyampaian yg terlambat ?
Biaya yg berhubungan dgn produk defektif ?
Bila ada persentase deviasi yang besar atau jika jumlahnya sama,
tetapi hasil sebelumnya sangat kurang dari yg diharapkan, maka
resiko tinggi.
@ Resiko yg dihubungkan dgn karakteristik pelanggan
Resiko yg berhubungan dengan kepintaran pelanggan & kemampuan
pengembang untuk berkomunikasi dgn pelanggan dgn cara yg cepat.
Karakteristik pelanggan :
- Pelanggan mempunyai keinginan yg berbeda.
- Pelanggan memiliki kepribadian yg berbeda.
- Pelanggan memiliki hubungan yg bervariasi dgn pemasok.
- Pelanggan juga kadang-kadang bertentangan.
Karakteristik pelanggan mempengaruhi kemampuan tim PL untuk
menyelesaikan suatu proyek tepat waktu & sesuai anggaran.
B
y

H
e
n
d
r
a
N
e
t
Page 69 / 146
Checklist item resiko yg berhubungan dgn karakteristik pelanggan:
Pernahkah anda sebelumnya bekerja dengan pelanggan ?
Apakah pelanggan memiliki gagasan yg solid mengenai apa yg
diperlukannya ? sudahkah pelanggan menggunakan waktunya
untuk menuliskannya ?
Apakah pelanggan akan setuju dgn penggunaan waktu didalam
pertemuan pengumpulan persyaratan formal (bab 11) utk
mengidentifikasi ruang lingkup proyek ?
Apakah pelanggan bersedia membangun sambungan
komunikasi cepat dgn pengembang ?
Apakah pelanggan bersedia berpartisipasi dalam kajian ?
Apakah pelanggan secara teknis pandai dlm area produk tsb?
Apakah pelanggan bersedia membiarkan orang
2
melakukan
pekerjaan mereka ?
Apakah pelanggan memahami proses perangkat lunak tsb ?
Bila setiap jawaban dari pertanyaan diatas adalah tidak, maka
investigasi lebih jauh harus dilakukan utk memperkirakan potensi
resiko.
@ Resiko definisi proses
Bila kualitas merupakan sebuah konsep yg disetujui sbg hal yg
penting tetapi tidak tidak ada yg berintdak untuk mencapainya
dengan cara yg dapat yg dilakukan, maka proyek tersebut beresiko.
Masalah-masalah proses
Apakah manajemen senior anda mendukung suatu pernyataan
kebijaksanaan yg menekankan pentingnya suatu proses standar
untuk pengembangan proses ?
Sudahkah organisasi anda mengembangkan suatu diskripsi
tertulis mengenai proses PL yg akan digunakan pd proyek ini ?
B
y

H
e
n
d
r
a
N
e
t
Page 70 / 146
Apakah anggota
2
staf ditugasi ke proses PL pd saat PL
didokumentasi & bersedia menggunakannya ?
Apakah proses PL digunakan untuk proyek lain ?
Sudahkah organisasi anda mengembangkan atau mendapatkan
serangkaian serangkaian kursus pelatihan RPL bagi para
manajer dan staf teknik ?
Apakah standar RPL yg diterbitkan disediakan utk setiap
pengembang PL & manajer PL ?
Sudahkah dokumen outline & contoh
2
dikembangkan untuk
semua yg ditentukan sebagai bagian yg dapat disampaikan
sebagai bagian dari proses PL ?
Apakah kajian teknis formal terhadap spesifikasi persyaratan,
desain, dan kode dilakukan secara reguler ?
Apakah kajian teknis formal terhadap prosedur pengujian &
test case dilakukan secara reguler ?
Apakah hasil dari masing
2
kajian teknis formal
didokumentasikan, termasuk kesalahan yg ditemukan & sumber
daya yg digunakan ?
Apakah mekanisme utk memastikan bahwa kerja yg dilakukan
pd suatu proyek sesuai dengan standar RPL ?
Apakah manajemen konfigurasi digunakan utk memelihara
konsistensi diantara _ystem/persyaratan PL, desain, kode, dan
test case ?
Apakah digunakan suatu mekanisme utk mengontrol perubahan
ke persyaratan pelanggan yg mempengaruhi PL ?
Adakah pernyataan mengenai kerja, spesifikasi persyaratan
pelanggan, dan rencana pengembangan PL yg didokumentasikan
untuk masing
2
subkontrak ?
Apakah ada prosedur untuk menelusuri & mengkaji kinerja
subkontrak ?
Masalah-masalah teknis
B
y

H
e
n
d
r
a
N
e
t
Page 71 / 146
Apakah digunakan teknik spesifikasi aplikasi untuk membantu
komunikasi diantara pelanggan & pengembang ?
Apakah metode spesifik digunakan untuk analisis PL ?
Apakah anda melihat suatu metode spesifik untuk data &
desain arsitektur ?
Apakah lebih dari 90% dari kode anda ditulis dgn bahasa orde
yg lebih tinggi ?
Apakah konvensi spesifik utk dokumentasi kode didefinisikan
& digunakan ?
Apakah anda menggunakan metode spesifik utk desain test
case?
Apakah digunakan peranti PL utk mendukung perencanaan &
aktivitas penelusuran ?
Apakah digunakan peranti PL manajemen konfigurasi utk
me-ngontrol & menelusuri aktivitas perubahan diseluruh
proses PL ?
Apakah digunakan peranti PL utk mendukung analisis PL &
desain proses ?
Apakah digunakan peranti utk menciptakan prototipe PL ?
Apakah digunakan peranti PL utk mendukung proses
pengujian ?
Apakah peranti PL digunakan utk mendukung produksi dan
manajemen dokumentasi ?
Apakah metrik kualitas dikumpulkan bagi semua proyek PL ?
Apakah metrik produktivitas dikumpulkan bagi semua proyek
PL?
Bila mayoritas jawaban terhadap pertanyaan tsb adalah `tidak`,
maka proses PL lemah dan berisiko tinggi.
@ Resiko teknologi yang akan dibangun
B
y

H
e
n
d
r
a
N
e
t
Page 72 / 146
Resiko yg berhubungan dgn kompleksitas sistem yg akan dibangun
dan `kebaruan` teknologi yg dikemas oleh system.
Checklist item resiko yg berhubungan dengan teknologi yg akan
dibangun :
Apakah teknologi yg akan dibangun adalah hal yg baru untuk
organisasi anda?
Apakah persyaratan pelanggan memerlukan kreasi algoritma
baru atau teknologi input atau output?
Apakah PL berinterface dgn perangkat keras baru atau belum
terbukti?
Apakah PL yg akan dibangun ber-interace dgn produk PL yg
dipasok oleh vendor yg belum terbukti?
Apakah PL yg akan dibangun ber-interface dgn suatu sistem
database yg fungsi kinerjanya belum dibuktikan di dalam area
aplikasi ini?
Apakan diperlukan interface pemakai khusus oleh persyaratan
produk?
Apakah persyaratan untuk produk memerlukan kreasi
komponen program yg tidak sama dengan yg dikembangkan
terakhir oleh organisasi anda?
Apakah persyarata memerlukan pemakaian analisis, desain
atau metode pengujian baru?
Apakah persyaratan memerlukan metode pengembangan PL
tdk konvensional, spt metode formal, pendekatan Al-based
dan jaringan syaraf buatan?
Apakah persyaratan meletakkan batasan kinerja yg eksesif
pada produk tersebut?
Apakah pelanggan tidak yakin pada fungsionalitas yg diminta
dapat dilakukan?
Bila jawaban dari pertanyaan
2
di atas adalah ya, penyelidikan lebih
lanjut harus dilakukan untuk memperkirakan risiko potensial.
B
y

H
e
n
d
r
a
N
e
t
Page 73 / 146
@ Resiko lingkungan pengembangan
Resiko yg berhubungan dgn keberadaan & kualitas peranti yg akan
digunakan untuk membangun produk.
Lingkungan proses PL mendukung tim proyek, proses dan produk.
Lingkungan yg salah dapat menjadi sumber resiko yg penting.
Checklist item resiko yg berhubungan dengan lingkungan
pengembangan :
Apakah peranti manajemen proyek dapat diperoleh?
Apakah peranti manajemen proses dapat diperoleh?
Apakah peranti untuk analisis dan desain dapat diperoleh?
Apakah peranti analisis dan desain penyampaian metode sesuai
bagi produk yg akan dibangun?
Apakah kompiler atau generasi kode dapat diperoleh dan
sesuai untuk produk yg akan dibangun?
Apakah peranti pengujian dapat diperoleh dan sesuai untuk
produk yg akan dibangun?
Apakah peranti manajemen konfigurasi PL dapat diperoleh?
Apakah lingkungan menggunakan suatu database atau tempat
penyimpanan?
Apakah semua peranti PL dapat diintegrasikan satu dgn
lainnya?
Sudahkah anggota tim proyek menerima pelatihan dgn masing
2
peranti?
Apakah ada pakar lokal untuk menjawab pertanyaan
2
mengenai
peranti tersebut?
Apakah bantuan dan dokumentasi on-line bagi peranti
memadai?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah tidak,
berarti lingkungan pengembangan PL lemah dan berisiko tinggi.
B
y

H
e
n
d
r
a
N
e
t
Page 74 / 146
@ Resiko yg berhubungan dgn ukuran & pengalaman staf
Resiko yg berhubungan dgn keseluruhan teknik & pengalaman proyek
dari RPL yg akan melakukan tugas tsb.
Checklist item resiko yg berhubungan dengan ukuran & pengalaman
staf :
Apakah orang
2
terbaik dapat diperoleh?
Apakah orang
2
tsb memiliki gabungan ketrampilan yg benar?
Apakah orang
2
yg ada mencukupi?
Apakah staf dimasukkan ke dalam seluruh durasi proyek?
Akankah banyak staf proyek bekerja hanya dalam paruh waktu
pada proyek ini?
Apaka staf memiliki pengharapan yg tepat mengenai pekerjaan
yg ada sekarang?
Sudahkah staf menerima pelatihan yg memadai?
Apakah pergantian di antara staf akan cukup rendah untuk
memungkinkan kontinuitas?
Bila jawaban terhadap pertanyaan
2
tsb adalah tidak, maka
penyelidikan lebih lanjut harus dilakukan untuk memperkirakan
risiko potensial.
Komponen Risiko dan Driver
Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu
menghendaki agar manajer proyek mengidentifikasi risiko driver yg
mempengaruhi komponen risiko PL kinerja, biaya, dukungan dan
jadwal.
Komponen risiko didefinisikan dgn cara sbb :
B
y

H
e
n
d
r
a
N
e
t
Page 75 / 146
Risiko kinerja tingakat ketidakpastian dimana produk akan
memenuhi persyaratannya dan cocok dgn penggunaannya.
Risiko biaya tingkat ketidakpastian dimana biaya proyek akan
dijaga
Risiko dukungan tingkat ketidakpastian dimana PL akan
mudah dikoreksi, disesuaikan dan ditingkatkan.
Risiko jadwal tingkat ketidakpastian dimana jadwal proyek
akan dijaga dan produk akan disampaikan tepat waktu.
Pengaruh driver risiko thd komponen risiko dibagi ke dalam satu dari
empat kategori pengaruh diabaikan, marjinal, kritis dan
katastropis. Tabel 6.1. menunjukkan konsekuensi potensial kesalahan
(baris berlabel 1) atau kegagalan untuk mencapai suatu keluaran yg
diharapkan (baris berlabel 2). Kategori pengaruh dipilih berdasarkan
karakterisasi yg paling cocok dgn deskripsi pada tabel.
B
y

H
e
n
d
r
a
N
e
t
Page 76 / 146
Tabel 6.1. Penilaian Pengaruh
KOMPONEN
KATEGORI
KINERJA DUKUNGAN BIAYA JADWAL
1 Gagal memenuhi persyaratan
menyebabkan misi gagal
Kegagalan menyebabakan biaya
meningkat dan jadwal tertunda dgn
EV>$500K
KATASTROPIK 2 Degradasi
signifikanpd
tdk
berprestasinya
kinerja teknis
PL yg tdk
responsive
atau tdk dpt
didukung
Kemungkinana
kurangnya
finansial dan
membengkaknya
anggaran
Tgl pengiriman
yg tdk dpt
dipenuhi
akan menurunkan kinerja ke titik
dimana sukses misi diragukan
Kegagalan menyebabkan
tertundanya operasinal dan atau
meningkatnya biaya dgn EV $100K
s/d $500K
KRITIS 2 Beberapa
penundaan dlm
kinerja teknis
Penundaan
minor dalam
modifikasi PL
Sedikit
kekurangan
sumber daya
finansial,
mungkin
membengkak
Sedikit
meleset dlm tgl
pengiriman
akan mengakibatkan degradasi
misi kedua
Biaya, pengaruh dan atau
melesetnya jadwal dpt diperbaiki
dgn EV $1 s/d $100K
MARJINAL 2 Penurunan
minimal sampai
kecil dlm
kinerja teknis
Dukungan PL
yg responsif
Sumber daya
finansial yg
mencukupi
Jadwal yg
realistis dan
dpt dicapai
DAPAT
DIABAIKAN
memberikan pengaruh yg tdk
menyenangkan dan
non-operasional
Kesalahan menyebabkan biaya
tambahan dan atau berpengaruh
terhadap jadwal dgn EV < $1K
2 Tdk ada
penurunan dlm
kinerja teknis
PL yg dpt
didukung dgn
mudah
Mungkin
anggaran di bwh
ketentuan
Tgl pengiriman
dpt dicapai
lebih cepat
B
y

H
e
n
d
r
a
N
e
t
Page 77 / 146
Catatan:
(1) Konsekuensi potensial terhadap kesalahan PL yg tdk dpt
dideteksi
(2) Konsekuensi potensial jika hasil akhir yg diinginkan tidak
tercapai
EV = Expected Value
PROYEKSI RISIKO / PERKIRAAN RISIKO
Dua cara melakukan proyeksi risiko :
1. Probabilitas di mana risiko adalah nyata
2. Konsekuensi masalah yang berhubungan dengan risiko
Perencanaan proyek bersama dengan manajer & staf teknik
melakukan 4 aktifitas proyeksi risiko :
1. Membangun suatu skala yang merefleksikan kemungkinan
risiko yang dirasakan
2. Menggambar konsekuensi risiko
3. Memperkirakan pengaruh risiko pada proyek dan produk
4. Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga
akan tidak ada kesalahpahaman
MENGEMBANGKAN TABEL RISIKO
Tabel risiko memberi manajer proyek sebuah teknik sederhana bagi
proyeksi risiko.
B
y

H
e
n
d
r
a
N
e
t
Page 78 / 146
Tabel 6.2 Contoh Tabel Risiko
Risiko Kategori Prob Pengaruh RMMM
Estimasi ukuran rendah
secara signifikan
PS 60% 2
Jumlah pemakai lebih
besar dari yg diharapkan
PS 30% 3
Pemakaian ulang lebih
rendah dr yg diharapkan
PS 70% 2
Pemakaian akhir menolak BU 40% 3
Deadline pengiriman
diperketat
BU 50 % 2
Pendanaan dihapuskan CU 40% 1
Pelanggan akan merubah
kebutuhan
PS 80% 2
Teknologi tdk memenuhi
harapan
TE 30% 1
Kurangnya pelatihan pada
piranti
DE 80% 3
Staf tdk berpengalaman ST 30% 2
Turnover staf tinggi ST 60% 2
KATEGORI RISIKO :
PS : Ukuran produk TE : Teknologi
BU : Bisnis DE : Lingkungan Pengembangan
CU : Proses ST : Ukuran Staf & Pengalaman
B
y

H
e
n
d
r
a
N
e
t
Page 79 / 146
NILAI PENGARUH
1 : Katastropik 3 : Marjinal
2 : Kritis 4 : Dapat diabaikan
Caranya :
1. Daftarkan semua risiko
2. Masing-masing risiko dikatogorikan
3. Probabilitas masing-masing risiko dapat diperkirakan oleh
anggota tim secara individual
4. Pengaruh masing-masing risiko diperkirakan dengan
menggunkan karekteristik yg ada di gambar 6.1
5. Katergori untuk masing-masing dari keempat komponen risiko
kinerja, dukungan, biaya, dan jadwal dirata-rata untuk
menentukan nilai keseluruhan
6. Urutkan probabilitas tinggi dan pengaruh tinggi dimasukkan ke
urutan pertama.
MENILAI PENGARUH RISIKO
Tiga factor yg mempengaruhi konsekuensi jika suatu risiko
benar-benar terjadi :
1. Sifatnya ; risiko yang menunjukkan masalah yg muncul bila ia
terjadi
2. Ruang lingkupnya; menggabungkan kepelikannya (seberapa
seriusnya masalah ini ? ) dengan keseluruhan distribusi
( berapa banyak proyek yg akan dipengaruhi atau berapa
banyak pelanggan terganggu ? )
3. Timingnya; mempertimbangkan kapan dan untuk berapa lama
pengaruh itu dirasakan.
B
y

H
e
n
d
r
a
N
e
t
Page 80 / 146
Seorang manajer proyek mungkin menginginkan berita buruk terjadi
segera mungkin tetapi dalam beberapa kasus penundaan lebih lama
akan lebih baik.
Langkah-langkah yg direkomendasikan untuk menentukan
konsekuensi keseluhan dari suatu resiko :
1. Tentukan probabilitas rata-rata dari nilai kejadian untuk
masing-masing komponen risiko
2. Dengan mengunkan tabel 6.2, tentukan pengaruh untuk
masing-masing komponen berdasarkan kreteria yg
diperlihatkan
3. Lengkapi tabel risiko dan analsis hasilnya seperti dijelaskan
sebelumnya di bab 6 ini.
Tim proyek harus melihat tabel risiko pada interval yg reguler
mengevaluasi lagi masing-masing risiko untuk menentukan kapan
keadaan baru menyebabkan probabilitas dan pengaruh berubah.
Akibatnya diperlukan penambahan risiko baru ke tabel, mengganti
risiko yg tidak relevan dan mengubah pemosisian relatif dari risiko
lainnya.
PENILAIN RISIKO
Dalam proses manajemen risiko, maka telah membangun serangkaian
titik tripel yg berbentuk :
] , , [
i i i
x l r
i
r
adalah risiko,
i
l
adalah kemungkinan (probabilitas) dan
i
x
adah
pengaruh dari risiko tersebut. Selama penilaian risiko harus menguji
akurasi estimasi yg dibuat selama proyeksi risiko dan
B
y

H
e
n
d
r
a
N
e
t
Page 81 / 146
memprioritaskan risiko yg telah diungkap dan cara mengontrol serta
mencegah risiko yg mungkin terjadi.
Tingkat referen risiko harus ditentukan sehingga bermanfaat.
Sebagian besar proyek PL , komponen resiko yaitu kinerja, biaya,
dukungan dan jadwal mencerminkan tingkat referen risiko.
Tingkat referen risiko adalah tingkat degradasi kinerja,
peningkatan biaya, kesulitan dukungan, dan melesatnya jadwal yang
menyebabkan proyek diterminasi.
Jika kombinasi risiko menciptakan masalah sehinnga 1 tingkat
referen terlampaui maka kerja berhenti.
Tingkat referen memiliki titik tunggal yg disebut referen point /
break point dimana keputusan diteruskan atau dihentikan
sama-sama diterima.
Selama penilaian maka dilakukan langkah-langkah sebagai berikut :
1. Tentukan tingkat referen risiko untuk proyek
2. Usahakan untuk mengembangkan hubungan antara
masing-masing
] , , [
i i i
x l r
dan masing-masing tingkat referen
3. Prediksi himpunan titik referen yg menentukan daerah
tereliminasi dibatasi oleh kurva atau area ketidakpastian.
4. Cobalah memprediksi bagaimana penggabungan kombinasi
risiko akan mempengaruhi suatu titik referen
PENGURANGAN, MONITORING dan MANAJEMEN RISIKO
Aktifitas analisis risiko mempunyai titik tunggal yg memiliki tujuan
untuk membantu tim proyek dalam mengembangkan strategi yg
berkaitan dengan risiko.
B
y

H
e
n
d
r
a
N
e
t
Page 82 / 146
Strategi yg efektif harus :
1. Menghindari risiko
2. Memonitoring risiko
3. Manajemen risiko dan perencanaan kemungkinan
Langkah-langkah untuk mengurangi turnover staf adalah
1. Temui staf yg ada, untuk menentukan penyebab keluar
2. Bertindaklah untuk mengurangi penyebab-penyebab yg ada di
bawah kontrol manajemen sebelum proyek dimulai
3. Bila proyek dimulai asumsikan turnover akan terjadi dan
kembangkan teknik-teknik untuk memastikan kontiunitas pada
saat orang keluar
4. Kumpulkan tim proyek sehingga informasi mengenai
masing-masing aktivitas pengembangan dapat disebarluaskan
5. Tentukan standar dokumentasi dan buat mekanisme untuk
memastikan bahwa dokumen dikembangkan tepat waktu
6. Lakukan kajian antar teman terhadap semua pekerjaan
tersebut sehingga lebih dari satu orang yang terbiasa dengan
pekerjaan itu
7. Tentukan backup anggota staf untuk setiap teknologi kritis
Aktifitas pemonitoran dimulai, manajer proyek memonitor
factor-faktor yang dapat memberikan suatu indikasi apakah risiko
mungkin sedang menjadi lebih atau kurang.
Untuk kasus turnover tinggi, factor-faktor yg dapat dimonitor :
1. Sikap umum anggota tim berdasarkan tekanan proyek
2. Tingkat di mana tim disatu padukan
3. Hubungan interpersonal di antara anggota tim
4. Masalah pontensial dengan kompensasi dan manfaat
5. Keberadaan pekerjakan di dalam perusahaan dan di luarnya
B
y

H
e
n
d
r
a
N
e
t
Page 83 / 146
Langkah pengurangan resiko diperlukan bagi definisi standar
dokuntasi dan mekanisme untuk memastikan bahwa dokumen
dikembangkan secara tepat waktu, guna memastikan kontinuitas.
Manajemen risiko dan perencanaan kemungkinan mengasumsikan
bahwa usaha pengurangan telah gagal dan risiko menjadi suatu
kenyataan.
Contoh, diandaikan proyek sedang berlangsung dengan baik dan
sejumlah orang mengatakan akan keluar dari proyek tersebut maka
strategi pengurangan telah dilakukan dengan backup , informasi,
dokumentasi dan pengetahuan telah disebar ke semua tim. Manajer
proyek akan menyesuaikan lagi jadwal dengan fungsi-fungsi yg telah
disusun sepenuhnya dan pendatang baru akan ditambah untuk
mengejar dan membagun serta akan ditransfer pengetahuan oleh
orang akan keluar.
Langkah RMMM (Risk Mitigating Monitoring and Management Plan)
menambah biaya proyek.
RISIKO KESELAMATAN DAN BAHAYA
Risiko tidak hanya pada proyek itu sendiri tetapi juga pada risiko
kegagalan PL dilapangan (pemakai akhir).
Bila PL digunakan untuk sistem kontrol, kompleksitas sistem dapat
bertambah dengan urutan naik.
Cacat desain yg tidak kentara yaitu sesuatu yg tidak dapat
terungkap dan tereliminasi dalam kontrol konvensional berbasis
perangkat keras menjadi lebih sulit diungkap pada saat PL
digunakan.
B
y

H
e
n
d
r
a
N
e
t
Page 84 / 146
Keselamatan PL dan analisis bahaya adalah aktifitas jaminan kualitas
PL yg berfokus pd indentifikasi dan perkiraan bahaya pontensial
terhadap PL dan menyebabkan kegagalan sistem.
RMMM PLAN
Strategi manajemen risiko dapat dimasukkan dalam rencana proyek
PL atau langkah manajemen risiko dapat diatur ke dalam RMMM
PLAN yg terpisah dimana akan didokumentasikan semua kegiatan yg
dilakukan sebagai bagian dari analisis risiko dan oleh manajer proyek
digunakan sebagai bagian dari keseluruhan rencana proyek.
Uraian untuk RMMM PLAN adalah sebagai berikut :
I. Pengantar
1. Lingkup dan tujuan Dokumen
2. Tinjauan risiko utama
3. Tanggung jawab
a. Manajemen
b. Staf teknis
II. Tabel Risiko Proyek
1. Deskripsi semua risiko di atas yang ditentukan
2. Faktor-faktor yang mempengaruhi probabilitas dan
pengaruh
III. Pengurangan, monitoring, dan Manajemen Risiko
n. Risiko # n
a. Pengurangan
i. Strategi umum
ii. Langkah khusus untuk mengurangi risiko
b. Monitoring
i. Faktor-faktor yang dimonitoring
ii. Pendekatan monitoring
c. Manajemen
B
y

H
e
n
d
r
a
N
e
t
Page 85 / 146
i. Rencana kontigensi
ii. Konsiderasi khusus
IV. Jadwal Iterasi Rencana RMMM
V. Kesimpulan
Sasaran dari monitoring risiko (aktifitas penelurusan proyek) yaitu
1. Memperkirakan apakah risiko yang diramalkan benar-benar
terjadi
2. Memastikan bahwa langkah aversi risiko yang didefiniskan
untuk risiko telah diterapkan secara benar
3. Mengumpulkan informasi yang dapat digunakan untuk analisis
risiko masa yang akan datang
Tugas lain dari monitoring risiko adalah berusaha menentukan risiko
asli pada seluruh proyek.
B
y

H
e
n
d
r
a
N
e
t
Page 86 / 146

7.1 KONSEP DASAR
Pengiriman PL terlambat dikirimkan (jadwal yg telah)
disebabkan :
1. Batas waktu yg tidak realistis karena dibuat oleh orang
diluar kelompok RPL
2. Perubahan kebutuhan pelanggan yg tdk tercemin dalam
perubahan jadwal
3. Memandang rendah jumlah usaha & / sumber sumber daya
yg dibutuhkan dalam melakukan pekerjaan
4. Resiko yang dapat diramalkan & / tidak dapat diramalkan
yang tidak dipertimbangkan pada proyek tersebut
5. Kesulitan teknis dan manusia yang tidak dapat dilihat
sebelumnya
6. Kesalahan komunikasi di antara staff proyek yang
mengakibatkan penundaan proyek
7. Kegagalan manajer proyek untuk mengetahui bahwa proyek
sudah ketinggalan dari jadwal yang ada dan kurang tindakan
dalam memecahkan masalah tersebut

Tindakan yang dilakukan dalam menghadapi keterlambatan
jadwal proyek yaitu :
B
y

H
e
n
d
r
a
N
e
t
BAB 7.PENJADWALAN & PENELUSURAN PROYEK
Page 87 / 146

Lakukan perkiraan lengkap berdasarkan data dari proyek
yang lalu . Tentukan usaha yang diperkirakan dan durasi
untuk proyek tersebut
Dengan metode Inkremental, kembangkan suatu strategi
pengembangan yang akan menyampaikan fungsionalitas
kritis dengan batas waktu ditentukan tetapi tundalah
fungsionalitas dan dokumentasikan rencana tersebut.
Komunikasikan dengan pelanggan, jelaskan mengapa jadwal
tidak realistis. Lakukan pencatatan bahwa semua perkiraan
yang ada pada kinerja proyek dan tunjukan % peningkatan
yang dibutuhkan untuk mencapai batas waktu yang ada
Menawarkan strategi pengembangan incremental sebagai
alternatif

Penjadwalan proyek pengembangan PL dapat dilihat dari :
Tanggal akhir pelepasan sistem berbasis komputer yang
telah dibuat dan organisasi PL dibatasi dalam
mendistribusikan kerja di dalam batas waktu yang telah
ditentukan
Penjadwalan PL mengasumsikan bahwa batasan kronologis
secara umum telah dibicarakan tetapi batas akhir
ditentukan oleh organisasi PL

B
y

H
e
n
d
r
a
N
e
t
Page 88 / 146

Prinsip dasar menentukan jadwal proyek PL :
1. Pembagian
2. Saling ketergantungan
3. Alokasi waktu
4. Validasi kerja
5. Batasan tanggungjawab
6. Batasan keluaran
7. Kejadian penting yang ditentukan

7.2 HUBUNGAN ANTARA MANUSIA DAN KERJA
Bila suatu proyek mengalami keterlambatan jadwal yang
ditetapkan maka akan menambah programmer untuk mengejar
ketinggalan tersebut. Sayangnya, penambahan orang akan pada
akhir proyek sering menjadi bencana menyebabkan jadwal
menjadi lebih terlambat lagi. Karena orang ditambah akan
mempelajari sistem yang telah ada dan orang yang mengajari
mereka adalah orang yang sedang bekerja pada proyek tersebut
sehinnga tidak bisa mengerjakan pekerjaannya. Waktu untuk
mempelajari sistem mengakibatkan meningkatnya jalur
komunikasi sehingga membutuhkan kerja tambahan dan
tambahan waktu proyek.

B
y

H
e
n
d
r
a
N
e
t
Page 89 / 146

7.3 HUBUNGAN EMPIRIS
3
4
3
1
) / ( t B E P L =

L = jumlah baris
P = produktifitas
E = usaha (person month)
B = factor skill ( 0,16 0, 39)
t = durasi proyek dalam bulan kalender

) 1 , 7 )( /(
4 3 3
t P L E
t
=

E = usaha yg diperluas (person year)
L = jumlah baris
P = produktifitas
t = durasi proyek dalam tahun

7.4 MENENTUKAN SERANGKAIAN TUGAS UNTUK PROYEK
PL

Rangkaian tugas adalah sekumpulan tugas kerja RPL,
pondasi, dan kemampuan penyampaian yg harus diselesaikan
untuk menyelesaikan sebuah proyek tertentu serta memberikan
disiplin yg cukup untuk mencapai kualitas PL yg tinggi.

B
y

H
e
n
d
r
a
N
e
t
Page 90 / 146

Tipe proyek PL adalah
1. Consept Development Project, untuk mencari konsep bisnis
yg baru / aplikasi dgn teknologi baru
2. New Aplication Development Project, dilakukan sbg
konsekunsi permintaan pelanggan khusus
3. Aplication Enhancement Project, PL yg ada mengalami
modifikasi utama dari fungsi, kinerja / interface yg dapat
diamati oleh pemakai akhir
4. Aplication Maintenance Projects, dilakukan untuk
membetulkan, menyesuaikan / memperluas PL yg ada dgn cara
tidak begitu jelas
5. Reengineering Projects, membagun sistem yg ada (warisan)
secara keseluruhan / sebagian

4 Tingkat kekakuan proyek didefinisikan :
Casual
Structured
Strict
Quick Reaction

7.5 Menentukan Kriteria Adaptasi
Untuk menentukan derajat kekakuan yg direkomendasikan
di mana proses PL akan diaplikasikan. Kriterianya adalah:

B
y

H
e
n
d
r
a
N
e
t
Page 91 / 146

1. Ukuran proyek
2. Jumlah pemakaian potensial
3. Misi kekritisan
4. Umum Aplikasi
5. Stabilitas kebutuhan
6. Mudahnya komunikasi pelanggan/pengembang
7. Kematangan teknologi yg dapat diaplikasikan
8. Batasan unjuk kerja
9. Karakteristik embedded / non embedded
10. Staffing Proyek
11. Interoperabilitas
12. Faktor Perekayasaan kembali

Kreteria diatas diberi kisaran dari 1 sampai 5.
1 = mewakili sebuah proyek yg dibutuhkan sub-kumpulan kecel
dari tugas proses & metodologi keseluruhan serta
dokumentasi minimal
5 = mewakili sebuah proyek dimana serangkaian tugas proses
lengkap harus diaplikasikan dan metodologi keseluruhan
serta dokumentasi substansial

B
y

H
e
n
d
r
a
N
e
t
Page 92 / 146

7.6 PERHITUNGAN NILAI TASK SET SELECTOR (TSS)

Langkah-langkah menghitung nilai TSS :
1. Kajilah masing-masing kriteria adaptasi dalam sub bab 7.5
dan tetapkan angka yg sesuai (1 s/d 5) berdasarkan
karakteristik proyek
2. Kajilah factor pembobotan yg ditetapkan (0,9 s/d 1,2) dan
bila diperlukan dapat diubah sesuai dengan keperluan proyek
3. Hasil produk = angka x factor pembobot x entry point
multiplier
Entry point multiplier berharga 0 dan 1 berarti relevansi
kreteria adaptasi dengan tipe proyek
4. Hitunglah rata-rata dari semua entri pada kolom produk dan
tempatkan pada ruang yg ditandai TSS. Harga ini digunakan
untuk memilih kumpulan tugas yg paling sesuai bagi proyek
anda.

7.7 Interpretasi Harga TSS dan Pemilihan Kumpulan Tugas
Tabel 7.2 Harga TSS
TASK SET SELECTOR (TSS) Tingkat Kekakuan
TSS < 1,2 Casual
1,0 < TSS <3,0 Structured
TSS > 2,4 Stict

B
y

H
e
n
d
r
a
N
e
t
Page 93 / 146

Overlap antara harga TSS dari kumpulan tugas yg disetujui
dengan kumpulan tugas lain dimaksudkan untuk menggambarkan
bahwa batasan yg tajam tidak mungkin ditentukan pada saat
memilih kumpulan tugas.
Dalam analisis akhir, harga TSS, pengalaman masa lalu, dan
aturan umum harus difaktorkan ke dalam pilihan kumpulan
sebuah proyek.
Contoh dapat dilihat pada tabel 7.3 dimana proyek tipe proyek
adalah new application development (Ndev).
Harga TSS produk adalah 2,8 maka manajer memilih pilihan
pemakaian terbaik dari test set structured maupun strict.
Keputusan akhir diambil setelah semua factor proyek
dipertimbangkan.

7. 8 MEMILIH TUGAS TUGAS RPL
Proyek pengembangan konsep dididekati dengan menerapkan
tugas-tugas utama berikut ini :
1. Penentuan ruang lingkup konsep dilakukan scr menyeluruh
2. Perencanaan konsep pendahuluan membangun kemampuan
organisasi untuk melakukan kerja yg diimplentasi oleh ruang
lingkup proyek
3. Perkiraan risiko teknologi mengevaluasi risiko yg
berhubungan dgn teknologi yg diimplementasikan sebagai
bagian dari ruang lingkup proyek
B
y

H
e
n
d
r
a
N
e
t
Page 94 / 146

4. Bukti dari konsep mendemontrasikan viabilitas sebuah
teknologi baru dlm konteks perangkat lunak
5. Implementasi konsep mengimplementasikan representasi
konsep dengan cara yg dapat dikaji oleh seorang pelanggan &
digunakan sebagai pemasaran pd saat konsep harus dijual ke
pelanggan / manajemen lain
6. Reaksi pelanggan terhadap konsep mengumpulkan umpan balik
tentang konsep & target sebuah teknologi baru yg
mengkhususkan pd aplikasi pelanggan

Tim perangkat lunak harus memahami apa yg harus dilakukan
(ruang llingkup), tim/manajer hrs menentukan apakah ada orang
yg dapat mengerjakannya (perencanaan), menentukan risiko
sehubungan dengan kerja tersebut (estimasi risiko),
membuktikan teknologi dengan berbagai cara (pembuktian
konsep), mengimplementasian proyek dgn prototaping sehingga
dpt dievaluasi oleh pelanggan (konsep impelentasi & evaluasi
pelanggan) , bila konsep dapat dipercaya maka dihasilkan versi
produksi.

7.8 PENYARINGAN TUGAS-TUGAS MAYOR
Jadual mikroskopik harus disaring untuk menghasilkan
jadual proyek lengkap, penyaringan dimulai dengan mengambil
B
y

H
e
n
d
r
a
N
e
t
Page 95 / 146

setiap tugas utama & melakukan dekomposisi terhadap tugas
tersebut kedlm serangkaian sub tugas .
Contoh dekomposisi tugas, Penentuan Ruang Lingkup Konsep
dengan pendekatan bahasa desain proses :

Tugas I.1 Penentuan Ruang Lingkup Proses
I.1.1 Mengidentifikasi kebutuhan, keuntungan & pelanggan
potensial
I.1.2 Menentukan kejadian output/kontrol & input yg diharapkan
yg mengendalikan aplikasi
Memulai Tugas I.1.2
I.1.2.1 FTR mengkaji deskripsi kebutuhan tertulis
I.1.2.2 Memperoleh daftar output/input yg tampak pd
konsumen

Case of : mekanik
Mekanik : penyebaran fungsi kualitas
Bertemu dgn pelanggan untuk mengisolasi
kebutuhan konsep utama;
Mewawancarai pemakai akhir
Meneliti pendekatan masalah, proses saat ini
Mengkaji permintaan & keluhan sebelumnya
Mekanik = analisis terstruktur
Membuat daftar objek data minor
Menentukan hubungan antar objek
Mekanik = melihat objek
Membuat daftar kelas bermasalah
Mengembangkan hirarki kelas & hubungan kelas
Menentukan atribut untuk kelas
I.1.2.3 FTR : mengkaji output / input dengan pelanggan & merevisi
sesuai kebutuhan
B
y

H
e
n
d
r
a
N
e
t
Page 96 / 146

I.1.3 Menentukan fungsionalitas/ tingkah laku untuk setiap fungsi
utama

Memulai Tugas I.1.3
I.1.3.1 FTR : mengkaji objek data output & input yg diambil
dari tugas I.1.2

7.9 MENENTUKAN JARINGAN TUGAS
Jaringan tugas merupakan representasi grafik dari aliran
tugas sebuah proyek & digunakan sebagai mekanisme untuk
seluruh rangkaian & ketergantunagn tugas merupakan input bagi
suatu alat bantu penjadual proyek secara otomatis.
Manajer proyek harus tanggap terhadap jalur kritis. Dapat
dilihat pada gambar 7.????.

7.10 PENJADUALAN
Teknik kajian & evaluasi program (PERT) & metode jalur
kritis (CPM) adalah dua metode penjadualan proyek yg dapat
diaplikasikan pd pengembangan perangkat lunak. Kedua teknik
dikendalikan oleh informasi yg sudah dikembangan pd aktifitas
perencanaan proyek sebelumnya :
Estimasi kerja
Dekomposisi fungsi produk
Pemilihan tipe proyek & rangkaian tugas
B
y

H
e
n
d
r
a
N
e
t
Page 97 / 146

Kesaling-ketergantungan antara tugas-tugas dpt ditentukan dgn
menggunakan sebuah jaringan tugas, ka&g-ka&g disebut
Struktur Perincian Kerja (WBS) ditentukan untuk produk
sebagai satu kesatuan / untuk fungsi individual.
Baik PERT & CPM menyediakan piranti kuantitatif yg
memperbolehkan perencanan perangkat lunak untuk
1. Menentukan jalur kritis rantai tugas yg menentukan
durasi proyek
2. Membangun estimasi waktu yg paling mungkin bagi tugas-
tugas individual dgn menerapkan model statistik
3. Menghitung batas waktu yg membatasi suatu jendela
waktu untuk suatu tugas tertentu
Riggs menggambarkan waktu batas yg penting dimana
8. Suatu tugas dapat dimulai ketika semua tuags sebelumnya
sudah diselesaikan dalam waktu yg paling pendek yg mungkin
9. Waktu paling lambat untuk menginisiasi tugas sebelum waktu
penyelesaian proyek minimum ditunda
10. Penyelesaian paling awal jumlah dari waktu mulai paling
awal dari durasi tugas
11. Selesai paling akhir jumlah dari waktu mulai paling lambat
ditambah ke durasi tugas
12. Total float jumlah waktu surplus / waktu ekstra yg
diperbolehkan dalam penjadual tugas sehingga jalur kritis
jaringan terjada sesuai jadual
B
y

H
e
n
d
r
a
N
e
t
Page 98 / 146

1.11 DIAGRAM TIMELINE
Dalam membuat jadual proyek PL, perencana memulainya
dgn serangkaian tugas , bila piranti otomatis digunakan, rincian
kerja dimasukkan sbg sebuah jaringan tugas / outline tugas.
Kemudian kerja, durasi, & tanggal mulai dimasukkan bg setiap
tugas dan tugas-tugas dapat ditentukan bagi individu-individu
tertentu.
Dengan input tersebut terbentu diagram timeline atau
gantt. Contoh dapat dilihat pada gambar ????
Batang horizontal adalah menunjukkan durasi dari masing-
masing tugas
Bila ada batang ganda pada saat yg sama pd kalender, tugas-
tugas konkuren diimplikasikan.
Tanda diamond menunjukkan kejadian penting.
Hasilnya adalah tabel proyek mementukkan tanggal dimulai dan
berakhirnya baik yg direncanakan maupun yg sesungguhnya.

1.12 PENELUSURAN JADUAL
Penelusuran jadwal dapat dilakukan dengan berbagai cara :
1. Mengadakan pertemuan status proyek scr periodic di mna
anggota tim melaporkan masalah & kemajuannya
2. Mengevaluasi hasil kajian yg dilakukan pd keseluruhan
proses RPL
B
y

H
e
n
d
r
a
N
e
t
Page 99 / 146

3. Menentukan apakah kejadian penting proyek formal
(tanda diamond) telah dikerjakan sesuai tanggal yg
dijadualkan
4. Membandingkan tanggal mulai actual dengan tanggal mulai
yg direncanakan bg setiap tugas proyek yg ditulis dlm
tabel
5. Pertemuan scr informal dgn para pelaksana untuk
mendapatkan perkiraan kemajuan subjektif mereka
tanggal dan masalah di masa mendatang
Teknik pelacakan , biasanya dilakukan oleh manajer proyek yg
berpengalaman.
Kontrol digunakan oleh manajer proyek PL untuk menjalankan
sumber-sumber daua proyek, menyelesaikan masalah,
mengarahkan staf proyek.
Bila proyek berjakan baik kontrol menjadi langgor tetapi bila
sebaliknya maka kontrol diperketat dan focus ditekankan pd
area masalah.
Pada tekanan batas waktu yg berat, manajer proyek
menggunakan metode time boxing yaitu setiap tugas disesuaikan
dgn mengerjakan scr backward dari tanggal penyampaian untuk
pertambahan tsb yg dibatasi batas waktu yg ditambah 10 % bila
sudah sampai pd batas waktu maka pekerjaan berhenti dan
dimulai dgn pekerjaan baru.

B
y

H
e
n
d
r
a
N
e
t
Page 100 / 146

7.13 RENCANA PROYEK
Rencana proyek PL diproduksi pada titik puncak tugas-
tugas perencanaan yang memberikan biaya dasar dan informasi
penjadualan yg dipakai pd keseluruhan proyek.
Rencana proyek digunakan kepentingan orang yg berbeda
berupa dokumen singkat yaitu :
1. Mengkomunikasikan ruang lingkup & sumber-sumber daya
kpd manajer PL
2. Menentukan risiko & mengusulkan teknik manajemen risiko
3. Membatasi biaya & jadual untuk keperluan pengkajian
4. Memberikan pendekatan yg menyeluruh kpd
pengembangan PL bagi orang-orang yg berhubungan dg
proyek tersebut
5. Menguraikan bagaimana kualitas akan dijamin & perubahan
akan dilakukan
Langkah-langkah berikut dalam proyek PL akan berkosentrasi
pada definisi, pengembangan dan pemeliharaan :

I. Pendahuluan
A. Tujuan Rencana
B. Ruang Lingkup & Tujuan Proyek
1. Pernyataan Ruang lingkup
2. Fungsi-fungsi utama
3. Isu-isu kerja
4. Batasan manajemen & teknik
II. Estimasi Proyek
A. Data historis yg digunakan untuk estimasi
B. Teknik-teknik estimasi
B
y

H
e
n
d
r
a
N
e
t
Page 101 / 146

C. Estimasi Usaha, biaya, & durasi
III. Strategi Manajemen Risiko
A. Tabel risiko
B. Penambahan risiko untuk dikelola
C. Rencana RMMM untuk setiap risiko
1. Mitigasi risiko
2. Monitoring risiko
3. Manajemen risiko (rencana kontigensi)
IV. Jadual
A. Struktur Pembagian Kerja Proyek
B. Jaringan tugas
C. Diagram Timeline / gantt
D. Tabel sumber daya
V. Sumber Daya Proyek
A. Orang
B. Perangkat keras & Perangkat Lunak
C. Sumber daya khusus
VI. Staf Organisasi
A. Struktur tim jika diterapkan
B. Pelaporan manajemen
VII. Pelacakan & Mekanisme Kontrol
A. Jaminan & kontrol kualitas
B. Mananjemen & kontrol perubahan
VIII. Lampiran
B
y

H
e
n
d
r
a
N
e
t
Page 102 / 146

Tabel 7.1
ENTRY PRINT MULTIPIER KRETERIA
ADAPTAS
GRADE LEBAR
CONC NDEV ENHAN MAINT REENG PRODUCT
Ukuran proyek 2 0 1 1 1 1 0
Jumlah pemakaian 3 0 1 1 1 1 0
Kekritikalitas Bisnis 4 0 1 1 1 1 0
Umum 3 0 1 1 0 0 0
Stabilitas kebutuhan 2 0 1 1 1 1 0
Kemudahan
komunikasi
2 1 1 1 1 1 1
Kematangan teknologi 2 1 1 0 0 1 1
Batasan kinerja 3 0 1 1 0 1 0
Embedded/non
embedded
3 1 1 1 0 1 1
Staffing Proyek 2 1 1 1 1 1 1
Interoperabilitas 4 0 1 1 1 1 0
Faktor Rekayasa
Ulang
0 0 0 0 0 1 0
Task Set Selector (TSS)
B
y

H
e
n
d
r
a
N
e
t
h
t
t
p
:
/
/
w
w
w
.
h
e
n
d
r
a
-
j
a
t
n
i
k
a
.
w
e
b
.
i
d
P
a
g
e

1
0
3

/

1
4
6

Tabel 73 Contoh Kasus
ENTRY PRINT MULTIPIER KRETERIA
ADAPTAS
GRADE LEBAR
CONC NDEV ENHAN MAINT REENG PRODUCT
Ukuran proyek 2 1,20 - 1 - - - 2,4
Jumlah pemakaian 3 1,10 - 1 - - - 3,3
Kekritikalitas Bisnis 4 1,10 - 1 - - - 4,4
Umur 3 0,90 - 1 - - - 2,7
Stabilitas kebutuhan 2 1,20 - 1 - - - 2,4
Kemudahan
komunikasi
2 0,90 - 1 - - - 1,8
Kematangan teknologi 2 0,90 - 1 - - - 1,8
Batasan kinerja 3 0,80 - 1 - - - 2,4
Embedded/non
embedded
3 1,20 - 1 - - - 3,6
Staffing Proyek 2 1,00 - 1 - - - 2
Interoperabilitas 4 1,10 - 1 - - - 4,4
B
y

H
e
n
d
r
a
N
e
t
h
t
t
p
:
/
/
w
w
w
.
h
e
n
d
r
a
-
j
a
t
n
i
k
a
.
w
e
b
.
i
d
P
a
g
e

1
0
4

/

1
4
6

Faktor Rekayasa
Ulang
2 1,20 - 0 - - - 2.4
Task Set Selector (TSS) 2.8

B
y

H
e
n
d
r
a
N
e
t
h
t
t
p
:
/
/
w
w
w
.
h
e
n
d
r
a
-
j
a
t
n
i
k
a
.
w
e
b
.
i
d
P
a
g
e

1
0
5

/

1
4
6
BAB 8
JAMINAN KUALITAS PERANGKAT LUNAK
Software Quality Assurance [SQA]
J aminan kualitas perangkat lunak adalah aktivitas
pelindung yang diaplikasikan pada seluruh proses
perangkat lunak.
SQA meliputi :
1. pendekatan manajemen kualitas
2. teknologi rekayasa perangkat lunak yang efektif
(metode dan peranti)
3. kajian teknik formal yang diaplikasikan pada
keseluruhan proses perangkat lunak
4. strategi pengujian multitiered (deret bertingkat)
5. kontrol dokumentasi perangkat lunak dan
perubahan
6. prosedur untuk menjamin kesesuaian dengan
standar pengembangan perangkat lunak
7. mekanisme pengukuran dan pelaporan.
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.
Konsep kunci kualitas kontrol adalah bahwa semua
produk kerja memiliki spesifikasi yang telah
ditentukan dan dapat diukur dimana kita dapat
membandingkan output dari setiap proses.
Kalang (loop) menjadi penting untuk meminimalkan
cacat yang dihasilkan.
B
y

H
e
n
d
r
a
N
e
t
Page 106 / 146
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 & konfidensi bahwa kulitas produk dapat
memenuhi sasaran.
Biaya Kualitas
Biaya kualitas menyangkut semua biaya yang
diadakan untuk mengejar kualitas atau untuk
menampilkan kualitas yang berhubungan dengan
aktivitas.
Studi tentang biaya kualitas dilakukan untuk
memberikan garis dasar bagi biaya kualitas yang
sedang digunakan, untuk mengidentifikasi
kemungkinan pengurangan biaya kualitas serta
memberikan basis perbandingan yang ternormalisasi.
Biaya kualitas dapat dibagi ke dalam biaya-biaya
yang dihubungkan dengan :
a. pencegahan
b. penilaian
c. kegagalan.
a) Biaya pencegahan meliputi :
Perencanaan
Kajian teknis formal
Perlengkapan pengujian
Pelatihan
B
y

H
e
n
d
r
a
N
e
t
Page 107 / 146
b) Biaya penilaian meliputi :
Inspeksi in-proses dan interproses
Pemeliharaan dan kalibrasi peralatan
Pengujian
c) Biaya kegagalan
Biaya kegagalan adalah biaya yang akan hilang bila
tidak ada cacat yang muncul sebelum produk
disampaikan kepada pelanggan.
Biaya kegagalan internal adalah
biaya yang diadakan bila kita mendeteksi suatu
kesalahan dalam produk sebelum produk dipasarkan.
Biaya kegagalan internal meliputi:
Pengerjaan kembali
Perbaikan
Analisis mode kegagalan
Biaya kegagalan eksternal adalah
biaya yang berhubungan dengan cacat yang
ditemukan setelah produk disampaikan kepada
pelanggan.
Biaya kegagalan eksternal meliputi:
Resolusi keluhan
Penggantian dan pengembalian produk
Dukungan help line
Kerja jaminan
Biaya relatif mendapatkan dan membetulkan cacat
bertambah secara dramatis pada saat kita melangkah
dari pencegahan ke pendeteksian dan dari kegagalan
internal ke kegagalan eksternal.
B
y

H
e
n
d
r
a
N
e
t
Page 108 / 146
P e m b e n tu k a n De s ain K o de U ji
P e n ge m b a n ga n
Uji
Si s te m
O pe ra si
L a p a n g an
1 0 0 0
1 0 0
1 0
1
B
i
a
y
a
R
e
l
a
t
i
f
P
e
m
b
e
n
t
u
k
a
n
K
e
s
a
l
a
h
a
n
1
w a k tu
3 - 6
w a k tu
10
w a k tu
1 5 - 4 0
wa k tu
3 0 - 70
w a ktu
4 0 - 10 00
w a k tu
Gambar 8.1 Biaya Relatif pembetulan kesalahan
JAMINAN KUALITAS PERANGKAT LUNAK
Kualitas perangkat lunak didefinisikan sebagai:
Konformansi terhadap kebutuhan fungsional dan
kinerja yang dinyatakan secara eksplisit, standar
perkembangan yang didokumentasikan secara
eksplisit, dan karakteristik implisit yang diharapkan
bagi semua perangkat lunak dikembangkan secara
profesional.
definisi tersebut berfungsi untuk menekankan tiga hal
penting, yaitu:
1. Kebutuhan perangkat lunak merupakan fondasi
yang melaluinya kualitas diukur.
2. Standar yang telah ditentukan menetapkan
serangkaian kriteria pengembangan yang
menuntun cara perangkat lunak direkayasa.
3. Ada serangkaian kebutuhan implisit yang sering
dicantumkan (misalnya kebutuhan akan
kemampuan pemeliharaan yang baik).
B
y

H
e
n
d
r
a
N
e
t
Page 109 / 146
Kelompok SQA berfungsi sebagai perwakilan in-
house pelanggan, yaitu orang yang akan melakukan
SQA harus memperhatikan perangkat lunak dari
sudut pandang pelanggan.
Kelompok SQA harus dapat menjawab pertanyaan-
pertanyaan dibawah ini untuk memastikan bahwa
kualitas perangkat lunak benar-benar terjaga.
Apakah perangkat lunak cukup memenuhi
faktor kualitas
Sudahkah pengembangan perangkat lunak
dilakukan sesuai dengan standar yang telah
ditetapkan sebelumnya?
Sudahkah disiplin teknik dengan tepat
memainkan perannya sebagi bagian dari
aktivitas SQA?
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 bertanggung jawab
terhadap perencanaan jaminan kualitas,
kesalahan, penyimpanan rekaman, analisis,
dan pelaporan.
Tugas kelompok SQA adalah
membantu tim rekayasa perangkat lunak dalam
pencapaian produk akhir yang berkualitas tinggi.
B
y

H
e
n
d
r
a
N
e
t
Page 110 / 146
Aktivitas yang dilakukan (atau difasilitasi) oleh
kelompok SQA yang independen:
v Menyiapkan rencana SQA untuk suatu proyek.
Rencana tersebut mengindentifikasikan hal-hal
berikut:
Evaluasi yang dilakukan
Audit dan kajian yang dilakukan
Standar yang dapat diaplikasikan pada proyek
Prosedur untuk pelaporan & penelusuran
kesalahan
Dokumen yang dihsilkan oleh kelompok SQA
Jumlah umpan balik yang diberikan pada tim
proyek perangkat lunak
v Berpartisipasi dalam pengembangan deskripsi
proses pengembangan proyek.
v Mengkaji aktivitas rekayasa perangkat lunak
untuk memverifikasi pemenuhan proses
perangkat lunak yang sudah ditentukan.
v Mengaudit produk kerja perangkat lunak yang
ditentukan untuk membuktikan kesesuaian
dengan produk kerja yang ditentukan tersebut
sebagai bagian dari proses perangkat lunak.
v Memastikan bahwa deviasi pada kerja dan
produk perangkat lunak didokumentasikan & di-
tangani sesuai dgn rosedur pendokuementasian.
v Mencatat ketidak-sesuaian dan melaporkannya
kepada manajemen senior.
v Mengkoordinasi kontrol dan manajemen
perubahan, dan membantu mengumpulkan dan
menganalisis metrik perangkat lunak.
B
y

H
e
n
d
r
a
N
e
t
Page 111 / 146
KAJIAN PERANGKAT LUNAK
Kajian perangkat lunak merupakan salah satu
aktivitas SQA yang terpenting.
Kajian perangkat lunak adalah suatu filter bagi proses
rekayasa perangkat lunak, yaitu kajian yg diterapkan
pd berbagai titik selama pengembangan PL &
berfungsi untuk mencari kesalahan yg kemudian akan
dihilangkan.
Kajian perangkat lunak berfungsi untuk memurnikan
produk kerja perangkat lunak yang terjadi sebagai
hasil dari analisis, desain, dan pengkodean.
KAJIAN TEKNIK FORMAL
(Formal Technic Review - FTR )
FTR adalah aktivitas jaminan kualitas perangkat lunak
yang dilakukan oleh perekayasa perangkat lunak.
Kajian teknik formal atau walktrough adalah
pertemuan kajian yang disesuaikan dengan
kebutuhan yang terbukti sangat efektif untuk
menemukan kesalahan.
Keuntungan utama kajian teknis formal adalah
penemuan kesalahan sejak awal sehingga tidak
berlanjut ke langkah selanjutnya dalam proses
perangkat lunak.
Tujuan FTR adalah
1. Menemukan kesalahan dlm fungsi, logika, /
implementasinya dlm berbagai representasi PL;
2. Membuktikan bahwa perangkat lunak di bawah
kajian memenuhi syarat;
B
y

H
e
n
d
r
a
N
e
t
Page 112 / 146
3. Memastikan bahwa PL disajikan sesuai dgn
standar yg sudah ditentukan sebelumnya;
4. Mencapai perangkat lunak yg dikembangkan
dengan cara yang seragam;
5. Membuat proyek lebih dapat dikelola.
FTR berfungsi sebagai dasar pelatihan yang
memungkinkan perekayasa yunior mengamati
berbagai pendekatan yang berbeda terhadap analisis
perangkat lunak, desain, dan implementasi.
FTR juga berfungsi untuk mengembangkan backup
dan kontinuitas karena sejumlah orang mengenal baik
bagian-bagian perangkat lunak yang tidak mereka
ketahui sebelumnya.
Masing-masing FTR dilakukan sebagai suatu
pertemuan dan akan berhasil hanya bila
direncanakan, dikontrol dan dihadirkan dengan tepat.
Dalam paragraf berikut, panduan yang mirip dengan
walktrough disajikan sebagai kajian teknis formal
representatif.
TABEL 8.1 Perbandingan Biaya Pengembangan
Kesalahan yang
ditemukan
Jumlah Unit Biaya Total
Kajian dilakukan
Selama desain
Sebelum pengujian
Selama pengujian
Setelah peluncuran
22
36
15
3
1.5
6.5
15
67
33
234
315
201
783
Kajian tidak
dilakukan
Sebelum pengujian
Selama pengujian
Setelah peluncuran
22
82
12
6.5
15
67
143
1230
804
2177
B
y

H
e
n
d
r
a
N
e
t
Page 113 / 146
Pertemuan Kajian
Tanpa memperhatikan format FTR yang dipilih, setiap
pertemuan kajian harus mematuhi batasan-batasan
berikut ini :
Antara 3 & 5 orang (khususnya) harus dilibatkan
dalam kajian;
Persiapan awal harus dilakukan, tetapi waktu
yang dibutuhkan harus tidak lebih dari 2 jam dari
kerja bagi setiap person
Durasi pertemuan kajian harus kurang dari 2 jam
Pertemuan kajian dihadiri oleh pimpinan kajian,
pengkaji, dan prosedur. Salah satu dari pengkaji
berperan sebagai pencatat, yaitu seseorang yang
mencatat semua masalah penting yang muncul
selama pengkajian.
FTR dimulai dengan pengenalan agenda dan
pendahuluan dari prosedur. Bila ada masalah
kesalahan ditemukan akan dicatat.
Pada akhir kajian, semua peserta FTR yang hadir
harus memutuskan apakah akan
1. menerima produk kerja tanpa modifikasi lebih
lanjut,
2. menolak produk kerja sehubungan dengan
kesalahan yangada (sekali dbetulkan, kajiann lain
harus dilakukan), atau
3. menerima produk kerja secara sementara
(kesalahan minor telah terjadi & harus dikoreksi,
tetapi kajian tambahan akan diperlukan).
Keputusan kemudian dibuat.
Semua peserta FTR melengkapinya dengan tanda
tangan yang menunjukkan partisipasi mereka dalam
kajian serta persetujuan mereka terhadap pertemuan
tim kajian.
B
y

H
e
n
d
r
a
N
e
t
Page 114 / 146
Pelaporan Kajian dan Penyimpanan Rekaman
Selama FTR, seorang pengkaji (pencatat) secara aktif
mencatat semua masalah yang sudah dimunculkan,
yang kemudian dirangkum pada akhir pertemuan
sehingga dihasilkan daftar masalah kajian. Sebagai
tambahan, laporan rangkuman kajian yang sederhana
telah diselesaikan di mana rangkuman kajian
merupakan jawaban dari tiga pertanyaan berikut:
1. Apa yang dikaji ?
2. Siapa yang melakukan?
3. penemuan apa yang dihasilkan dan apa
kesimpulannya?
Daftar masalah kajian mempunyai dua tujuan:
1. Mengidentifikasi area masalah pada produk,
2. Daftar item kegiatan yang menjadi petunjuk bagi
prosedur saat koreksi dilakukan.
Daftar masalah biasanya dilampirkan pada laporan.
Pedoman Kajian
Pedoman untuk melakukan kajian teknis formal harus
dilakukan sebelumnya, didistribusikan kepada semua
pengkaji, disetujui, dan kemudian dilaksanakan.
Kajian yang tidak terkontrol sering dapat menjadi lebih
buruk daripada bila tidak ada kajian sama sekali.
Berikut ini serangkaian pedoman minimum untuk
kajian teknis formal:
1. Kajian produk, bukan produser.
2. Menetapkan agenda dan menjaganya.
3. Membatasi perdebatan dan bantahan.
B
y

H
e
n
d
r
a
N
e
t
Page 115 / 146
4. Menetapkan area masalah, tetapi tidak tergoda
untuk menyelesaikannya setiap masalah yang
dicatat.
5. Mengambil catatan tertulis.
6. Membatasi jumlah peserta dan mewajibkan
persiapan awal.
7. Mengembangkan daftar bagi masing-
masing produk kerja yang akan dikaji.
8. Mengalokasikan sumber-sumber daya dan
jadwal waktu untuk FTR.
9. Melakukan pelatihan bagi semua pengkaji.
10. Mengkaji kajian awal Anda.
PENDEKATAN FORMAL TERHADAP SQA
Kualitas perangat lunak merupakan tugas setiap
orang & kualitas dapat dicapai melalui analisis,
desain, pengkodean, dan pengujian yang baik serta
aplikasi standar pengembangan perangkat lunak yang
diterima.
Pada lebuh dari dua dekade, segmen komunitas
rekayasa perangkat lunak yang kecil tetapi vokal telah
memperlihatkan bahwa dibutuhkan suatu pendekatan
yang lebih formal terhadap jaminan kualitas perangkat
lunak.
Pembuktian matematis terhadap kebenarannya
dapat diaplikasikan untuk menunjukkan bahwa
program menyesuaikan diri secara tepat dengan
spesifikasinya.
JAMINAN KUALITAS STATISTIK (SQA)
Jaminan kualitas statistik mencerminkan trend yang
sedang tumbuh di seluruh industri untuk menjadi lebih
kuantitatif terhadap kualitas.
B
y

H
e
n
d
r
a
N
e
t
Page 116 / 146
Pada perangkat lunak, jaminan kualitas statistik
mengimplikasikan langkah-langkah berikut ini:
1. Informasi tentang cacat perangkat lunak
dikumpulkan dan dipilah-pilahkan.
2. Melakukan suatu usaha untuk menelusuri
masing-masing cacat sampai ke penyebab
pokoknya.
3. Dengan menggunakan prinsip Pareto (80 persen
cacat dapat ditelusuri sampai 20 persen dari
semua kemungkinan penyebab), mengisolasi
yang 20 persen tersebut (vital few)
4. Sekali penyebab vital few telah diidentifikasi,
beralih untuk membetulkan maslah yang
menyebabkan cacat.
Banyak kesalahan ditemukan pada waktu
perangkat lunak sedang dalam proses
pengembangan. Cacat yang lain ditemukan setelah
perangkat lunak diluncurkan kepada pemakai akhir.
Meskipun ratusan kesalahan yang berbeda
diluncurkan, semuanya dapat ditelusuri dari satu (atau
lebih) penyebab berikut ini :
Spesifikasi yang tidak lengkap atau keliru (IES)
Kesalahan interpretasi komunikasi pelanggan
(MMC)
Deviasi intersioanl dari spesifikasi (IDS)
Pelanggaran standar pemrograman (VPS)
Kesalahan dalam representasi data (EDRIMI)
Kesalahan dalam logika desain (EDL)
Interface modul yang tidak konsisten (IMI)
Pengujian yang tidak lengkap atau keliru (IET)
Dokumentasi yang tidak lengkap atau tidak
akurat (IID)
Kesalahan dalam penerjemahan bahasa
pemrograman desain (PLT)
B
y

H
e
n
d
r
a
N
e
t
Page 117 / 146
Antarmuka manusia dengan komputer yang tidak
konsisten atau mengandung ambiguitas (HCI)
Dan msih banyak lagi (MIS)
RELIABILITAS PERANGKAT LUNAK
Reliabilitas perangkat lunak, tidak seperti faktor
kualitas yang lain, dapat diukur, diarahan, dan
diestimasi dengan menggunakan data
pengembangan historis. Reliabilitas perangkat lunak
didefinisikan dalam bentuk statistik sebagai
kemungkinan operasi program komputer bebas
kegagalan di dalam suatu lingkungan tertentu dan
waktu tertentu.
Kapan saja reliabilitas perangkat lunak
dibicarakan, selalu muncul pertanyaan yang sangat
penting : Apa yang dimaksudkan dengan bentuk
kegagalan? dalam konteks dan banyak diskusi
mengenai kualitas dan reliabilitas perangkat lunak,
kegagalann adalah ketidaksesuaian dengan
kebutuhan perangkat lunak.
Kegagalan hanya akan mengganggu atau
bahkan merupakan bencana. Satu kegagalan dapat
diperbaiki dalam beberapa detik sementara kesalahan
yang lain mungkin membutuhkan waktu pembetulan
berminggu-minggu atau bahkan berbulan-bulan.
Pembetulan satu kegagalan kenyataannya dapat
menghasilkan kesalahan lain yang baru yang
mungkin akan membawa lagi kesalahan yang lain
lagi.
Pengukuran Reliabilitas dan Availabilitas
Kerja awal dalam reliabilitas perangkat lunak
berusaha mengekstrapolasi matematika teori
reliabitas perangkat keras. Sebagian besar model
reliabilitas yang berhubungan dengan perangkat
B
y

H
e
n
d
r
a
N
e
t
Page 118 / 146
keras didasarkan pada kegagalan sehubungan
dengan keusangan (wear), bukan kesalahan karena
cacat desain. Dalam perangkat keras, kegagalan
sehubungan dengan keusangan fisik (misalnya
pengaruh suhu, korosi, kejutan) lebih banyak terjadi
daripada kegagalan karena isu. Akan tetapi, yang
terjadi pada perangkat lunak adalah hal yang
sebaliknya. Kenyataannya, semua kegagalan
perangkat lunak dapat ditelusuri ke dalam desain atau
masalah implementasi; keusangan tidak tercakup.
Masih ada perdebatan yang terjadi di seputar
hubunan antara konsep kunci dalam reliabilitas
perangkat keras dan kemampuan aplikasinya
terhadap perangkat lunak.
Meskipun ada hubungan yang tidak dapat
dibantah, namun sangat penting untuk
memprtimbangkan beberapa konsep sederhana yang
berlaku untuk kedua sistem elemen tersebut.
Bila kita andaikan suatu sistem yang berbasis
komputer, pengukuran reliabilitas secara sederhana
adalah berupa mean time between failure (MTBF),
dimana :
MTBF = MTTF + MTTR
(Akronim MTTF adalah mean time to failure dan MTR
berarti mean time to repair.)
Banyak peneliti berpendapat bahwa MTBF
merupakan pengukuran yang jauh lebih berguna
daripada pengukuran cacat/KLOC. Secara sederhana
dapat dikatakan bahwa seorang pemakai akhir lebih
memperhatikan kegagalan, bukan jumlah cacat.
Karena masing-masing cacat yangada pada sebuah
program tidak memiliki tingkat kegagalan yang sama,
maka penghitungan cacat total hanya memberikan
sedikit indikasi tentang reliabilitas sistem.
B
y

H
e
n
d
r
a
N
e
t
Page 119 / 146
Contohnya adalah sebuah program yang telah
beroperasi selama 14 bulan. Banyak cacat mungkin
tidak terdeteksi dalam jumlah waktu yang lama
sampai pada akhirnya cacat itu ditemukan. MTBF dari
cacat yang tidak jelas seperti itu dapat berlangsung
sampai 50, bahkan 100 tahun. Cacat yang lain, yang
juga belum ditemukan, dapat memiliki tingkat
kegagalan 18 atau 24 bulan. Meskipun setiap kategori
pertama cacat (yang memiliki MTBF panjang)
dihilangkan, pengaruhnya pada reliabilitas perangkat
lunak tidak dapat diabaikan.
Availabilitas perangkat lunak adalah
kemungkinan sebuah program beroperasi sesuai
dengan kebutuhan pada suatu titik yang diberikan
pada suatu waktu dan didefinisikan sebagai :
Availabilitas = MTTF / (MTTF + MTTR) x 100 %
Pengukuran reliabilitas MTBF sama sensitifnya
dengan MTTF dan MTTR. Pengukuran availabilitas
jauh lebih sensitif daripada MTTR, yang merupakan
pengukuran tidak langsung terhadap kemampuan
pemeliharaan perangkat lunak.
Keamanan Perangkat Lunak dan Analisis Risiko
Leveson membicarakan pengaruh perangkat lunak
dalam sistem kritis keamanan ketika menulis :
Sebelum perangkat lunak digunakan di dalam
sistem kritis keamanan, perangkat lunak itu
sering dikontrol oleh alat mekanik konvensional
(tidak dapat diprogram) dan elektronik. Teknik
keamanan sistem didesain untuk mengatasi
kegagalan acak dalam sistem-sistem tersebut.
Kesalahan perancangan oleh manusia dapat
sepenuhnya dihindari atau dihilangkan sebelum
B
y

H
e
n
d
r
a
N
e
t
Page 120 / 146
perangkat lunak tersebut diluncurkan dan
dioperasikan.
Ketika perangkat lunak diguanakn sebagai
bagian dari sistem kontrol, kompleksitasnya dapat
bertambah dengan satu urutan besaran atau lebih.
Kesalahan desain yang tidak kentara yang
disebabknan oleh kesalahan manusia sesuatu yang
dapat diunkapkan dan dikurangi dalam kontrol
konvensional berbasis perangkat keras menjadi
lebih sulit ditemukan pada waktu perangkat lunak
digunakan.
Keamanan perangkat lunak dan analisis risiko
adalah aktivitas jaminan kualitas perangkat lunak
yang berfokus pada identifikasi dan penilaian risiko
potensial yang mungkin berpengaruh negatif terhadap
perangkat lunak dan menyebabkan seluruh sistem
menjadi gagal. Jika risiko dapat diidentifikasi pada
awal proses rekayasa perangkat lunak, maka ciri-ciri
desain perangkat lunak dapat ditetapkan sehingga
akan mengeliminasi atau mengontrol risiko potensial.
Proses analisis dan modeling dilakukan sebagai
bagian dari keamanan perangkat lunak. Awalnya,
risiko diidentifikasi dan dipilah-pilahkan berdasarkan
kekritisan dan risiko. Sebagai contoh, beberapa risiko
yang berkaitan dengan kontrol peluncuran berbasis
komputer untuk automobil mungkin:
Menyebabkan percepatan yang tidak terkontrol
tidak dapat dihentikan
Tidak lepas ketika pedal rem ditekan
Tidak nyambung ketika skalar diaktifkan
Perlahan-lahan kehilangan atau menambah
kecepatan
B
y

H
e
n
d
r
a
N
e
t
Page 121 / 146
Setelah risiko tingkat sistem diidentifikasi, maka
digunakan teknik analisis untuk menandai kehebatan
dan probabilitas event. Supaya efektif, perangkat
lunak harus dianalisis dalam konteks keseluruhan
sistem. Sebagai contoh, kesalahan input pemakai
yang tidak kentara (manusia sebagai komponen
sistem) dapat diperbesar oleh kesalahan perangkat
lunak, sehingga menghasilkan data kontrol yang
memposisikan sebuah perangkat lunak, sehingga
menghasilkan data kontrol yang memposisikan
sebuah perangkat mekanik secara tidak tepat. Jika
ada serangkaian kondisi lingkungan eksternal (dan
hanya jika mereka ditemui), maka posisi perangkat
mekanik yang tidak tepat dapat menyebabkan
kegagalan fatal. Teknik analisis seperti analisis pohon
kegagalan, logika real-time , atau model Petrinet ,
dapat digunakan untuk memprediksi rantai event yang
dapat mengakibatkan risiko dan kemungkinan di
mana setiap event akan terjadi untuk menciptakan
rantai.
Analisis pohon kesalahan membangun model
grafis dan kombinasi event yang konkuren dan
berurutan yang dapat menyebabkan suatu event atau
sistem yang penuh risiko. Dengan menggunakan
pohon kesalahan yang dikembangkan dengan baik,
maka dimungkinkan untuk meneliti kosekuensi urutan
kegagalan yang terinterelasi yang terjadi pada
komponen sistem yang berbeda. Logika real-time
(RTL) membangun sebuah model sistem dengan
menentukan event dan aksi yang sesuai. Model
event-action dapat dianalisis dengan menggunakan
operasi logika untuk menguji tuntutan keamanan
seputar komponen sistem dan timing-nya. Model
Petrinet dapat digunakan untuk menentukan
kesalahan yang paling berisiko.
B
y

H
e
n
d
r
a
N
e
t
Page 122 / 146
Sekali risiko diidentifikasi dan dianalisis, maka
keamanan yang berhubungan dengan kebutuhan
untuk perangkat lunak dapat ditetapkan. Spesifikasi
dapat berupa sederetan event yang tidak diinginkan
dan sistem yang diinginkan merespon event tersebut.
Peran perangkat lunak dalam mengatur event yang
tidak diinginkan kemudian diindikasi.
Meskipun reliabilitas perangkat lunak
berhubungan erat satu sama lain dengan lainnya,
namun sangat penting untuk memahami perbedaan
tipis yang ada di antara mereka. Reliabilitas
perangkat lunak menggunakan analisis statistik untuk
menentukan kemungkinan terjadinya kegagalan
perangkat lunak. Tetapi kegagalan tidak perlu
menghasilkan risiko atau kecelakaan. Kemanan
perangkat lunak mengamati bagaimana kegagalan
menimbulkan keadaan yang dapat menyebabkan
kecelakaan. Kegagalan tidak perlu dipertimbangkan di
dalam ruang hampa, tetapi dievaluasi dalam konteks
keseluruhan sistem berbasis komputer.
Diskusi komprehensif tentang analisis risiko dan
keamanan perangkat lunak tidak masuk dalam ruang
lingkup buku ini. Pembaca yang tertarik untuk
mengetahui lebih jauh tentang hal tersebut sebaiknya
membaca buku yang ditulis oleh Leveson .
RENCANA SQA
SQA plan menjadi peta jalan untuk membangun
jaminan kualitas perangkat lunak. Dikembangkan oleh
kelompok SQA dan tim proyek, rencana itu berfungsi
sebagai template bagi aktifitas SQA yang dibangun
untuk setiap proyek perangkat lunak.
Gambar 8.5 memperlihatkan sebuah outline
untuk rencana SQA yang disetujui oleh IEEE . Bagian
B
y

H
e
n
d
r
a
N
e
t
Page 123 / 146
awal menggambarkan tujuan dan ruang lingkup
dokumen dan menunjukkan aktivitas proses
perangkat lunak yang diungkap oleh jaminan kualitas.
Semua dokumen yang dicatat oleh rencana SQA
didaftar dan semua standar yang dapat diapliksikan
dicatat. Bagian Manajemen dari rencana tersebut
menggambarkan tempat SQA pada struktur
organisasi; tugas-tugas dan aktivitas SQA dan
penempatannya di seluruh proses perangkat lunak;
dan peran organisasional serta tanggung jawab relatif
terhadap kualitas produk.
Bagian Dokumentasi menggambarkan (dengan
refernsi) masing-masing produk kerja yang dihasilkan
sebagai bagian dari proses perangkat lunak;
mencakup hal-hal berikut :
Dokumen proyek (misalnya, rencana proyek)
Model (misalnya, hirarki kelas ERD)
Dokumen teknis (misalnya, spesifikasi, rencana
pengujian)
Dokumen pemakai (misalnya file0file help)
Sebagai tambahan, bagian ini menentukan
serangkaian produk kerja minmum yang dapat
diterima untuk mencapai kualitas yang tinggi.
Standar, Praktik dan Konversi mencatat semua
standar/praktik yang diterapkan selama proses
perangkat lunak (misalnya, standar dokumen, stadar
pengkodean, dan pedoman kajian). Semua proyek,
proses, dan metrik produk yang dikumpulkan sebagai
bagian dari usaha rekayasa perangkat lunak juga
harus dicatat.
Bagian Kajian dan Audit dari rencana
mengidentifiaksi kajian dan audit yang akan dilakukan
oleh tim rekayasa perangkat lunak, kelompok SQA,
B
y

H
e
n
d
r
a
N
e
t
Page 124 / 146
dan pelanggan. Bagian ini memberikan gambaran
yang luas terhadap pendekatan bagi masing-masig
kajian dan audit.
I. Tujuan Rencana
II. Referensi
III. Manajemen
1. Organisasi
2. Tugas
3. Tanggung jawab
IV. Dokumentasi
1. Tujuan
2. Dokuen rekayasa perangkat lunak yang diperlukan
3. Dokumen-dokumen lain
V. Standar, Praktis dan Konversi
1. Tujuan
2. Konvensi
VI. Tinjauan dan Audit
1. Tujuan
2. Tinjauan
a. Kebutuhan perangkat lunak
b. Desain
c. Verifikasi dan validasi perangkat lunak
d. Audit fungsional
e. Audit fisik
f. Audit in-process
g. Manajemen
VII. Pengujian
VIII. Pelaporan Masalah dan Tindakan Koreksi
IX. Peranti, Teknik, dan Metodologi
X. Kontrol Kode
XI. Kontrol Media
XII. Kontrol Pemasok
XIII. Pengumpulan, Pemeliharaan, dan Penyimpanan Catatan
XIV. Pelatihan
XV. Manajemen Risiko
Gambar 8.5 Rencana kualitas jaminan perangkat
lunak standar ANSI/IEEE 730 1984 dan 983-1986
Bagian pengujian merujuk rencana dan prosedur
pengujian perangkat lunak (Bab17). Bagian ini juga
menentukkan kebutuhan penyimpanan rekaman
pengujian. Pelaporan Masalah dan Tindakan Korektif
menentukan prosedur untuk pelaporan, pelacakan,
B
y

H
e
n
d
r
a
N
e
t
Page 125 / 146
dan pembetulan kesalahan serta cacat, juga
mengidentifikasi tanggung jawab organisaional untuk
akyivitas-aktivitas tersebut.
Bagian akhir rencana SQA adalah mengidentifikasi
peranti dan metode yang mengandung aktifitas dan
tugas-tugas SQA; merujuk manajemen konfigurasi
perangkat lunak untuk mengontrol perubahan;
menetapkan pendekatan manajemen kontrak;
membangun metode perakitan, perlindungan dan
pemeliharaan semua catatan; mengidentifikasi
pelatihan yang dibutuhkan untuk memenuhi
kebutuhan rencana, serta menetapkan metode-
metode untuk mengidentifikasi, menilai, memonitor,
dan mengontrol risiko.
STANDAR KUALITAS ISO 9000
Sistem jaminan kualitas dapat didefinisikan sebagai
strukutr, tanggung jawab, prosedur, proses dan
sumber-sumber daya organisasi untuk
mengimplementasi manajemen kualitas. ISO 9000
menjelaskan elemen jaminan kualitas dalam bentuk
yang umum yang dapat diaplikasikan pada berbagai
bisnis tanpa memandang produk dan jasa yang
ditawarkan.
Agar terdaftar dalam satu model sistem jaminan
kualitas yang ada pada ISO 9000, sistem kualitas dan
operasi perusahaan diperiksa oleh auditor bagian
ketiga untuk memeriksa kesesuaiannya dengan
standar dan operasi efektif. Bila registrasi itu berhasil,
perusahaan diberi sertifikat dari badan registrasi yang
diwakili oleh auditor. Audit pengawasan tegah tahuan
terus dilakukan untuk memastikan kesesuaiannya
dengan standar yang sudah ditetapkan.
B
y

H
e
n
d
r
a
N
e
t
Page 126 / 146
Pendekatan ISO terhadap Sistem Jaminan
Kualitas
Model jaminan kualitas ISO 9000 memperlakukan
perusahaan sebagai jaringan proses yang saling
terhubung (interkoneksi). Suatu sistem kualitas,
supaya sesuai dengan ISO, proses-prosesnya harus
menekankan pada area yang telah diidentifikasi pada
standar ISO, dan harus didokumentasi dan
dipraktikan sebagimana dikelaskan.
Pendokuemnatsian proses membantu organisasi
untuk memahami, mengontrol, dan mengembangkan
jaringan proses yang mungkin dapat mendatangkan
keuntunagn terbesar bagi organisasi yang merancang
dan mengimplementasikan kualitas yang sesuai
dengan ISO.
ISO 9000 menggambarkan elemen sebuah
sistem jaminan kualitas secara umum. Elemen-
elemen tersebut mencakup struktur, prosedur, proses,
organisasi, dan sumber day ayang dibutuhkan untuk
mehimplementasi rencana kualitas, kontrol kualitas,
jaminan, kualitas, dan pengembangan kualiats. Tetapi
ISO 9000 tidak menggambarkan bagaimanan
organisasi seharusnya mengimpelemnatsi elemen-
elemen kualitas tersebut. Sebagai konsekuensi, ada
tantangan dalam mendesain dan mengimplementasi
suatu sistem jaminan kualitas yang memenuhi
standar dengan produk, layanan dan budaya
perusahaan.
Standar ISO 9001
ISO 9001 adalah standar kualitas yang berkalu untuk
rekayasa perangkat lunak. Standar tersebut berisi 20
syarat yang harus ada untuk mencapai sistem
jaminan kualitas yangefektif. Karena standar ISO
9001 dapat diaplikasikan pada semua disiplin
B
y

H
e
n
d
r
a
N
e
t
Page 127 / 146
rekayasa / engineering, maka dikembangkan
sekumpulan khusus pedoman ISO untuk membantu
menginterpretsi standar untuk digunakan pada proses
perangkat lunak.
Dua puluh syarat yang digambarkan oleh ISO
9001 menekankan topik-topik berikut :
1. Tanggung jawab manajemen
2. Sistem kualitas
3. Kajian kontrak
4. Kontrol desain
5. Kontrol data dan dokumen
6. Pembelian
7. Kontrol terhadap produk yang disuplai oleh
pelanggan
8. Identifikasi dan kemampuan penelusuran
produk
9. Kontrol proses
10. Pemeriksaan dan pengujian
11. Kontrol pemeriksaan, pengukuran, dan
perlengkapan pengujian
12. Pemeriksaan dan status pengujian
13. Kontrol ketudaksesuaian produk
14. Tindakan preventif dan korektif
15. Penanganan, penyimpanan, pengepakan,
preservasi, dan penyampaian
16. Kontrol terhadap catatan kualitas
17. Audit kualitas internal
18. Pelatihan
19. Pelayanan
20. Teknik statistik
B
y

H
e
n
d
r
a
N
e
t
Page 128 / 146
Untuk dapat didaftar dalam ISO 9001, organisasi
perangkat lunak harus membuat kebijakan dan
prosedur yang memberi tekanan pada masing-masing
syarat tersebut dan kemudian dapat menunjukkan
bahwa prosedur dan fungsi itu telah diikuti. Untuk
penjelsan leih lanjt, pembaca yang tertarik dengan
informasi mengnenai ISO 9001.
B
y

H
e
n
d
r
a
N
e
t
Page 129 / 146
BAB 9
PENGUJIAN PERANGKAT LUNAK
Pengujian PL adalah elemen kritis dari jaminan kualitas PL dan
merepresentasikan spesifikasi, desain dan pengkodean.
Meningkatnya visibilitas PL sbg suatu elemen sistem dan "biaya yg muncul
akibat kegagalan PL, memotivasi dilakukan perencanaan yg baik melalui
pengujian yg teliti.
Dalam melakukan uji coba ada 2 masalah penting yang akan dibahas, yaitu :
A. Teknik uji coba PL
B. Strategi uji coba PL
TEKNIK UJI COBA PL
Pada dasarnya, pengujian merupakan suatu proses rekayasa PL yg dapat
dianggap (secara psikologis) sebagai hal yg destruktif daripada
konstruktif.
SASARAN PENGUJIAN (Glen Myers) :
1. Pengujian adalah proses eksekusi suatu program dengan maksud
menemukan kesalahan.
2. Test case yg baik adalah test case yg memiliki probabilitas tinggi
untuk menemukan kesalahan yg belum pernah ditemukan sebalumnya.
3. Pengujian yg sukses adalah pengujian yg mengungkap semua
kesalahan yg belum pernah ditemukan sebelumnya.
PRINSIP PENGUJIAN (diusulkan Davis) :
Semua pengujian harus dapat ditelusuri sampai ke persyaratan
pelanggan.
Pengujian harus direncanakan lama sebelum pengujian itu dimulai.
Prinsip Pareto berlaku untuk pengujian PL. Prinsip Pareto
mengimplikasikan 80% dari semua kesalahan yg ditemukan selama
pengujian sepertinya akan dapat ditelusuri sampai 20% dari semua
modul program.
Pengujian harus mulai "dari yg kecil" dan berkembang ke pengujian
"yang besar".
Pengujian yg mendalam tidak mungkin.
Paling efektif, pengujian dilakukan oleh pihak ketiga yg independen.
B
y

H
e
n
d
r
a
N
e
t
Page 130 / 146
TESTABILITAS
Testabilitas PL adalah seberapa mudah sebuah program komputer
dapat diuji. Karena pengujian sangat sulit, perlu diketahui apa yg dapat
dilakukan untuk membuatnya menjadi mudah.
Karakteristik PL yg diuji :
OPERABILITAS, semakin baik dia bekerja semakin efisien dia dapat
diuji.
OBSERVABILITAS, apa yg anda lihat adalah apa yg anda uji.
KONTROLABILITAS, semakin baik kita dapat mengontrol PL
semakin banyak pengujian yg adapat diotomatisasi dan dioptimalkan.
DEKOMPOSABILITAS, dengan mengontrol ruang lingkup pengujian
kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian
kembali.
KESEDERHANAAN, semakin sedikit yg diuji semakin cepat
pengujian.
STABILITAS, semakin sedikit perubahan semakin sedikit gangguan
pengujian.
KEMAMPUAN DIPAHAMI, semakin banyak informasi yg dimiliki
semakin detail pengujiannya.
ATRIBUT PENGUJIAN YG BAIK :
Memiliki probabilitas yg tinggi menemukan kesalahan.
Tidak redundan.
Harusnya jenis terbaik.
Tidak boleh terlalu sederhana atau terlalu kompleks.
DESAIN TEST CASE
Terdapat bermacam-macam rancangan metode test case yg dapat
digunakan, semua menyediakan pendekatan sistematis untuk uji coba, yg
terpenting metode menyediakan kemungkinan yg cukup tinggi menemukan
kesalahan.
Terdapat 2 macam test case:
1. Pengetahuan fungsi yg spesifik dari produk yg telah dirancang untuk
diperlihatkan, test dapat dilakukan untuk menilai masing-masing fungsi
apakah telah berjalan sebagaimana yg diharapkan.
2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan
untuk memperlihatkan cara kerja dari produk secara rinci sesuai
dengan spesifikasinya.
B
y

H
e
n
d
r
a
N
e
t
Page 131 / 146
Dua macam pendekatan test yaitu :
1. Black Box Testing
Test case ini bertujuan untuk menunjukkan fungsi PL tentang cara
beroperasinya, apakah pemasukan data keluaran telah berjalan
sebagaimana yang diharapkan dan apakah informasi yang disimpan
secara eksternal selalu dijaga kemutakhirannya.
2. White Box Testing
Adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya
logikal path (jalur logika) perangkat lunak akan ditest dengan
menyediakan test case yang akan mengerjakan kumpulan kondisi dan
atau pengulangan secara spesifik. Secara sekilas dapat diambil
kesimpulan white box testing merupakan petunjuk untuk mendapatkan
program yang benar secara 100%.
UJI COBA WHITE BOX
Uji coba white box adalah metode perancangan test case yang
menggunakan struktur kontrol dari perancangan prosedural untuk
mendapatkan test case. Dengan rnenggunakan metode white box, analis
sistem akan dapat memperoleh test case yang:
menjamin seluruh independent path di dalam modul yang dikerjakan
sekurang-kurangnya sekali
mengerjakan seluruh keputusan logikal
mengerjakan seluruh loop yang sesuai dengan batasannya
mengerjakan seluruh struktur data internal yang menjamin validitas
1. UJI COBA BASIS PATH
Uji coba basis path adalah teknik uji coba white box yg diusulkan
Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan
ukuran kekompleksan logical dari perancangan prosedural dan menggunkan
ukuran ini sbg petunjuk untuk mendefinisikan basis set dari jalur
pengerjaan. Test case yg didapat digunakan untuk mengerjakan basis set
yg menjamin pengerjaan setiap perintah minimal satu kali selama uji coba.
1.1. Notasi diagram alir
Sequence if while until case
Gambar 9.1
B
y

H
e
n
d
r
a
N
e
t
Page 132 / 146
Untuk menggambarkan pemakaian diagram alir diberikan contoh
perancangan prosedural dalam bentuk flowchart
1
6
3
7 8 5
4
2
9
10
11
Gambar 9.2 Diagram Alir
Selanjutnya diagram alir diatas dipetakan ke grafik alir
node
Gambar 9.3 Grafik Alir
Lingkaran/node :
menggambarkan satu/lebih perintah prosedural. Urutan proses dan
keputusan dapat dipetakan dalam satu node.
Tanda panah/edge :
menggambarkan aliran kontrol. Setiap node harus mempunyai tujuan
node
Region :
adalah daerah yg dibatasi oleh edge dan node. Termasuk daerah
diluar grafik alir.
B
y

H
e
n
d
r
a
N
e
t
Page 133 / 146
Contoh menterjemahkan pseudo code ke grafik alir
1: do while record masih ada
baca record
2: if record ke 1 = 0
3: then proses record
simpan di buffer
naikan kounter
4: else if record ke 2 = 0
5 then reser kounter
6 proses record
simpan pada file
7a: endif
endif
7b: enddo
8 : end
Gambar 9.4 Menerjemahkan PDL ke grafik Alir
Nomor pd pseudo code berhubungan dengan nomor node. Apabila
diketemukan kondisi majemuk (compound condition) pada pseudo cade
pembuatan grafik alir menjadi rumit. Kondisi majemuk mungkin terjadi
pada operator Boolean (AND, OR, NAND, NOR) yg dipakai pada perintah
if.
Contoh :
if A or B
then procedure x
else procedure y
endif
Gambar 9.5 Logika Gabungan
B
y

H
e
n
d
r
a
N
e
t
Page 134 / 146
Node dibuat terpisah untuk masing-masing kondisi A dan B dari
pernyataan IF A OR B. Masing-masing node berisi kondisi yg disebut
pridicate node dan mempunyai karakteristik dua atau lebih edge darinya.
1.2. CYCLOMATIC COMPLEXITY
Cyclomatic complexity adalah metrik PL yang menyediakan ukuran
kuantitatif dari kekompleksan logikal program. Apabila digunakan dalam
kontek metode uji coba basis path, nilai yang dihitung untuk cyclomatic
complexity menentukan jumlah jalur independen dalam basis set suatu
program dan memberi batas atas untuk jumlah uji coba yang harus
dikerjakan untuk menjamin bahwa seluruh perintah sekurang-kurangnya
telah dikerjakan sekali.
Jalur independent adalah jalur yang melintasi atau melalui program
dimana sekurang-kurangnya terdapat proses perintah yang baru atau
kondisi yang baru.
Dari gambar 9.3 :
Path 1 : 1 - 11
Path 2 : 1 - 2 - 3 - 4 - 5 - 10 - 1 - 11
Path 3 : 1 - 2 - 3 - 6 - 8 - 9 ...: 10 - 1 - 11
Path 4 ': 1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11
Path 1,2,3,4 yang telah didefinisikan di atas merupakan basis set untuk
diagaram alir.
Cyclomatic complexity digunakan untuk mencari jumlah path dalam satu
flowgraph. Dapat dipergunakan rumusan sbb :
1. Jumlah region grafik alir sesuai dengan cyclomatic complexity.
2. Cyclomatix complexity V(G) untuk grafik alir dihitung dengan rumus:
V(G) = E - N + 2
dimana:
E = jumlah edge pada grafik alir
N = jumlah node pada grafik alir
3. Cyclomatix complexity V(G) juga dapat dihitung dengan rumus:
V(G) = P + 1
dimana P = jumlah predicate node pada grafik alir
Pada Gambar 9.3 dapat dihitung cyclomatic complexity:
1. Flowgraph mempunyai 4 region
2. V(G) = 11 edge - 9 node + 2 = 4
3. V(G) = 3 predicate node + 1 = 4
Jadi cyclomatic complexity untuk flowgraph Gambar 9.3 adalah 4
B
y

H
e
n
d
r
a
N
e
t
Page 135 / 146
1.3. MELAKUKAN TEST CASE
Metode uji coba basis path juga dapat diterapkan pada perancangan
prosedural rinci atau program sumber. Pada bagian ini akan dijelaskan
langkah-langkah uji coba basis path. Prosedur rata-rata pada bagian
berikut akan digunakan sebagai contoh dalam pembuatan test case.
PROCEDURE RATA-RATA
INTERFACE RESULT rata, total, input, total.valid
INTERFACE RESULT nilai, minim, max
TYPE NILAl (1:100) IS SCALAR ARRAY;
TYPE rata, total. input, total.valid, max.minim, jumlah IS SCALAR;
TYPE I IS INTEGER;
I = 1;
total. input = total. valid = 0;
jumlah = 0;
DO WHILE nilai(i) <> -999 .and. total.input < 100
tambahkan total.input dengan 1;
IF nilai(i) >= minimum .and. nilai(i}<=max;
THEN tambahkan total.valid dengan I;
jumlah=jumlah + nilai(i);
ELSE skip;
END IF
tambahkan i dengan 1;
ENDDO
IF total. valid> 0
THEN rata =jumlah/ total. valid;
ELSE rata = -999;
ENDIF
END
Langkah-Iangkah pembuatan test case:
1. Dengan mempergunakan perancangan prosedural atau program sumber
sebagai dasar, digambarkan diagram alirnya.
Gambar 9.6 Diagram Alir prosedur rata
B
y

H
e
n
d
r
a
N
e
t
Page 136 / 146
2. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat:
V(G) = 6 region .
V(G) = 17 edge - 13 node + 2 = 6
V(G) = 5 predicate node + 1 = 6
3. Tentukan independent path pada flowgraph
Dari hasil perhitungan cyclomatic complexity terdapat 6 independent
path yaitu:
path 1 : 1-2-10-11-13
path 2 : 1-2-10-12-13
path 3 : 1-2-3-10-11-13
path 4 : 1-2-3-4-5-8-9-2-..
path 5 : 1-2-3-4-5-6-8-9-2-..
path 6 : 1-2-3-4-5-6-7-8-9-2-...
4. Buat test case yang akan mengerjakan masing-masing path pada basis
set. Data yang dipilih harus tepat sehingga setiap kondisi dari
predicate node dikerjakan semua.
1.4. GRAPH METRIK
Graph metrik merupakan PL yang dikembangkan untuk membantu uji coba
basis path atau struktur data. Graph metrik adalah matrik empat persegi
yang mempunyai ukuran (sejumlah baris dan kolom) yang sama dengan
jumlah node pada flowgraph. Masing-masing baris dan kolom mempunyai
hubungan dengan node yang telah ditentukan dan pemasukan data matrik
berhubungan dengan hubungan (edge) antanode.
Contoh sederhana pemakaian graph matrik dapat digambarkan sbb :
Gambar 9.7. Graph matrik
Pada gambar flowgraph masing-masing node ditandai dengan angka clan
edge dengan huruf kecil, kemudian diterjemahkan ke graph matrik.
Contoh hubungan node 3 dengan node 4 pada graph ditandai dengan huruf
b.
B
y

H
e
n
d
r
a
N
e
t
Page 137 / 146
Hubungan bobot menyediakan tambahan informasi tentang aliran kontrol.
Secara simpel hubungan bobot dapat diberi nilai 1 jika ada hubungan
antara node atau nilai 0 jika tidak ada hubungan. Dapat juga hubungan
bobot diberi tanda dengan:
kemungkinan link (edge) dikerjakan
waktu yang digunakan untuk proses selama traversal dari link
memori yang diperlukan selama traversal link
sumber daya yang diperlukan selama traversal link
Gambar 9.8 Hubungan bobot
Koneksi :
1 1 = 0
2 1 = 1
2 1 = 1
2 1 = 1
3 + 1 = 4 cyclomatic complexity
2. PENGUJIAN LOOP
Loop merupakan kendala yang sering muncul untuk menerapkan algoritma
dengan tepat. Uji coba loop merupakan teknik pengujian white box yg
fokusnya pada validitas dari loop.
Kelas loop yaitu :
a. Loop Sederhana, pengujian loop sederhana dilakukan dgn mudah,
dimana n jumlah maksimum yg diijinkan melewati loop tsb.
1. Lewati loop secara keseluruhan
2. Hanya satu yg dapat melewati loop
3. m dapat melewati loop dimana m< n
b. Loop Tersarang, pengujian loop ini menggunakan pendekatan loop
sederhana. Petunjuk pengujian loop tersarang :
1. Dimulai dari loop paling dalam. Atur semua loop ke nilai minimum.
2. Kerjakan dgn prinsip loop sederhana untuk loop yg paling dalam
sementara tahan loop yg di luar pada parameter terkecil (nilai
kounter terkecil)
B
y

H
e
n
d
r
a
N
e
t
Page 138 / 146
3. Kemudian lanjutkan untuk loop yg diatasnya.
4. Teruskan sampai semua loop selesai di uji.
c. Loop Terangkai, pengujian loop ini menggunakan pendekatan loop
sederhana bila masing-masing loop independen, tetapi bila dua loop
dirangkai dan pencacah loop 1 digunakan sebagai harga awal loop 2 maka
loop tsb jadi tidak independen, maka pendekatan yg diaplikasikan ke
loop tersarang direkomendasikan.
d. Loop Tidak Terstruktur, Kapan saja memungkinkan, loop ini didisain
kembali agar mencerminkan penggunaan komsepsi pemrograman
tertruktur.
Loop tidak
terstruktur
Loop
terangkai
Loop
tersarang
Loop
sederhana
Gambar 9.9. Macam-macam loop
PENGUJIAN BLACK-BOX
Pengujian black-box berfokus pada persyaratan fungsional PL. Pengujian
inimemungkinkan analis system memperoleh kumpulan kondisi input yg
akan mengerjakan seluruh keperluan fungsional program.
Tujuan metode ini mencari kesalaman pada:
Fungsi yg salah atau hilang
Kesalahan pada interface
Kesalahan pada struktur data atau akses database
Kesalahan performansi
Kesalahan inisialisasi dan tujuan akhir
Metode ini tidak terfokus pada struktur kontrol seperti pengujian white-
box tetapi pada domain informasi.
B
y

H
e
n
d
r
a
N
e
t
Page 139 / 146
Pengujian dirancang untuk menjawab pertanyaan sbb:
Bagaimana validitas fungsional diuji?
Apa kelas input yg terbaik untuk uji coba yg baik?
Apakah sistem sangat peka terhadap nilai input tertentu?
Bagaimana jika kelas data yang terbatas dipisahkan?
Bagaimana volume data yg dapat ditoleransi oleh sistem?
Bagaimana pengaruh kombinasi data terhadap pengoperasian
system?
1. EQUIVALENCE PARTITIONING
Equivalence partitioning adalah metode pengujian black-box yg memecah
atau membagi domain input dari program ke dalam kelas-kelas data
sehingga test case dapat diperoleh.
Perancangan test case equivalence partitioning berdasarkan evaluasi kelas
equivalence untuk kondisi input yg menggambarkan kumpulan keadaan yg
valid atau tidak. Kondisi input dapat berupa nilai numeric, range nilai,
kumpulan nilai yg berhubungan atau kondisi Boolean.
Contoh :
Pemeliharaan data untuk aplikasi bank yg sudah diotomatisasikan. Pemakai
dapat memutar nomor telepon bank dengan menggunakan mikro komputer
yg terhubung dengan password yg telah ditentukan dan diikuti dengan
perintah-perintah. Data yg diterima adalah :
Kode area : kosong atau 3 digit
Prefix : 3 digit atau tidak diawali 0 atau 1
Suffix : 4 digit
Password : 6 digit alfanumerik
Perintah : check, deposit, dll
Selanjutnya kondisi input digabungkan dengan masing-masing data elemen
dapat ditentukan sbb :
Kode area : kondisi input, Boolean kode area mungkin ada atau tidak
kondisi input, range nilai ditentukan antara 200 dan 999
Prefix : kondisi input range > 200 atau tidak diawali 0 atau 1
Suffix : kondisi input nilai 4 digit
Password : kondisi input boolean pw mungkin diperlukan atau tidak
kondisi input nilai dengan 6 karakter string
Perintah : kondisi input set berisi perintah-perintah yang telah
didefinisikan
B
y

H
e
n
d
r
a
N
e
t
Page 140 / 146
2. BOUNDARY VALUE ANALYSIS
Untuk permasalahan yg tidak diketahui dg jelas cenderung menimbulkan
kesalahan pada domain outputnya. BVA merupakan pilihan test case yg
mengerjakan nilai yg telah ditentukan, dgn teknik perancangan test case
melengkapi test case equivalence partitioning yg fokusnya pada domain
input. BVA fokusnya pada domain output.
Petunjuk pengujian BVA :
1. Jika kondisi input berupa range yg dibatasi nilai a dan b, test case
harus dirancang dgn nilai a dan b.
2. Jika kondisi input ditentukan dgn sejumlah nilai, test case harus
dikembangkan dgn mengerjakan sampai batas maksimal nilai tsb.
3. Sesuai petunjuk 1 dan 2 untuk kondisi output dirancang test case
sampai jumlah maksimal.
4. Untuk struktur data pada program harus dirancang sampai batas
kemampuan.
STRATEGI PENGUJIAN PL
Strategi uji coba PL memudahkan para perancang untuk menentukan
keberhasilan system yg telah dikerjakan. Hal yg harus diperhatikan
adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan
dengan baik dan berapa lama waktu, upaya dan sumber daya yg
diperlukan.
Strategi uji coba mempunyai karakteristik sbb :
Pengujian mulai pada tingkat modul yg paling bawah, dilanjutkan
dgn modul di atasnya kemudian hasilnya dipadukan.
Teknik pengujian yang berbeda mungkin menghasilakn sedikit
perbedaan (dalam hal waktu)
Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk
proyek yang besar) suatu kelompok pengujian yang independen.
Pengujian dan debugging merupakan aktivitas yang berbeda,
tetapi debugging termasuk dalam strategi pengujian.
Pengujian PL adalah satu elemen dari topik yang lebih luas yang sering
diacu sebagai verifikasi dan validasi (V& V).
Verifikasi : Kumpulan aktifitas yg menjamin penerapan PL benar-benar
sesuai dgn fungsinya.
Validasi : Kumpulan aktivitas yang berbeda yang memastikan bahwa PL
yang dibangun dapat memenuhi keperluan pelanggan.
Dgn kata lain :
Verifikasi : Apakah kita membuat produk dgn benar?
Validasi : Apakah kita membuat benar-benar suatu produk?
B
y

H
e
n
d
r
a
N
e
t
Page 141 / 146
Definisi dari V&V meliputi berbagai aktivitas yang kita rujuk sebagai
jaminan kualias PL (SQA).
Pengujian merupakan salah satu tugas yg ada dlm arus siklus
pengembangan system yg dapat digambarkan dalam bentuk spiral :
Rekayasa sistem
Persyaratan
Desain
Kode
Tes unit
Tes integrasi
Tes validasi
Tes sistem
Gambar 9.10. Strategi Uji Coba
1. PENGUJIAN UNIT
Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit
terkecil dari desain PL, yakni modul. Uji coba unit selalu berorientasi pada
white box testing dan dapat dikerjakan paralel ayau beruntun dengan
modul lainnya.
1.1 Pertimbangan Pengujian Unit
Interface diuji cobakan untuk menjamin informasi yg masuk atau yg ke
luar dari unit program telah tepat atau sesuai dgn yg diharapkan. Yg
pertama diuji coba adalah interface karena diperlukan untuk jalannya
informasi atau data antar modul.
Myers mengusulkan checklist untuk pengujian interface:
Apakahjumlah parameter input sama dengan jumlah argumen?
Apakah antara atribut dan parameter argumen sudah cocok?
Apakah antara sistem satuan parameter dan argumen sudah cocok?
Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil
sama dengan jumlah parameter?
Apakah atribut dari argumen yang ditransmisikan ke modul yang
dipanggil sama dengan atribut parameter?
Apakah sistem unit dari argumen yang ditransmisikan ke modul yang
dipanggil sama dengan sistem satuan parameter?
Apakah jumlah atribut dari urutan argumen ke fungsi-fungsi built-in
sudah benar?
B
y

H
e
n
d
r
a
N
e
t
Page 142 / 146
Adakah referensi ke parameter yang tidak sesuai dengan pain entri
yang ada?
Apakah argumen input-only diubah?
Apakah definisi variabel global konsisten dengan modul?
Apakah batasan yang dilalui merupakan argumen?
Bila sebuah modul melakukan I/O ekstemal, maka pengujian interface
tambahan harus dilakukan.
Atribut file sudah benar?
Pemyataan OPEN/CLOSE sudah benar?
Spesifikasi format sudah cocok dengan pernyataan I/O?
Ukuran buffer sudah cocok dengan ukuran rekaman?
File dibuka sebelum penggunaan?
Apakah kondisi End-of-File ditangani?
Kesalahan I/O ditangani?
Adakah kesalahan tekstual di dalam informasi output?
Kesalahan yang umum di dalam komputasi adalah:
kesalah-pahaman atau prosedur aritmatik yang tidak benar
operasi mode yang tercampur
inisialisasi yang tidak benar
inakurasi ketelitian
representasi simbolis yang tidak benar dari sebuah persamaan.
Test case harus mengungkap kesalahan seperti
perbandingan tipe data yang berbeda
preseden atau operator logika yang tidak benar
pengharapan akan persamaan bila precision error membuat per-
samaan yang tidak mungkin
perbandingan atau variabel yang tidak benar
penghentian loop yang tidak ada atau tidak teratur
kegagalan untuk keluar pada saat terjadi iterasi divergen
variabel loop yang dimodifikasi secara tidak teratur.
1.2. Prosedur Pengujian Unit
Program sumber telah dikembangkan, ditunjang kembali dan
diverifikasi untuk sintaksnya, maka perancangan test case dimulai.
Peninjauan kembali perancangan informasi akan menyediakan petunjuk
untuk menentukan test case. Karena modul bukan program yg berdiri
sendiri maka driver (pengendali) dan atau stub PL harus dikembangkan
untuk pengujian unit.
B
y

H
e
n
d
r
a
N
e
t
Page 143 / 146
Driver adl program yg menerima data untuk test case dan menyalurkan
ke modul yg diuji dan mencetak hasilnya.
Stub melayani pemindahan modul yg akan dipanggil untuk diuji.
2. PENGUJIAN INTEGRASI
Pengujian terintegrasi adl teknik yg sistematis untuk penyusunan struktur
program, pada saat bersamaan dikerjakan uji coba untuk memeriksa
kesalahan yg nantinya digabungkan dengan interface.
Metode pengujian
top down integration
buttom up integration
2.1. TOP DOWN INTEGRATION
Merupakan pendekatan inkrmental untuk penyusunan struktur program.
Modul dipadukan dgn bergerak ke bawah melalui kontrol hirarki dimulai
dari modul utama.
Modul subordinat ke modul kontrol utama digabungkan ke dalam struktur
baik menurut depth first atau breadth first.
Proses integrasi:
modul utama digunakan sebagai test driver dan stub yg
menggantikan seluruh modul yg secara langsung berada di bawah
modul kontrol utama.
Tergantung pada pendekatan perpaduan yg dipilih (depth / breadth)
Uji coba dilakukan selama masing-masing modul dipadukan
Pada penyelesaian masing-masing uji coba stub yg lain dipindahkan
dgn modul sebenarnya.
Uji coba regression yaitu pengulangan pengujian untuk mencari
kesalahan lain yg mungkin muncul.
2.2. BOTTOM UP INTEGRATION
Pengujian buttom up dinyatakan dgn penyusunan yg dimulai dan
diujicobakan dgn atomic modul (yi modul tingkat paling bawah pd struktur
program). Karena modul dipadukan dari bawah ke atas, proses yg
diperlukan untuk modul subordinat yg selalu diberikan harus ada dan
diperlukan untuk stub yg akan dihilangkan.
B
y

H
e
n
d
r
a
N
e
t
Page 144 / 146
Strategi pengujian :
Modul tingkat bawah digabungkan ke dalam cluster yg
memperlihatkan subfungsi PL
Driver (program kontrol pengujian) ditulis untuk mengatur input test
case dan output
Cluster diuji
Driver diganti dan cluster yg dikombinasikan dipindahkan ke atas
pada struktur program
fgd
Cluster 1
Gambar 9.11. Buttom Up Integration
3. UJI COBA VALIDASI
Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah
validasi terting. Pengujian validasi dikatakan berhasil bila fungsi yg ada
pada PL sesuai dgn yg diharapkan pemakai.
Validasi PL merupakan kumpulan seri uji coba black box yg menunjukkan
sesuai dgn yg diperlukan.
Kemungkinan kondisi setelah pengujian:
1. Karakteristik performansi fungsi sesuai dgn spesifikasi dan dapat
diterima.
2. Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar
penyimpangan.
Pengujian BETA dan ALPHA
Apabila PL dibuat untuk pelanggan maka dapat dilakukan aceeptance test
sehingga memungkinkan pelanggan untuk memvalidasi seluruh keperluan.
Test ini dilakukan karena memungkinkan pelanggan menemukan kesalahan
yg lebih rinci dan membiasakan pelanggan memahami PL yg telah dibuat.
B
y

H
e
n
d
r
a
N
e
t
Page 145 / 146
Pengujian Alpha
Dilakukan pada sisi pengembang oleh seorang pelanggan. PL digunakan
pada setting yg natural dgn pengembang yg memandang melalui bahu
pemakai dan merekam semua kesalahan dan masalah pemakaian.
Pengujian Beta
Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir PL dalam
lingkungan yg sebenarnya, pengembang biasanya tidak ada pada pengujian
ini. Pelanggan merekan semua masalah (real atau imajiner) yg ditemui
selama pengujian dan melaporkan pada pengembang pada interval waktu
tertentu.
4. UJI COBA SISTEM
Pada akhirnya PL digabungkan dgn elemen system lainnya dan rentetan
perpaduan system dan validasi tes dilakukan. Jika uji coba gagal atau di
luar skope dari proses daur siklus pengembangan system, langkah yg
diambil selama perancangan dan pengujian dapat diperbaiki. Keberhasilan
perpaduan PL dan system yg besar merupakan kuncinya.
Sistem testing merupakan rentetan pengujian yg berbeda-beda dgn
tujuan utama mengerjakan keseluruhan elemen system yg dikembangkan.
4.1. Recovery Testing
Adalah system testing yg memaksa PL mengalami kegagalan dalam
bermacam-macam cara dan memeriksa apakah perbaikan dilakukan dgn
tepat.
4.2. Security Testing
Adalah pengujian yg akan melalukan verifikasi dari mekanisme
perlindungan yg akan dibuat oleh system, melindungi dari hal-hal yg
mungkin terjadi.
4.3. Strees Testing
Dirancang untuk menghadapi situasi yg tidak normal pada saat program
diuji. Testing ini dilakukan oleh system untuk kondisi seperti volume data
yg tidak normal (melebihi atau kurang dari batasan) atau frkkuensi.
B
y

H
e
n
d
r
a
N
e
t
Page 146 / 146

OPTIMIZED-SOFTWARE-ENGINEERING

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

OPTIMIZED-SOFTWARE-ENGINEERING

Diunggah oleh

Hak Cipta:

Format Tersedia

BAB I

Anda mungkin juga menyukai