MODUL REKAYASA PERANGKAT LUNAK STMIK DHARMAPALA RIAU
I. INTRODUCTION TO SOFTWARE ENGINEERING
1. What and Why Sofware
Engineering ?
1.1 Software Engineering (Rekayasa Perangkat Lunak) Ekonomi dari semua bangsa-bangsa maju tergantung pada perangkat lunak Semakin banyak sistem yang dikendalikan oleh perangkat lunak Rekayasa Perangkat Lunak mempunyai kaitan dengan teori, metode, dan perkakas (tools) untuk pengembangan perangkat lunak profesional Rekayasa Perangkat Lunak sudah menjadi bagian yang penting untuk menghadirkan pendapatan nasional pada semua negara maju
1.2 Software Costs (Biaya-Biaya Perangkat Lunak)
Biaya-biaya perangkat lunak sering mendominasi biaya-biaya sistem. Biaya-biaya perangkat lunak pada suatu PC sering lebih besar dari harga perangkat keras. Biaya-biaya perawatan perangkat lunak lebih besar dibanding dengan pengembangan perangkat lunak, karena sistem dengan masa pakai lama, biaya pemeliharaan mungkin beberapa kali biayabiaya pengembangan. Rekayasa Perangkat Lunak mempunyai kaitan dengan biaya-biaya pengembangan perangkat lunak yang ekonomis.
1.3 FAQs about Software Engineering (Pertanyaan-pertanyaan Seputar SE)
Apakah software itu?
Apakah software engineering itu?
Apa perbedaan antara software engineering dan computer science?
Apa perbedaan antara software engineering dan system engineering?
Apakah software process itu?
Apakah software process model itu?
FAQs about Software Engineering (Lanjutan)
Apa saja yang merupakan biaya-biaya rekayasa perangkat lunak itu?
Apa saja metode rekayasa perangkat lunak itu?
Apakah CASE (Computer-Aided Software Engineering) itu?
Apa saja atribut dari perangkat lunak yang baik?
Apakah yang merupakan tantangan kunci dalam menghadapi rekayasa perangkat lunak?
What is software? perintah (program komputer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan; struktur data yang memungkinkan program memanipulasi informasi secara proporsional; dan dokumen yang menggambarkan operasi dan kegunaan program. Produk Perangkat lunak mungkin :
Generic (Umum) - yang dikembangkan untuk dijual ke bidang pelanggan berbeda; Bespoke/Custom (Pesanan) - dikembangkan untuk pelanggan tunggal menurut spesifikasi mereka.
What is software engineering?
Software engineering adalah suatu disiplin rekayasa (rancang-bangun) yang terkait dengan semua aspek produksi perangkat lunak.
Engineer perangkat lunak mengadopsi pendekatan sistematis dan terorganisir untuk pekerjaan mereka dan menggunakan teknik dan tools yang disesuaikan dengan masalah yang dihadapi untuk dipecahkan, batasan pengembangan, dan sumber daya tersedia.
IEEE Definition (IEEE = Institute of Electrical and Electronic Engineers)
Software engineering adalah: 1.
Aplikasi dari sebuah pendekatan yang bersifat kuantifiabel, disiplin, dan sistematis bagi pengembangan, operasi, dan pemeliharaan perangkat lunak.
2.
Studi tentang pendekatan-pendekatan seperti pada (1)
Bidang Penelitian Software Engineering mengacu pada kedua hal tsb.
What is the difference between software engineering and computer science?
Computer science mempunyai kaitan dengan theory and fundamentals; software engineering mempunyai kaitan dengan practicalities of developing and delivering useful software.
Computer science sekarang ini tidak cukup lengkap untuk bertindak sebagai
tiang penyokong software engineering.
What is the difference between software engineering and system engineering?
System engineering mempunyai kaitan dengan semua aspek pengembangan sistem berbasis-komputer yang mencakup perangkat keras, perangkat lunak ,dan yang terkait dengan proses bisnis.
Software engineering berkonsentrasi pada komponen perangkat lunak sistem yang lebih besar.
System engineers mencakup spesifikasi sistem, desain arsitektur, pengintegrasian, dan penyebaran.
What is a software process?
Software process merupakan himpunan aktivitas tujuan pengembangan atau evolusi perangkat lunak. Aktivitas umum dalam semua proses perangkat lunak adalah:
Specification (Spesifikasi)- hal-hal yang diperlukan oleh sistem dan batasan pengembangannya. Development (Pengembangan)- produksi sistem perangkat lunak. Validation (Pengesahan) - pemeriksaan perangkat lunak sesuai dengan keinginan pelanggan. Evolution (Evolusi) - pengubahan perangkat lunak sesuai dengan permintaan pelanggan.
What is a software process model?
Software process model merupakan representasi sederhana suatu software process, yang diperkenalkan dari suatu perspektif spesifik. Contoh perspektif proses adalah
Workflow Perspektif - Urutan aktivitas Data-Flow Perspektif - Arus Informasi Role/Action Perspektif – Peran dan Aksi
Proses umum model
Waterfall Evolutionary development Formal transformation Integration from reusable components
What are the costs of software engineering?
Perkiraan kasar adalah 60% untuk biaya pengembangan, sedangkan 40% untuk biaya pengujian. Untuk custom sofware, biaya-biaya evolusi sering melebihi biaya-biaya pengembangan.
Biaya-biaya berubah-ubah tergantung pada jenis sistem yang dikembangkan dan kebutuhan atribut sistem seperti kehandalan dan reliabilitas sistem.
Distribusi biaya-biaya tergantung pada model pengembangan yang digunakan.
What are software engineering methods? Software engineering methods merupakan pendekatan terstruktur dalam pengembangan perangkat lunak yang meliputi model sistem, notasi, aturan, desain advice, dan panduan proses. Model Descriptions (Uraian Model) Uraian tentang model grafis yang harus diproduksi. Rules (Aturan-aturan) Batasan yang berlaku pada model sistem. Recommendations (Rekomendasi) Rekomendasi untuk praktik desain yang baik. Process guidance (Panduan Proses) Aktivitas yang mengikuti.
What is CASE (Computer-Aided Software Engineering)?
CASE adalah System software yang digunakan untuk mendukung otomatisasi aktivitas proses perangkat lunak. CASE sering digunakan untuk mendukung metode.
Upper-Case Tools untuk mendukung aktivitas proses awal kebutuhan dan desain.
Lower-Case
Tools untuk mendukung aktivitas selanjutnya seperti programming, debugging, dan testing.
What are the attributes of good software? Software perlu memiliki fungsi kebutuhan dan kemampuan yang diperlukan oleh pemakai dan harus maintainable, dependable , efficient, dan usable. Maintainability Software harus dapat ditingkatkan dan diubah sesuai dengan kebutuhan. Dependability Software harus dapat dipercaya (trustworthy). Efficiency Software seharusnya tidak membuat penggunaan sumber daya sistem menjadi boros. Usability Software harus dapat dipakai oleh para pemakai yang direncanakan.
What are the key challenges facing software engineering? Tantangan : mengatasi sistem warisan (legacy systems), meningkatnya heterogenitas (Heterogenity) sistem, dan tuntutan permintaan percepatan penyerahan(Delivery) sistem.
Legacy systems Sistem warisan (sistem lama) harus dirawat dan dibaharui.
Heterogenity Sistem terdistribusikan dalam bentuk campuran antara perangkat keras dan lunak.
Delivery
Adanya peningkatan tekanan untuk penyerahan perangkat 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 jujur jika mereka diharapkan untuk terhormat sebagai seorang profesional.
Perilaku etis tidak hanya sekedar menegakkan hukum saja tetapi harus lebih dari itu (lih. hal. berikutnya).
Issues of professional responsibility
Confidentiality (Kerahasiaan) Engineer seharusnya menghormati kerahasiaan dari klien mereka tanpa tergantung dengan ya atau tidaknya suatu persetujuan kerahasiaan formal ditandatangani.
Competence (Kemampuan) Engineer mestinya tidak salah menggambarkan tingkatan kemampuannya. Mereka mestinya tidak dengan sadar menerima pekerjaan yang di luar kemampuannya.
Issues of professional responsibility (lanjutan)
Intellectual property rights (Hak milik intelektual) Engineers harus sadar akan hukum lokal yang mengatur penggunaan dari properti intelektual seperti hak paten, hak cipta, dll. Mereka harus seksama untuk memastikan bahwa intelektual properti klien harus dilindungi. Computer misuse (Penyalahgunaan Komputer) Software engineers mestinya tidak menggunakan kecakapan teknis mereka untuk menyalahgunakan komputer orang lain. Penyalahgunaan komputer dari yang relatif sepele (misal untuk bermain game) sampai yang serius (pemberian virus). ***
2 The Software Product
2.1 The Evolving Role of Software
Peran Perangkat Lunak saat ini:
Berfungsi sebagai sebuah produk
mengantarkan potensi penghitungan yang dibangun oleh perangkat lunak komputer. Perangkat lunak sebagai transformer informasi yang memproduksi, mengatur, memperoleh, memodifikasi, menampilkan atau memancarkan informasi, sehingga pekerjaan menjadi semakin mudah
Berfungsi sebagai kendaraan yang mengantarkan sebuah produk
Dasar untuk kontrol komputer (sistem operasi), komunikasi informasi (jaringan) dan penciptaan serta kontrol dari program-program lain (piranti dan lingkungan perangkat lunak)
2.2 Evolution of Software 2st Era
1st Era • Batch orientation • Limited distribution • Custom software
1950
1960
• Multiuser • Real-time • Database • Product software
1970
3st Era • Distributed systems • Embedded ‘intelligence’ • Low cost hardware
1980
4st Era • Powerful desk-top systems • Object-oriented technologies • Expert systems • Artificial neural networks • Parallel computing • Network computers
1990
2000
2.3 Serangkaian masalah perangkat lunak sehubungan dengan evolusi sistem berbasis komputer
Kemajuan perangkat keras terus berlanjut melampaui kemampuan engineer dalam membangun perangkat lunak yang sesuai dengan perangkat keras yang ada. Kemampuan engineer untuk membangun program baru tidak dapat memenuhi kebutuhan akan program baru dan tidak dapat membangun program yang cukup cepat untuk memenuhi kebutuhan bisnis dan pasar. Pemakaian komputer yang tersebar luas membuat masyarakat semakin tergantung pada operasi perangkat lunak yang reliabel. Kerusakan ekonomi yang besar dan potensi penderitaan manusia dapat muncul bila terjadi kegagalan perangkat lunak. Kita masih berjuang untuk membangun perangkat lunak komputer dengan reliabilitas dan kualitas yang tinggi. Kemampuan kita untuk mendukung program yang ada terhambat oleh buruknya desain serta sumber daya yang tidak memadai.
2.4 Software Characteristics Perangkat lunak lebih merupakan elemen logika dan bukan merupakan elemen fisik, sehingga perangkat lunak memiliki ciri yang berbeda dari perangkat keras. Perangkat
lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang klasik (manufaktur).
Perangkat
lunak tidak pernah usang. Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat dirakit dari komponen yang sudah ada.
Failure Curve of Hardware
Tingkat kegagalan
kematian segera
Waktu
usang
Failure Curve for Software (idealized) Tingkat kegagalan pada tingkat yang sama sampai usang
Waktu
Actual Failure Curve for Software laju kegagalan meningkat sehubungan dengan efek sampingan
Tingkat kegagalan
perubahan kurva aktual
Waktu
kurva ideal
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 asumsiasumsi 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.
Untuk menghasilkan perangkat lunak yang berkualitas, maka kita perlu membeli komputer terbaru.
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 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. The Software Process
3.1 Software Engineering Layers
Tools Methods Process
Quality
3.2 A Generic View of Software Engineering
Engineering meliputi kegiatan analisis, desain, konstruksi, verifikasi, dan manajemen kesatuan teknik atau sosial. Pertanyaan-pertanyaan yang harus dimunculkan dan dijawab: Apa masalah yang akan dipecahkan? Karakteristik entitas yang manakah yang dipakai untuk menyelesaikan masalah tersebut? Bagaimanakah entitas (dan pemecahan) tersebut diadakan? Bagaimanakah entitas tersebut dibangun? Pendekatan apakah yang akan dipakai untuk menemukan kesalahan-kesalahan yang dibuat dalam desain dan kontruksi dari entitas tersebut? Bagaimanakah entitas tersebut ditopang selama proses adaptasi yang lama, pada saat koreksi, serta ketika perbaikan dibutuhkan 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)
Adaptation (Adaptasi)
modifikasi perangkat lunak karena perubahan kebutuhan fungsional original (CPU, OS, aturan bisnis, karakteristik produk eksternal, dll)
Enhancement (Perkembangan)
membetulkan cacat atau kerusakan
memperluas perangkat lunak sehingga melampaui kebutuhan fungsi originalnya
Prevention (Pencegahan)
pencegahan sebagai antisipasi perubahan karena usia perangkat lunak
3.5 Umbrella Activities
Software project tracking and control Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management
3.6 Software Development Stages
Requirements Analysis & Specification Conceptual/System Design Detailed/Program Design Implementation/Coding Unit & Integration Testing System Testing System Delivery Maintenance
3.7. The Software Process Common Process Framework Framework Activities Task Sets Tasks Milestones, deliveriables SQA points
Umbrella Activities
3.7.1 Five Process Maturity Levels (SEI=Software Engineering Institute)
Level 1: Initial Software process yang ditandai seperti ad hoc dan chaotic (kesemrawutan). Level 2: Repeatable Tracking / penelusuran masalah biaya, jadwal, dan fungsionalitas proyekproyek terdahulu. Level 3: Defined Pendokumentasian, standarisasi, dan pengintegrasian software proses pada perangkat lunak organisasi besar. Level 4: Managed Pengukuan detail dan kualitas produksi perangkat lunak. Level 5: Optimizing Penambahan proses melalui umpan balik kuantitatif, gagasan inovatif pengujian, dan teknologi.
3.8. Software Process Models
Linier Sequential Model Waterfall Model V Model RAD Model
Prototyping Model Evolutionary Model Incremental Model Spiral Model Component Assembly Model Concurrent Development Model
Formal Model Fourth Generation Techniques
3.8.1. Linier Sequential Model
System/Information Engineering Analysis
Design
Code
Test
3.8.1.1 Waterfall Model
Sebuah pendekatan pengembangan perangkat
lunak yang sistematik dan sekuensial.
Disebut juga ‘Classic Life Cycle’.
Paradigma yang sudah lama sekali, tetapi masih banyak yang memakai karena dianggap masih sesuai dengan keadaan sekarang.
Waterfall Model Diagram Requirements definition System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance
Modified Waterfall Model Sashimi
(M.Kochanski)
Waterfall with Spiral Introduction
Waterfall with Subprojects
3.8.1.2 V Model OPERATION & MAINTENANCE
Validate requirements
REQUIREMENTS ANALYSIS
ACCEPTANCE TESTING SYSTEM DESIGN
Verify design
PROGRAM DESIGN
SYSTEM TESTING
UNIT & INTEGRATION TESTING
CODING
3.8.1.3 RAD Model
RAD = Rapid Application Development
Adaptasi dari waterfall model yang:
menekankan siklus pengembangan perangkat lunak yang sangat pendek;
menggunakan pendekatan konstruksi berbasis komponen.
Menciptakan sistem fungsional yang utuh dalam waktu 60-90 hari.
RAD Model Diagram team #3 business modeling
team #2 data modeling
business modeling
process modeling
team #1 data modeling
business modeling
application generation
process modeling
data modeling
testing & turnover
application generation
process modeling
application generation
testing & turnover
testing & turnover 60 - 90 hari
RAD Model Phases
Business Modelling Memodelkan fungsi-fungsi bisnis untuk menjawab pertanyaanpertanyaan: 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 Requirements
Prototype Programming
Reviews
Validates?
Release
Throw-away prototyping System Programming
Prototype Requirements
System Testing
Prototype Programming
Reviews
Validates?
Reviews
Validates?
Release
Prototyping Speciality
Frekuensi komunikasi user – developer meningkat
Membantu analis dalam
evaluasi oleh user berkali-kali user bisa memberikan masukan setiap saat
Pengembangan lebih cepat
menentukan kebutuhan user yang sebenarnya meminimalkan salah persepsi
Peran user meningkat
pengembang akan selalu meminta pendapat user
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 sulit melakukan evaluasi
bentuk program sudah terlihat sejak awal. user merasa tidak akan lama lagi selesai. pengembang sering mengabaikan dokumentasi.
User berharap terlalu banyak
bentuk prototipe sering berubah, disesuaikan dengan kebutuhan user.
User ingin cepat selesai
user & pengembang harus sama-sama memiliki komitmen menyediakan waktu untuk bertemu.
keseringan evaluasi & komunikasi membuat user menjadi berubah keinginan dan tidak pasti dengan kebutuhan.
Prototipe bekerja tidak efisien
lebih mementingkan keberhasilan.
3.8.3 Evolutionary Model 3.8.3.1 Incremental Model Incremental Model merupakan gabungan antara model linier sekuensial dan prototyping. 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 system/information engineering analysis
increment 2
design
analysis
increment 3
code
design
analysis
increment 4
delivery of 1st increment
test
code
design
analysis
test
delivery of 2nd increment
code
design
test
code
delivery of 3rd increment
test
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 Integration and test plan
Risk Analysis
development plan
menentukan tujuan, alternatif, batasan sistem dan budget
analisa resiko berdasarkan evaluasi user analisa resiko berdasarkan kebutuhan awal
development plan Requirements
Customer Communication
prototipe awal
Engineering prototipe tingkat berikutnya
Project Entry Point
produk-jadi Customer Evaluation
Construction & Release
3.8.3.3 Component Assembly Model
identify candidate components
look up components in library
construct n- th iteration of system
extract components if available
put new components in library
build components if unavailable
Engineering, contruction & release
engineering
entry point
customer evaluation Customer communication
risk analysis planning
3.8.3.4 Concurrent Development Model none Analysis activity Under development A waiting changes
Under review Under revision
done
baselined
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 memverifikasi sistem berbasis komputer dengan menggunakan notasi matematis yang tepat;
Variasi dari pendekatan ini disebut clean-room software engineering.
Formal method akan dibahas pada bab tersendiri
3.8.5 Fourth Generation Techniques (4GT)
Terkait dengan penggunaan tools.
Pengembang software mendefinisikan karakteristik software secara 'high level'; tool secara otomatis akan membangkitkan kode.
4GT mempercepat proses pengembangan perangkat lunak.
Proses perancangan dan dokumentasi baik.
Masih dipertanyakan beberapa pihak: efisiensi kode yang dihasilkan, kemudahan (relatif).
4GT Techniques requirements gathering
design strategy
implementation using 4GL
testing
***
4. Konsep Manajemen Proyek 4.1 People Perangkat Lunak 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) 69
4.3.4 Contoh Dekomposisi (complex project)
Konsep Manajemen Proyek Perangkat Lunak Manajemen Proyek Perangkat Lunak merupakan suatu aktivitas pelindung (umbrella activity) untuk mengelola proyek perangkat lunak, yang difokuskan pada 3P: People (manusia); Problem (masalah) dan Process (proses)
70
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
4.1 People 4.1.1 Para Pemain (Stakeholder)
71
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.
4.1.2 Pemimpin Tim Pemimpin tim (team leaders): seseorang yang memimpin sebuah proyek perangkat lunak. Syarat : Model Kepemimpinan MOI (Weinberg):
Motivasi:
72
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.
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.
73
Struktur tim yang terbaik berdasarkan gaya manajemen, jumlah orang, tingkat keahlian, kompleksitas masalah.
4.1.4 Tiga Organisasi Tim (Mantei)
74
Democratic Decentralized (DD); tidak ada pimpinan yang tetap, keputusan diambil secara bersama-sama, hubungan horizontal.
Controlled Decentralized (CD); ada pimpinan untuk setiap 'task' dan subpimpinan untuk 'sub-task', terjadi komunikasi horizontal & vertikal.
Controlled Centralized (CC); ada team leader untuk top-level problem solving & koordinasi internal, koordinasi vertikal
4.1.5 Faktor-faktor dalam Perencanaan Struktur Tim RPL (Mantei)
75
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
4.1.6 Pengaruh Karakteristik Proyek pada Struktur Tim Team type: Difficulty high low Size large small Team lifetime short long Modularity high low Reliability high low Delivery date strict lax Sociability high low 76
DD
CD
CC
x
x
x
x
x
x
x
x
x
x
x
x x
x x x
x
x
x x
x
4.1.7 Masalah Koordinasi dan Komunikasi Ada banyak hal yang menyebabkan proyek perangkat lunak bermasalah, penyebabnya diantaranya adalah:
77
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.
4.1.8 Teknik Koordinasi Proyek (Kraul dan Streeter) Pendekatan impersonal, formal.
78
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.
4.2 Problem Manajer proyek perangkat lunak berhadapan dengan dilema awal proyek, yaitu menentukan perkiraan kuantitatif dan rencana organisasi tetapi informasi yang akurat belum tersedia. Requirement analysis yang lengkap dibutuhkan untuk melakukan estimasi, tetapi memerlukan waktu yang lama dan kadang-kadang kebutuhan berubah-ubah pada saat proyek berjalan. Solusi: definisikan scope (ruang lingkup) dengan benar dan segera.
79
4.2.1 Ruang Lingkup Masalah
dibatasi oleh: Context
80
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?
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:
81
Fungsionalitas yang harus dihasilkan
Proses yang akan dipakai untuk menghasilkan sesuatu
Manusia cenderung melakukan dekomposisi jika menghadapi masalah yang kompleks
4.3 Proses
82
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.
4.3.1 Menggabungkan Masalah dan Proses Tahap awal project planning dimulai dengan penggabungan problem dan process. Setiap fungsi yang akan direkayasa harus melampaui sejumlah aktivitas yang sudah ditentukan Misal organisasi mengadopsi kerangka aktivitas sbb:
83
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.
Software Engineering Tasks Product Functions Text input Editing & formatting Automatic copy edit Page layout capability Automatic indexing & TOC File management Document production
84
engineering
risk analysis
planning
customer communication
COMMON PROCESS FRAMEWORK ACTIVITIES
4.3.2 Dekomposisi Proses
Memilih paradigma rekayasa perangkat lunak yang paling baik sesuai dengan tingkat relativitas dari perangkat lunak. Bila
85
proyek relatif kecil dan mirip dengan proyek sebelumnya, maka dapat dipilih pendekatan linier sekuensial Bila masalah dapat dipecah-pecah dan batasan waktu yang ketat, maka dapat dipilih model RAD. Bila batas waktunya ketat, tetapi fungsionalitas tidak dapat optimal, maka dapat dipilih strategi pertambahan. dll Sekali model dipilih, kerangka kerja umum (CPF=common Process Framework) harus disesuaikan dengan model.
4.3.3 Contoh Dekomposisi (simple project)
86
Membuat daftar klarifikasi
Bertemu dengan customer untuk klarifikasi
Bersama-sama menentukan scope
Review scope
Penyempurnaan scope berdasarkan berbagai kendala
4.3.4 Contoh Dekomposisi (complex project) Mengkaji kebutuhan customer 87
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. ***
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
88
Proses Perangkat Lunak dan Metrik Proyek
Measure (mengukur); kuantitatif luasan, jumlah, dimensi, kapasitas, atau ukuran dari atribut sebuah proses atau produk. Measurement (pengukuran); kegiatan menentukan sebuah measure. Metrics (IEEE): ukuran kuantitatif dari tingkat di mana sebuah sistem, komponen, atau proses memiliki atribut tertentu Indikator adalah sebuah metrik atau kombinasi dari metrik yang memberikan pengetahuan ke dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk perangkat lunak. 89
5.1 Domain Metrik
Pengukuran perangkat lunak dilakukan pada proses dan proyek perangkat lunak. Indikator proses memungkinkan:
Indikator proyek, memungkinkan manajer proyek:
90
Software engineer memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung. Manajer dan pelaksana memperkirakan hal-hal yang harus dikerjakan dan yang tidak 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.
5.1.1 Tujuan Umum Pengukuran
91
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?
5.1.2 Determinan Kualitas dan Efektivitas Perangkat Lunak
People
92
Process
s es sin ns Bu ditio n Co
Ch Cus ara tom cte er ris tic s
Product
Development Environment
Technology
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:
93
Function Points
Feature Points
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 94
Rupiah
(Rp) per halaman dokumentasi
Contoh (size-oriented metrics)
95
Project
LOC
Effort
$(000) pp.doc. Errors Defects People
alpha
12,100
24
168
365
134
29
3
beta
27,200
62
440
1224
321
86
5
gamma
20,200
43
314
1050
256
64
6
..
..
..
..
..
..
..
..
Kontroversi Size-Oriented Metrics
96
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.
5.2.2 Function-Oriented Metrics
97
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)
5.2.2.1 Function Points Domain Informasi: Jumlah input dari user: jumlah user input yang dibutuhkan aplikasi Jumlah output untuk user: jumlah semua keluaran baik laporan maupun kesalahan (ke printer/layar) Jumlah input inquiry: masukan on-line yang mengakibatkan keluaran on-line Jumlah file Jumlah interface eksternal: semua interface yang dibaca oleh mesin untuk memindahkan informasi ke sistem lain. 98
5.2.2.2 Penghitungan Metrik Function Points Weighting Factor measurement parameter
count
simple averagecomplex
number of user inputs
x
3
4
6
=
number of user outputs
x
4
5
7
=
number of user inquiries
x
3
4
6
=
number of files
x
7
10
15
=
number of external interfaces
x
5
7
10
=
total
FP= total x [0.65 + 0.01 x Fi] Domain kompleksitas 99
Fi (i = 1 s/d 14) adalah ‘complexity adjustment values’ berdasarkan respon yang diperoleh dari pertanyaan-pertanyaan berikut ini.
Pertanyaan-Pertanyaan Untuk menghitung Fi, pertanyaan-pertanyaan di bawah ini dijawab dengan memberi nilai 5
antara 0 s/d
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
Apakah memerlukan pemasukan data secara ‘on-line’?
Apakah pemasukan data ‘on-line’ terjadi pada transaksi input thd layar atau operasi ganda?
Apakah file master di’update’ secara on-line?
Apakah input,output, file secara inquiry begitu kompleks?
Apakah proses internal begitu kompleks?
Apakah kode yang dibuat harus dapat digunakan ulang?
Apakah konversi dan instalasi termasuk dalam perancangan?
Apakah sistem dirancang untuk dapat diinstall pada berbagai organisasi yang berbeda?
Apakah aplikasi dirancang untuk memberikan fasilitas perubahan dan kemudahan pemakaian bagi user? 100
sudah ada yang sudah terpakai secara penuh?
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 Q = inquiry, 101
F = internal data structure
E = external file, R = transition.
O = output
T = transformation,
5.2.2.4 Penentuan Kompleksitas Transformasi Function Points Semantic Statements 1-5
6 - 10
11 +
1 - 10
low
low
average
11 - 20
low
average
high
21 +
average
high
high
Processing Steps
102
Perhitungan 3D function point index Complexity Weighting measurement element
average
high
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 103
low
5.3 Penyatuan Pendekatan Metrik yang Berbeda Banyaknya LOC yang dibutuhkan untuk membangun 1 FP
Programming Language
104
LOC/FP (average)
assembly language C
320 128
Cobol Fortran
105 105
Pascal Ada
90 70
object-oriented languages fourth generation languages (4GLs)
30 20
code generators spreadsheets
15 6
graphical languages (icons)
4
5.4 Kualitas Perangkat Lunak 5.4.1 Faktor yang Mempengaruhi Kualitas McCall dan Cavano mendefinisikan satu set quality factors yang merupakan tahap awal untuk mengembangkan metrik untuk pengukuran kualitas perangkat lunak:
product operation (using it),
product revision (changing it), dan
product transition (porting it).
(dibahas di Bab Matriks Teknis PL)
105
5.4.2 Faktor yang Mempengaruhi Kualitas (Gilb)
Correctness: perangkat lunak bekerja dengan baik & benar ( correctness = kesalahan / kloc )
106
Maintainability: mudah dirawat; mttc (mean time to change) kecil
Integrity: tahan gangguan; tingkat sekuriti yang baik
Usability: mudah digunakan
5.5 Penyatuan Metrik-metrik dalam Proses Perangkat Lunak software engineering process
software project
data collection
measures
data collection software product
data collection
107
***
metrics
indicators
6. Perenc. Proyek Perangkat Lunak (Software Project Planning) 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
108
6.5.2.2 COnstructive COst MOdel (COCOMO) 6.5.2.3 Persamaan Perangkat Lunak
Perenc. Proyek Perangkat Lunak
Project planning adalah serangkaian aktivitas-aktivitas kolektif dalam proses manajemen proyek perangkat lunak.
Estimation adalah aktivitas pertama dalam project planning
Estimation menjadi dasar bagi aktivitas perencanaan proyek yang lain.
Project planning menjadi peta jalan bagi kesuksesan rekayasa perangkat lunak
109
6.1 Observasi pada Estimasi
110
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
6.2 Tujuan Perencanaan Proyek
menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya, dan jadwal.
Tujuan project planning dapat tercapai melalui proses penemuan informasi yang menunjuk ke estimasi yang dapat dipertanggungjawabkan.
111
6.3. Ruang Lingkup Perangkat Lunak (Software Scope) Fungsi
(functions) Kinerja (perfomance) Batasan(constraints) Antarmuka (interface) Keandalan (reliability) 112
6.3.1. Rangkaian Pertanyaan SW Scope
Lingkup PL yang akan dibuat ditentukan melalui pertemuan-pertemuan antara customer dengan developer Untuk menjembatani jurang komunikasi antara customer dengan developer, Gause & Weinberg mengusulkan 3 rangkaian pertanyaan berikut:
113
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 pertanyaanpertanyaan yang memusatkan pada efektivitas dari pertemuan itu sendiri (disebut meta-questions).
6.3.1.1 Contoh Rangkaian Pertanyaan Pertama
114
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?
6.3.1.2 Contoh Rangkaian Pertanyaan Kedua
115
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?
6.3.1.3 Contoh Rangkaian Pertanyaan Ketiga
116
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?
6.3.2. Contoh Scoping 1 conveyor line motion ID No.
2 ID No.
ID No.
ID No.
3 4
bar code SORTING STATION
shunt control connection
5 6
117
6.3.2.1 Penjelasan Gambar
118
Conveyor Line Sorting System (CLSS) menyortir box-box yang bergerak pada ban berjalan. Setiap box diidentifikasi dengan bar code yang menyatakan nomor part. Box-box tersebut akan disortir ke dalam 6 wadah berdasarkan nomor part. Box-box tersebut melewati stasiun sortir yang berisi pembaca bar code dan sebuah PC (Personal Computer). PC di stasiun sortir dihubungkan dengan mekanisme langsiran (shunt) yang akan menyortir box-box tersebut ke dalam wadah-wadah yang sesuai. Box-box tersebut lewat dengan urutan yang acak dan berjarak sama. PL CLSS menerima informasi masukan dari pembaca bar code dengan interval waktu sesuai dengan kecepatan ban berjalan.
6.3.2.1 Penjelasan Gambar(lanj)
119
Data bar code tersebut akan didekodekan ke dalam format identifikasi box. PL akan melakukan look-up pada basis data part number yang berisi maksimum 1000 entry untuk menentukan lokasi wadah yang sesuai bagi box yang saat itu di stasiun sortir. Lokasi wadah yang sesuai diberikan pada sorting shunt yang akan menempatkan box tersebut pada wadah yang sesuai. Sebuah catatan (record) yang berisi wadah tujuan dari setiap box dibangkitkan untuk recovery nantinya dan pelaporan. PL CLSS juga menerima masukan dari sebuah tachometer pulsa yang akan dipakai untuk sinkronisasi sinyal kontrol ke 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.
6.3.2.2 Dekomposisi Pernyataan
120
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)
6.3.2.3 Kesimpulan Contoh Scoping
Kinerja sistem ini ditentukan oleh kecepatan ban berjalan. Pemrosesan setiap box harus selesai sebelum box berikutnya tiba di pembaca bar code.
Kendala-kendala yang membatasi PL CLSS adalah meliputi perangkat keras yang harus diakses (pembaca bar code, shunt, PC), memori yang tersedia, dan konfigurasi keseluruhan dari lini ban berjalan tersebut.
121
6.3.2.3 Kesimpulan Contoh Scoping (lanj)
Interface : PL yang dibuat berinteraksi dengan elemen-elemen lain dari sistem berbasis komputer ini. Konsep interface mempunyai arti; (1) hardware yang mengeksekusi PL dan perangkat lain yang secara tidak langsung dikontrol oleh PL tersebut. (2) software yang telah ada dan harus dilink dengan software yang baru (dibuat) tersebut. (3) orang yang menggunakan PL tersebut via keyboard atau I/O devices lainnya. (4) prosedur-prosedur yang mengawali atau mengakhiri (mengikuti) PL tersebut sebagai urutan operasi yang sekuensial.
122
6.4 Sumber Daya
People
Reusable Software Components
Hardware/Software Tools 123
6.4.1 Sumber Daya Manusia
Diperlukan keahlian untuk menyelesaikan pengembangan PL; baik dari segi posisi organisasional (misal: manager, senior software engineer, dsb) maupun spesialisasi (misal: telekomunikasi, basis data, dsb).
Sedangkan jumlah banyaknya personil yang dibutuhkan ditentukan setelah estimasi beban kerja (development effort).
124
6.4.2 Reusable Software Resources
125
Off-the-shelf components; memanfaatkan yang telah dibuat pada proyek internal sebelumnya. Full-experience components; mereview spesifikasi, kode, desain atau pengujian data dari proyek sebelumnya Partial-experience components; aplikasi, kode, desain atau data dari proyek sebelumnya dihubungkan dengan proyek sekarang New components; pembuatan komponen baru
6.4.3 Environmental Resources
126
Lingkungan yang mendukung proyek PL, disebut juga software engineering environment (SEE); meliputi
hardware
software
hardware & software khusus
6.5. Estimasi Proyek Perangkat Lunak (Software project estimation)
Ada 2 teknik dalam melakukan estimasi proyek perangkat lunak, yaitu:
Decomposition
Empirical
127
Techniques
Estimation Models
6.5.1. Teknik Dekomposisi (Decomposition techniques)
Dekomposisi masalah : memecah-mecah masalah yang kompleks menjadi serangkaian masalah yang lebih kecil.
Ketelitian estimasi proyek PL diprediksi pada sejumlah hal: (1) derajat ketepatan estimasi ukuran produk yang akan dibuat, (2) kemampuan menterjemahkan ukuran terestimasi tersebut ke dalam beban kerja, waktu kalender, dan rupiah,
(3) derajat rencana proyek yang mencerminkan kemampuan tim software, dan
128
(4) kestabilan persyaratan-persyaratan produk dan lingkungan yang mendukung upaya software engineering.
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 komponenkomponen standar yang ada. Change sizing; memodifikasi PL dengan banyak cara, menggunakan suatu rasio kerja setiap perubahan, sehingga ukuran perubahan dapat diperkirakan
129
6.5.1.2 Problem-based Estimation
Data LOC dan FP dipakai dalam dua hal selama estimasi proyek PL: (1) sebagai suatu estimation variable yang dipakai untuk “memberi ukuran” pada setiap elemen PL yang akan dibuat, dan (2) sebagai baseline metrics yang dikumpulkan dari proyek terdahulu dan dipakai bersama-sama dengan estimation variable untuk menghitung proyeksi biaya dan beban kerja.
130
6.5.1.2 Problem-based Estimation (lanj)
Tanpa memandang variabel estimasi yang dipakai, project planner mulai dengan mengestimasi rentang nilai untuk setiap fungsi atau nilai domain informasi.
Dengan menggunakan data historis atau intuisi, ditentukan ukuran nilai yang optimistik (sopt), rata-rata (sm), dan yang pesimistik (spess).
Kemudian dihitung nilai yang diharapkan (three-point atau expected value) sbb.
131
EV = (sopt + 4 sm + spess)/6
6.5.1.3 Contoh Estimasi Berbasis-LOC
132
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.
6.5.1.3 Contoh Estimasi Berbasis-LOC (lanj)
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) Function
134
Estimated LOC
user interface and control facilities (UICF)
2.300
two-dimensional geometric analysis (2DGA)
5.300
three-dimensional geometric analysis (3DGA)
6.800
database management (DBM)
3.350
computer graphics display facilities (CGDF)
4.950
peripheral control (PC)
2.100
design analysis modules (DAM)
8.400
estimated lines of code
33.200
6.5.1.4 Contoh Estimasi Berbasis FP Information Domain Value
opt.
likely
pess.
est. count
number of inputs
20
24
30
24
4
96
number of outputs
12
15
22
16
5
80
number of inquiries
16
22
28
22
4
88
number of files
4
4
5
4
10
40
number of external interfaces
2
2
3
2
7
14
count-total
135
weight
FP-count
318
6.5.1.4 Contoh Estimasi Berbasis FP(lanj) Factor
Value
Backup and recovery
4
Data communication Distributed processing
2 0
Performance critical Existing operation environment
4 3
On-line data entry Input transaction over multiple screens
4 5
Master files updated on-line Information domain values complex
3 5
internal processing complex Code designed for reuse
5 4
Conversion/installation in design Multiple installations
3 5
Application designed for change Complexity adjustment factor
5 1.17
FPestimated = count-total x [0,65 + 0,01 x F i ] 136
FPestimated = 372
6.5.1.5 Contoh Estimasi Berbasis Proses
137
Sederetan kegiatan proses software harus dikerjakan untuk masingmasing fungsi.
Fungsi-fungsi dan kegiatan-kegiatan proses PL yang terkait dapat dinyatakan dalam tabel berikut.
Software Engineering Tasks Product Functions Text input Editing & formatting Automatic copy edit Page layout capability Automatic indexing & TOC File management Document production
138
engineering
risk analysis
planning
customer communication
COMMON PROCESS FRAMEWORK ACTIVITIES
6.5.2 Empirical Estimation Models
Model estimasi untuk software komputer dengan menggunakan formula-formula yang diturunkan secara empirik untuk memprediksi beban kerja sebagai fungsi dari LOC atau FP.
Data empirik yang mendukung model-model estimasi tersebut diturunkan dari sample proyek yang terbatas.
Model-model estimasi mempunyai struktur sbb.
E = A + B ´ (ev)C dengan A, B, dan C adalah konstanta yang diturunkan secara empirik E adalah effort dalam orang bulan ev adalah variabel estimasi (dalam LOC atau FP) 139
6.5.2.1 Beberapa Model Estimasi LOC-Oriented E = 5,2 ´ (KLOC )0,91
Walston-Felix model
E = 5,5 + 0,73´ (KLOC )1,16
Bailey-Basili model
E = 3,2 ´ (KLOC )1,05
Boehm simple model
E = 5,288´ (KLOC )1,047
Doty model untuk KLOC > 9
FP-Oriented E = - 13,39 + 0,0545 ´ ( FP ) Albrecht and Gaffney model
140
E = 60,62´ 7,728´ 10-8(FP)3
Kemerer model
E = 585,7 + 15.12´ ( FP )
Matson, Barnett, and Mellichamp model
6.5.2.2 COnstructive COst MOdel (COCOMO) Model mempunyai bentuk hirarki (berdasarkan Boehm) sbb:
Model 1. Basic COCOMO Model Menghitung development effort (dan cost) sebagai fungsi dari ukuran program yang dinyatakan dalam estimasi LOC.
E = abKLOCbb D = cbEdb
141
dengan E adalah effort (usaha) dalam orang-bulan dan D adalah waktu pengembangan dalam bulan kronologis.
BASIC COCOMO MODEL Software Project
ab
bb
cb
db
organic semi-detached embedded
2,4 3,0 3,6
1,05 1,12 1,20
2,5 2,5 2,5
0,38 0,35 0,32
Dengan mengambil nilai pada contoh CAD, maka biaya perperson: 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 • Organic – proyek perangkat lunak yang sederhana dan relatif kecil person • Semi-detached – proyek perangkat lunak menengah 142
• Embedded – proyek perangkat lunak yang kompleks seperti PL penerbangan
Model 2. Intermediate COCOMO Model
Menghitung usaha pengembangan PL sebagai fungsi ukuran program dan serangkaian pengendali biaya yang menyangkut penilaian yang subyektif terhadap produk, hardware, personil, dan atribut proyek. E = aiKLOCbi x EAF
143
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 (lanj)
Software Project
ai
bi
organic semi-detached embedded
3,2 3,0 2,8
1,05 1,12 1,20
• Organic – proyek perangkat lunak yang sederhana dan relatif kecil • Semi-detached – proyek perangkat lunak menengah • Embedded – proyek perangkat lunak yang kompleks seperti PL penerbangan 144
Model 3. Advanced COCOMO Model Menghubungkan semua karakteristik model intermediate dengan penilaian terhadap pengaruh
pengendali biaya pada setiap langkah (analisis, perancangan, pemrograman, dll) dari proses rekayasa
perangkat lunak.
145
6.5.2.3 Persamaan Perangkat Lunak Persamaa PL : model multivariasi yang mengasumsikan distribusi khusus effort sepanjang hidup proyek pengembangan perangkat lunak. Dihasilkan (estimasi) dari data produktivitas 4000 proyek perangkat lunak yang sejaman. Didefinisikan sbb:
E = [LOC x B0,333/P]3 x (1/t4)
146
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
***
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 147
Definisi Konseptual Risiko (Robert Charette) • Risiko berkaitan dengan kejadian yang akan datang. • Risiko melibatkan perubahan, seperti perubahan dalam pemikiran, opini, tindakan, atau tempat. • Risiko melibatkan pilihan dan ketidakpastian dalam pilihan itu sendiri. 148
Dalam konteks rekayasa perangkat lunak : • risiko apa saja yang dapat menyebabkan proyek PL serba salah? • Bagaimana perubahan-perubahan dalam persyaratan-
persyaratan pelanggan, teknologi pengembangan, komputer target, dan entitas lain yang berkaitan dengan keberhasilan proyek secara keseluruhan? • Metode-metode dan tool-tool apa yang harus dipakai, berapa orang yang harus dilibatkan, seberapa jauh penekanan terhadap kualitas yang dipandang cukup 149
memadai?
7.1 Strategi Risiko: Reaktif vs Proaktif • Strategi reaktif : tim PL tidak melakukan sesuatu sampai sesuatu yang tidak diinginkan terjadi. Kemudian tim akan bertindak untuk mengatasi masalah tersebut secepatnya. Cara ini kadang-kadang disebut “fire fighting mode”. • Strategi proaktif : kegiatan menanggulangi risiko sudah diawali jauh sebelum kerja teknis dimulai. Dalam hal ini, risiko-risiko yang potensial diidentifikasi, probabilitas dan pengaruh proyek diperkirakan, dan dibuat prioritas berdasarkan tingkat pentingnya. Kemudian tim membuat rencana untuk mengelola risiko-risiko tersebut. 150
7.2. Karakteristik Risiko
Ketidakpastian - kejadian yang mencirikan suatu risiko dapat terjadi atau tidak, yaitu tidak ada risiko kemungkinan 100%. Kerugian - jika risiko menjadi kenyataan, akibat yang tidak diinginkan atau kerugian akan diperoleh.
151
Dalam menganalisis risiko, adalah sangat penting untuk mengkuantifikasi tingkat ketidakpastian dan tingkat kerugian yang ditimbulkan oleh masing-masing risiko. Untuk itu perlu dipertimbangkan berbagai kategori risiko. 7.2.1 Kategori Risiko 7.2.2 Kategori Risiko Menurut R. Charette 152
7.2.1 Kategori Risiko
risiko proyek : potensi muncul dari pembiayaan, jadwal, personal, sumber daya, pelanggan, persyaratan, kompleksitas, ukuran, dan ketidakpastian struktural. risiko teknis : yang disebabkan oleh ambiguitas, spesifikasi, ketidakpastian teknik, keusangan teknik, dan teknologi yang leading edge. risiko bisnis : risiko pasar, risiko strategi, pemasaran, risiko manajemen, dan risiko biaya. 153
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.
154
• Unpredictable risks : risiko-risiko yang sangat sulit diketahui sebelumnya.
Ada 2 tipe risiko untuk masing-masing kategori di atas. • Generic risks : risiko yang mengancam setiap proyek PL.
• Product specific risks : risiko-risiko yang hanya dapat diidentifikasi dengan pemahaman yang jelas pada teknologi, SDM, dan lingkungan yang spesifik bagi proyek tersebut. Untuk mengidentifikasi risiko tipe ini, rencana proyek & pernyataan tentang lingkup PL yang akan dibuat diperiksa. 155
7.3. Identifikasi Risiko Identifikasi risiko adalah upaya sistematis untuk menentukan ancaman-ancaman pada rencana proyek (estimasi, jadwal, pembebanan sumber-sumber, dsb.). Salah satu metoda untuk mengidentifikasi risiko adalah dengan membuat sebuah risk item checklist. Dari checklist tersebut dapat dilakukan pembandingan dengan pengalaman proyek sebelumnya. Bila deviasinya sama atau lebih besar, atau banyaknya jawaban negatif, maka risiko proyek tersebut dapat dikatakan tinggi.
Checklist tersebut dapat dipakai untuk mengidentifikasikan dan memusatkan perhatian pada suatu subset dari known & predictable risks dalam subkategori umum berikut. 7.3.1 Item Identifikasi Risiko 156
7.3.2. Komponen-komponen & Penggerak Risiko
7.3.1 Item Identifikasi Risiko Ukuran produk : risiko yang timbul sehubungan dengan ukuran perangkat lunak yang direkayasa. Dampak bisnis : berkaitan dengan batasan yang dibebankan oleh manajemen atau pasar. Karakteristik pelanggan : berhubungan dengan kecerdikan pelanggan dan kemampuan perekayasa untuk berkomunikasi dengan pelanggan. Definisi proses : risiko yang berkaitan dengan masalah-masalah proses dan teknis rekayasa. Lingkungan pengembangan : berhubungan dengan ketersediaan dan kualitas tools yang digunakan dalam rekayasa. Teknologi yang akan dibangun : risiko sehubungan dengan kompleksitas sistem dan ‘kebaruan’ teknologi. 157
Jumlah dan pengalaman staf : risiko sehubungan dengan keseluruhan teknik dan pengalaman perekayasa.
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 persyaratanpersyaratannya dan sesuai untuk pemakaian yang diperuntukkannya. • Support risk Derajat ketidakpastian bahwa PL akan mudah dikoreksi, diadaptasi, dan ditingkatkan. • Cost risk Derajat ketidakpastian bahwa anggaran proyek akan terjaga (tetap).
158
• Schedule risk Derajat ketidakpastian bahwa jadwal proyek tidak akan berubah dan bahwa produk akan diserahkan tepat waktu.
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).
159
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).
COMPONENTS PERFORMANCE CATEGORY
1 CATASTROPHIC
2 1 CRITICAL
2 1 MARGINAL
2 1 NEGLIGIBLE
2
160
SUPPORT
COST
SCHEDULE
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 161
7.4.3 Penilaian Risiko
7.4.1 Kegiatan Proyeksi Risiko • Menetapkan suatu skala yang mencerminkan kemungkinan yang dibayangkan pada suatu risiko, • Melukiskan akibat-akibat dari risiko tsb. • Mengestimasi dampak risiko pada proyek dan produk, dan
• Mencatat akurasi keseluruhan dari proyeksi risiko tsb sehingga tidak akan terjadi salah pengertian. 162
Untuk memudahkan digunakan tabel berikut.
7.4.2 Pembuatan Tabel Risiko Teknik sederhana untuk proyeksi risiko adalah dengan Tabel Risiko (lihat tabel). Setelah semua risiko yang mungkin (terpikirkan) serta probabilitas kemunculannya dan tingkat dampaknya, tertuliskan semua, tahap selanjutnya adalah mengurutkan berdasarkan resultan probabilitas dan dampak (merupakan kegiatan penentuan prioritas). Tahap selanjutnya adalah menentukan cut-off line. 163
Risks
Category Probability
Size estimate may be significantly low
PS
60%
2
Larger number of users than planned
PS
30%
3
Less reuse than planned
PS
70%
2
End users resist system
BU
40%
3
Delivery deadline will be tightened
BU
50%
2
Funding will be lost
CU
40%
1
Customer will change requirements
PS
80%
2
Technology will not meet expectations
TE
30%
1
Lack of training on tools
DE
80%
3
Staff inexperienced
ST
30%
2
Staff turnover will be high
ST
60%
2
... ...
164
Impact
PS : Product Size
BU : Business Risk
CU : Customer Risk
TE : Technology Risk
DE : Development Risk
ST : Staff Risk
RMMM
Cut-off
Risiko-risiko di atas garis cut-off harus ditangani dengan seksama. Risiko-risiko di bawah garis cut-off dievaluasi kembali untuk menentukan prioritas tahap kedua.
Penggerak-penggerak risiko (bukan dampaknya) dapat dinilai berdasarkan skala probabilitas kualitatif dengan nilai-nilai: impossible, improbable, probable, dan frequent.
165
Pengaruh Probabilitas dan Dampak Risiko thd Perhatian Manajemen
impact
very high
low
Faktor risiko dengan pengaruh tinggi tetapi probabilitas rendah, tidak boleh menyerap sebagian besar perhatian manajemen.
high management concern
very low 0
1.0 166
probability of occurrence
7.4.3 Penilaian Risiko
Tingkat referen resiko adalah tingkat degradasi kinerja, pembengkakan biaya, kesulitan dukungan, dan melesetnya jadual atau kombinasinya yang menyebabkan proyek diterminasi.
167
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
Proyeksi melesetnya jadwal
Titik referen (nilai biaya,nilai waktu)
168
Proyeksi membengkaknya jadwal
7.5. Pengurangan (Mitigation), Monitoring, dan Manajemen Risiko (RMMM)
Semua kegiatan analisis risiko mempunyai satu tujuan tunggal : membantu tim proyek dalam pengembangan suatu strategi untuk menghadapi risiko. Strategi yang efektif harus mempertimbangkan 3 isu berikut:
• menghindari risiko (risk avoidance), • monitoring risiko (risk monitoring), • manajemen risiko dan perencanaan kemungkinan (risk management & contingency planning). 169
7.5.1 Menghindari Risiko (risk avoidance) Bila tim PL mengadopsi cara proaktif, maka penghindaran risiko selalu merupakan strategi yang terbaik. Hal ini dicapai dengan mengembangkan rencana untuk mengurangi/menghindari risiko (risk mitigation). Misal : pergantian staf (turnover) yang tinggi merupakan salah satu risiko proyek (ri), yang digambarkan dalam bentuk triplet sbb : [ri, li, xi]
170
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.
Untuk mengurangi risiko ini, manajemen proyek harus mengembangkan suatu strategi untuk mengurangi turnover. Langkah-langkah yang mungkin diambil adalah sbb. 1. Adakan pertemuan dengan staf untuk menentukan sebab-sebab turnover (misal kondisi kerja yang jelek, gaji rendah, pasar tenaga kerja yang kompetitif). 2. Ambil tindakan untuk mengurangi sebab-sebab tersebut sebelum proyek mulai.
171
3. Begitu proyek mulai, misalkan turnover akan terjadi, maka kembangkan teknik-teknik untuk menjamin kontinuitas bila seseorang meninggalkan pekerjaannya.
4. Organisir tim proyek sehingga informasi mengenai setiap kegiatan pengembangan tersebar luas. 5. Tentukan standar dokumentasi dan tetapkan mekanisme untuk memastikan bahwa dokumendokumen tersebut dibuat dengan tepat. 6. Laksanakan kajian antarteman terhadap semua pekerjaan tersebut sehingga lebih dari satu orang yang terbiasa dengan pekerjaan itu. 7. Tentukan backup anggota staf pada setiap teknologi kritis. 172
7.5.2 Monitoring Risiko (risk monitoring) Sebagaimana proyek bergerak maju, kegiatan risk monitoring mulai.
Manajer proyek memantau faktor-faktor yang dapat memberikan indikasi apakah risiko kemungkinan menjadi nyata atau kurang nyata? Dalam contoh staff turnover, faktor-faktor berikut harus dipantau. • Perilaku umum dari anggota tim berdasarkan pada tekanantekanan proyek. • Derajat kesatuan tim (kekompakan). • Hubungan interpersonal di antara anggota tim. • Masalah-masalah potensial yang berkaitan dengan kompensasi dan keuntungan.
173
• Ketersediaan (availability) pekerjaan-pekerjaan di dalam perusahaan tersebut dan di luar.
7.5.3 Manajemen Risiko dan Perencanaan Kemungkinan
Risk management & contingency planning mengasumsikan bahwa upaya pengurangan (mitigation) telah gagal dan risiko telah menjadi kenyataan.
Saat proyek sudah benar-benar berjalan dan jika strategi mitigasi juga dijalankan, maka backup telah tersedia (ada), informasi terdokumentasi, dan pengetahuan telah disebarkan pada tim.
174
Selain itu, manajer proyek dapat secara temporer melakukan pemusatan kembali sumber-sumber (dan menyesuaikan kembali jadwal proyek).
7.6 Safety Risks & Hazards (keselamatan & bahaya)
Risiko tidak hanya terbatas pada proyek PL itu sendiri. Risiko dapat muncul setelah PL sukses dibuat dan diserahkan kepada pelanggan.
Risiko-risiko ini secara tipikal berkaitan dengan akibatakibat dari kegagalan PL di lapangan. Walaupun probabilitas kegagalan pada sistem yang direkayasa dengan baik adalah kecil, suatu fault yang tidak terdeteksi pada sistem kontrol atau monitoring yang berbasis komputer dapat menyebabkan kerugian yang besar. 175
Software safety & hazard analysis adalah kegiatan software quality assurance yang memusatkan perhatian pada identifikasi dan penilaian hazardhazard yang potensial yang dapat memberi dampak negatif pada PL dan menyebabkan seluruh sistem gagal. ***
176
8. PROJECT SCHEDULING & TRACKING 8.1 Konsep Dasar 8.1.1 Penyebab Keterlambatan Proyek PL 8.1.2 Prinsip-prinsip Dasar 8.2 Hubungan Manusia dan Kerja 8.2.1 Contoh 8.2.2 Distribusi Effort 8.3 Penentuan Rangkaian Tugas Proyek PL 8.3.1 Rangkaian Tugas (Task Set) 8.3.2 Beberapa Tipe Proyek 8.3.3 Tingkat Kesulitan 8.3.4 Penentuan Kriteria Adaptasi 8.3.5 Penghitungan Nilai Task Set Selector 8.3.6 Contoh Perhitungan TSS 8.3.7 Contoh Perhitungan TSS utk Proyek Pengembangan Aplikasi Baru 8.3.8 Memilih Task-task Rekayasa PL 8.3.9 Contoh task-task utama rekayasa perangkat lunak 8.4 Rincian Task-task Utama 8.5 Penentuan Task Network 8.6 Penjadwalan 8.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 dipertimbangkan ketika 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 sendirisendiri 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 dengan sekumpulan task yang memungkinkan tim PL menentukan, mengembangkan, dan pada akhirnya memelihara PL komputer.
Tidak ada satu set tunggal yang cocok untuk semua proyek. Oleh karena itu proses PL yang efektif harus menentukan sekumpulan task set, masing-masing dirancang untuk memenuhi kebutuhan-kebutuhan tipe proyek yang berbeda.
Task set adalah sekumpulan task-task pekerjaan rekayasa PL, milestones, dan deliverables yang harus dipenuhi untuk menyelesaikan proyek. Task set yang dipilih harus memberikan disiplin yang cukup untuk mencapai kualitas PL yang tinggi, tetapi harus tidak membebani tim proyek dengan kerja yang tidak perlu. Task set dirancang untuk mengakomodasi berbagai tipe proyek dan tingkat kesulitan (degree of rigor) yang berbeda.
8.3.2 Beberapa Tipe Proyek
• Proyek-proyek pengembangan konsep. • Proyek-proyek pengembangan aplikasi baru.
• Proyek-proyek peningkatan kemampuan aplikasi yang sudah ada. • Proyek-proyek perawatan aplikasi. • Proyek-proyek reengineering.
8.3.3 Tingkat Kesulitan Degree of rigor (tingkat kesulitan) adalah suatu fungsi dari berbagai karakteristik proyek. Terdapat 4 degree of rigor. o casual, o structured, o strict, o quick reaction. Manajer proyek harus mengembangkan suatu cara yang sistematis untuk pemilihan degree of rigor yang sesuai untuk suatu proyek. Untuk memenuhi hal tersebut, kriteria adaptasi proyek didefinisikan dan nilai task set selector dihitung, sbb.
8.3.4 Penentuan Kriteria Adaptasi Kriteria adaptasi dipakai untuk menentukan degree of rigor bagi proses PL yang akan dipakai pada proyek. Sebelas kriteria adaptasi (grade 1-5) untuk proyek PL: • ukuran proyek, • jumlah user, • kekritisan misi yang diemban, • umur (lamanya) aplikasi tersebut akan dipakai, • kestabilan dalam persyaratan, • kemudahan komunikasi customer/developer, • kemapanan (maturity) teknologi yang dipakai, • kendala-kendala pada kinerja, • karakteristik embedded/nonembedded, • project staffing, dan • reengineering factors.
Masing-masing kriteria adaptasi diberi grade antara 1 s/d 5. Grade1 merepresentasikan suatu proyek yang membutuhkan subset yang kecil pada task-task proses dan persyaratan-persyaratan
metodologi dan dokumentasi adalah minimal. Grade 5 merepresentasikan suatu proyek yang
memiliki satu set task-task proses lengkap yang harus dipergunakan, seluruh persyaratanpersyaratan 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
Grade
Weight Conc.
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
_______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______
1.20 1.10 1.10 0.90 1.20 0.90 0.90 0.80 1.20 1.00 1.10 1.20
0 0 0 0 0 1 1 0 1 1 0 0
Entry Point Multiplier NDev. Enhan. Maint. 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
Product Reeng. 1 1 1 0 1 1 1 1 1 1 1 1
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
8.3.7 Contoh Perhitungan TSS untuk Proyek Pengembangan Aplikasi Baru Adaptation Criteria
Grade Weight Conc.
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
Task set selector (TSS)
2 3 4 3 2 2 2 3 3 2 4 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
_______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______
Entry Point Multiplier NDev. Enhan. Maint. 1 1 1 1 1 1 1 1 1 1 1 0
_______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______
_______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______
Product Reeng. _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______
2.4 3.3 4.4 2.7 2.4 1.8 1.8 2.4 3.6 2.0 4.4 0.0 2.8
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 Definition
Planning
Engineering/ Construction
Customer Evaluation
Release
Concept development 1.1 Concept scoping
1.4 Proof of concept
1.2 Preliminary concept planning 1.3 Technology risk assessment
New Application Development Projects Application Enhancement Projects Application Maintenance Reengineering
1.6 Customer reaction 1.5 Concept implementation
Preliminary concept planning Technology risk assessment Planning
Project Definition
Engineering/ Construction
Concept scoping
Proof of concept
Customer reaction Release Customer Evaluation
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.
Contoh Task Network I.3a Tech. Risk Assessment
I.1 Concept scoping
I.2 Concept planning
I.3b Tech. Risk Assessment
I.3c Tech. Risk Assessment
I.5a Concept Implement
I.4 Proof of Concept
I.5b Concept Implement
I.5c Concept Implement
Integrate a, b, c
I.6 Customer Reaction
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 1.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement defined
week 1
week 2
week 3
week 4
week 5
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 Content I.
II.
III.
IV. V. VI. VII.
VIII.
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 Estimasi Proyek A. Data Historis yang Digunakan untuk Estimasi B. Teknik-teknik Estimasi C. Estimasi Usaha, Biaya, Durasi Strategi Manajemen Risiko A. Tabel Risiko B. Pembahasan Risiko untuk Dikelola C. Rencana RMMM untuk setiap Risiko Jadwal Sumber Daya Proyek Staf Organisasi Pelacakan dan Mekanisme Kontrol 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 Review 9.7.1 Review Meeting 9.7.2 Laporan Review 9.7.3 Pedoman Review 9.8 Reliabilitas Perangkat Lunak 9.8.1 Reliabilitas (kehandalan) 9.8.2 Pengukuran Reliabilitas & Availabilitas 9.9 Software Safety & Hazard Analysis 9.10 Rencana SQA
9.1 Ruang Lingkup Tujuan utama dari rekayasa perangkat lunak adalah menghasilkan perangkat lunak yang berkualitas tinggi Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak, yang meliputi:
pendekatan manajemen kualitas
teknologi rekayasa perangkat lunak yang efektif (metode)
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 pengembangan perangkat lunak
mekanisme pengukuran dan pelaporan
9.2 Konsep Kualitas 9.2.1 Kualitas
1.
2.
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. 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. 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
Aktivitas oleh kelompok SQA:
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
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 memurnikan produk kerja perangkat lunak yang terjadi sebagai suatu hasil dari analisis, desain, dan coding. FTR (Formal Technical Review) atau disebut walkthrough adalah filter yang paling efektif untuk meningkatkan kualitas PL.
9.5 Dampak Defects Software thd. Biaya
Dalam kontek proses PL, istilah defect dan fault adalah sinonim. Keduanya menyatakan secara tidak langsung suatu problem kualitas yang ditemukan setelah PL dirilis kepada end users. Sasaran utama dari FTR adalah menemukan errors selagi proses PL berjalan sehingga tidak menjadi defect setelah PL dirilis. Keuntungan sesungguhnya dari FTR adalah menemukan error sedini mungkin sehingga error tsb tidak menjalar ke langkah berikutnya dalam proses PL. Sejumlah studi menunjukkan bahwa kegiatan desain mengintrodusir error antara 50% dan 65% dari seluruh error (dan pada akhirnya, seluruh defect) selama proses PL. FTR telah menunjukkan bahwa sampai 75% efektif dalam menemukan cacat-cacat desain. Dengan mendeteksi dan menghapus sejumlah besar persentase error, proses review secara subtansial mengurangi biaya pada langkahlangkah 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 problemproblem 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 ciriciri 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 SQA yang dibangun untuk setiap proyek perangkat lunak. Rencana SQA dicatat dalam dokumen produk kerja yang mencakup: dokumen proyek (rencana proyek); model (ERD); dokumen teknis (spesifikasi, rencana pengujian); dokumen pemakai (file-file help).
***
10. SOFTWARE CONFIGURATION MANAGEMENT 10.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. Pendahuluan 10.1.1 Perubahan
Perubahan adalah hal yang tidak dapat dihindarkan ketika perangkat lunak komputer sedang dibuat.
Perubahan2 tersebut meningkatkan tingkat kebingungan di antara para software engineer yang berkerja pada proyek tersebut.
Kebingungan muncul bila perubahan2 tersebut tidak dianalisis sebelum perubahan tersebut dilaksanakan; dicatat sebelum diimplementasi, dilaporkan kepada yang ingin mengetahui, atau dikontrol dengan suatu cara yang akan meningkatkan kualitas & mengurangi error.
Software configuration management (SCM) adalah kegiatan payung (umbrella activities) yang dilaksanakan selama proses perangkat lunak.
10.1.2 Tujuan SCM Karena perubahan dapat terjadi kapan saja, maka kegiatan SCM dibuat untuk; 1) mengidentifikasi perubahan, 2) mengontrol perubahan, 3) mengimplementasikan perubahan dengan benar, dan 4) melaporkan perubahan kepada pihak-pihak yang mempunyai kepentingan.
10.1.3 Software Maintenance vs Software Configuration Management Penting untuk dibedakan dengan jelas antara software maintenance dan software configuration management. Software Maintenance adalah serangkaian aktivitas rekayasa perangkat lunak yang terjadi setelah perangkat lunak diserahkan ke pelanggan dan telah dioperasikan. Software configuration management adalah serangkaian kegiatan tracking & control yang dimulai ketika suatu proyek perangkat lunak dimulai dan berakhir ketika perangkat lunak sudah tidak beroperasi lagi.
10.1.4 Informasi dan Perubahan Keluaran dari proses perangkat lunak adalah informasi yang dapat dibagi ke dalam 3 kategori utama; 1) program komputer (baik dalam bentuk source code maupun executable),
2) dokumen2 yang menjelaskan program komputer tersebut (yang ditargetkan baik untuk technical practitioners maupun users), dan 3) data (yang diisikan dalam program atau dikeluarkan dari program). Item2 yang terdiri dari semua informasi yang dihasilkan sebagai bagian dari proses perangkat lunak secara kolektif disebut Software Configuration Items (SCI).
Selama proses - rekayasa SCI berkembang dengan pesat. System specification menghasilkan sebuah software project plan dan software requirements specification (juga dokumen2 yang terkait dengan hardware), yang secara berurutan akan menghasilkan dokumen2 untuk menciptakan suatu hirarki informasi.
Perubahan masuk ke dalam proses rekayasa. Perubahan dapat terjadi kapan saja, untuk suatu alasan. Ini sesuai dengan Hukum 1 system engineering [BER80] yang menyatakan: “Tidak masalah dimana anda berada dalam siklus kehidupan sistem, sistem akan berubah, dan keinginan untuk mengubahnya akan selalu ada selama siklus hidup tersebut”.
10.2. Software Configuration Management 10.2.1 Sumber Dasar Perubahan Terdapat 4 sumber dasar perubahan. Bisnis baru atau kondisi pasar yang mendiktekan perubahan2 dalam produk atau aturan2 bisnis. Keinginan pelanggan baru yang meminta modifikasi data yang dihasilkan oleh sistem informasi; fungsionalitas yang diberikan oleh produk, atau layanan yang diberikan oleh suatu sistem berbasis komputer. Reorganisasi dan/atau perampingan bisnis yang menyebabkan perubahan prioritas proyek atau struktur tim rekayasa perangkat lunak. Kendala2 anggaran atau jadwal yang menyebabkan redefinisi sistem atau produk. SCM adalah sekumpulan kegiatan yang telah dikembangkan untuk menangani perubahan2 selama siklus hidup dari perangkat lunak komputer. SCM dapat dipandang sebagai kegiatan SQA yang dipakai selama proses perangkat lunak.
10.2.2 Baseline Perubahan adalah kenyataan hidup dalam pengembangan perangkat lunak. Pelanggan ingin memodifikasi persyaratan2. Pengembang ingin memodifikasi metode2 teknis. Manager ingin memodifikasi cara pendekatan proyek. Baseline adalah sebuah konsep SCM yang membantu dalam kontrol perubahan2 tanpa secara serius menghalangi perubahan2 yang dapat dijustifikasi. IEEE mendifinisikan baseline sebagai: Suatu spesifikasi atau produk yang telah direview secara formal dan disetujui bersama, yang selanjutnya berfungsi sebagai dasar bagi pengembangan lebih lanjut, serta dapat diubah hanya melalui prosedur2 kontrol perubahan formal. Dalam konteks rekayasa perangkat lunak, baseline adalah milestone dalam rekayasa perangkat lunak yang ditandai dengan penyampaian (delivery) SCI dan persetujuan (approval) SCI tersebut yang diperoleh lewat suatu FTR.
Baseline system engineering System Specification
requirements analysis Software Requirements Specification
software design Design Specification
coding Source Code
testing Test Plans/Procedures/Data
release Operational System
10.2.3 SCI Baseline dan Database Proyek modified Project database
SCIs
approved Software engineering tasks
SCIs
Formal technical reviews
SCIs stored
SCIs extracted SCM controls Jalur modifikasi
SCIs
Perlu modifikasi?
10.3 Software Configuration Item (SCI) SCI merupakan informasi yang diciptakan sebagai bagian dari proses rekayasa perangkat lunak.
SCI berikut menjadi target bagi teknik2 CM dan membentuk sekumpulan baseline. 1. 2. 3.
4. 5.
System Specification Software Project Plan Software Requirement Specification a. Graphical analysis model b. Process specifications c. Prototype(s) d. Mathematical specification Preliminary User Manual Design Specification a. Data design description b. Architectural design description c. Modul design descriptions d. Interface design descriptions e. Object description
Software Configuration Item (lanj) 6. Source Code Listing 7. Test Specification a. Test plan & procedure b. Test cases & recorded results
8. Operation & Installation Manuals 9. Executable Program a. Module executable code b. Linked modules
10. Database Description a. Schema & file structure b. Initial content
11. As-built User Manual 12. Maintenance Documents a. Software problem reports b. Maintenance requests c. Engineering change orders
13. Standard & Procedure for Software Engineering
10.4. SCM Process 10.4.1 Tanggung Jawab SCM SCM adalah sebuah elemen penting dari SQA Tanggung jawab utamanya adalah mengontrol perubahan. SCM juga bertanggung jawab untuk : mengidentifikasi individual SCI & berbagai versi perangkat lunak, meng-audit software configuration untuk memastikan bahwa dia telah dikembangkan dengan benar, dan melaporkan semua perubahan yang telah dilakukan pada konfigurasi tersebut.
10.4.2 Pertanyaan Seputar SCM
Diskusi mengenai SCM memperkenalkan sekumpulan pertanyaan kompleks sebagai berikut. Bagaimana suatu organisasi mengidentifikasi dan menangani berbagai versi yang ada dari sebuah program (dan dokumentasinya) dalam suatu cara yang akan memungkinkan perubahan ditampung secara efisien? Bagaimana suatu organisasi mengontrol perubahan sebelum dan setelah perangkat lunak dirilis ke pelanggan? Siapa yang mempunyai tanggung jawab (otoritas) untuk approving (menyetujui) & prioritizing (memprioritaskan) perubahan? Bagaimana kita yakin bahwa perubahan2 tersebut telah dilakukan dengan benar? Mekanisme apa yang dipakai untuk memberitahu yang lain bahwa perubahan telah dilakukan?
10.4.3 Tugas SCM Pertanyaan2 tersebut membawa kepada definisi 5 tugas (task) SCM : identifikasi,
kontrol versi, kontrol perubahan, auditing konfigurasi, dan pelaporan.
10.5 Identifikasi Objek dalam SC 10.5.1 Tipe Objek Untuk mengontrol & menangani SCI2, masing2 item harus diberi nama berbeda dan kemudian diorganisir dengan menggunakan metode berorientasi objek. Dua tipe objek dapat diidentifikasi: basic objects (obyek dasar) & aggregate objects (kumpulan obyek). Sebuah basic object adalah sebuah “unit of text” yang telah diciptakan oleh seorang software engineer pada saat (selama) analisis, design, coding, atau testing. Sebuah aggregate object adalah sekumpulan basic object dan aggregate objects lainnya.
10.5.2 Keunikan Objek Setiap object mempunyai sekumpulan fitur yang berbeda yang mengidentifikasikannya secara unik; sebuah nama (object name),
suatu deskripsi (object description), suatu daftar sumber daya (resources list) dan suatu realisasi (realization)
10.5.2 Keunikan Objek (lanj) Object name adalah sebuah string karakter yang mengidentifikasi object secara tidak samar. Object description adalah sebuah list item2 data yang mengidentifikasi: tipe SCI (misal dokumen, program, data) yang direpresentasikan oleh object; suatu project identifier; dan informasi perubahan dan/atau versi.
Resources adalah entitas yang disediakan, diproses, diacu atau sebaliknya diperlukan oleh object. Realisasi adalah sebuah pointer pada “unit of text” untuk suatu basic object dan null untuk suatu aggregate object.
10.5.3 Hubungan Antar-Objek
Configuration object identification juga harus mempertimbangkan hubungan yang ada antara “named objects”
Sebuah object dapat diidentifikasi sebagai <part-of> suatu aggregate object.
Hubungan <part-of> menentukan sebuah hirarki object2.
Hubungan di antara object2 dalam suatu hirarki objek tidak hanya sepanjang direct path dari hirarchical tree, tetapi dalam beberapa hal, object2 diinterrelasikan melewati cabang2 dari object hirarchy.
Interrelationships antara configuration objects dapat direpresentasikan dengan sebuah module interconection language (MIL).
MIL menggambarkan interdependencies di antara configuration objects dan memungkinkan suatu versi dari suatu sistem dikonstruksi secara otomatis.
Gambar : Configuration Objects Data Model
Design specification data design architectural design module design interface design Module N interface description algorithm description PDL
Test specification test plan test procedure test cases
Source code
10.5.4 Evolusi Objek Skema identifikasi untuk objek2 perangkat lunak harus mengenali bahwa objek2 berevolusi selama proses perangkat lunak. Sebelum suatu objek dijadikan baseline, dia boleh berubah berkali-kali, dan bahkan setelah suatu baseline ditetapkan, perubahan2 mungkin cukup sering. Dimungkinkan untuk menciptakan sebuah evolution graph untuk suatu object. Evolution graph menggambarkan sejarah perubahan dari object (lihat gbr). Dimungkinkan juga perubahan2 dapat dilakukan pada sembarang versi, tetapi tidak perlu pada semua versi.
Grafik Evolusi
obj 1.0
obj 1.1
obj 1.3
obj 1.4
obj 2.0
obj 2.1
obj 1.2
obj 1.1.1
obj 1.1.2
10.6 Kontrol Versi (Version Control) Clemm[CLE89] menggambarkan version control dalam konteks SCM sbb: Configuration management mengijinkan seorang user untuk menentukan konfigurasi alternatif dari sistem software melalui pemilihan versi2 yang sesuai. Hal ini didukung oleh atribut2 yang terkait dengan masing2 versi
software, dan kemudian juga mengijinkan suatu konfigurasi ditentukan (dan dikonstruksi) dengan menggambarkan serangkaian atribut yang diinginkan.
10.6.1 Versi PL Atribut2 yang dikemukakan di atas dapat sesederhana seperti hanya sebuah nomor versi tertentu yang terkait pada masing2 objek atau sekompleks seperti suatu string dari variable boolean (switches) yang menunjukkan tipe tertentu dari perubahan2 fungsional yang telah dilakukan pada sistem. Salah satu representasi dari versi2 yang berlainan dari suatu sistem adalah evolution graph (lihat gbr). Masing2 node pada graph tersebut adalah sebuah aggregate object, yaitu satu versi lengkap (utuh) dari perangkat lunak.
10.6.2 Komponen Masing2 versi perangkat lunak adalah sekumpulan SCI (source code, dokumen2, data) dan setiap versi dapat terdiri dari variant2 yang berbeda. Untuk melukiskan konsep ini, pikirkan sebuah versi dari sebuah program sederhana yang tersusun dari komponen2 1, 2, 3, 4, dan 5 (lihat gbr). Komponen 4 hanya dipakai bila software diimplementasikan dengan menggunakan display warna. Komponen 5 diimplementasikan bila tampilan yang dipakai monochrome. Oleh karena itu, dua variant dari versi tersebut dapat ditentukan: (1) komponen2 1, 2, 3, dan 4; (2) komponen2 1, 2, 3, dan 5.
Grafik Evolusi Revisi Perangkat Lunak
obj 1.0
obj 1.1
obj 1.3
obj 1.4
obj 2.0
obj 2.1
obj 1.2
obj 1.1.1
obj 1.1.2 1 2
3
variants
4
5 components
10.6.3 Varian Untuk membangun varian yang sesuai dari suatu versi tertentu dari suatu program, masing2 komponen dapat diberikan suatu “attribute-tuple”, yaitu sebuah lis dari fitur2 yang akan menentukan suatu komponen tertentu harus dipakai bila suatu varian tertentu dari suatu versi perangkat lunak dibuat. Satu atau lebih atribut diberikan untuk masing2 varian. Sebagai contoh, suatu atribut ‘color’ dapat dipakai untuk menentukan komponen yang harus disertakan bila color display yang harus didukung. Cara lain untuk mengkonseptualisir hubungan antara komponen, varian2, dan versi2 (revisi2) adalah merepresentasikannya sebagai “object pool”
variants
components
versions object
10.6.4 Hub Objek Konfigurasi, Komponen, Varian, dan Versi Hubungan antara configuration object dan komponen2, varian2, dan versi2 dapat direpresentasikan sebagai sebuah ruang tiga dimensi. Sebuah versi dapat dipilih dari beberapa varian yang ada (sb vertikal) yang terdiri dari beberapa komponen. Sebuah komponen tersusun dari sekumpulan objek2 pada tingkat level revisi yang sama. Sebuah varian adalah sekumpulan objek2 yang berbeda pada tingkat revisi yang sama, dan oleh karena itu berada berdampingan secara paralel dengan variant2 lain.
Sebuah versi baru ditentukan bila perubahan2 besar (utama) dilakukan pada satu atau lebih object.
10.7 Kontrol Perubahan Untuk proyek pengembangan perangkat lunak yang besar, perubahan yang tidak terkontrol membawa pada kekacauan (chaos). Change control menggabungkan prosedur manusia dan tool otomatis guna memberikan sebuah mekanisme untuk mengontrol perubahan. Suatu change request di submit dan dievaluasi untuk menilai manfaat teknisnya, efek samping yang potensial, dampak keseluruhan pada configuration objects dan fungsi2 sistem lainnya.
10.7.1 Proses Kontrol Perubahan
Hasil dari evaluasi tersebut dipresentasikan sebagai sebuah Change Report yang dipakai oleh Change Control Authority (CCA), yaitu seseorang atau grup yang membuat keputusan akhir terhadap status dan prioritas dari perubahan tersebut.
Sebuah Engineering Change Order (ECO) dibuat untuk setiap perubahan yang telah disetujui.
ECO menjelaskan perubahan2 yang harus dibuat, kendala2 yang harus diperhatikan, dan kriteria2 untuk review & audit.
Objek yang akan diubah di’checked out’ dari basis data proyek, dilakukan perubahan, dan kegiatan2 SQA yang bersesuaian dilaksanakan. Objek tersebut kemudian di’checked-in’ ke basis data dan mekanisme version control yang sesuai dipakai untuk menciptakan versi berikutnya dari perangkat lunak tersebut. Proses check-in dan check-out mengimplementasikan dua elemen penting dari kontrol perubahan, yaitu access control & synchronization control.
10.7.2 Kontrol Akses & Sinkronisasi
Kontrol akses mengatur perekayasa perangkat lunak yang mempunyai otoritas untuk mengakses dan memodifikasi suatu configuration object tertentu (khusus). Kontrol sinkronisasi membantu untuk memastikan bahwa paralel changes yang dilakukan oleh dua orang yang berbeda tidak saling overwrite satu terhadap lainnya. Aliran kontrol akses & sinkronisasi dilukiskan secara skematik pada gbr berikut.
Change Control check-in configuration object (modified version) configuration object (baseline version) unlock audit info ownership info software engineer
access control
project database
lock configuration object (extracted version)
configuration object (baseline version) check-out
10.8 Audit Konfigurasi Identifikasi, kontrol versi, dan kontrol perubahan membantu pengembang perangkat lunak untuk mempertahankan aturan, bila tidak akan mendatangkan situasi yang chaotic & fluid. Walaupun demikian, bahkan mekanisme kontrol yang berhasil mentrack perubahan hanya sampai ECO dibangkitkan.
Bagaimana kita dapat menjamin bahwa perubahan tersebut telah diimplementasikan dengan benar? Jawabnya adalah dua hal: (1) FTR, dan (2) software configuration audit.
10.8.1 Proses Audit Konfigurasi FTR memusatkan pada ketepatan (correctness) teknis dari configuration object yang telah dimodifikasi. Para reviewer menilai SCI tersebut untuk menentukan konsistensi terhadap SCI2 lain, penghilangan, dan potensial side effects. FTR harus dilaksanakan untuk semua perubahan termasuk yang paling sepele. Software configuration audit melengkapi (menyempurnakan) FTR dengan penilaian suatu configuration object untuk karakteristik2 yang pada umumnya tidak dipertimbangkan selama review.
10.8.2 Pertanyaan dalam Proses Audit Konfigurasi Audit tersebut menanyakan dan menjawab pertanyaan2 berikut: 1. Apakah perubahan yang ditentukan dalam ECO telah dilakukan? Apakah suatu modifikasi tambahan telah disertakan? 2. Apakah FTR telah dilakukan untuk menilai ketepatan teknis? 3. Apakah standard2 software engineering telah diikuti dengan benar? 4. Apakah perubahan tersebut telah ditandai dalam SCI? Apakah tanggal perubahan dan orang yang membuat perubahan telah dicatat? Apakah atribut2 configuration object mencerminkan perubahan tersebut? 5. Apakah prosedur2 SCM untuk pencatatan perubahan, perekaman, dan pelaporan telah diikuti? 6. Apakah semua SCI yang terkait telah diupdate dengan benar?
10.8.3 Pelaporan Status Konfigurasi (Status Accounting)
Setiap kali suatu SCI diberi identifikasi baru atau diupdate, sebuah Configuration Status Reporting CSR entry dibuat. Setiap kali suatu perubahan disetujui oleh CCA (yaitu, suatu ECO dikeluarkan), sebuah entry CSR dibuat. Setiap kali suatu configuration audit dilakukan, hasil2nya dilaporkan sebagai bagian dari task CSR. Output dari CSR dapat diletakkan dalam basis data online shg pengembang perangkat lunak atau pengelola (maintainers) dapat mengakses informasi perubahan dengan keyword category.
10.9 SCM Standards Beberapa standard SCM awal, seperti MIL-STD-483, DOD-STD-480A, dan MIL-STD-1521A, memusatkan pada software yang dikembangkan untuk aplikasi militer. Standar ANSI/IEEE yang lebih baru, seperti ANSI/IEEE Std. No. 828 - 1983, Std. No. 1042 - 1987, dan Std. No. 1028 - 1988, dapat dipakai untuk software komersial dan direkomendasikan baik untuk organisasi2 rekayasa perangkat lunak besar & kecil. ***
III. METODE KONVENSIONAL
11. REKAYASA SISTEM BERBASIS KOMPUTER
11.1 Sistem Berbasis Komputer (Computer-based System)
Sistem berbasis komputer bertujuan untuk mendukung berbagai fungsi bisnis atau untuk mengembangkan suatu produk yang dapat dijual untuk menghasilkan keuntungan bisnis.
Elemen-elemen sistem berbasis komputer: 1.
Perangkat lunak (program komputer, struktur data, dan dokumen yang berhubungan)
2.
Perangkat keras (perangkat elektronik dan elektromekanik)
3.
Manusia (user yang memakai perangkat lunak dan perangkat keras)
4.
Basisdata (kumpulan informasi besar dan terorganisir yang diakses melalui perangkat lunak)
5.
Dokumentasi (manual, formulir, dan informasi deskriptif lainnya)
6.
Prosedur (langkah-langkah yang menentukan penggunaan elemen sistem)
Rekayasa Perangkat Lunak terjadi sebagai konsekuensi dari suatu proses yang disebut Rekayasa Sistem Berbasis Komputer (Rekayasa Sistem)
Rekayasa Sistem memfokuskan diri pada berbagai elemen, analisis, desain, dan pengorganisasian elemen-elemen tersebut ke dalam suatu sistem yang dapat menjadi sebuah produk, jasa, atau teknologi untuk mentransformasi informasi atau kontrol. Oleh sebab itu rekayasa sistem cenderung pada pengembangan sistem berbasis komputer.
Proses Rekayasa Sistem disebut Rekayasa Informasi bila konteks kerja berfokus pada sistem informasi bagi manajemen yang bersifat unik bagi suatu institusi. Hasil rekayasa ini dapat bersifat masal (menjadi suatu produk yang dipasarkan masal) hanya bila dapat diterapkan di berbagai institusi tanpa merubah fungsi-fungsi transformasi.
11.1.1 Karakteristik Sistem Berbasis Komputer Karakteristik Sistem Berbasis Komputer ditandai oleh adanya elemen-elemen yang berbasis komputer pula. Sistem Otomasi Pabrik
Sistem Inventori
Sistem Pemanukfaturan
Sistem Aliran Material
Mesin Control Numeric
Sistem Informasi
Sel Pemanufakturan
Robot
Perangkat Entry Data
11.1.2 Hirarki Rekayasa Sistem
Rekayasa melingkupi sekumpulan metode dari atas ke bawah (top-down) dan dari ke bawah ke atas (bottom-up) untuk mengendalikan hirarki dari sistem makro.
Proses rekayasa sistem dimulai dengan sebuah world view (WV). Semua domain bisnis atau domain produk diuji untuk memastikan bahwa bisnis atau konteks teknologi yang tepat dapat dibangun.
Pada domain tertentu, kebutuhan sistem yang ditargetkan (mis. data, SW, HW, manusia) dianalisis. Kemudian analisis, desain, dan konstruksi dari elemen yang ditargetkan diinisiasi.
Pada puncak hirarki, suatu konteks yang lebih luas dibangun, dan di bagian dasarnya, aktivitas teknik lengkap - yang dilakukan oleh disiplin rekayasa yang relevan - dilakukan.
Gambaran sistem : WV = {D1 D2 D3……Dn} WV = wold view (sebuah sistem besar) Di = {E1 E2 E3……En} Di = domain sistem (sub sistem) E1 = {C1 C2 C3……Cn} Ei = elemen (pembentuk domain)
11.1.3 Hirarki Rekayasa Perangkat Lunak Domain Bisnis / Produk
World View
domain interes
elemen sistem
Pandangan 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 Perencanaan Strategi Informasi (World View)
Perusahaan area bisnis
Area Bisnis
Analisis Area Bisnis (Pandangan Domain)
persyaratan pemrosesan Sistem Informasi
Desain Sistem Bisnis (Pandangan Elemen)
Konstruksi dan Integrasi (Pandangan Detail)
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 informasi perusahaan secara rinci dan tajam.
Untuk memodelkan relasi antaraspek-aspek informasi perekayasa informasi harus menggambarkan penggunaan objek data dan transformasinya pada masing-masing area bisnis dan menggambarkan pula mekanisme fungsi dan proses bisnis pada masing-masing area bisnis dalam mentransformasi objek data.
Untuk melakukan tersebut, BAA menggunakan sejumlah model:
model data
model aliran proses
diagram dekomposisi proses
matriks lintas referensi
11.2.3 Pemodelan Data
Objek : Pelanggan Atribut :
nama
nama perusahaan objek : perusahaan
klasifikasi pekerjaan dan otoritas pembelian
alamat bisnis dan informasi kontak
pembelian sebelumnya
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.
Mengkonfirmasikan Info pesanan
Memberi Informasi produk
Membangun kontak pelanggan
Menyiapkan Pesanan pengiriman Mengarahkan Pertanyaan/ perhatian
Memberi Evaluasi produk
Menerima Pesanan penjualan
Memeriksa Konfigurasi ketersediaan Membangun Kontak pelanggan
Model aliran proses untuk fungsi penjualan
Tindak lanjut ke pelanggan
• Objek data input dan output yang diperlihatkan untuk masing-masing proses menunjukkan transformasi informasi untuk menyelesaikan suatu fungsi bisnis Info pesanan utk konfirmasi
Pelanggan
Info produk Info query
Memberi Informasi produk
Rekaman kontak
Membangun kontak pelanggan
Deskripsi produk
Mengkonfirmasikan Info pesanan
Data pesanan Menyiapkan Pesanan pengiriman
Mengarahkan Pertanyaan/ perhatian Memberi Evaluasi produk
Deskripsi Produk terevaluasi
Pemenuhan pesanan
Menerima Pesanan penjualan
Format konfigurasi
Memeriksa Konfigurasi ketersediaan
Data pengiriman
Info pesanan Pemenuhan pesanan Membangun Kontak pelanggan
ketersediaan
Info pesanan
Tindak lanjut ke pelanggan
Pemenuhan pesanan
Rekayasa Informasi merupakan suatu pendekatan Rekayasa Sistem yang digunakan untuk menentukan arsitektur yang memungkinkan organisasi /bisnis menggunakan informasi scr efektif.
11.3 Rekayasa Sistem
Rekayasa Sistem merupakan suatu aktivitas pemecahan masalah yang dihadapi sistem.
Data produk, fungsi, dan perilaku sistem harus ditemukan, dianalisis, dan dialokasikan ke dalam komponen-komponen rekayasa.
Perekayasa sistem harus memperjelas dan membatasi persyaratan sistem dengan mengidentifikasi ruang lingkup fungsi dan kinerja yang diinginkan.
Rekayasa Sistem diawali dengan analisis sistem untuk membentuk model arsitektur sistem dan spesifikasi sistem.
11.3.1 Aktivitas-aktivitas dalam Analisis Sistem
Analisis sistem dilakukan dengan sasaran sebagai berikut:
1.
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.
Identifikasi Kebutuhan
Dilakukan dengan cara bertemu dengan pelanggan dan pemakai akhir.
Hasil dari indentifikasi kebutuhan dispesifikasi dalam suatu dokumen konsep sistem
2.
3.
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
Analisis Ekonomi
4.
Analisis biaya keuntungan yang menggambarkan biaya untuk pengembangan proyek dan membandingkannya dengan keuntungan yang nyata dan tidak nyata dari suatu sistem.
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
Pemrosesan input
Fungsi proses dan kontrol
Pemeliharaan dan self-test
Pemrosesan output
Contoh: Diagram konteks arsitektur untuk CLSS Operator Stasiun sorting Data permintaan
Pembaca Bar code
Conveyor lain
Query dan report
Bar code
Sistem Pengurutan Conveyor Line Indikator kecepatan
Data diagnostik Operator Stasiun sorting
***
Kode Perintah langsir
Mekanisme pengurutan
Data pelaporan terformat mainframe
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 Persyaratan Analisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani jurang antara alokasi perangkat lunak tingkat sistem dan desain perangkat lunak. Analisis persyaratan memungkinkan perekayasa sistem menentukan fungsi dan kinerja perangkat lunak, menunjukkan interface perangkat lunak dengan elemen-elemen sistem yang lain, dan membangun batasan yang harus dipenuhi oleh perangkat lunak.
Analisis Persyaratan PL Perangkat Lunak Desain PL
Analisis Persyaratan PL
Elemen2 lain
REKAYASA SISTEM
12.2 Prinsip-Prinsip Analisis
1.
2.
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
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 modelmodel sistem untuk memahami aliran data dan kontrol, operasi behavioral dan pemrosesan fungsional, serta muatan informasi.
Model tersebut berfungsi sebagai dasar bagi desain perangkat lunak dan untuk membuat spesifikasi perangkat lunak.
Spesifikasi lengkap belum bisa didapatkan pada tahap ini, pendekatan alternatif pada analisis persyaratan adalah prototyping.
12.3.3 Pemodelan Analisis DD : mendeskripsikan semua objek data yang dikonsumsi PL
Struktur Model Analisis
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
Entity Relationship Diagram (ERD)
Data Dictionary (DD) State Transition Diagram (STD)
Data Flow Diagram (DFD)
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
2.
Atribut adalah properti suatu objek data.
3.
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). Atribut digunakan untuk:
menamai sebuah contoh dari objek data,
menggambarkan contoh,
membuat referensi ke contoh yang lain pada tabel yang lain
Hubungan adalah relasi antara objek data yang satu dengan yang lainnya.
Misal: Sensor dan Pintu hubungan : Sensor menggerakkan Pintu
Objek Data, Atribut dan Hubungan Objek:
Atribut:
Hubungan:
Nama Alamat Umur Lisensi Mengemudi Nomor
memiliki Merk Model Nomor ID Tipe Warna
Representasi Tabular Objek Data Mengikat satu objek data ke data lain, dalam kasus ini, pemilik Atribut penamaan Atribut pengidentifikasi deskriptif
Atribut referensial
Merk
Model
ID#
Tipe
Warna
Pemilik
Lexus
LS400
AB123
Sedan
Putih
RSP
BMW
750iL
X456
Coupe
Merah
CCD
Ford
Taurus
YZ276
Sedan
Putih
LJL
Chevy
Corvette
Q1234
Sport
Hijau
BLF
12.3.4 Spesifikasi Pada prinsipnya Spesifikasi merupakan representasi persyaratan dari perangkat lunak yang akan dibangun. Diperlukan pendekatan sbb.
Teknik spesifikasi yang terfasilitasi (Facilitated Aplication Specification Techniques = FAST)
Pertemuan dilakukan di tempat netral yang dihadiri oleh pengembang maupun pelanggan.
Tujuannya : identifikasi masalah, pemecahan, negosiasi, membentuk persyaratan PL.
Ada fasilitator (sebaiknya konsultan) yang bertugas mengontrol pertemuan.
Penyebaran fungsi kualitas
Quality Function Deployment (QFD) adalah teknik manajemen kualitas yang menterjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak
QFD berkonsentrasi pada pemaksimalan kepuasan pelanggan
Hasil proses spesifikasi dituangkan dalam Dokumen Spesifikasi PL (lih.SCI).
12.3.5 Kajian
Kajian digunakan untuk memastikan Spesifikasi sudah lengkap, konsisten, dan akurat. Contoh pertanyaan kajian :
Apakah tujuan dan sasaran yang dinyatakan bagi PL tetap 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
Entity Relationship Diagram (ERD)
Data Dictionary (DD) State Transition Diagram (STD)
Data Flow Diagram (DFD)
Desain Prosedural
Desain Interface Desain Arsitektur
Desain Data
13.2 Desain Data
Desain data adalah tahapan pemilihan representasi logis dari objek data yang telah teridentifikasi dalam Analisis Persyaratan dan Spesifikasi. Prinsip2nya : Prinsip2 analisis sistem yang diterapkan pada fungsi dan perilaku PL juga perlu diterapkan pada data. Semua struktur data dan operasinya harus teridentifikasi. Kamus data harus dibangun untuk merepresentasikan hub antarobjek data dan batasan2nya. Keputusan desain data tingkat rendah harus dilakukan di akhir proses desain data. Konsep information hiding (penyembunyian informasi suatu modul agar tidak diakses oleh modul lain yang tidak berkepentingan) dan perangkaian sangat penting bagi kualitas PL. Pustaka struktur data dan operasi yang berguna harus dikembangkan agar dapat digunakan kembali. Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi tipe data abstrak.
13.3. Desain Arsitektur PL
Arsitektur merupakan struktur hirarkhi dari komponen program (modul), interaksinya, dan struktur data yang digunakan. Terdapat bbrp model desain arsitektur :
Model Struktural : bdsk struktur komponen program
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, NassiShneiderman 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. Modularitas 13.3.1.1 Modularitas dan Kompleksitas Problem
Modularitas diterapkan melalui pembagian PL ke dalam komponen – komponen PL yang dapat dipanggil terpisah sehingga bila terdapat problem, maka problem tsb akan lebih mudah diselesaikan. Kompleksitas ( C ) problem (p1 dan p2) yang
bergabung menjadi satu, lebih besar dibandingkan bila problem tersebut dipandang secara terpisah. C(p1+p2) > C(p1) + C(p2)
Oleh sebab itu modularitas penting dalam desain arsitektur PL. Namun berkaitan dengan biaya, sebaiknya dihindari kondisi undermodularity maupun overmodularity. Semakin banyak modul semakin rendah biaya per-modul tetapi semakin tinggi biaya integrasinya.
13.3.1.2 Independensi Fungsional
Konsep ini mrpk pertumbuhan langsung dari modularitas, konsep abstraksi PL, dan Information Hiding. Independensi diukur melalui Kohesi dan Kopling.
Kohesi Modul yang kohesif seharusnya hanya melakukan satu hal saja (kohesi tinggi = fungsional <> koinsidental).
Kopling Sehubungan dengan perangkaian dengan modul lain, maka modul yang baik seharusnya memiliki hubungan yang sederhana (kopling rendah)
13.3.2 Proses Desain Arsitektur
13.3.2.1 Pemetaan Transformasi Informasi dari ‘dunia eksternal’ mengalir masuk ke dalam PL dan keluar lagi dalam bentuk informasi dunia eksternal. Misal ketikan keyboard dan bunyi di saluran telpon akan masuk ke pusat transformasi dan dialirkan ke dunia luar dalam bentuk tampilan layar. Aliran ini disebut aliran transformasi. Dalam DFD dapat dijumpai adanya aliran transformasi ini. Guna menyusun struktur program aliran transformasi dari DFD ini dipetakan dengan langkah pengkajian thd Context DFD, penentuan pusat transformasi, pemfaktoran dan penyaringan, dan pemetaan. Contohnya sbb.
Contoh Pemetaan Transformasi
Promosi
Penjualan
Penerimaan Pesanan
Persiapan Pengiriman
Mengkonfirmasikan Info pesanan
Memberi Informasi produk
Membangun kontak pelanggan
Menyiapkan Pesanan pengiriman Mengarahkan Pertanyaan/ perhatian
Memberi Evaluasi produk
Menerima Pesanan penjualan
Memeriksa Konfigurasi ketersediaan Membangun Kontak pelanggan
Tindak lanjut ke pelanggan
13.3.2.1 Pemetaan Transaksi
Aliran transaksi ditandai dengan pergerakan data sepanjang jalur masuk yang mengkonversikan informasi dunia eksternal ke dalam suatu transaksi. Transaksi ini akan menimbulkan jalur aksi. Pusat aliran informasi tempat banyak jalur aksi berasal disebut pusat transaksi.
Pemetaan DFD yang mengandung aliran transaksi ke struktur program hampir sama dengan pemetaan aliran transformasi, namun yang diidentifikasi adalah pusat transaksinya (lihat contoh)
Contoh Pemetaan Transaksi
Kontrol Transaksi
a
d
b
b d
p
a
c1
q q
r s
p
r
s
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.
b.
c.
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
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
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
14.1 Dasar-dasar Pengujian Metrik Kualitas PL
Portability Reusability Interoperability
Maitainabilty Flexibility
TESTABILITY
Revisi Produk
Transisi Produk
Operasi Produk Correctness, Reliability, Usability, Integrity, Efisiency Faktor Kualitas PL McCall
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)
1.
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.
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
Cyclomatic Complexity 1
2,3 6 7
R3
R2
4,5
8 R1
9
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)
10
Ri : Region ke I [MCCL92]
11
R4 Contoh V(G) = 4 V(G) > 10 : more troblesome and less reliable[MART88].
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), nodeweight (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 BlackBox digunakan scr eksklusif dalam validasi.
14.3.1 Proses Pengujian Unit Testing Module Testing
COMPONENT TESTING
Sub-system Testing System Testing
INTEGRATION TESTING
Acceptance Testing USER TESTING
1. Component Testing Pengujian terhadap komponen sistem, seringkali menggunakan teknik pengujian White-Box. a. Unit Testing • pengujian tahap awal • pengujian komponen secara terpisah • unit-unit terkecil diuji : function, procedure, subprogram, dll b. Module Testing (modul memadukan beberapa komponen) • menguji interaksi antarunit • menguji perilaku modul
2.
Integration Testing Pengujian 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 Testing Pengujian 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
ACCEPTANCE TEST PLAN
Use
Acceptance Test
Detailed Design
System Design
SYSTEM INTEGRATION TEST PLAN
SUB-SYSTEM INTEGRATION TEST PLAN
System Integration Test
***
Module & Unit Code and Test
Sub-system Integration Test
