http://www.hendra-jatnika.web.id
BAB I SOFTWARE ENGINEERING Arti Software Engineering : Ilmu yang mempelajari tehnik pembuatan software yang baik dengan pendekatan tehnik (Engineering approach) Dalam membuat softrare yang baik, ada beberapa cara : 1. Fase Perencanaan (Planning) : a) Rencana software b) Analisa kebutuhan software c) Analisa cost banefit (Salah satu bagian dari studi kelayakan) 2. Fase Pengembangan (Development) : a) Coding b) Testing Macam-macam test program : i) Unit test (Test per modul) ii) Integreated test (Test penggabungan dari modul-modul yang telah diuji) iii) Validated test (Diuji dengan data sebenarnya) iv) System test (Test dilakukan dengan lingkungan sebenarnya) v) Topdown test (Test gabungan dari atas ke bawah) vi) Bottom up test (Test gabungan dari bawah ke atas) 3. Fase Pemeliharaan (Maintenance) : Jenis-jenis maintenance a) Koreksi (Corection) b) Adaptasi (Adaptive) Software dikembangkan sesuai dengan tuntutan perkembangan jaman c) Adaptasi yang berkembang pada dewasa ini terbagi atas : i) Sistem Operasi
t e N
a r d
By
◊
n e H
Pengarahan sistem operasi yang bersifat multi user. Contoh : UNIX
◊ Sistem operasi yang bersifat jaringan. Contoh : NOVELL ii) RDBMS - Relational DataBase Management System ◊ Berkembang dalam bentuk bahasa SQL (Structure Query Language). iii) Bahasa Mengarah pada perkembangan bahasa generasi ke empat (4GL - Fourth Generation Language) Bahasa 4GL adalah suatu bahasa yang dibuat untuk meningkatkan produktifitas programmer dan end user. Contoh : a) INFORMIX - Dapat dijalankan pada PC dengan minimum RAM 4MB + 640KB dan disk storage > 40MB b) ORACLE c) INGRES Page 1 / 146
http://www.hendra-jatnika.web.id
d) AS / SET - Digunakan pada IBM AS 400 e) POWER HOUSE - digunakan pada HR 3000 iv) Perfective Menyempurnakan software yang ada biasanya dilakukan karena permintaan / saran / kritik user.
t e N
a r d
By
n e H
Page 2 / 146
http://www.hendra-jatnika.web.id
SOFTWARE AND SOFTWARE ENGINEERING Selama tiga dekade pertama dari era komputerisasi, tantangan utama adalah mengembangkan hardware komputer yang dapat mengurangi biaya pengolahan dan penyimpanan data. Selama dekade tahun 1980 an, kemajuan yang pesat dari mikro elektronik menghasilkan kemampuan komputer yang lebih baik pada tingkat biaya yang lebih rendah. Namun masalah sekarang berbeda. Tantangan utama adalah mengurangi biaya dan memperbaiki kualitas solusi berbasis komputer (Solusi yang diimplementasikan dengan mempergunakan software). Software merupakan faktor kunci dalam keberhasilan suatu usaha, software dapat membedakan satu perusahaan dari perusahan saingannya. EVOLUSI PERKEMBANGAN SOFTWARE Evolusi software
1950
1960
1970
1980
1990
2000
Tahun-tahun awal :
Era ketiga
◊
Batch orientation
◊
Distibuted system
◊
Limmited distribution
◊
Embedded intellegence
◊
Custummer software
◊
Low cost hardware
a r d ◊
Era kedua : ◊
Multi user
◊
Real time
◊
Database
t e N
By
n e H
Consumer infact
Era keempat : ◊
Expert system
◊
A I Machine
◊
Parallel architecture
TAHUN-TAHUN PERTAMA : ◊
Batch Orientation Suatu orientasi di mana proses dilakukan setelah data dikumpulkan dalam satuan waktu tertentu, atau proses dilakukan setelah data terkumpul, lawan dari batch adalah ONLINE atau Interactive Process. Keuntungan dari Interactive adalah mendapatkan data yang selalu up to date.
◊
Limmited distribution Suatu penyebaran software yang terbatas pada perusahaan-perusahaan tertentu.
◊
Custom software Software yang dikembangkan berdaasarkan perusahaan-perusahaan tertentu.
ERA KEDUA : ◊
Multi user Suatu sistem di mana satu komputer digunakan oleh beberapa user pada saat yang sama.
◊
Real Time
Page 3 / 146
http://www.hendra-jatnika.web.id
Suatu sistem yang dapat mengumpulkan, menganalisa dan mentransformasikan data dari berbagai sumber, mengontrol proses dan menghasilkan output dalam mili second. ◊
Database Perkembangan yang pesat dari alat penyimpan data yang OnLine menyebabkan muncul generasi pertama DBMS (DataBase Management System).
◊
Product Software Adalah software yang dikembangkan untuk dijual kepada masyarakat luas.
ERA KETIGA : ◊
Distributed system Suatu sistem yang tidak hanya dipusatkan pada komputer induk (Host computer), daerah atau bidang lainnya yang juga memiliki komputer yang ukurannya lebih kecil dari komputer induk. Lawan dari distributed system adalah Centralized System.
◊
Embedded Intelegence Suatu product yang diberi tambahan “Intellegence” dan biasanya ditambahkan mikroprocessor yang mutakhir. Contohnya adalah automobil, robot, peralatan diagnostic serum darah.
◊
Low Cost Hardware harga hardware yang semakin rendah, ini dimungkinkan karena munculnya Personal Computer.
◊
Consummer Inpact Adanya perkembangan komputer yang murah menyebabkan banyaknya software yang dikembangkan, software ini memberi dampak yang besar terhadap masyarakat.
t e N
a r d
ERA KEEMPAT :
n e H
◊
Expert system Suatu penerapan A.I. (Artificial Intellegence) pada bidang-bidang tertentu, misalnya bidang kedokteran, komunikasi, dll.
◊
AI Machine Suatu mesin yang dapat meniru kerja dari sebagian otak manusia. Misalnya mesin robot, komputer catur.
◊
Parallel Architecture Arsitektur komputer yang memungkinkan proses kerja LAN paralel, yang dimungkinkan adanya prosesor berbeda dalam satu komputer
By
ARTI SOFTWARE 1. Instruksi Atau program komputer yang ketika dieksekusi akan memberi fungsi dan hasil yang diinginkan. 2. Struktur data Yang memungkinkan program memanipulasi informasi 3. Dokumen Yang menggambarkan operasi dan penggunaan program. SIFAT DAN KARAKTERISTIK SOFTWARE 1. Software merupakan elemen sistem logik dan bukan elemen sistem fisik seperti hardware
Page 4 / 146
http://www.hendra-jatnika.web.id
2. Elemen itu tidak aus, tetapi bisa rusak. 3. Elemen software itu direkayasa atau dikembangkan dan bukan dibuat di pabrik seperti hardware 4. Software itu tidak bisa dirakit. KOMPONEN SOFTWARE 1. Bentuk bahasa Terbagi 2, yaitu A. High Level, contoh PASCAL, COBOL, FORTRAN. B. Middle Level, contoh C 2. Bentuk translator Terbagi 3 , yaitu : A. Interpreter Menerjemahkan dari bahasa tingkat tinggi ke bahasa tingkat rendah secara satu persatu (statemen demi statemen) B. Compiler Menerjemahkan secara keseluruhan, proses lebih cepat dari interpreter C. Assembler Menerjemahkan dari bahasa rakitan ke bahasa mesin 3. Bentuk mesin : LANGUAGE FORM
a r d
HIGH LEVEL MIDDLE LEVEL
TRANSLATOR
MACHINE LANGUAGE
t e N
By
n e H
Page 5 / 146
http://www.hendra-jatnika.web.id
APLIKASI SOFTWARE 1. Sistem Software Adalah sekumpulan program yang ditulis untuk melayani atau menunjang program lainnya. Beberapa sistem software seperti compiler, editor, komponen-komponen sistem operasi, driver dan prosesor telekomunikasi. 2. Real Time software Software yang mengukur, menganalisis dan mengontrol kejadian yang sesungguhnya terjadi di dunia. Elemenelemen real time software terdiri dari : A. Komponen pengumpul data Yang mengumpulkan dan menyusun informasi dari lingkungan external. B. Komponen analisis Yang mentransformasikan informasi yang diperlukan oleh aplikasi C. Komponen kontrol Yang memberikan respon kepada lingkungan external D. Komponen monitor Yang mengkoordinasi semua komponen-komponen lainnya, sehingga respons real time yang berkisar 1 milisecond sampai 1 menit dapat dipertahankan. Perlu dicatat bahwa istilah real time berbeda dari istilah interactive atau time sharing. Sistem real time harus memberikan respons pada waktu yang ditentukan, sedangkan pada sistem interactive atau time sharing respons time biasanya melebihi batas waktu yang ditentukan tanpa merusak hasil. 3. Business software Software yang palinmg banyak digunakan dalam bidang aplikasi software. Software ini digunakan oleh manajemen untuk mengambil kepitusan ( Decision Making ) dalam bidang bisnis. Contoh :
t e N
a r d
◊
By
DAC EASY ACCOUNTING
n e H
◊ FINANCE MANAJER 4. Engineering and sciencetific software Software yang dicirikan dengan algoritma numerik, aplikasinya berkisar dari astronomi sampai vulkanologi, dari analis ketegangan otomotif sampai dinamika orbit ruang angkasa. Software ini banyak digunakan dalam bidang engineering dan science. Contoh ◊ CAD / CAM ( Computer Aided Design / Computer Aided Manufacture - Ssimulasi sistem ) 5. Emdebed software Suatu software disimpan dalam memori tetap - ROM - Read Only Memory, dan digunakan untuk mengontrol product dan sistem software ini dijalankan dengan berbagai fungsi terbatas. 6. PC software (Personal Computer) Software yang banyak digunakan di komputer pribadi (PC). Contoh : ◊
Word Processing
◊
Spreadsheet
◊
Computer Graphics
:
Printshop, Print Magic
◊
Games
:
Paoman, Load Runner
◊
DBMS
:
Dbase III+, Foxbase, Clipper
: :
WS, WP
Lotus, Supercalc
◊ Network : 7. Artificial Intelegence software
LAN, Novell
Page 6 / 146
http://www.hendra-jatnika.web.id
Software yang banyak menggunakan algoritma non numerik dalam memecahkan masalah kompleks yang tidak dapat dianalisis dengan analisis komputasi biasa. Saat ini bidang AI yang paling aktif adalah expert system atau knowledge base system. Bidang aplikasi lain dari software AI adalah pengenalan citra dan suara ( image and voice pattern recognition ), teorema pembuktian dan permainan / games. KRISIS SOFTWARE Adalah sekumpulan masalah yang ditemukan dalam pengembangan software computer. Masalahnya tidak hanya terbatas pada software yang tidak berfungsi sebagaimana mestinya, tetapi krisis software ini terdiri dari masalah yang berhubungan dengan : 1. Bagaimana mengembangkan software 2. Bagaimana memelihara software ynag ada, yang berkembang dalam jumlah besar 3. Bagaimana mengimbangi permintaan software yang makin besar. MASALAH Krisis software oleh beberapa masalah : 1. Estimasi jadual dan biaya yang seringkali tidak tepat 2. Produktivitas orang-orang software yang tidak dapat mengimbangi permintaan software 3. Kualitas software yang kurang baik.
t e N
Penyebab : Masalah yang berhubungan dengan krisis software disebabkan oleh : 1. Karakteristik software itu sendiri Karakteristik software adalah software yang bersifat logika dibandingkan fisik, oleh karena itu mengukur software harus merupakan suatu kesatuan, tidak seperti hardware. Software yang bersifat tidak aus ini menyebabkan kesalahan yang terjadi pada software. Umumnya terjadi pada tahap pengembangan. Manajer tingkat menengah dan tingkat atas yang tidak mempunyai latar belakang software, seringkali diberi tanggung jawab untuk mengembangkan software. Padahal tidak semua manajer itu dapat me-manage semua proyek. Praktisnya : software programmer atau software engineering mendapatkan latihan formal yang sedikit dalam hal tehnik baru pengembangan software. 2. Kegagalan mereka yang bertanggung jawab dalam pengembangan software.
a r d
By
n e H
MITOS SOFTWARE 1. Mitos managements A. Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu. Realitasnya : Walau hasil program sama, produktivitas dan kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments B. Kita sudah mempunyai buku yang berisi standarisasi dan prosedur untuk pembentukan software. Realitasnya : Memang buku tersebut ada, tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah ketinggalan jaman ( out of date ). C. Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini sering disebut Mongolian harde concept. 2. Mitos Langganan / Customer
Page 7 / 146
http://www.hendra-jatnika.web.id
A. Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian. Realitasnya : Definisi awal yang buruk adalah penyebab utama kegagalan terhadap usaha-usaha pembentukkan software. Penjelasan yang formal dan terinci tentang informasi fungsi performance interface, hambatan desain dan kriteria validasi adalah penting. Karakteristik di atas dapat ditentukan hanya setelah adanya komunikasi antara customer dan developer. B. Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Kenyataannya memang benar bahwa kebutuhan software berubah, tetapi dampak dari perubahan berbeda dari waktu ke waktu. Biaya akibat perubahan
60 - 100 kali 1,5 - 6 kali
1 kali
Waktu penyelesaian Definition
Development
Maintenance
Kesimpulan : Jika perubahan mendekati akhir penyelesaian, maka biaya akan lebih besar. 3. Mitos Praktisi A. Tidak ada metode untuk analisis disain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding. Realitasnya : Metode untuk analisis desain dan testing diperlukan dalam pengembangan software. B. Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi dengan cara “CATCH AS CATCH CAM”. Realitasnya : Diperlukan budget yang besar dalam maintenance software. Pemeliharaan software harus diorganisir, direncanakan dan dikontrol seolah-olah sebagai suatu proyek besar dalam sebuah organisasi.
t e N
a r d
By
n e H
MODEL SOFTWARE ENGINEERING Krisis software tidak dapat hilang dalam satu satu malam, di mana tidak ada suatu pendekatan yang baik dalam mengatasi krisis software, namun gabungan dari metode untuk semua fase dalam pengembangan siftware seperti peralatan yang lebih baik untuk mengautomatisasi metode-metode ini, tehnik yang lebih baik untuk mengontrol kualitas, dan filosofi untuk koordinasi kontrol, serta manajemen dipelajari dalam suatu disiplin ilmu yang kita sebut software engineering. Definisi : Menurut Fritz Badar, software engineering adalah disiplin ilmu yang menerapkan prinsip-prinsip engineering agar mendapatkan software yang ekonomis yang dapat dipercaya dan bekerja lebih efisien pada mesin yang sebenarnya. Software engineering terdiri dari 3 elemen kunci, yaitu : 1. Metode, 2. Peralatan (tools), 3. Prosedur, yang memungkinkan manajer mengontrol proses pengembangan software dan memberikan praktisi dasar yang baik untuk pembentukan software berkualitas tinggi. Page 8 / 146
http://www.hendra-jatnika.web.id
1. Metode Software Enginnering Metode software engineering memberikan tehnik-tehnik bagaimana membentuk software. Metode ini terdiri dari serangkaian tugas : ◊
Perencanaan & estimasi proyek
◊
Analisis kebutuhan sistem dan software
◊
Desain struktur data
◊
Arsitektur program dan prosedur algoritma
◊
Coding
◊ Testing dan pemeliharaan 2. Peralatan Software Engineering Peralatan software engineering memberikan dukungan atau semiautomasi untuk metode. Contohnya : ◊
CASE (Case Aided Software Engineering), yaitu suatu software yang menggabungkan software, hardware, dan database software engineering untuk menghasilkan suatu lingkungan software engineering.
◊
Database Software Engineering, adalah sebuah struktur data yang berisi informasi penting tentang analisis, desain, kode dan testing.
◊ Analogi dengan CASE pada hardware adalah : CAD, CAM, CAE 3. Prosedur Software Engineering Terdiri dari : ◊
urut-urutan di mana metode tersebut diterapkan
◊
dokumen
◊
laporan-laporan
◊
formulir-formulir yang diperlukan
◊
mengontrol kualitas software
◊
mengkoordinasi perubahan yang terjadi pada software
By
t e N
a r d
n e H
Dalam penguasaan atas model software engineering atau software engineering paradigm, dikenal ada 3 metode yang luas dipergunakan, yaitu : 1. Classic Life Cycle Pradigm - Model Water Fall - Model Siklus Hidup Klasik SISTEM ENGINEERING ANALYS DESIGN CODE TESTING MAINTENANCE
Keterangan : A. System Engineering and Analysis Karena software merupakan bagian terbesar dari sistem, maka pekerjaan dimulai dengan cara menerapkan kebutuhan semua elemen sistem dan mengalokasikan sebagian kebutuhan tersebut ke software.
Page 9 / 146
http://www.hendra-jatnika.web.id
Pandangan terhadap sistem adalah penting, terutama pada saat software harus berhubungan dengan elemen lain, seperti : ◊
Hardware
◊
Software
◊ Database B. Analisis kebutuhan software Suatu proses pengumpulan kebutuhan software untuk mengerti sifat-sifat program yang dibentuk software engineering, atau analis harus mengerti fungsi software yang diinginkan, performance dan interface terhadap elemen lainnya. Hasil dari analisis ini didokumentasikan dan direview / dibahas / ditinjau bersama-sama customer. C. Design Desain software sesungguhnya adalah proses multi step (proses yang terdiri dari banyak langkah) yang memfokuskan pada 3 atribut program yang berbeda, yaitu : ◊
Struktur data
◊
Arsitektur software
◊ Rincian prosedur Proses desain menterjemahkan kebutuhan ke dalam representasi software yang dapat diukur kualitasnya sebelum mulai coding. Hasil dari desain ini didokumentasikan dan menjadi bagian dari konfigurasi software. D. Coding Desain harus diterjemahkan ke dalam bentuk yang dapat dibaca oleh mesin E. Testing Segera sesudah objek program dihasilkan, pengetesan program dimulai. Proses testing difokuskan pada logika internal software. Jaminan bahwa semua pernyataan atau statements sudah dites dan lingkungan external menjamin bahwa definisi input akan menghasilkan output yang diinginkan. F. Maintenance Software yang sudah dikirim ke customer data berubah karena
t e N
a r d
By
n e H
◊
Software mengalami error
◊
Software harus diadaptasi untuk menyesuaikan dengan lingkungan external, misalnya adanya sistem operasi baru atau peripheral baru.
◊ Software yang lebih disempurnakan karena adanya permintaan dari customer. Masalah yang dihadapi dari model siklus hidup klasik adalah : ◊
Proyek yang sebenarnya jarang mengikuti aliran sequential yang ditawarkan model ini. Iterasi (Pengulangan) selalu terjadi dan menimbulkan masalah pda aplikasi yang dibentuk oleh model ini.
◊
Seringkali pada awalnya customer sulit menentukan semua kebutuhan secara explisit (jelas).
◊
Customer harus sabar karena versi program yang jalan tidak akan tersedia sampai proyek software selesai dalam waktu yang lama.
Page 10 / 146
http://www.hendra-jatnika.web.id
2. Prototype Paradigm REQUIMENTS GATHERING "QUICK DESIGN" BUILD PROTOTYPE EVALUATED AND REFINEMENTS ENGINEER PRODUCT
Keterangan : Seringkali seorang customer sulit menentukan input yang lebih terinci, proses yang diinginkan dan output yang diharapkan. Tentu saja ini menyebabkan developer tidak yakin dengan efisiensi alogoritma yang dibuatnya, sulit menyesuaikan sistem operasi, serta interaksi manusia dan mesin yang harus diambil. Dalam hal seperti ini, pendekatan prototype untuk software engineering merupakan langkah yang terbaik. Prototype sebenarnya adalah suatu proses yang memungkinkan developer membuat sebuah model software. Ada 2 bentuk dari model ini, yaitu : A. Paper Prototype Menggambarkan interaksi manusia dan mesin dalam sebuah bentuk yang memungkinkan user mengerti bagaimana interaksi itu terjadi. B. Working Prototype Adalah prototype yang mengimplementasikan beberapa bagian dari fungsi software yang diinginkan seperti pada pendekatan pengembangan software. Model ini dimulai dengan :
a r d
◊
Pengumpulan kebutuhan developer dan customer
◊
Menentukan semua tujuan software
◊
Mengidentifikasi kebutuhan-kebutuhan yang diketahui
By
t e N
n e H
Hasil dari pengumpulan kebutuhan diteruskan pada Quick Design. Quick Design ini memfokuskan pada representasi aspek-aspek software yang dapat dilihat oleh user, misalnya format input dan output, selanjutanya dari desain cepat diteruskan pada pembentukan prototype (langkah ke 3). Prototype ini dievaluasi oleh customer / user dan digunakan untuk memperbaiki kebutuhan-kebutuhan software. Proses iterasi terjadi agar prototype yang dihasilkan memenuhi kebutuhan customer, juga pada saat yang sama developer mengerti lebih baik tentang apa yang harus dikerjakan. Masalah yang dihadapi oleh prototyping paradigm ini adalah : ◊
Customer hanya melihat pada apa yang dihasilkan oleh software, tidak peduli pada hal-hal yang berhubungan dengan kualitas software dan pemeliharaan jangka panjang.
◊
Developer seringkali menyetujui apa yang diterangkan oleh customer agar prototype dapat dihasilkan dengan cepat. Akibatnya timbul pemilihan sistem operasi / bahasa pemrograman yang tidak tepat.
3. Fourth Generation Tehnique Paradigm - Model tehnik generasi ke 4 / 4GT REQUIMENTS GATHERING "DESIGN STRATEGICS" IMPLEMENTATION USING 4GT PRODUCT
Page 11 / 146
http://www.hendra-jatnika.web.id
Istilah Fourth Generation Technique (4GT) meliputi seperangkat peralatan software yang memungkinkan seorang developer software menerapkan beberapa karakteristik software pada tingkat yang tinggi, yang kemudian menghasilkan source code dan object code secara otomatis sesuai dengan spesifikasi yang ditentukan developer. Saat ini peralatan / tools 4GT adalah bahasa non prosedur untuk : ◊
DataBase Query
◊
Pembentukan laporan ( Report Generation )
◊
Manipulasi data
◊
Definisi dan interaksi layar (screen)
◊
Pembentukan object dan source ( Object and source generation )
◊
Kemampuan grafik yang tinggi, dan
◊ Kemampuan spreadsheet Keterangan gambar : ◊
Model 4GT untuk software engineering dimulai dengan rangkaian pengumpulan kebutuhan. Idealnya, seorang customer menjelaskan kebutuhan-kebutuhan yang selanjutnay diterjemahkan ke dalam prototype. Tetapi ini tidak dapat dilakukan karena customer tidak yakin dengan apa yang diperlukan, tidak jelas dalam menetapkan fakta-fakta yang diketahui dan tidak dapat menentukan informasi yang diinginkan oleh peralatan 4GT.
◊
Untuk aplikasi kecil adalah mungkin bergerak langsung dari langkah pengumpulan kebutuhan ke implementasi yang menggunakan bahasa non prosedur fourth generation (generasi ke 4). Tetapi untuk proyek besar, pengembangan strategi desain sistem tetap diperlukan, sekalipun kita menggunakan 4GL. Penggunaan 4GT tanpa desain untuk proyek besar akan menyebabkan masalah yang sama yang ditemui dalam pengembangan software yang menggunakan pendekatan konvensional.
t e N
a r d
◊
Implementasi yang menggunakan 4GL memungkinkan developer software menjelaskan hasil yang diinginkan yang kemudian diterjemahkan ke dalam bentuk source code dan object code secara otomatis.
◊
Langkah yang terakhir adalah mengubah implementasi 4GT ke dalam sebuah product. Selanjutnya developer harus melakukan pengetesan, pengembangan dokumentasi dan pelaksanaan semua aktifitas lainnya yang diwujudkan dalam model software engineering.
n e H
By
Masalah yang dihadapi dalam model 4GT adalah adanya sebagian orang yang beranggapan bahwa : A. peralatan 4GT tidak semudah penggunaan bahasa pemrograman, B. source code yang dihasilkan oleh peralatan ini tidak efisien, C. pemeliharaan sistem software besar yang dikembangkan dengan 4GT masih merupakan tanda tanya. 4. Model Kombinasi - Combining Paradigm DAPAT LANGSUNG JIKA PENDEKATANNYA JELAS PROTOTYPING REQUIMENTS GATHERINGS
APPLY 4GL
ENGINEER PRODUCT
PROTOTYPE
EVALUATE
CLASSIC LIFE CYCLE
Keterangan : Model ini menggabungkan keuntungan-keuntungan dari beberapa model sebelumnya. Seperti pada model sebelumnya, model kombinasi ini dimulai dengan langkah pengumpulan kebutuhan.
Page 12 / 146
http://www.hendra-jatnika.web.id
Pendekatan yang dapat diambil adalah pendekatan siklus hidup klasik (Analisis sistem dan analisis kebutuhan software) atau dapat juga menggunakan pendekatan seperti prototyping jika definisi masalahnya tidak terlalu formal. Jika kebutuhan untuk fungsi dan performance software diketahui dan dimengerti, pendekatan yang dianjurkan adalah model siklus hidup klasik. Sebaliknya, jika aplikasi software menuntut interaksi yang sering antara manusia dan mesin, membutuhkan algoritma yang tidak dapat dibuktikan, atau membutuhkan tehnik output / kontrol, maka pendekatan yang dianjurkan adalah model prototyping. Pada kasus seperti ini, 4GL dapat digunakan untuk mendapat prototype dengan cepat. Segera sesudah prototype dievaluasi dan disempurnakan, langkah desain dan implementasi dalam siklus hidup klasik diterapkan. Dari model yang disebut di atas dapat diambil suatu kesimpulan, bahwa proses pengembangan software terdiri dari 3 fase, yaitu : 1. Fase Definisi 2. Fase Pengembangan (Development) 3. Fase Pemeliharaan (Maintenance) 1. Fase Definisi Fase definisi memfokuskan pada “What”. Selama definisi ini, developer software berusaha untuk : ◊
Mengidentifikasi informasi apa yang dikerjakan proses
◊
Fungsi dan performance apa yang diinginkan
◊
Interface apa yang dibutuhkan
◊
Hambatan desain apa yang ada, dan
◊
Kriteria validasi apa yang dibutuhkan untuk menetapkan keberhasilan sistem.
By
t e N
a r d
n e H
A. Sistem Analis Sistem analis menetapkan peranan dari setiap elemen dalam sistem berbasis komputer, terutama mengalokasikan peranan software. B. Sistem Software Planning Dalam sistem ini, setelah lingkungan software dialokasikan, maka langkah dari sistem software planning ini adalah : ◊
Pengalokasian sumber / resource
◊
Estimasi biaya
◊ Penetapan tugas pekerjaan dan jadual. C. Requirement Analysis Penetapan lingkup untuk software memberikan petunjuk / arah. Namun definisi yang lebih rinci dari informasi dan fungsi software diperlukan sebelum pekerjaan dimulai. 2. Fase Pengembangan Fase pengembangan berfokus pada “How”. Selama pengembangan, developer software berusaha menjelaskan : ◊
Bagaimana struktur data dan arsitektur software yang didesain
◊
Bagaimana rincian prosedur diimplementasikan ( diterapkan )
◊
Bagaimana desain diterjemahkan ke dalam bahasa pemrograman atau bahasa non prosedur, dan
◊
Bagaimana pengetesan akan dilaksanakan. Page 13 / 146
http://www.hendra-jatnika.web.id
A. Desain software ( Software Design ) Desain menterjemahkan kebutuhan-kebutuhan software ke dalam sekumpulan representasi (grafik, tabel, diagram, atau bahasa yang menjelaskan struktur data, arsitektur software dan prosedur algoritma). B. Coding Representasi desain harus diterjemahkan ke dalam bahasa tiruan / artificial language yang menghasilkan perintah-perintah yang dapat dieksekusi oleh komputer. C. Software Testing Segera sesudah software diimplementasikan dalam bentuk yang dapat dieksekusi oleh mesin, software perlu ditest untuk menemukan kesalahan ( merupakan fungsi logika dan implementasi ). 3. Fase Pemeliharaan Fase pemelihaaan berfokus pada “Change” atau perubahan. Ini dapat disebabkan : A. Perubahan karena software error ( Corective Maintenance ) B. Perubahan karena software disesuaikan / diadaptasi dengan lingkungan external, misalnya munculnya CPU baru, sistem operasi baru ( Adaptive Maintenance ) C. Perubahan software yang disebabkan customer / user meminta fungsi tambahan, misalnya fungsi grafik, fungsi matematik, dll ( Perfective Maintenance )
t e N
a r d
By
n e H
Page 14 / 146
http://www.hendra-jatnika.web.id
BAB II COMPUTER SYSTEM ENGINEERING Computer system engineering (Rekayasa Sistem Komputer) terdiri atas 2 bagian, yaitu : 1 Hardware engineering 1 Software engineering Setiap disiplin ini berusaha menunjukkan pengembangan sistem berbasis komputer tehnik engineering. Untuk hardware komputer telah sedemikian maju dan relatif jenuh. Sebaliknya software komputer mulai berkembang, dan saat ini menggantikan peranan hardware sebagai elemen sistem yang sulit direncanakan, sedikit kemungkinan untuk berhasil dengan biaya rendah dan waktu yang cepat, serta paling sukar untuk dikelola. Apa Sistem itu ? Sistem adalah sekumpulan elemen yang saling berinteraksi untuk mencapai suatu tujuan. Sedangkan Computer Based System diorganisir untuk mendapatkan beberapa metode, prosedur atau pengontrolan dengan cara mengelola informasi. Elemen-elemen dari sistem berbasis komputer adalah : 1. Software Program komputer, struktur data dan dokumentasi yang saling berhubungan dan memberikan efek pada metode, prosedur dan kontrol yang diinginkan. 2. Hardware Peralatan elektronik, (misalnya CPU, memory) yang memberikan kemampuan komputasi serta peralatan elektromedia (misalnya sensor, motor, pompa) yang memberikan fungsi external. 3. People / Brainware User dan operator dari hardware dan software 4. Database Sekumpulan informasi yang besar, yang diorganisir agar dapat diakses oleh software dan merupakan bagian integral dari fungsi sistem. 5. Prosedur Langkah-langkah yang menetapkan pemakaian khusus untuk setiap elemen sistem.
t e N
a r d
By
n e H
PROCEDURE
DATABASE
INPUT
HARDWARE
OUTPUT
SYSTEM
DOCUMENT
SOFTWARE
PEOPLE
Keterangan :
Page 15 / 146
http://www.hendra-jatnika.web.id
Computer system engineering adalah suatu aktifitas pemecahan masalah fungsi sistem yang diinginkan, ditemukan, dianalisis, dan dialokasikan ke elemen-elemen sistem individu. Computer System Engineering disebut juga Sistem Analis, dimulai dengan : 1. Penetapan tujuan customer 2. Hambatan-hambatan dan representasi fungsi performance yang dapat dialokasikan ke masing-masing elemen sistem. Segera setelah fungsi performance, hambatan dan interface ditetapkan, system engineering selanjutnya melakukan pekerjaan alokasi. Selama pengalokasian fungsi diserahkan kepada satu / lebih elemen sistem (misalnya software, hardware, people, dll) seringkali alokasi alternatif diusulkan dan dievaluasi. Fungsi yang dialokasikan maksudnya adalah menentukan mana yang masuk ke hardware, ke software dan ke brainware Berikut ini adalah kriteria pemilihan konfigurasi sistem berdasarkan alokasi fungsi dan performance ke elemen sistem : 1. Project Consideration - Pertimbangan Proyek 1 Dapatkah konfigurasi dihasilkan dengan biaya dan jadual yang ditetapkan lebih awal ? 2. Business Consideration - Pertimbangan Bisnis 1 Dapatkah konfigurasi memberikan solusi yang paling menguntungkan ? 1 Dapatkah dipasarkan dengan sukses ? Ä Pertimbangan ini yang paling penting. 3. Technical Consideration - Pertimbangan tehnik 1 Apakah ada tehnologi untuk mengembangkan semua elemen sistem ? 1 Dapatkah fungsi performance dijamin ? 1 Dapatkah konfigurasi dipelihara dengan cukup baik ? 4. Manufacturing Evaluation - Evaluasi Pabrikasi 1 Apakah fasilitas dan peralatan manufaktur tersedia ? 1 Apakah ada komponen yang diperlukan dengan segera ? 1 Apakah jaminan kualitas dapat dipercaya ? 5. Human Issues - Hal-hal yang berhubungan dengan manusia 1 Apakah tenaga kerja terlatih untuk pengembangan dan manufaktur tersedia ? 1 Apakah customer mengerti dengan apa yang akan dicapai oleh sistem ? 6. Environmental Interface - Berhubungan dengan lingkungan 1 Apakah konfigurasi yang diusulkan sudah cukup berhubungan dengan lingkungan external dari sistem ? 1 Apakah komunikasi mesin è manusia dan manusia è mesin sudah ditangani dengan baik ? 7. Legal Consideration - Pertimbangan hukum 1 Apakah pertimbangan yang dihasilkan sudah dilindungi oleh hukum ?
t e N
a r d
By
n e H
PERTIMBANGAN HARDWARE Computer System Engineering selalu mengalokasikan satu / lebih fungsi sistem ke hardware komputer. Elemen-elemen hardware 1. CPU - Cenral Processing Units
Page 16 / 146
http://www.hendra-jatnika.web.id
2. Adalah unit yang melakukan pekerjaan aritmatik, logika, dan fungsi pengontrol serta berinteraksi dengan komponen lainnya. Sekarang ini, beberapa arsitektur komputer ditambahkan ko-prosesor untuk melakukan fungsi pengolahan khusus ( fungsi kalkulasi ) sehingga performance CPU dapat ditingkatkan. 3. BUS 4. Adalah alat komunikasi yang menghubungkan elemen satu dengan elemen lainnya untuk pengiriman instruksi, data dan informasi pengontrolan. 5. Memory 6. Memory memberikan tempat penyimpanan instruksi dan data yang dapat diakses langsung / tidak langsung melalui perintah yang dieksekusi oleh CPU dan ko-prosesornya. Memory terbagi menjadi 2 bagian, yaitu : A. Memori Primer / Primary Memory / Main Memory Adalah memory yang terdapat di dalam komputer, terdiri atas 2 bagian yaitu : i. RAM - Random Access Memory Untuk menyimpan data / instruksi yang bersifat temporary ii. ROM - Read Only Memory / Firmware Untuk menyimpan perintah dan / atau data yang permanen. ROM terbagi atas 2 golongan a. PROM - Programmabel Read Only Memory Memory ROM yang dapat ditulis / diprogram dan dapat dihapus dengan cara : 1 EEPROM - Eraseble Electrical Programmabel ROM Dihapus dengan kejutan listrik tertentu 1 UVPROM - Ultra Violet Programmabel ROM Dihapus dengan sinar ultra violet b. MASK ROM ROM yang terjual sudah diprogram pada saat dibuat oleh pabriknya. B. Memory Sekunder Sifat yang menonjol dari memory jenis ini adalah : i. Waktu akses lambat ii. Kapasitas besar sekali dibandingkan dengan memory primer iii. Waktu akses berkisar milidetik dengan kapasitas antara 400.000 sampai 1 billion byte iv. Contoh : Floppy disk, harddisk, hardcard, optical disk
t e N
a r d
By
n e H
APLIKASI HARDWARE Dapat dikelompokan dalam 3 bagian besar, yaitu : 1. Pengelolahan informasi 2. Pengontrolan proses dan aplikasi real time 3. Tambahan intelegensi
REKAYASA HARDWARE Untuk komputer digital yang dikembangkan dari perancangan elektronik, proses perancangannya terdiri dari 3 tahap : 1. Perencanaan dan spesifikasi
Page 17 / 146
http://www.hendra-jatnika.web.id
2. Perencanaan dan implementasi prototype 3. Manufaktur distribusi dan pelayanan Segera / sesudah analisis dan definisi dijalankan, fungsi dialokasikan ke hardware. Fase I : Perencanaan dan Spesifikasi
HARDWARE FUNCTION
DEVELOPMENT PLANNING
DETAILED REQUIRMENT ANALYSIS
REVIEW
REVIEW
HARDWARE SPECIFICATION
COST SCHEDULE
Fase I terdiri dari : 1. Perencanaan pengembangan 2. Analisis hardware Perencanaan pengembangan dilaksanakan untuk menetapkan lingkup-lingkup dari usaha-usaha terhadap hardware, oleh karena itu menimbulkan beberapa pertanyaan, antara lain : 1. Jenis hardware apa yang terbaik untuk fungsi yang ditentukan? 2. Hardware yang mana yang tersedia untuk dijual, bagaimana biayanya, jenis interface yang diperlukan, dan apa yang harus dilakukan untuk merancang dan membangun ?
a r d
Fase II : Perencanaan dan Implementasi Prototype
DESIGN ANALYSIS
REVIEW
By
t e N
n e H
BUILT & TEST PROTOTYPE
REVIEW
MANUFACTURING ANALYSIS
PROTOTYPE ( BELUM SEMPURNA ) DESIGN DRIVING
Kebutuhan analisis dan konfigurasi hardware mulai dirancang, dilakukan tinjauan tehnis demi mendapatkan spesifikasi rancangan yang benar. Komponen mulai dibuat dan prototype mulai diralat. Prototype diuji untuk menjamin bahwa prototype telah memenuhi semua persyaratan. Namun prototype sering menghadapi ketidakmiripan dengan prosedur yang dibuat. Karena itu perlu adanya spesifikasi pabrikasi Fase III : Manufacture Distribution dan Pelayanan
Page 18 / 146
http://www.hendra-jatnika.web.id
NETWORK
MANUFACTURE
REVIEW
QUALITY ASSURANCE
DISTRIBUTION
MAINTENANCE ORANIZATION
SPARE PART
PRODUCTS
Mulai dihasilkan prosedur-prosedur dengan penekanan pada kualitas produk. Dengan mekanisme distribusi produk terhadap fase ini, juga dibentuk bagian perbaikan dan maintenance
PERENCANAAN SISTEM Tahap perencanaan dari siklus hidup software adalah suatu proses definisi, analis, spesifikasi, estimasi dan review. HARDWARE FUNCTIONS
BUSINESS NEEDS
t e N
COST SCHEDULE RESOURCES
SYSTEM DEFINITION
a r d
SOFTWARE FUNCTIONS
By
en
H
SOFTWARE PLAN
SOFTWARE SCOPE
REQUIREMENT ANALYSIS
Definisi sistem merupakan langkah pertama dalam fase perencanaan. Tujuan dari definisi sistem ini adalah : 1. Evaluasi konsep sistem : feasibility, cost benefit, dan businness needs 2. Jelaskan interface, function, dan performance sistem 3. Alokasi fungsi pada hardware, software dan elemen tambahan. Tujuan dari perencanaan software adalah mengestimasi biaya dan waktu pengembangan. Untuk mencapai ini, lingkup software harus dimengerti dengan sempurna, dan sumber harus ditentukan dengan tepat. Analisis kebutuhan software memperjelas : 1. Software interfaces 2. Atribut fungsional 3. Karakteristik performance 4. Kendala desain 5. Kriteria validasi Timbul pertanyaan : 1. Berapa besar usaha yang akan diberikan pda fase perencanaan ? Ä 10 s/d 20 % dari usaha keseluruhan proyek diberikan pada perencanaan dan analisis kebutuhan software.
Page 19 / 146
http://www.hendra-jatnika.web.id
2. Siapa yang mengerjakannya ? Ä Analis yang berpengalaman dan terlatih memperkerjakan hampir semua pekerjaan yang berhubungan dengan fase perencanaan. Untuk proyek yang sangat besar, dapat dibentuk sebuah tim analis. 3. Mengapa begitu sulit ? Ä Konsep yang tidak jelas harus ditransformasikan ke dalam elemen yang jelas.
FEASIBILITY STUDI ( STUDI KELAYAKAN ) Semua proyek layak bila sumber dan waktunya tidak terbatas. Kenyataannya, pengembangan sistem berbasis komputer dibatasi oleh sumber dan waktu. Ada 4 bidang utama yang menjadi konsentrasi dari feasibility studi, yaitu : 1. Economic Feasibility : Evaluasi biaya (cost) dan manfaat (benefit) dalam pengembangan sistem. 2. Tehcnical feasibilitu : Studi tentang fungsi, performance, dan hambatan yang berpengaruh terhadap kemampuan mendapatkan sistem yang baik. 3. Legal Feasibility : Penentuan berbagai pelanggaran, kewajiban yang dapat terjadi dari pengembangan sistem. 4. Alternative : Evaluasi sebagai alternatif untuk mengembangkan sistem
t e N
a r d
ANALISIS COST BENEFIT
n e H
Menggambarkan biaya pengembangan proyek dan mempertimbangkan keuntungan sistem, baik yang tangible maupun intangible (dapat diukur dan tidak dapat diukur). Analis cost benefit ini tergantung dari karakteristik sistem yang akan dikembangkan, ukuran relatif proyek (besar kecil proyek), dan ROI (Return On Invesment) yang diharapkan dari proyek. Keuntungan dari sistem baru selalu dibandingkan dengan keuntungan dari sistem yang ada.
By
Contoh soal : Suatu CAD (Computer Aided Design) akan menggantikan cara manual dalam membuat gambar-gambah tehnik. Misalkan : 1 t = waktu rata-rata menggambar = 4 jam 1 c = biaya gambar perjam = $20 1 n = banyaknya gambar pertahun = 8000 1 p = persentase gambar yang dihasilkan dengan sistem CAD = 60% Penurunan waktu gambar menjadi 1/4 nya dengan adanya sistem CAD. Jadi : Biaya yang dapat ditekan (dihemat) sebesar :
=
1 1 × t × c × n × p = × 4 × 20 × 8000 × 60% = 96,000/thn 4 4
Bila untuk sistem CAD harus dikeluarkan biaya sebesar :
Page 20 / 146
http://www.hendra-jatnika.web.id
1 biaya pengembangan / membeli = $204,000, 1 biaya pemeliharaan = $32,000 per tahun, maka masa pengembalian / payback periode dari proyek CAD ini adalah : Biaya pengeluaran (cost ) = biaya penghematan ( benefit ) 204,000 + x • 32,000 = 96,000 • x 64,000 • x = 204,000 x = 3.2 tahun Ini berarti setelah 3.2 tahun, barulah proyek CAD ini memberikan titik impas (break even). Setelah ini barulah memberikan keuntungan. Grafik :
BIAYA PENGHEMATAN (DALAM RIBUAN)
PENGHEMATAN DENGAN SISTEM CAD
BREAK EVEN POINT M
A
N TU N IT) U F KE R O A P S (
G
AN
307 BIAYA DENGAN SISTEM CAD AN GI U R ) KE S A LOS S ( MA
204
By
t e N
a r d
n e H
TAHUN
PAYBACK PERIODE (MASA PENGEMBALIAN)
3.2
PERENCANAAN SOFTWARE Untuk melaksanakan pengembangan proyek software dan berhasil, kita harus mengerti : 1. Ruang lingkup pekerjaan yang dilakukan 2. Sumber yang diinginkan 3. Usaha dan biaya 4. Jadual yang dikehendaki Perencanaan software adalah : Langkah kedua dalam fase perencanaan, tetapi merupakan langkah pertama dalam proses rekayasa software yang akan memberikan pengertian kepada 4 hal di atas. Perencanaan software mengkombinasikan 2 tugas, yaitu : 1. Riset
Page 21 / 146
http://www.hendra-jatnika.web.id
2. Estimasi Tujuan perencanaan software : Memberikan suatu kerangka yang memungkinkan manajer membuat estimasi yang beralasan tentang sumber, biaya dan jadual. Contoh soal : TUGAS
USAHA, per orang per bulan
Requirement
1.5
Design
3.0
Code
1.0
Test
3.5
Usaha yang dihasilkan
9.0
Dari usaha ini, dihasilkan 2,900 LOC (banyaknya baris program). 200 LOC digunakan simulasi, dan testing tidak termasuk bagian dari software yang dioperasikan. 2700 LOC Produktivitasnya : = 9.0 per orang per bulan = 300 LOC per orang per bulan. Ada 4 orang software engineering yang masing-masing
mampu menghasilkan 4000 LOC per tahun. Bila mereka dipekerjakan dalam 1 team, maka proyek ada 6 jalur komunikasi yang mungkin (communication path). Setiap jalur komunikasi memerlukan waktu yang seharusnya digunakan untuk pengembangan Loding sebesaar 240 LOC per tahun. Bila proyek 1 tahun tersebut mengalami keterlambatan jadwal dan tinggal 1 bulan lagi, perlu penambahan 3 orang lagi kedalam team tersebut. Bila dianggap terjadi pengurangan produktivitas team, untuk setiap jalur komunikasi adalah sama, baik untuk pegawai lama dan baru. Hitung berapa produktivitas team sebelum dan sesudah penambahan 3 orang tersebut, sekaligus jangka waktunya berbeda !!!
t e N
a r d
By
n e H
Jawab : Jalur komunikasi 4 orang à ada 6 jalur (lihat gambar).
Produktivitas sebelum penambahan : = ( 4 × 4,000 ) - ( 240 × 6 ) = 16,000 - 1,440 = 14,560 LOC per tahun Produktivitas setelah penambahan : 1 Jika jalur komunikasinya berbeda : 4000 240 = (4 × 4000) + ( 3 × × 2 ) − (6 × 240 + 15 × x2 ) 12 12 = 16000 + 2000 - ( 1440 + 600 ) = 18000 - 2040 = 16960 1 Jika jalur komunikasinya dianggap sama :
Page 22 / 146
http://www.hendra-jatnika.web.id
= (4 × 4000) + ( 3 ×
4000
× 2 ) − (6 × 240 + 15) 12 = 16000 + 2000 - ( 1440 + 3600 ) = 18000 - 5040 = 12960
PROSES DESAIN SOFTWARE Desain dalam fase pengembangan merupakan langkah pertama, di mana fase pengembangan merupakan fase kedua dalam siklus hidup software. Segera sesudah kebutuhan software ditetapkan, dimulailah fase pengembangan yang terdiri dari 4 langkah berbeda : 1. Desain awal (preliminary design) 2. Detailed Design (Desain primeir) 3. Coding 4. Testing Aliran informasi selama fase pengembangan dapat dilihat pada gambar di bawah ini. FUNCTIONAL REQUIREMENT
INFORMATION FLOW & STRUCTURE
PRELIMINARY DESIGN
SOFTWARE STRUCTURE
DETAILED DESIGN
By
t e N
TESTED MODULS
TESTING
n e H
a r d
SOFTWARE
PROCEDURE
CODE & UNIT TEST
INTEGRATED VALIDATED SOFTWARE
Kebutuhan software & aliran informasi ( Structure Information Software ) memulai langkah desain awal dengan menggunakan 1 dari beberapa metode desain struktur software untuk dikembangkan. Struktur software yang juga disebut Arsitektur Software ini menjelaskan tentang hubungan antar elemen utama dari sebuah program. Desain terinci menterjemahkan elemen-elemen struktural ke dalam penjelasan software ( prosedur software ). Source Code dihasilkan dan pengetesan awal dilakukan selama langkah pengkodean dan pengetesan unit hasilnya berupa model-model program yang sudah ditest. Langkah terakhir dalam fase pengembangan adalah dilakukannya pengetesan integrasi dan validasi. Fase pengembangan paling sedikit menyerap 75% dari biaya software baru. Ini berarti pengambilan keputusan dalam fase ini akan sangat mempengaruhi keberhasilan dalam implementasi software dan kemudahan dalam pemeliharaan software.
Page 23 / 146
http://www.hendra-jatnika.web.id
DEFECT APLICATION MODEL ( DAM )
ERROR YANG DILEWATKAN LANGKAH SEBELUMNYA DARI "PRELIMINARY DESIGN"
PERSENTASE EFISIENSI ERROR YANG DAPAT DIDETEKSI
ERROR YANG DIPERKUAT DENGAN FAKTOR PENGUAT X
ERROR YANG DITERUSKAN KE LANGKAH BERIKUTNYA
ERROR BARU YANG DIHASILKAN
DAM digunakan untuk memberikan gambaran tentang pembentukan dan pendeteksian error selama desain awal dari Desain Terinci dan Pengkodean. Dengan model ini, kita dapat membandingkan besarnya biaya yang dikeluarkan dengan adanya error, baik untuk review maupun tanpa review.
t e N
a r d
By
n e H
Page 24 / 146
http://www.hendra-jatnika.web.id
Contoh DAM tanpa REVIEW : (1) PRELIMINARY DESIGN
(2) DETAILED DESIGN 6
%
10
6
10 0
(3) CODE / UNIT TEST
10
10
37
4*1.5 X=1.5
4
0%
(6) SYSTEM TEST
46
23
46
20%
0
25 (0)
(5) VALIDATED TEST
93 93
27*3 X=3
27
25 (0)
(4) INTEGRATED TEST
23
50%
0
0 (23)
50%
0
0 (47)
11
50%
0 (23)
(12)
Cara Kerja : 2. 6 + ( 4 × 1,5 ) + 25 = 37
4. 93 + 0 + 0
37 × 0% = 0 37 - 0 = 37
93 × 50% = 4650% = 46,5 ≈ 46 93 - 46 = 47
3. 40 + ( 27 × 3 ) + 25 = 116
5. 46 + 0 + 0 = 46
116 × 20% = 2320% = 23,2 ≈ 23 116 - 23 = 93
46 × 50% = 2300% = 23 46 - 23 = 23
et
6. 23 + 0 + 0 = 23 23 × 50% = 1150% = 11,5 ≈ 11 23 - 11 = 12
aN
r d n
He
By
Contoh DAM dengan REVIEW :
2 3 0
70%
10
1
5
2
15
1*1.5
50%
25 (7)
5
24
10*3
60%
25 (14)
6
12 0
50%
0 (36)
(6) SYSTEM TEST
12
24 10
(5) VALIDATED TEST
(4) INTEGRATED TEST
(3) CODE / UNIT TEST
(2) DETAILED DESIGN
(1) PRELIMINARY DESIGN
6 0
50%
0 (12)
Page 25 / 146
0
50%
0 (6)
(3)
3 ERROR LATEN
http://www.hendra-jatnika.web.id
1. ( 10 + 0 ) × 70% = 7
4. 0 + 0 + 24 = 24 24 × 50% = 1200% = 12 24 - 12 = 12
2. 5 + ( 1 × 1,5 ) + 25 = 28,5 28,5 × 50% = 1425% = 14,25 ≈ 14
5. 12 + 0 + 0 = 12
28,5 - 14 = 14,5 ≈ 15
12 × 50% = 600% = 6 12 - 6 = 6
3. ( 10 × 3 ) + 5 + 25 = 60 60 × 60% = 3600% = 26 60 - 36 = 24
6. 6 + 0 + 0 = 6 6 × 50% = 3 6-3=3
KEGIATAN
BIAYA per ERROR
NON REVIEW
REVIEW
Selama desain
1
0x1=0
21 x 1 = 21
Sebelum test ( coding )
5
23 x 5 = 115
36 x 5 = 180
Selama test ( validated & integrated test )
10
82 x 10 = 820
21 x 10 = 210
Setelah dipasarkan ( error laten )
100
11 x 100 = 1100
3 x 100 = 300
2035
711
Total biaya
a r d
t e N
By
n e H
Page 26 / 146
http://www.hendra-jatnika.web.id
Soal Latihan no. 1 : Diketahui : 5 software engineering masing-masing mampu menyelesaikan 4000 LOC per tahun bila bekerja secara individu. Mereka bekerja sama dalam 1 team. Bila proyek 1 tahun tersebut mengalami keterlambatan dan tinggal 1 bulan lagi, perlu tambahan 1 software engineering lagi ke dalam team tersebut. Pengurangan produktivitas team untuk setiap jalur komunikasi adalah sama ( 200 LOC per tahun ) untuk menunjuk adanya proses belajar bagi staff baru. Ditanya : Hitung produktivitas team sebelum dan sesudah penambahan seorang software engineering !!! Jawab : P Sebelum : = ( 4000 x 5 ) - ( 10 x 200 ) = 20000 - 2000 = 18000 LOC / tahun P Sesudah P Jalur sama : 4000 = (5 × 4000 + 1 × × 1) − (10 × 200 + 5 × 200) 12 = { (20000+333,3) - 3000 } = 20333,3 - 3000 = 17333,3 LOC / tahun
P Jalur beda :
n e H
200 × 1) 12 = 20333,3 - 2083,3 = 18250 LOC / tahun
= 20333,3 − (2000 + 5 ×
By
a r d
t e N
Page 27 / 146
http://www.hendra-jatnika.web.id
Soal Latihan No. 2a : Gambar dan buatlah perbandingan biaya, baik untuk Review maupun NonReview dari ilustrasi berikut ini: 1. Pada tahap rancangan awal : A. Kesalahan yang timbul = 10 B. Efisiensi dengan review = 70% 2. Pada tahap rancangan terinci : A. Sebanyak 50%, kesalahan dilewatkan, sisanya diperkuat dengan faktor penguat = 2 B. Kesalahan baru yang muncul = 25 C. Efisiensi dengan review = 50% 3. Pada tahap coding / unit test A. sebanyak 40% kesalahan dilewatkan, dan sisanya diperkuat dengan faktor penguat 3. B. Efisiensi dengan review 80%, dan non review 50%. C. Kesalahan baru yang muncul = 20%. 4. Pada tahap selanjutnya dilakukan perbaikan dengan efisiensi masing-masing = 50% 5. Biaya yang harus ditanggung untuk setiap kesalahan adalah : A. Selama rancangan = 2 satuan harga B. Sebelum test = 5 satuan harga C. Selama test = 20 satuan harga D. Setelah dipasarkan = 60 satuan harga
t e N
a r d
Jawab :
n e H
TABEL PERBANDINGAN BIAYA ANTARA DENGAN REVIEW & NON REVIEW KEGIATAN
By
BIAYA per ERROR
NON REVIEW
Selama desain Sebelum test ( coding ) Selama test ( validated & integrated test ) Setelah dipasarkan ( error laten ) Total biaya
Page 28 / 146
REVIEW
http://www.hendra-jatnika.web.id
Soal Latihan No. 2b : Gambar dan buatlah perbandingan biaya, baik untuk Review maupun NonReview dari ilustrasi berikut ini: 1. Pada tahap rancangan awal : A. Kesalahan yang timbul = 10 B. Efisiensi dengan review = 80% 2. Pada tahap rancangan terinci : A. Sebanyak 60%, kesalahan dilewatkan, sisanya diperkuat dengan faktor penguat = 3 B. Kesalahan baru yang muncul = 20 C. Efisiensi dengan review = 40% 3. Pada tahap coding / unit test A. sebanyak 30% kesalahan dilewatkan, dan sisanya diperkuat dengan faktor penguat 2. B. Efisiensi dengan review 75%, dan non review 45%. C. Kesalahan baru yang muncul = 25%. 4. Pada tahap selanjutnya dilakukan perbaikan dengan efisiensi masing-masing = 60% 5. Biaya yang harus ditanggung untuk setiap kesalahan adalah : A. Selama rancangan = 3 satuan harga B. Sebelum test = 10 satuan harga C. Selama test = 30 satuan harga D. Setelah dipasarkan = 70 satuan harga
t e N
a r d
Jawab :
n e H
TABEL PERBANDINGAN BIAYA ANTARA DENGAN REVIEW & NON REVIEW KEGIATAN
By
BIAYA per ERROR
NON REVIEW
Selama desain Sebelum test ( coding ) Selama test ( validated & integrated test ) Setelah dipasarkan ( error laten ) Total biaya
Page 29 / 146
REVIEW
http://www.hendra-jatnika.web.id
BAB III KONSEP MANAJEMEN PROYEK 3.1
SPEKTRUM MANAJEMEN
Manajemen proyek Perangkat Lunak (PL) yang efektif berfokus pada 3 P, dimana harus berurut yaitu PEOPLE
: Elemen terpenting dari suksesnya proyek
PRODUCT /
: Software yang dikembangkan
PROBLEM PROCESS
: Suatu kerangka kerja dari suatu aktifitas dan kumpulan tugas untuk memgembangkan PL
PROJECT
t e N
: Penggabungan semua kerja untuk membuat
a r dkenyataan produk menjadi (tambahan) n He y B 3.2 PEOPLE ( MANUSIA)
SEI telah mengembangkan suatu model kematangan kemampuan manajemen manusia (People Management Capability Manurity Model ( PM – CMM ) ) untuk mempertinggi kesiapan organisasi PL dalam membuat aplikasi yang semakin kompleks sehingga menarik, menumbuhkan, memotivasi, menyebarkan dan memelihara bakat yang dibutuhkan untuk mengembangkan kemapuan mengembankan PL mereka.
Page 30 / 146
http://www.hendra-jatnika.web.id
Model kematangan manajemen manusia membatasi pada Rekruitmen
Kompensasi
Seleksi
Pemgembangan karir
Manajemen unjuk kerja
Desain kerja & organisasi
Pelatihan
Perkembangan karir tim / kultur
Manusia dalam pengembangan PL terdiri dari : a. Player (Pemain) - Manajer Senior
menentukan
isu
bisnis
yang
mempengaruhi dalam proyek
- Manajer Proyek
- Pelaksana
By
- Pelanggan
t e merencanakan,Nmemotivasi, mengorgaa r d nisir,mengontrol aplikasi/produk n e Hmempunyai ketrampilan teknik untuk merekayasa aplikasi menentukan jenis kebutuhan bagi PL yang akan dibuat
- Pemakai akhir
yang berinteraksi dengan PL yang dibuat
b. Team Leader (Pimpinana Tim) Manajemen proyek merupakan kegiatan manusia intensif sehingga memerlukan praktisi yang cakap.
Page 31 / 146
http://www.hendra-jatnika.web.id
Model Kepemimpinan (MOI yaitu Motivasi, Organisasi, gagasan & Inovasi) menurut Jerry Weinberg. Karakteristik yang menentukan manajer proyek efektif yaitu - Pemecahan Masalah
- Prestasi
- Identitas manajerial
- Pengaruh & pembentukan tim
c. The Software Team ( Tim PL) Sumber daya manusia kepada sebuah proyek yang akan membutuhkan n manusia yang bekerja selama k tahun , ada beberapa
alternatif
untuk
menentukan
t e N
tersebut : -
a r n orang mengerjakan d tugas n e sebanyak m H dengan sedikit By
sumber
fungsional kombinasi
daya
berbeda kerja
&
koordinasi tanggung jawab manajer proyek - n
orang
mengerjakan
tugas
fungsional
berbeda
sebanyak m (m
= 1 tugas fungsional, setiap tim mempunyai sebuah struktur spesifik yang ditentukan untuk semua tim yang bekerja pada sebuah proyek, koordinasi dikontrol
Page 32 / 146
http://www.hendra-jatnika.web.id
oleh tim itu sendiri dan oleh manajer proyek PL ( sistem ini paling produktif) Mantei, mengusulkan 3 organisasi tim yaitu: § Demokrasi terdesentralisasi (DD) Tidak memiliki pimpinan permanen dan koordinator dipilih untuk tugas pendek bila tugas berbeda maka pimpinan berbeda. Keputusan diambil oleh konsensus kelompok dan komunikasi secara horizontal § Terkontrol terdesentralisasi (CD)
t e N
Tim memiliki pimpinan tertentu dan memiliki pimpinan
a r skunder untuk sub-sub dmasalah. Pemecahan masalah n e H dari kelompok dan implentasi merupakan aktifitas By
pemecahan pada sub-sub kelompok. Komunikasi antar kelompok dan orang bersifat horizontal tetapi komunikasi secara vertical berjalan bila hirarki kontrol berjalan . § Terkontrol tersentralisasi (CC) Pemecahan tingkat puncak dan internal tim oleh pimpinan tim. Komunikasi dilakukan secara vertical. 7 faktor proyek yang harus dipertimbangkan dalam rencanakan tim RPL yaitu : 1. Kesulitan pada masalah
Page 33 / 146
http://www.hendra-jatnika.web.id
2. Ukuran program yang dihasilkan (LOC / function) 3. Waktu tim (umur) 4. Tingkat dimana dapat dimodularitasi 5. Kualitas serta keandalan 6. Kepastian tanggal penyampaian 7. Tingkat sosiabilitas / komunikasi Pengaruh Karakteristik Proyek pada Struktur Tim Tipe Tim Tingkat Kesulitan o Tinggi o Rendah Ukuran o Besar o Kecil Umur Tim o Singkat o Panjang Modularitas o Tinggi o Rendah Keandalan o Tinggi o Rendah Tanggal Pengiriman o Ketat/pasti o Longgar Sosiabilitas o Tinggi o Rendah
By
DD
CD
CC
x
x
x
x
x
x
x
x
x
t e N
a r d
en
H
x
x
x x
x x x
x
x
x x
Page 34 / 146
x
http://www.hendra-jatnika.web.id
Constantine, mengusulkan 4 paradigma organisasional bagi tim RPL 1. Paradigma Tertutup Membentuk hirarki otoritas tradisional ( mirip tim CC) tetapi kurang inovatif 2. Paradigma Random Membentuk tim longgar & tergantung pada inisiatif individual tim, untuk inovasi sangat baik(unggul) bila unjuk kerja tim teratur. 3. Paradigma Terbuka Membentuk tim dengan cara tertentu sehingga banyak
t e Nmasalah yang kompleks kontrol, inovasi banyak . Cocok untuk a r d tetapi tidak seefesien timn lainnya e H 4. Paradigma Sinkron By Mengorganisasikan tim untuk bekerja pada bagian-bagian kecil masalah dengan komunikasi aktif pada tim d. Coordinatian & Communication Issue (masalah koordinasi & komunikasi) Proyek PL mengalami kesulitan dikarenakan : ü Skala usaha pengembangan yang besar sehingga kesulitan dalam mengkoordinasi anggota tim & Kompleksitas yang semakin besar
Page 35 / 146
http://www.hendra-jatnika.web.id
ü Ketidakpastian mengakibatkan perubahan terus menurus pada proyek ü Interoperabilitas
merupakan
ciri
dari
sistem
dan
menyesuaikan dengan batasan sistem Kraul & Streeter menguji sekumpulan teknik koordinasi proyek yang dibagi atas ü Pendekatan impersonal, formal penyampaian & dokumen RPL (memo, laporan dll) ü Prosedure
interpersonal,
formal
aktifitas jaminan
t e N
kualitas yang diterapkan kepada produk kerja RPL
ü
a r (status pengkajian , perancangan d & inpeksi kode) n He informal pertemuan kelompok Prosedure interpersonal, y B untuk menyebarkan informasi & pemecahan masalah serta pengembangan staf
ü Komunikasi
teknik,
surat
elektronis,
web
sites,
teleconferens, papan buletin elektronik ü Jaringan interpersonal diskusi informal pada orang diluar proyek untuk mendapatkan pengalaman sehinnga mendukung kerja proyek
Page 36 / 146
http://www.hendra-jatnika.web.id
3.3 PROBLEM / PRODUCT Analisis yang mendetail mengenai kebutuhan PL akan memberikan informasi untuk menghitung perkiraan kuantitatif & perencanaan organisasi. Tetapi itu sulit karena informasi yang diberikan customer tidak lengkap. Ruang lingkup masalah dibatasi dengan : -
Konteks PL yang dibangun memenuhi sistem, produk / konteks bisnis yang lebih besar serta batasan yang menentukan hasilnya
-
-
t e N
Tujuan informasi
a r Objek pelanggan yang dihasilkan d sbg output dr PL yang dapat n He digunakan sebagai input y B Fungsi & unjuk kerja PL digunakan untuk mentransformasikan input menjadi output
Pernyataan ruang lingkup dibatasi (data jumlah pemakai simultan, ukuran pengiriman, waktu mak respon ), batasan /& jangka waktu dicatat (biaya produk membatasi jumlah memori) & factor mitigasi (algoritma yang dibutuhkan software aplikasi (pemograman))
Page 37 / 146
http://www.hendra-jatnika.web.id
Dekomposisi Masalah / pembagian masalah diterapkan pada : - Fungsionalitas yang disampaikan - Proses yang dipakai
3.4 PROCESS Proses PL memberikan suatu kerangka kerja dimana rencana komprehensip bagi pengembangan PL yang dapat dibangun dengan - Sejumlah
kumpulan
tugas
yang
berbeda,
kemampuan
penyampaian & jaminan kualitas - Aktifitas
pelindung,
jaminan
1.
y B Sekunsial Linier
PL, t e
manajemen
N a r
konfigurasi PL & pengukuran Model PROSES :
kualitas
d n e
H
Classic Life Cycle / model air terjun 2. Prototipe Perencanaan kilat untuk konstruksi oleh prototype 3. Rapid Aplication Development (RAD) Model sekunsial linier yang menekankan siklus pengembangan yang sangat pendek dengan pendekatan konstruksi berbasis komponen 4. Inkremental (Pertambahan) Menggabungkan elemen-elemen model sekunsial linier dengan filosopi prototype iterative khusus untuk staffing
Page 38 / 146
http://www.hendra-jatnika.web.id
5. Spiral Merangkai sifat iterative dari prototype dengan cara kontrol & aspek sistematis dari sekunsial linier 6. Rakitan Komponen Paradigma orientrasi obyek menekankan kreasi kelas yang mengenkapsulasi data & algoritma yang dipakai untuk memanipulasi data (gabungan dengan karakter spiral) 7. Perkembangan Komponen Sering dipakai untuk mengembangkan aplikasi client server Aktifitas dibagi menjadi : - dimensi sistem : desain, assembly & pemakai - dimensi komponen : desain & realisasi
t e N
8. Metode Formal Mengkhususkan, mengembangkan, & menverifikasi sistem berbasis komputer dengan notasi matematis yang tepat (Clean room RPL)
a r d
By
n e H
9. Teknik Generasi Keempat Serangkaian alat bantu PL yang secara otomatis memunculkan kode sumber yang berdasarkan pada spesifikasi perekayasaan 1,2 3 (konvensional) sisanya evolusioner Harus ditentukan model paling banyak memawakili pelanggan, karakteristik produk & lingkungan proyek Serangkaian aktifitas kerja PL : 1. Komunikasi pelanggan 2. Perencanaan 3. Analisa Resiko 4. Rekayasa
Page 39 / 146
http://www.hendra-jatnika.web.id
5. Konstruksi dan rilis 6. Evaluasi Pelanggan Dekomposisi Proses Bila batasan waktu yang ketat diberikan dan masalah dapat dipecah-pecah, model RAD mungkin pilihan yang paling tepat. Tugas kerja yang actual bervariasi sehingga dekomposi proses dimulai pada saat bagaimana menyesesaikan kerja proses secara umum.
t e N
3.5 PROYEK
a r d pada aturan 90-90 yaitu pada Profesional industri sering mengacu n e H saat mendiskusikan proyek By PL yang sukar maka 90 % dr sistem
yang pertama menyerap 90 % dari usaha & waktu yang diberikan. 10 %terakhir mengambil 90 % lain dari usaha & waktu yang diberikan. Dr penyataan tersebut proyek mengalami kesulitan yaitu 1. Kemajuan mengalami kecacatan 2. Tidak ada cara untuk mengkalibrasi kemajuan karena tidak memperoleh matrik kuantitatif 3. Rencana proyek belum dirancang untuk menakomodasi sumber daya yang diperlukan pada akhir sebuah proyek
Page 40 / 146
http://www.hendra-jatnika.web.id
4. Resiko-resiko belum mempertimbangkan secara eksplisit serta belum dibuat rencana untuk mengurangi, mengatur & memonitor 5. Jadual yang ada tidak realistis & cacat
Untuk mengatasi masalah tersebut maka diperlukan waktu pada awal proyek untuk membangun rencana yang realistis guna memonitor rencana proyek selama berjalan & pada keseluruhan proyek serta mengontrol kualitas serta perubahannya.
t e N
a r d
By
n e H
Page 41 / 146
http://www.hendra-jatnika.web.id
BAB 4 PROSES PERANGKAT LUNAK & METRIK PROYEK
Lord Kelvin berkata : Bila Anda dapat mengukur apa yg sedang Anda bicarakan mengekspresikannya dalam angka, berarti Anda memahaminya.
dan
Tujuan pengukuran perangkat lunak adalah : • Untuk menyatakan kualitas produk • Untuk menilai kulitas manusia yg terlibat dalam pembuatan produk. • Untuk menilai keuntungan pemakaian metode & alat bantu yg baru. • Sebagai dasar untuk melakukan perkiraan. • Untuk membantu penyesuaian pemakaian alat bantu yg baru atau pelatihan tambahan. Metrik perangkat lunak mengacu pada pengukuran perangkat lunak komputer. Pengukuran digunakan untuk membantu perhitungan, kontrol kualitas, perkiraan produktivitas, & kontrol proyek, serta untuk membantu mengambil keputusan taktis pada saat proyek sudah berjalan.
t e N
a r d
n e H INDIKATOR PENGUKURAN, METRIK, DAN y B Measure (mengukur) :
Mengindikasikan kuantitatif dari luasan, jumlah, dimensi, kapasitas, atau ukuran dari atribut sebuah proses atau produk. Measurement (pengukuran) : Kegiatan menentukan sebuah measure (pengukuran) Metrics (metrik) : Ukuran kuantitatif dari tingkat dimana sebuah sistem, komponen, atau proses memiliki atribut tertentu. RPL mengumpulkan pengukuran & mengembangkan metrik sehingga diperoleh suatu indicator. Indicator (indicator) : Sebuah metrik atau kombinasi dari metrik yg memberikan pengetahuan kedalam proses PL, sebuah proyek PL, atau produk itu sendiri. Page 42 / 146
http://www.hendra-jatnika.web.id
Indikator memberikan pengetahuan yang memungkinkan manajer proyek atau perekayasa PL menyesuaikan proses, proyek, dan produk, untuk membuat semuanya menjadi lebih baik. METRIK DALAM PROSES DAN DOMAIN PROYEK • METRIK PROSES • METRIK PROYEK Metrik harus dikumpulkan sehingga indikator proses dan indikator produk (proyek) dapat dipastikan. Indikator proses memungkinkan : 1. sebuah organisasi rekayasa PL memperoleh pengetahuan tentang reliabilitas sebuah proses yg sedang berlangsung 2. manajer & pelaksana memperkirakan apa yg harus dikerjakan dan yang tidak.
t e Indikator proyek memungkinkan manajer proyek N PL : a 1. memperkirakan status sebuah proyek yg sedang berlangsung r d 2. menelusuri resiko-resiko potensial n e 3. menemukan area masalah sebelum masalah ‘menjadi semakin kristis’. H 4. menyesuaikan aliran kerja atau tugas-tugas. y B 5. mengevaluasi kemampuan tim proyek untuk mengontrol kualitas hasil kerja RPL.
METRIK PROSES Metrik proses digunakan untuk tujuan strategis. Cara untuk meningkatkan proses perangkat lunak : • mengukur atribut tertentu dari proses • mengembangkan serangkaian metrik yg berarti • menggunakan metrik itu untuk memberikan indikator yg akan membawa kepada sebuah strategi pengembangan.
Page 43 / 146
http://www.hendra-jatnika.web.id
Produk Karakteristik Pelanggan
Kondisi Bisnis Proses
Manusia
Teknologi
Lingkungan Pengembangan
Gbr. Determinan untuk kualitas dan efektivitas organisasional PL. Mengukur reliabilitas proses PL secara tidak langsung yaitu dengan mengambil serangkaian metrik berdasarkan keluaran yg dapat diambil oleh proses. Keluaran menyangkut : • pengukuran kesalahan yg ditemukan sebelum pelepasan PL. • cacat yg disampaikan & dilaporkan oleh pemakai akhir. • produk kerja yg dikirim. • usaha manusia yg dilakukan • waktu kalender yg digunakan • konfirmasi jadwal • dll
t e N
a r d
By
n e H
Pada saat organisasi menjadi lebih nyaman dengan kumpulan & manfaat metrik proses, derivasi dari indikator sederhana memberikan suatu cara kepada suatu pendekatan yg lebih teliti yg disebut SSPI (Statistical Software Process Improvement). SSPI menggunakan analisis kegagalan PL untuk mengumpulkan informasi seputar semua kesalahan & cacat yg terjadi pada saat sebuah aplikasi, sistem, atau produk dikembangkan dan dipakai. Kesalahan : Ketidaksempurnaan pd sebuah produk kerja yg ditemukan oleh perekayasa PL sebelum PL itu disampaikan kepada pemakai akhir.
Page 44 / 146
http://www.hendra-jatnika.web.id
Cacat : Ketidaksempurnaan pd sebuah produk kerja yg ditemukan oleh perekayasa PL setelah PL itu disampaikan kepada pemakai akhir. Analisis kegagalan bekerja dengan cara sbb. : 1. Semua kesalahan & cacat dikategorikan dari awal 2. Biaya untuk mengkoreksi setiap kesalahan & cacat dicatat. 3. Jumlah kesalahan & cacat dari setiap kategori dihitung dan ditata dalam urutan naik. 4. Biaya keseluruhan dari kesalahan & cacat dalam setiap kategori dihitung. 5. Data resultan dianalisis untuk menemukan kategori yg menelan biaya besar. 6. Rencana dikembangkan untuk memodifikasi proses guna mengeliminasi kelas kesalahan & cacat yg paling membutuhkan banyak biaya. Berdasarkan langkah 1&2 diatas, ditemukan ada 8 penyebab kerusakan dan sumbernya : • Sumber spesifikasi/persyaratan : a. Logic 20% b. Penanganan data 10,5% c. Standar 6,9%
t e N
a r d
By
Sumber desain : a. Spesifikasi 25,5%
n e H
• Sumber kode : a. Interface perangkat lunak 6,0% b. Interface perangkat keras 7,7% c. Pemeriksaan kesalahan 10,9% d. Interface pemakai 11,7%
METRIK PROYEK Tujuan metrik proyek : 1. untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yg diperlukan untuk menghindari penundaan serta mengurangi masalah & resiko potensial.
Page 45 / 146
http://www.hendra-jatnika.web.id
2. untuk memperkirakan kualitas produk pada basis yg berlaku, dan bila dibutuhkan, memodifikasi pendekatan teknis untuk meningkatkan kualitas. Pengukuran proyek PL bersifat taktis, yaitu bahwa metrik proyek & indikator yg berasal dari pengukuran digunakan oleh manajer proyek dan tim PL untuk mengadaptasi aliran kerja proyek & aktifitas teknis. Selagi sebuah proyek berjalan, pengukuran usaha dan waktu kalender yg digunakan dibandingkan dengan perkiraan awal (dan jadwal proyek). Manajer proyek menggunakan data tersebut untuk memonitor & mengontrol kemajuan. Selagi PL berjalan dari spesifikasi ke perancangan, metrik teknik dikumpulkan untuk memperkirakan kualitas desain serta memberikan indikator yg akan mempengaruhi pendekatan yg akan diambil untuk memunculkan kode & modul serta pengujian integrasi (integrated test).
t e N
a r d
Kualitas meningkat ----à kesalahan menjadi minimal
By
n e H
Biaya berkurang
Kesalahan berkurang --à jumlah kerja ulang berkurang Model lain dari metrik proyek mengusulkan bahwa setiap proyek seharusnya mengukur : • input ( pengukuran sumber daya) • output (pengukuran kemampuan penyampaian atau produk kerja yg diciptakan selama proses RPL) • hasil (pengukuran yg menunjukkan kemampuan penyampaian)
PENGUKURAN PERANGKAT LUNAK Pengukuran perangkat lunak dibedakan menjadi dua yaitu : • Pengukuran langsung (direct) o Metrik Size-Oriented • Pengukuran tidak langsung (indirect) o Metrik Function-Oriented o Metrik Function Point Page 46 / 146
http://www.hendra-jatnika.web.id
Yang diukur pada pengukuran langsung adalah : • Biaya • Pengaruh • Jumlah baris perintah (LOC) yg diproduksi • Kecepatan eksekusi • Ukuran memori • Kesalahan Yang diukur pada pengukuran tidak langsung adalah : • fungsi • kualitas • kompleksitas • efisiensi • keandalan • kemampuan pemeliharaan
t e N
Metrik Size-Oriented Proyek LOC alpha 12,100 betha 27,200 gamma 20,200
a r d Kesalahan Usaha Dolar halaman n e 365 134 24 168 H 62 y 440 1224 321 43 B 314 1050 256
cacat 29 86 64
Manusia 3 5 6
Produktivitas = KLOC / usaha Kualitas = kesalahan / KLOC Biaya = biaya / KLOC Dokumentasi = halaman / KLOC Metrik size-oriented tidak diterima sebagai cara terbaik untuk mengukur proses pengembangan perangkat lunak. Sebagian besar berkisar di seputar pemakaian LOC.
Page 47 / 146
http://www.hendra-jatnika.web.id
Metrik Function-Oriented Metode pendekatan yg digunakan dapat disebut : Function Point (FP). FP dihitung dgn melengkapi tabel dibawah ini : Faktor pembobotan Parameter pengukuran
jumlah
sederhana
ratarata
kompleks
Jumlah input pemakai
X
3
4
6
=
Jumlah output pemakai
X
4
5
7
=
Jml penyelidikan pemki
X
3
4
6
=
Jumlah file
X
7
10
15
=
Jml interface internal
X
6
7
t10 e N
=
a r d
Total --------------------------------------------------------------------------------------à
n e H
FP = jumlah total x [0,65 + 0,01 x jumlah(fi) ]
By
Jumlah(fi) didapat dari jumlah range jawaban dari 14 pertanyaan berikut : 1. 2. 3. 4. 5.
apakah sistem membutuhkan backup & recovery yg reliable ? apakah komunikasi data dibutuhkan ? apakah fungsi pemrosesan didistribusikan ? apakah kinerja penting apakah sistem akan berjalan pd lingkungan operasional yg sudah ada yg paling banyak digunakan ? 6. apakah sistem membutuhkan entry data online ? 7. apakah entry data online membutuhkan ada transaksi input terhadap layar atau operasi ganda 8. apakah file master diperbarui secara online ? 9. apakah input, output, file, atau inquery kompleks ? 10.apakah pemrosesan internal kompleks ? 11.apakah kode didesain untuk dapat dipakai kembali ? 12.apakah desain melibatkan konversi dan instalasi 13.apakah sistem didesain untuk instalasi ganda dalam organisasi berbeda ?
Page 48 / 146
http://www.hendra-jatnika.web.id
14.apakah aplikasi didesain untuk memfasilitasi perubahan & mempermudah pemakai untuk menggunakannya ? range jawaban (skala) untuk pertanyaan diatas antara 0 s/d 5 : 0 : tidak berpengaruh 1 : kurang penting 2 : cukup penting 3 : rata-rata 4 : penting 5 : sangat penting Lima faktor penting yg mempengaruhi produktivitas perangkat lunak menurut Basili dan Zelkowitz : 1. faktor manusia 2. faktor masalah 3. faktor proses 4. faktor produk 5. faktor sumber daya
t e N
a r d
Faktor – faktor untuk mengukur kualitas perangkat lunak (4 metrik kualitas): 1. Cara yang benar 2. Maintanabilitas 3. Integritas 4. Usebilitas
By
n e H
Faktor – faktor yang mempengaruhi biaya pengembangan PL : 1. kemampuan programmer dan tenaga kerja 2. kekompleksan produk 3. ukuran produk 4. waktu yang tersedia 5. keandalan yang diperlukan 6. teknologi yang dipergunakan
Page 49 / 146
http://www.hendra-jatnika.web.id
BAB 5 PERENCANAAN PROYEK PERANGKAT LUNAK
Proses manajemen proyek perangkat lunak dimulai dengan kegiatan project planning (perencanaan proyek). Yang pertama dari aktifitas ini adalah estimation (perkiraan). Estimasi membawa resiko yang inheren (dari diri sendiri) dan resiko inilah yang membawa ketidakpastian. Yang mempengaruhi estimasi : - Project complexity (kompleksitas proyek) - Project size (ukuran proyek) - Struktural uncertainty (ketidakpastian struktural) Tujuan Perencanaan Proyek Perangkat Lunak : menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan terhadap sumber daya, biaya dan jadwal pada awal proyek yang dibatasi oleh waktu.
t e N
a r d
n e H
Aktifitas Perencanaan Proyek PL 1. Menentukan ruang lingkup PL 2. Mengestimasi sumber daya yang dibutuhkan
By
RUANG LINGKUP PL Ruang lingkup PL menggambarkan : fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi yang digambarkan dlm statemen ruang lingkup dievaluasi untuk memberikan awalan yang lebih detail pada saat dimulai estimasi. Kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Batasan mengidentifikasi batas yang ditempatkan pada PL oleh perangkat keras eksternal, memori atau sistem lain.
Page 50 / 146
http://www.hendra-jatnika.web.id
Informasi yang dibutuhkan (awal pertemuan antara pelanggan dan pengembang) * Pertanyaan berfokus pada pelanggan, tujuan keseluruhan serta keuntungan. - Siapa di belakang permintaan kerja ini? - Siapa yang akan memakai solusi ini? - Apakah keuntungan ekonomi dari solusi yang sukses? - Adakah sumber daya lain bagi solusi ini? * Pertanyaan yang memungkinkan analis memahami masalah lebih baik dan pelanggan menyuarakan persepsi tentang sebuah solusi. - Bagaimana Anda (pelanggan) menandai output yg baik yg akan dihasilkan oleh sebuah solusi yg baik? - Masalah apa yang dituju solusi ini? - Dapatkah anda menggambarkan lingkungan dimana solusi akan dipakai? - Adakah batasan atau isu kinerja khusus yg akan mempengaruhi
t e PL berinteraksi dengan elemen sistem berbasis N komputer. Konsep sebuah a r interface diinterpretasi untuk menentukan: d n 1. Hardware yg mengeksekusiePL dan device yg dikontrol secara tidak H langsung oleh PL y B 2. Software yg sudah ada dan harus dihubungkan dengan PL yg baru 3. Manusia yg menggunakan PL melalui keyboard atau perangkat I/O lain 4. Prosedur SUMBER DAYA 1. Manusia 2. Perangkat Lunak Kategori yg diusulkan BEUNATAN - Komponen Off-the-self - Komponen Full-Experience - Komponen Partial-Experience - Komponen Baru 3. Lingkungan (Software Engineering Environment - SEE), menggabungkan PL dan Perangkat Keras.
Page 51 / 146
http://www.hendra-jatnika.web.id
Estimasi biaya dan usaha dapat dilakukan dengan cara : 1. Menunda estimasi sampai akhir proyek. 2. Berdasarkan estimasi pada proyek yg mirip sebelumnya. 3. Menggunakan 'teknik dekomposisi' yg relatif sederhana u/ estimasi biaya dan usaha proyek. 4. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya PL. Akurasi estimasi proyek PL didasarkan pada : 1. Tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk yg akan dibuat. 2. Kemampuan mengestimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar. 3. Tingkat dimana rencana proyek mencerminkan kemampuan tim PL. 4. Stabilitas syarat produk serta lingkungan yg mendukung usaha pengembangan PL.
t e N
a r d
n e H
Putnam dan Myers mengusulkan 4 masalah penentuan ukuran : - Fuzzy-logic sizing (logika kabur) Perencana harus mengidentifikasi tipe aplikasi, membuat besarannya dalam skala kuantitatif kemudian dibandingkan dengan rentang orisinil. - Function point sizing Perencana mengembangkan estimasi berdasarkan karakteristik domain informasi. - Standard component sizing PL dibangun dari sejumlah 'komponen standar' yg umum (subsistem, modul, laporan, program interaktif). - Change sizing Digunakan jika PL yang ada harus dimodifikasi dengan banyak cara sebagai bagian dari proyek.
By
Page 52 / 146
http://www.hendra-jatnika.web.id
Data baris kode (LOC) dan titik fungsi (FP) pada estimasi proyek digunakan sbg : 1. variabel estimasi yg dipakai untuk mengukur masing-masing elemen PL. 2. metrik baseline yg dikumpulkan dari proyek yg lalu dan dipakai dengan variabel estimasi untuk mengembangakan proyeksi kerja dan biaya. Expected Value untuk variabel estimasi : EV = (Sopt + 4Sm + Spess) / 6 EV = Expected value Sopt = Estimasi optimistik Sm = Estimasi paling sering Spess = Estimasi pesimistik Apakah estimasi ini benar ? ' Kita tidak yakin!' Bagaimanapun canggih teknik estimasi harus di-cross-check dengan pendekatan lain. Contoh estimasi berbasis LOC
t e N
a r d
n e H
PL CAD akan menerima data geometri dua dan tiga demensi dari seorang perekayasa yang akan berinteraksi dan mengontrol sistem CAD melalui suatu interface pemakai. Kajian spesifikasi sistem menunjukkan bahwa PL akan mengeksekusi Workstation dan harus berinteraksi dengan berbagai periperal grafis komputer spt mouse, digitizer dan printer laser.
By
Diketahui : Perhitungan LOC untuk fungsi analisis geometri 3D (3DGA) : optimis : 4600 most likely : 6900 pesimistik : 8600 EV = (4600 + 4*6900 + 8600) / 6 = 6800 LOC
Page 53 / 146
http://www.hendra-jatnika.web.id
Jumlah tersebut dimasukkan ke dalam tabel, begitu juga untuk perhitungan yang lain. Sehingga diperoleh : Tabel perkiraan (estimasi) untuk metode LOC Fungsi LOC terestimasi interface pemakai & fasilitas kontrol (UICF) analisis geometrik dua demensi (2DGA) analisis geometrik tiga demensi (3DGA) manajemen databse (DBM) fasilitas display grafis komputer (CGDF) kontrol periperal (PC) modul analisis desain (DAM)
2.300 5.300 6.800 3.350 4.950 2.100 8.400
baris kode terestimasi
33.200
Jika : Produktifitas rata-rata organisasional = 620 LOC/person-month Upah karyawan = $8.000 per bulan Biaya per baris kode = $13
t e N
a r d
Maka :
By
n e H
Tingkat produktifitas = jumlah titik fungsi jumlah orang-bulan Jumlah karyawan
= 33200 LOC 620 LOC/bln
= 53,5 ≈ 54 orang
Estimasi biaya proyek berdasar LOC = 33.200 LOC * $ 13 = $ 431.600 Estimasi biaya proyek berdasar upah = 54 orang * $8.000 = $432.000
Page 54 / 146
http://www.hendra-jatnika.web.id
Estimasi berbasis FP (Function Point) Dekomposisi untuk perhitungan berbasis FP berfokus pada harga domain info daripada fungsi PL. Perencana proyek memperkirakan input, output, inquiry, file dan interface eksternal. Untuk tujuan perkiraan tersebut faktor pembobotan kompleksitas diasumsikan menjadi rata-rata. Setiap faktor pembobotan kompleksitas diestimasi dan faktor penyesuaian kompleksitas dihitung seperti dibawah ini : Faktor Harga Backup and recovery 4 Komunikasi data 2 Pemrosesan terdistribusi 0 Kinerja kritis 4 Lingkungan operasi yang ada 3 Entri data on-line 4 Transaksi input pada layar ganda 5 File master yang diperbarui on-line secara on-line 3 Nilai kompleks domain informasi 5 Pemrosesan internal yang kompleks 5 Kode yg didesain untuk dapat dipakai lagi 4 Konversi/instalasi dalam disain 3 Instalasi ganda 5 Aplikasi yg didesain bagi perubahan 5 Faktor penyesuaian kompleksitas 1.17 TOTAL 53.17
t e N
a r d
By
n e H
Page 55 / 146
http://www.hendra-jatnika.web.id
Perkiraan harga domain informasi : Tabel perkiraan harga domain informasi nilai domain informasi jumlah jumlah jumlah jumlah jumlah
input output inquiry file interface eksternal
opt
likely
pess
20 12 16 4 2
24 15 22 4 2
30 22 28 5 3
jumlah estimasi 24 16 22 4 2
jumlah total
jumlah FP
4 5 4 10 7
96 80 88 40 14
318
jumlah estimasi (lihat rumus EV) bobot (lihat kembali bab 4) jumlah FP = jumlah estimasi * bobot Total faktor pembobotan = ΣFi = 53.17 Total FP = 318
By
t e N
a r d
n e H
FP terestimasi = jumlah total * ( 0.65 + 0.01 * ΣFi) = 318 * ( 0.65 + 0.01 * 53.17 ) = 375 Diketahui : Produktifitas Upah Biaya FP
bobot
= 6.5 LOC/pm (dari historis) = $ 8.000/m = $ 8.000 = $ 1.230 65 LOC
Estimasi biaya proyek = Biaya FP * FP terestimasi = $ 1.230 * 375 = $ 461.250
Page 56 / 146
http://www.hendra-jatnika.web.id
Usaha terestimasi = Total biaya upah/p
= $ 461.250 $ 8.000
= 58 p/m
MODEL COCOMO Barry Boehm memperkenalkan hirarki model estimasi PL dengan nama COCOMO (COnstructive COst MOdel = Model Biaya Konstruktif) yang berbentuk sbb : 1. Model COCOMO Dasar Menghitung usaha pengembangan PL (dan biaya) sbg fungsi dari ukuran program yg diekspresikan dalam baris kode yg diestimasi (LOC). 2. Model COCOMO Intermediate Menghitung usaha pengembangan PL sbg fungsi ukuran program dan serangkaian 'pengendali biaya' yg menyangkut penilaian yg subyektif thd produk, perangkat keras, personil dan atribut proyek. 3. Model COCOMO Advance Menghubungkan semua karakteristik versi intermediate dg penilaian thd pengaruh pengendali biaya pd setiap langkah (analis, perancangan, dll) dari proses rekayasa PL.
t e N
a r d
By
n e H
Model COCOMO mendefinisikan 3 kelas proyek PL yi : 1. Model Organik Ukuran proyek relatif kecil, PL yang dibuat atau dikembangkan lebih simpel dengan aplikasi kerja yg baik. Misal program analisis termal yang dikembangkan untuk kelompok transfer panas. 2. Model Semi Detached Ukuran proyek dan kekompleksan perangkat cukup besar dengan pengalaman kerja campuran (ada yg telah berpengalaman dan ada yg belum berpengalaman). Misal sistem pemrosesan transaksi dengan syarat tertentu untuk perangkat keras terminal dan perangkat lunak database. 3. Model Embedded Ukuran proyek dan kekompleksan PL yg dikembangkan atau dikerjakan besar. Misal perangkat lunak kontrol penerbangan untuk pesawat udara. Page 57 / 146
http://www.hendra-jatnika.web.id
Pesamaan COCOMO Dasar bb E = ab (KLOC) db D = cb E Dimana : E = Effort (usaha yang diaplikasikan - pm) D = waktu pengembangan (m) KLOC = jumlah perkiraan baris kode (dalam ribuan) ab, bb, cb, db = koefisien (lihat tabel) Tabel Model COCOMO Dasar Proyek PL ab bb organik 2.4 1.05 semi-detached 3.0 1.12 embedded 3.6 1.20
cb 2.5 2.5 2.5
t e N
a r d
n e H
db 0.38 0.35 0.32
y B Model dasar ini dapat diperluas dengan mempertimbangkan kumpulan 'atribut pengendali biaya' yg dikelompokkan dalam 4 kategori utama : 1. Atribut produk - ukuran keandalan proyek - ukuran dari aplikasi database - kekompleksan produk 2. Atribut perangkat keras - kendala performansi run-time - kendala memori - lingkungan dari violability dari virtual memori - waktu perputaran yg diperlukan 3. Atribut personil - kemampuan sistem analis - kemampuan software engineering - pengalaman aplikasi Page 58 / 146
http://www.hendra-jatnika.web.id
- pengalaman virtual mesin - pengalaman bahasa pemrograman 4. Atribut proyek - pemakaian alat bantu PL - metode aplikasi software engineering - jadwal pengembangan Masing-masing dari 15 atribut di atas dirata-rata dlm sebuah skala 6 titik dg rentang dari 'sangat rendah' ke 'sangat tinggi' (dlm kepentingan atau harga). Persamaan COCOMO Intermediate bi E = ai (KLOC) * EAF
t e N
dimana : EAF = Effort Adjusment Factor (faktor penyesuaian usaha) yg mempunyai range antara 0.9 sampai 1.4 ai, bi = koefisien (lihat tabel)
a r d
By
n e H
Tabel Model COCOMO Intermediate Proyek PL ai bi organik 3.2 1.05 semi-detached 3.0 1.12 embedded 2.8 1.20
Page 59 / 146
http://www.hendra-jatnika.web.id
Contoh estimasi model COCOMO Kita aplikasikan model dasar pada contoh PL CAD sebelumnya dengan koefisien seperti pada tabel bb E = ab (KLOC) E = 2.4 (KLOC)1.05 = 2.4 (33.2)1.05 = 95 pm Harga ini jauh lebih tinggi dibanding estimasi sebelumnya karena model COCOMO mengasumsikan tingkat LOC/pm yang jauh lebih rendah.
t e N
Untuk menghitung durasi proyek : db D = cb E 0.38
D = 2.5 (E) = 2.5 (95)0.38 = 12.3 bulan
By
a r d
n e H
Harga durasi proyek memungkinkan perencana untuk menentukan jumlah orang yang disetujui (N) N = E/D = 95/12.3 = 7,7 ≈ 8 orang Kenyataannya, perencana dapat memutuskan hanya menggunakan 4 orang saja dan pemperpanjang durasi proyek. Catatan : Hubungan antara usaha dan waktu tidak linier.
Page 60 / 146
http://www.hendra-jatnika.web.id
KEPUTUSAN MAKE-BUY Pada aplikasi PL, dari segi biaya sering lebih efektif membeli dari pada mengembangkan sendiri. Manajer RPL dihadapkan pada keputusan make-buy dengan pilihan : 1. PL dapat dibeli (atau lisensi) off-the-self. 2. Komponen PL full-experience dan partial-experience, dapat diperoleh dan kemudian dimodifikasi dan integrasi untuk memenuhi kebutuhan sendiri. 3. PL dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi pembeli. Untuk produk PL yang mahal, langkah-langkah di bawah ini dapat dipetimbangkan: 1. Kembangkan spesifikasi untuk fungsi dan kinerja PL yg diperlukan. 2. Perkirakan biaya internal untuk pengembangan dan tanggal penyampaian. 3a. Pilih tiga atau empat calon aplikasi yang paling cocok dengan aplikasi anda. 3b. Pilih komponen yang reusable yg dapat membantu konstruksi aplikasi yg diperlukan. 4. Kembnagkan sebuah matriks perbandingan untuk membandingkan calon PL. 5. Evaluasi masing-masing paket PL berdasarkan kualitas produk sebelumnya, dukungan penjual, arah proyek, reputasi dsb. 6. Hubungi pemakai PL lain dan mintalah pendapat mereka.
t e N
a r d
By
n e H
Pada analisis akhir, keputusan make-buy berdasarkan kondisi sbb: 1. Tanggal penyampaian 2. Biaya yang diperlukan 3. Dukungan
Page 61 / 146
http://www.hendra-jatnika.web.id
MEMBUAT POHON KEPUTUSAN Rekayasa atau organisasi PL dapat menggunakan teknik statistik analisis pohon keputusan dengan pilihan : 1. membangun sistem X dari permulaan 2. menggunakan lagi komponen partial experience yang ada untuk membangun sistem 3. membeli sebuah produk perangkat lunak yang dapat diperoleh dan dimodifikasi untuk memenuhi kebutuhan lokal 4. mengkontrakkan pengembangan PL ke vendor luar Bila sistem dibangun dari permulaan, hanya 70% probabilitasnya sehingga pekerjaan menjadi sulit. Perencana proyek dapat memproyeksikan usaha pengembangan yang sulit berbiaya $450.000, usaha yang sederhana diperkirakan berbiaya $380.000.
t e N
a r d
Expected value untuk biaya dihitung sepanjang cabang pohon keputusan, adalah :
n e H
Expected Cost = Σ (jalur probabilitas)i * (biaya jalur terestimasi)i
By
dimana i adalah garis edar pohon keputusan. Contoh : expected costbuild expected costreuse expected costbuy expected costcontract
= 0.30 ($380 K) + 0.70 ($450 K) = $ 429 K = 0.40 ($275 K) + 0.60 (0.20 ($310 K) + 0.80 ($490 K)) = $ 382 K = 0.70 ($210 K) + 0.30 ($400 K) = $ 267 K = 0.60 ($350 K) + 0.40 ($500 K) = $ 410 K
Berdasar biaya probabilitas dan proyeksi, expected cost yang paling rendah adalah pilihan buy
Page 62 / 146
http://www.hendra-jatnika.web.id
Catatan : Banyak kriteria yang harus dipertimbangakan, bukan hanya biaya, seperti pengalaman pengembang/ vendor/ kontraktor, penyesuaian kebutuhan,kecenderungan perubahan dapat mempengaruhi keputusan akhir!
t e N
a r d
By
n e H
Page 63 / 146
http://www.hendra-jatnika.web.id
BAB 6 Manajemen Resiko Defenisi konseptual mengenai resiko : (Robert Charette) 1. Resiko berhubungan dengan kejadian di masa yg akan datang. 2. Resiko melibatkan perubahan (spt. perubahan pikiran, pendapat, aksi, atau tempat) 3. Resiko melibatkan pilihan & ketidakpastian bahwa pilihan itu akan dilakukan. Strategi Resiko Reaktif vs Proaktif Strategi reaktif memonitor proyek terhadap kemungkinan resiko. Sumber2 daya dikesampingkan, padahal seharusnya sumber2 daya menjadi masalah yang sebenarnya / penting.
t e N
a r dkerja teknis diawali. Strategi proaktif dimulai sebelum n Heprobabilitas & pengaruh proyek Resiko potensial diidentifikasi, diperkirakan, dan diprioritaskan menurut kepentingan, kemudian By membangun suatu rencana untuk manajemen resiko. Sasaran utama adalah menghindari resiko. Resiko Perangkat Lunak Karakteristik resiko : 1. Ketidakpastian 2. Kerugian Kategori resiko : • Resiko proyek • Resiko teknis • Resiko bisnis
Page 64 / 146
http://www.hendra-jatnika.web.id
Kategori resiko oleh Robert Charette : • Resiko yang sudah diketahui • Resiko yang dapat diramalkan • Resiko yang tidak diharapkan @ Resiko proyek Resiko proyek mengancam rencana proyek. Bila resiko proyek menjadi kenyataan maka ada kemungkinan jadwal proyek akan mengalami slip & biaya menjadi bertambah. Resiko proyek mengidenifikasi : - biaya - sumber daya - jadwal - pelanggan - personil (staffing & organisasi) - masalah persyaratan
t e N
a r d
@ Resiko teknis
n e H
Resiko teknis mengancam kualitas & ketepatan waktu PL yg akan dihasilkan. Bila resiko teknis menjadi kenyataan maka implementasinya menjadi sangat sulit atau tidak mungkin.
By
Resiko teknis mengidentifikasi : - desain potensial - implementasi - interfacing - verivikasi - masalah pemeliharaan
- ambiquitas - spesifikasi - ketidakpastian teknik - keusangan teknik - teknologi yg leading edge
@ Resiko bisnis Resiko bisnis mengancam viabilitas PL yg akan dibangun. Resiko bisnis membahayakan proyek atau produk.
Page 65 / 146
http://www.hendra-jatnika.web.id
5 resiko bisnis utama : 1. pembangunan produk atau sistem yg baik sebenarnya tdk pernah diinginkan oleh setiap orang (resiko pasar) 2. pembangunan sebuah produk yg tidak sesuai dgn keseluruhan strategi bisnis bagi perusahaan (resiko strategi) 3. Pembangunan sebuah produk dimana sebuah bagian pemasaran tidak tahu bagaimana harus menjualnya. 4. Kehilangan dukungan manajemen senior sehubungan dg perubahan pd fokus atau perubahan pd manusia (resiko manajemen) 5. Kehilangan hal2 yg berhubungan dgn biaya atau komitmen personal (resiko biaya). @ Resiko yg sudah diketahui
t e adalah resiko yg dpt diungkap setelah dilakukan N evaluasi secara a r& lingkungan teknik dimana hati terhadap rencana proyek, bisnis, d nsumber informasi reliable lainnya. proyek sedang dikembangkan,e dan H seperti : By yg tdk realitas - tgl penyampaian 2
- kurangnya persyaratan yg terdokumentasi - kurangnya ruag lingkup PL - lingkungan pengembangan yg buruk @ Resiko yg dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya. Misalnya : - pergantian staf - komunikasi yg buruk dgn para pelanggan - mengurangi usaha staff bila permintaan pemeliharaan sedang berlangsung dilayani
Page 66 / 146
http://www.hendra-jatnika.web.id
@ Resiko yg tidak diharapkan resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya. Identifikasi Resiko Identifikasi resiko dalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek. Tujuan identifikasi resiko : untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap saat diperlukan. Tipe resiko : 1. resiko generik merupakan ancaman potensial pd setiap proyek PL. 2. resiko produk spesifik hanya dapat diidentifikasi dgn pemahaman khusus mengenai teknologi, manusia, serta lingkungan yg spesifik terhadap proyek yg ada.
t e N
a r d
By
n e H
Metode untuk mengidentifikasi resiko adalah menciptakan checklist item resiko. Kategori checklist item resiko : o resiko ukuran produk o resiko yg mempengaruhi bisnis o resiko yg dihubungkan dgn karakteristik pelanggan o resiko definisi proses o resiko teknologi yang akan dibangun o resiko lingkungan pengembangan o resiko yg berhubungan dgn ukuran dan pengalaman staf
Page 67 / 146
http://www.hendra-jatnika.web.id
@ Resiko ukuran produk Resiko yg berhubungan dgn keseluruhan ukuran PL yg akan dibangun atau dimodifikasi. Checklist item resiko yg berhubungan dgn ukuran produk (PL) : • ukuran produk diperkirakan dalam LOC atau FP ? • tingkat kepercayaan dlm estimasi ukuran yg diperkirakan ? • ukuran produk yg diestimasi dalam jumlah program, file, transaksi ? • presentase deviasi dalam ukuran produk dari rata2 produk terakhir ? • ukuran database yg dibuat atau digunakan oleh produk ? • jumlah pemakai produk ? • jumlah perubahan yg diproyeksikan ke persyaratan produk ? sebelum produk ? setelah penyampaian ? • jumlah PL yg digunakan kembali ?
t e N
a r d
n e H
y B Bila persentasie deviasi besar atau deviasinya sama, tetapi hasil yg lalu sangat kurang dari yg diharapkan, maka resikonya tinggi.
@ Resiko yg mempengaruhi bisnis Resiko yg berhubungan dengan batasan yg dibebankan oleh manajemen atau pasar. Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan pertimbangan bisnis kadang mengalami konflik langsung dengan kenyataan teknis. Checklist item resiko yg berhubungan dgn pengaruh bisnis :
Page 68 / 146
http://www.hendra-jatnika.web.id
• • • • • • • • • •
Pengaruh produk terhadap hasil perusahaan ? Visibilitas produk terhadap manajemen senior ? Kelayakan deadline penyampaian ? Jumlah pelanggan yg akan menggunakan produk & konsistensi kebutuhan relatif mereka dengan produk tersebut ? Jumlah produk / sistem lain dgn apa produk ini harus dapat saling dioperasikan ? Kepintaran pemakai akhir ? Jumlah dan kualitas dokumentasi produk yg harus diproduksi & disampaikan kepada pelanggan ? Batasan pemerintahan pada konstruksi produk ? Biaya yg berhubungan dgn penyampaian yg terlambat ? Biaya yg berhubungan dgn produk defektif ?
Bila ada persentase deviasi yang besar atau jika jumlahnya sama, tetapi hasil sebelumnya sangat kurang dari yg diharapkan, maka resiko tinggi.
t e N
a r d
n e H
y B @ Resiko yg dihubungkan dgn karakteristik pelanggan Resiko yg berhubungan dengan kepintaran pelanggan & kemampuan pengembang untuk berkomunikasi dgn pelanggan dgn cara yg cepat. Karakteristik pelanggan : - Pelanggan mempunyai keinginan yg berbeda. - Pelanggan memiliki kepribadian yg berbeda. - Pelanggan memiliki hubungan yg bervariasi dgn pemasok. - Pelanggan juga kadang-kadang bertentangan. Karakteristik pelanggan mempengaruhi kemampuan tim PL untuk menyelesaikan suatu proyek tepat waktu & sesuai anggaran.
Page 69 / 146
http://www.hendra-jatnika.web.id
Checklist item resiko yg berhubungan dgn karakteristik pelanggan: • Pernahkah anda sebelumnya bekerja dengan pelanggan ? • Apakah pelanggan memiliki gagasan yg solid mengenai apa yg diperlukannya ? sudahkah pelanggan menggunakan waktunya untuk menuliskannya ? • Apakah pelanggan akan setuju dgn penggunaan waktu didalam pertemuan pengumpulan persyaratan formal (bab 11) utk mengidentifikasi ruang lingkup proyek ? • Apakah pelanggan bersedia membangun sambungan komunikasi cepat dgn pengembang ? • Apakah pelanggan bersedia berpartisipasi dalam kajian ? • Apakah pelanggan secara teknis pandai dlm area produk tsb? • Apakah pelanggan bersedia membiarkan orang2 melakukan pekerjaan mereka ? • Apakah pelanggan memahami proses perangkat lunak tsb ?
t e N
a r d
Bila setiap jawaban dari pertanyaan diatas adalah ‘tidak’, maka investigasi lebih jauh harus dilakukan utk memperkirakan potensi resiko.
By
n e H
@ Resiko definisi proses Bila kualitas merupakan sebuah konsep yg disetujui sbg hal yg penting tetapi tidak tidak ada yg berintdak untuk mencapainya dengan cara yg dapat yg dilakukan, maka proyek tersebut beresiko. Masalah-masalah proses • Apakah manajemen senior anda mendukung suatu pernyataan kebijaksanaan yg menekankan pentingnya suatu proses standar untuk pengembangan proses ? • Sudahkah organisasi anda mengembangkan suatu diskripsi tertulis mengenai proses PL yg akan digunakan pd proyek ini ?
Page 70 / 146
http://www.hendra-jatnika.web.id
• Apakah anggota2 staf ‘ditugasi’ ke proses PL pd saat PL didokumentasi & bersedia menggunakannya ? • Apakah proses PL digunakan untuk proyek lain ? • Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian serangkaian kursus pelatihan RPL bagi para manajer dan staf teknik ? • Apakah standar RPL yg diterbitkan disediakan utk setiap pengembang PL & manajer PL ? • Sudahkah dokumen outline & contoh2 dikembangkan untuk semua yg ditentukan sebagai bagian yg dapat disampaikan sebagai bagian dari proses PL ? • Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain, dan kode dilakukan secara reguler ? • Apakah kajian teknis formal terhadap prosedur pengujian & test case dilakukan secara reguler ? • Apakah hasil dari masing2 kajian teknis formal didokumentasikan, termasuk kesalahan yg ditemukan & sumber daya yg digunakan ? • Apakah mekanisme utk memastikan bahwa kerja yg dilakukan pd suatu proyek sesuai dengan standar RPL ? • Apakah manajemen konfigurasi digunakan utk memelihara konsistensi diantara _ystem/persyaratan PL, desain, kode, dan test case ? • Apakah digunakan suatu mekanisme utk mengontrol perubahan ke persyaratan pelanggan yg mempengaruhi PL ? • Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan, dan rencana pengembangan PL yg didokumentasikan untuk masing2 subkontrak ? • Apakah ada prosedur untuk menelusuri & mengkaji kinerja subkontrak ?
t e N
a r d
By
n e H
Masalah-masalah teknis
Page 71 / 146
http://www.hendra-jatnika.web.id
• Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi diantara pelanggan & pengembang ? • Apakah metode spesifik digunakan untuk analisis PL ? • Apakah anda melihat suatu metode spesifik untuk data & desain arsitektur ? • Apakah lebih dari 90% dari kode anda ditulis dgn bahasa orde yg lebih tinggi ? • Apakah konvensi spesifik utk dokumentasi kode didefinisikan & digunakan ? • Apakah anda menggunakan metode spesifik utk desain test case? • Apakah digunakan peranti PL utk mendukung perencanaan & aktivitas penelusuran ? • Apakah digunakan peranti PL manajemen konfigurasi utk me-ngontrol & menelusuri aktivitas perubahan diseluruh proses PL ? • Apakah digunakan peranti PL utk mendukung analisis PL & desain proses ? • Apakah digunakan peranti utk menciptakan prototipe PL ? • Apakah digunakan peranti PL utk mendukung proses pengujian ? • Apakah peranti PL digunakan utk mendukung produksi dan manajemen dokumentasi ? • Apakah metrik kualitas dikumpulkan bagi semua proyek PL ? • Apakah metrik produktivitas dikumpulkan bagi semua proyek PL?
t e N
a r d
By
n e H
Bila mayoritas jawaban terhadap pertanyaan tsb adalah `tidak`, maka proses PL lemah dan berisiko tinggi. @ Resiko teknologi yang akan dibangun
Page 72 / 146
http://www.hendra-jatnika.web.id
Resiko yg berhubungan dgn kompleksitas sistem yg akan dibangun dan `kebaruan` teknologi yg dikemas oleh system. Checklist item resiko yg berhubungan dengan teknologi yg akan dibangun : • Apakah teknologi yg akan dibangun adalah hal yg baru untuk organisasi anda? • Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi input atau output? • Apakah PL berinterface dgn perangkat keras baru atau belum terbukti? • Apakah PL yg akan dibangun ber-interace dgn produk PL yg dipasok oleh vendor yg belum terbukti? • Apakah PL yg akan dibangun ber-interface dgn suatu sistem database yg fungsi kinerjanya belum dibuktikan di dalam area aplikasi ini? • Apakan diperlukan interface pemakai khusus oleh persyaratan produk? • Apakah persyaratan untuk produk memerlukan kreasi komponen program yg tidak sama dengan yg dikembangkan terakhir oleh organisasi anda? • Apakah persyarata memerlukan pemakaian analisis, desain atau metode pengujian baru? • Apakah persyaratan memerlukan metode pengembangan PL tdk konvensional, spt metode formal, pendekatan Al-based dan jaringan syaraf buatan? • Apakah persyaratan meletakkan batasan kinerja yg eksesif pada produk tersebut? • Apakah pelanggan tidak yakin pada fungsionalitas yg diminta dapat ’dilakukan’?
t e N
a r d
By
n e H
Bila jawaban dari pertanyaan2 di atas adalah ’ya’, penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial.
Page 73 / 146
http://www.hendra-jatnika.web.id
@ Resiko lingkungan pengembangan Resiko yg berhubungan dgn keberadaan & kualitas peranti yg akan digunakan untuk membangun produk. Lingkungan proses PL mendukung tim proyek, proses dan produk. Lingkungan yg salah dapat menjadi sumber resiko yg penting. Checklist item resiko yg berhubungan dengan lingkungan pengembangan : • Apakah peranti manajemen proyek dapat diperoleh? • Apakah peranti manajemen proses dapat diperoleh? • Apakah peranti untuk analisis dan desain dapat diperoleh? • Apakah peranti analisis dan desain penyampaian metode sesuai bagi produk yg akan dibangun? • Apakah kompiler atau generasi kode dapat diperoleh dan sesuai untuk produk yg akan dibangun? • Apakah peranti pengujian dapat diperoleh dan sesuai untuk produk yg akan dibangun? • Apakah peranti manajemen konfigurasi PL dapat diperoleh? • Apakah lingkungan menggunakan suatu database atau tempat penyimpanan? • Apakah semua peranti PL dapat diintegrasikan satu dgn lainnya? • Sudahkah anggota tim proyek menerima pelatihan dgn masing2 peranti? • Apakah ada pakar lokal untuk menjawab pertanyaan2 mengenai peranti tersebut? • Apakah bantuan dan dokumentasi on-line bagi peranti memadai?
t e N
a r d
By
n e H
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah ’tidak’, berarti lingkungan pengembangan PL lemah dan berisiko tinggi.
Page 74 / 146
http://www.hendra-jatnika.web.id
@ Resiko yg berhubungan dgn ukuran & pengalaman staf Resiko yg berhubungan dgn keseluruhan teknik & pengalaman proyek dari RPL yg akan melakukan tugas tsb. Checklist item resiko yg berhubungan dengan ukuran & pengalaman staf : • Apakah orang2 terbaik dapat diperoleh? • Apakah orang2 tsb memiliki gabungan ketrampilan yg benar? • Apakah orang2 yg ada mencukupi? • Apakah staf dimasukkan ke dalam seluruh durasi proyek? • Akankah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini? • Apaka staf memiliki pengharapan yg tepat mengenai pekerjaan yg ada sekarang? • Sudahkah staf menerima pelatihan yg memadai? • Apakah pergantian di antara staf akan cukup rendah untuk memungkinkan kontinuitas?
t e N
a r d
By
n e H
Bila jawaban terhadap pertanyaan2 tsb adalah ’tidak’, maka penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial. Komponen Risiko dan Driver Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu menghendaki agar manajer proyek mengidentifikasi risiko driver yg mempengaruhi komponen risiko PL – kinerja, biaya, dukungan dan jadwal. Komponen risiko didefinisikan dgn cara sbb :
Page 75 / 146
http://www.hendra-jatnika.web.id
• Risiko kinerja – tingakat ketidakpastian dimana produk akan memenuhi persyaratannya dan cocok dgn penggunaannya. • Risiko biaya – tingkat ketidakpastian dimana biaya proyek akan dijaga • Risiko dukungan – tingkat ketidakpastian dimana PL akan mudah dikoreksi, disesuaikan dan ditingkatkan. • Risiko jadwal – tingkat ketidakpastian dimana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu. Pengaruh driver risiko thd komponen risiko dibagi ke dalam satu dari empat kategori pengaruh – diabaikan, marjinal, kritis dan katastropis. Tabel 6.1. menunjukkan konsekuensi potensial kesalahan (baris berlabel 1) atau kegagalan untuk mencapai suatu keluaran yg diharapkan (baris berlabel 2). Kategori pengaruh dipilih berdasarkan karakterisasi yg paling cocok dgn deskripsi pada tabel.
t e N
a r d
By
n e H
Page 76 / 146
http://www.hendra-jatnika.web.id
Tabel 6.1. Penilaian Pengaruh KOMPONEN KINERJA
DUKUNGAN
BIAYA
JADWAL
KATEGORI
KATASTROPIK
1
Gagal memenuhi persyaratan menyebabkan misi gagal
2
PL yg tdk Degradasi responsive signifikanpd atau tdk dpt tdk berprestasinya didukung kinerja teknis Gagal memenuhi persyaratan akan menurunkan kinerja ke titik dimana sukses misi diragukan
1
KRITIS
2
1
MARJINAL
2
1 DAPAT DIABAIKAN 2
Beberapa penundaan dlm kinerja teknis
By
Penundaan minor dalam modifikasi PL
t e N
a r d
n e H
Gagal memenuhi persyaratan akan mengakibatkan degradasi misi kedua Dukungan PL Penurunan minimal sampai yg responsif kecil dlm kinerja teknis Gagal memenuhi persyaratan memberikan pengaruh yg tdk menyenangkan dan non-operasional PL yg dpt Tdk ada didukung dgn penurunan dlm mudah kinerja teknis
Page 77 / 146
Kegagalan menyebabakan biaya meningkat dan jadwal tertunda dgn EV>$500K Tgl pengiriman Kemungkinana yg tdk dpt kurangnya dipenuhi finansial dan membengkaknya anggaran Kegagalan menyebabkan tertundanya operasinal dan atau meningkatnya biaya dgn EV $100K s/d $500K Sedikit Sedikit meleset dlm tgl kekurangan pengiriman sumber daya finansial, mungkin membengkak Biaya, pengaruh dan atau melesetnya jadwal dpt diperbaiki dgn EV $1 s/d $100K Jadwal yg Sumber daya realistis dan finansial yg dpt dicapai mencukupi Kesalahan menyebabkan biaya tambahan dan atau berpengaruh terhadap jadwal dgn EV < $1K Mungkin anggaran di bwh ketentuan
Tgl pengiriman dpt dicapai lebih cepat
http://www.hendra-jatnika.web.id
Catatan: (1) Konsekuensi potensial terhadap kesalahan PL yg tdk dpt dideteksi (2) Konsekuensi potensial jika hasil akhir yg diinginkan tidak tercapai EV = Expected Value
PROYEKSI RISIKO / PERKIRAAN RISIKO Dua cara melakukan proyeksi risiko : 1. Probabilitas di mana risiko adalah nyata 2. Konsekuensi masalah yang berhubungan dengan risiko
t e Nmanajer
Perencanaan proyek bersama dengan & staf teknik melakukan 4 aktifitas proyeksi risiko : 1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan 2. Menggambar konsekuensi risiko 3. Memperkirakan pengaruh risiko pada proyek dan produk 4. Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada kesalahpahaman
a r d
By
n e H
MENGEMBANGKAN TABEL RISIKO Tabel risiko memberi manajer proyek sebuah teknik sederhana bagi proyeksi risiko.
Page 78 / 146
http://www.hendra-jatnika.web.id
Tabel 6.2 Contoh Tabel Risiko Risiko Kategori Estimasi ukuran rendah PS secara signifikan Jumlah pemakai lebih PS besar dari yg diharapkan Pemakaian ulang lebih PS rendah dr yg diharapkan Pemakaian akhir menolak BU Deadline pengiriman BU diperketat Pendanaan dihapuskan CU Pelanggan akan merubah PS kebutuhan Teknologi tdk memenuhi TE harapan Kurangnya pelatihan pada DE piranti Staf tdk berpengalaman ST Turnover staf tinggi ST § § §
By
Prob 60%
Pengaruh RMMM 2
30%
3
70%
2
40% 50 %
3 2
40% 80%
1 2
a30% r d
1
80%
3
30% 60%
2 2
n e H
t e N
KATEGORI RISIKO : PS : Ukuran produk BU : Bisnis CU : Proses
TE : Teknologi DE : Lingkungan Pengembangan ST : Ukuran Staf & Pengalaman
Page 79 / 146
http://www.hendra-jatnika.web.id
NILAI PENGARUH 1 : Katastropik 2 : Kritis
3 : Marjinal 4 : Dapat diabaikan
Caranya : 1. Daftarkan semua risiko 2. Masing-masing risiko dikatogorikan 3. Probabilitas masing-masing risiko dapat diperkirakan oleh anggota tim secara individual 4. Pengaruh masing-masing risiko diperkirakan dengan menggunkan karekteristik yg ada di gambar 6.1 5. Katergori untuk masing-masing dari keempat komponen risiko kinerja, dukungan, biaya, dan jadwal dirata-rata untuk menentukan nilai keseluruhan 6. Urutkan probabilitas tinggi dan pengaruh tinggi dimasukkan ke urutan pertama.
t e N
a r d
By
n e H
MENILAI PENGARUH RISIKO Tiga factor yg mempengaruhi konsekuensi jika suatu risiko benar-benar terjadi : 1. Sifatnya ; risiko yang menunjukkan masalah yg muncul bila ia terjadi 2. Ruang lingkupnya; menggabungkan kepelikannya (seberapa seriusnya masalah ini ? ) dengan keseluruhan distribusi ( berapa banyak proyek yg akan dipengaruhi atau berapa banyak pelanggan terganggu ? ) 3. Timingnya; mempertimbangkan kapan dan untuk berapa lama pengaruh itu dirasakan.
Page 80 / 146
http://www.hendra-jatnika.web.id
Seorang manajer proyek mungkin menginginkan berita buruk terjadi segera mungkin tetapi dalam beberapa kasus penundaan lebih lama akan lebih baik. Langkah-langkah yg direkomendasikan untuk menentukan konsekuensi keseluhan dari suatu resiko : 1. Tentukan probabilitas rata-rata dari nilai kejadian untuk masing-masing komponen risiko 2. Dengan mengunkan tabel 6.2, tentukan pengaruh untuk masing-masing komponen berdasarkan kreteria yg diperlihatkan 3. Lengkapi tabel risiko dan analsis hasilnya seperti dijelaskan sebelumnya di bab 6 ini. Tim proyek harus melihat tabel risiko pada interval yg reguler mengevaluasi lagi masing-masing risiko untuk menentukan kapan keadaan baru menyebabkan probabilitas dan pengaruh berubah. Akibatnya diperlukan penambahan risiko baru ke tabel, mengganti risiko yg tidak relevan dan mengubah pemosisian relatif dari risiko lainnya.
t e N
a r d
By
n e H
PENILAIN RISIKO Dalam proses manajemen risiko, maka telah membangun serangkaian titik tripel yg berbentuk :
[ ri , l i , x i ] ri adalah risiko, li adalah kemungkinan (probabilitas) dan xi adah pengaruh dari risiko tersebut. Selama penilaian risiko harus menguji akurasi estimasi yg dibuat selama proyeksi risiko dan
Page 81 / 146
http://www.hendra-jatnika.web.id
memprioritaskan risiko yg telah diungkap dan cara mengontrol serta mencegah risiko yg mungkin terjadi. Tingkat referen risiko harus ditentukan sehingga bermanfaat. Sebagian besar proyek PL , komponen resiko yaitu kinerja, biaya, dukungan dan jadwal mencerminkan tingkat referen risiko. Tingkat referen risiko adalah tingkat degradasi kinerja, peningkatan biaya, kesulitan dukungan, dan melesatnya jadwal yang menyebabkan proyek diterminasi. Jika kombinasi risiko menciptakan masalah sehinnga ≥ 1 tingkat referen terlampaui maka kerja berhenti. Tingkat referen memiliki titik tunggal yg disebut referen point / break point dimana keputusan diteruskan atau dihentikan sama-sama diterima.
t e N
a r d
Selama penilaian maka dilakukan langkah-langkah sebagai berikut : 1. Tentukan tingkat referen risiko untuk proyek 2. Usahakan untuk mengembangkan hubungan antara
n e H
y B masing-masing [ r , l , x ] dan masing-masing tingkat referen i
i
i
3. Prediksi himpunan titik referen yg menentukan daerah tereliminasi dibatasi oleh kurva atau area ketidakpastian. 4. Cobalah memprediksi bagaimana penggabungan kombinasi risiko akan mempengaruhi suatu titik referen
PENGURANGAN, MONITORING dan MANAJEMEN RISIKO Aktifitas analisis risiko mempunyai titik tunggal yg memiliki tujuan untuk membantu tim proyek dalam mengembangkan strategi yg berkaitan dengan risiko.
Page 82 / 146
http://www.hendra-jatnika.web.id
Strategi yg efektif harus : 1. Menghindari risiko 2. Memonitoring risiko 3. Manajemen risiko dan perencanaan kemungkinan Langkah-langkah untuk mengurangi turnover staf adalah 1. Temui staf yg ada, untuk menentukan penyebab keluar 2. Bertindaklah untuk mengurangi penyebab-penyebab yg ada di bawah kontrol manajemen sebelum proyek dimulai 3. Bila proyek dimulai asumsikan turnover akan terjadi dan kembangkan teknik-teknik untuk memastikan kontiunitas pada saat orang keluar 4. Kumpulkan tim proyek sehingga informasi mengenai masing-masing aktivitas pengembangan dapat disebarluaskan 5. Tentukan standar dokumentasi dan buat mekanisme untuk memastikan bahwa dokumen dikembangkan tepat waktu 6. Lakukan kajian antar teman terhadap semua pekerjaan tersebut sehingga lebih dari satu orang yang terbiasa dengan pekerjaan itu 7. Tentukan backup anggota staf untuk setiap teknologi kritis
t e N
a r d
By
n e H
Aktifitas pemonitoran dimulai, manajer proyek memonitor factor-faktor yang dapat memberikan suatu indikasi apakah risiko mungkin sedang menjadi lebih atau kurang. Untuk kasus turnover tinggi, factor-faktor yg dapat dimonitor : 1. Sikap umum anggota tim berdasarkan tekanan proyek 2. Tingkat di mana tim disatu – padukan 3. Hubungan interpersonal di antara anggota tim 4. Masalah pontensial dengan kompensasi dan manfaat 5. Keberadaan pekerjakan di dalam perusahaan dan di luarnya
Page 83 / 146
http://www.hendra-jatnika.web.id
Langkah pengurangan resiko diperlukan bagi definisi standar dokuntasi dan mekanisme untuk memastikan bahwa dokumen dikembangkan secara tepat waktu, guna memastikan kontinuitas. Manajemen risiko dan perencanaan kemungkinan mengasumsikan bahwa usaha pengurangan telah gagal dan risiko menjadi suatu kenyataan. Contoh, diandaikan proyek sedang berlangsung dengan baik dan sejumlah orang mengatakan akan keluar dari proyek tersebut maka strategi pengurangan telah dilakukan dengan backup , informasi, dokumentasi dan pengetahuan telah disebar ke semua tim. Manajer proyek akan menyesuaikan lagi jadwal dengan fungsi-fungsi yg telah disusun sepenuhnya dan pendatang baru akan ditambah untuk mengejar dan membagun serta akan ditransfer pengetahuan oleh orang akan keluar.
t e N
a r d
n e H
Langkah RMMM (Risk Mitigating Monitoring and Management Plan) menambah biaya proyek.
By
RISIKO KESELAMATAN DAN BAHAYA Risiko tidak hanya pada proyek itu sendiri tetapi juga pada risiko kegagalan PL dilapangan (pemakai akhir). Bila PL digunakan untuk sistem kontrol, kompleksitas sistem dapat bertambah dengan urutan naik. Cacat desain yg tidak kentara yaitu sesuatu yg tidak dapat terungkap dan tereliminasi dalam kontrol konvensional berbasis perangkat keras menjadi lebih sulit diungkap pada saat PL digunakan.
Page 84 / 146
http://www.hendra-jatnika.web.id
Keselamatan PL dan analisis bahaya adalah aktifitas jaminan kualitas PL yg berfokus pd indentifikasi dan perkiraan bahaya pontensial terhadap PL dan menyebabkan kegagalan sistem. RMMM PLAN Strategi manajemen risiko dapat dimasukkan dalam rencana proyek PL atau langkah manajemen risiko dapat diatur ke dalam RMMM PLAN yg terpisah dimana akan didokumentasikan semua kegiatan yg dilakukan sebagai bagian dari analisis risiko dan oleh manajer proyek digunakan sebagai bagian dari keseluruhan rencana proyek. Uraian untuk RMMM PLAN adalah sebagai berikut : I. Pengantar 1. Lingkup dan tujuan Dokumen 2. Tinjauan risiko utama 3. Tanggung jawab a. Manajemen b. Staf teknis II. Tabel Risiko Proyek 1. Deskripsi semua risiko di atas yang ditentukan 2. Faktor-faktor yang mempengaruhi probabilitas pengaruh III. Pengurangan, monitoring, dan Manajemen Risiko n. Risiko # n a. Pengurangan i. Strategi umum ii. Langkah khusus untuk mengurangi risiko b. Monitoring i. Faktor-faktor yang dimonitoring ii. Pendekatan monitoring
t e N
a r d
By
n e H
c. Manajemen
Page 85 / 146
dan
http://www.hendra-jatnika.web.id
i. Rencana kontigensi ii. Konsiderasi khusus IV. Jadwal Iterasi Rencana RMMM V. Kesimpulan Sasaran dari monitoring risiko (aktifitas penelurusan proyek) yaitu 1. Memperkirakan apakah risiko yang diramalkan benar-benar terjadi 2. Memastikan bahwa langkah aversi risiko yang didefiniskan untuk risiko telah diterapkan secara benar 3. Mengumpulkan informasi yang dapat digunakan untuk analisis risiko masa yang akan datang Tugas lain dari monitoring risiko adalah berusaha menentukan risiko asli pada seluruh proyek.
t e N
a r d
By
n e H
Page 86 / 146
http://www.hendra-jatnika.web.id
BAB 7.PENJADWALAN & PENELUSURAN PROYEK
7.1 KONSEP DASAR Pengiriman
PL
terlambat
dikirimkan
(jadwal
yg
telah)
disebabkan : 1. Batas waktu yg tidak realistis karena dibuat oleh orang diluar kelompok RPL 2. Perubahan kebutuhan pelanggan yg tdk tercemin dalam perubahan jadwal 3. Memandang rendah jumlah usaha & / sumber –sumber daya
t e N
yg dibutuhkan dalam melakukan pekerjaan
a r d
4. Resiko yang dapat diramalkan & / tidak dapat diramalkan
n e H pada proyek tersebut yang tidak dipertimbangkan Bydan manusia yang tidak dapat 5. Kesulitan teknis
dilihat
sebelumnya 6. Kesalahan
komunikasi
di
antara
staff
proyek
yang
mengakibatkan penundaan proyek 7. Kegagalan manajer proyek untuk mengetahui bahwa proyek sudah ketinggalan dari jadwal yang ada dan kurang tindakan dalam memecahkan masalah tersebut
Tindakan yang dilakukan dalam menghadapi keterlambatan jadwal proyek yaitu :
Page 87 / 146
http://www.hendra-jatnika.web.id
Lakukan perkiraan lengkap berdasarkan data dari proyek yang lalu . Tentukan usaha yang diperkirakan dan durasi untuk proyek tersebut Dengan metode Inkremental, kembangkan suatu strategi pengembangan
yang
akan
menyampaikan
fungsionalitas
kritis dengan batas waktu ditentukan tetapi tundalah fungsionalitas dan dokumentasikan rencana tersebut. Komunikasikan dengan pelanggan, jelaskan mengapa jadwal tidak realistis. Lakukan pencatatan bahwa semua perkiraan yang ada pada kinerja proyek dan tunjukan % peningkatan yang dibutuhkan untuk mencapai batas waktu yang ada
t e N incremental Menawarkan strategi pengembangan a r d n alternatif e H By
sebagai
Penjadwalan proyek pengembangan PL dapat dilihat dari : Tanggal akhir pelepasan sistem berbasis komputer yang telah
dibuat
dan
organisasi
PL
dibatasi
dalam
mendistribusikan kerja di dalam batas waktu yang telah ditentukan Penjadwalan PL mengasumsikan bahwa batasan kronologis secara
umum
telah
dibicarakan
ditentukan oleh organisasi PL
Page 88 / 146
tetapi
batas
akhir
http://www.hendra-jatnika.web.id
Prinsip dasar menentukan jadwal proyek PL : 1.
Pembagian
2.
Saling ketergantungan
3.
Alokasi waktu
4.
Validasi kerja
5.
Batasan tanggungjawab
6.
Batasan keluaran
7.
Kejadian penting yang ditentukan
7.2 HUBUNGAN ANTARA MANUSIA DAN KERJA Bila suatu proyek mengalami keterlambatan jadwal yang
t e N untuk mengejar ditetapkan maka akan menambah programmer a r d n penambahan orang akan pada ketinggalan tersebut. Sayangnya, e H akhir proyek sering By menjadi bencana menyebabkan jadwal menjadi lebih terlambat lagi. Karena orang ditambah akan
mempelajari sistem yang telah ada dan orang yang mengajari mereka adalah orang yang sedang bekerja pada proyek tersebut sehinnga tidak bisa mengerjakan pekerjaannya. Waktu untuk mempelajari komunikasi
sistem sehingga
mengakibatkan membutuhkan
tambahan waktu proyek.
Page 89 / 146
meningkatnya kerja
tambahan
jalur dan
http://www.hendra-jatnika.web.id
7.3 HUBUNGAN EMPIRIS 1 3
L = P × ( E / B) t
4 3
L = jumlah baris P = produktifitas E = usaha (person month) B = factor skill ( 0,16 – 0, 39) t = durasi proyek dalam bulan kalender
E = L 3 /( P
3t
E = usaha yg diperluas (person year)
t 4 )( 7 ,1 )
t e N
a r d
L = jumlah baris P = produktifitas
By
n e H
t = durasi proyek dalam tahun
7.4 MENENTUKAN SERANGKAIAN TUGAS UNTUK PROYEK PL
Rangkaian tugas adalah sekumpulan tugas kerja RPL, pondasi, dan kemampuan penyampaian yg harus diselesaikan untuk menyelesaikan sebuah proyek tertentu serta memberikan disiplin yg cukup untuk mencapai kualitas PL yg tinggi.
Page 90 / 146
http://www.hendra-jatnika.web.id
Tipe proyek PL adalah 1. Consept Development Project, untuk mencari konsep bisnis yg baru / aplikasi dgn teknologi baru 2. New
Aplication
Development
Project,
dilakukan
sbg
konsekunsi permintaan pelanggan khusus 3. Aplication Enhancement Project, PL yg ada mengalami modifikasi utama dari fungsi, kinerja / interface yg dapat diamati oleh pemakai akhir 4. Aplication
Maintenance
Projects,
dilakukan
untuk
membetulkan, menyesuaikan / memperluas PL yg ada dgn cara tidak begitu jelas
t e N yg ada (warisan) 5. Reengineering Projects, membagun sistem a r d n secara keseluruhan / sebagian e H By
4 Tingkat kekakuan proyek didefinisikan : Casual Structured Strict Quick Reaction
7.5 Menentukan Kriteria Adaptasi Untuk menentukan derajat kekakuan yg direkomendasikan di mana proses PL akan diaplikasikan. Kriterianya adalah:
Page 91 / 146
http://www.hendra-jatnika.web.id
1.
Ukuran proyek
2.
Jumlah pemakaian potensial
3.
Misi kekritisan
4.
Umum Aplikasi
5.
Stabilitas kebutuhan
6.
Mudahnya komunikasi pelanggan/pengembang
7.
Kematangan teknologi yg dapat diaplikasikan
8.
Batasan unjuk kerja
9.
Karakteristik embedded / non embedded
10. Staffing Proyek 11. Interoperabilitas
t e N
a r d
12. Faktor Perekayasaan kembali
By
n e H
Kreteria diatas diberi kisaran dari 1 sampai 5. 1 = mewakili sebuah proyek yg dibutuhkan sub-kumpulan kecel dari
tugas
proses
&
metodologi
keseluruhan
serta
dokumentasi minimal 5 = mewakili sebuah proyek dimana serangkaian tugas proses lengkap harus diaplikasikan dan metodologi keseluruhan serta dokumentasi substansial
Page 92 / 146
http://www.hendra-jatnika.web.id
7.6 PERHITUNGAN NILAI TASK SET SELECTOR (TSS)
Langkah-langkah menghitung nilai TSS : 1. Kajilah masing-masing kriteria adaptasi dalam sub bab 7.5 dan tetapkan angka yg sesuai (1 s/d 5) berdasarkan karakteristik proyek 2. Kajilah factor pembobotan yg ditetapkan (0,9 s/d 1,2) dan bila diperlukan dapat diubah sesuai dengan keperluan proyek 3. Hasil produk = angka
x factor pembobot x entry point
multiplier Entry point multiplier berharga 0 dan 1 berarti relevansi
t e N kreteria adaptasi dengan tipe proyek a r d n entri pada kolom produk dan 4. Hitunglah rata-rata darie semua H tempatkan pada y B ruang yg ditandai TSS. Harga ini digunakan
untuk memilih kumpulan tugas yg paling sesuai bagi proyek anda.
7.7 Interpretasi Harga TSS dan Pemilihan Kumpulan Tugas Tabel 7.2 Harga TSS TASK SET SELECTOR (TSS) TSS < 1,2
Tingkat Kekakuan Casual
1,0 < TSS <3,0
Structured
TSS > 2,4
Stict
Page 93 / 146
http://www.hendra-jatnika.web.id
Overlap antara harga TSS dari kumpulan tugas yg disetujui dengan kumpulan tugas lain dimaksudkan untuk menggambarkan bahwa batasan yg tajam tidak mungkin ditentukan pada saat memilih kumpulan tugas. Dalam analisis akhir, harga TSS, pengalaman masa lalu, dan aturan umum harus difaktorkan ke dalam pilihan kumpulan sebuah proyek. Contoh dapat dilihat pada tabel 7.3 dimana proyek tipe proyek adalah new application development (Ndev). Harga TSS produk adalah 2,8 maka manajer memilih pilihan pemakaian terbaik dari test set structured maupun strict.
t e N factor Keputusan akhir diambil setelah asemua r d n dipertimbangkan. e H By
proyek
7. 8 MEMILIH TUGAS TUGAS RPL
Proyek pengembangan konsep dididekati dengan menerapkan tugas-tugas utama berikut ini : 1. Penentuan ruang lingkup konsep dilakukan scr menyeluruh 2. Perencanaan konsep pendahuluan membangun kemampuan organisasi untuk melakukan kerja yg diimplentasi oleh ruang lingkup proyek
3. Perkiraan
risiko
teknologi
mengevaluasi
risiko
yg
berhubungan dgn teknologi yg diimplementasikan sebagai bagian dari ruang lingkup proyek
Page 94 / 146
http://www.hendra-jatnika.web.id
4. Bukti dari konsep mendemontrasikan viabilitas sebuah teknologi baru dlm konteks perangkat lunak
5. Implementasi
konsep
mengimplementasikan
representasi
konsep dengan cara yg dapat dikaji oleh seorang pelanggan & digunakan sebagai pemasaran pd saat konsep harus dijual ke pelanggan / manajemen lain 6. Reaksi pelanggan terhadap konsep mengumpulkan umpan balik tentang
konsep
&
target
sebuah
teknologi
baru
yg
mengkhususkan pd aplikasi pelanggan
Tim perangkat lunak harus memahami apa yg harus dilakukan
t e N apakah ada orang (ruang llingkup), tim/manajer hrs menentukan a r d n yg dapat mengerjakannyae(perencanaan), menentukan risiko H sehubungan dengan By kerja tersebut (estimasi risiko),
membuktikan teknologi dengan berbagai cara (pembuktian konsep), mengimplementasian proyek dgn prototaping sehingga dpt dievaluasi oleh pelanggan (konsep impelentasi & evaluasi pelanggan) , bila konsep dapat dipercaya maka dihasilkan versi produksi.
7.8 PENYARINGAN TUGAS-TUGAS MAYOR Jadual mikroskopik harus disaring untuk menghasilkan jadual proyek lengkap, penyaringan dimulai dengan mengambil
Page 95 / 146
http://www.hendra-jatnika.web.id
setiap tugas utama & melakukan dekomposisi terhadap tugas tersebut kedlm serangkaian sub tugas . Contoh dekomposisi tugas, Penentuan Ruang Lingkup Konsep dengan pendekatan bahasa desain proses :
Tugas I.1 Penentuan Ruang Lingkup Proses I.1.1
Mengidentifikasi
kebutuhan,
keuntungan
&
pelanggan
potensial I.1.2
Menentukan kejadian output/kontrol & input yg diharapkan yg mengendalikan aplikasi Memulai Tugas I.1.2 I.1.2.1 FTR mengkaji deskripsi kebutuhan tertulis I.1.2.2 Memperoleh daftar output/input yg tampak pd
t e N
konsumen
a r d
n e H
Case of : mekanik
By
Mekanik : penyebaran fungsi kualitas Bertemu
dgn
pelanggan
untuk
mengisolasi
kebutuhan konsep utama; Mewawancarai pemakai akhir Meneliti pendekatan masalah, proses saat ini Mengkaji permintaan & keluhan sebelumnya Mekanik = analisis terstruktur Membuat daftar objek data minor Menentukan hubungan antar objek Mekanik = melihat objek Membuat daftar kelas bermasalah Mengembangkan hirarki kelas & hubungan kelas Menentukan atribut untuk kelas I.1.2.3 FTR : mengkaji output / input dengan pelanggan & merevisi sesuai kebutuhan
Page 96 / 146
http://www.hendra-jatnika.web.id
I.1.3 Menentukan fungsionalitas/ tingkah laku untuk setiap fungsi utama Memulai Tugas I.1.3 I.1.3.1 FTR : mengkaji objek data output & input yg diambil dari tugas I.1.2
7.9 MENENTUKAN JARINGAN TUGAS Jaringan tugas merupakan representasi grafik dari aliran tugas sebuah proyek & digunakan sebagai mekanisme untuk seluruh rangkaian & ketergantunagn tugas merupakan input bagi suatu alat bantu penjadual proyek secara otomatis.
t e N
Manajer proyek harus tanggap terhadap jalur kritis. Dapat dilihat pada gambar 7.????.
y B 7.10 PENJADUALAN
a r d
n e H
Teknik kajian & evaluasi program (PERT) & metode jalur kritis (CPM) adalah dua metode penjadualan proyek yg dapat diaplikasikan pd pengembangan perangkat lunak. Kedua teknik dikendalikan oleh informasi yg sudah dikembangan pd aktifitas perencanaan proyek sebelumnya : Estimasi kerja Dekomposisi fungsi produk Pemilihan tipe proyek & rangkaian tugas
Page 97 / 146
http://www.hendra-jatnika.web.id
Kesaling-ketergantungan antara tugas-tugas dpt ditentukan dgn menggunakan
sebuah
jaringan
tugas,
ka&g-ka&g
disebut
Struktur Perincian Kerja (WBS) ditentukan untuk produk sebagai satu kesatuan / untuk fungsi individual. Baik
PERT
&
CPM
menyediakan
piranti
kuantitatif
yg
memperbolehkan perencanan perangkat lunak untuk 1.
Menentukan jalur kritis – rantai tugas yg menentukan durasi proyek
2.
Membangun estimasi waktu yg paling mungkin bagi tugastugas individual dgn menerapkan model statistik
3.
Menghitung batas waktu yg membatasi suatu jendela
t e N
a r d
waktu untuk suatu tugas tertentu
n e H
Riggs menggambarkan waktu batas yg penting dimana
By
8. Suatu tugas dapat dimulai ketika semua tuags sebelumnya sudah diselesaikan dalam waktu yg paling pendek yg mungkin 9. Waktu paling lambat untuk menginisiasi tugas sebelum waktu penyelesaian proyek minimum ditunda 10.
Penyelesaian paling awal – jumlah dari waktu mulai paling
awal dari durasi tugas 11. Selesai paling akhir – jumlah dari waktu mulai paling lambat ditambah ke durasi tugas 12.
Total float – jumlah waktu surplus / waktu ekstra yg
diperbolehkan dalam penjadual tugas sehingga jalur kritis jaringan terjada sesuai jadual
Page 98 / 146
http://www.hendra-jatnika.web.id
1.11
DIAGRAM TIMELINE Dalam membuat jadual proyek PL, perencana memulainya
dgn serangkaian tugas , bila piranti otomatis digunakan, rincian kerja dimasukkan sbg sebuah jaringan tugas / outline tugas. Kemudian kerja, durasi, & tanggal mulai dimasukkan bg setiap tugas dan tugas-tugas dapat ditentukan bagi individu-individu tertentu. Dengan input tersebut terbentu diagram timeline atau gantt. Contoh dapat dilihat pada gambar ???? Batang horizontal adalah menunjukkan durasi dari masing-
t e N
a r d
masing tugas
n e H
Bila ada batang ganda pada saat yg sama pd kalender, tugas-
By
tugas konkuren diimplikasikan.
Tanda diamond menunjukkan kejadian penting. Hasilnya adalah tabel proyek mementukkan tanggal dimulai dan berakhirnya baik yg direncanakan maupun yg sesungguhnya.
1.12
PENELUSURAN JADUAL
Penelusuran jadwal dapat dilakukan dengan berbagai cara : 1.
Mengadakan pertemuan status proyek scr periodic di mna anggota tim melaporkan masalah & kemajuannya
2.
Mengevaluasi hasil kajian yg dilakukan pd keseluruhan proses RPL
Page 99 / 146
http://www.hendra-jatnika.web.id
3.
Menentukan apakah kejadian penting proyek formal (tanda diamond) telah dikerjakan sesuai tanggal yg dijadualkan
4.
Membandingkan tanggal mulai actual dengan tanggal mulai yg direncanakan bg setiap tugas proyek yg ditulis dlm tabel
5.
Pertemuan
scr
mendapatkan
informal
perkiraan
dgn
para
kemajuan
pelaksana subjektif
untuk mereka
tanggal dan masalah di masa mendatang Teknik pelacakan , biasanya dilakukan oleh manajer proyek yg berpengalaman.
t e NPL untuk menjalankan Kontrol digunakan oleh manajer proyek a r d n menyelesaikan masalah, sumber-sumber daua proyek, e H mengarahkan staf proyek. By Bila proyek berjakan baik kontrol menjadi langgor tetapi bila sebaliknya maka kontrol diperketat dan focus ditekankan pd area masalah. Pada
tekanan
batas
waktu
yg
berat,
manajer
proyek
menggunakan metode time boxing yaitu setiap tugas disesuaikan dgn mengerjakan scr backward dari tanggal penyampaian untuk pertambahan tsb yg dibatasi batas waktu yg ditambah 10 % bila sudah sampai pd batas waktu maka pekerjaan berhenti dan dimulai dgn pekerjaan baru.
Page 100 / 146
http://www.hendra-jatnika.web.id
7.13 RENCANA PROYEK Rencana proyek PL diproduksi pada titik puncak tugastugas perencanaan yang memberikan biaya dasar dan informasi penjadualan yg dipakai pd keseluruhan proyek. Rencana proyek digunakan kepentingan orang yg berbeda berupa dokumen singkat yaitu : 1. Mengkomunikasikan ruang lingkup & sumber-sumber daya kpd manajer PL 2. Menentukan risiko & mengusulkan teknik manajemen risiko 3. Membatasi biaya & jadual untuk keperluan pengkajian 4. Memberikan
pendekatan
yg
menyeluruh kpd t e N yg berhubungan dg pengembangan PL bagi orang-orang a r d n proyek tersebut e H 5. Menguraikan bagaimana kualitas akan dijamin & perubahan By akan dilakukan
Langkah-langkah berikut dalam proyek PL akan berkosentrasi pada definisi, pengembangan dan pemeliharaan :
I.
Pendahuluan A. Tujuan Rencana B. Ruang Lingkup & Tujuan Proyek 1. Pernyataan Ruang lingkup 2. Fungsi-fungsi utama 3. Isu-isu kerja 4. Batasan manajemen & teknik II. Estimasi Proyek A. Data historis yg digunakan untuk estimasi B. Teknik-teknik estimasi
Page 101 / 146
http://www.hendra-jatnika.web.id
C.
Estimasi Usaha, biaya, & durasi III. Strategi Manajemen Risiko A. Tabel risiko B. Penambahan risiko untuk dikelola C. Rencana RMMM untuk setiap risiko 1. Mitigasi risiko 2. Monitoring risiko 3. Manajemen risiko (rencana kontigensi) IV. Jadual A. Struktur Pembagian Kerja Proyek B. Jaringan tugas C. Diagram Timeline / gantt D. Tabel sumber daya V. Sumber Daya Proyek A. Orang B. Perangkat keras & Perangkat Lunak C. Sumber daya khusus VI. Staf Organisasi A. Struktur tim jika diterapkan B. Pelaporan manajemen VII. Pelacakan & Mekanisme Kontrol A. Jaminan & kontrol kualitas B. Mananjemen & kontrol perubahan VIII. Lampiran
t e N
a r d
By
n e H
Page 102 / 146
Tabel 7.1 ENTRY PRINT MULTIPIER NDEV ENHAN MAINT REENG 1 1 1 0 1 1 1 0 1 1 1 0 1 0 0 0 1 1 1 0 1 1 1 1
CONC 1 1 1 1 1 1
By
0 1 1
0 0 0
1 1 1
1 0 1
1 1 0
1 1 0
1 1 1
1 0 0
t
Ne
1 1 0
ra
1 1 1
nd
He
Page 103 / 146
PRODUCT
http://www.hendra-jatnika.web.id
KRETERIA GRADE LEBAR ADAPTAS Ukuran proyek 2 0 Jumlah pemakaian 3 0 Kekritikalitas Bisnis 4 0 Umum 3 0 Stabilitas kebutuhan 2 0 Kemudahan 2 1 komunikasi Kematangan teknologi 2 1 Batasan kinerja 3 0 Embedded/non 3 1 embedded Staffing Proyek 2 1 Interoperabilitas 4 0 Faktor Rekayasa 0 0 Ulang Task Set Selector (TSS)
Tabel 73 Contoh Kasus
By
CONC -
PRODUCT 2,4 3,3 4,4 2,7 2,4 1,8
-
-
-
1,8 2,4 3,6
1 1
-
-
-
2 4,4
http://www.hendra-jatnika.web.id
1 1 1
t
-
Ne
-
ENTRY PRINT MULTIPIER NDEV ENHAN MAINT REENG 1 1 1 1 1 1 -
ra
nd
He
Page 104 / 146
KRETERIA GRADE LEBAR ADAPTAS Ukuran proyek 2 1,20 Jumlah pemakaian 3 1,10 Kekritikalitas Bisnis 4 1,10 Umur 3 0,90 Stabilitas kebutuhan 2 1,20 Kemudahan 2 0,90 komunikasi Kematangan teknologi 2 0,90 Batasan kinerja 3 0,80 Embedded/non 3 1,20 embedded Staffing Proyek 2 1,00 Interoperabilitas 4 1,10
Faktor Rekayasa 2 Ulang Task Set Selector (TSS)
1,20
-
0
-
-
-
2.4 2.8
By t
Ne
ra
nd
He
Page 105 / 146
http://www.hendra-jatnika.web.id
http://www.hendra-jatnika.web.id
BAB 8 JAMINAN KUALITAS PERANGKAT LUNAK Software Quality Assurance [SQA] Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak. SQA meliputi : 1. pendekatan manajemen kualitas 2. teknologi rekayasa perangkat lunak yang efektif (metode dan peranti) 3. kajian teknik formal yang diaplikasikan pada keseluruhan proses perangkat lunak 4. strategi pengujian multitiered (deret bertingkat) 5. kontrol dokumentasi perangkat lunak dan perubahan 6. prosedur untuk menjamin kesesuaian dengan standar pengembangan perangkat lunak 7. mekanisme pengukuran dan pelaporan.
t e N
a r d
By
n e H
Kontrol Kualitas Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan. Konsep kunci kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan dan dapat diukur dimana kita dapat membandingkan output dari setiap proses. Kalang (loop) menjadi penting untuk meminimalkan cacat yang dihasilkan. Page 106 / 146
http://www.hendra-jatnika.web.id
Jaminan Kualitas Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan jaminan kualitas adalah : untuk memberikan data yang diperlukan oleh manajemen untuk menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian & konfidensi bahwa kulitas produk dapat memenuhi sasaran. Biaya Kualitas Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas.
t e N
a r d
n e H
Studi tentang biaya kualitas dilakukan untuk memberikan garis dasar bagi biaya kualitas yang sedang digunakan, untuk mengidentifikasi kemungkinan pengurangan biaya kualitas serta memberikan basis perbandingan yang ternormalisasi.
By
Biaya kualitas dapat dibagi ke dalam biaya-biaya yang dihubungkan dengan : a. pencegahan b. penilaian c. kegagalan. a) Biaya pencegahan meliputi : • Perencanaan • Kajian teknis formal • Perlengkapan pengujian • Pelatihan
Page 107 / 146
http://www.hendra-jatnika.web.id
b) Biaya penilaian meliputi : • Inspeksi in-proses dan interproses • Pemeliharaan dan kalibrasi peralatan • Pengujian c) Biaya kegagalan Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang muncul sebelum produk disampaikan kepada pelanggan. Biaya kegagalan internal adalah biaya yang diadakan bila kita mendeteksi suatu kesalahan dalam produk sebelum produk dipasarkan.
t e N
Biaya kegagalan internal meliputi: • Pengerjaan kembali • Perbaikan • Analisis mode kegagalan
a r d
By
n e H
Biaya kegagalan eksternal adalah biaya yang berhubungan dengan cacat yang ditemukan setelah produk disampaikan kepada pelanggan. Biaya kegagalan eksternal meliputi: • Resolusi keluhan • Penggantian dan pengembalian produk • Dukungan help line • Kerja jaminan Biaya relatif mendapatkan dan membetulkan cacat bertambah secara dramatis pada saat kita melangkah dari pencegahan ke pendeteksian dan dari kegagalan internal ke kegagalan eksternal.
Page 108 / 146
http://www.hendra-jatnika.web.id
1000 Biaya Relatif Pembentukan Kesalahan
40 - 10 00 w a k tu 30 - 70 w a k tu 100
15 - 40 w a k tu 10 w a k tu
10
1
3 - 6 w a k tu 1 w a k tu
P e m b e n tu k a n
D e s a in
K ode
U ji P engem bangan
U ji S is te m
O p e ra s i La pangan
Gambar 8.1 Biaya Relatif pembetulan kesalahan
JAMINAN KUALITAS PERANGKAT LUNAK Kualitas perangkat lunak didefinisikan sebagai: Konformansi terhadap kebutuhan fungsional dan kinerja yang dinyatakan secara eksplisit, standar perkembangan yang didokumentasikan secara eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat lunak dikembangkan secara profesional.
t e N
a r d
By
n e H
definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu: 1. Kebutuhan perangkat lunak merupakan fondasi yang melaluinya kualitas diukur. 2. Standar yang telah ditentukan menetapkan serangkaian kriteria pengembangan yang menuntun cara perangkat lunak direkayasa. 3. Ada serangkaian kebutuhan implisit yang sering dicantumkan (misalnya kebutuhan akan kemampuan pemeliharaan yang baik).
Page 109 / 146
http://www.hendra-jatnika.web.id
Kelompok SQA berfungsi sebagai perwakilan inhouse pelanggan, yaitu orang yang akan melakukan SQA harus memperhatikan perangkat lunak dari sudut pandang pelanggan. Kelompok SQA harus dapat menjawab pertanyaanpertanyaan dibawah ini untuk memastikan bahwa kualitas perangkat lunak benar-benar terjaga. • Apakah perangkat lunak cukup memenuhi faktor kualitas • Sudahkah pengembangan perangkat lunak dilakukan sesuai dengan standar yang telah ditetapkan sebelumnya? • Sudahkah disiplin teknik dengan tepat memainkan perannya sebagi bagian dari aktivitas SQA?
t e N
Aktivitas SQA
a r d
n e H
y B Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan dengan dua konstituen yang berbeda : – perekayasa perangkat mengerjakan kerja teknis
lunak
yang
– kelompok SQA yang bertanggung jawab terhadap perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan. Tugas kelompok SQA adalah membantu tim rekayasa perangkat lunak dalam pencapaian produk akhir yang berkualitas tinggi.
Page 110 / 146
http://www.hendra-jatnika.web.id
Aktivitas yang dilakukan (atau kelompok SQA yang independen:
difasilitasi)
oleh
v Menyiapkan rencana SQA untuk suatu proyek. Rencana tersebut mengindentifikasikan hal-hal berikut: • Evaluasi yang dilakukan • Audit dan kajian yang dilakukan • Standar yang dapat diaplikasikan pada proyek • Prosedur untuk pelaporan & penelusuran kesalahan • Dokumen yang dihsilkan oleh kelompok SQA • Jumlah umpan balik yang diberikan pada tim proyek perangkat lunak v Berpartisipasi dalam pengembangan deskripsi proses pengembangan proyek.
t e N
a r d
v Mengkaji aktivitas rekayasa perangkat lunak untuk memverifikasi pemenuhan proses perangkat lunak yang sudah ditentukan.
By
n e H
v Mengaudit produk kerja perangkat lunak yang ditentukan untuk membuktikan kesesuaian dengan produk kerja yang ditentukan tersebut sebagai bagian dari proses perangkat lunak. v Memastikan bahwa deviasi pada kerja dan produk perangkat lunak didokumentasikan & ditangani sesuai dgn rosedur pendokuementasian. v Mencatat ketidak-sesuaian dan melaporkannya kepada manajemen senior. v Mengkoordinasi kontrol dan manajemen perubahan, dan membantu mengumpulkan dan menganalisis metrik perangkat lunak.
Page 111 / 146
http://www.hendra-jatnika.web.id
KAJIAN PERANGKAT LUNAK Kajian perangkat lunak merupakan aktivitas SQA yang terpenting.
salah
satu
Kajian perangkat lunak adalah suatu filter bagi proses rekayasa perangkat lunak, yaitu kajian yg diterapkan pd berbagai titik selama pengembangan PL & berfungsi untuk mencari kesalahan yg kemudian akan dihilangkan. Kajian perangkat lunak berfungsi untuk “memurnikan” produk kerja perangkat lunak yang terjadi sebagai hasil dari analisis, desain, dan pengkodean.
KAJIAN TEKNIK FORMAL (Formal Technic Review - FTR )
t e N
a r d
n e H
FTR adalah aktivitas jaminan kualitas perangkat lunak yang dilakukan oleh perekayasa perangkat lunak.
By
Kajian teknik formal atau walktrough adalah pertemuan kajian yang disesuaikan dengan kebutuhan yang terbukti sangat efektif untuk menemukan kesalahan. Keuntungan utama kajian teknis formal adalah penemuan kesalahan sejak awal sehingga tidak berlanjut ke langkah selanjutnya dalam proses perangkat lunak. Tujuan FTR adalah 1. Menemukan kesalahan dlm fungsi, logika, / implementasinya dlm berbagai representasi PL; 2. Membuktikan bahwa perangkat lunak di bawah kajian memenuhi syarat;
Page 112 / 146
http://www.hendra-jatnika.web.id
3. Memastikan bahwa PL disajikan sesuai dgn standar yg sudah ditentukan sebelumnya; 4. Mencapai perangkat lunak yg dikembangkan dengan cara yang seragam; 5. Membuat proyek lebih dapat dikelola.
FTR berfungsi sebagai dasar pelatihan yang memungkinkan perekayasa yunior mengamati berbagai pendekatan yang berbeda terhadap analisis perangkat lunak, desain, dan implementasi. FTR juga berfungsi untuk mengembangkan backup dan kontinuitas karena sejumlah orang mengenal baik bagian-bagian perangkat lunak yang tidak mereka ketahui sebelumnya. Masing-masing FTR dilakukan sebagai suatu pertemuan dan akan berhasil hanya bila direncanakan, dikontrol dan dihadirkan dengan tepat. Dalam paragraf berikut, panduan yang mirip dengan walktrough disajikan sebagai kajian teknis formal representatif.
t e N
a r d
By
n e H
TABEL 8.1 Perbandingan Biaya Pengembangan Kesalahan yang Jumlah Unit Biaya Total ditemukan Kajian dilakukan 33 1.5 Selama desain 22 Sebelum pengujian 36 6.5 234 15 Selama pengujian 15 315 3 67 Setelah peluncuran 201 783 Kajian tidak dilakukan Sebelum pengujian 22 6.5 143 Selama pengujian 82 15 1230 Setelah peluncuran 804 12 67 2177 Page 113 / 146
http://www.hendra-jatnika.web.id
Pertemuan Kajian Tanpa memperhatikan format FTR yang dipilih, setiap pertemuan kajian harus mematuhi batasan-batasan berikut ini : • Antara 3 & 5 orang (khususnya) harus dilibatkan dalam kajian; • Persiapan awal harus dilakukan, tetapi waktu yang dibutuhkan harus tidak lebih dari 2 jam dari kerja bagi setiap person • Durasi pertemuan kajian harus kurang dari 2 jam Pertemuan kajian dihadiri oleh pimpinan kajian, pengkaji, dan prosedur. Salah satu dari pengkaji berperan sebagai pencatat, yaitu seseorang yang mencatat semua masalah penting yang muncul selama pengkajian. FTR dimulai dengan pengenalan agenda dan pendahuluan dari prosedur. Bila ada masalah kesalahan ditemukan akan dicatat.
t e N
a r d
By
n e H
Pada akhir kajian, semua peserta FTR yang hadir harus memutuskan apakah akan 1. menerima produk kerja tanpa modifikasi lebih lanjut, 2. menolak produk kerja sehubungan dengan kesalahan yangada (sekali dbetulkan, kajiann lain harus dilakukan), atau 3. menerima produk kerja secara sementara (kesalahan minor telah terjadi & harus dikoreksi, tetapi kajian tambahan akan diperlukan). Keputusan kemudian dibuat. Semua peserta FTR melengkapinya dengan tanda tangan yang menunjukkan partisipasi mereka dalam kajian serta persetujuan mereka terhadap pertemuan tim kajian. Page 114 / 146
http://www.hendra-jatnika.web.id
Pelaporan Kajian dan Penyimpanan Rekaman Selama FTR, seorang pengkaji (pencatat) secara aktif mencatat semua masalah yang sudah dimunculkan, yang kemudian dirangkum pada akhir pertemuan sehingga dihasilkan daftar masalah kajian. Sebagai tambahan, laporan rangkuman kajian yang sederhana telah diselesaikan di mana rangkuman kajian merupakan jawaban dari tiga pertanyaan berikut: 1. Apa yang dikaji ? 2. Siapa yang melakukan? 3. penemuan apa yang kesimpulannya?
dihasilkan
dan
apa
t e N
Daftar masalah kajian mempunyai dua tujuan: 1. Mengidentifikasi area masalah pada produk, 2. Daftar item kegiatan yang menjadi petunjuk bagi prosedur saat koreksi dilakukan. Daftar masalah biasanya dilampirkan pada laporan.
a r d
By
n e H
Pedoman Kajian Pedoman untuk melakukan kajian teknis formal harus dilakukan sebelumnya, didistribusikan kepada semua pengkaji, disetujui, dan kemudian dilaksanakan. Kajian yang tidak terkontrol sering dapat menjadi lebih buruk daripada bila tidak ada kajian sama sekali. Berikut ini serangkaian pedoman minimum untuk kajian teknis formal: 1. Kajian produk, bukan produser. 2. Menetapkan agenda dan menjaganya. 3. Membatasi perdebatan dan bantahan. Page 115 / 146
http://www.hendra-jatnika.web.id
4. Menetapkan area masalah, tetapi tidak tergoda untuk menyelesaikannya setiap masalah yang dicatat. 5. Mengambil catatan tertulis.
6. Membatasi jumlah peserta dan mewajibkan persiapan awal. 7. Mengembangkan daftar bagi masingmasing produk kerja yang akan dikaji. 8. Mengalokasikan sumber-sumber daya dan jadwal waktu untuk FTR. 9. Melakukan pelatihan bagi semua pengkaji. 10. Mengkaji kajian awal Anda. PENDEKATAN FORMAL TERHADAP SQA Kualitas perangat lunak merupakan tugas setiap orang & kualitas dapat dicapai melalui analisis, desain, pengkodean, dan pengujian yang baik serta aplikasi standar pengembangan perangkat lunak yang diterima. Pada lebuh dari dua dekade, segmen komunitas rekayasa perangkat lunak yang kecil tetapi vokal telah memperlihatkan bahwa dibutuhkan suatu pendekatan yang lebih formal terhadap jaminan kualitas perangkat lunak. Pembuktian matematis terhadap kebenarannya dapat diaplikasikan untuk menunjukkan bahwa program menyesuaikan diri secara tepat dengan spesifikasinya.
t e N
a r d
By
n e H
JAMINAN KUALITAS STATISTIK (SQA) Jaminan kualitas statistik mencerminkan trend yang sedang tumbuh di seluruh industri untuk menjadi lebih kuantitatif terhadap kualitas.
Page 116 / 146
http://www.hendra-jatnika.web.id
Pada perangkat lunak, jaminan kualitas statistik mengimplikasikan langkah-langkah berikut ini: 1. Informasi tentang cacat perangkat lunak dikumpulkan dan dipilah-pilahkan. 2. Melakukan suatu usaha untuk menelusuri masing-masing cacat sampai ke penyebab pokoknya. 3. Dengan menggunakan prinsip Pareto (80 persen cacat dapat ditelusuri sampai 20 persen dari semua kemungkinan penyebab), mengisolasi yang 20 persen tersebut (vital few) 4. Sekali penyebab vital few telah diidentifikasi, beralih untuk membetulkan maslah yang menyebabkan cacat. Banyak kesalahan ditemukan pada waktu perangkat lunak sedang dalam proses pengembangan. Cacat yang lain ditemukan setelah perangkat lunak diluncurkan kepada pemakai akhir. Meskipun ratusan kesalahan yang berbeda diluncurkan, semuanya dapat ditelusuri dari satu (atau lebih) penyebab berikut ini :
t e N
a r d
By
n e H
• Spesifikasi yang tidak lengkap atau keliru (IES) • Kesalahan interpretasi komunikasi pelanggan (MMC) • Deviasi intersioanl dari spesifikasi (IDS) • Pelanggaran standar pemrograman (VPS) • Kesalahan dalam representasi data (EDRIMI) • Kesalahan dalam logika desain (EDL) • Interface modul yang tidak konsisten (IMI) • Pengujian yang tidak lengkap atau keliru (IET) • Dokumentasi yang tidak lengkap atau tidak akurat (IID) • Kesalahan dalam penerjemahan bahasa pemrograman desain (PLT)
Page 117 / 146
http://www.hendra-jatnika.web.id
• Antarmuka manusia dengan komputer yang tidak konsisten atau mengandung ambiguitas (HCI) • Dan msih banyak lagi (MIS) RELIABILITAS PERANGKAT LUNAK Reliabilitas perangkat lunak, tidak seperti faktor kualitas yang lain, dapat diukur, diarahan, dan diestimasi dengan menggunakan data pengembangan historis. Reliabilitas perangkat lunak didefinisikan dalam bentuk statistik sebagai “kemungkinan operasi program komputer bebas kegagalan di dalam suatu lingkungan tertentu dan waktu tertentu”. Kapan saja reliabilitas perangkat lunak dibicarakan, selalu muncul pertanyaan yang sangat penting : Apa yang dimaksudkan dengan bentuk “kegagalan?” dalam konteks dan banyak diskusi mengenai kualitas dan reliabilitas perangkat lunak, kegagalann adalah ketidaksesuaian dengan kebutuhan perangkat lunak. Kegagalan hanya akan mengganggu atau bahkan merupakan bencana. Satu kegagalan dapat diperbaiki dalam beberapa detik sementara kesalahan yang lain mungkin membutuhkan waktu pembetulan berminggu-minggu atau bahkan berbulan-bulan. Pembetulan satu kegagalan kenyataannya dapat menghasilkan kesalahan lain yang baru yang mungkin akan membawa lagi kesalahan yang lain lagi.
t e N
a r d
By
n e H
Pengukuran Reliabilitas dan Availabilitas Kerja awal dalam reliabilitas perangkat lunak berusaha mengekstrapolasi matematika teori reliabitas perangkat keras. Sebagian besar model reliabilitas yang berhubungan dengan perangkat Page 118 / 146
http://www.hendra-jatnika.web.id
keras didasarkan pada kegagalan sehubungan dengan keusangan (wear), bukan kesalahan karena cacat desain. Dalam perangkat keras, kegagalan sehubungan dengan keusangan fisik (misalnya pengaruh suhu, korosi, kejutan) lebih banyak terjadi daripada kegagalan karena isu. Akan tetapi, yang terjadi pada perangkat lunak adalah hal yang sebaliknya. Kenyataannya, semua kegagalan perangkat lunak dapat ditelusuri ke dalam desain atau masalah implementasi; keusangan tidak tercakup. Masih ada perdebatan yang terjadi di seputar hubunan antara konsep kunci dalam reliabilitas perangkat keras dan kemampuan aplikasinya terhadap perangkat lunak. Meskipun ada hubungan yang tidak dapat dibantah, namun sangat penting untuk memprtimbangkan beberapa konsep sederhana yang berlaku untuk kedua sistem elemen tersebut.
t e N
a r d
n e H suatu sistem yang berbasis Bila kita andaikan By reliabilitas secara sederhana komputer, pengukuran adalah berupa mean time between failure (MTBF), dimana : MTBF = MTTF + MTTR (Akronim MTTF adalah mean time to failure dan MTR berarti mean time to repair.) Banyak peneliti berpendapat bahwa MTBF merupakan pengukuran yang jauh lebih berguna daripada pengukuran cacat/KLOC. Secara sederhana dapat dikatakan bahwa seorang pemakai akhir lebih memperhatikan kegagalan, bukan jumlah cacat. Karena masing-masing cacat yangada pada sebuah program tidak memiliki tingkat kegagalan yang sama, maka penghitungan cacat total hanya memberikan sedikit indikasi tentang reliabilitas sistem. Page 119 / 146
http://www.hendra-jatnika.web.id
Contohnya adalah sebuah program yang telah beroperasi selama 14 bulan. Banyak cacat mungkin tidak terdeteksi dalam jumlah waktu yang lama sampai pada akhirnya cacat itu ditemukan. MTBF dari cacat yang tidak jelas seperti itu dapat berlangsung sampai 50, bahkan 100 tahun. Cacat yang lain, yang juga belum ditemukan, dapat memiliki tingkat kegagalan 18 atau 24 bulan. Meskipun setiap kategori pertama cacat (yang memiliki MTBF panjang) dihilangkan, pengaruhnya pada reliabilitas perangkat lunak tidak dapat diabaikan. Availabilitas perangkat lunak adalah kemungkinan sebuah program beroperasi sesuai dengan kebutuhan pada suatu titik yang diberikan pada suatu waktu dan didefinisikan sebagai :
t e N
Availabilitas = MTTF / (MTTF + MTTR) x 100 %
a r d
n e H
Pengukuran reliabilitas MTBF sama sensitifnya dengan MTTF dan MTTR. Pengukuran availabilitas jauh lebih sensitif daripada MTTR, yang merupakan pengukuran tidak langsung terhadap kemampuan pemeliharaan perangkat lunak.
By
Keamanan Perangkat Lunak dan Analisis Risiko Leveson membicarakan pengaruh perangkat lunak dalam sistem kritis keamanan ketika menulis : Sebelum perangkat lunak digunakan di dalam sistem kritis keamanan, perangkat lunak itu sering dikontrol oleh alat mekanik konvensional (tidak dapat diprogram) dan elektronik. Teknik keamanan sistem didesain untuk mengatasi kegagalan acak dalam sistem-sistem tersebut. Kesalahan perancangan oleh manusia dapat sepenuhnya dihindari atau dihilangkan sebelum Page 120 / 146
http://www.hendra-jatnika.web.id
perangkat lunak dioperasikan.
tersebut
diluncurkan
dan
Ketika perangkat lunak diguanakn sebagai bagian dari sistem kontrol, kompleksitasnya dapat bertambah dengan satu urutan besaran atau lebih. Kesalahan desain yang tidak kentara yang disebabknan oleh kesalahan manusia – sesuatu yang dapat diunkapkan dan dikurangi dalam kontrol konvensional berbasis perangkat keras – menjadi lebih sulit ditemukan pada waktu perangkat lunak digunakan. Keamanan perangkat lunak dan analisis risiko adalah aktivitas jaminan kualitas perangkat lunak yang berfokus pada identifikasi dan penilaian risiko potensial yang mungkin berpengaruh negatif terhadap perangkat lunak dan menyebabkan seluruh sistem menjadi gagal. Jika risiko dapat diidentifikasi pada awal proses rekayasa perangkat lunak, maka ciri-ciri desain perangkat lunak dapat ditetapkan sehingga akan mengeliminasi atau mengontrol risiko potensial.
t e N
a r d
By
n e H
Proses analisis dan modeling dilakukan sebagai bagian dari keamanan perangkat lunak. Awalnya, risiko diidentifikasi dan dipilah-pilahkan berdasarkan kekritisan dan risiko. Sebagai contoh, beberapa risiko yang berkaitan dengan kontrol peluncuran berbasis komputer untuk automobil mungkin: • Menyebabkan percepatan yang tidak terkontrol tidak dapat dihentikan • Tidak lepas ketika pedal rem ditekan • Tidak nyambung ketika skalar diaktifkan • Perlahan-lahan kehilangan atau menambah kecepatan
Page 121 / 146
http://www.hendra-jatnika.web.id
Setelah risiko tingkat sistem diidentifikasi, maka digunakan teknik analisis untuk menandai kehebatan dan probabilitas event. Supaya efektif, perangkat lunak harus dianalisis dalam konteks keseluruhan sistem. Sebagai contoh, kesalahan input pemakai yang tidak kentara (manusia sebagai komponen sistem) dapat diperbesar oleh kesalahan perangkat lunak, sehingga menghasilkan data kontrol yang memposisikan sebuah perangkat lunak, sehingga menghasilkan data kontrol yang memposisikan sebuah perangkat mekanik secara tidak tepat. Jika ada serangkaian kondisi lingkungan eksternal (dan hanya jika mereka ditemui), maka posisi perangkat mekanik yang tidak tepat dapat menyebabkan kegagalan fatal. Teknik analisis seperti analisis pohon kegagalan, logika real-time , atau model Petrinet , dapat digunakan untuk memprediksi rantai event yang dapat mengakibatkan risiko dan kemungkinan di mana setiap event akan terjadi untuk menciptakan rantai.
t e N
a r d
By
n e H
Analisis pohon kesalahan membangun model grafis dan kombinasi event yang konkuren dan berurutan yang dapat menyebabkan suatu event atau sistem yang penuh risiko. Dengan menggunakan pohon kesalahan yang dikembangkan dengan baik, maka dimungkinkan untuk meneliti kosekuensi urutan kegagalan yang terinterelasi yang terjadi pada komponen sistem yang berbeda. Logika real-time (RTL) membangun sebuah model sistem dengan menentukan event dan aksi yang sesuai. Model event-action dapat dianalisis dengan menggunakan operasi logika untuk menguji tuntutan keamanan seputar komponen sistem dan timing-nya. Model Petrinet dapat digunakan untuk menentukan kesalahan yang paling berisiko.
Page 122 / 146
http://www.hendra-jatnika.web.id
Sekali risiko diidentifikasi dan dianalisis, maka keamanan yang berhubungan dengan kebutuhan untuk perangkat lunak dapat ditetapkan. Spesifikasi dapat berupa sederetan event yang tidak diinginkan dan sistem yang diinginkan merespon event tersebut. Peran perangkat lunak dalam mengatur event yang tidak diinginkan kemudian diindikasi. Meskipun reliabilitas perangkat lunak berhubungan erat satu sama lain dengan lainnya, namun sangat penting untuk memahami perbedaan tipis yang ada di antara mereka. Reliabilitas perangkat lunak menggunakan analisis statistik untuk menentukan kemungkinan terjadinya kegagalan perangkat lunak. Tetapi kegagalan tidak perlu menghasilkan risiko atau kecelakaan. Kemanan perangkat lunak mengamati bagaimana kegagalan menimbulkan keadaan yang dapat menyebabkan kecelakaan. Kegagalan tidak perlu dipertimbangkan di dalam ruang hampa, tetapi dievaluasi dalam konteks keseluruhan sistem berbasis komputer.
t e N
a r d
By
n e H
Diskusi komprehensif tentang analisis risiko dan keamanan perangkat lunak tidak masuk dalam ruang lingkup buku ini. Pembaca yang tertarik untuk mengetahui lebih jauh tentang hal tersebut sebaiknya membaca buku yang ditulis oleh Leveson . RENCANA SQA SQA plan menjadi peta jalan untuk membangun jaminan kualitas perangkat lunak. Dikembangkan oleh kelompok SQA dan tim proyek, rencana itu berfungsi sebagai template bagi aktifitas SQA yang dibangun untuk setiap proyek perangkat lunak. Gambar 8.5 memperlihatkan sebuah outline untuk rencana SQA yang disetujui oleh IEEE . Bagian Page 123 / 146
http://www.hendra-jatnika.web.id
awal menggambarkan tujuan dan ruang lingkup dokumen dan menunjukkan aktivitas proses perangkat lunak yang diungkap oleh jaminan kualitas. Semua dokumen yang dicatat oleh rencana SQA didaftar dan semua standar yang dapat diapliksikan dicatat. Bagian Manajemen dari rencana tersebut menggambarkan tempat SQA pada struktur organisasi; tugas-tugas dan aktivitas SQA dan penempatannya di seluruh proses perangkat lunak; dan peran organisasional serta tanggung jawab relatif terhadap kualitas produk. Bagian Dokumentasi menggambarkan (dengan refernsi) masing-masing produk kerja yang dihasilkan sebagai bagian dari proses perangkat lunak; mencakup hal-hal berikut :
t e N
• Dokumen proyek (misalnya, rencana proyek) • Model (misalnya, hirarki kelas ERD) • Dokumen teknis (misalnya, spesifikasi, rencana pengujian) • Dokumen pemakai (misalnya file0file help)
a r d
By
n e H
Sebagai tambahan, bagian ini menentukan serangkaian produk kerja minmum yang dapat diterima untuk mencapai kualitas yang tinggi. Standar, Praktik dan Konversi mencatat semua standar/praktik yang diterapkan selama proses perangkat lunak (misalnya, standar dokumen, stadar pengkodean, dan pedoman kajian). Semua proyek, proses, dan metrik produk yang dikumpulkan sebagai bagian dari usaha rekayasa perangkat lunak juga harus dicatat. Bagian Kajian dan Audit dari rencana mengidentifiaksi kajian dan audit yang akan dilakukan oleh tim rekayasa perangkat lunak, kelompok SQA, Page 124 / 146
http://www.hendra-jatnika.web.id
dan pelanggan. Bagian ini memberikan gambaran yang luas terhadap pendekatan bagi masing-masig kajian dan audit. I. Tujuan Rencana II. Referensi III. Manajemen 1. Organisasi 2. Tugas 3. Tanggung jawab IV. Dokumentasi 1. Tujuan 2. Dokuen rekayasa perangkat lunak yang diperlukan 3. Dokumen-dokumen lain V. Standar, Praktis dan Konversi 1. Tujuan 2. Konvensi VI. Tinjauan dan Audit 1. Tujuan 2. Tinjauan a. Kebutuhan perangkat lunak b. Desain c. Verifikasi dan validasi perangkat lunak d. Audit fungsional e. Audit fisik f. Audit in-process g. Manajemen VII. Pengujian VIII. Pelaporan Masalah dan Tindakan Koreksi IX. Peranti, Teknik, dan Metodologi X. Kontrol Kode XI. Kontrol Media XII. Kontrol Pemasok XIII. Pengumpulan, Pemeliharaan, dan Penyimpanan Catatan XIV. Pelatihan XV. Manajemen Risiko
t e N
a r d
By
n e H
Gambar 8.5 Rencana kualitas jaminan perangkat lunak standar ANSI/IEEE 730 – 1984 dan 983-1986 Bagian pengujian merujuk rencana dan prosedur pengujian perangkat lunak (Bab17). Bagian ini juga menentukkan kebutuhan penyimpanan rekaman pengujian. Pelaporan Masalah dan Tindakan Korektif menentukan prosedur untuk pelaporan, pelacakan, Page 125 / 146
http://www.hendra-jatnika.web.id
dan pembetulan kesalahan serta cacat, juga mengidentifikasi tanggung jawab organisaional untuk akyivitas-aktivitas tersebut. Bagian akhir rencana SQA adalah mengidentifikasi peranti dan metode yang mengandung aktifitas dan tugas-tugas SQA; merujuk manajemen konfigurasi perangkat lunak untuk mengontrol perubahan; menetapkan pendekatan manajemen kontrak; membangun metode perakitan, perlindungan dan pemeliharaan semua catatan; mengidentifikasi pelatihan yang dibutuhkan untuk memenuhi kebutuhan rencana, serta menetapkan metodemetode untuk mengidentifikasi, menilai, memonitor, dan mengontrol risiko. STANDAR KUALITAS ISO 9000
t e N
a r d
Sistem jaminan kualitas dapat didefinisikan sebagai strukutr, tanggung jawab, prosedur, proses dan sumber-sumber daya organisasi untuk mengimplementasi manajemen kualitas. ISO 9000 menjelaskan elemen jaminan kualitas dalam bentuk yang umum yang dapat diaplikasikan pada berbagai bisnis tanpa memandang produk dan jasa yang ditawarkan.
By
n e H
Agar terdaftar dalam satu model sistem jaminan kualitas yang ada pada ISO 9000, sistem kualitas dan operasi perusahaan diperiksa oleh auditor bagian ketiga untuk memeriksa kesesuaiannya dengan standar dan operasi efektif. Bila registrasi itu berhasil, perusahaan diberi sertifikat dari badan registrasi yang diwakili oleh auditor. Audit pengawasan tegah tahuan terus dilakukan untuk memastikan kesesuaiannya dengan standar yang sudah ditetapkan.
Page 126 / 146
http://www.hendra-jatnika.web.id
Pendekatan Kualitas
ISO
terhadap
Sistem
Jaminan
Model jaminan kualitas ISO 9000 memperlakukan perusahaan sebagai jaringan proses yang saling terhubung (interkoneksi). Suatu sistem kualitas, supaya sesuai dengan ISO, proses-prosesnya harus menekankan pada area yang telah diidentifikasi pada standar ISO, dan harus didokumentasi dan dipraktikan sebagimana dikelaskan. Pendokuemnatsian proses membantu organisasi untuk memahami, mengontrol, dan mengembangkan jaringan proses yang mungkin dapat mendatangkan keuntunagn terbesar bagi organisasi yang merancang dan mengimplementasikan kualitas yang sesuai dengan ISO.
t e N
ISO 9000 menggambarkan elemen sebuah sistem jaminan kualitas secara umum. Elemenelemen tersebut mencakup struktur, prosedur, proses, organisasi, dan sumber day ayang dibutuhkan untuk mehimplementasi rencana kualitas, kontrol kualitas, jaminan, kualitas, dan pengembangan kualiats. Tetapi ISO 9000 tidak menggambarkan bagaimanan organisasi seharusnya mengimpelemnatsi elemenelemen kualitas tersebut. Sebagai konsekuensi, ada tantangan dalam mendesain dan mengimplementasi suatu sistem jaminan kualitas yang memenuhi standar dengan produk, layanan dan budaya perusahaan.
a r d
By
n e H
Standar ISO 9001 ISO 9001 adalah standar kualitas yang berkalu untuk rekayasa perangkat lunak. Standar tersebut berisi 20 syarat yang harus ada untuk mencapai sistem jaminan kualitas yangefektif. Karena standar ISO 9001 dapat diaplikasikan pada semua disiplin Page 127 / 146
http://www.hendra-jatnika.web.id
rekayasa / engineering, maka dikembangkan sekumpulan khusus pedoman ISO untuk membantu menginterpretsi standar untuk digunakan pada proses perangkat lunak. Dua puluh syarat yang digambarkan oleh ISO 9001 menekankan topik-topik berikut : 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Tanggung jawab manajemen Sistem kualitas Kajian kontrak Kontrol desain Kontrol data dan dokumen Pembelian Kontrol terhadap produk yang disuplai oleh pelanggan Identifikasi dan kemampuan penelusuran produk Kontrol proses Pemeriksaan dan pengujian Kontrol pemeriksaan, pengukuran, dan perlengkapan pengujian Pemeriksaan dan status pengujian Kontrol ketudaksesuaian produk Tindakan preventif dan korektif Penanganan, penyimpanan, pengepakan, preservasi, dan penyampaian Kontrol terhadap catatan kualitas Audit kualitas internal Pelatihan Pelayanan Teknik statistik
t e N
a r d
By
n e H
Page 128 / 146
http://www.hendra-jatnika.web.id
Untuk dapat didaftar dalam ISO 9001, organisasi perangkat lunak harus membuat kebijakan dan prosedur yang memberi tekanan pada masing-masing syarat tersebut dan kemudian dapat menunjukkan bahwa prosedur dan fungsi itu telah diikuti. Untuk penjelsan leih lanjt, pembaca yang tertarik dengan informasi mengnenai ISO 9001.
t e N
a r d
By
n e H
Page 129 / 146
http://www.hendra-jatnika.web.id
BAB 9 PENGUJIAN PERANGKAT LUNAK Pengujian PL adalah elemen kritis dari jaminan kualitas PL dan merepresentasikan spesifikasi, desain dan pengkodean. Meningkatnya visibilitas PL sbg suatu elemen sistem dan "biaya” yg muncul akibat kegagalan PL, memotivasi dilakukan perencanaan yg baik melalui pengujian yg teliti. Dalam melakukan uji coba ada 2 masalah penting yang akan dibahas, yaitu : A. Teknik uji coba PL B. Strategi uji coba PL TEKNIK UJI COBA PL Pada dasarnya, pengujian merupakan suatu proses rekayasa PL yg dapat dianggap (secara psikologis) sebagai hal yg destruktif daripada konstruktif. SASARAN PENGUJIAN (Glen Myers) : 1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan. 2. Test case yg baik adalah test case yg memiliki probabilitas tinggi untuk menemukan kesalahan yg belum pernah ditemukan sebalumnya. 3. Pengujian yg sukses adalah pengujian yg mengungkap semua kesalahan yg belum pernah ditemukan sebelumnya.
t e N
a r d
By
n e H
PRINSIP PENGUJIAN (diusulkan Davis) : • Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan. • Pengujian harus direncanakan lama sebelum pengujian itu dimulai. • Prinsip Pareto berlaku untuk pengujian PL. Prinsip Pareto mengimplikasikan 80% dari semua kesalahan yg ditemukan selama pengujian sepertinya akan dapat ditelusuri sampai 20% dari semua modul program. • Pengujian harus mulai "dari yg kecil" dan berkembang ke pengujian "yang besar". • Pengujian yg mendalam tidak mungkin. • Paling efektif, pengujian dilakukan oleh pihak ketiga yg independen.
Page 130 / 146
http://www.hendra-jatnika.web.id
TESTABILITAS Testabilitas PL adalah seberapa mudah sebuah program komputer dapat diuji. Karena pengujian sangat sulit, perlu diketahui apa yg dapat dilakukan untuk membuatnya menjadi mudah. Karakteristik PL yg diuji : • OPERABILITAS, semakin baik dia bekerja semakin efisien dia dapat diuji. • OBSERVABILITAS, apa yg anda lihat adalah apa yg anda uji. • KONTROLABILITAS, semakin baik kita dapat mengontrol PL semakin banyak pengujian yg adapat diotomatisasi dan dioptimalkan. • DEKOMPOSABILITAS, dengan mengontrol ruang lingkup pengujian kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali. • KESEDERHANAAN, semakin sedikit yg diuji semakin cepat pengujian. • STABILITAS, semakin sedikit perubahan semakin sedikit gangguan pengujian. • KEMAMPUAN DIPAHAMI, semakin banyak informasi yg dimiliki semakin detail pengujiannya.
t e N
a r d
ATRIBUT PENGUJIAN YG BAIK : • Memiliki probabilitas yg tinggi menemukan kesalahan. • Tidak redundan. • Harusnya ‘jenis terbaik’. • Tidak boleh terlalu sederhana atau terlalu kompleks.
By
n e H
DESAIN TEST CASE Terdapat bermacam-macam rancangan metode test case yg dapat digunakan, semua menyediakan pendekatan sistematis untuk uji coba, yg terpenting metode menyediakan kemungkinan yg cukup tinggi menemukan kesalahan. Terdapat 2 macam test case: 1. Pengetahuan fungsi yg spesifik dari produk yg telah dirancang untuk diperlihatkan, test dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan sebagaimana yg diharapkan. 2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya.
Page 131 / 146
http://www.hendra-jatnika.web.id
Dua macam pendekatan test yaitu : 1. Black Box Testing Test case ini bertujuan untuk menunjukkan fungsi PL tentang cara beroperasinya, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya. 2. White Box Testing Adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur logika) perangkat lunak akan ditest dengan menyediakan test case yang akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%. UJI COBA WHITE BOX Uji coba white box adalah metode perancangan test case yang menggunakan struktur kontrol dari perancangan prosedural untuk mendapatkan test case. Dengan rnenggunakan metode white box, analis sistem akan dapat memperoleh test case yang: • menjamin seluruh independent path di dalam modul yang dikerjakan sekurang-kurangnya sekali • mengerjakan seluruh keputusan logikal • mengerjakan seluruh loop yang sesuai dengan batasannya • mengerjakan seluruh struktur data internal yang menjamin validitas
t e N
a r d
By
n e H
1. UJI COBA BASIS PATH Uji coba basis path adalah teknik uji coba white box yg diusulkan Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan menggunkan ukuran ini sbg petunjuk untuk mendefinisikan basis set dari jalur pengerjaan. Test case yg didapat digunakan untuk mengerjakan basis set yg menjamin pengerjaan setiap perintah minimal satu kali selama uji coba. 1.1. Notasi diagram alir Sequence
if
while
until
Gambar 9.1
Page 132 / 146
case
http://www.hendra-jatnika.web.id
Untuk menggambarkan pemakaian diagram alir perancangan prosedural dalam bentuk flowchart
diberikan
contoh
1
2
3
6
4
7
8
5
9 10 11
Gambar 9.2 Diagram Alir
t e N
Selanjutnya diagram alir diatas dipetakan ke grafik alir
a r d
By
n e H
node
Gambar 9.3 Grafik Alir Lingkaran/node : menggambarkan satu/lebih perintah prosedural. Urutan proses dan keputusan dapat dipetakan dalam satu node. Tanda panah/edge : menggambarkan aliran kontrol. Setiap node harus mempunyai tujuan node Region : adalah daerah yg dibatasi oleh edge dan node. Termasuk daerah diluar grafik alir.
Page 133 / 146
http://www.hendra-jatnika.web.id
Contoh menterjemahkan pseudo code ke grafik alir
1: do while record masih ada baca record 2: if record ke 1 = 0 3: then proses record simpan di buffer naikan kounter 4: else if record ke 2 = 0 5 then reser kounter 6 proses record simpan pada file 7a: endif endif 7b: enddo 8 : end
t e N
a r Gambar 9.4 Menerjemahkan d PDL ke grafik Alir n e H Nomor pd pseudo code berhubungan dengan nomor node. Apabila y B diketemukan kondisi majemuk (compound condition) pada pseudo cade pembuatan grafik alir menjadi rumit. Kondisi majemuk mungkin terjadi pada operator Boolean (AND, OR, NAND, NOR) yg dipakai pada perintah if. Contoh :
if A or B then procedure x else procedure y endif
Gambar 9.5 Logika Gabungan
Page 134 / 146
http://www.hendra-jatnika.web.id
Node dibuat terpisah untuk masing-masing kondisi A dan B dari pernyataan IF A OR B. Masing-masing node berisi kondisi yg disebut pridicate node dan mempunyai karakteristik dua atau lebih edge darinya. 1.2. CYCLOMATIC COMPLEXITY Cyclomatic complexity adalah metrik PL yang menyediakan ukuran kuantitatif dari kekompleksan logikal program. Apabila digunakan dalam kontek metode uji coba basis path, nilai yang dihitung untuk cyclomatic complexity menentukan jumlah jalur independen dalam basis set suatu program dan memberi batas atas untuk jumlah uji coba yang harus dikerjakan untuk menjamin bahwa seluruh perintah sekurang-kurangnya telah dikerjakan sekali. Jalur independent adalah jalur yang melintasi atau melalui program dimana sekurang-kurangnya terdapat proses perintah yang baru atau kondisi yang baru. Dari gambar 9.3 : Path 1 : 1 - 11 Path 2 : 1 - 2 - 3 - 4 - 5 - 10 - 1 - 11 Path 3 : 1 - 2 - 3 - 6 - 8 - 9 ...: 10 - 1 - 11 Path 4 ': 1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11 Path 1,2,3,4 yang telah didefinisikan di atas merupakan basis set untuk diagaram alir.
t e N
a r d
By
n e H
Cyclomatic complexity digunakan untuk mencari jumlah path dalam satu flowgraph. Dapat dipergunakan rumusan sbb : 1. Jumlah region grafik alir sesuai dengan cyclomatic complexity. 2. Cyclomatix complexity V(G) untuk grafik alir dihitung dengan rumus: V(G) = E - N + 2 dimana: E = jumlah edge pada grafik alir N = jumlah node pada grafik alir 3. Cyclomatix complexity V(G) juga dapat dihitung dengan rumus: V(G) = P + 1 dimana P = jumlah predicate node pada grafik alir Pada Gambar 9.3 dapat dihitung cyclomatic complexity: 1. Flowgraph mempunyai 4 region 2. V(G) = 11 edge - 9 node + 2 = 4 3. V(G) = 3 predicate node + 1 = 4 Jadi cyclomatic complexity untuk flowgraph Gambar 9.3 adalah 4
Page 135 / 146
http://www.hendra-jatnika.web.id
1.3. MELAKUKAN TEST CASE Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci atau program sumber. Pada bagian ini akan dijelaskan langkah-langkah uji coba basis path. Prosedur rata-rata pada bagian berikut akan digunakan sebagai contoh dalam pembuatan test case. PROCEDURE RATA-RATA INTERFACE RESULT rata, total, input, total.valid INTERFACE RESULT nilai, minim, max TYPE NILAl (1:100) IS SCALAR ARRAY; TYPE rata, total. input, total.valid, max.minim, jumlah IS SCALAR; TYPE I IS INTEGER; I = 1; total. input = total. valid = 0; jumlah = 0; DO WHILE nilai(i) <> -999 .and. total.input < 100 tambahkan total.input dengan 1; IF nilai(i) >= minimum .and. nilai(i} <=max; THEN tambahkan total.valid dengan I; jumlah=jumlah + nilai(i); ELSE skip; END IF tambahkan i dengan 1; ENDDO IF total. valid> 0 THEN rata =jumlah/total. valid; ELSE rata = -999; ENDIF END
t e N
a r d
By
n e H
Langkah-Iangkah pembuatan test case: 1. Dengan mempergunakan perancangan prosedural atau program sumber sebagai dasar, digambarkan diagram alirnya.
Gambar 9.6 Diagram Alir prosedur rata
Page 136 / 146
http://www.hendra-jatnika.web.id
2. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat: V(G) = 6 region . V(G) = 17 edge - 13 node + 2 = 6 V(G) = 5 predicate node + 1 = 6 3. Tentukan independent path pada flowgraph Dari hasil perhitungan cyclomatic complexity terdapat 6 independent path yaitu: path 1 : 1-2-10-11-13 path 2 : 1-2-10-12-13 path 3 : 1-2-3-10-11-13 path 4 : 1-2-3-4-5-8-9-2-.. path 5 : 1-2-3-4-5-6-8-9-2-.. path 6 : 1-2-3-4-5-6-7-8-9-2-... 4. Buat test case yang akan mengerjakan masing-masing path pada basis set. Data yang dipilih harus tepat sehingga setiap kondisi dari predicate node dikerjakan semua. 1.4. GRAPH METRIK
t e N
Graph metrik merupakan PL yang dikembangkan untuk membantu uji coba basis path atau struktur data. Graph metrik adalah matrik empat persegi yang mempunyai ukuran (sejumlah baris dan kolom) yang sama dengan jumlah node pada flowgraph. Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah ditentukan dan pemasukan data matrik berhubungan dengan hubungan (edge) antanode.
a r d
By
n e H
Contoh sederhana pemakaian graph matrik dapat digambarkan sbb :
Gambar 9.7. Graph matrik Pada gambar flowgraph masing-masing node ditandai dengan angka clan edge dengan huruf kecil, kemudian diterjemahkan ke graph matrik. Contoh hubungan node 3 dengan node 4 pada graph ditandai dengan huruf b.
Page 137 / 146
http://www.hendra-jatnika.web.id
Hubungan bobot menyediakan tambahan informasi tentang aliran kontrol. Secara simpel hubungan bobot dapat diberi nilai 1 jika ada hubungan antara node atau nilai 0 jika tidak ada hubungan. Dapat juga hubungan bobot diberi tanda dengan: • • • •
kemungkinan link (edge) dikerjakan waktu yang digunakan untuk proses selama traversal dari link memori yang diperlukan selama traversal link sumber daya yang diperlukan selama traversal link
Gambar 9.8 Hubungan bobot Koneksi : 1–1=0 2–1=1 2–1=1 2–1=1 3 + 1 = 4 cyclomatic complexity
t e N
a r d
By
n e H
2. PENGUJIAN LOOP Loop merupakan kendala yang sering muncul untuk menerapkan algoritma dengan tepat. Uji coba loop merupakan teknik pengujian white box yg fokusnya pada validitas dari loop. Kelas loop yaitu : a. Loop Sederhana, pengujian loop sederhana dilakukan dgn mudah, dimana n jumlah maksimum yg diijinkan melewati loop tsb. 1. Lewati loop secara keseluruhan 2. Hanya satu yg dapat melewati loop 3. m dapat melewati loop dimana m< n b. Loop Tersarang, pengujian loop ini menggunakan pendekatan loop sederhana. Petunjuk pengujian loop tersarang : 1. Dimulai dari loop paling dalam. Atur semua loop ke nilai minimum. 2. Kerjakan dgn prinsip loop sederhana untuk loop yg paling dalam sementara tahan loop yg di luar pada parameter terkecil (nilai kounter terkecil)
Page 138 / 146
http://www.hendra-jatnika.web.id
3. Kemudian lanjutkan untuk loop yg diatasnya. 4. Teruskan sampai semua loop selesai di uji. c. Loop Terangkai, pengujian loop ini menggunakan pendekatan loop sederhana bila masing-masing loop independen, tetapi bila dua loop dirangkai dan pencacah loop 1 digunakan sebagai harga awal loop 2 maka loop tsb jadi tidak independen, maka pendekatan yg diaplikasikan ke loop tersarang direkomendasikan. d. Loop Tidak Terstruktur, Kapan saja memungkinkan, loop ini didisain kembali agar mencerminkan penggunaan komsepsi pemrograman tertruktur.
Loop sederhana
Loop tersarang
t e N
a r d
By
n e H
Loop terangkai
Loop tidak terstruktur
Gambar 9.9. Macam-macam loop
PENGUJIAN BLACK-BOX Pengujian black-box berfokus pada persyaratan fungsional PL. Pengujian inimemungkinkan analis system memperoleh kumpulan kondisi input yg akan mengerjakan seluruh keperluan fungsional program. Tujuan metode ini mencari kesalaman pada: • Fungsi yg salah atau hilang • Kesalahan pada interface • Kesalahan pada struktur data atau akses database • Kesalahan performansi • Kesalahan inisialisasi dan tujuan akhir Metode ini tidak terfokus pada struktur kontrol seperti pengujian whitebox tetapi pada domain informasi.
Page 139 / 146
http://www.hendra-jatnika.web.id
Pengujian dirancang untuk menjawab pertanyaan sbb: • Bagaimana validitas fungsional diuji? • Apa kelas input yg terbaik untuk uji coba yg baik? • Apakah sistem sangat peka terhadap nilai input tertentu? • Bagaimana jika kelas data yang terbatas dipisahkan? • Bagaimana volume data yg dapat ditoleransi oleh sistem? • Bagaimana pengaruh kombinasi data terhadap pengoperasian system? 1. EQUIVALENCE PARTITIONING Equivalence partitioning adalah metode pengujian black-box yg memecah atau membagi domain input dari program ke dalam kelas-kelas data sehingga test case dapat diperoleh. Perancangan test case equivalence partitioning berdasarkan evaluasi kelas equivalence untuk kondisi input yg menggambarkan kumpulan keadaan yg valid atau tidak. Kondisi input dapat berupa nilai numeric, range nilai, kumpulan nilai yg berhubungan atau kondisi Boolean.
t e N
Contoh : Pemeliharaan data untuk aplikasi bank yg sudah diotomatisasikan. Pemakai dapat memutar nomor telepon bank dengan menggunakan mikro komputer yg terhubung dengan password yg telah ditentukan dan diikuti dengan perintah-perintah. Data yg diterima adalah : Kode area : kosong atau 3 digit Prefix : 3 digit atau tidak diawali 0 atau 1 Suffix : 4 digit Password : 6 digit alfanumerik Perintah : check, deposit, dll
a r d
By
n e H
Selanjutnya kondisi input digabungkan dengan masing-masing data elemen dapat ditentukan sbb : Kode area : kondisi input, Boolean – kode area mungkin ada atau tidak kondisi input, range – nilai ditentukan antara 200 dan 999 Prefix : kondisi input range > 200 atau tidak diawali 0 atau 1 Suffix : kondisi input nilai 4 digit Password : kondisi input boolean – pw mungkin diperlukan atau tidak kondisi input nilai dengan 6 karakter string Perintah : kondisi input set berisi perintah-perintah yang telah didefinisikan
Page 140 / 146
http://www.hendra-jatnika.web.id
2. BOUNDARY VALUE ANALYSIS Untuk permasalahan yg tidak diketahui dg jelas cenderung menimbulkan kesalahan pada domain outputnya. BVA merupakan pilihan test case yg mengerjakan nilai yg telah ditentukan, dgn teknik perancangan test case melengkapi test case equivalence partitioning yg fokusnya pada domain input. BVA fokusnya pada domain output. Petunjuk pengujian BVA : 1. Jika kondisi input berupa range yg dibatasi nilai a dan b, test case harus dirancang dgn nilai a dan b. 2. Jika kondisi input ditentukan dgn sejumlah nilai, test case harus dikembangkan dgn mengerjakan sampai batas maksimal nilai tsb. 3. Sesuai petunjuk 1 dan 2 untuk kondisi output dirancang test case sampai jumlah maksimal. 4. Untuk struktur data pada program harus dirancang sampai batas kemampuan. STRATEGI PENGUJIAN PL Strategi uji coba PL memudahkan para perancang untuk menentukan keberhasilan system yg telah dikerjakan. Hal yg harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yg diperlukan. Strategi uji coba mempunyai karakteristik sbb : • Pengujian mulai pada tingkat modul yg paling bawah, dilanjutkan dgn modul di atasnya kemudian hasilnya dipadukan. • Teknik pengujian yang berbeda mungkin menghasilakn sedikit perbedaan (dalam hal waktu) • Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatu kelompok pengujian yang independen. • Pengujian dan debugging merupakan aktivitas yang berbeda, tetapi debugging termasuk dalam strategi pengujian.
t e N
a r d
By
n e H
Pengujian PL adalah satu elemen dari topik yang lebih luas yang sering diacu sebagai verifikasi dan validasi (V& V). Verifikasi : Kumpulan aktifitas yg menjamin penerapan PL benar-benar sesuai dgn fungsinya. Validasi : Kumpulan aktivitas yang berbeda yang memastikan bahwa PL yang dibangun dapat memenuhi keperluan pelanggan. Dgn kata lain : Verifikasi : “ Apakah kita membuat produk dgn benar?” Validasi : “ Apakah kita membuat benar-benar suatu produk?”
Page 141 / 146
http://www.hendra-jatnika.web.id
Definisi dari V&V meliputi berbagai aktivitas yang kita rujuk sebagai jaminan kualias PL (SQA). Pengujian merupakan salah satu tugas yg ada dlm arus siklus pengembangan system yg dapat digambarkan dalam bentuk spiral : Rekayasa sistem Persyaratan Desain Kode Tes unit Tes integrasi Tes validasi Tes sistem
Gambar 9.10. Strategi Uji Coba
1. PENGUJIAN UNIT
t e N
Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain PL, yakni modul. Uji coba unit selalu berorientasi pada white box testing dan dapat dikerjakan paralel ayau beruntun dengan modul lainnya.
a r d
n e H
y B 1.1 Pertimbangan Pengujian Unit
Interface diuji cobakan untuk menjamin informasi yg masuk atau yg ke luar dari unit program telah tepat atau sesuai dgn yg diharapkan. Yg pertama diuji coba adalah interface karena diperlukan untuk jalannya informasi atau data antar modul. Myers mengusulkan checklist untuk pengujian interface: • • • •
Apakahjumlah parameter input sama dengan jumlah argumen? Apakah antara atribut dan parameter argumen sudah cocok? Apakah antara sistem satuan parameter dan argumen sudah cocok? Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan jumlah parameter?
• Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter? • Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter? • Apakah jumlah atribut dari urutan argumen ke fungsi-fungsi built-in sudah benar?
Page 142 / 146
http://www.hendra-jatnika.web.id
• Adakah referensi ke parameter yang tidak sesuai dengan pain entri yang ada? • Apakah argumen input-only diubah? • Apakah definisi variabel global konsisten dengan modul? • Apakah batasan yang dilalui merupakan argumen? Bila sebuah modul melakukan I/O ekstemal, maka pengujian interface tambahan harus dilakukan. • Atribut file sudah benar? • Pemyataan OPEN/CLOSE sudah benar? • Spesifikasi format sudah cocok dengan pernyataan I/O? • Ukuran buffer sudah cocok dengan ukuran rekaman? • File dibuka sebelum penggunaan? • Apakah kondisi End-of-File ditangani? • Kesalahan I/O ditangani? • Adakah kesalahan tekstual di dalam informasi output? Kesalahan yang umum di dalam komputasi adalah: • kesalah-pahaman atau prosedur aritmatik yang tidak benar • operasi mode yang tercampur • inisialisasi yang tidak benar • inakurasi ketelitian • representasi simbolis yang tidak benar dari sebuah persamaan.
t e N
a r d
Test • • • • • • •
By
n e H
case harus mengungkap kesalahan seperti perbandingan tipe data yang berbeda preseden atau operator logika yang tidak benar pengharapan akan persamaan bila precision error membuat persamaan yang tidak mungkin perbandingan atau variabel yang tidak benar penghentian loop yang tidak ada atau tidak teratur kegagalan untuk keluar pada saat terjadi iterasi divergen variabel loop yang dimodifikasi secara tidak teratur.
1.2. Prosedur Pengujian Unit Program
sumber
telah dikembangkan, ditunjang
kembali dan
diverifikasi untuk sintaksnya, maka perancangan test case dimulai. Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul bukan program yg berdiri sendiri maka driver (pengendali) dan atau stub PL harus dikembangkan untuk pengujian unit.
Page 143 / 146
http://www.hendra-jatnika.web.id
Driver adl program yg menerima data untuk test case dan menyalurkan ke modul yg diuji dan mencetak hasilnya. Stub melayani pemindahan modul yg akan dipanggil untuk diuji. 2. PENGUJIAN INTEGRASI Pengujian terintegrasi adl teknik yg sistematis untuk penyusunan struktur program, pada saat bersamaan dikerjakan uji coba untuk memeriksa kesalahan yg nantinya digabungkan dengan interface. Metode pengujian • top down integration • buttom up integration 2.1. TOP DOWN INTEGRATION Merupakan pendekatan inkrmental untuk penyusunan struktur program. Modul dipadukan dgn bergerak ke bawah melalui kontrol hirarki dimulai dari modul utama. Modul subordinat ke modul kontrol utama digabungkan ke dalam struktur baik menurut depth first atau breadth first.
t e N
a r d
n e H
Proses integrasi: • modul utama digunakan sebagai test driver dan stub yg menggantikan seluruh modul yg secara langsung berada di bawah modul kontrol utama. • Tergantung pada pendekatan perpaduan yg dipilih (depth / breadth) • Uji coba dilakukan selama masing-masing modul dipadukan • Pada penyelesaian masing-masing uji coba stub yg lain dipindahkan dgn modul sebenarnya. • Uji coba regression yaitu pengulangan pengujian untuk mencari kesalahan lain yg mungkin muncul.
By
2.2. BOTTOM UP INTEGRATION Pengujian buttom up dinyatakan dgn penyusunan yg dimulai dan diujicobakan dgn atomic modul (yi modul tingkat paling bawah pd struktur program). Karena modul dipadukan dari bawah ke atas, proses yg diperlukan untuk modul subordinat yg selalu diberikan harus ada dan diperlukan untuk stub yg akan dihilangkan.
Page 144 / 146
http://www.hendra-jatnika.web.id
Strategi pengujian : • Modul tingkat bawah digabungkan ke dalam cluster yg memperlihatkan subfungsi PL • Driver (program kontrol pengujian) ditulis untuk mengatur input test case dan output • Cluster diuji • Driver diganti dan cluster yg dikombinasikan dipindahkan ke atas pada struktur program
fgd
Cluster 1
t e N
a r d
Gambar 9.11. Buttom Up Integration
y B 3. UJI COBA VALIDASI
n e H
Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi terting. Pengujian validasi dikatakan berhasil bila fungsi yg ada pada PL sesuai dgn yg diharapkan pemakai. Validasi PL merupakan kumpulan seri uji coba black box yg menunjukkan sesuai dgn yg diperlukan. Kemungkinan kondisi setelah pengujian: 1. Karakteristik performansi fungsi sesuai dgn spesifikasi dan dapat diterima. 2. Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar penyimpangan. Pengujian BETA dan ALPHA Apabila PL dibuat untuk pelanggan maka dapat dilakukan aceeptance test sehingga memungkinkan pelanggan untuk memvalidasi seluruh keperluan. Test ini dilakukan karena memungkinkan pelanggan menemukan kesalahan yg lebih rinci dan membiasakan pelanggan memahami PL yg telah dibuat.
Page 145 / 146
http://www.hendra-jatnika.web.id
Pengujian Alpha Dilakukan pada sisi pengembang oleh seorang pelanggan. PL digunakan pada setting yg natural dgn pengembang “yg memandang” melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian. Pengujian Beta Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir PL dalam lingkungan yg sebenarnya, pengembang biasanya tidak ada pada pengujian ini. Pelanggan merekan semua masalah (real atau imajiner) yg ditemui selama pengujian dan melaporkan pada pengembang pada interval waktu tertentu. 4. UJI COBA SISTEM Pada akhirnya PL digabungkan dgn elemen system lainnya dan rentetan perpaduan system dan validasi tes dilakukan. Jika uji coba gagal atau di luar skope dari proses daur siklus pengembangan system, langkah yg diambil selama perancangan dan pengujian dapat diperbaiki. Keberhasilan perpaduan PL dan system yg besar merupakan kuncinya.
t e N
Sistem testing merupakan rentetan pengujian yg berbeda-beda dgn tujuan utama mengerjakan keseluruhan elemen system yg dikembangkan.
a r d
n e H
4.1. Recovery Testing Adalah system testing yg memaksa PL mengalami kegagalan dalam bermacam-macam cara dan memeriksa apakah perbaikan dilakukan dgn tepat.
By
4.2. Security Testing Adalah pengujian yg akan melalukan verifikasi dari mekanisme perlindungan yg akan dibuat oleh system, melindungi dari hal-hal yg mungkin terjadi. 4.3. Strees Testing Dirancang untuk menghadapi situasi yg tidak normal pada saat program diuji. Testing ini dilakukan oleh system untuk kondisi seperti volume data yg tidak normal (melebihi atau kurang dari batasan) atau frkkuensi.
Page 146 / 146