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
54
Embed
DECISION SUPPORT SYSTEM UNTUK OPERASI …arwins2.tripod.com/ec6002_files/publikasi/dss-complete.pdf · 2.5.5 Post -delivery ... dipresentasikan sangat tergantung kepada hasil analisa
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
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