Embed Size (px)
Citation preview
MODUL REKAYASA PERANGKAT LUNAK
STMIK DHARMAPALA RIAU
1. What and Why Sofware
Engineering ?
I. INTRODUCTION TO SOFTWARE ENGINEERING
1.1 Software Engineering (Rekayasa Perangkat Lunak)
Ekonomi dari semua bangsa-bangsa maju tergantung pada perangkat lunak
Semakin banyak sistem yang dikendalikan oleh perangkat lunak
Rekayasa Perangkat Lunak mempunyai kaitan dengan teori, metode, dan perkakas (tools) untuk pengembangan perangkat lunak profesional
Rekayasa Perangkat Lunak sudah menjadi bagian yang penting untuk menghadirkan pendapatan nasional pada semua negara maju
1.2 Software Costs (Biaya-Biaya Perangkat Lunak)
Biaya-biaya perangkat lunak sering mendominasi biaya-biaya sistem. Biaya-biaya perangkat lunak pada suatu PC sering lebih besar dari harga perangkat keras.
Biaya-biaya perawatan perangkat lunak lebih besar dibanding dengan pengembangan perangkat lunak, karena sistem dengan masa pakai lama, biaya pemeliharaan mungkin beberapa kali biaya-biaya pengembangan.
Rekayasa Perangkat Lunak mempunyai kaitan dengan biaya-biaya pengembangan perangkat lunak yang ekonomis.
1.3 FAQs about Software Engineering (Pertanyaan-pertanyaan Seputar SE)
Apakah software itu?
Apakah software engineering itu?
Apa perbedaan antara software engineering dan computer science?
Apa perbedaan antara software engineering dan system engineering?
Apakah software process itu?
Apakah software process model itu?
FAQs about Software Engineering (Lanjutan)
Apa saja yang merupakan biaya-biaya rekayasa perangkat
lunak itu?
Apa saja metode rekayasa perangkat lunak itu?
Apakah CASE (Computer-Aided Software Engineering) itu?
Apa saja atribut dari perangkat lunak yang baik?
Apakah yang merupakan tantangan kunci dalam
menghadapi rekayasa perangkat lunak?
What is software?
perintah (program komputer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan;
struktur data yang memungkinkan program memanipulasi informasi secara proporsional; dan
dokumen yang menggambarkan operasi dan kegunaan program.
Produk Perangkat lunak mungkin :
Generic (Umum) - yang dikembangkan untuk dijual ke bidang pelanggan berbeda;
Bespoke/Custom (Pesanan) - dikembangkan untuk pelanggan tunggal menurut spesifikasi mereka.
What is software engineering?
Software engineering adalah suatu disiplin rekayasa (rancang-bangun) yang terkait dengan semua aspek produksi perangkat lunak.
Engineer perangkat lunak mengadopsi pendekatan sistematis dan terorganisir untuk pekerjaan mereka dan menggunakan teknik dan tools yang disesuaikan dengan masalah yang dihadapi untuk dipecahkan, batasan pengembangan, dan sumber daya tersedia.
IEEE Definition(IEEE = Institute of Electrical and Electronic Engineers)
Software engineering adalah:
1. Aplikasi dari sebuah pendekatan yang bersifat kuantifiabel, disiplin, dan
sistematis bagi pengembangan, operasi, dan pemeliharaan perangkat
lunak.
2. Studi tentang pendekatan-pendekatan seperti pada (1)
Bidang Penelitian Software Engineering mengacu pada kedua hal tsb.
What is the difference between software engineeringand computer science?
Computer science mempunyai kaitan dengan theory and fundamentals; software
engineering mempunyai kaitan dengan practicalities of developing and delivering
useful software.
Computer science sekarang ini tidak cukup lengkap untuk bertindak sebagai
tiang penyokong software engineering.
What is the difference between software engineering and system engineering?
System engineering mempunyai kaitan dengan semua aspek
pengembangan sistem berbasis-komputer yang mencakup
perangkat keras, perangkat lunak ,dan yang terkait
dengan proses bisnis.
Software engineering berkonsentrasi pada komponen
perangkat lunak sistem yang lebih besar.
System engineers mencakup spesifikasi sistem, desain
arsitektur, pengintegrasian, dan penyebaran.
What is a software process?
Software process merupakan himpunan aktivitas tujuan pengembangan atau evolusi perangkat lunak.
Aktivitas umum dalam semua proses perangkat lunak adalah:
Specification (Spesifikasi)- hal-hal yang diperlukan oleh sistem dan batasan pengembangannya.
Development (Pengembangan)- produksi sistem perangkat lunak.
Validation (Pengesahan) - pemeriksaan perangkat lunak sesuai dengan keinginan pelanggan.
Evolution (Evolusi) - pengubahan perangkat lunak sesuai dengan permintaan pelanggan.
What is
a software process model? Software process model merupakan representasi
sederhana suatu software process, yang diperkenalkan dari suatu perspektif spesifik.
Contoh perspektif proses adalah
Workflow Perspektif - Urutan aktivitas
Data-Flow Perspektif - Arus Informasi
Role/Action Perspektif – Peran dan Aksi
Proses umum model
Waterfall
Evolutionary development
Formal transformation
Integration from reusable components
What are the costs of software engineering?
Perkiraan kasar adalah 60% untuk biaya pengembangan, sedangkan
40% untuk biaya pengujian. Untuk custom sofware, biaya-biaya
evolusi sering melebihi biaya-biaya pengembangan.
Biaya-biaya berubah-ubah tergantung pada jenis sistem yang
dikembangkan dan kebutuhan atribut sistem seperti kehandalan
dan reliabilitas sistem.
Distribusi biaya-biaya tergantung pada model pengembangan yang
digunakan.
What are software engineering
methods?Software engineering methods merupakan
pendekatan terstruktur dalam pengembangan perangkat lunak yang meliputi model sistem, notasi, aturan, desain advice, dan panduan proses.
Model Descriptions (Uraian Model)
Uraian tentang model grafis yang harus diproduksi.
Rules (Aturan-aturan)
Batasan yang berlaku pada model sistem.
Recommendations (Rekomendasi)
Rekomendasi untuk praktik desain yang baik.
Process guidance (Panduan Proses)
Aktivitas yang mengikuti.
What is CASE (Computer-Aided Software Engineering)?
CASE adalah System software yang digunakan untuk mendukung
otomatisasi aktivitas proses perangkat lunak. CASE sering digunakan
untuk mendukung metode.
Upper-Case
Tools untuk mendukung aktivitas proses awal kebutuhan dan desain.
Lower-Case
Tools untuk mendukung aktivitas selanjutnya seperti programming,
debugging, dan testing.
What are the attributes of good
software?Software perlu memiliki fungsi kebutuhan dan kemampuan yang
diperlukan oleh pemakai dan harus maintainable, dependable , efficient, dan usable.
Maintainability
Software harus dapat ditingkatkan dan diubah sesuai dengan kebutuhan.
Dependability
Software harus dapat dipercaya (trustworthy).
Efficiency
Software seharusnya tidak membuat penggunaan sumber daya sistem menjadi boros.
Usability
Software harus dapat dipakai oleh para pemakai yang direncanakan.
What are the key challenges facing
software engineering?
Tantangan : mengatasi sistem warisan (legacy systems), meningkatnya heterogenitas (Heterogenity) sistem, dan
tuntutan permintaan percepatan penyerahan(Delivery)sistem.
Legacy systems
Sistem warisan (sistem lama) harus dirawat dan dibaharui.
Heterogenity
Sistem terdistribusikan dalam bentuk campuran antara
perangkat keras dan lunak.
Delivery
Adanya peningkatan tekanan untuk penyerahan perangkat
lunak lebih cepat.
1.4 Professional and Ethical
Responsibility
Software engineering melibatkan tanggung-jawab lebih luas dibanding hanya aplikasi kecakapan teknis.
Software engineer harus bertindak secara etis, bertanggung jawab, dan jujurjika mereka diharapkan untuk terhormat sebagai seorang profesional.
Perilaku etis tidak hanya sekedar menegakkan hukum saja tetapi harus lebih dari itu (lih. hal. berikutnya).
Issues of professional responsibility
Confidentiality (Kerahasiaan)
Engineer seharusnya menghormati kerahasiaan dari
klien mereka tanpa tergantung dengan ya atau
tidaknya suatu persetujuan kerahasiaan formal
ditandatangani.
Competence (Kemampuan)
Engineer mestinya tidak salah menggambarkan
tingkatan kemampuannya. Mereka mestinya tidak
dengan sadar menerima pekerjaan yang di luar
kemampuannya.
Issues of professional responsibility
(lanjutan)
Intellectual property rights (Hak milik intelektual)
Engineers harus sadar akan hukum lokal yang mengatur penggunaan dari properti intelektual seperti hak paten, hak cipta, dll. Mereka harus seksama untuk memastikan bahwa intelektual properti klien harus dilindungi.
Computer misuse (Penyalahgunaan Komputer)
Software engineers mestinya tidak menggunakan kecakapan teknis mereka untuk menyalahgunakan komputer orang lain. Penyalahgunaan komputer dari yang relatif sepele (misal untuk bermain game) sampai yang serius (pemberian virus).
***
2.1 The Evolving Role of Software
Peran Perangkat Lunak saat ini:
Berfungsi sebagai sebuah produk
mengantarkan potensi penghitungan yang dibangun oleh perangkat lunak
komputer. Perangkat lunak sebagai transformer informasi yang
memproduksi, mengatur, memperoleh, memodifikasi, menampilkan atau
memancarkan informasi, sehingga pekerjaan menjadi semakin mudah
Berfungsi sebagai kendaraan yang mengantarkan sebuah produk
Dasar untuk kontrol komputer (sistem operasi), komunikasi informasi
(jaringan) dan penciptaan serta kontrol dari program-program lain (piranti
dan lingkungan perangkat lunak)
2.2 Evolution of Software
1st Era 2st Era 3st Era
1950 1960 1970 1980 1990 2000
4st Era
• Batch orientation
• Limited distribution
• Custom software
• Multiuser• Real-time• Database• Product software
• Distributed systems
• Embedded ‘intelligence’
• Low cost hardware
• Powerful desk-top systems
• Object-oriented technologies
• Expert systems• Artificial neural
networks• Parallel computing• Network
computers
2.3 Serangkaian masalah perangkat lunak sehubungan
dengan evolusi sistem berbasis komputer
Kemajuan perangkat keras terus berlanjut melampaui kemampuan engineer dalam membangun perangkat lunak yang sesuai dengan perangkat keras yang ada.
Kemampuan engineer untuk membangun program baru tidak dapat memenuhi kebutuhan akan program baru dan tidak dapat membangun program yang cukup cepat untuk memenuhi kebutuhan bisnis dan pasar.
Pemakaian komputer yang tersebar luas membuat masyarakat semakin tergantung pada operasi perangkat lunak yang reliabel. Kerusakan ekonomi yang besar dan potensi penderitaan manusia dapat muncul bila terjadi kegagalan perangkat lunak.
Kita masih berjuang untuk membangun perangkat lunak komputer dengan reliabilitas dan kualitas yang tinggi.
Kemampuan kita untuk mendukung program yang ada terhambat oleh buruknya desain serta sumber daya yang tidak memadai.
2.4 Software Characteristics
Perangkat lunak lebih merupakan elemen logika dan bukan merupakan elemen fisik, sehingga perangkat lunak memiliki ciri yang berbeda dari perangkat keras.
Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang klasik (manufaktur).
Perangkat lunak tidak pernah usang.
Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat dirakit dari komponen yang sudah ada.
Failure Curve of Hardware
kurva ideal
Tingkat
kegagalan
kematian
segerausang
Waktu
Failure Curve for Software
(idealized)
Tingkat
kegagalan
pada tingkat yang sama
sampai usang
Waktu
Actual Failure Curve for Software
Tingkat
kegagalan
perubahan
laju kegagalan meningkat
sehubungan dengan efek
sampingan
kurva
ideal
kurva
aktual
Waktu
2.5 Software Components
Komponen perangkat lunak adalah informasi yang
tersimpan dalam dua bentuk dasar, yaitu
komponen yang tidak bisa dieksekusi (non
machine executable) dan yang dapat dieksekusi
mesin (machine executable).
Reusability merupakan suatu ciri penting dari
komponen perangkat lunak kualitas tinggi.
2.6. Software Myths
Software Miths (mitos-mitos perangkat lunak) adalah asumsi-
asumsi permasalahan yang kebenarannya tidak dapat
dipertanggungjawabkan berkaitan dengan pengembangan
perangkat lunak
Tiga kelompok yang terkait dalam pengembangan perangkat
lunak
Management : manajer yang bertanggungjawab terhadap
pengembangan perangkat lunak
Customer : pelanggan yang memesan perangkat lunak
Practitioner’s : praktisi yang mengembangkan perangkat
lunak
2.6.1 Management Myths
Dengan memiliki buku berisi standard dan prosedur yang banyak untuk pengembangan perangkat lunak, maka pekerjaan pasti lancar.
Buku-buku itu memang lengkap, tapi apakah digunakan ? Apakah praktisi perangkat lunak sadar dengan keberadaannya. Apakah cocok dengan pengembangan yang modern ? Apakah benar-benar lengkap ?
Untuk menghasilkan perangkat lunak yang berkualitas, maka kita perlu membeli komputer terbaru.
Untuk mendapatkan perangkat lunak yang berkualitas, CASE tools lebih penting daripada perangkat keras.
Bila terlambat maka tambahlah jumlah programer
Penambahan programmer semakin menambah keterlambatan.
2.6.2 Customer Myths
Tujuan sistem secara umum cukup untuk memulai menulis program, rincian belakangan saja.
Definisi awal yang buruk merupakan sebab utama gagalnya kerja perangkat lunak
Rincian kebutuhan sistem sangat penting: fungsi
performance
antar-muka
batasan rancangan
kriteria validasi
dll
Perangkat lunak bersifat fleksibel, perubahan kebutuhan mudah diakomodasi oleh pengembang perangkat lunak
Dampak perubahan sangat bergantung pada tahap mana perubahan terjadi
2.6.3 Practitioner’s Myths
Program selesai, pekerjaan selesai
50% - 70% usaha dihabiskan setelah program diserahkan ke user untuk pertama kalinya.
Kualitas hanya bisa diketahui setelah program berjalan (running)
Kualitas dapat dijaga sejak PL dikembangkan.
Yang diserahkan ke user adalah program
Yang diserahkan adalah program, dokumen, dan data.
***
3.1 Software Engineering Layers
Tools
Methods
Process
Quality
3.2 A Generic View of Software
Engineering
Engineering meliputi kegiatan analisis, desain, konstruksi, verifikasi, dan manajemen kesatuan teknik atau sosial.
Pertanyaan-pertanyaan yang harus dimunculkan dan dijawab:
Apa masalah yang akan dipecahkan?
Karakteristik entitas yang manakah yang dipakai untuk menyelesaikan masalah tersebut?
Bagaimanakah entitas (dan pemecahan) tersebut diadakan?
Bagaimanakah entitas tersebut dibangun?
Pendekatan apakah yang akan dipakai untuk menemukan kesalahan-kesalahan yang dibuat dalam desain dan kontruksi dari entitas tersebut?
Bagaimanakah entitas tersebut ditopang selama proses adaptasi yang lama, pada saat koreksi, serta ketika perbaikan dibutuhkan oleh para pemakai entitas tersebut?
3.3 General Phase to Software
Engineering Definition phase berfokus pada ‘apa’ (what):
informasi yang akan diproses
fungsi dan perfomance yang dibutuhkan
tingkah laku sistem yang diharapkan
interface yang akan dibangun
batasan sistem yang sukses
Development phase berfokus pada ‘bagaimana’ (how):
data dikonstruksikan
fungsi-fungsi diimplementasikan
detail prosedur akan diimplementasikan
interface dikarakterisasi
rancangan akan diterjemahkan ke dalam pemrograman
pengujian dilakukan
Maintenance phase berfokus pada ‘perubahan’ (change):
dihubungkan dengan koreksi kesalahan
ketika lingkungan perangkat lunak berkembang
sehubungan dengan perubahan kebutuhan pelanggan
3.4 Changes in Phase Development
Correction (Koreksi)
membetulkan cacat atau kerusakan
Adaptation (Adaptasi)
modifikasi perangkat lunak karena perubahan kebutuhan fungsional original (CPU, OS, aturan bisnis, karakteristik produk eksternal, dll)
Enhancement (Perkembangan)
memperluas perangkat lunak sehingga melampaui kebutuhan fungsi originalnya
Prevention (Pencegahan)
pencegahan sebagai antisipasi perubahan karena usia perangkat lunak
3.5 Umbrella Activities
Software project tracking and control
Formal technical reviews
Software quality assurance
Software configuration management
Document preparation and production
Reusability management
Measurement
Risk management
3.6 Software Development Stages
Requirements Analysis & Specification
Conceptual/System Design
Detailed/Program Design
Implementation/Coding
Unit & Integration Testing
System Testing
System Delivery
Maintenance
3.7. The Software Process
Common Process Framework
Umbrella Activities
Framework Activities
Task Sets
Tasks
Milestones, deliveriables
SQA points
3.7.1 Five Process Maturity Levels (SEI=Software
Engineering Institute)
Level 1: Initial
Software process yang ditandai seperti ad hoc dan chaotic (kesemrawutan).
Level 2: Repeatable
Tracking / penelusuran masalah biaya, jadwal, dan fungsionalitas proyek-proyek terdahulu.
Level 3: Defined
Pendokumentasian, standarisasi, dan pengintegrasian software proses pada perangkat lunak organisasi besar.
Level 4: Managed
Pengukuan detail dan kualitas produksi perangkat lunak.
Level 5: Optimizing
Penambahan proses melalui umpan balik kuantitatif, gagasan inovatif pengujian, dan teknologi.
3.8. Software Process Models
Linier Sequential Model Waterfall Model
V Model
RAD Model
Prototyping Model
Evolutionary Model Incremental Model
Spiral Model
Component Assembly Model
Concurrent Development Model
Formal Model
Fourth Generation Techniques
3.8.1. Linier Sequential Model
Analysis Design Code Test
System/Information
Engineering
3.8.1.1 Waterfall Model
Sebuah pendekatan pengembangan perangkat
lunak yang sistematik dan sekuensial.
Disebut juga ‘Classic Life Cycle’.
Paradigma yang sudah lama sekali, tetapi masih
banyak yang memakai karena dianggap masih
sesuai dengan keadaan sekarang.
Waterfall Model Diagram
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Modified Waterfall Model (M.Kochanski)
Waterfall with Spiral IntroductionSashimi
Waterfall with Subprojects
3.8.1.2 V Model
REQUIREMENTS
ANALYSIS
SYSTEM
DESIGN
PROGRAM
DESIGN
CODING
UNIT & INTE-
GRATION TESTING
SYSTEM
TESTING
ACCEPTANCE
TESTING
OPERATION
& MAINTENANCE
Verify design
Validate requirements
3.8.1.3 RAD Model
RAD = Rapid Application Development
Adaptasi dari waterfall model yang:
menekankan siklus pengembangan perangkat lunak yang sangat pendek;
menggunakan pendekatan konstruksi berbasis komponen.
Menciptakan sistem fungsional yang utuh dalam waktu 60-90 hari.
RAD Model Diagram
business
modeling
data
modeling
process
modeling
application
generation
testing
&
turnover
business
modeling
data
modeling
process
modeling
application
generation
testing
&
turnover
business
modeling
data
modeling
process
modeling
application
generation
testing
&
turnover
60 - 90 hari
team #1
team #2
team #3
RAD Model Phases
Business Modelling
Memodelkan fungsi-fungsi bisnis untuk menjawab pertanyaan-pertanyaan:
Informasi apa yang mengendalikan proses bisnis ? Informasi apa yang dimunculkan? Ke mana infomasi itu pergi? Siapa yang memprosesnya?
Data Modelling
Aliran informasi yang didefinisikan pada fase business modelling ditransformasikan ke dalam serangkaian obyek data.
Process Modelling
Mentransformasikan obyek data pada suatu fungsi yang menghasilkan aliran informasi yang dibutuhkan.
Application Generation
Mengkonstruksi perangkat lunak dengan memakai komponen yang ada (bila memungkinkan) atau menciptakan komponen yang dapat dipakai lagi.
Testing and Turnover
Menguji komponen baru.
3.8.2 Prototyping Model
Dipakai jika:
Sistem mempunyai resiko tinggi
tidak jelas permasalahannya
Lebih fokus pada perancangan dialog user - komputer
bagaimana membuat dialog yang baik, ramah, mudah ?
Sistem diminati oleh banyak pemakai
mencari kesepakatan (dasar untuk menyamakan persepsi)
User ingin cepat selesai
user tidak sabar menunggu
prototipe segera memperlihatkan bentuk kerja sistem
Masa pakai singkat
sistem hanya dipakai beberapa kali saja
Ingin menunjukkan inovasi
pengembang dapat menunjukkan kecanggihan
Kebutuhan berubah-ubah
user sulit menjelaskan kebutuhan
Types of Prototyping
Evolutionary prototyping
Dimulai dari model, kemudian dikembangkan dan akhirnya dipakai.
Throw-away prototyping
Hanya dikembangkan sebagai model untuk mencari blue-print.
Evolutionary Prototyping
Prototype
Programming
Prototype
Requirements
Reviews
Release
Validates?
Throw-away prototyping
Release
System
Testing
System
Programming
Reviews
Validates?
Prototype
Programming
Prototype
Requirements
ReviewsValidates?
Prototyping Speciality
Frekuensi komunikasi user – developer meningkat
pengembang akan selalu meminta pendapat user
Membantu analis dalam
menentukan kebutuhan user yang sebenarnya
meminimalkan salah persepsi
Peran user meningkat
evaluasi oleh user berkali-kali
user bisa memberikan masukan setiap saat
Pengembangan lebih cepat
program bisa langsung dibuat
user melihat perkembangan tahap demi tahap
Implementasi mudah
user sudah mengenal perangkat lunak yang dikembangkan
user tidak akan merasa asing
sejak awal user sudah merasa memiliki
Prototyping Weakness
User sibuk
user & pengembang harus sama-sama memiliki komitmen menyediakan waktu untuk bertemu.
User sulit melakukan evaluasi
bentuk prototipe sering berubah, disesuaikan dengan kebutuhan user.
User ingin cepat selesai
bentuk program sudah terlihat sejak awal.
user merasa tidak akan lama lagi selesai.
pengembang sering mengabaikan dokumentasi.
User berharap terlalu banyak
keseringan evaluasi & komunikasi membuat user menjadi berubah keinginan dan tidak pasti dengan kebutuhan.
Prototipe bekerja tidak efisien
lebih mementingkan keberhasilan.
3.8.3 Evolutionary Model3.8.3.1 Incremental Model
Incremental Model merupakan gabungan antara model linier sekuensial dan prototyping.
Setiap linier sekuen menghasilkan produk yang deliveriables.
Increment pertama merupakan produk inti (core), yang mengandung persyaratan/kebutuhan dasar.
Penambahan dilakukan pada increment-increment berikutnya.
Incremental Model Diagram
analysis design code test
analysis design code test
analysis design code test
analysis design code test
system/information
engineering
increment 2
increment 3
increment 4
delivery of
1st increment
delivery of
2nd increment
delivery of
3rd increment
delivery of
4th increment
3.8.3.2 Spiral Model
Evolutionary process (pengembangan bertingkat)
Menggabungkan keunggulan prototyping dan waterfall
Memungkinkan dikembangkannya perangkat lunak secara bertahap (incremental) dan cepat.
Terbagi atas 6 tahapan
customer communication
planning
risk analysis
engineering
construction & release
customer evaluation
Spiral Model Diagram
Planning
Risk Analysis
Engineering
Customer
Evaluation Construction
& Release
Customer
Communication
Project
Entry Point
analisa resiko
berdasarkan
kebutuhan awal
analisa resiko
berdasarkan evaluasi
user
produk-jadi
prototipe awal
prototipe tingkat
berikutnya
menentukan
tujuan, alternatif,
batasan sistem
dan budget Requirements
development plan
Integration and test plan
development plan
3.8.3.3 Component Assembly Model
planning
engineering
risk analysis
customer evaluation
entry point
identify candidatecomponents
look up componentsin library
extract componentsif available
build components ifunavailable
put newcomponents in
library
construct n- thiteration of system
Customer
communication
Engineering,
contruction & release
3.8.3.4 Concurrent Development Model
none
Under
development
A waiting
changes
Under
revision
Under
review
baselined
done
Analysis activity
Konkurensi Tercapai dengan Cara:
aktivitas sistem dan komponen yang berlangsung
secara simultan dan dapat dimodelkan dengan
menggunakan pendekatan orientasi keadaan;
aplikasi klien/server khusus yang
diimplementasikan dengan banyak komponen yang
masing-masing bisa dirancang dan direalisasikan
secara konkuren.
3.8.4 Formal Model
mencakup sekumpulan aktivitas yang membawa
kepada spesifikasi matematis perangkat lunak
komputer;
memungkinkan software engineer untuk
mengkhususkan, mengembangkan, dan mem-
verifikasi sistem berbasis komputer dengan
menggunakan notasi matematis yang tepat;
Variasi dari pendekatan ini disebut clean-room
software engineering.
Formal method akan dibahas pada bab tersendiri
3.8.5 Fourth Generation Techniques
(4GT)
Terkait dengan penggunaan tools.
Pengembang software mendefinisikan karakteristik
software secara 'high level'; tool secara otomatis akan
membangkitkan kode.
4GT mempercepat proses pengembangan perangkat lunak.
Proses perancangan dan dokumentasi baik.
Masih dipertanyakan beberapa pihak: efisiensi kode yang
dihasilkan, kemudahan (relatif).
4GT Techniques
requirementsgathering
design strategy
implementationusing 4GL
testing
***
69
4. Konsep Manajemen Proyek Perangkat Lunak4.1 People
4.1.1 Para Pemain (Stakeholder)
4.1.2 Pemimpin Tim
4.1.3 Tim Perangkat Lunak
4.1.4 Tiga Organisasi Tim (Mantei)
4.1.5 Faktor-faktor dalam Perencanaan Struktur Tim RPL (Mantei)
4.1.6 Pengaruh Karakteristik Proyek pada Struktur Tim
4.1.7 Masalah Koordinasi dan Komunikasi
4.1.8 Teknik Koordinasi Proyek (Kraul dan Streeter)
4.2 Problem
4.2.1 Ruang Lingkup Masalah
4.2.2 Dekomposisi Masalah
4.3 Proses
4.3.1 Menggabungkan Masalah dan Proses
4.3.2 Dekomposisi Proses
4.3.3 Contoh Dekomposisi (simple project)
4.3.4 Contoh Dekomposisi (complex project)
70
Konsep Manajemen Proyek Perangkat Lunak
Manajemen Proyek Perangkat Lunak merupakan
suatu aktivitas pelindung (umbrella activity)
untuk mengelola proyek perangkat lunak, yang
difokuskan pada 3P: People (manusia); Problem
(masalah) dan Process (proses)
People: semua orang yang terlibat dalam proyek
perangkat lunak
Problem: menentukan ruang lingkup dan batasan proyek
perangkat lunak sekaligus teknik pemecahannya.
Process: kerangka kerja yang komprehensif dalam
pembangunan perangkat lunak
71
4.1 People
4.1.1 Para Pemain (Stakeholder) Senior managers: yang menentukan isu-isu bisnis yang sering
memiliki pengaruh penting dalam proyek.
Project (technical) managers: yang harus merencanakan, memotivasai, mengorganisasi, dan mengontrol sebuah produk atau aplikasi.
Practitioners: yang menyampaikan keteranpilan teknik yang diperlukan untuk merekayasa sebuah produk atau aplikasi.
Customers: yang menentukan jenis kebutuhan bagi perangkat lunak yang akan direkayasa.
End users: yang akan memakai perangkat lunak.
72
4.1.2 Pemimpin Tim
Pemimpin tim (team leaders): seseorang yang memimpin sebuah proyek perangkat lunak.
Syarat : Model Kepemimpinan MOI (Weinberg):
Motivasi: kemampuan untuk memberi dorongan pada staf teknis untuk menghasilkan sesuatu dengan kemampuan terbaiknya.
Organisasi: kemampuan untuk membentuk proses yang sedang berlangsung yang memungkinkan konsep dasar diterjemahkan ke dalam suatu hasil akhir.
Gagasan dan Inovasi: kemampuan untuk mendorong manusia untuk menciptakan dan bertindak kreatif meskipun mereka bekerja di dalam suatu ikatan yang dibangun untuk suatu produk perangkat lunak yang spesifik.
73
4.1.3 Tim Perangkat Lunak
Alternatif pemanfaatan SDM pada proyek perangkat lunak:
n individu diberi m tugas fungsional yang berbeda (m > n), ada individu yang merangkap kombinasi kerja.
n individu diberi m tugas yang berbeda (m < n), secara tidak langsung terbentuk tim informal.
n individu dibagi menjadi t tim, setiap tim mempunyai tugas yang spesifik.
Struktur tim yang terbaik berdasarkan gaya manajemen, jumlah orang, tingkat keahlian, kompleksitas masalah.
74
4.1.4 Tiga Organisasi Tim (Mantei)
Democratic Decentralized (DD); tidak ada pimpinan yang tetap,
keputusan diambil secara bersama-sama, hubungan horizontal.
Controlled Decentralized (CD); ada pimpinan untuk setiap 'task' dan sub-
pimpinan untuk 'sub-task', terjadi komunikasi horizontal & vertikal.
Controlled Centralized (CC); ada team leader untuk top-level problem
solving & koordinasi internal, koordinasi vertikal
75
4.1.5 Faktor-faktor dalam Perencanaan
Struktur Tim RPL (Mantei) Tingkat kesulitan masalah
Besarnya program (dalam LOC atau FP)
Team lifetime
Tingkat modularitas program
Kualitas dan reliabilitas program
Batas waktu pengembangan
Tingkat sosialisasi (sosiabilitas) proyek
76
4.1.6 Pengaruh Karakteristik Proyek
pada Struktur TimTeam type:
Difficulty
high
low
Size
large
small
Team lifetime
short
long
Modularity
high
low
Reliability
high
low
Delivery date
strict
lax
Sociability
high
low
DD CD CC
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
77
4.1.7 Masalah Koordinasi dan Komunikasi
Ada banyak hal yang menyebabkan proyek perangkat lunak bermasalah, penyebabnya diantaranya adalah:
Scale (skala): skala proyek yang demikian besar, sehingga koordinasi sulit.
Uncertainty (ketidakpastian): perubahan-perubahan yang terus-menerus.
Interoperability (interoperabilitas): perangkat lunak yang dibuat harus dapat berkomunikasi dengan perangkat lunak yang lain.
78
4.1.8 Teknik Koordinasi Proyek
(Kraul dan Streeter) Pendekatan impersonal, formal.
Dokumen, memo teknis, milestone proyek, schedule, error tracking report, dll
Prosedur interpersonal, formal.
Difokuskan pada jaminan kualitas kegiatan, diantaranya inspeksi desain dan kode.
Prosedur interpersonal, informal.
Group meeting untuk bertukar informasi dan problem solving, requirement gathering dan pengembangan staff.
Komunikasi elektronik.
E-mail, E-BB, web sites, video conference.
Jaringan interpersonal.
Diskusi informal dengan orang di luar proyek.
79
4.2 Problem
Manajer proyek perangkat lunak berhadapan dengan dilema awal proyek, yaitu menentukan perkiraan kuantitatif dan rencana organisasi tetapi informasi yang akurat belum tersedia.
Requirement analysis yang lengkap dibutuhkan untuk melakukan estimasi, tetapi memerlukan waktu yang lama dan kadang-kadang kebutuhan berubah-ubah pada saat proyek berjalan.
Solusi: definisikan scope (ruang lingkup) dengan benar dan segera.
80
4.2.1 Ruang Lingkup Masalah
dibatasi oleh:
Context
Bagaimana perangkat lunak yang dibangun dapat memenuhi sebuah sistem, produk, atau konteks bisnis yang lebih besar, serta apa batasan yang ditentukan sebagai hasil dari konteks tersebut?
Information Objectives
Obyek data pelanggan apa yang dihasilkan sebagai output dari perangkat lunak, dan obyek data apa yang diperlukan sebagai input?
Function dan performance
Fungsi apa yang dilakukan oleh perangkat lunak untuk mentransformasi input data menjadi output?
81
4.2.2 Dekomposisi Masalah
Dekomposisi masalah disebut juga partitioning (pembagian), merupakan aktivitas yang mendudukkan inti dari analisis kebutuhan perangkat lunak.
Dekomposisi dilakukan dalam 2 area:
Fungsionalitas yang harus dihasilkan
Proses yang akan dipakai untuk menghasilkan sesuatu
Manusia cenderung melakukan dekomposisi jika menghadapi masalah yang kompleks
82
4.3 Proses
Fase-fase generik dan menandai proses perangkat lunak: definisi, pembangunan, dan pemeliharaan
Fase generik dijalankan menggunakan salah satu model rekayasa perangkat lunak.
Project manager harus memilih model rekayasa yang paling tepat berdasarkan karakteristik masalah, tim, dan kriteria proyek.
83
Tahap awal project planning dimulai dengan penggabungan problem dan process.
Setiap fungsi yang akan direkayasa harus melampaui sejumlah aktivitas yang sudah ditentukan
Misal organisasi mengadopsi kerangka aktivitas sbb:
Customer communication – membangun komunikasi yang efektif antara pengembang dan pelanggan
Planning – menentukan sumber daya, ketepatan waktu, dan informasi proyek yang lain
Risk analysis – menentukan resiko-resiko manajemen dan teknis
Engineering – membangun aplikasi perangkat lunak
Construction and release – membangun, menguji, menginstal, dan memberikan dukungan kepada pemakai (dokumen dan pelatihan)
Customer evaluation – umpan balik pelanggan
Selanjutnya dibuat matriksnya.
4.3.1 Menggabungkan Masalah dan
Proses
84
Software Engineering Tasks
Product Functions
Text input
Editing & formatting
Automatic copy edit
Page layout capability
Automatic indexing & TOC
File management
Document production
COMMON PROCESS
FRAMEWORK ACTIVITIES
cu
sto
mer
co
mm
un
icati
on
pla
nn
ing
risk
an
aly
sis
en
gin
eeri
ng
85
4.3.2 Dekomposisi Proses
Memilih paradigma rekayasa perangkat lunak yang paling baik sesuai dengan tingkat relativitas dari perangkat lunak.
Bila proyek relatif kecil dan mirip dengan proyek sebelumnya, maka dapat dipilih pendekatan linier sekuensial
Bila masalah dapat dipecah-pecah dan batasan waktu yang ketat, maka dapat dipilih model RAD.
Bila batas waktunya ketat, tetapi fungsionalitastidak dapat optimal, maka dapat dipilih strategi pertambahan. dll
Sekali model dipilih, kerangka kerja umum (CPF=common Process Framework) harus disesuaikan dengan model.
86
4.3.3 Contoh Dekomposisi
(simple project) Membuat daftar klarifikasi
Bertemu dengan customer untuk klarifikasi
Bersama-sama menentukan scope
Review scope
Penyempurnaan scope berdasarkan berbagai kendala
87
4.3.4 Contoh Dekomposisi
(complex project) Mengkaji kebutuhan customer
Merencanakan dan menjadwal sebuah pertemuan formal dengan customer
Melakukan penelitian untuk menentukan pemecahan yang diusulkan
Mempersiapkan dokumen kerja serta agenda untuk pertemuan formal
Mengadakan pertemuan
Secara bersama-sama mengembangkan spesifikasi detail yang merefleksikan data, fungsi, dan karakteristik yang berhubungan dengan perilaku perangkat lunak
Mengkaji setiap spesifikasi detail tersebut untuk upaya perbaikan, konsistensi, dan mengurangi ambiguitas
Mencantumkan spesifikasi detail ke dalam sebuah dokumen ruang lingkup
Mengkaji dokumen ruang lingkup dengan semua pendapat yang ada.
Memodifikasi dokumen ruang lingkup sesuai dengan kebutuhan.
***
88
5. Proses Perangkat Lunak dan Metrik Proyek
5.1 Domain Metrik
5.1.1 Tujuan Umum Pengukuran
5.1.2 Determinan Kualitas dan Efektivitas Perangkat Lunak
5.2 Pengukuran Perangkat Lunak
5.2.1 Size-Oriented Metrics
5.2.2 Function-Oriented Metrics
5.2.2.1 Function Points
5.2.2.2 Penghitungan Metrik Function Points
5.2.2.3 Feature Points
5.2.2.4 Penentuan Kompleksitas Transformasi Function Points
5.3 Penyatuan Pendekatan Metrik yang Berbeda
5.4 Kualitas Perangkat Lunak
5.4.1 Faktor yang Mempengaruhi Kualitas
5.4.2 Faktor yang Mempengaruhi Kualitas (Gilb)
5.5 Penyatuan Metrik-metrik dlm Proses Perangkat Lunak
89
Proses Perangkat Lunak dan Metrik Proyek
Measure (mengukur); kuantitatif luasan, jumlah, dimensi,
kapasitas, atau ukuran dari atribut sebuah proses atau
produk.
Measurement (pengukuran); kegiatan menentukan sebuah
measure.
Metrics (IEEE): ukuran kuantitatif dari tingkat di mana
sebuah sistem, komponen, atau proses memiliki atribut
tertentu
Indikator adalah sebuah metrik atau kombinasi dari metrik
yang memberikan pengetahuan ke dalam proses perangkat
lunak, sebuah proyek perangkat lunak, atau produk
perangkat lunak.
90
5.1 Domain Metrik
Pengukuran perangkat lunak dilakukan pada proses dan proyekperangkat lunak.
Indikator proses memungkinkan:
Software engineer memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung.
Manajer dan pelaksana memperkirakan hal-hal yang harus dikerjakan dan yang tidak
Indikator proyek, memungkinkan manajer proyek:
Memperkirakan status proyek
Menelusuri resiko-resiko potensial
Menemukan area masalah sebelum menjadi kritis
Menyesuaikan aliran kerja atau tugas-tugas
Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas.
91
5.1.1 Tujuan Umum Pengukuran
Mengetahui kualitas perangkat lunak; baik atau
jelek
Menilai produktifitas pembuatan perangkat lunak;
kecepatan pembuatan, ukuran perangkat lunak
Menilai manfaat dari penerapan sebuah metoda;
mencari paradigma andalan
Dasar untuk melakukan perkiraan; pedoman di
masa mendatang
Membantu untuk memastikan apakah dibutuhkan
peralatan baru atau pelatihan tambahan?
92
5.1.2 Determinan Kualitas dan
Efektivitas Perangkat LunakProduct
TechnologyPeople
ProcessCusto
mer
Chara
cte
ristics
Development
EnvironmentB
usin
ess
Conditio
ns
93
5.2 Pengukuran Perangkat Lunak
Size-Oriented Metrics: metrik yang berorientasi pada besar fisik ukuran
perangkat lunak
Function-Oriented Metrics: metrik yang berorientasi pada fungsionalitas dan
utilitas perangkat lunak, menggunakan:
Function Points
Feature Points
94
5.2.1 Size-Oriented Metrics
Normalisasi kualitas dan produktivitas dengan mengukur besar-kecilnya (LOC/KLOC)perangkat lunak, sehingga diperoleh:
Error per KLOC
Defect (cacat) per KLOC
Rupiah (Rp) per LOC
Halaman dokumentasi per KLOC
Metrik lain dapat diturunkan:
Error per orang-bulan
LOC per orang-bulan
Rupiah (Rp) per halaman dokumentasi
95
Contoh (size-oriented metrics)
alpha 12,100 24 168 365 134 29 3
beta 27,200 62 440 1224 321 86 5
gamma 20,200 43 314 1050 256 64 6
.. .. .. .. .. .. .. ..
Project LOC Effort $(000) pp.doc. Errors Defects People
96
Kontroversi Size-Oriented Metrics
Metrik size-oriented tidak diterima secara universal; kontroversi terletak pada pemakaian LOC.
Pendukung: LOC merupakan artifak proyek pengembangan perangkat lunak yang mudah dihitung.
Penentang: LOC tergantung bahasa pemrograman, LOC tidak mendukung desain yang baik tetapi program singkat, tidak dapat dengan mudah mengakomodasi bahasa non-prosedural, dan pemakaiannya membutuhkan tingkat detail yang sulit dicapai.
97
5.2.2 Function-Oriented Metrics
Mengukur secara tidak langsung.
Ditekankan pada fungsional & utilitas program.
Diusulkan pertama kali oleh Albrecht, dengan usulan cara perhitungan yang disebut: function point (FP).
FP diturunkan dengan menggunakan hubungan empiris berbasis pada sesuatu yang terukur dari domain informasi dan berhubungan dengan kompleksitas PL. (lihat berikut)
98
5.2.2.1 Function Points
Domain Informasi:
Jumlah input dari user: jumlah user input yang dibutuhkan aplikasi
Jumlah output untuk user: jumlah semua keluaran baik laporan maupun kesalahan (ke printer/layar)
Jumlah input inquiry: masukan on-line yang mengakibatkan keluaran on-line
Jumlah file
Jumlah interface eksternal: semua interface yang dibaca oleh mesin untuk memindahkan informasi ke sistem lain.
99
5.2.2.2 Penghitungan Metrik Function
Points
number of user inputs 63 4x =
number of user outputs 74 5x =
number of user inquiries 63 4x =
number of files 157 10x =
number of external interfaces 105 7x =
total
measurement parameter complexsimple averagecount
Weighting Factor
FP= total x [0.65 + 0.01 x Fi]
Domain kompleksitas
Fi (i = 1 s/d 14) adalah ‘complexity adjustment values’ berdasarkan
respon yang diperoleh dari pertanyaan-pertanyaan berikut ini.
100
Pertanyaan-Pertanyaan
Untuk menghitung Fi, pertanyaan-pertanyaan di bawah ini dijawab dengan memberi nilai antara 0 s/d
5
Apakah sistem memerlukan backup dan recovery?
Apakah diperlukan fasilitas komunikasi data?
Apakah diperlukan fasilitas ‘distributed processing’?
Apakah kinerja sangat penting?
Apakah sistem akan dijalankan pada lingkungan yang sudah ada yang sudah terpakai secara penuh?
Apakah memerlukan pemasukan data secara ‘on-line’?
Apakah pemasukan data ‘on-line’ terjadi pada transaksi input thd layar atau operasi ganda?
Apakah file master di’update’ secara on-line?
Apakah input,output, file secara inquiry begitu kompleks?
Apakah proses internal begitu kompleks?
Apakah kode yang dibuat harus dapat digunakan ulang?
Apakah konversi dan instalasi termasuk dalam perancangan?
Apakah sistem dirancang untuk dapat diinstall pada berbagai organisasi yang berbeda?
Apakah aplikasi dirancang untuk memberikan fasilitas perubahan dan kemudahan pemakaian bagi user?
101
5.2.2.3 Feature Points
Seperti function point dengan penambahan karakteristik perangkat lunak lain: algorithma.
Boeing telah mengembangkan function point extension untuk sistem-sistem real time yang disebut 3D function point.
Untuk menghitung 3D function point hubungan berikut dipakai
Index = I + O + Q + F + E + T + R
Keterangan : I = input O = output
Q = inquiry, F = internal data structure
E = external file, T = transformation,
R = transition.
102
5.2.2.4 Penentuan Kompleksitas
Transformasi Function Points
Semantic
Statements
Processing
Steps
1 - 5 6 - 10 11 +
1 - 10
11 - 20
21 +
low low average
low average high
average high high
103
Perhitungan 3D function point index
internal data structures x 7 + x 10 + x 15 =
external data x 5 + x 7 + x 10 =
number of user inputs x 3 + x 4 + x 6 =
number of user outputs x 4 + x 5 + x 7 =
number of user inquiries x 3 + x 4 + x 6 =
transformations x 7 + x 10 + x 15 =
transitions x n/a + x n/a + x n/a =
3D function point index
measurement element low average high
Complexity Weighting
104
assembly language
C
Cobol
Fortran
Pascal
Ada
object-oriented languages
fourth generation languages (4GLs)
code generators
spreadsheets
graphical languages (icons)
320
128
105
105
90
70
30
20
15
6
4
Programming Language LOC/FP (average)
Banyaknya LOC yang dibutuhkan untuk membangun 1 FP
5.3 Penyatuan Pendekatan
Metrik yang Berbeda
105
5.4 Kualitas Perangkat Lunak
5.4.1 Faktor yang Mempengaruhi Kualitas
McCall dan Cavano mendefinisikan satu set quality factors yang merupakan
tahap awal untuk mengembangkan metrik untuk pengukuran kualitas
perangkat lunak:
product operation (using it),
product revision (changing it), dan
product transition (porting it).
(dibahas di Bab Matriks Teknis PL)
106
5.4.2 Faktor yang Mempengaruhi Kualitas
(Gilb)
Correctness: perangkat lunak bekerja dengan baik & benar ( correctness =
kesalahan / kloc )
Maintainability: mudah dirawat; mttc (mean time to change) kecil
Integrity: tahan gangguan; tingkat sekuriti yang baik
Usability: mudah digunakan
107
5.5 Penyatuan Metrik-metrik dalam
Proses Perangkat Lunaksoftware
engineering
process
software
project
software
product
data
collection
data
collection
data
collection
measures
metrics
indicators
***
108
6.1 Observasi pada Estimasi
6.2 Tujuan Perencanaan Proyek
6.3. Ruang Lingkup Perangkat Lunak
6.3.1. Rangkaian Pertanyaan SW Scope
6.3.1.1 Contoh Rangkaian Pertanyaan Pertama
6.3.1.2 Contoh Rangkaian Pertanyaan Kedua
6.3.1.3 Contoh Rangkaian Pertanyaan Ketiga
6.3.2. Contoh Scoping
6.3.2.1 Penjelasan Gambar
6.3.2.2 Dekomposisi Pernyataan
6.3.2.3 Kesimpulan Contoh Scoping
6.4 Sumber Daya
6.4.1 Sumber Daya Manusia
6.4.2 Reusable Software Resources
6.4.3 Environmental Resources
6.5. Estimasi Proyek Perangkat Lunak
6.5.1. Teknik Dekomposisi
6.5.1.1 Software Sizing
6.5.1.2 Problem-based Estimation
6.5.1.3 Contoh Estimasi Berbasis-LOC
6.5.1.4 Contoh Estimasi Berbasis FP
6.5.1.5 Contoh Estimasi Berbasis Proses
6.5.2 Empirical Estimation Models
6.5.2.1 Beberapa Model Estimasi
6.5.2.2 COnstructive COst MOdel (COCOMO)
6.5.2.3 Persamaan Perangkat Lunak
6. Perenc. Proyek Perangkat Lunak (Software Project Planning)
109
Project planning adalah serangkaian aktivitas-aktivitas kolektif dalam proses manajemen proyek perangkat lunak.
Estimation adalah aktivitas pertama dalam project planning
Estimation menjadi dasar bagi aktivitas perencanaan proyek yang lain.
Project planning menjadi peta jalan bagi kesuksesan rekayasa perangkat lunak
Perenc. Proyek Perangkat Lunak
110
6.1 Observasi pada Estimasi
Estimasi pada project planning meliputi estimasi sumber daya, biaya, dan jadwal pengembangan perangkat lunak.
Hal-hal yang mempengaruhi estimasi:
Project complexity (kompleksitas proyek); berpengaruh terhadap ketidakpastian yang inheren dalam perencanaan
Project size (ukuran project); berpengaruh terhadap akurasi estimasi
Structural uncertainty (ketidakpastian struktural); berpengaruh terhadap resiko estimasi
111
6.2 Tujuan Perencanaan Proyek
menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat
estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya,
dan jadwal.
Tujuan project planning dapat tercapai melalui proses penemuan informasi
yang menunjuk ke estimasi yang dapat dipertanggungjawabkan.
112
6.3. Ruang Lingkup Perangkat Lunak
(Software Scope)
Fungsi (functions)
Kinerja (perfomance)
Batasan(constraints)
Antarmuka (interface)
Keandalan (reliability)
113
6.3.1. Rangkaian Pertanyaan SW Scope
Lingkup PL yang akan dibuat ditentukan melalui pertemuan-pertemuan antara customer dengan developer
Untuk menjembatani jurang komunikasi antara customer dengan developer, Gause & Weinberg mengusulkan 3 rangkaian pertanyaan berikut:
Rangkaian pertanyaan pertama adalah sekumpulan pertanyaan bebas konteks yang memusatkan pada customer, sasaran keseluruhan PL yang dibuat, dan keuntungan yang akan diperoleh.
Rangkaian pertanyaan kedua adalah sekumpulan pertanyaan yang memungkinkan analis mendapatkan pemahaman yang lebih baik atas problem, dan customer dapat menyuarakan persepsinya atas suatu solusi.
Rangkaian pertanyaan ketiga adalah pertanyaan-pertanyaan yang memusatkan pada efektivitas dari pertemuan itu sendiri (disebut meta-questions).
114
6.3.1.1 Contoh Rangkaian Pertanyaan Pertama
Siapa di belakang permintaan pekerjaan ini?
Siapa yang akan menggunakan solusi ini?
Keuntungan ekonomis apa yang diperoleh dari solusi ini?
Adakah sumber daya lain untuk solusi ini?
115
6.3.1.2 Contoh Rangkaian Pertanyaan Kedua
Bagaimana anda mengkarakterisir keluaran “yang
baik” yang akan dimunculkan oleh solusi ini?
Problem apa saja yang akan dihadapi oleh solusi
ini?
Dapatkan anda menunjukkan kepada kami (atau
menjelaskan) lingkungan di mana solusi ini akan
dipakai?
Adakah batasan atau isu kinerja khusus yang akan
mempengaruhi cara pendekatan terhadap solusi?
116
6.3.1.3 Contoh Rangkaian Pertanyaan Ketiga
Apakah anda orang yang tepat untuk menjawab pertanyaan-pertanyaan ini? Apakah jawaban anda “resmi”?
Apakah pertanyaan-pertanyaan kami relevan untuk problem yang anda punya?
Apakah saya terlalu banyak pertanyaan?
Apakah ada orang lain yang dapat memberikan informasi-informasi tambahan?
Apakah ada hal-hal lain yang harus kami tanyakan kepada anda?
117
6.3.2. Contoh Scoping
1
2
3
4
5
6
ID No.ID No.ID No.ID No.
SORTING
STATIONcontrol
connection
conveyor line
motion
shuntbar code
118
6.3.2.1 Penjelasan Gambar
Conveyor Line Sorting System (CLSS) menyortir box-box yang bergerak pada ban berjalan.
Setiap box diidentifikasi dengan bar code yang menyatakan nomor part.
Box-box tersebut akan disortir ke dalam 6 wadahberdasarkan nomor part.
Box-box tersebut melewati stasiun sortir yang berisi pembaca bar code dan sebuah PC (Personal Computer).
PC di stasiun sortir dihubungkan dengan mekanisme langsiran (shunt) yang akan menyortir box-box tersebut ke dalam wadah-wadah yang sesuai.
Box-box tersebut lewat dengan urutan yang acak dan berjarak sama.
PL CLSS menerima informasi masukan dari pembaca bar code dengan interval waktu sesuai dengan kecepatan ban berjalan.
119
6.3.2.1 Penjelasan Gambar(lanj)
Data bar code tersebut akan didekodekan ke dalam format identifikasi box.
PL akan melakukan look-up pada basis data part number yang berisi maksimum 1000 entry untuk menentukan lokasiwadah yang sesuai bagi box yang saat itu di stasiun sortir.
Lokasi wadah yang sesuai diberikan pada sorting shunt yang akan menempatkan box tersebut pada wadah yang sesuai.
Sebuah catatan (record) yang berisi wadah tujuan dari setiap box dibangkitkan untuk recovery nantinya dan pelaporan.
PL CLSS juga menerima masukan dari sebuah tachometer pulsa yang akan dipakai untuk sinkronisasi sinyal kontrol ke mekanisme shunting.
Berdasarkan pada jumlah pulsa yang akan dibangkitkan antara stasiun sortir dan shunt, PL akan menghasilkan sebuah sinyal kontrol ke shunt untuk menenpatkan box tersebut dengan benar.
120
6.3.2.2 Dekomposisi Pernyataan
Dekomposisi dari pernyataan di atas, dapat diekstrak menjadi fungsi-fungsi penting dari PL yang akan dibuat; yaitu:
read bar code input (membaca input bar code)
read pulse tachometer (membaca pulsa tachometer)
decode part code data (mengkodekan bagian data kode)
do database look-up (mengerjakan look-up database)
determine bin location (menentukan lokasi kotak penyimpanan
produce control signal for shunt (memproduksi sinyal kontrol untuk shunt)
maintain record of box destinations (memelihara rekaman tujuan kotak)
121
6.3.2.3 Kesimpulan Contoh Scoping
Kinerja sistem ini ditentukan oleh kecepatan ban berjalan. Pemrosesan setiap box harus selesai sebelum box berikutnya tiba di pembaca bar code.
Kendala-kendala yang membatasi PL CLSS adalah meliputi perangkat keras yang harus diakses (pembaca bar code, shunt, PC), memori yang tersedia, dan konfigurasi keseluruhan dari lini ban berjalan tersebut.
122
6.3.2.3 Kesimpulan Contoh Scoping (lanj)
Interface : PL yang dibuat berinteraksi dengan elemen-elemen lain dari sistem berbasis komputer ini. Konsep interface mempunyai arti;(1) hardware yang mengeksekusi PL dan perangkat lain yang
secara tidak langsung dikontrol oleh PL tersebut.
(2) software yang telah ada dan harus dilink dengan software yang baru (dibuat) tersebut.
(3) orang yang menggunakan PL tersebut via keyboard atau I/O devices lainnya.
(4) prosedur-prosedur yang mengawali atau mengakhiri (mengikuti) PL tersebut sebagai urutan operasi yang sekuensial.
123
6.4 Sumber Daya
Hardware/Software Tools
Reusable Software
Components
People
124
6.4.1 Sumber Daya Manusia
Diperlukan keahlian untuk menyelesaikan pengembangan PL; baik dari segi
posisi organisasional (misal: manager, senior software engineer, dsb) maupun
spesialisasi (misal: telekomunikasi, basis data, dsb).
Sedangkan jumlah banyaknya personil yang dibutuhkan ditentukan setelah
estimasi beban kerja (development effort).
125
6.4.2 Reusable Software Resources
Off-the-shelf components; memanfaatkan yang telah dibuat pada proyek internal sebelumnya.
Full-experience components; mereview spesifikasi, kode, desain atau pengujian data dari proyek sebelumnya
Partial-experience components; aplikasi, kode, desain atau data dari proyek sebelumnya dihubungkandengan proyek sekarang
New components; pembuatan komponen baru
126
6.4.3 Environmental Resources
Lingkungan yang mendukung proyek PL, disebut juga software engineering
environment (SEE); meliputi
hardware
software
hardware & software khusus
127
6.5. Estimasi Proyek Perangkat Lunak
(Software project estimation) Ada 2 teknik dalam melakukan estimasi proyek perangkat lunak, yaitu:
Decomposition Techniques
Empirical Estimation Models
128
6.5.1. Teknik Dekomposisi
(Decomposition techniques) Dekomposisi masalah : memecah-mecah masalah yang
kompleks menjadi serangkaian masalah yang lebih kecil.
Ketelitian estimasi proyek PL diprediksi pada sejumlah hal:
(1) derajat ketepatan estimasi ukuran produk yang akan dibuat,
(2) kemampuan menterjemahkan ukuran terestimasi tersebut ke dalam beban kerja, waktu kalender, dan rupiah,
(3) derajat rencana proyek yang mencerminkan kemampuan tim software, dan
(4) kestabilan persyaratan-persyaratan produk dan lingkungan yang mendukung upaya software engineering.
129
6.5.1.1 Software Sizing
Dalam kontek project planning, size mengacu pada hasil-hasil proyek PL yang dapat dikuantifikasi.
Putnam & Myers mengusulkan 4 cara untuk pengukuran problem; Fuzzy-logic sizing; menggunakan teknik reasoning
aproksimasi Function point sizing; mengembangkan estimasi karakteristik
domain informasi Standard component sizing; menggunakan komponen-
komponen standar yang ada.
Change sizing; memodifikasi PL dengan banyak cara, menggunakan suatu rasio kerja setiap perubahan, sehingga ukuran perubahan dapat diperkirakan
130
6.5.1.2 Problem-based Estimation
Data LOC dan FP dipakai dalam dua hal selama estimasi proyek PL:
(1) sebagai suatu estimation variable yang dipakai untuk “memberi ukuran”
pada setiap elemen PL yang akan dibuat, dan
(2) sebagai baseline metrics yang dikumpulkan dari proyek terdahulu dan
dipakai bersama-sama dengan estimation variable untuk menghitung
proyeksi biaya dan beban kerja.
131
Tanpa memandang variabel estimasi yang dipakai, project planner mulai dengan mengestimasi rentang nilai untuk setiap fungsi atau nilai domain informasi.
Dengan menggunakan data historis atau intuisi, ditentukan ukuran nilai yang optimistik (sopt), rata-rata (sm), dan yang pesimistik (spess).
Kemudian dihitung nilai yang diharapkan (three-point atau expected value) sbb.
EV = (sopt + 4 sm + spess)/6
6.5.1.2 Problem-based Estimation
(lanj)
132
6.5.1.3 Contoh Estimasi Berbasis-LOC
Rekayasa : Software CAD yang dapat menerima data geometrik 2-D dan 3-D dari seorang engineer. Engineer akan berinteraksi dan mengkontrol sistem CAD tersebut melalui user interface yang akan mencerminkan karakteristik perancangan interface human-machine yang baik.
Semua data geometrik dan informasi pendukung lainnya akan disimpan dalam suatu basis data CAD.
Modul-modul analisis - design akan dibuat untuk menghasilkan keluaran yang akan memperagakan (display) pada berbagai graphics devices.
Software akan dirancang guna mengontrol dan berinteraksi dengan devices periferal yang meliputi mouse, digitizer, dan laser printer.
133
Kita asumsikan fungsi-fungsi utama PL tersebut adalah:
user interface and control facilities (UICF)
two-dimensional geometric analysis (2DGA)
three-dimensional geometric analisys (3DGA)
database management (DBM)
computer graphics display facilities (CGDF)
peripheral control (PC)
design analysis modules (DAM)
6.5.1.3 Contoh Estimasi Berbasis-LOC
(lanj)
134
user interface and control facilities (UICF)
two-dimensional geometric analysis (2DGA)
three-dimensional geometric analysis (3DGA)
database management (DBM)
computer graphics display facilities (CGDF)
peripheral control (PC)
design analysis modules (DAM)
Estimated LOCFunction
2.300
5.300
6.800
3.350
4.950
2.100
8.400
33.200estimated lines of code
6.5.1.3 Contoh Estimasi Berbasis-LOC
(lanj)
135
6.5.1.4 Contoh Estimasi Berbasis FP
number of inputs
number of outputs
number of inquiries
number of files
number of external interfaces
Information Domain Value opt. likely pess.
20 24 30
12 15 22
16 22 28
4 4 5
2 2 3
est.
count weight FP-count
24
16
22
4
2
4
5
4
10
7
96
80
88
40
14
count-total 318
136
Backup and recovery
Data communication
Distributed processing
Performance critical
Existing operation environment
On-line data entry
Input transaction over multiple screens
Master files updated on-line
Information domain values complex
internal processing complex
Code designed for reuse
Conversion/installation in design
Multiple installations
Application designed for change
Complexity adjustment factor
4
2
0
4
3
4
5
3
5
5
4
3
5
5
1.17
Factor Value
FPestimated
= count-total x [0,65 + 0,01 x Fi]
FPestimated
= 372
6.5.1.4 Contoh Estimasi Berbasis FP(lanj)
137
6.5.1.5 Contoh Estimasi Berbasis Proses
Sederetan kegiatan proses software harus dikerjakan untuk masing-
masing fungsi.
Fungsi-fungsi dan kegiatan-kegiatan proses PL yang terkait dapat
dinyatakan dalam tabel berikut.
138
Software Engineering Tasks
Product Functions
Text input
Editing & formatting
Automatic copy edit
Page layout capability
Automatic indexing & TOC
File management
Document production
COMMON PROCESS
FRAMEWORK ACTIVITIES
cu
sto
mer
co
mm
un
icati
on
pla
nn
ing
ris
k
an
aly
sis
en
gin
eerin
g
139
6.5.2 Empirical Estimation Models
Model estimasi untuk software komputer dengan
menggunakan formula-formula yang diturunkan secara
empirik untuk memprediksi beban kerja sebagai fungsi
dari LOC atau FP.
Data empirik yang mendukung model-model estimasi
tersebut diturunkan dari sample proyek yang terbatas.
Model-model estimasi mempunyai struktur sbb.
CevBAE )(´+=
dengan A, B, dan C adalah konstanta yang diturunkan
secara empirik
E adalah effort dalam orang bulan
ev adalah variabel estimasi (dalam LOC atau FP)
140
6.5.2.1 Beberapa Model Estimasi
91,0)(2,5 KLOCE ´=
16,1)(73,05,5 KLOCE ´+=
05,1)(2,3 KLOCE ´=
047,1)(288,5 KLOCE ´=
Walston-Felix model
Bailey-Basili model
Boehm simple model
Doty model untuk KLOC > 9
)(0545,039,13 FPE ´+-=
38 )(10728,762,60 FPE -´´=
)(12.157,585 FPE ´+=
Albrecht and Gaffney model
Kemerer model
Matson, Barnett, and Mellichamp
model
LOC-Oriented
FP-Oriented
141
6.5.2.2 COnstructive COst MOdel
(COCOMO)Model mempunyai bentuk hirarki (berdasarkan Boehm) sbb:
Model 1. Basic COCOMO Model
Menghitung development effort (dan cost) sebagai fungsi dari
ukuran program yang dinyatakan dalam estimasi LOC.
E = abKLOCbb
D = cbEdb
dengan E adalah effort (usaha) dalam orang-bulan dan D adalah
waktu pengembangan dalam bulan kronologis.
142
Software Project
organic
semi-detached
embedded
ab
2,4
3,0
3,6
bb
1,05
1,12
1,20
cb
2,5
2,5
2,5
db
0,38
0,35
0,32
BASIC COCOMO MODEL
Dengan mengambil nilai pada
contoh CAD, maka biaya per-
person:
E = 2,4 (KLOC)1,05
E = 2,4 (33,2)1,05
E = 95 person-month
Untuk menghitung durasi proyek:
D = 2,5 E0,35
E = 2,5 (95)0,35
E = 12,3 month
Jumlah orang yang
disetujui:
E = E/D = 95/12,3 = ~8
person• Organic – proyek perangkat lunak yang sederhana dan relatif kecil
• Semi-detached – proyek perangkat lunak menengah
• Embedded – proyek perangkat lunak yang kompleks seperti PL penerbangan
143
Menghitung usaha pengembangan PL sebagai fungsi
ukuran program dan serangkaian pengendali biaya
yang menyangkut penilaian yang subyektif terhadap
produk, hardware, personil, dan atribut proyek.
E = aiKLOCbi x EAF
dengan E adalah effort dalam orang-bulan dan EAF
adalah faktor penyesuaian usaha dengan harga
berkisar antara 0,9 sampai 1,4.
Model 2. Intermediate COCOMO Model
144
Software Project
organic
semi-detached
embedded
ai
3,2
3,0
2,8
bi
1,05
1,12
1,20
Model 2. Intermediate COCOMO Model (lanj)
• Organic – proyek perangkat lunak yang sederhana dan relatif
kecil
• Semi-detached – proyek perangkat lunak menengah
• Embedded – proyek perangkat lunak yang kompleks seperti
PL penerbangan
145
Menghubungkan semua karakteristik model
intermediate dengan penilaian terhadap pengaruh
pengendali biaya pada setiap langkah (analisis,
perancangan, pemrograman, dll) dari proses rekayasa
perangkat lunak.
Model 3. Advanced COCOMO Model
146
6.5.2.3 Persamaan Perangkat Lunak
Persamaa PL : model multivariasi yang mengasumsikan distribusi khusus effort sepanjang hidup proyek pengembangan perangkat lunak.
Dihasilkan (estimasi) dari data produktivitas 4000 proyek perangkat lunak yang sejaman.
Didefinisikan sbb:
E = [LOC x B0,333/P]3 x (1/t4)
keterangan :
E= effort dalam person-month atau person-year
t = durasi proyek dalam bulan atau tahun
B = faktor skill khusus (pertumbuhan skill). Untuk program kecil
(KLOC=5 sampai 15) B=0,16; untuk program lebih besar dari 70 KLOC, B=0,39
P = parameter produktivitas
Waktu pengembangan minimum didefinisikan:
tmin=8,14(LOC/P)0,43
***
147
7. PENGELOLAAN RISIKO
Definisi Konseptual Risiko
7.1 Strategi Risiko: Reaktif vs Proaktif
7.2. Karakteristik Risiko
7.3. Identifikasi Risiko
7.4. Proyeksi Risiko
7.5. Pengurangan (Mitigation), Monitoring, dan Manajemen Risiko (RMMM)
7.6 Safety Risks & Hazards
148
Definisi Konseptual Risiko(Robert Charette)
• Risiko berkaitan dengan kejadian yang akan datang.
• Risiko melibatkan perubahan, seperti perubahan dalam pemikiran, opini, tindakan, atau tempat.
• Risiko melibatkan pilihan dan ketidakpastiandalam pilihan itu sendiri.
149
Dalam konteks rekayasa perangkat lunak :
• risiko apa saja yang dapat menyebabkan proyek PL
serba salah?
• Bagaimana perubahan-perubahan dalam persyaratan-
persyaratan pelanggan, teknologi pengembangan,
komputer target, dan entitas lain yang berkaitan
dengan keberhasilan proyek secara keseluruhan?
• Metode-metode dan tool-tool apa yang harus dipakai,
berapa orang yang harus dilibatkan, seberapa jauh
penekanan terhadap kualitas yang dipandang cukup
memadai?
150
7.1 Strategi Risiko: Reaktif vs Proaktif
• Strategi reaktif : tim PL tidak melakukan sesuatu
sampai sesuatu yang tidak diinginkan terjadi.
Kemudian tim akan bertindak untuk mengatasi
masalah tersebut secepatnya. Cara ini kadang-kadang
disebut “fire fighting mode”.
• Strategi proaktif : kegiatan menanggulangi risiko sudah
diawali jauh sebelum kerja teknis dimulai. Dalam hal
ini, risiko-risiko yang potensial diidentifikasi,
probabilitas dan pengaruh proyek diperkirakan, dan
dibuat prioritas berdasarkan tingkat pentingnya.
Kemudian tim membuat rencana untuk mengelola
risiko-risiko tersebut.
151
7.2. Karakteristik Risiko
Ketidakpastian - kejadian yang mencirikan
suatu risiko dapat terjadi atau tidak, yaitu
tidak ada risiko kemungkinan 100%.
Kerugian - jika risiko menjadi kenyataan,
akibat yang tidak diinginkan atau kerugian
akan diperoleh.
152
Dalam menganalisis risiko, adalah sangat
penting untuk mengkuantifikasi tingkat
ketidakpastian dan tingkat kerugian yang
ditimbulkan oleh masing-masing risiko.
Untuk itu perlu dipertimbangkan berbagai
kategori risiko.
7.2.1 Kategori Risiko
7.2.2 Kategori Risiko Menurut R. Charette
153
7.2.1 Kategori Risiko
risiko proyek : potensi muncul dari pembiayaan, jadwal, personal, sumber daya, pelanggan, persyaratan, kompleksitas, ukuran, dan ketidakpastian struktural.
risiko teknis : yang disebabkan oleh ambiguitas, spesifikasi, ketidakpastian teknik, keusangan teknik, dan teknologi yang leading edge.
risiko bisnis : risiko pasar, risiko strategi, pemasaran, risiko manajemen, dan risiko biaya.
154
7.2.2 Kategori Risiko Menurut R. Charette
• Know risks : risiko yang dapat ditemukan
setelah evaluasi yang hati-hati pada rencana
proyek, lingkungan bisnis & teknis proyek yang
sedang dikerjakan, dan sumber-sumber informasi
handal lainnya.
• Predictable risks : risiko yang diesktrapolasi
dari pengalaman proyek-proyek sebelumnya.
• Unpredictable risks : risiko-risiko yang sangat
sulit diketahui sebelumnya.
155
Ada 2 tipe risiko untuk masing-masing kategori di atas.
• Generic risks : risiko yang mengancam setiap proyek PL.
• Product specific risks : risiko-risiko yang hanya dapat diidentifikasi dengan pemahaman yang jelas pada teknologi, SDM, dan lingkungan yang spesifik bagi proyek tersebut. Untuk mengiden-tifikasi risiko tipe ini, rencana proyek & pernyataan tentang lingkup PL yang akan dibuat diperiksa.
156
7.3. Identifikasi Risiko
Identifikasi risiko adalah upaya sistematis untuk menentukan
ancaman-ancaman pada rencana proyek (estimasi, jadwal,
pembebanan sumber-sumber, dsb.).
Salah satu metoda untuk mengidentifikasi risiko adalah dengan
membuat sebuah risk item checklist. Dari checklist tersebut dapat
dilakukan pembandingan dengan pengalaman proyek sebelumnya.
Bila deviasinya sama atau lebih besar, atau banyaknya jawaban
negatif, maka risiko proyek tersebut dapat dikatakan tinggi.
Checklist tersebut dapat dipakai untuk mengidentifikasikan dan
memusatkan perhatian pada suatu subset dari known & predictable
risks dalam subkategori umum berikut.
7.3.1 Item Identifikasi Risiko
7.3.2. Komponen-komponen & Penggerak Risiko
157
7.3.1 Item Identifikasi Risiko Ukuran produk : risiko yang timbul sehubungan dengan ukuran
perangkat lunak yang direkayasa.
Dampak bisnis : berkaitan dengan batasan yang dibebankan oleh manajemen atau pasar.
Karakteristik pelanggan : berhubungan dengan kecerdikan pelanggan dan kemampuan perekayasa untuk berkomunikasi dengan pelanggan.
Definisi proses : risiko yang berkaitan dengan masalah-masalah proses dan teknis rekayasa.
Lingkungan pengembangan : berhubungan dengan ketersediaan dan kualitas tools yang digunakan dalam rekayasa.
Teknologi yang akan dibangun : risiko sehubungan dengan kompleksitas sistem dan ‘kebaruan’ teknologi.
Jumlah dan pengalaman staf : risiko sehubungan dengan keseluruhan teknik dan pengalaman perekayasa.
158
7.3.2. Komponen-komponen & Penggerak Risiko
Penggerak risiko yang mempengaruhi komponen-komponen risiko PL -
kinerja, biaya, support, dan jadwal, harus diidentifikasi.
7.3.2.1 Komponen Risiko
• Performance risk
Derajat ketidakpastian bahwa produk akan memenuhi persyaratan-
persyaratannya dan sesuai untuk pemakaian yang diperuntukkannya.
• Support risk
Derajat ketidakpastian bahwa PL akan mudah dikoreksi, diadaptasi,
dan ditingkatkan.
• Cost riskDerajat ketidakpastian bahwa anggaran proyek akan terjaga (tetap).
• Schedule risk
Derajat ketidakpastian bahwa jadwal proyek tidak akan berubah dan
bahwa produk akan diserahkan tepat waktu.
159
7.3.2.2 Penggerak Risiko
Dampak dari setiap penggerak risiko pada komponen risiko dibagi (dikelompokkan) ke dalam salah satu dari empat kategori berikut;
kecil sekali (negligible),
kecil (marginal),
kritis (critical), dan
bencana (catastrophic).
Tabel berikut ini yang dikembangkan oleh Angkatan Udara AS merupakan pedoman untuk menunjukkan konsekuensi potensial kesalahan (label 1) dan konsekuensi potensial jika hasil akhir yang diinginkan tidak tercapai (label 2).
160
COMPONENTS
CATEGORY
PERFORMANCE SUPPORT COST SCHEDULE
CATASTROPHIC
CRITICAL
MARGINAL
NEGLIGIBLE
1
2
1
1
1
2
2
2
161
7.4. Proyeksi Risiko
Proyeksi risiko, atau disebut juga estimasi risiko, mencoba
untuk menentukan peringkat setiap risiko berdasarkan dua
hal;
• Kemungkinan atau probabilitas bahwa risiko tersebut
nyata ada,
• Akibat (konsekuensi) pada problem-problem yang terkait
pada risiko tersebut bila benar terjadi.
7.4.1 Kegiatan Proyeksi Risiko
7.4.2 Pembuatan Tabel Risiko
7.4.3 Penilaian Risiko
162
7.4.1 Kegiatan Proyeksi Risiko
• Menetapkan suatu skala yang mencerminkan kemungkinan yang dibayangkan pada suatu risiko,
• Melukiskan akibat-akibat dari risiko tsb.
• Mengestimasi dampak risiko pada proyek dan produk, dan
• Mencatat akurasi keseluruhan dari proyeksi risiko tsb sehingga tidak akan terjadi salah pengertian.
Untuk memudahkan digunakan tabel berikut.
163
7.4.2 Pembuatan Tabel Risiko
Teknik sederhana untuk proyeksi risiko adalah
dengan Tabel Risiko (lihat tabel).
Setelah semua risiko yang mungkin (terpikirkan)
serta probabilitas kemunculannya dan tingkat
dampaknya, tertuliskan semua, tahap selanjutnya
adalah mengurutkan berdasarkan resultan
probabilitas dan dampak (merupakan kegiatan
penentuan prioritas).
Tahap selanjutnya adalah menentukan cut-off line.
164
Risks Category Probability Impact RMMM
Size estimate may be significantly low
Larger number of users than planned
Less reuse than planned
End users resist system
Delivery deadline will be tightened
Funding will be lost
Customer will change requirements
Technology will not meet expectations
Lack of training on tools
Staff inexperienced
Staff turnover will be high
...
...
PS
PS
PS
BU
BU
CU
PS
TE
DE
ST
ST
60%
30%
70%
40%
50%
40%
80%
30%
80%
30%
60%
2
3
2
2
2
3
2
1
2
1
3
PS : Product Size BU : Business Risk
CU : Customer Risk TE : Technology Risk
DE : Development Risk ST : Staff Risk
Cut-off
165
Risiko-risiko di atas garis cut-off harus ditangani
dengan seksama.
Risiko-risiko di bawah garis cut-off dievaluasi
kembali untuk menentukan prioritas tahap kedua.
Penggerak-penggerak risiko (bukan dampaknya)
dapat dinilai berdasarkan skala probabilitas
kualitatif dengan nilai-nilai: impossible,
improbable, probable, dan frequent.
166
management
concern
probability of
occurrence
impact
1.0
0
very low
very high
high
Faktor risiko
dengan
pengaruh tinggi
tetapi
probabilitas
rendah, tidak
boleh
menyerap
sebagian besar
perhatian
manajemen.
low
Pengaruh Probabilitas dan Dampak
Risiko thd Perhatian Manajemen
167
7.4.3 Penilaian Risiko
Tingkat referen resiko adalah tingkat degradasi
kinerja, pembengkakan biaya, kesulitan
dukungan, dan melesetnya jadual atau
kombinasinya yang menyebabkan proyek
diterminasi.
Tingkat referen resiko ini memiliki nilai tunggal
yang disebut referent point yang merupakan titik
impas untuk meneruskan atau menghentikan
proyek sama-sama dapat diterima. Titik-titik ini
kemudian dibuat prediksinya (lihat gambar). Bila
suatu kombinasi resiko jadwal dan biaya jatuh
pada daerah kurva yang tertutup akan
menyebabkan proyek terhenti.
168
Proyeksi membengkaknya jadwal
Pro
ye
ks
i m
ele
se
tnya
ja
dw
al
Titik referen (nilai biaya,nilai waktu)
169
7.5. Pengurangan (Mitigation), Monitoring, dan Manajemen Risiko (RMMM)
Semua kegiatan analisis risiko mempunyai satu tujuan tunggal : membantu tim proyek dalam pengembangan suatu strategi untuk menghadapi risiko.
Strategi yang efektif harus mempertimbangkan 3 isu berikut:
• menghindari risiko (risk avoidance),• monitoring risiko (risk monitoring),• manajemen risiko dan perencanaan kemungkinan
(risk management & contingency planning).
170
7.5.1 Menghindari Risiko (risk avoidance)
Bila tim PL mengadopsi cara proaktif, maka penghindaran risiko selalu merupakan strategi yang terbaik.
Hal ini dicapai dengan mengembangkan rencana untuk mengurangi/menghindari risiko (risk mitigation).
Misal : pergantian staf (turnover) yang tinggi merupakan salah satu risiko proyek (ri), yang digambarkan dalam bentuk triplet sbb :
[ri, li, xi]
Berdasarkan pada data historis dan intuisi, kemungkinan (li) pergantian staf diestimasi sebesar 0,7 dan pengaruh (xi) dari risiko tersebut diprediksi kritis pada biaya dan jadwal proyek.
171
Untuk mengurangi risiko ini, manajemen proyek harus mengembangkan suatu strategi untuk mengurangi turnover. Langkah-langkah yang mungkin diambil adalah sbb.
1. Adakan pertemuan dengan staf untuk menentukan sebab-sebab turnover (misal kondisi kerja yang jelek, gaji rendah, pasar tenaga kerja yang kompetitif).
2. Ambil tindakan untuk mengurangi sebab-sebabtersebut sebelum proyek mulai.
3. Begitu proyek mulai, misalkan turnover akan terjadi, maka kembangkan teknik-teknik untuk menjamin kontinuitas bila seseorang meninggalkan pekerjaannya.
172
4. Organisir tim proyek sehingga informasimengenai setiap kegiatan pengembangan tersebar luas.
5. Tentukan standar dokumentasi dan tetapkan mekanisme untuk memastikan bahwa dokumen-dokumen tersebut dibuat dengan tepat.
6. Laksanakan kajian antarteman terhadap semua pekerjaan tersebut sehingga lebih dari satu orang yang terbiasa dengan pekerjaan itu.
7. Tentukan backup anggota staf pada setiap teknologi kritis.
173
7.5.2 Monitoring Risiko (risk monitoring)
Sebagaimana proyek bergerak maju, kegiatan risk monitoring mulai.
Manajer proyek memantau faktor-faktor yang dapat memberikan
indikasi apakah risiko kemungkinan menjadi nyata atau kurang nyata?
Dalam contoh staff turnover, faktor-faktor berikut harus dipantau.
• Perilaku umum dari anggota tim berdasarkan pada tekanan-
tekanan proyek.
• Derajat kesatuan tim (kekompakan).
• Hubungan interpersonal di antara anggota tim.
• Masalah-masalah potensial yang berkaitan dengan kompensasi
dan keuntungan.
• Ketersediaan (availability) pekerjaan-pekerjaan di dalam
perusahaan tersebut dan di luar.
174
7.5.3 Manajemen Risiko dan Perencanaan Kemungkinan
Risk management & contingency planning
mengasumsikan bahwa upaya pengurangan
(mitigation) telah gagal dan risiko telah menjadi
kenyataan.
Saat proyek sudah benar-benar berjalan dan jika
strategi mitigasi juga dijalankan, maka backup
telah tersedia (ada), informasi terdokumentasi,
dan pengetahuan telah disebarkan pada tim.
Selain itu, manajer proyek dapat secara temporer
melakukan pemusatan kembali sumber-sumber
(dan menyesuaikan kembali jadwal proyek).
175
7.6 Safety Risks & Hazards (keselamatan & bahaya)
Risiko tidak hanya terbatas pada proyek PL itu sendiri.
Risiko dapat muncul setelah PL sukses dibuat dan
diserahkan kepada pelanggan.
Risiko-risiko ini secara tipikal berkaitan dengan akibat-
akibat dari kegagalan PL di lapangan.
Walaupun probabilitas kegagalan pada sistem yang
direkayasa dengan baik adalah kecil, suatu fault yang
tidak terdeteksi pada sistem kontrol atau monitoring
yang berbasis komputer dapat menyebabkan kerugian
yang besar.
176
Software safety & hazard analysis adalah kegiatan
software quality assurance yang memusatkan
perhatian pada identifikasi dan penilaian hazard-
hazard yang potensial yang dapat memberi
dampak negatif pada PL dan menyebabkan seluruh
sistem gagal.
***
8. PROJECT SCHEDULING &
TRACKING8.1 Konsep Dasar8.1.1 Penyebab Keterlambatan Proyek PL8.1.2 Prinsip-prinsip Dasar8.2 Hubungan Manusia dan Kerja8.2.1 Contoh8.2.2 Distribusi Effort8.3 Penentuan Rangkaian Tugas Proyek PL8.3.1 Rangkaian Tugas (Task Set)8.3.2 Beberapa Tipe Proyek8.3.3 Tingkat Kesulitan8.3.4 Penentuan Kriteria Adaptasi8.3.5 Penghitungan Nilai Task Set Selector8.3.6 Contoh Perhitungan TSS8.3.7 Contoh Perhitungan TSS utk Proyek Pengembangan Aplikasi Baru8.3.8 Memilih Task-task Rekayasa PL8.3.9 Contoh task-task utama rekayasa perangkat lunak8.4 Rincian Task-task Utama8.5 Penentuan Task Network8.6 Penjadwalan8.7 Project Plan
8.1 Konsep Dasar
8.1.1 Penyebab Keterlambatan Proyek PL
• Batas penyerahan yang tidak realistis yang ditetapkan oleh seseorang di luar grup rekayasa PL dan memaksakannya pada manajer dan praktisi dalam grup tsb.
• Perubahan kebutuhan pelanggan yang tidak tercermin dalam jadwal.
• Memandang rendah jumlah sumber daya yang akan diperlukan untuk mengerjakan pekerjaan tsb.
• Resiko-resiko yang dapat diprediksi dan/atau resiko-resiko yang tidak dapat diprediksi yang belum dipertimbangkanketika proyek dimulai.
• Kesulitan-kesulitan teknis yang belum dapat diramalkan sebelumnya.
• Kesulitan-kesulitan manusia yang tidak dapat
diprediksi sebelumnya.
• Miskomunikasi di antara staf proyek yang
mengakibatkan keterlambatan.
• Ketidakmampuan manajer proyek untuk mengetahui
bahwa proyek tidak mengikuti jadwal dan tidak
melakukan tindakan yang dapat mengatasi masalah
tsb.
Batas waktu yang agresif (tidak realistik) adalah sebuah
kenyataan. Seringkali batas waktu tersebut ditetapkan
berdasarkan alasan-alasan yang disetujui oleh orang
yang menetapkan batas waktu tersebut, tetapi
seharusnya juga disetujui oleh orang yang
mengerjakannya.
8.1.2 Prinsip-prinsip Dasar
Realitas RPL : ada ratusan tugas kecil yang harus
dikerjakan untuk mencapai tujuan yang lebih besar.
Tugas manajer proyek : menentukan tugas-tugas proyek,
mengindentifikasi tugas-tugas yang kritis, dan menelusuri
kemajuannya untuk memastikan bahwa penundaan dapat
direorganisasi setiap hari.
Solusi : manajer harus mempunyai jadwal yang telah
ditetapkan dengan derajat resolusi yang memungkinkan
manajer memonitor kemajuan dan mengontrol proyek
tersebut.
Penjadwalan proyek PL : suatu kegiatan mendistribusikan beban kerja terestimasi sepanjang durasi proyek yang telah direncanakan dengan mengalokasikan beban kerja pada tugas-tugas rekayasa PL. Prinsip-prinsip dasarnya sbb
Prinsip-prinsip Dasar
1. Compartmentalization (pembagian). Proyek harus
dibagi-bagi ke dalam sejumlah tugas dan aktivitas yang
dapat ditangani. Untuk melakukan ini, baik produk
maupun proses harus didekomposisi.
2. Interdependency (saling ketergantungan). Saling
ketergantungan dari setiap tugas dan aktivitas yang
dibagi-bagi harus ditentukan. Beberapa tugas harus
dikerjakan berurutan; yang lain dapat dikerjakan secara
bersamaan. Beberapa kegiatan tidak dapat dimulai
karena harus menunggu hasil dari kegiatan lain.
Beberapa kegiatan lainnya dapat bekerja secara bebas.
3. Time allocation (alokasi waktu). Masing-masing tugas
yang akan dijadwalkan harus dialokasikan dalam
sejumlah satuan kerja (misalnya kerja orang-hari).
Selain itu harus ditetapkan waktu mulai dan waktu
selesai.
4. Effort Validation (validasi kerja). Dengan alokasi waktu,
manajer harus menjamin bahwa tidak terjadi alokasi
yang melebihi jumlah staf yang ada dalam suatu waktu.
5. Defined responsibilities (batasan tanggungjawab).
Setiap tugas yang dijadwalkan harus ditugaskan kepada
satu anggota tim tertentu.
6. Defined outcomes (batasan keluaran). Setiap tugas
yang dijadwalkan harus memiliki keluaran tertentu.
7. Defined milestones (tonggak ukur). Setiap tugas atau
grup tugas harus terkait dengan project milestone.
8.2 Hubungan Manusia dan Kerja
8.2.1 Contoh
Misal ada 4 orang SE, masing-masing mampu menghasilkan 5000 LOC/th bila bekerja sendiri-sendiri dalam proyek individual.
Bila ke-4 SE tersebut ditempatkan pada sebuah tim untuk proyek (mis 1 tahun) terdapat 6 jalur komunikasi.
Masing-masing jalur komunikasi tsb butuh waktu yang harus disisihkan dari waktu membuat PL.
Krn overhead yang berkaitan dgn komunikasi untuk masing-masing jalur komunikasi diasumsikan produktivitas tim perjalur berkurang dengan 250 LOC/th.
Produktivitas tim menjadi :
4*5000 – 6*250 = 18.500 LOC/th
atau berkurang
(1500/2000) x 100% = 7,5%
dari yang diharapkan shg dpt menyebabkan proyek terlambat.
Misal bila 2 bln sebelum penyerahan, ditambahkan lagi 2 SE shg jumlah jalur menjadi 14. Diasumsikan per SE tambahan: 840 LOC / 2 bln shg produktivitas tim menjadi :
4*5000 + 2*840 – 14*250 = 18.180 LOC/th (vs 18.500).
Ini menunjukkan bahwa Jumlah Tenaga Kerja tidak memiliki hubungan linier dengan Produktivitas Kerja.
Suatu hubungan empirik yang menyatakan jumlah LOC (L)
dengan effort (E) dan waktu pengembangan (t), adalah;
L = P x (E/B)1/3 t4/3
dengan P adalah parameter produktivitas (antara 2000
sampai 28.000), B adalah faktor keahlian khusus (antara
0,16 sampai 0,39; lih 6.5.2.3). Bila persamaan tersebut
ditata lagi akan diperoleh :
E = L3/(P3t4)
Misal sebuah proyek PL real time membutuhkan usaha
33.000 LOC dan 12 person-year. Bila 8 orang ditugaskan
dalam tim, maka proyek akan terselesaikan kira-kira dalam
1,3 tahun. Tetapi jika waktu penyelesaian diulur 6 bln lagi
(diselesaikan dalam 1,75 tahun) dengan rumus di atas
diperoleh E = 3,8 person-year, artinya tenaga kerja dapat
dikurangi hingga 4 orang saja. Mana yg menguntungkan?
8.2.2 Distribusi Effort
Distribusi beban kerja yang dianjurkan dalam phase-phase
definisi & pengembangan adalah 40 - 20 - 40; 40% atau
lebih beban kerja dialokasikan untuk tugas-tugas front-end
(analisis & design); 40% dipakai dalam back-end testing
dan 20% untuk coding.
Distribusi effort tergantung pada karakteristik proyek. Effort
yang dihabiskan dalam perencanaan proyek jarang
mencapai lebih dari 2% atau 3%.
Analisis persyaratan-persyaratan dapat menghabiskan 10%
sampai 25% effort. Sedangkan effort yang dihabiskan
dalam analisis atau pembuatan prototype tergantung pada
ukuran dan kompleksitas proyek; 20% s/d 25% biasanya
dihabiskan untuk perancangan PL.
Karena beban kerja juga diberikan dalam software
design, kesulitan-kesulitan yang akan dihadapi
dalam coding juga akan berkurang; kisaran antara
15% s/d 20% dari effort keseluruhan dapat dicapai.
Testing dilanjutkan dengan debugging dapat
mencapai 30% s/d 40%. Kekritisan PL sering
dipengaruhi oleh jumlah testing yang diperlukan.
Untuk PL yang human-rated persentasenya bahkan
lebih tinggi.
8.3. Penentuan Rangkaian Tugas Proyek PL
8.3.1 Rangkaian Tugas (Task Set)
Sejumlah model proses: linier sequensial,iterative, evolutionary, dsb, penuh dengansekumpulan task yang memungkinkan tim PLmenentukan, mengembangkan, dan padaakhirnya memelihara PL komputer.
Tidak ada satu set tunggal yang cocok untuksemua proyek. Oleh karena itu proses PL yangefektif harus menentukan sekumpulan task set,masing-masing dirancang untuk memenuhikebutuhan-kebutuhan tipe proyek yang berbeda.
Task set adalah sekumpulan task-task pekerjaan
rekayasa PL, milestones, dan deliverables yang
harus dipenuhi untuk menyelesaikan proyek.
Task set yang dipilih harus memberikan disiplin
yang cukup untuk mencapai kualitas PL yang
tinggi, tetapi harus tidak membebani tim proyek
dengan kerja yang tidak perlu.
Task set dirancang untuk mengakomodasi
berbagai tipe proyek dan tingkat kesulitan (degree
of rigor) yang berbeda.
8.3.2 Beberapa Tipe Proyek
• Proyek-proyek pengembangan konsep.
• Proyek-proyek pengembangan aplikasi baru.
• Proyek-proyek peningkatan kemampuan aplikasi
yang sudah ada.
• Proyek-proyek perawatan aplikasi.
• Proyek-proyek reengineering.
8.3.3 Tingkat Kesulitan
Degree of rigor (tingkat kesulitan) adalah suatu fungsi
dari berbagai karakteristik proyek.
Terdapat 4 degree of rigor.
o casual,
o structured,
o strict,
o quick reaction.
Manajer proyek harus mengembangkan suatu cara yang
sistematis untuk pemilihan degree of rigor yang sesuai
untuk suatu proyek.
Untuk memenuhi hal tersebut, kriteria adaptasi proyek
didefinisikan dan nilai task set selector dihitung, sbb.
8.3.4 Penentuan Kriteria Adaptasi
Kriteria adaptasi dipakai untuk menentukan degree of rigor
bagi proses PL yang akan dipakai pada proyek.
Sebelas kriteria adaptasi (grade 1-5) untuk proyek PL:
• ukuran proyek,
• jumlah user,
• kekritisan misi yang diemban,
• umur (lamanya) aplikasi tersebut akan dipakai,
• kestabilan dalam persyaratan,
• kemudahan komunikasi customer/developer,
• kemapanan (maturity) teknologi yang dipakai,
• kendala-kendala pada kinerja,
• karakteristik embedded/nonembedded,
• project staffing, dan
• reengineering factors.
Masing-masing kriteria adaptasi diberi grade
antara 1 s/d 5. Grade1 merepresentasikan suatu
proyek yang membutuhkan subset yang kecil pada
task-task proses dan persyaratan-persyaratan
metodologi dan dokumentasi adalah minimal.
Grade 5 merepresentasikan suatu proyek yang
memiliki satu set task-task proses lengkap yang
harus dipergunakan, seluruh persyaratan-
persyaratan metode, dan dokumentasinya
substansial.
8.3.5 Penghitungan Nilai Task Set Selector(TSS)
Memilih task set yang sesuai untuk sebuah proyek
dengan langkah-langkah berikut.
• Periksa masing-masing kriteria adaptasi dan beri
grade yang sesuai berdasarkan karakteristik
proyek.
• Periksa faktor bobot (nilai berkisar antara 0.8 s/d
1.2) yang diberikan pada masing-masing kriteria.
Faktor bobot menunjukkan tingkat pentingnya
(relatif) dari kriteria adaptasi tertentu pada tipe
PL yang dibuat terhadap lingkungan lokal.
• Kalikan grade dengan faktor bobot dan dengan
entry point multiplier (bernilai 0 atau 1; yang
menunjukkan relevansi kriteria adaptasi dengan
tipe proyek) untuk tipe proyek yang sedang
dikerjakan.
Grade * weighting_factor * entry_point_multiplier
• Hitung task set selector dengan mengambil nilai
rata-rata dari product. Lihat tabel berikut.
8.3.6 Contoh Perhitungan TSS
Adaptation Criteria
Size of project
Number of users
Business criticality
Longevity
Stability of requirements
Ease of communication
Maturity of technology
Performance constraints
Embedded/nonembedded
Project staffing
Interoperability
Reengineering factors
Grade Weight Entry Point Multiplier Product
Conc. NDev. Enhan. Maint. Reeng.
0
0
0
0
0
1
1
0
1
1
0
0
1
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
1
0
1
1
1
1
0
1
1
1
0
1
1
0
0
0
1
1
0
1
1
1
0
1
1
1
1
1
1
1
1
1.20
1.10
1.10
0.90
1.20
0.90
0.90
0.80
1.20
1.00
1.10
1.20
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
Task set selector (TSS) _______
Task Set Selector Value Degree of Rigor
TSS < 1.2
1.0 < TSS < 3.0
TSS > 2.4
casual
structured
strict
Adaptation Criteria
Size of project
Number of users
Business criticality
Longevity
Stability of requirements
Ease of communication
Maturity of technology
Performance constraints
Embedded/nonembedded
Project staffing
Interoperability
Reengineering factors
Grade Weight Entry Point Multiplier Product
Conc. NDev. Enhan. Maint. Reeng.
1
1
1
1
1
1
1
1
1
1
1
0
1.20
1.10
1.10
0.90
1.20
0.90
0.90
0.80
1.20
1.00
1.10
1.20
2.4
3.3
4.4
2.7
2.4
1.8
1.8
2.4
3.6
2.0
4.4
0.0
Task set selector (TSS) 2.8
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
_______
2
3
4
3
2
2
2
3
3
2
4
0
8.3.7 Contoh Perhitungan TSS untuk Proyek Pengembangan Aplikasi Baru
8.3.8 Memilih Task-task Rekayasa PL
Untuk membuat jadwal proyek, task set harus didistribusikan pada garis waktu proyek.
Task set tergantung pada tipe proyek dan degree of rigor.
Masing-masing tipe proyek dapat didekati dengan menggunakan model proses (linier sekuensial, iterative, atau evolutionary).
Dalam beberapa hal, suatu tipe proyek dapat beralih, secara perlahan, menuju tipe proyek lainnya (sebagai contoh, proyek pengembangan konsep baru dapat dilanjutkan menjadi proyek pengembangan aplikasi baru, dst).
8.3.9 Contoh task-task utama rekayasa perangkat lunak
untuk pengembangan konsep adalah;
• concept scoping,
• preliminary concept planning,
• technology risk assessment,
• proof of concept,
• concept implementation,
• customer reaction to concept.
Sifat dasar dari task-task pengembangan konsep adalah
iterative.
Bila model proses linier yang dipilih, maka dapat dilihat
gambar berikut.
Project
DefinitionPlanning
Engineering/
ConstructionRelease
Customer
Evaluation
Concept development
1.1 Concept scoping
1.2 Preliminary concept planning
1.3 Technology risk assessment
1.4 Proof of concept
1.5 Concept implementation
1.6 Customer reaction
New Application
Development Projects
Application
Enhancement Projects
Application
Maintenance
Reengineering
Project
Definition
Planning
Engineering/
Construction
Release
Customer
Evaluation
Customer reaction
Concept scoping
Preliminary concept planning
Technology risk assessment
Proof of concept
Concept implementation
8.4 Rincian Task-task Utama
Task-task utama dapat dipakai untuk menentukan
jadwal makroskopik bagi suatu proyek.
Jadwal makroskopik tersebut harus dirinci lagi untuk
menghasilkan jadwal proyek terinci.
Rincian tersebut dapat dimulai dengan
mendekomposisi task-task utama ke dalam set-set
subtask.
Contoh task refinement untuk proyek pengembangan
konsep: concept scoping task, dengan menggunakan
process design language.
Tugas I.1 Penentuan Ruang Lingkup Konsep
I.1.1 Mengindentifikasi kebutuhan, keuntungan, dan
pelanggan potensial
I.1.2 Menentukan kejadian output/kontrol dan input yang
diharapkan, yang mengendalikan aplikasi
Memulai Tugas I.1.2
I.1.2.1 Mengkaji deskripsi kebutuhan yang ditulis
I.1.2.2 Memperoleh daftar output/input yang tampak
pada dokumen
dst ..........
8.5 Penentuan Task Network
Task-task dan subtask-subtask mempunyai saling
ketergantungan berdasarkan pada urutan
pengerjaannya.
Selain itu bila lebih dari satu orang bekerja pada
proyek tersebut, ada kemungkinan task-task
dikerjakan secara paralel, task konkuren ini harus
dikoordinasikan.
Task network adalah representasi grafis dari aliran
task untuk suatu proyek.
I.1
Concept
scoping
I.2
Concept
planning
I.3a
Tech. Risk
Assessment
I.4
Proof of
Concept
I.5b
Concept
Implement
I.5c
Concept
Implement
I.5a
Concept
Implement
Integrate
a, b, c
I.6
Customer
Reaction
I.3b
Tech. Risk
Assessment
I.3c
Tech. Risk
Assessment
Contoh Task Network
8.6 Penjadwalan
Penjadwalan proyek PL tidak berbeda dengan
penjadwalan multitask engineering effort lainnya.
Tool-tool & teknik-teknik umum untuk penjadwalan
proyek dapat dipakai untuk proyek PL dengan
sedikit modifikasi.
Program Evaluation and Review Technique
(PERT) dan Critical Path Method (CPM) adalah
dua metoda penjadwalan proyek yang dapat
dipakai pada proyek pengembangan PL.
Work tasks week 1 week 2 week 3 week 4 week 5
1.1.1 Identify need and benefits
Meet with customers
Identify needs and project constraints
Establish product statement
Milestone: product statement defined
Tracking the Schedule
Tracking dapat dipenuhi dengan sejumlah cara yang
berbeda.
• Adakan pertemuan berkala untuk membahas status
proyek; setiap anggota tim melaporkan kemajuan dan
masalah-masalah yang dihadapi.
• Evaluasi hasil semua review yang dilakukan selama
proses rekayasa PL.
• Tentukan apakah formal project milestone telah
dipenuhi sesuai dengan tanggal yang telah terjadwal?
• Bandingkan waktu mulai sebenarnya dengan waktu
mulai terjadwal untuk masing-masing proyek task.
• Pertemuan informal dengan para praktisi untuk
mendapatkan penilaian subyektifnya atas kemajuan
saat itu dan problem-problem yang tampak.
8.7 Project Plan
Setiap langkah dalam proses rekayasa PL harus
menghasilkan suatu hasil kerja yang dapat
diperiksa dan dapat bertindak sebagai dasar untuk
langkah berikutnya.
Software project plan dihasilkan di akhir dari
planning tasks.
Dia memberikan informasi tentang cost dan
jadwal yang akan dipakai selama proses rekayasa
PL.
Project Planning ContentI. Pendahuluan
A. Tujuan Rencana
B. Ruang Lingkup dan Tujuan Proyek
1. Pernyataan Ruang Lingkup
2. Fungsi-Fungsi Utama
3. Isu-isu Kinerja
4. Batasan Manajemen dan Teknis
II. Estimasi Proyek
A. Data Historis yang Digunakan untuk Estimasi
B. Teknik-teknik Estimasi
C. Estimasi Usaha, Biaya, Durasi
III. Strategi Manajemen Risiko
A. Tabel Risiko
B. Pembahasan Risiko untuk Dikelola
C. Rencana RMMM untuk setiap Risiko
IV. Jadwal
V. Sumber Daya Proyek
VI. Staf Organisasi
VII. Pelacakan dan Mekanisme Kontrol
VIII. Lampiran
***
9. Software Quality Assurance
9.1 Ruang Lingkup
9.2 Konsep Kualitas
9.2.1 Kualitas
9.2.2 Kontrol Kualitas
9.2.3 Jaminan Kualitas
9.2.4 Biaya Kualitas
9.3 Aktivitas SQA
9.4 Kajian Perangkat Lunak (Software Review)
9.5 Dampak Defects Software thd. Biaya
9.6 Kajian Teknik Formal (Formal Technical Review)
9.7 Review9.7.1 Review Meeting9.7.2 Laporan Review9.7.3 Pedoman Review9.8 Reliabilitas Perangkat Lunak9.8.1 Reliabilitas (kehandalan)9.8.2 Pengukuran Reliabilitas & Availabilitas9.9 Software Safety & Hazard Analysis9.10 Rencana SQA
9.1 Ruang Lingkup
Tujuan utama dari rekayasa perangkat lunak adalah menghasilkan perangkat lunak yang berkualitas tinggi
Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh prosesperangkat lunak, yang meliputi:
pendekatan manajemen kualitas
teknologi rekayasa perangkat lunak yang efektif (metode)
kajian teknik formal yang diaplikasikan pada keseluruhan proses perangkat lunak
strategi pengujian multitiered
kontrol dokumentasi perangkat lunak dan perubahan yang dibuat untuknya
prosedur untuk menjamin kesesuaian dengan standar pengem-bangan perangkat lunak
mekanisme pengukuran dan pelaporan
9.2 Konsep Kualitas
9.2.1 Kualitas Kualitas (menurut American Heritage Dictionary) adalah sebuah
karakteristik atau atribut dari sesuatu yang dapat diukur, dibandingkan dengan standar yang diketahui.
Berdasarkan pada sifat pengkurannya, ada dua jenis kualitas yang ada, yaitu kualitas desain dan kualitas konformansi.
1. Kualitas desain mengacu pada karakteristik tertentu yang ditentukan oleh desainer terhadap item tertentu. Desain berkualitas bila produk yang dihasilkan sesuai dengan spesifikasi yang ditentukan. Kualitas desain mencakup syarat, spesifikasi dan desain sistem.
2. Kualitas konformansi adalah tingkat spesifikasi desain yang terus diikuti selama pembuatan. Semakin tinggi tingkat konformansi, semakin tinggi tingkat kualitas konformasi.
Kualitas konformansi difokuskan pada implementasi, jika implementasi mengikuti desain, dan sistem yang dihasilkan memenuhi persyaratan dan kinerja, maka kualitas konformasi menjadi tinggi.
9.2.2 Kontrol Kualitas
Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan.
Kontrol kualitas mencakup loop (kalang) umpan balik pada proses yang menciptakan produk kerja dengan membandingkan output dari setiap proses dengan spesifikasi yang telah ditetapkan.
9.2.3 Jaminan Kualitas
Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen.
Tujuan jaminan kualitas adalah untuk memberikan data yang diperlukan oleh manajemen untuk menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian dan konfidensi bahwa kualitas produk dapat memenuhi sasaran.
9.2.4 Biaya Kualitas
Biaya kualitas menyangkut semua biaya yang diadakan untuk menampilkan kualitas yang berhubungan dengan aktivitas.
Biaya kualitas dapat dibagi ke dalam biaya yang dihubungkan dengan pencegahan, penilaian, dan kegagalan.
Biaya pencegahan meliputi
perencanaan kualitas
kajian teknis formal (FTR)
perlengkapan pengujian
pelatihan
Biaya penilaian meliputi
inspeksi dalam suatu proses dan interproses
pemeliharaan dan kalibrasi peralatan
pengujian
Biaya kegagalan meliputi
Internal (sebelum penyerahan produk)
pengerjaan kembali
perbaikan
analisis mode kegagalan
Eksternal (setelah penyerahan produk)
resolusi keluhan
penggantian dan pengembalian produk
dukungan help line
jaminan
9.3 Aktivitas SQA
Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan dengan dua konstituen yang berbeda:
perekayasa perangkat lunak yang mengerjakan kerja teknis
kelompok SQA yang bertanggungjawab terhadap perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan
Aktivitas oleh kelompok SQA:
menyiapkan rencana SQA untuk suatu proyek;
berpartisipasi dalam deskripsi proses pengembangan proyek;
mengkaji aktivitas perangkat lunak untuk memverifikasi pemenuhan proses perangkat lunak yang sudah ditentukan;
meng-audit produk kerja perangkat lunak yang ditentukan untuk membuktikan kesesuaian dengan produk kerja yang ditentukan tersebut sebagai bagian dari proses perangkat lunak;
memastikan bahwa deviasi pada kerja dan produk kerja perangkat lunak didokumentasi dan ditangani sesuai prosedur pendokumentasian;
mencatat ketidakssesuaian dan melaporkannya kepada manajemen senior.
9.4 Kajian Perangkat Lunak (Software
Review)
Software reviews adalah sebuah filter untuk proses rekayasa perangkat lunak.
Reviews dilaksanakan di berbagai titik selama pengembangan perangkat lunak dan membantu menemukan error yang kemudian dapat dihilangkan.
Software reviews membantu untuk memurnikanproduk kerja perangkat lunak yang terjadi sebagai suatu hasil dari analisis, desain, dan coding.
FTR (Formal Technical Review) atau disebut walkthrough adalah filter yang paling efektif untuk meningkatkan kualitas PL.
9.5 Dampak Defects Software thd. Biaya
Dalam kontek proses PL, istilah defect dan fault adalah sinonim. Keduanya menyatakan secara tidak langsung suatu problem kualitas yang ditemukan setelah PL dirilis kepada end users.
Sasaran utama dari FTR adalah menemukan errors selagi proses PL berjalan sehingga tidak menjadi defect setelah PL dirilis.
Keuntungan sesungguhnya dari FTR adalah menemukan error sedini mungkin sehingga error tsb tidak menjalar ke langkah berikutnya dalam proses PL.
Sejumlah studi menunjukkan bahwa kegiatan desain mengintrodusir error antara 50% dan 65% dari seluruh error (dan pada akhirnya, seluruh defect) selama proses PL.
FTR telah menunjukkan bahwa sampai 75% efektif dalam menemukan cacat-cacat desain.
Dengan mendeteksi dan menghapus sejumlah besar persentase error, proses review secara subtansial mengurangi biaya pada langkah-langkah selanjutnya dalam phase-phase pengembangan dan maintenance.
9.6 Kajian Teknik Formal
(Formal Technical Review)
FTR adalah aktivitas jaminan kualitas perangkat lunak yang dilakukan oleh perekayasa perangkat lunak.
Tujuan FTR adalah: menemukan error dalam fungsi, logika, atau
implementasinya dalam berbagai representasi perangkat lunak;
memverifikasi bahwa perangkat lunak yang direview memenuhi syarat;
memastikan bahwa perangkat lunak tersebut telah direpresentasikan sesuai dengan standard yang telah ditentukan sebelumnya;
untuk mencapai perangkat lunak yang dikembangkan dengan cara yang seragam;
membuat proyek lebih mudah dikelola.
9.7 Review
9.7.1 Review Meeting
Review meeting (pertemuan kajian) adalah
pertemuan tim review produk kerja perangkat lunak
yang terdiri dari 3 sampai 5 orang guna mengkaji dan
mengevaluasi perangkat lunak yang telah dihasilkan.
Diakhir review, tim harus memutuskan apakah:
menerima hasil kerja tersebut tanpa modifikasi lebih
lanjut.
menolak hasil kerja tersebut karena adanya kesalahan
yang fatal, atau
menerima hasil kerja tersebut secara sementara
(error2 kecil telah ditemukan dan harus dikoreksi;
tetapi tidak perlu direview lagi).
9.7.2 Laporan Review
Ada 2 dokumen yg dihasilkan dalam review meeting
yaitu daftar masalah review (review issues list) dan
laporan rangkuman review (review summary report).
Review summary report memuat jawab dari 3
pertanyaan berikut:
(1) apa yg telah direview,
(2) siapa yg telah mereviewnya, dan
(3) apa yang telah ditemukan & apa kesimpulannya.
Review issues list berisi hal2 yang berguna dlm:
(1) mengidentifikasi area problem, dan
(2) bertindak sebagai action item checklist untuk
memandu produsen dalam melakukan koreksi.
9.7.3 Pedoman Review
Review produk, bukan produser
Menetapkan agenda dan tetap menjaganya
Membatasi perdebatan dan bantahan
Menetapkan area masalah, tetapi tidak mencoba untuk
menyelesaikan setiap masalah yang dicatat
Buat catatan tertulis
Membatasi jumlah peserta dan lakukan persiapan awal
Buat sebuah daftar utk setiap work product yang direview.
Alokasikan sumber-sumber daya dan jadwal waktu untuk FTR.
Lakukan pelatihan yang berguna bagi semua reviewer.
Review hasil-hasil review yang baru saja dilakukan.
9.8 Reliabilitas Perangkat Lunak
9.8.1 Reliabilitas (kehandalan)
Reliabilitas perangkat lunak didefinisikan sebagai probabilitas operasi komputer bebas kegagalan dalam suatu lingkungan tertentu dan waktu tertentu. Misal suatu PL memiliki reliabilitas 0,96 pada 8 jam eksekusi, berarti apabila PL tsb dieksekusi 100 kali selama 8 jam dia akan beroperasi dg benar 96 kali.
Kehandalan perangkat lunak dapat diukur, diarahkan, dan diestimasi dengan menggunakan data pengembangan historis.
9.8.2 Pengukuran Reliabilitas & Availabilitas
Dalam kenyataannya, semua kegagalan perangkat lunak dapat dilacak dari problem-problem desain atau implementasi.
Untuk sebuah sistem berbasis komputer, pengukuran sederhana kehandalan adalah berupa Mean Time Between Failure (MTBF),
MTBF = MTTF + MTTR(MTTF : mean time to failure dan
MTTR : mean time to repair)
Software availability adalah probabilitas bahwa sebuah program beroperasi berdasarkan persyaratannya pada suatu titik tertentu pada suatu waktu dan didefinisikan sebagai:
Availability = {MTTF/(MTTF + MTTR)} x 100%
9.9 Software Safety & Hazard Analysis
Keamanan perangkat lunak dan analisis risiko
adalah aktivitas SQA yang memfokuskan pada
identifikasi & penilaian hazard (risiko)
potensial yang mungkin berpengaruh negatif
terhadap perangkat lunak dan menyebabkan
seluruh sistem menjadi gagal (fail).
Bila risiko dapat diidentifikasi pada awal
proses rekayasa perangkat lunak, maka ciri-
ciri desain perangkat lunak dapat ditetapkan
shg akan mengeliminasi risiko potensial.
9.10 Rencana SQA
SQA plan adalah peta jalan untuk membangun jaminan kualitas perangkat lunak. SQA plan berfungsi sebagai template bagi aktivitas SQAyang dibangun untuk setiap proyek perangkat lunak.
Rencana SQA dicatat dalam dokumen produk kerja yang mencakup: dokumen proyek (rencana proyek); model (ERD); dokumen teknis (spesifikasi, rencana pengujian); dokumen pemakai (file-file help).
***
10. SOFTWARE CONFIGURATION MANAGEMENT10.1. Pendahuluan
10.1.1 Perubahan
10.1.2 Tujuan SCM
10.1.3 Software Maintenance vs Software Configuration Management
10.1.4 Informasi dan Perubahan
10.2. Software Configuration Management
10.2.1 Sumber Dasar Perubahan
10.2.2 Baseline
10.2.3 SCI Baseline dan Database Proyek
10.3 Software Configuration Item (SCI)
10.4. SCM Process
10.4.1 Tanggung Jawab SCM
10.4.2 Pertanyaan Seputar SCM
10.4.3 Tugas SCM
10.5 Identifikasi Objek dalam SC
10.5.1 Tipe Objek
10.5.2 Keunikan Objek
10.5.3 Hubungan Antar-Objek
10.5.4 Evolusi Objek
10.6 Kontrol Versi (Version Control)
10.6.1 Versi PL
10.6.2 Komponen
10.6.3 Varian
10.6.4 Hub Objek Konfigurasi, Komponen, Varian, dan Versi
10.7 Kontrol Perubahan
10.7.1 Proses Kontrol Perubahan
10.7.2 Kontrol Akses & Sinkronisasi
10.8 Audit Konfigurasi
10.8.1 Proses Audit Konfigurasi
10.8.2 Pertanyaan dalam Proses Audit Konfigurasi
10.8.3 Pelaporan Status Konfigurasi (Status Accounting)
10.9 Software Configuration Management (SCM) Standards
10.1.1 Perubahan
Perubahan adalah hal yang tidak dapat dihindarkan ketika
perangkat lunak komputer sedang dibuat.
Perubahan2 tersebut meningkatkan tingkat kebingungan
di antara para software engineer yang berkerja pada
proyek tersebut.
Kebingungan muncul bila perubahan2 tersebut tidak
dianalisis sebelum perubahan tersebut dilaksanakan;
dicatat sebelum diimplementasi, dilaporkan kepada yang
ingin mengetahui, atau dikontrol dengan suatu cara yang
akan meningkatkan kualitas & mengurangi error.
Software configuration management (SCM) adalah
kegiatan payung (umbrella activities) yang dilaksanakan
selama proses perangkat lunak.
10.1. Pendahuluan
Karena perubahan dapat terjadi kapan saja, maka
kegiatan SCM dibuat untuk;
1) mengidentifikasi perubahan,
2) mengontrol perubahan,
3) mengimplementasikan perubahan dengan benar,
dan
4) melaporkan perubahan kepada pihak-pihak yang
mempunyai kepentingan.
10.1.2 Tujuan SCM
Penting untuk dibedakan dengan jelas antara
software maintenance dan software configuration
management.
Software Maintenance adalah serangkaian aktivitas
rekayasa perangkat lunak yang terjadi setelah
perangkat lunak diserahkan ke pelanggan dan telah
dioperasikan.
Software configuration management adalah
serangkaian kegiatan tracking & control yang dimulai
ketika suatu proyek perangkat lunak dimulai dan
berakhir ketika perangkat lunak sudah tidak
beroperasi lagi.
10.1.3 Software Maintenance vs Software Configuration Management
Keluaran dari proses perangkat lunak adalah informasi yang
dapat dibagi ke dalam 3 kategori utama;
1) program komputer (baik dalam bentuk source code
maupun executable),
2) dokumen2 yang menjelaskan program komputer tersebut
(yang ditargetkan baik untuk technical practitioners
maupun users), dan
3) data (yang diisikan dalam program atau dikeluarkan dari
program).
Item2 yang terdiri dari semua informasi yang dihasilkan
sebagai bagian dari proses perangkat lunak secara kolektif
disebut Software Configuration Items (SCI).
10.1.4 Informasi dan Perubahan
Selama proses - rekayasa SCI berkembang dengan pesat.
System specification menghasilkan sebuah software project
plan dan software requirements specification (juga dokumen2
yang terkait dengan hardware), yang secara berurutan akan
menghasilkan dokumen2 untuk menciptakan suatu hirarki
informasi.
Perubahan masuk ke dalam proses rekayasa. Perubahan
dapat terjadi kapan saja, untuk suatu alasan. Ini sesuai dengan
Hukum 1 system engineering [BER80] yang menyatakan:
“Tidak masalah dimana anda berada dalam siklus kehidupan
sistem, sistem akan berubah, dan keinginan untuk
mengubahnya akan selalu ada selama siklus hidup tersebut”.
10.2.1 Sumber Dasar Perubahan
Terdapat 4 sumber dasar perubahan. Bisnis baru atau kondisi pasar yang mendiktekan perubahan2 dalam
produk atau aturan2 bisnis.
Keinginan pelanggan baru yang meminta modifikasi data yang
dihasilkan oleh sistem informasi; fungsionalitas yang diberikan oleh
produk, atau layanan yang diberikan oleh suatu sistem berbasis
komputer.
Reorganisasi dan/atau perampingan bisnis yang menyebabkan perubahan
prioritas proyek atau struktur tim rekayasa perangkat lunak.
Kendala2 anggaran atau jadwal yang menyebabkan redefinisi sistem atau
produk.
SCM adalah sekumpulan kegiatan yang telah dikembangkan untuk
menangani perubahan2 selama siklus hidup dari perangkat lunak
komputer.
SCM dapat dipandang sebagai kegiatan SQA yang dipakai selama
proses perangkat lunak.
10.2. Software Configuration Management
Perubahan adalah kenyataan hidup dalam pengembangan perangkat
lunak. Pelanggan ingin memodifikasi persyaratan2. Pengembang ingin
memodifikasi metode2 teknis. Manager ingin memodifikasi cara
pendekatan proyek.
Baseline adalah sebuah konsep SCM yang membantu dalam kontrol
perubahan2 tanpa secara serius menghalangi perubahan2 yang dapat
dijustifikasi.
IEEE mendifinisikan baseline sebagai:
Suatu spesifikasi atau produk yang telah direview secara formal dan
disetujui bersama, yang selanjutnya berfungsi sebagai dasar bagi
pengembangan lebih lanjut, serta dapat diubah hanya melalui
prosedur2 kontrol perubahan formal.
Dalam konteks rekayasa perangkat lunak, baseline adalah milestone
dalam rekayasa perangkat lunak yang ditandai dengan penyampaian
(delivery) SCI dan persetujuan (approval) SCI tersebut yang diperoleh
lewat suatu FTR.
10.2.2 Baseline
Baseline
system engineering
requirements analysis
software design
coding
testing
release
System Specification
Software Requirements Specification
Design Specification
Source Code
Test Plans/Procedures/Data
Operational System
SCIs
SCIs SCIsFormal
technical
reviews
Software
engineering
tasks
SCIs
SCIsSCM
controls
Project
database
approved
modified
extracted
stored
10.2.3 SCI Baseline dan Database Proyek
Jalur modifikasi
Perlu
modifikasi?
SCI merupakan informasi yang diciptakan sebagai bagian dari proses
rekayasa perangkat lunak.
SCI berikut menjadi target bagi teknik2 CM dan membentuk
sekumpulan baseline.
1. System Specification
2. Software Project Plan
3. Software Requirement Specification
a. Graphical analysis model
b. Process specifications
c. Prototype(s)
d. Mathematical specification
4. Preliminary User Manual
5. Design Specification
a. Data design description
b. Architectural design description
c. Modul design descriptions
d. Interface design descriptions
e. Object description
10.3 Software Configuration Item (SCI)
6. Source Code Listing
7. Test Specification
a. Test plan & procedure
b. Test cases & recorded results
8. Operation & Installation Manuals
9. Executable Program
a. Module executable code
b. Linked modules
10. Database Description
a. Schema & file structure
b. Initial content
11. As-built User Manual
12. Maintenance Documents
a. Software problem reports
b. Maintenance requests
c. Engineering change orders
13. Standard & Procedure for Software Engineering
Software Configuration Item (lanj)
10.4.1 Tanggung Jawab SCM
SCM adalah sebuah elemen penting dari SQA
Tanggung jawab utamanya adalah mengontrol
perubahan.
SCM juga bertanggung jawab untuk :
mengidentifikasi individual SCI & berbagai versi
perangkat lunak,
meng-audit software configuration untuk memastikan
bahwa dia telah dikembangkan dengan benar, dan
melaporkan semua perubahan yang telah dilakukan
pada konfigurasi tersebut.
10.4. SCM Process
Diskusi mengenai SCM memperkenalkan sekumpulan pertanyaan
kompleks sebagai berikut.
Bagaimana suatu organisasi mengidentifikasi dan menangani
berbagai versi yang ada dari sebuah program (dan
dokumentasinya) dalam suatu cara yang akan memungkinkan
perubahan ditampung secara efisien?
Bagaimana suatu organisasi mengontrol perubahan sebelum dan
setelah perangkat lunak dirilis ke pelanggan?
Siapa yang mempunyai tanggung jawab (otoritas) untuk
approving (menyetujui) & prioritizing (memprioritaskan)
perubahan?
Bagaimana kita yakin bahwa perubahan2 tersebut telah dilakukan
dengan benar?
Mekanisme apa yang dipakai untuk memberitahu yang lain
bahwa perubahan telah dilakukan?
10.4.2 Pertanyaan Seputar SCM
Pertanyaan2 tersebut membawa kepada definisi 5 tugas
(task) SCM :
identifikasi,
kontrol versi,
kontrol perubahan,
auditing konfigurasi, dan
pelaporan.
10.4.3 Tugas SCM
10.5.1 Tipe Objek
Untuk mengontrol & menangani SCI2, masing2 item harus
diberi nama berbeda dan kemudian diorganisir dengan
menggunakan metode berorientasi objek.
Dua tipe objek dapat diidentifikasi: basic objects (obyek
dasar) & aggregate objects (kumpulan obyek).
Sebuah basic object adalah sebuah “unit of text” yang
telah diciptakan oleh seorang software engineer pada
saat (selama) analisis, design, coding, atau testing.
Sebuah aggregate object adalah sekumpulan basic object
dan aggregate objects lainnya.
10.5 Identifikasi Objek dalam SC
Setiap object mempunyai sekumpulan fitur yang berbeda
yang mengidentifikasikannya secara unik;
sebuah nama (object name),
suatu deskripsi (object description),
suatu daftar sumber daya (resources list) dan
suatu realisasi (realization)
10.5.2 Keunikan Objek
Object name adalah sebuah string karakter yang
mengidentifikasi object secara tidak samar.
Object description adalah sebuah list item2 data yang
mengidentifikasi:
tipe SCI (misal dokumen, program, data) yang
direpresentasikan oleh object;
suatu project identifier; dan informasi perubahan
dan/atau versi.
Resources adalah entitas yang disediakan, diproses,
diacu atau sebaliknya diperlukan oleh object.
Realisasi adalah sebuah pointer pada “unit of text” untuk
suatu basic object dan null untuk suatu aggregate object.
10.5.2 Keunikan Objek (lanj)
Configuration object identification juga harus mempertimbangkan
hubungan yang ada antara “named objects”
Sebuah object dapat diidentifikasi sebagai <part-of> suatu aggregate
object.
Hubungan <part-of> menentukan sebuah hirarki object2.
Hubungan di antara object2 dalam suatu hirarki objek tidak hanya
sepanjang direct path dari hirarchical tree, tetapi dalam beberapa hal,
object2 diinterrelasikan melewati cabang2 dari object hirarchy.
Interrelationships antara configuration objects dapat
direpresentasikan dengan sebuah module interconection language
(MIL).
MIL menggambarkan interdependencies di antara configuration
objects dan memungkinkan suatu versi dari suatu sistem dikonstruksi
secara otomatis.
10.5.3 Hubungan Antar-Objek
Gambar : Configuration Objects
Design specification
data designarchitectural designmodule designinterface design
Test specification
test plantest proceduretest cases
Module N
interface descriptionalgorithm descriptionPDL
Data Model
Source code
Skema identifikasi untuk objek2 perangkat lunak harus
mengenali bahwa objek2 berevolusi selama proses
perangkat lunak.
Sebelum suatu objek dijadikan baseline, dia boleh
berubah berkali-kali, dan bahkan setelah suatu baseline
ditetapkan, perubahan2 mungkin cukup sering.
Dimungkinkan untuk menciptakan sebuah evolution graph
untuk suatu object. Evolution graph menggambarkan
sejarah perubahan dari object (lihat gbr).
Dimungkinkan juga perubahan2 dapat dilakukan pada
sembarang versi, tetapi tidak perlu pada semua versi.
10.5.4 Evolusi Objek
obj
1.0
obj
1.1
obj
1.2
obj
2.0
obj
2.1
obj
1.3
obj
1.4
obj
1.1.1
obj
1.1.2
Grafik Evolusi
Clemm[CLE89] menggambarkan version control dalam
konteks SCM sbb:
Configuration management mengijinkan seorang user
untuk menentukan konfigurasi alternatif dari sistem
software melalui pemilihan versi2 yang sesuai. Hal ini
didukung oleh atribut2 yang terkait dengan masing2 versi
software, dan kemudian juga mengijinkan suatu
konfigurasi ditentukan (dan dikonstruksi) dengan
menggambarkan serangkaian atribut yang diinginkan.
10.6 Kontrol Versi (Version Control)
Atribut2 yang dikemukakan di atas dapat sesederhana
seperti hanya sebuah nomor versi tertentu yang terkait
pada masing2 objek atau sekompleks seperti suatu string
dari variable boolean (switches) yang menunjukkan tipe
tertentu dari perubahan2 fungsional yang telah dilakukan
pada sistem.
Salah satu representasi dari versi2 yang berlainan dari
suatu sistem adalah evolution graph (lihat gbr).
Masing2 node pada graph tersebut adalah sebuah
aggregate object, yaitu satu versi lengkap (utuh) dari
perangkat lunak.
10.6.1 Versi PL
Masing2 versi perangkat lunak adalah sekumpulan SCI
(source code, dokumen2, data) dan setiap versi dapat
terdiri dari variant2 yang berbeda.
Untuk melukiskan konsep ini, pikirkan sebuah versi dari
sebuah program sederhana yang tersusun dari
komponen2 1, 2, 3, 4, dan 5 (lihat gbr).
Komponen 4 hanya dipakai bila software
diimplementasikan dengan menggunakan display warna.
Komponen 5 diimplementasikan bila tampilan yang
dipakai monochrome.
Oleh karena itu, dua variant dari versi tersebut dapat
ditentukan: (1) komponen2 1, 2, 3, dan 4; (2) komponen2
1, 2, 3, dan 5.
10.6.2 Komponen
Grafik Evolusi Revisi Perangkat Lunak
obj
1.0
obj
1.1
obj
1.2
obj
2.0
obj
2.1
obj
1.3
obj
1.4
obj
1.1.1
obj
1.1.2
1
2 3
4 5
components
variants
Untuk membangun varian yang sesuai dari suatu versi
tertentu dari suatu program, masing2 komponen dapat
diberikan suatu “attribute-tuple”, yaitu sebuah lis dari fitur2
yang akan menentukan suatu komponen tertentu harus
dipakai bila suatu varian tertentu dari suatu versi
perangkat lunak dibuat.
Satu atau lebih atribut diberikan untuk masing2 varian.
Sebagai contoh, suatu atribut ‘color’ dapat dipakai untuk
menentukan komponen yang harus disertakan bila color
display yang harus didukung.
Cara lain untuk mengkonseptualisir hubungan antara
komponen, varian2, dan versi2 (revisi2) adalah
merepresentasikannya sebagai “object pool”
10.6.3 Varian
components
versions
variants
object
Hubungan antara configuration object dan komponen2,
varian2, dan versi2 dapat direpresentasikan sebagai
sebuah ruang tiga dimensi.
Sebuah versi dapat dipilih dari beberapa varian yang ada
(sb vertikal) yang terdiri dari beberapa komponen.
Sebuah komponen tersusun dari sekumpulan objek2 pada
tingkat level revisi yang sama.
Sebuah varian adalah sekumpulan objek2 yang berbeda
pada tingkat revisi yang sama, dan oleh karena itu berada
berdampingan secara paralel dengan variant2 lain.
Sebuah versi baru ditentukan bila perubahan2 besar
(utama) dilakukan pada satu atau lebih object.
10.6.4 Hub Objek Konfigurasi, Komponen, Varian, dan Versi
Untuk proyek pengembangan perangkat lunak yang
besar, perubahan yang tidak terkontrol membawa pada
kekacauan (chaos).
Change control menggabungkan prosedur manusia dan
tool otomatis guna memberikan sebuah mekanisme untuk
mengontrol perubahan.
Suatu change request di submit dan dievaluasi untuk
menilai manfaat teknisnya, efek samping yang potensial,
dampak keseluruhan pada configuration objects dan
fungsi2 sistem lainnya.
10.7 Kontrol Perubahan
Hasil dari evaluasi tersebut dipresentasikan sebagai sebuah Change
Report yang dipakai oleh Change Control Authority (CCA), yaitu
seseorang atau grup yang membuat keputusan akhir terhadap status
dan prioritas dari perubahan tersebut.
Sebuah Engineering Change Order (ECO) dibuat untuk setiap
perubahan yang telah disetujui.
ECO menjelaskan perubahan2 yang harus dibuat, kendala2 yang
harus diperhatikan, dan kriteria2 untuk review & audit.
Objek yang akan diubah di’checked out’ dari basis data proyek,
dilakukan perubahan, dan kegiatan2 SQA yang bersesuaian
dilaksanakan.
Objek tersebut kemudian di’checked-in’ ke basis data dan mekanisme
version control yang sesuai dipakai untuk menciptakan versi
berikutnya dari perangkat lunak tersebut.
Proses check-in dan check-out mengimplementasikan dua elemen
penting dari kontrol perubahan, yaitu access control & synchronization
control.
10.7.1 Proses Kontrol Perubahan
Kontrol akses mengatur perekayasa perangkat lunak yang mempunyai otoritas untuk mengakses dan memodifikasi suatu configuration object tertentu (khusus).
Kontrol sinkronisasi membantu untuk memastikan bahwa paralel changes yang dilakukan oleh dua orang yang berbeda tidak saling overwrite satu terhadap lainnya.
Aliran kontrol akses & sinkronisasi dilukiskan secara skematik pada gbr berikut.
10.7.2 Kontrol Akses & Sinkronisasi
check-in
access
control
check-out
software
engineer
project
database
ownership
info
configuration object
(baseline version)
configuration object
(baseline version)
configuration object
(extracted version)
configuration object
(modified version)
unlock
lock
audit info
Change Control
Identifikasi, kontrol versi, dan kontrol perubahan
membantu pengembang perangkat lunak untuk
mempertahankan aturan, bila tidak akan mendatangkan
situasi yang chaotic & fluid.
Walaupun demikian, bahkan mekanisme kontrol yang
berhasil mentrack perubahan hanya sampai ECO
dibangkitkan.
Bagaimana kita dapat menjamin bahwa perubahan
tersebut telah diimplementasikan dengan benar?
Jawabnya adalah dua hal: (1) FTR, dan (2) software
configuration audit.
10.8 Audit Konfigurasi
FTR memusatkan pada ketepatan (correctness) teknis
dari configuration object yang telah dimodifikasi.
Para reviewer menilai SCI tersebut untuk menentukan
konsistensi terhadap SCI2 lain, penghilangan, dan
potensial side effects. FTR harus dilaksanakan untuk
semua perubahan termasuk yang paling sepele.
Software configuration audit melengkapi
(menyempurnakan) FTR dengan penilaian suatu
configuration object untuk karakteristik2 yang pada
umumnya tidak dipertimbangkan selama review.
10.8.1 Proses Audit Konfigurasi
Audit tersebut menanyakan dan menjawab pertanyaan2
berikut:
1. Apakah perubahan yang ditentukan dalam ECO telah dilakukan?
Apakah suatu modifikasi tambahan telah disertakan?
2. Apakah FTR telah dilakukan untuk menilai ketepatan teknis?
3. Apakah standard2 software engineering telah diikuti dengan
benar?
4. Apakah perubahan tersebut telah ditandai dalam SCI? Apakah
tanggal perubahan dan orang yang membuat perubahan telah
dicatat? Apakah atribut2 configuration object mencerminkan
perubahan tersebut?
5. Apakah prosedur2 SCM untuk pencatatan perubahan, perekaman,
dan pelaporan telah diikuti?
6. Apakah semua SCI yang terkait telah diupdate dengan benar?
10.8.2 Pertanyaan dalam Proses Audit Konfigurasi
Setiap kali suatu SCI diberi identifikasi baru atau
diupdate, sebuah Configuration Status Reporting CSR
entry dibuat.
Setiap kali suatu perubahan disetujui oleh CCA (yaitu,
suatu ECO dikeluarkan), sebuah entry CSR dibuat.
Setiap kali suatu configuration audit dilakukan, hasil2nya
dilaporkan sebagai bagian dari task CSR.
Output dari CSR dapat diletakkan dalam basis data on-
line shg pengembang perangkat lunak atau pengelola
(maintainers) dapat mengakses informasi perubahan
dengan keyword category.
10.8.3 Pelaporan Status Konfigurasi (Status Accounting)
Beberapa standard SCM awal, seperti MIL-STD-483,
DOD-STD-480A, dan MIL-STD-1521A, memusatkan
pada software yang dikembangkan untuk aplikasi
militer.
Standar ANSI/IEEE yang lebih baru, seperti
ANSI/IEEE Std. No. 828 - 1983, Std. No. 1042 - 1987,
dan Std. No. 1028 - 1988, dapat dipakai untuk
software komersial dan direkomendasikan baik untuk
organisasi2 rekayasa perangkat lunak besar & kecil.
***
10.9 SCM Standards
11. REKAYASA SISTEM BERBASIS KOMPUTER
III. METODE KONVENSIONAL
11.1 Sistem Berbasis Komputer (Computer-based System)
Sistem berbasis komputer bertujuan untuk mendukung berbagai
fungsi bisnis atau untuk mengembangkan suatu produk yang
dapat dijual untuk menghasilkan keuntungan bisnis.
Elemen-elemen sistem berbasis komputer:
1. Perangkat lunak (program komputer, struktur data, dan dokumen
yang berhubungan)
2. Perangkat keras (perangkat elektronik dan elektromekanik)
3. Manusia (user yang memakai perangkat lunak dan perangkat keras)
4. Basisdata (kumpulan informasi besar dan terorganisir yang diakses
melalui perangkat lunak)
5. Dokumentasi (manual, formulir, dan informasi deskriptif lainnya)
6. Prosedur (langkah-langkah yang menentukan penggunaan elemen
sistem)
Rekayasa Perangkat Lunak terjadi sebagai konsekuensi dari
suatu proses yang disebut Rekayasa Sistem Berbasis
Komputer (Rekayasa Sistem)
Rekayasa Sistem memfokuskan diri pada berbagai elemen,
analisis, desain, dan pengorganisasian elemen-elemen
tersebut ke dalam suatu sistem yang dapat menjadi sebuah
produk, jasa, atau teknologi untuk mentransformasi
informasi atau kontrol. Oleh sebab itu rekayasa sistem
cenderung pada pengembangan sistem berbasis komputer.
Proses Rekayasa Sistem disebut Rekayasa Informasi bila
konteks kerja berfokus pada sistem informasi bagi
manajemen yang bersifat unik bagi suatu institusi. Hasil
rekayasa ini dapat bersifat masal (menjadi suatu produk
yang dipasarkan masal) hanya bila dapat diterapkan di
berbagai institusi tanpa merubah fungsi-fungsi
transformasi.
11.1.1 Karakteristik Sistem Berbasis Komputer
Sistem Otomasi Pabrik
Sistem Pemanukfaturan
Sel PemanufakturanSistem Aliran Material
Perangkat Entry DataRobotMesin Control Numeric
Sistem InformasiSistem Inventori
Karakteristik Sistem Berbasis Komputer ditandai oleh adanya elemen-elemen yang berbasis komputer pula.
11.1.2 Hirarki Rekayasa Sistem
Rekayasa melingkupi sekumpulan metode dari atas ke bawah
(top-down) dan dari ke bawah ke atas (bottom-up) untuk
mengendalikan hirarki dari sistem makro.
Proses rekayasa sistem dimulai dengan sebuah world view (WV).
Semua domain bisnis atau domain produk diuji untuk memastikan
bahwa bisnis atau konteks teknologi yang tepat dapat dibangun.
Pada domain tertentu, kebutuhan sistem yang ditargetkan (mis.
data, SW, HW, manusia) dianalisis. Kemudian analisis, desain, dan
konstruksi dari elemen yang ditargetkan diinisiasi.
Pada puncak hirarki, suatu konteks yang lebih luas dibangun, dan
di bagian dasarnya, aktivitas teknik lengkap - yang dilakukan oleh
disiplin rekayasa yang relevan - dilakukan.
Gambaran sistem :
WV = {D1 D2 D3……Dn} WV = wold view (sebuah sistem besar)
Di = {E1 E2 E3……En} Di = domain sistem (sub sistem)
E1 = {C1 C2 C3……Cn} Ei = elemen (pembentuk domain)
11.1.3 Hirarki Rekayasa Perangkat Lunak
Domain Bisnis / Produk
domain interes
World View
elemen sistemPandangan Domain
Pandangan Elemen
Pandangan Detail
11.2 Rekayasa Informasi Tujuan dari rekayasa informasi (information engineering) adalah
untuk
menentukan arsitektur yang memungkinkan suatu organisasi /bisnis (selanjutnya disebut bisnis saja) menggunakan informasi secara efektif,
membuat suatu rencana menyeluruh guna mengimplementasi arsitektur-arsitektur tersebut.
Tiga arsitektur yang harus dianalisis dan dirancang dalam konteks dan tujuan bisnis:
Arsitektur data
memberikan kerangka kerja untuk kebutuhan informasi dan bisnis atau fungsi bisnis. Blok bangunan dari arsitektur ini adalah objek data yang digunakan oleh suatu basisdata dan ditransformasikan untuk memberikan informasi yang melayani kebutuhan bisnis.
Arsitektur aplikasi
melingkupi elemen-elemen dari suatu sistem yang mentransformasi objek ke dalam arsitektur data untuk keperluan bisnis.
Infrastruktur teknologi
menyangkut perangkat keras dan perangkat lunak yang digunakan untuk mendukung aplikasi dan data.
Untuk memodelkan arsitektur sistem, ditetapkan hirarki
aktivitas rekayasa informasi, mulai dari World View, Domain
View, Element View hingga Detail View.
WV dicapai melalui information strategy planning (ISP),
dengan memandang bisnis keseluruhan sebagai sebuah entitas
dan memisahkan domain bisnis yang penting untuk perusahaan
/ institusi keseluruhan
Pandangan domain yang dikaitkan dengan IE disebut analisis
area bisnis/ Business Area Analysis (BAA)
BAA adalah pengindentifikasian data lengkap dan persyaratan
fungsi (dalam bentuk proses) dari area bisnis yang dipilih, yang
diindentifikasi selama ISP, dan memastikan interaksi mereka
(dalam bentuk matriks)
BAA mendefinisikan objek-objek data, hubungan antarobjek,
dan aliran data.
11.2.1 Hirarki Rekayasa Informasi
Perusahaan
Sistem Informasi
Area Bisnis
PerencanaanStrategi Informasi (World View)
persyaratan pemrosesan
Analisis Area Bisnis(Pandangan Domain)
Desain Sistem Bisnis(Pandangan Elemen)
Konstruksi dan Integrasi (Pandangan Detail)
area bisnis
Perekaya Perangkat Lunak
11.2.2 Analisis Area Bisnis
Gambaran analisis area bisnis adalah sbb.
BAA membentuk suatu kerangka kerja lengkap untuk membangun perusahaan / organisasi yang berbasis informasi.
BAA menggunakan satu area bisnis pada suatu waktu dan menganalisisnya secara detail.
BAA menggunakan diagram dan matriks untuk memodelkan dan merekam data / aktivitas dalam perusahaan serta untuk memberikan pemahaman yang jelas tentang relasi antaraspek-aspek informasiperusahaan secara rinci dan tajam.
Untuk memodelkan relasi antaraspek-aspek informasi perekayasa informasi harus menggambarkan penggunaan objek data dan transformasinya pada masing-masing area bisnis dan menggambarkan pula mekanisme fungsi dan proses bisnis pada masing-masing area bisnis dalam mentransformasi objek data.
Untuk melakukan tersebut, BAA menggunakan sejumlah model:
model data
model aliran proses
diagram dekomposisi proses
matriks lintas referensi
11.2.3 Pemodelan Data
Objek : Pelanggan
Atribut :
nama
nama perusahaan objek : perusahaan
klasifikasi pekerjaan dan otoritas pembelian
alamat bisnis dan informasi kontak
pembelian sebelumnya
tanggal kontak terakhir rekaman kontak
status kontak status kontak terakhir
tanggal kontak selanjutnya
sifat kontak yang disepakati
Atribut nama perusahaan dimodifikasi untuk menunjuk objek lain yang disebut ‘perusahaan’ yang dapat berisi informasi tambahan mengenai besar perusahaan, kebutuhan pembelian, nama kontak yang lain, dsb., yang berguna dalam domain penjualan.
11.2.4 Pemodelan Proses
Kegiatan pada suatu area bisnis mencakup serangkaian fungsi bisnis, yang diuraikan ke dalam proses bisnis yang lebih rinci.
Contoh : proses yang terjadi dalam fungsi penjualan
membangun kontak pelanggan
menyediakan literatur dan informasi yang sesuai
mengarahkan pertanyaan dan perhatian
memberi evaluasi produk
menerima pesanan penjualan
memeriksa ketersediaan konfigurasi yang dipesan
menyiapkan pesanan pengiriman
mengkonfirmasikan konfigurasi, penetapan harga, tanggal pengiriman ke pelanggan
mengirim pesanan pengiriman ke bagian pengiriman
tindak lanjut ke pelanggan
Penjabaran proses tersebut tertuang dalam model sbb.
11.2.5 Pemodelan Aliran Informasi
Model aliran proses diintegrasikan dengan model data untuk
mengindikasi aliran informasi melalui suatu area bisnis.
Membangunkontak
pelanggan
MemberiInformasi
produk
MemberiEvaluasiproduk
MengarahkanPertanyaan/
perhatian
MenerimaPesanan
penjualan
MemeriksaKonfigurasi
ketersediaan
MenyiapkanPesanan
pengiriman
Mengkonfir-masikan Info
pesanan
MembangunKontak
pelangganTindak
lanjut kepelanggan
Model aliran proses untuk fungsi penjualan
Membangunkontak
pelanggan
MemberiInformasi
produk
MemberiEvaluasiproduk
MengarahkanPertanyaan/
perhatian
MenerimaPesanan
penjualan
MemeriksaKonfigurasi
ketersediaan
MenyiapkanPesanan
pengiriman
Mengkonfir-masikan Info
pesanan
MembangunKontak
pelangganTindak
lanjut kepelanggan
Rekayasa Informasi merupakan suatu pendekatan Rekayasa Sistem yang digunakan untukmenentukan arsitektur yang memungkinkan organisasi /bisnis menggunakan informasi scr efektif.
Rekamankontak
Infoproduk
Deskripsiproduk
Pemenuhanpesanan
DeskripsiProduk terevaluasi
Pelanggan
Pemenuhanpesanan
Format konfigurasi
ketersediaan
Info pesanan
Info pesanan utk konfirmasi
Datapengiriman
Pemenuhanpesanan
Info pesanan
Info query Data pesanan
• Objek data input dan output yang diperlihatkan untuk masing-masing proses menunjukkan transformasi informasi untuk menyelesaikan suatu fungsi bisnis
11.3 Rekayasa Sistem Rekayasa Sistem merupakan suatu aktivitas pemecahan masalah yang
dihadapi sistem.
Data produk, fungsi, dan perilaku sistem harus ditemukan, dianalisis,
dan dialokasikan ke dalam komponen-komponen rekayasa.
Perekayasa sistem harus memperjelas dan membatasi persyaratan
sistem dengan mengidentifikasi ruang lingkup fungsi dan kinerja yang
diinginkan.
Rekayasa Sistem diawali dengan analisis sistem untuk membentuk
model arsitektur sistem dan spesifikasi sistem.
11.3.1 Aktivitas-aktivitas dalam Analisis Sistem
Analisis sistem dilakukan dengan sasaran sebagai berikut:
mengidentifikasi kebutuhan pelanggan,
mengevaluasi konsep sistem untuk fisibilitas,
mengalokasikan fungsi-fungsi untuk perangkat keras, perangkat lunak, manusia, basisdata, dan elemen sistem yang lain,
membuat batasan biaya dan jadwal,
menciptakan definisi sistem yang membentuk pondasi bagi semua kerja rekayasa subsekuen.
1. Identifikasi Kebutuhan
Dilakukan dengan cara bertemu dengan pelanggan dan pemakai akhir.
Hasil dari indentifikasi kebutuhan dispesifikasi dalam suatu dokumen konsep sistem
2. Studi Fisibilitas
Fisibilitas ekonomi; evaluasi biaya pengembangan dibobot dengan pemasukan utama atau keuntungan yang didapat dari sistem atau produk yang dikembangkan
Fisibilitas teknis; studi mengenai fungsi, kinerja, dan batasan yang dapat mempengaruhi kemampuan untuk mencapai sebuah sistem yang dapat diterima
Fisibilitas legal; pertimbangan mengenai pelanggaran, kekerasan, atau liabilitas (pertanggung jawaban) yang dihasilkan dari pengembangan sistem
Alternatif; evaluasi mengenai pendekatan alternatif pada pengembangan sistem atau proyek
3. Analisis Ekonomi
Analisis biaya keuntungan yang menggambarkan biaya untuk pengembangan proyek dan membandingkannya dengan keuntungan yang nyata dan tidak nyata dari suatu sistem.
4. Analisis Teknis
Analis mengevaluasi kebaikan teknis dari konsep sistem, dan pada saat yang sama mengumpulkan informasi tambahan mengenai kinerja, reliabilitas, kemampuan pemeliharaan, dan produksibilitas.
11.3.2 Pemodelan Arsitektur Sistem Untuk mengembangkan model sistem maka digunakan template
arsitektur, yang terdiri dari lima daerah pemrosesan : (1) interface
pemakai; (2) input; (3) fungsi dan kontrol; (4) output; (5)
pemeliharaan dan self-test.
Pemrosesan interface pemakai
Pemrosesaninput
Pemrosesanoutput
Fungsi proses dan kontrol
Pemeliharaan dan self-test
Contoh: Diagram konteks arsitektur untuk CLSS
Sistem Pengurutan
Conveyor Line
OperatorStasiunsorting
OperatorStasiunsorting
PembacaBar code
Conveyorlain
Mekanismepengurutan
mainframe
Data permintaan Query danreport
Kode Perintahlangsir
Bar code
Data diagnostik
Indikatorkecepatan
Data pelaporanterformat
***
12. KONSEP DAN PRINSIP ANALISIS
12.1 Analisis Persyaratan
12.2 Prinsip-Prinsip Analisis
12.3 Area Kerja Analisis
12.3.1 Identifikasi dan Perumusan Masalah
12.3.2 Evaluasi dan Sintesis
12.3.3 Pemodelan Analisis
12.3.4 Spesifikasi
12.3.5 Kajian
12.1 Analisis PersyaratanAnalisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani jurang antara alokasi perangkat lunak tingkat sistem dan desain perangkat lunak.
Analisis persyaratan memungkinkan perekayasa sistem menentukan fungsi dan kinerjaperangkat lunak, menunjukkan interface perangkat lunak dengan elemen-elemen sistem yang lain, dan membangun batasan yang harus dipenuhi oleh perangkat lunak.
Desain PL
Perangkat Lunak
Elemen2
lain
Analisis
Persyaratan PL
REKAYASA
SISTEM
Analisis
Persyaratan PL
12.2 Prinsip-Prinsip Analisis
1. Prinsip Operasional
Domain informasi dari suatu masalah harus dipahami
Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan
Perilaku perangkat lunak harus direpresentasikan
Model-model yang menggambarkan informasi, fungsi dan tingkah laku sistem harus dipecah-pecah secara hirarki
Proses analisis harus bergerak dari informasi dasar ke detail implementasi
2. Prinsip Panduan untuk rekayasa persyaratan
Memahami masalah sebelum membuat model analisis
Mengembangkan prototipe, sehingga pemakai memahami bagaimana interaksi manusia dan komputer
Merekam asal dan alasan untuk setiap persyaratan
Menggunakan pandangan persyaratan bertingkat
Memprioritaskan persyaratan
Mengurangi ambiguitas
12.3 Area Kerja Analisis
Analisis persyaratan memberikan model-model yang akan
diterjemahkan ke dalam data, arsitektur, interface, dan desain
prosedural kepada perancang perangkat lunak.
Analisis persyaratan perangkat lunak dapat dibagi menjadi lima area
kerja:
1) Identifikasi dan Perumusan Masalah
2) Evaluasi dan Sintesis
3) Pemodelan
4) Spesifikasi
5) Kajian
12.3.1 Identifikasi dan Perumusan Masalah
Identifikasi bisa diawali dengan mempelajari spesifikasi sistem dan atau
rencana proyek perangkat lunak. Contohnya :
Pemasok besar suku cadang kendaraan bermotor membutuhkan sistem
kontrol inventaris. Analis merumuskan masalah yang berhubungan
dengan sistem manual yang ada sbb.
Ketidakmampuan untuk dengan cepat memperoleh status suatu komponen.
Dua atau tiga hari berkali-kali memperbarui suatu file kartu.
Pemesanan kembali secara bertingkat kepada penjual yang sama karena
tidak ada cara untuk menghubungkan para penjual dengan komponen, dsb.
12.3.2 Evaluasi dan Sintesis
Dalam melakukan analisis, fokus utama analis adalah pada ‘apa’? bukan ‘bagaimana?’.
Data apakah yang diproduksi dan dikonsumsi, batasan apakah yang dipakai?
Selama aktivitas sintesis, evaluasi, dan solusi analis menciptakan model-model sistem untuk memahami aliran data dan kontrol, operasi behavioraldan pemrosesan fungsional, serta muatan informasi.
Model tersebut berfungsi sebagai dasar bagi desain perangkat lunak dan untuk membuat spesifikasi perangkat lunak.
Spesifikasi lengkap belum bisa didapatkan pada tahap ini, pendekatan alternatif pada analisis persyaratan adalah prototyping.
12.3.3 Pemodelan Analisis
DataDictionary
(DD)
EntityRelationshipDiagram(ERD)
DataFlowDiagram(DFD)
StateTransitionDiagram
(STD)
Struktur Model AnalisisDD : mendeskripsikan semua objek data yang dikonsumsi PL
ERD : menggambarkan hub antarobjek data
DFD : merepresentasikan transformasi data dan fungsi-fungsi tranformasi
STD : menunjukkan perilaku sistem akibat kejadian eksternal
PSPEC : mendeskripsi setiap fungsi / proses pada DFD
CSPEC : deskripsi aspek kontrol PL
Pemodelan Data
Model data terdiri dari tiga informasi yang saling tergantung:
1. Objek data adalah representasi dari semua informasi gabungan yang harus dipahami oleh perangkat lunak
Objek data dapat berupa entitas eksternal (semua sumber data atau yang mengkonsumsi informasi), suatu benda (laporan atau tampilan), peristiwa (sambungan telepon) atau event (sebuah alarm), peran (tenaga penjualan), unit organisasi (bagian akuntansi), atau suatu struktur (file).
2. Atribut adalah properti suatu objek data.
Atribut digunakan untuk:
menamai sebuah contoh dari objek data,
menggambarkan contoh,
membuat referensi ke contoh yang lain pada tabel yang lain
3. Hubungan adalah relasi antara objek data yang satu dengan yang lainnya.
Misal: Sensor dan Pintu hubungan : Sensor menggerakkan Pintu
Objek Data, Atribut dan Hubungan
Objek: Atribut: Hubungan:
NamaAlamatUmurLisensi MengemudiNomor
MerkModelNomor IDTipe Warna
memiliki
Representasi Tabular Objek Data
Merk Model ID# Tipe Warna Pemilik
Lexus LS400 AB123 Sedan Putih RSP
BMW 750iL X456 Coupe Merah CCD
Ford Taurus YZ276 Sedan Putih LJL
Chevy Corvette Q1234 Sport Hijau BLF
pengidentifikasi
Atribut deskriptif Atribut
referensial
Atribut penamaan
Mengikat satu objek data ke data lain, dalam kasus ini, pemilik
12.3.4 SpesifikasiPada prinsipnya Spesifikasi merupakan representasi persyaratan
dari perangkat lunak yang akan dibangun. Diperlukan pendekatan sbb.
Teknik spesifikasi yang terfasilitasi (Facilitated Aplication Specification Techniques = FAST)
Pertemuan dilakukan di tempat netral yang dihadiri oleh pengembang maupun pelanggan.
Tujuannya : identifikasi masalah, pemecahan, negosiasi, membentuk persyaratan PL.
Ada fasilitator (sebaiknya konsultan) yang bertugas mengontrol pertemuan.
Penyebaran fungsi kualitas
Quality Function Deployment (QFD) adalah teknik manajemen kualitas yang menterjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak
QFD berkonsentrasi pada pemaksimalan kepuasan pelanggan
Hasil proses spesifikasi dituangkan dalam Dokumen Spesifikasi PL(lih.SCI).
12.3.5 KajianKajian digunakan untuk memastikan Spesifikasi sudah lengkap,
konsisten, dan akurat. Contoh pertanyaan kajian :
Apakah tujuan dan sasaran yang dinyatakan bagi PL tetap konsisten dengan tujuan dan sasaran sistem?
Apakah interface ke semua elemen sistem sudah digambarkan?
Apakah aliran informasi dan struktur telah didefinisikan dengan tepat bagi domain masalah?
Apakah diagram telah dipresentasikan dengan jelas?
Apakah fungsi mayor tetap ada dalam ruang lingkup dan sudah digambarkan dengan tepat?
Apakah perilaku PL konsisten dengan informasi yang harus diproses dan fungsi yang harus dilakukannya?
Apakah batasan desain realistis?
Apakah risiko teknologis pengembangan sudah dipertimbangkan?
Apakah kriteria validasi dinyatakan secara detil dan memadai untuk menggambarkan sebuah sistem yang berhasil?
Apakah ada inkonsistensi, penghilangan, atau redundancy?
Apakah kontak dengan pelanggan sudah lengkap?
Apakah pemakai sudah mengkaji manual atau prototype?
***
13. KONSEP DAN PRINSIP
PERANCANGAN
(DESAIN)
13.1 Transformasi Model Analisis ke Model Desain
DataDictionary
(DD)
EntityRelationshipDiagram(ERD)
DataFlowDiagram(DFD)
StateTransitionDiagram
(STD)
Desain Data
Desain Arsitektur
Desain
Interface
Desain
Prosedural
13.2 Desain DataDesain data adalah tahapan pemilihan representasi logis dari
objek data yang telah teridentifikasi dalam Analisis Persyaratan dan Spesifikasi. Prinsip2nya :
Prinsip2 analisis sistem yang diterapkan pada fungsi dan perilaku PL juga perlu diterapkan pada data.
Semua struktur data dan operasinya harus teridentifikasi.
Kamus data harus dibangun untuk merepresentasikan hub antarobjek data dan batasan2nya.
Keputusan desain data tingkat rendah harus dilakukan di akhir proses desain data.
Konsep information hiding (penyembunyian informasi suatu modul agar tidak diakses oleh modul lain yang tidak berkepentingan) dan perangkaian sangat penting bagi kualitas PL.
Pustaka struktur data dan operasi yang berguna harus dikembangkan agar dapat digunakan kembali.
Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi tipe data abstrak.
13.3. Desain Arsitektur PLArsitektur merupakan struktur hirarkhi dari komponen program (modul),
interaksinya, dan struktur data yang digunakan. Terdapat bbrp model
desain arsitektur :
Model Struktural : bdsk struktur komponen program
Model Kerangka Kerja : berupa peningkatan abstraksi desain
berdasarkan kerangka kerja
Model Dinamis : menggambarkan perilaku berdasarkan external events
Model Proses : fokus pada proses
Model Fungsional : menggambarkan hirarkhi fungsional
Alat process modeling : Flow Chart, Flow of Document, Data Flow Diagram, Structured Chart, HIPO Diagram, Pseudocode, Nassi-Shneiderman Chart, Warnier-Orr Diagram, Michael Jackson Diagram, Functional Decomposition, Action Diagram, Data Navigation Diagram, HOS Chart, dsb.
Alat data modeling : Entity Relationship Diagram, Network Diagram, Hierarchical Diagram, Table Normalization, atau gabungannya.
Alat object modeling : Object Diagram (Coad/Yourdon, Rambaugh, Firesmith, Booch, dsb.) yang dapat dibangun dengan Oracle Designer/2000, Microsoft Visual Studio – Enterprise Tools (Modeler), dsb.
Alat working modeling : Excelerator, Easycase, Oracle Designer/2000, Microsoft Visual Studio - Enterprise Tools (Modeler), dsb.
Studi perbandingan tentang berbagai macam alat tersebut dapat dijumpai di buku Structured Techniques (James Martin& Carma McClure).
13.3.1. Modularitas13.3.1.1 Modularitas dan Kompleksitas Problem
Modularitas diterapkan melalui pembagian PL ke dalam komponen
– komponen PL yang dapat dipanggil terpisah sehingga bila
terdapat problem, maka problem tsb akan lebih mudah
diselesaikan. Kompleksitas ( C ) problem (p1 dan p2) yang
bergabung menjadi satu, lebih besar dibandingkan bila problem
tersebut dipandang secara terpisah.
C(p1+p2) > C(p1) + C(p2)
Oleh sebab itu modularitas penting dalam desain arsitektur PL.
Namun berkaitan dengan biaya, sebaiknya dihindari kondisi
undermodularity maupun overmodularity. Semakin banyak modul
semakin rendah biaya per-modul tetapi semakin tinggi biaya
integrasinya.
13.3.1.2 Independensi Fungsional
Konsep ini mrpk pertumbuhan langsung dari modularitas, konsep abstraksi PL,
dan Information Hiding. Independensi diukur melalui Kohesi dan Kopling.
Kohesi
Modul yang kohesif seharusnya hanya melakukan satu hal saja (kohesi tinggi =
fungsional <> koinsidental).
Kopling
Sehubungan dengan perangkaian dengan modul lain, maka modul yang baik
seharusnya memiliki hubungan yang sederhana (kopling rendah)
13.3.2 Proses Desain Arsitektur
13.3.2.1 Pemetaan Transformasi
Informasi dari ‘dunia eksternal’ mengalir masuk ke dalam PL dan keluar lagi dalam bentuk informasi dunia eksternal. Misal ketikan keyboard dan bunyi di saluran telpon akan masuk ke pusat transformasi dan dialirkan ke dunia luar dalam bentuk tampilan layar. Aliran ini disebut aliran transformasi. Dalam DFD dapat dijumpai adanya aliran transformasi ini.
Guna menyusun struktur program aliran transformasi dari DFD ini dipetakan dengan langkah pengkajian thd Context DFD, penentuan pusat transformasi, pemfaktoran dan penyaringan, dan pemetaan. Contohnya sbb.
Contoh Pemetaan
Transformasi
Membangunkontak
pelanggan
MemberiInformasi
produk
MemberiEvaluasiproduk
MengarahkanPertanyaan/
perhatian
MenerimaPesanan
penjualan
MemeriksaKonfigurasi
ketersediaan
MenyiapkanPesanan
pengiriman
Mengkonfir-masikan Info
pesanan
MembangunKontak
pelangganTindak
lanjut kepelanggan
Penerimaan
Pesanan
Penjualan
Promosi Persiapan
Pengiriman
13.3.2.1 Pemetaan Transaksi
Aliran transaksi ditandai dengan pergerakan data sepanjang jalur masuk yang
mengkonversikan informasi dunia eksternal ke dalam suatu transaksi.
Transaksi ini akan menimbulkan jalur aksi. Pusat aliran informasi tempat
banyak jalur aksi berasal disebut pusat transaksi.
Pemetaan DFD yang mengandung aliran transaksi ke struktur program hampir
sama dengan pemetaan aliran transformasi, namun yang diidentifikasi adalah
pusat transaksinya (lihat contoh)
Contoh Pemetaan Transaksi
a
b
d p
q
r
s
d
c1
r sq
p
a
b
Kontrol Transaksi
13.4 Desain Interface
1. Internal : merupakan desain interface antarmodul dalam PL yang dikendalikan oleh data
yang harus mengalir di antara modul-modul. Aliran transformasi dalam DFD merupakan
pijakan utama dalam desain ini selain kemampuan bahasa pemrograman.
2. Eksternal : merupakan interface untuk entitas eksternal (tidak termasuk manusia), misalnya
sensor pada PL Safehome.
3. Manusia – Mesin : merupakan interface antara manusia dengan PL (Human – Computer
Interface). Interface ini memiliki tantangan besar karena berkaitan dengan pengguna
dengan berbagai karakter yang lebih sulit untuk dipelajari. Terdapat tiga kategori pedoman
desain HCI sbb.
a. Interaksi Umum
Format konsisten
Berikan umpan balik
Konfirmasi untuk aksi destruktif (misal Hapus)
Ijinkan pembatalan (misal Undo)
Kurangi jumlah informasi yang harus diingat
Efisiensi dalam dialog, gerakan (tangan), pemikiran
Perlindungan thd kegagalan
Kategorikan aktivitas sejenis dan posisinya di layar
Sediakan Help yang sensitif konteks
Berikan petunjuk singkat (tools tips) pada setiap button / ikon / nama
Gunakan perintah dan nama2 yang pendek
b. Output
Tampilkan informasi yang relevan dg konteks
Jangan membanjiri pemakai dg informasi
Gunakan label, singkatan, warna yg standar dan konsisten
Peliharalah konteks visual saat pengguna melakukan zoom-in / zoom-out
Pesan kesalahan harus memiliki arti yang jelas
Gunakan variasi huruf, indentasi, pengelompokan untuk memudahkan pemahaman
Gunakan jendela untuk tipe-tipe informasi yang berbeda
Gunakan tampilan alami (bukan angka / grafik) bila memungkinkan
Geografi layar dioptimalkan shg tidak ada jendela yang ‘hilang’ / sulit ditemukan
Berikan kemungkinan kustomisasi output (utk advance user)
Jangan ada informasi / data yang tidak lengkap / hilang sebagian
c. Input
Minimalkan jumlah aksi input (combo box, list, dsb.)
Konsisten
Berikan kemungkinan kustomisasi input (utk advance user)
Mode input harus fleksibel (mouse / keyboard)
Non-aktifkan button / ikon yang tidak relevan dengan aksi
Berikan kesempatan untuk mengontrol aliran interaksi (mengubah, membetulkan, mengulang)
Sediakan Help
Jangan meminta aktivitas manual (perhitungan, tanggal, waktu, dsb) bila dapat dilakukan oleh PL
13.5 Desain Prosedural
Spesifikasi prosedural ditetapkan setelah desain data, arsitektur, dan interface selesai guna penyusunan algoritma PL.
Desain prosedural diterapkan melalui teknik pemrograman terstruktur yang didasarkan pada struktur logika algoritma :
Sekuensial
Percabangan
Perulangan
Alat-alat yang dapat digunakan :
Flow Chart, HIPO Diagram, Pseudocode, Nassi-Shneiderman Chart, Warnier-Orr Diagram, Action Diagram, HOS Chart, dsb.
***
14. PENGUJIAN
PERANGKAT LUNAK
14.1 Dasar-dasar Pengujian
14.2 Teknik Pengujian
14.3 Strategi Pengujian dan V&V
Metrik Kualitas PL
Operasi
Produk
Revisi
Produk
Transisi
Produk
Faktor Kualitas PL McCall
Correctness, Reliability, Usability, Integrity, Efisiency
Portability
Reusability
Interoperability
Maitainabilty
Flexibility
TESTABILITY
14.1 Dasar-dasar Pengujian
Testability
Karakteristik PL yang dapat diuji :
Operabilitas
Observabilitas
Kontrolabilitas
Dekomposabilitas
Kesederhanaan
Stabilitas
Kemampuan untuk dapat dipahami
Sebelum melakukan pengujian perlu dipersiapkan Test Case terlebih dahulu agar diperoleh kemungkinan tertinggi dalam menemukan kesalahan dengan waktu dan usaha yang minimum. Desain Test Case dapat dilakukan melalui berbagai teknik pengujian sbb.
14.2 Teknik Pengujian
14.2.1 Pengujian White-Box (Glass Box)
Semua jalur independen pada suatu modul ditelusuri minimal 1
kali
Semua jalur keputusan logis True / False dilalui
Semua loop dieksekusi pada batas yang tercantum dan batas
operasionalnya
Struktur data internal digunakan agar validitas terjamin.
1. Pengujian Basis Path
Merupakan salah satu teknik White Box
Merupakan salah satu teknik pengujian struktur kontrol
Menjamin semua statemen dalam setiap jalur independen
program dieksekusi minimal 1 kali.
Perhitungan jalur independen dapat dilakukan melalui metrik
Cyclomatic Complexity
Didasarkan pada teori graph.
Desain prosedural diterjemahkan dalam suatu grafik alir.
Dihitung melalui 4 cara
V(G) = jumlah region grafik alir
V(G) = jumlah path
V(G) = E – N + 2
V(G) = P + 1
E : Edge
N : Node
P : simpul predikat (IF / percabangan)
Ri : Region ke I [MCCL92]
Contoh V(G) = 4
V(G) > 10 : more troblesome and less reliable[MART88].
Cyclomatic Complexity
1
2,3
4,5
6
9
7 8
11
10
R3
R4
R1
R2
2. Pengujian Struktur Kontrol
Teknik ini merupakan perbaikan dari basis path yang
meliputi :
Pengujian Kondisi : didasarkan pada struktur
kontrol (=, <, >, not, and, dsb.)
Pengujian Aliran Data : didasarkan pada adanya
hubungan antar-statemen pada program.
Pengujian Loop : berfokus pada validitas konstruksi
loop.
14.2.2 Pengujian Black-Box
Pengujian ini berfokus pada persyaratan fungsional PL dan merupakan
komplemen dari pengujian White-Box. Hal tsb dapat dicapai
melalui :
1. Pengujian Graph-based : dimulai dengan membuat grafik
sekumpulan node yang mempresentasikan objek(misal New File,
Layar baru dg atributnya), link (hubungan antarobjek), node-
weight (misal nilai data tertentu seperti atribut layar, perilaku),
dan link-weight (karakteristik suatu link, misal menu select)
2. Equivalence Partitioning : membagi domain input untuk
pengujian agar diperoleh kelas-kelas kesalahan (misal kelompok
data karakter, atau atribut yang lain)
3. Analisis Nilai Batas : pengujian berdasarkan nilai batas domain
input.
4. Pengujian Perbandingan : disebut juga pengujian back-to-back
yang diterapkan pada pada suatu versi PL atau PL redundan untuk
memastikan konsistensinya.
14.2.3 Pengujian untuk Aplikasi dan Lingkungan Khusus
1. Pengujian GUI : dilakukan melalui sederetan check list untuk
menguji tampilan.
2. Pengujian Arsitektur Client – Server : berkaitan dengan sifat
pemrosesan terdistribusi, kinerja, kehadiran sejumlah platform
HW yang berbeda, kompleksitas komunikasi data dan jaringan,
kebutuhan akan layanan client multiple, dan persyaratan
koordinasi yang dibebankan pada server.
3. Pengujian Dokumentasi dan Help : didekati dalam 2 fase, yakni
FTR dan live test yang dikaitkan langsung pada penggunaan nyata.
4. Pengujian Sistem Real Time : berkaitan dengan penanganan
interupsi, timing data, proses paralel. Langkah2 yang dilakukan
meliputi Pengujian Task, Pengujian Perilaku, Pengujian antar-task,
dan Pengujian Sistem.
14.3 Strategi Pengujian dan V&V
1. Strategi Pengujian
mengintegrasikan metode desain test case PL ke dalam sederetan langkah yang bertujuan untuk menghasilkan perangkat lunak yang berhasil.
2. Verifikasi & Validasi
harus dilakukan pada tiap tahap pengembangan sistem,
dengan dokumentasi dari tahap sebelumnya.
Verifikasi are we building the product right : untuk memastikan bhw PL scr tepat mengimplementasikan suatu fungsi tertentu.
Validasi are we building the right product : untuk memastikan bhw PL dpt ditelusuri hingga ke persyaratan pelanggan. Validasi mrpk seri akhir pengujian yang melibatkan user (User Testing) baik yang berlangsung dlm lingkungan pengembang (Alpha Test) maupun di luar lingkungan pengembang (Beta Test). Teknik pengujian Black-Box digunakan scr eksklusif dalam validasi.
14.3.1 Proses Pengujian
Unit
Testing
Module
Testing
Sub-system
Testing
System
Testing
Acceptance
Testing
COMPONENT
TESTING
INTEGRATION
TESTING USER
TESTING
1. Component TestingPengujian terhadap komponen sistem, seringkali menggunakan teknik pengujian
White-Box.a. Unit Testing
• pengujian tahap awal• pengujian komponen secara terpisah• unit-unit terkecil diuji : function, procedure, subprogram, dll
b. Module Testing (modul memadukan beberapa komponen)• menguji interaksi antarunit• menguji perilaku modul
2. Integration TestingPengujian terhadap integrasi antarmodul scr Top-Down, Bottom-Up, dan
Pengujian Regresi (test case ulang pada suatu subset untuk memastikan tidak adanya perubahan akibat pengujian). Integration Test dilakukan baik dengan teknik pengujian Black-Box maupun sebagian White-Box.
a. Sub-system TestingPengujian terhadap antarmuka pada modul-modul yang sudah diintegrasikan
b. System Testing• Pengujian terhadap perilaku sistem• Apakah sistem sesuai dengan spesifikasi
3. User Testing
Pengujian oleh user, seringkali menggunakan teknik Black-Box.
a. Pengujian Tahap Akhir
b. Pengujian User (acceptance testing)
• diuji dengan data sebenarnya
• pengujian terhadap fasilitas yang tersedia
• menilai kinerja (performance)
14.3.2 Perencanaan Pengujian
Requirement
Specification
System
Specification
System
Design
Detailed
Design
Module &
Unit Code
and Test
Sub-system
Integration Test
System
Integration Test
Acceptance
TestUse
ACCEPTANCE
TEST PLAN
SYSTEM
INTEGRATION
TEST PLAN
SUB-SYSTEM
INTEGRATION
TEST PLAN
***
