4

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

5

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

6

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.

7

Gambar 2.3. Model proses incremental[2].

Gambar 2.3. Model proses RAD[2].

8

(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

9

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 keadaan-

keadaan 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 time-

effective untuk membentuk suatu pendekatan fabrikasi yang menghindarkan

kerusakan-kerusakan produk. Pendekatan cleanroom membutuhkan disiplin

untuk menghilangkan kesalahan dalam penspesifikasian, perancangan dan

10

fabrikasi produk secara “bersih”. Proses model ini adalah salah satu variasi

dari model proses Formal Methods yang berbasiskan pada persamaan-

persamaan matematika. Untuk lebih jelasnya, model proses ini ditampilkan

pada Gambar 2.8.

Gambar 2.7. Model proses concurrent engineering[2].

11

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.

12

Gambar 2.9. Model proses versi DoD-2167A[3],[5].

13

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.

14

(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.

15

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 :

16

(1) Field service engineer.

(2) Suku cadang bebas bea.

2.4.6 Retirement Phase

Melaksanakan kegiatan uninstallation sistem dari peralatan yang menggunakannya

untuk kemudian dihapuskan atau dihancurkan.

2.5 Dokumen-dokumen Pembangunan Sistem

2.5.1 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.

17

(3) Interface Requirements Specification (IRS) yang mendokumentasikan

kebutuhan-kebutuhan pendahuluan eksternal interface untuk setiap CSCI

pada tahap System Requirement Analysis/Design dan kebutuhan-

kebutuhan 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 kebutuhan-

kebutuhan 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.

18

(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).

19

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).