4 BAB II KONSEP PEMBANGUNAN SISTEM DARI PERSPEKTIF

BAB II
KONSEP PEMBANGUNAN SISTEM DARI PERSPEKTIF
SOFTWARE ENGINEERING
2.1
Pengantar
Untuk membangun sistem yang handal (reliable) dihadapkan pada kondisi terkini, setiap
software engineer harus memahami dan mengikuti tahapan-tahapan yang telah
ditetapkan di dalam software engineering sebagaimana definisi yang dikeluarkan oleh
IEEE Standard 610.12.
Software engineering is "(1) the application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of
software, that is, the application of engineering to software," and "(2) the
study of approaches as in (1)."
Oleh karena itu dalam pembangunan sistem, setiap software engineer harus memilih
model proses yang paling tepat sehingga dia mendapatkan kemudahan dalam mengelola
dan mengendalikan proses pembangunannya tahap demi tahap.
Walaupun pada
dasarnya pembangunan sistem adalah pekerjaan tim, namun setiap anggota tim juga
harus paham bagaimana proses pembangunan sistem tersebut berjalan sehingga ia dapat
menempatkan posisinya sesuai dengan tahapan yang sedang berjalan.
2.2
Model Proses
Model proses disebut juga dengan aliran kerja (workflow), yakni tata cara bagaimana
elemen-elemen proses berhubungan satu dengan lainnya.
Aliran kerja ini dapat juga
4
disebut dengan siklus hidup (life-cycle) sistem yang dimulai dari sejak sistem diajukan
untuk dibangun hingga saat ia ditarik dari peredaran.
Dalam perspektif software
engineering terdapat beberapa model proses yang dapat diadopsi dalam pembangunan
suatu sistem. Model-model tersebut adalah :
(1)
Model Waterfall.
Ini adalah model proses yang paling umum digunakan
sehingga sering disebut dengan classic life-cycle.
Ia menyarankan
pendekatan sekuensial sistematis pembangunan software yang dimulai dari
penspesifikasian persyaratan-persyaratan (requirement) oleh pengguna yang
berlanjut
melalui
proses
perencanaan,
pemodelan,
konstruksi
dan
penggelaran serta dukungan berlanjut setelah software telah lengkap sesuai
dengan yang dipersyaratkan di awal pembangunannya. Nama setiap tahap
dalam model waterfall dapat berbeda pada referensi yang berbeda, namun
pada dasarnya esensinya tetap sama yakni urutan yang sekuensial dan
sistematis dalam proses pembangunan sistem sebagaimana ditunjukkan pada
Gambar 2.1 dan Gambar 2.2.
Gambar 2.1. Model proses waterfall[2].
(2)
Model Incremental.
Model ini mengkombinasikan elemen-elemen model
proses waterfall yang diaplikasikan secara iteratif.
Ia mengaplikasikan
urutan-urutan linier secara bertingkat selaras dengan berjalannya waktu.
Setiap urutan linier menghasilkan penambahan (increment) pada software
5
yang dikirimkan. Proses model ini menfokuskan pada pengiriman produk
operasional pada setiap penambahannya. Produk awal adalah versi rendah
dari produk akhir namun telah mampu mengakomodir kebutuhan pengguna.
Model proses ini ditampilkan pada Gambar 2.3.
Gambar 2.2. Model proses waterfall[4].
(3)
Model RAD.
Proses model yang ditampilkan pada Gambar 2.4. ini
memberikan penekanan pada siklus pembangunan pendek disebut dengan
Rapid Application Development (RAD). Model RAD adalah adaptasi versi
“kecepatan-tinggi” model waterfall dimana pembangunan cepat dicapai
dengan menggunakan pendekatan konstruksi berbasis komponen.
Jika
persyaratan-persyaratan sistem dipahami dengan baik dan lingkup proyek
dibatasi, proses RAD memudahkan tim pembangun sistem untuk membuat
sistem yang berfungsi penuh dalam rentang waktu yang sangat singkat.
6
Gambar 2.3. Model proses incremental[2].
Gambar 2.3. Model proses RAD[2].
7
(4)
Model Evolutionary Process.
Model proses ini memberikan pendekatan
pembangunan software dari perspektif alami yakni melalui evolusi seiring
dengan berjalannya waktu. Hal ini didasari pada fakta bahwa kadang pada
proses pembangunan software, persyaratan-persyaratan berubah sehingga
batas waktu tidak dapat dicapai. Oleh karena itu, para software engineer
memerlukan suatu life-cycle yang berkembang (evolve) seiring dengan
berjalannya waktu.
Proses model evolutionary bersifat iteratif sehingga
software engineer mempunyai kesempatan untuk menghasilkan software
yang lebih lengkap.
Pendekatan yang dilakukan adalah dengan
mengaplikasikan paradigma prototyping.
Gambar 2.5. Model proses evolutionary dengan paradigma prototyping[2].
(5)
Model Spiral. Model ini diajukan oleh Boehm yang mendeskripsikan suatu
model proses pembangunan software secara evolusi yang menggabungkan
sifat iteratif prototyping dengan aspek-aspek terkendali dan sistematik dari
8
model waterfall. Dengan menggunakan model spiral ini, software dibangun
dalam serangkaian pelepasan evolusi.
Pada iterasi awal, software yang
dilepas ke pengguna mungkin berupa prototype.
Pada iterasi berikutnya,
versi terekayasa yang lebih lengkap diproduksi.
Gambar 2.6. Model proses spiral[2].
(6)
Model Concurrent Development. Model proses ini dapat direpresentasikan
secara skematis sebagai serangkaian aktivitas-aktivitas kerangka kerja,
tindakan-tindakan dan tugas-tugas software engineering, dan keadaankeadaan yang berkaitan dengannya.
Model ini disebut juga dengan
concurrent engineering dan aplikatif pada semua jenis pembangunan
software dan memberikan gambaran yang akurat dari keadaan yang sedang
berlaku dalam proyek. Model proses ini dipresentasikan pada Gambar 2.7.
(7)
Model Cleanroom Process. Filosofi proses model ini adalah cost dan timeeffective untuk membentuk suatu pendekatan fabrikasi yang menghindarkan
kerusakan-kerusakan produk. Pendekatan cleanroom membutuhkan disiplin
untuk menghilangkan kesalahan dalam penspesifikasian, perancangan dan
9
fabrikasi produk secara “bersih”. Proses model ini adalah salah satu variasi
dari model proses Formal Methods yang berbasiskan pada persamaanpersamaan matematika. Untuk lebih jelasnya, model proses ini ditampilkan
pada Gambar 2.8.
Gambar 2.7. Model proses concurrent engineering[2].
10
Gambar 2.8. Model proses cleanroom engineering[2].
2.3
Model Proses Implementasi DSS
Untuk mengimplementasikan sistem DSS yang dirancang ditinjau dari perspektif
software engineering, digunakan life-cycle model Waterfall dengan mengadopsi model
proses yang dikeluarkan oleh US Department of Defense standard, DoD2167A –
Military Standard, Defense System Software Development. Model proses ini dapat
dilihat pada Gambar 2.9.
11
Gambar 2.9. Model proses versi DoD-2167A[3],[5].
12
2.4
Kegiatan-kegiatan Software Engineering
Di dalam perancangan dan implementasi software, organisasi software komputer
terdiri dari Computer Software Configuration Item (CSCI) yang terdiri dari
Computer Software Component (CSC) dan Computer Software Unit (CSU)
sebagaimana didokumentasikan di dalam Software Development Plan (SDP).
Pembangunan CSCI, CSC dan CSU didokumentasikan di dalam Software
Development Files (SDF) yang berisi :
(1)
Pertimbangan dan hambatan perancangan.
(2)
Dokumentasi dan data perancangan.
(3)
Informasi jadwal dan status.
(4)
Persyaratan dan pertanggung jawaban uji.
(5)
Prosedur-prosedur, kasus-kasus dan hasil-hasil uji.
Standar di atas digunakan agar proses pembangunan software dapat dikelola
mengikuti jadwal kontrak yang telah ditetapkan di dalam SDP.
Proses
pembangunan software harus melalui aktivitas-aktivitas besar sebagai berikut :
2.4.1
Requirement Phase
Melaksanakan
aktivitas-aktivitas pengumpulan
informasi
dan
data
tentang
requirement system secara fungsional dan non-fungsional.
2.4.2
Analysis (Specification) Phase
Melaksanakan aktivitas-aktivitas System/Software Requirements Analysis.
(1)
System Requirements Analysis/Design. Melaksanakan kegiatan-kegiatan
engineering pendahuluan untuk setiap CSCI.
13
(2)
Software Requirement Analysis.
Melaksanakan kegiatan-kegiatan
engineering lengkap untuk setiap CSCI.
2.4.3
Design Phase
Melaksanakan aktivitas-aktivitas :
(1)
Preliminary Design. Melaksanakan kegiatan perancangan pendahuluan
untuk setiap CSCI agar mengalokasikan kebutuhan-kebutuhan yang
didefinisikan di dalam SRS dan IRS yang berkaitan CSC dari setiap
CSCI.
(2)
Detailed Design. Melaksanakan kegiatan perancangan detil untuk setiap
CSCI agar mengalokasikan kebutuhan-kebutuhan yang didefinisikan di
dalam SRS dan IRS yang berkaitan CSC dari setiap CSCI.
2.4.4
Implementation Phase
2.4.4.1 Coding and CSU Testing
Di sini dilaksanakan kegiatan-kegiatan :
(1)
Pengkodean CSU.
(2)
Pengujian setiap CSU untuk meyakinkan bahwa algoritma dan logika
yang digunakan pada setiap CSU benar dan telah memenuhi spesifikasi
yang telah ditetapkan.
(3)
Pembuatan prosedur yang akan dilaksanakan untuk menguji operasional
setiap CSU.
(4)
Melakukan revisi terhadap dokumentasi perancangan dan kode
sebagaimana mestinya.
(5)
Mendokumentasikan prosedur yang telah dilaksanakan ke dalam SDF.
14
2.4.4.2 CSC Integration and Testing
Di sini dilaksanakan kegiatan-kegiatan dengan:
(1)
Melaksanakan integrasi CSC.
(2)
Pengujian setiap CSC untuk meyakinkan bahwa algoritma dan logika
yang digunakan pada setiap CSC benar dan telah memenuhi spesifikasi
yang telah ditetapkan.
(3)
Melakukan revisi terhadap dokumentasi perancangan dan kode
sebagaimana mestinya.
(4)
Mendokumentasikan prosedur integrasi dan pengujian yang telah
dilaksanakan ke dalam SDF.
2.4.4.3 CSCI Testing
Dilaksanakan kegiatan pengujian fungsional CSCI untuk meyakinkan bahwa
algoritma dan logika yang digunakan benar dan telah memenuhi spesifikasi yang
telah ditetapkan.
2.4.4.4 System Integration and Testing
Dilaksanakan kegiatan integrasi dan pengujian fungsional sistem untuk meyakinkan
bahwa algoritma dan logika yang digunakan benar dan telah memenuhi spesifikasi
yang telah ditetapkan.
2.4.5
Post-delivery Maintenance Phase
Melaksanakan kegiatan dan dukungan pemeliharaan dan dukungan suku cadang
setelah intalasi sistem on-site. Dukungan pemeliharaan di dalam masa jaminan pada
umumnya berupa :
15
2.4.6
(1)
Field service engineer.
(2)
Suku cadang bebas bea.
Retirement Phase
Melaksanakan kegiatan uninstallation sistem dari peralatan yang menggunakannya
untuk kemudian dihapuskan atau dihancurkan.
2.5
2.5.1
Dokumen-dokumen Pembangunan Sistem
Requirement Phase
Pada tahap requirement diterbitkan sebuah dokumen System/Segment Specification
(SSS) yang mendeskripsikan spesifikasi dari sistem dan segmen sisten yang akan
dibangun.
2.5.2
Analysis Phase
Pada
Analysis
Phase
dilakukan
kegiatan-kegiatan
System
Requirement
Analysis/Design dan Software Requirement Analysis yang akan menghasilkan 3
(tiga) dokumen sebagai berikut :
(1)
System/Segment Design Document (SSDD) yang berisi analisa untuk
menentukan alokasi kebutuhan sistem terbaik antara hardware, software
dan personil dalam rangka membagi sistem ke dalam Hardware
Configuration Item (HWCI), CSCI dan operasi manual.
(2)
Software Requirements Specification (SRS) yang mendefinisikan
kebutuhan-kebutuhan engineering pendahuluan untuk setiap CSCI pada
tahap System Requirement Analysis/Design dan kebutuhan-kebutuhan
engineering lengkap pada tahap Software Requirement Analysis.
16
(3)
Interface Requirements Specification (IRS) yang mendokumentasikan
kebutuhan-kebutuhan pendahuluan eksternal interface untuk setiap CSCI
pada tahap System Requirement Analysis/Design dan kebutuhankebutuhan engineering lengkap pada tahap Software Requirement
Analysis.
Untuk pengawasan berjalannya pembangunan software, diterbitkan pula 3 (tiga)
dokumen sebagai sarana kontrol yakni :
(1)
System
Requirements
Review
(SRR)
tahap
System
Requirement
Analysis/Design sebagaimana yang ditetapkan di dalam kontrak pada.
(2)
System Design Review (SDR) pada tahap System Requirement
Analysis/Design sebagaimana yang ditetapkan di dalam kontrak.
(3)
Software Specification Review (SSR) pada tahap Software Requirement
Analysis sebagaimana yang ditetapkan di dalam kontrak.
2.5.3
Design Phase
Pada Design Phase dilakukan kegiatan-kegiatan Preliminary Design dan Detailed
Design yang akan menghasilkan 4 (empat) dokumen sebagai berikut :
(1)
Software Design Document (SDD) yang berisi mengenai perancangan
pendahuluan untuk setiap CSCI agar mengalokasikan kebutuhankebutuhan yang didefinisikan di dalam SRS dan IRS yang berkaitan
dengan CSC dari setiap CSCI pada tahap Preliminary Design dan
perancangan detil pada tahap Detailed Design.
(2)
Interface Design Document (IDD) yang mendefinisikan perancangan
pendahuluan eksternal interface setiap CSCI sebagaimana yang
didokumentasikan di dalam IRS pada tahap Preliminary Design dan
perancangan detil pada tahap Detailed Design.
17
(3)
Software Test Plan (STP) yang berisi uji kualifikasi formal yang harus
dilaksanakan mengikuti persyaratan-persyaratan yang dinyatakan di
dalam SRS.
(4)
Software
Test
Description
(STD)
yang
digunakan
untuk
mendokumentasikan informasi kasus tes dalam STP.
Untuk pengawasan berjalannya pembangunan software, diterbitkan pula 2 (dua)
dokumen sebagai sarana kontrol yakni :
(1)
Preliminary Design Review (PDR) pada tahap Preliminary Design
sebagaimana yang ditetapkan di dalam kontrak
(2)
Critical Design Review (CDR) pada tahap Detailed Design sebagaimana
yang ditetapkan di dalam kontrak.
2.5.4
Implementation Phase
Untuk pengawasan berjalannya kegiatan pada Implementation Phase, diterbitkan
pula 5 (lima) dokumen sebagai sarana kontrol yakni :
(1)
Software Product Specification (SPS) untuk setiap CSCI.
(2)
Software Test Report (STR) untuk setiap CSCI.
(3)
Version
Description
Document
(VDD)
untuk
CSCI
yang
mengidentifikasikan versi CSCI yang akan dikirimkan ke customer.
(4)
Functional Configuration Audit (FCA).
(5)
Physical Configuration Audit (PCA).
18
2.5.5
Post-delivery Maintenance Phase
Pada tahap delivery, harus disertakan dokumen-dokumen sebagai berikut :
(1)
Computer Resource Integrated Support Document (CRISD).
(2)
Computer System Operator's Manual (CSOM).
(3)
Software User's Manual (SUM).
(4)
Software Programmer's Manual (SPM).
(5)
Firmware Support Manual (FSM).
19