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