DECI (Pe p Pr INST ISION SUP OPE embangun erspektif S TU MATA ARWI NI rogram St TITUT TE PPORT SY ERASI UD nan Sistem Software E UGAS AKH KULIAH Oleh IN D.W. SU IM : 23206 tudi Tekni EKNOLO 2006 YSTEM U DARA m ditinjau Engineerin HIR EC-6002 UMARI 6008 ik Kompu OGI BAND UNTUK dari ng) uter DUNG
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
DECI
(Pe
p
Pr
INST
ISION SUP
OPE
embangun
erspektif S
TU
MATA
ARWI
NI
rogram St
TITUT TE
UPPORT SY
ERASI UD
nan Sistem
Software E
UGAS AKH
KULIAH
Oleh
IN D.W. SU
IM : 23206
tudi Tekni
EKNOLO2006
YSTEM U
DARA
m ditinjau
Engineerin
HIR
EC-6002
UMARI
6008
ik Kompu
OGI BAND
UNTUK
dari
ng)
uter
DUNG
DAFTAR ISI
Halaman
DAFTAR ISI ............................................................................................................ i
DAFTAR GAMBAR................................................................................................. iv
DAFTAR TABEL ................................................................................................... v
DAFTAR SINGKATAN ......................................................................................... vi
BAB I. PENDAHULUAN...................................................................................... 1
1.1 Latar Belakang Masalah ......................................................................... 1
1.2 Maksud dan Tujuan .................................................................................. 2
1.3 Batasan dan Tata Urut ............................................................................ 3
1.4 Konvensi ................................................................................................. 3
BAB II. KONSEP PEMBANGUNAN SISTEM DITINJAU DARI PERSPEKTIF
SOFTWARE ENGINEERING ................................................................................ 4
2.1 Pengantar ............................................................................................... 4
2.2 Model Proses .......................................................................................... 5
2.3 Model Proses Implementasi DSS .......................................................... 11
2.4 Kegiatan-kegiatan Software Engineering ............................................... 13
2.4.1 Requirement Phase ................................................................................ 13
2.4.2 Analysis (Specification) Phase .............................................................. 13
2.4.3 Design Phase ....................................................................................... 14
2.4.4 Implementation Phase ......................................................................... 14
2.4.4.1 Coding and CSU Testing …………………………………….……. 14
2.4.4.2 CSC Integration and Testing ……………………………………… 15
2.4.4.3 CSCI Testing .................................................................................... 15
2.4.4.4 System Integration and Testing ........................................................ 15
2.4.5 Post-delivery Maintenance Phase ....................................................... 15
2.4.6.Retirement Phase ................................................................................. 16
2.5 Dokumen-dokumen Pembangunan Sistem ............................................ 16
2.5.1 Requirement Phase ................................................................................ 16
2.5.2 Analysis (Specification) Phase ............................................................... 16
2.5.3 Design Phase ........................................................................................ 17
2.5.4 Implementation Phase .......................................................................... 18
2.5.5 Post-delivery Maintenance Phase ......................................................... 19
BAB III. TAHAPAN PEMBANGUNAN DECISION SUPPORT SYSTEM UNTUK
OPERASI UDARA ............................................................................... 20
3.1 Pengantar ................................................................................................. 20
3.2 Tahapan Software Engineering ............................................................... 21
3.2.1 Requirement Phase ............................................................................... 21
3.2.2 Analysis Phase ..................................................................................... 22
3.2.2.1 System Requirements Analysis/Design ............................................ 22
3.2.2.3 Software Requirement Analysis ........................................................ 26
3.2.3 Design Phase ....................................................................................... 29
3.2.3.1 Preliminary Design .......................................................................... 29
3.2.3.2 Detailed Design ............................................................................... 34
3.2.4 Implementation Phase ......................................................................... 34
3.2.5 Post-delivery Maintenance Phase ........................................................ 35
3.2.6 Retirement Phase ................................................................................. 35
3.3 Software Design Document (SDD) ......................................................... 35
BAB IV. SOFTWARE DESIGN DOCUMENT CSCI XR SEGMEN FEX ......... 36
4.1 Preliminary Design .................................................................................. 36
4.1.1 Tinjauan CSCI ...................................................................................... 361
4.1.1.1 Ikhtisar CSCI ..................................................................................... 36
4.1.1.2 Diagram Interface CSCI .................................................................... 36
4.1.1.3 Penjelasan Interface CSCI ................................................................. 37
4.1.2 Arsitektur CSCI .................................................................................... 38
4.1.2.1 Organisasi Statis ................................................................................. 38
4.1.2.2. Organisasi Dinamis ........................................................................... 39
4.1.2.3 Interface CSC .................................................................................... 39
4.1.3 Mode dan Status-status Sistem ............................................................ 39
4.1.4 Alokasi Memory dan Waktu Pengolahan .............................................. 40
4.2. Detailed Design – CSCI Design Description ......................................... 40
4.2.1 CSC Pembanding Fitur, XR_CSC01 ................................................... 40
4.2.2 CSC Buffer Fitur, XR_CSC02 ............................................................. 41
BAB V. PENUTUP ............................................................................................... 43
5.1 Rangkuman .............................................................................................. 43
5.2 Penutup .................................................................................................... 44
DAFTAR PUSTAKA ............................................................................................... 45
DAFTAR GAMBAR
Halaman
Gambar 2.1 Model proses waterfall[2] ............................................................. 5
Gambar 2.2 Model proses waterfall[4] ............................................................ 6
Gambar 2.3 Model proses incremental[2] ........................................................ 7
Gambar 2.4 Model proses RAD[2] ................................................................... 7
Gambar 2.5 Model proses revolutionary dengan paradigma prototyping[2] ..... 8
Gambar 2.6 Model proses spiral[2] ................................................................... 9
Gambar 2.7 Model proses concurrent engineering[2] ....................................... 10
Gambar 2.8 Model proses cleanroom engineering[2] ....................................... 11
Gambar 2.9 Model proses versi DoD-2167A[3],[5] ........................................... 12
Gambar 3.1 Blok diagram DSS untuk OPSUD ............................................... 20
Gambar 3.2 Konfigurasi Sistem/Segmen DSS dari System Requirement
Analysis/Design ............................................................................ 25
Gambar 3.3 Konfigurasi Sistem/Segmen/CSCI dari Software Requirement
Analysis ......................................................................................... 28
Gambar 3.4 Diagram interface eksternal CSCI DBS ...................................... 29
Gambar 3.5 Diagram interface eksternal CSCI FEX ...................................... 30
Gambar 3.6 Diagram interface eksternal CSCI FEZ ...................................... 32
Gambar 3.7 Diagram interface eksternal CSCI IFTG ..................................... 33
Gambar 3.8 Diagram interface eksternal CSCI DPS ...................................... 34
Gambar 4.1 Diagram interface CSCI FEX ..................................................... 37
Gambar 4.2 Pembagian CSCI XR ................................................................... 38
DAFTAR TABEL
Halaman
Tabel 4.1 Identifikasi CSC CSCI XR ............................................................ 38
Tabel 4.2 Tugas-tugas CSCI XR ................................................................... 39
Tabel 4.3 Interface CSCI ................................................................................ 39
Tabel 4.4 Pewaktuan dan eksekusi CSC ......................................................... 39
Tabel 4.5 Interface antara CSC ....................................................................... 40
Tabel 4.6 Alokasi memory dan waktu eksekusi CSU ..................................... 40
Tabel 4.7 Hubungan antara persyaratan CSCI dengan CSC .......................... 41
Tabel 4.7 Hubungan antara persyaratan CSCI dengan CSC .......................... 42
DAFTAR SINGKATAN
SINGKATAN Nama Pemakaian pertama kali pada halaman
CB Cara Bertindak 1
CDR Critical Design Review 18
CRISD Computer Resource Integrated Support
Document 19
CSC Computer Software Component 13
CSCI Computer Software Unit 13
CSOM Computer System Operator’s Manual 19
CSU Computer Software Configuration Item 13
DBS Database Segment 23
DPS Display System Segment 26
DSS Decision Support System 2
FCA Functional Configuration Audit 18
FEX Feature Extractor Segment 23
FEZ Feature Analyzer Segment 24
FSM Firmware Support Manual 19
HWCI Hardware Configuration Item 16
IDD Interface Design Document 17
IFTG Inference Integrator Segment 24
IRS Interface Requirement Specification 17
OPSUD Operasi Udara 1
PCA Physical Configuration Audit 18
PDR Preliminary Design Review 18
QA Quality Assurance 34
RAD Rapid Application Development 6
SDD Software Design Document 17
SDF Software Development Files 13
SDP Software Development Plan 13
SDR System Design Review 17
SKOMLEK Staf Komunikasi dan Elektronika 1
SLOG Staf Logistik 1
SOPS Staf Operasi 1
SPERS Staf Personel 1
SPM Software Programmer’s Manual 19
SPS Software Product Specification 18
SRR System Requirement Review 17
SRS Software Requirement Specification 16
SSDD System/Segment Design Document 16
SSR Software Requirement Review 17
STD Software Test Description 18
STP Software Test Plan 18
STR Software Test Report 18
SUM Software User’s Manual 19
VDD Version Description Document 18
BAB I
PENDAHULUAN
1.1 Latar Belakang Masalah
Di dalam suatu operasi udara (OPSUD) baik untuk perang maupun non-perang
(other than war) diperlukan suatu perencanaan yang seksama agar pelaksanaan
operasi berjalan seperti yang telah direncanakan. Keberhasilan pelaksanaan operasi
sangat tergantung kepada pemilihan alternatif Cara Bertindak (CB) yang paling tepat
dihadapkan kepada kondisi saat itu yang sedang dihadapi. Alternatif yang
dipresentasikan sangat tergantung kepada hasil analisa yang dilakukan pada data-data
kasar awal hasil kegiatan pengamatan dan pengintaian intelijen. Data-data awal ini
kemudian didistribusikan kepada 4 (empat) staf yakni staf operasi (SOPS), staf
personil (SPERS), staf logistik (SLOG) dan staf komunikasi dan elektronika
(SKOMLEK) untuk dianalisa lebih lanjut. Hasil analisa keempat staf ini kemudian
diintegrasikan atau difusikan untuk mendapatkan analisa yang lebih lengkap yang
merangkum hasil-hasil analisa sebelumnya untuk mendapatkan kesimpulan berupa
beberapa alternatif CB.
Di dalam kegiatan OPSUD, semua elemen bergerak dalam domain waktu. Ini
bermakna bahwa waktu menjadi parameter kritis dalam pergerakan semua komponen
OPSUD sehingga kegagalan dalam menepati parameter ini akan berdampak fatal
pada pelaksanaan dan misi operasi. Oleh karena itu, proses sejak data awal intelijen
diterima hingga dipresentasikannya alternatif-alternatif CB kepada Panglima perang
sebagai penentu keputusan (decision maker) harus cepat dan tepat dalam domain
waktu-kritis. Namun sayangnya hingga saat ini proses kegiatan analisa data awal
intelijen hingga diperolehnya alternatif-alternatif CB tersebut masih dijalankan
secara konvensional baik dari segi metode dan peralatan sehingga parameter waktu-
kritis ini tidak dapat dipenuhi. Dalam kondisi normal, misal untuk kegiatan latihan,
parameter waktu-kritis itu dapat sedikit diabaikan. Namun dalam kondisi perang
nyata, paramater ini menjadi faktor yang sangat signifikan karena keterlambatan
menanggapi data awal akan berdampak fatal pada eksistensi bangsa dan negara
sebagai contoh adalah Pearl Harbour tahun 1944.
Dalam upaya mengatasi permasalahan yang ada diperlukan suatu Decision Support
System (DSS) baru yang mampu melaksanakan proses otomasi pengolahan data awal
intelijen hingga diperolehnya alternatif-alternatif CB. Sistem yang diajukan
dirancang mampu melaksanakan proses pengolahan data awal intelijen secara
otomatis dengan mengekstraksi fitur-fitur relevan yang penting untuk kemudian
dianalisa oleh masing-masing subsistem yang mewakili keempat staf di atas. Hasil-
hasil analisa keempat subsistem ini kemudian diintegrasikan dan dilakukan
pengolahan untuk mendapatkan analisa yang mencakup analisa-analisa sebelumnya
untuk selanjutnya ditampilkan pada layar display. Untuk mengimplementasikan
sistem tersebut diperlukan tahapan-tahapan yang seksama agar diperoleh sistem yang
tepat sesuai dengan kebutuhan OPSUD dari masa ke masa dengan mengikuti standar
pembangunan sistem yang dipakai di dunia industri.
1.2 Maksud dan Tujuan
Maksud penulisan naskah ini adalah untuk mempresentasikan proses pembangunan
sistem yang diajukan ditinjau dari perspektif Rekayasa Perangkat Lunak (Software
Engineering) dengan tujuan untuk memenuhi tugas akhir EC-6002 Perancangan
Perangkat Lunak.
1.3 Batasan dan Tata Urut
Ruang lingkup penulisan naskah ini meliputi latar belakang permasalahan, konsep
pembangunan sistem yang digunakan dan tahapan-tahapan dalam pembangunan
sistem berdasarkan pada model pembangunan sistem yang dipilih dengan tata urut
sebagai berikut :
(1) BAB I – PENDAHULUAN.
(2) BAB II – KONSEP PEMBANGUNAN SISTEM DARI PERSPEKTIF
SOFTWARE ENGINEERING.
(3) BAB III – TAHAPAN-TAHAPAN PEMBANGUNAN DECISION
SUPPORT SYSTEM UNTUK OPERASI UDARA
(4) BAB IV – SOFTWARE DESIGN DOCUMENT CSCI XR
(5) BAB V – PENUTUP
1.4 Konvensi
Yang dimaksud dengan “Sistem” di dalam naskah ini untuk selanjutnya adalah
“Perangkat Lunak” atau software. [2] mendefinisikan software sebagai berikut :
Software is (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable programs to adequately manipulate information; (3) documents that describe the operation and use of the programs.
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
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 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.
Gambar 2.3. Model proses incremental[2].
Gambar 2.3. Model proses RAD[2].
(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 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 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].
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.
Gambar 2.9. Model proses versi DoD-2167A[3],[5].
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.
(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.
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 :
(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.
(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.
(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).
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).
BAB III
TAHAPAN PEMBANGUNAN DECISIONS SUPPORT SYSTEM
UNTUK OPERASI UDARA
3.1 Pengantar
Dengan berlandaskan pada model proses Waterfall dan mengadopsi model proses
standar industri US Department of Defense standard, DoD2167A – Military
Standard, Defense System Software Development, tahapan pembangunan sistem akan
dipresentasikan pada bagian ini. Tidak semua dokumen pembangunan sistem akan
diproduksi karena akan memakan waktu lama. Sebagai contoh tahapan yang akan
mendapat porsi lebih adalah Design Phase yang terdiri dari Preliminary Design dan
Implementation Phase. Untuk Post-delivery Maintenance Phase dan Retirement
Phase tidak dilaksanakan. Secara umum sistem yang akan dibangun digambarkan
dalam bentuk blok diagram sebagai berikut :
Gambar 3.1. Blok diagram DSS untuk OPSUD.
3.2 Tahapan Software Engineering Sistem
3.2.1 Requirement Phase
Untuk memudahkan referensi pada persyaratan sistem pada proses pembangunannya,
setiap persyaratan harus diberi kode khusus untuk membedakan satu dengan yang
lainnya. Kode standar yang digunakan adalah SRS_REQ_XX. SRS adalah
singkatan dari System Requirement Specification dan XX adalah nomor urut
spesifikasi.
(1) Persyaratan Fungsional (SRS_REQ_01). Sistem dirancang agar dapat
melaksanakan tugas-tugas (tasks) sebagai berikut :
(a) Ekstraksi fitur penting dari dalam database intelijen
(SRS_REQ_01-1).
(b) Analisa fitur intelijen yang telah diekstraksi sesuai dengan
kebutuhan (SRS01-2) :
(a) Dukungan Operasi (SRS_REQ_01-2a).
(b) Dukungan Personil (SRS_REQ_01-2b).
(c) Dukungan Logistik (SRS_REQ_01-2c).
(d) Dukungan Komunikasi dan Elektronika (SRS_REQ_01-2d).
(c) Integrasi (fusi) hasil analisa fitur dari keempat aspek di atas
(SRS_REQ_01-3).
(d) Membuat kesimpulan berdasarkan hasil integrasi (fusi) analisa data
(SRS_REQ_01-4).
(e) Menampilkan kesimpulan dalam bentuk pilihan pelaksanaan
operasi udara (SRS_REQ_01-5).
(2) Persyaratan Non Fungsional (SRS_REQ_02). Agar sistem dapat
bekerja sebagaimana yang ditetapkan di dalam Persyaratan Fungsional,
kondisi-kondisi berikut harus dapat dipenuhi yakni :
(a) Komputer standar yang didukung oleh teknologi terakhir dengan
platform Windows atau UNIX (SRS_REQ_02-1).
(b) Ketersediaan data intelijen yang berkesinambungan (continuously
updated database) (SRS_REQ_02-2).
(c) Dukungan sarana telekomunikasi yang berkesinambungan
(SRS_REQ_02-3).
(d) Dukungan sarana kelistrikan yang berkesinambungan
(SRS_REQ_02-4).
(e) Dukungan koneksi Internet yang berkesinambungan
(SRS_REQ_02-5).
3.2.2 Analysis Phase
3.2.2.1 System Requirements Analysis/Design
Konfigurasi Sistem/ Segmen hasil analisa dapat dilihat pada Gambar 3.2. Dari data
Requirement Phase maka sistem akan dibagi menjadi 5 (lima) segmen untuk
memudahkan implementasi software-nya. Segmen-segmen tersebut adalah :
(1) Segmen Database (DBS)
(a) Segmen DBS digunakan untuk menyimpan data-data intelijen kasar
hasil dari kegiatan pengamatan dan pengintaian taktis dan strategis
sebagaimana dinyatakan di dalam persyaratan (SRS_REQ_02-2).
(b) Segmen DBS akan diakses oleh CSCI Segmen FEX untuk
mengekstrak informasi-informasi yang relevan dan bernilai
strategis dan taktis untuk keperluan analisa lebih lanjut. Ini sesuai
dengan yang dinyatakan di dalam persyaratan (SRS_REQ_01-1).
(c) Untuk mendukung operasional Segmen DBS, diperlukan dukungan
sebagaimana yang dipersyaratkan di dalam (SRS_REQ_02-1),
(SRS_REQ_02-2), (SRS_REQ_02-3), (SRS_REQ_02-4) dan
(SRS_REQ_02-5).
(2) Segmen Feature Extractor (FEX)
(a) CSCI Segmen FEX bertugas melaksanakan proses ekstraksi fitur
dari Segmen DBS berdasarkan pola-pola tertentu dengan
menggunakan algoritma tertentu. Hal ini sesuai dengan yang
dinyatakan di dalam persyaratan (SRS_REQ_01-1).
(b) CSCI Segmen FEX akan mengirimkan hasil ekstraksi ke Segmen
FEZ untuk dilakukan pengolahan lebih lanjut sebagaimana yang
dipersyaratkan di dalam (SRS_REQ_01-2).
(c) Untuk mendukung operasional Segmen FEX, diperlukan dukungan
sebagaimana yang dipersyaratkan di dalam (SRS_REQ_02-1),
(SRS_REQ_02-3) dan (SRS_REQ_02-4).
(3) Segmen Feature Analyzer (FEZ)
(a) CSCI Segmen FEZ bertugas melaksanakan analisa hasil ekstraksi
fitur Segmen FEX. Hal ini sesuai dengan yang dinyatakan di
dalam persyaratan (SRS_REQ_01-2).
(b) CSCI Segmen FEZ juga bertugas melakukan distribusi fitur ke
keempat CSCI lainnya yang bertugas melakukan analisa
berdasarkan prepektif masing-masing. Hal ini sesuai dengan yang
dipersyaratkan di dalam (SRS_REQ_01-2a), (SRS_REQ_01-2b),
(SRS_REQ_01-2c) dan (SRS_REQ_01-2d).
(c) Untuk mendukung operasional Segmen FEZ, diperlukan dukungan
sebagaimana yang dipersyaratkan di dalam (SRS_REQ_02-1),
(SRS_REQ_02-3) dan (SRS_REQ_02-4).
(4) Segmen Inference Integrator (IFTG)
(a) CSCI Segmen IFTG bertugas melaksanakan integrasi/fusi hasil
analisa Segmen FEZ. Hal ini sesuai dengan yang dinyatakan di
dalam persyaratan (SRS_REQ_01-3).
(b) CSCI Segmen IFTG juga bertugas memproduksi kesimpulan dari
integrasi hasil analisa ke dalam beberapa alternatif keputusan. Hal
ini sesuai dengan yang dipersyaratkan di dalam (SRS_REQ_01-4).
(c) Untuk mendukung operasional Segmen IFTG, diperlukan
dukungan sebagaimana yang dipersyaratkan di dalam
(SRS_REQ_02-1), (SRS_REQ_02-3) dan (SRS_REQ_02-4).
Gambar 3.2. Konfigurasi Sistem/Segmen DSS dari System Requirements Analysis/Design.
(5) Segmen Display System (DPS)
(a) CSCI Segmen DPS bertugas menampilkan alternatif keputusan
hasil pengolahan Segmen IFTG. Hal ini sesuai dengan yang
dipersyaratkan di dalam (SRS_REQ_01-5).
(b) Untuk mendukung operasional Segmen DPS, diperlukan dukungan
sebagaimana yang dipersyaratkan di dalam (SRS_REQ_02-1),
(SRS_REQ_02-3) dan (SRS_REQ_02-4).
3.2.2.2 Software Requirement Analysis
Berdasarkan analisa pendahuluan di atas, setiap segmen akan dibagi menjadi
beberapa CSCI yang dapat dilihat pada Gambar 3.3. CSCI-CSCI tersebut adalah
sebagai berikut :
(1) Segmen DBS tidak memerlukan CSCI karena ia bersifat statis yakni
hanya menerima masukan data intelijen baru dari operator dan diakses
oleh CSCI Segmen FEX.
(2) Segmen FEX dibagi menjadi CSCI sebagai berikut :
(a) CSCI XR. Modul yang digunakan untuk ekstraksi fitur dari
database.
(b) CSCI XC. Modul yang digunakan untuk melakukan proses
penghitungan fitur yang diekstrak dari database.
(c) CSCI XS. Modul yang digunakan untuk melakukan proses
pengurutan frekuensi fitur secara descendant.
(d) CSCI XV. Modul ini bertugas untuk melakukan konversi data
frekuensi fitur ke bentuk urutan bit 0 dan 1.
(3) Segmen FEZ dibagi menjadi CSCI sebagai berikut :
(a) CSCI ZO. Modul yang digunakan untuk melakukan analisa fitur
dari aspek operasi.
(b) CSCI ZP. Modul yang digunakan untuk melakukan analisa fitur
dari aspek personel.
(c) CSCI ZG. Modul yang digunakan untuk melakukan analisa fitur
dari aspek logistik.
(d) CSCI ZC. Modul yang digunakan untuk melakukan analisa fitur
dari aspek komunikasi dan elektronika.
(e) CSCI ZD. Modul yang mendistribusikan fitur hasil ekstraksi ke
CSCI yang melaksanakan tugas analisa fitur.
(4) Segmen IFTG dibagi menjadi CSCI sebagai berikut :
(a) CSCI FG. Modul yang digunakan untuk melaksanakan integrasi
hasil analisa Segmen FEZ.
(b) CSCI FI. Modul yang bertugas melaksanakan tugas inferensi
integrasi analisa fitur.
(5) Segmen DPS akan dibagi menjadi CSCI sebagai berikut :
(a) CSCI PS. Modul yang bertugas menampilkan alternatif keputusan
hasil dari Segmen IFTG.
(b) CSCI PT. Modul yang bertugas memberikan layanan touch screen
pada monitor display.
(c) CSCI PP. Modul yang bertugas memberikan layanan cetak data.
Gambar 3.3. Konfigurasi Sistem/Segmen/CSCI dari Software Requirement Analysis.
3.2.3 Design Phase
3.2.3.1 Preliminary Design
Dilakukan pemetaan hubungan antar CSCI di dalam dan antar segmen sistem.
(1) Segmen DBS. Segmen ini bertanggung jawab dalam penyediaan data
intelijen yang terbaharui setiap saat dan diakses 24 jam terutama dalam
situasi operasi. Diagram interface yang menunjukkan hubungan Segmen
DBS dengan segmen lainnya dapat dilihat pada Gambar 3.4.
(a) Input
- Dari Segmen FEX
Koleksi pola untuk ekstraksi fitur.
(b) Output
- Menuju Segmen FEX.
Koleksi fitur-fitur relevan.
Gambar 3.4. Diagram interface eksternal CSCI DBS.
(2) Segmen FEX. Segmen ini bertugas untuk menyediakan informasi untuk
pengolahan lebih lanjut pada segmen berikutnya. Informasi digali
melalui proses ekstraksi, pengurutan, penghitungan dan konversi fitur
yang relevan secara otomatis. Diagram interface yang menunjukkan
hubungan Segmen FEX dengan segmen lainnya dapat dilihat pada
Gambar 3.5.
(a) Input
- Dari Segmen DBS
Koleksi fitur-fitur relevan.
(b) Output
- Menuju Segmen FEZ.
Koleksi fitur-fitur relevan dalam bentuk urutan bit 0
dan 1.
Gambar 3.5. Diagram interface eksternal CSCI FEX.
(3) Segmen FEZ. Segmen ini akan melakukan pengolahan informasi yang
telah dikonversikan sedemikian rupa oleh Segmen FEX untuk dianalisa.
Proses analisa dilakukan secara paralel dan otomatis hingga mendapatkan
kesimpulan antara. Diagram interface yang menunjukkan hubungan
Segmen FEZ dengan segmen lainnya dapat dilihat pada Gambar 3.6.
(a) Input
- Dari Segmen FEX
Koleksi fitur-fitur relevan dalam bentuk urutan bit 0
dan 1.
(b) Output
- Menuju Segmen IFTG.
Koleksi hasil-hasil analisa dalam bentuk urutan bit 0
dan 1 yang merepresentasikan aspek-aspek yang
dianalisa.
- Menuju Segmen DPS.
Koleksi hasil-hasil analisa dalam bentuk text yang
dapat langsung dibuat hard copy-nya.
(4) Segmen IFTG. Proses integrasi hasil analisa Segmen FEZ dilakukan
oleh segmen ini. Hasil integrasi kemudian diolah pada proses
selanjutnya untuk menghasilkan suatu kesimpulan. Diagram interface
yang menunjukkan hubungan Segmen IFTG dengan segmen lainnya
dapat dilihat pada Gambar 3.7.
(a) Input
- Dari Segmen FEZ
Koleksi hasil-hasil analisa dalam bentuk urutan bit 0
dan 1 yang merepresentasikan aspek-aspek yang
dianalisa.
(b) Output
- Menuju Segmen DPS.
Kesimpulan hasil-hasil analisa dalam bentuk text yang
dapat langsung ditampilkan dan dibuat hard copy-nya.
Gambar 3.6. Diagram interface eksternal CSCI FEZ.
(5) Segmen DPS. Segmen ini mempunyai tugas untuk menampilkan
produk dari segmen IFTG dalam bentuk tampilan dan cetak (hard copy).
Segmen ini juga memberikan kemudahan interaksi dengan user melalui
fasilitas touch screen yang diaplikasikan pada layar monitor. Diagram
interface yang menunjukkan hubungan Segmen DPS dengan segmen
lainnya dapat dilihat pada Gambar 3.8.
(a) Input
- Dari Segmen IFTG
Kesimpulan hasil-hasil analisa dalam bentuk text yang
dapat langsung ditampilkan dan dibuat hard copy-nya.
(b) Output
- Menuju monitor dan fasilitas hard copy.
Gambar 3.7. Diagram interface eksternal CSCI IFTG.
3.2.3.2 Detailed Design
Pada tahap ini dilakukan penentuan parameter-parameter yang digunakan di dalam
source code masing-masing CSCI.
3.2.4 Implementation Phase
Tidak dicakup di dalam naskah ini karena berkaitan dengan langsung dengan coding
setiap CSC/CSU dari setiap CSCI. Coding adalah suatu proses yang sangat
memakan resource. Kegiatan berikutnya setelah hasil coding diverifikasi adalah :
(1) Integrasi CSC-CSC ke masing-masing CSCI dan verifikasi.
(2) Integrasi CSCI-CSCI untuk setiap segmen dan verifikasi.
(3) Integrasi semua segmen membentuk satu sistem dan verifikasi.
Gambar 3.8. Diagram interface eksternal CSCI DPS.
3.2.5 Post-delivery Maintenance Phase
Tidak dicakup di dalam naskah ini karena berkaitan erat dengan produk sistem yang
dibuat dan harus melalui serangkaian pengujian dan quality assurance (QA).
3.2.6 Retirement Phase
Tidak dicakup di dalam naskah ini karena berkaitan erat dengan operasional sistem
setelah diinstalasi on-site dan dijalankan dalam rentang periode tertentu sesuai
dengan persyaratan life-time sistem tersebut.
3.3 Software Design Document (SDD)
SDD diproduksi untuk setiap CSCI sehingga bila mengikuti prosedur standar, maka
akan diproduksi sebanyak 14 SDD. Untuk menunjukkan tahapan software
engineering yang dijalankan, diberikan satu contoh SDD untuk CSCI XR dari
Segmen FEX yang akan dijelaskan pada BAB IV.
BAB IV
SOFTWARE DESIGN DOCUMENT[6]
CSCI XR SEGMEN FEX
4.1 Preliminary Design
4.1.1 Tinjauan CSCI
4.1.1.1 Ikhtisar CSCI
Tujuan dari CSCI ini adalah sebagai berikut :
(1) Melaksanakan proses ekstraksi fitur dari Segmen DBS berdasarkan pola-
pola tertentu dengan menggunakan algoritma tertentu. Hal ini sesuai
dengan yang dinyatakan di dalam persyaratan (SRS_REQ_01-1).
(2) Mengirimkan hasil ekstraksi ke Segmen FEZ untuk dilakukan
pengolahan lebih lanjut sebagaimana yang dipersyaratkan di dalam
(SRS_REQ_01-2).
4.1.1.2 Diagram Interface CSCI
Diagram interface CSCI yang menunjukkan hubungan antar CSCI XR dengan CSCI
lainnya dalam satu segmen dan segmen lainnya dapat dilihat pada Gambar 4.1.
4.1.1.3 Penjelasan Interface CSCI
Deskripsi berikut ini mengidentifikasi interface utama dengan CSCI XR.
(1) Input
(a) Dari Segmen DBS
- Fitur-fitur relevan yang diinginkan.
(2) Output
(a) Menuju CSCI XC
- Fitur-fitur relevan hasil ekstraksi CSCI XR untuk dihitung
frekuensi kemunculannya.
Gambar 4.1. Diagram interface CSCI FEX.
4.1.2 Arsitektur CSCI
4.1.2.1 Organisasi Statis
(1) CSCI dibagi menjadi beberapa CSC sebagai berikut :
Gambar 4.2. Pembagian CSCI XR.
(2) Identifikasi masing-masing CSC adalah sebagai berikut :
Tabel 4.1. Identifikasi CSC CSCI XR
Nama CSC Identifier CSC Fungsi Pembanding fitur
XR_CSC01
Membandingkan pola dengan fitur yang diekstraksi
Buffer fitur
XR_CSC02
Penyimpan sementara hasil ekstraksi sebelum dikirim ke CSCI XC
4.1.2.2 Organisasi Dinamis
(1) Tugas-tugas CSCI
Tabel 4.2. Tugas-tugas CSCI XR
Tugas Prosesor Kelas Eksekusi Tujuan CSC
Pendukung
Sinkron Yang tersedia Sinkron
Ekstraksi fitur dan penyimpan fitur
sementara
XR_CSC01 XR_CSC02
(2) Interface antar CSCI
Tabel 4.3. Interface CSCI
Interface Data
XR_XC Integer
(3) Pewaktuan dan Eksekusi CSC
Tabel 4.4. Pewaktuan dan eksekusi CSC
Identifier CSC Kelas Eksekusi Ketergantungan Waktu
XR_CSC01 Sinkron Tidak ada
XR_CSC02 Sinkron Tidak ada
4.1.2.3 Interface CSC
Tabel 4.5. Interface antara CSC
Interface Data
XR_INTF_XC Integer
4.1.3 Mode dan Status-status Sistem
Tidak ada.
4.1.4 Alokasi Memory dan Waktu Pengolahan
Data berikut adalah dummy data untuk keperluan penjelasan SDD.
Tabel 4.6. Alokasi memory dan waktu eksekusi CSU
Nama CSU
Jumlah Baris Kode
Jumlah Baris
Komentar
Jumlah Total Baris
Kode Terpakai
Ulang (%)
Rata-rata
Waktu Eksekusi
(msec)
Waktu Terburuk
(msec)
xr100.c 50 20 70 85 0,02 0,012
xr200.c 49 14 63 95 0,034 0,041
4.2 Detailed Design – CSCI Design Description
4.2.1 CSC Pembanding Fitur, XR_CSC01
(1) Ikhitisar CSC
CSC ini betanggung jawab untuk melakukan proses ekstraksi fitur dari dalam
database berdasarkan pada pola pembanding yang diberikan kepadanya.
Kesalahan proses dilaporkan melalui prosedur normal software.
(2) Data Input CSC
Lihat referensi 4.1.2.3.
(3) Data Output CSC
Lihat referensi 4.1.2.3.
(4) Persyaratan Software CSC
Persyaratan sebagai berikut dipenuhi oleh CSC ini :
Tabel 4.7. Hubungan antara persyaratan CSCI dengan CSC
Persyaratan Identifikasi
Ekstraksi fitur SRS_REQ_01-1
(5) Batasan-batasan oleh CSC
Tidak ada.
(6) Batasan-batasan pada CSC
Tidak ada.
4.2.2 CSC Buffer Fitur, XR_CSC02
(1) Ikhitisar CSC
CSC ini betanggung jawab untuk melakukan penyimpanan sementara hasil
proses ekstraksi fitur dari dalam database sebelum dikirimkan ke CSCI XC.
Kesalahan proses dilaporkan melalui prosedur normal software.
(2) Data Input CSC
Lihat referensi 4.1.2.3.
(3) Data Output CSC
Lihat referensi 4.1.2.3.
(4) Persyaratan Software CSC
Persyaratan sebagai berikut dipenuhi oleh CSC ini :
Tabel 4.8. Hubungan antara persyaratan CSCI dengan CSC
Persyaratan Identifikasi
Penyimpan ekstraksi sementara SRS_REQ_01-1
(5) Batasan-batasan oleh CSC
Tidak ada.
(6) Batasan-batasan pada CSC
Tidak ada.
BAB V
PENUTUP
5.1 Rangkuman
Untuk membangun suatu sistem yang handal, seorang software engineer harus
memahami tahapan-tahapan yang harus dilaksanakan dan mampu mengaplikasikan
engineering dalam pembangunan sistem tersebut. Terdapat banyak proses model
dalam pembangunan sistem sehingga harus tepat dalam memilih proses model yang
sesuai dengan proyek yang akan ditangani. Proses model yang umum digunakan
adalah waterfall life-cycle yang menggunakan pendekatan sekuensial sistematis yang
dimulai dari penspesifikasian persyaratan sistem, analisa, perancangan, implementasi
dan pengiriman produk hingga sistem ditarik dari operasionalnya.
Untuk melihat esensi pembangunan suatu sistem, telah digunakan contoh
pembangunan Decision Support System untuk Operasi Udara. Proses model yang
digunakan adalah model waterfall yang diadopsi oleh US Department of Defense
standard dalam bentuk standar software development DoD2167A – Military
Standard, Defense System Software Development. Tidak semua tahapan
dilaksanakan dikarenakan pada dasarnya contoh ini digunakan sebagai sarana untuk
memahami proses sistematis yang terencana dalam melaksanakan pembangunan
sistem.
Tahapan software engineering dilaksanakan hingga ke tahap Design Phase karena
tahap berikutnya telah masuk ke dalam domain pemrograman modul-modul
pembentuk sistem. Penekanan naskah ini adalah pada Design Phase dengan
mengambil contoh CSCI XR dari Segmen FEX yang dipresentasikan dalam bentuk
Software Design Document (SDD).
5.2 Penutup
Demikian naskah mengenai pembangunan sistem ditinjau dari perspektif software
engineering disampaikan dengan harapan dapat bermanfaat bagi para peserta kuliah
EC-6002 Perancangan Perangkat Lunak di Program Studi Teknik Komputer – STEI,
ITB di masa mendatang.
DAFTAR PUSTAKA
[1] Mayes Dale (2005), Establishing Great Software Development Process(es) for Your Organization, Embedded System Conference, California.
[2] Pressman, Roger (2001), Software Engineering: A Practitioner’s Approach, McGraw-Hill.
[3] Rakitin, Steven R. (1997), Software Verification and Validation: A Practitioner’s Guide, Artech House, Inc.
[4] Schach, Stephan (1999), Classical and Object Oriented Software Engineering, Irwin.
[5] ______________ (1989), Military Handbook: Tailoring Guide for DOD-STD-2167A Defense System Software Development, US Department of Defense.
[6] ______________ (1997), Software Design Document for the Simulation
Controller (SC) CSCI of the Real-Time Executive (RTX) Segment, Volume 5 Book 4 Cover 3, Thomson Training & Simulation Limited, Crawley, UK.
Related Documents
