MAKALAH

SISTEM EMBEDDED

Dibuat Oleh:

MOCHAMMAD PRADITIA JUNIAWAN

NIM: 2212182002

PROGRAM STUDI TEKNIK ELEKTRO

FAKULTAS TEKNIK
UNIVERSITAS JENDERAL ACHMAD YANI
CIMAHI
2019
1. Pendahuluan
Belakangan ini semakin berkembangnya teknologi pada bidang industri yang
mampu memberikan tingkat efisiensi yang baik pada setiap penggunaanya.
Perkembangan teknologi embedded dahulu hanya lebih berfokus pada komputer
akan tetapi seiring dengan perkembangannya kini embedded system mulai memiliki
tempat yang setara dengan teknologi lainnya. Embedded system itu sendiri
merupakan sebuah sistem komputer yang didesain untuk melakukan perkerjaan
khusus. Tidak seperti sistem yang dibangun di Personal Computer, embedded
system relatif lebih cepat dalam runtime bahkan seringkali real time karena
embedded system dibangun dengan bahasa pemrograman yang lebih dikenali oleh
hardware. Merancang sebuah produk berbasis embedded adalah tugas yang
menantang karena harus memenuhi kendala pada area penggunaan, ukuran,
konsumsi daya, dan juga waktu untuk memasarkan. Selama bertahun-tahun,
kompleksitas dari desain sistem embedded telah meningkat bahkan jika perubahan
kecil dalam desain membutuhkan perancangan dari awal yang menyebabkan
banyak konsumsi waktu.

2. Reuse: Intellectual Property Cores

Tidak semua komponen sistem embedded harus dirancang dari awal. Sebagai
gantinya, ada komponen standar yang dapat digunakan kembali. Komponen-
komponen ini terdiri dari pengetahuan dari upaya desain sebelumnya dan
merupakan kekayaan intelektual (IP). Penggunaan kembali IP adalah salah satu
teknik utama dalam mengatasi meningkatnya kompleksitas desain. Menggunakan
kembali komponen software yang tersedia adalah inti dari metodologi desain
berbasis platform.

Komponen perangkat lunak standar yang dapat digunakan kembali meliputi: sistem
operasi tertanam (OS), basis data yang real-time, dan bentuk middleware lainnya.
Adanya komponen berbentuk middleware lainnya ini menunjukkan software yang
menyediakan lapisan perantara antara OS dan software aplikasi (termasuk,
misalnya, libraries untuk komunikasi). Pemanggilan ke komponen software standar
mungkin sudah harus dimasukkan dalam spesifikasi. Oleh karena itu, informasi
tentang interface pemrograman aplikasi (API) dari komponen standar ini mungkin
diperlukan untuk menyelesaikan spesifikasi yang dapat dieksekusi.

Ada beberapa pendekatan standar untuk penjadwalan yang harus diperhitungkan

dan yang harus disadari oleh perancang. Pendekatan penjadwalan tertentu bisa jadi
didukung atau tidak didukung oleh sistem operasi tertentu. Batasan ini juga harus
diperhitungkan.

2.1 Implementasi Sistem Embedded

Setelah spesifikasi selesai, kegiatan desain dapat dimulai. Ini konsisten dengan
aliran informasi desain yang disederhanakan seperti yang dapat dilihat pada gambar
1.

Gambar 1. Penyederhanaan aliran perancangan informasi.

Ini merupakan karakteristik dari sistem embedded yang harus dipertimbangkan baik
untuk hardware maupun software. Karena itu, jenis desain ini juga disebut
hardware/software codesign. Tujuan keseluruhannya adalah untuk menemukan
kombinasi yang tepat antara hardware dan software yang menghasilkan produk
yang paling efisien dan memenuhi spesifikasi. Oleh karena itu, sistem embedded
tidak dapat dirancang oleh proses sintesis dengan hanya mempertimbangkan
spesifikasi perilaku. Sebaliknya, harus memperhitungkan komponen yang tersedia.
Ada juga penyebab lainnya untuk kendala ini adalah untuk mengatasi
meningkatnya kompleksitas sistem embedded dan persyaratan time-to-market yang
ketat, sistem reuse pada dasarnya tidak dapat dihindari. Ini mengarah pada istilah
desain berbasis platform yaitu “Platform adalah keluarga dari arsitektur yang
memenuhi serangkaian kendala yang diberlakukan untuk memungkinkan sistem
reuse pada komponen hardware dan software. Namun, platform hardware saja tidak
cukup. Desain derivatif yang cepat dan andal, memerlukan penggunaan interface
pemrograman aplikasi platform (API) untuk memperluas platform menuju software
aplikasi. Secara umum, platform adalah lapisan abstraksi yang mencakup banyak
kemungkinan penyempurnaan ke level yang lebih rendah. Desain berbasis platform
melakukan pendekatan meet-in-the-middle yaitu dalam aliran desain top-down,
desainer memetakan turunan dari platform atas ke turunan yang lebih rendah, dan
menyebarkan kendala pada desain” [Sangiovanni-Vincentelli, 2002].

Pemetaan adalah proses berulang di mana alat evaluasi kinerja memandu tugas
berikutnya. Gambar 2 [Herrera et al., 2003a] memvisualisasikan pendekatan ini.

Gambar 2. Platform-based Design.

Kegiatan desain harus mempertimbangkan keberadaan platform yang tersedia.

Sebenarnya ada sejumlah besar aktivitas desain, hanya beberapa yang dapat
disajikan di sini dan referensi ke platform yang tersedia tidak selalu eksplisit.
Aktivitas desain yang disajikan meliputi:
a) Manajemen konkurensi tingkat tugas: Aktivitas ini berkaitan dengan
pengidentifikasian tugas yang harus ada dalam sistem embedded akhir. Tugas-
tugas ini mungkin berbeda dari yang termasuk dalam spesifikasi, karena ada
alasan bagus untuk menggabungkan dan membagi tugas (lihat bagian 5.5.1).
b) Transformasi tingkat tinggi: Telah ditemukan bahwa ada banyak transformasi
tingkat tinggi yang dapat dioptimalkan untuk diterapkan pada spesifikasi.
Contohnya, loop dapat dipertukarkan sehingga akses ke komponen array
menjadi lebih lokal. Juga, aritmatika float point seringkali dapat diganti dengan
aritmatika point tetap tanpa kehilangan kualitas yang signifikan. Transformasi
tingkat tinggi ini biasanya di luar kemampuan kompiler yang tersedia dan harus
diterapkan sebelum kompilasi dimulai.
c) Partisi hardware/software: Dalam kasus umum, beberapa fungsi harus
dilakukan oleh hardware khusus karena meningkatnya persyaratan komputasi
[De Man, 2002]. Partisi hardware/software adalah aktivitas yang bertanggung
jawab atas operasi mapping proses ke hardware atau software.
d) Kompilasi: Bagian-bagian dari spesifikasi yang dipetakan ke software harus
dikompilasi. Efisiensi kode yang dihasilkan, ditingkatkan jika kompilator
mengeksploitasi informasi tentang harware yang mendasari prosesor (dan
memungkinkan juga memori). Oleh karena itu, ada kompiler “hardware-
aware” khusus untuk sistem embedded.
e) Penjadwalan: Penjadwalan (pemetaan operasi untuk memulai waktu) harus
dilakukan dalam beberapa konteks. Jadwal harus didekati selama partisi
hardware/software, selama manajemen konkurensi level tugas dan mungkin
juga selama kompilasi. Jadwal yang tepat dapat diperoleh untuk kode final.
f) Eksplorasi ruang desain: Dalam sebagian besar kasus, beberapa desain
memenuhi spesifikasi. Eksplorasi ruang desain adalah proses menganalisis set
desain yang memungkinkan. Di antara desain yang memenuhi spesifikasi, satu
desain harus dipilih.
3. Design Process Models
Proses desain terdiri dari lima tahap yang berbeda walaupun mungkin berbeda
untuk proyek atau disiplin ilmu desain tertentu. Tahapan proses desain tersebut
yaitu:
a) Mengidentifikasi dan merumuskan spesifikasi kebutuhan
b) Spesifikasi desain sistem
c) Functional Design
d) Architectural Design
e) Prototyping

3.1 Mengidentifikasi dan merumuskan spesifikasi kebutuhan

Analisis persyaratan dalam rekayasa sistem dan rekayasa perangkat lunak,
mencakup tugas-tugas yang masuk ke dalam menentukan kebutuhan atau kondisi
untuk memenuhi kebutuhan produk baru atau produk yang diubah, dengan
mempertimbangkan persyaratan yang mungkin bertentangan dari berbagai
pemangku kepentingan, penganalisis, pendokumentasian, pemvalidasi dan
pengelola perangkat lunak atau persyaratan sistem. Gambar 3 menunjukkan
interface antara cusomer dan proses desain.

Gambar 3. Interface antara customer dan proses desain.

Analisis persyaratan sangat penting untuk keberhasilan sistem atau software

proyek. Persyaratan harus didokumentasikan, dapat ditindaklanjuti, dapat diukur,
dapat teruji, dapat terlacak, terkait dengan kebutuhan atau peluang bisnis yang
teridentifikasi, dan dapat ditetapkan ke tingkat rincian yang cukup untuk desain
sistem.

Secara konseptual, analisis kebutuhan mencakup tiga jenis, yaitu:

a) Eliciting requirements: tugas untuk mengidentifikasi berbagai jenis
persyaratan dari berbagai sumber termasuk dokumentasi proyek, dokumentasi
proses bisnis, dan wawancara pemangku kepentingan. Ini kadang-kadang juga
disebut pengumpulan persyaratan.
b) Analyzing requirements: menentukan apakah persyaratan yang dinyatakan
jelas, lengkap, konsisten, dan tidak ambigu, serta menyelesaikan konflik yang
nyata.
c) Recording requirements: Persyaratan dapat didokumentasikan dalam berbagai
bentuk, biasanya termasuk daftar ringkasan dan dapat mencakup dokumen
berbahasa alami, kasus penggunaan, kisah pengguna, atau spesifikasi proses.

3.3.1 Mengkarakterisasi Sistem

Analisis kebutuhan bisa menjadi proses yang panjang dan sulit di mana banyak
keterampilan psikologis yang rumit terlibat. Sistem baru mengubah lingkungan dan
hubungan antar manusia, jadi penting untuk mengidentifikasi semua pemangku
kepentingan, memperhitungkan semua kebutuhan mereka dan memastikan mereka
memahami implikasi sistem baru. Analis dapat menggunakan beberapa teknik
untuk memperoleh persyaratan dari pelanggan. Ini dapat mencakup pengembangan
skenario, identifikasi kasus penggunaan, penggunaan observasi tempat kerja atau
etnografi, mengadakan wawancara, atau kelompok fokus dan membuat daftar
persyaratan. Prototyping dapat digunakan untuk mengembangkan contoh sistem
yang dapat ditunjukkan kepada para pemangku kepentingan. Bila perlu, analis akan
menggunakan kombinasi metode ini untuk menetapkan persyaratan yang tepat dari
para pemangku kepentingan, sehingga sistem yang memenuhi kebutuhan bisnis
dihasilkan.
Spesifikasi untuk setiap entitas dari lingkungan eksternal harus memiliki:
a. Nama dan deskripsi dari entitas
Setiap input/output variabel, harus memiliki informasi berikut ini:
f) Nama dari sinyal
g) Penggunaan dari sinyal, sebagai input atau sebagai output
h) Sifat sinyal sebagai event, data, atau sebagai state variabel
b. Tanggung jawab aktivitas
c. Hubungan
d. Keamanan dan keandalan

3.2 Spesifikasi Desain Sistem

Spesifikasi Desain Sistem (SDS) adalah dokumen lengkap yang berisi semua
informasi yang diperlukan untuk mengembangkan sistem. Desain sistem adalah
proses mendefinisikan arsitektur, komponen, modul, interface, dan data untuk suatu
sistem untuk memenuhi persyaratan yang ditentukan. Desain sistem dapat dilihat
sebagai penerapan teori sistem untuk pengembangan produk. Ada beberapa
tumpang tindih dengan disiplin analisis sistem, arsitektur sistem dan rekayasa
sistem. Spesifikasi desain sistem berfungsi sebagai jembatan antara customer dan
desainer seperti yang ditunjukkan pada gambar 4.

Gambar 4. Customer, persyaratan dan desainer.

Spesifikasi persyaratan memberikan tampilan dari luar sistem, dan juga
memberikan tampilan dari dalam. Spesifikasi desain memiliki 2 master, yaitu:
a. Harus menentukan interface publik sistem dari dalam sistem
 b. Harus menentukan bagaimana persyaratan yang ditentukan untuk dan oleh
interface publik harus dipenuhi oleh fungsi awal sistem.

Lima bidang yang harus dipertimbangkan adalah:

a. Kendala geografis.
b. Karakterisasi dan kendala pada sinyal interface.
c. Persyaratan interface pengguna
d. Batasan waktu.
e. Pertimbangan infrastruktur listrik
f. Keamanan dan keandalan

3.2.1 Spesifikasi sistem versus persyaratan sistem

Persyaratan memberikan deskripsi tentang sesuatu yang diinginkan atau
dibutuhkan. Merupakan seperangkat properti yang dibutuhkan. Spesifikasi adalah
deskripsi dari beberapa entitas yang memiliki atau mengimplementasikan properti
tersebut. Spesifikasi Persyaratan Sistem adalah kumpulan informasi terstruktur
yang mewujudkan persyaratan sistem.

Persyaratan dan spesifikasi merupakan komponen yang sangat penting dalam

pengembangan sistem embedden manapun. Analisis persyaratan adalah langkah
pertama dalam proses desain sistem, di mana persyaratan pengguna harus
diklarifikasi dan didokumentasikan untuk menghasilkan spesifikasi yang sesuai.
Sementara itu, kecenderungan umum bagi para desainer untuk cemas tentang
memulai desain dan implementasi, mendiskusikan persyaratan dengan pelanggan
sangat penting dalam pembangunan sistem keselamatan-kritis. Untuk kegiatan di
tahap pertama ini memiliki dampak signifikan pada hasil hilir dalam siklus hidup
sistem.

Misalnya, kesalahan yang dikembangkan selama tahap persyaratan dan spesifikasi

dapat menyebabkan kesalahan pada tahap desain. Ketika kesalahan ini ditemukan,
para insinyur harus meninjau kembali persyaratan dan spesifikasi untuk
memperbaiki masalah. Hal ini tidak hanya menyebabkan lebih banyak waktu
terbuang, tetapi juga kemungkinan kesalahan persyaratan dan spesifikasi lainnya.
Banyak kecelakaan ditemukan karena kekurangan persyaratan, implementasi
spesifikasi yang tidak lengkap, atau asumsi yang salah tentang persyaratan.
Sementara masalah-masalah ini dapat diterima dalam sistem yang tidak kritis
terhadap keselamatan, sistem keselamatan kritis tidak dapat mentolerir kesalahan
karena persyaratan dan spesifikasi. Oleh karena itu, diperlukan persyaratan yang
ditentukan dengan benar untuk menghasilkan spesifikasi yang jelas dan akurat.

Ada perbedaan yang jelas antara persyaratan dan spesifikasi. Persyaratan adalah
kondisi yang dibutuhkan oleh pengguna untuk memecahkan masalah atau mencapai
tujuan. Spesifikasi adalah dokumen yang terspesifikasi, lengkap, tepat, dapat
diverifikasi, terdapat persyaratan, memiliki desain, memiliki perilaku atau
karakteristik lain dari suatu sistem, dan seringkali, terdapat prosedur untuk
menentukan apakah ketentuan ini telah dipenuhi. Spesifikasi untuk persyaratan ini
akan mencakup informasi teknis tentang aspek desain tertentu. Istilah lain yang
umum dilihat dalam buku dan makalah adalah spesifikasi kebutuhan yang
merupakan dokumen yang menentukan persyaratan untuk suatu sistem atau
komponen. Ini mencakup persyaratan fungsional, persyaratan kinerja, persyaratan
interface, persyaratan desain, dan standar pengembangan.

Spesifikasi adalah deskripsi tepat dari sistem yang memenuhi persyaratan yang
dinyatakan. Dokumen sebuah spesifikasi harus:
a) Lengkap
b) Konsisten
c) Dapat dipahami
d) Dapat ditelusuri ke persyaratan
e) Jelas
f) Dapat dimodifikasi
g) Mampu ditulis
3.3 Functional Design
Proses desain fungsional memetakan "apa yang harus dilakukan" dari Spesifikasi
Persyaratan ke dalam "bagaimana melakukannya" dari spesifikasi desain. Selama
tahap ini, keseluruhan struktur produk ditentukan dari sudut pandang fungsional.
Desain fungsional menggambarkan aliran sistem logis, organisasi data, input dan
output sistem, aturan pemrosesan, dan karakteristik operasional produk dari sudut
pandang pengguna. Desain fungsional tidak berkaitan dengan perangkat lunak atau
perangkat keras yang akan mendukung operasi produk atau organisasi fisik data
atau program yang akan menerima input data, melaksanakan aturan pemrosesan,
dan menghasilkan output yang diperlukan.

Desain Fungsional adalah paradigma yang digunakan untuk menyederhanakan

desain hardware dan software seperti software komputer dan semakin, model 3D.
Desain fungsional memastikan bahwa setiap bagian modular perangkat hanya
memiliki satu tanggung jawab dan melakukan tanggung jawab itu dengan efek
samping minimum pada bagian lain. Modul yang dirancang secara fungsional
cenderung memiliki kopling rendah.

3.4 Architectural Design

Tujuan utama dari desain Arsitektur adalah alokasi atau pemetaan berbagai fungsi
sistem ke blok hardware dan software yang sesuai. Pekerjaan didasarkan pada
struktur fungsional yang terperinci. Kendala penting yang harus dipertimbangkan
termasuk item sebagai:
a. Distribusi geografis
b. Antarmuka fisik dan pengguna
c. Spesifikasi kinerja sistem
d. Batasan waktu dan persyaratan ketergantungan
e. Konsumsi daya
f. Komponen dan biaya warisan
3.5 Prototyping

Fase prototipe mengarah ke prototipe sistem operasional. Implementasi prototipe

termasuk:
a) Desain yang rinci
b) Debugging
c) Validasi
d) Pengujian

Prototipe adalah sampel awal atau model yang dibangun untuk menguji konsep atau
proses atau untuk bertindak sebagai hal yang akan ditiru atau dipelajari. Ini adalah
istilah yang digunakan dalam berbagai konteks, termasuk semantik, desain,
elektronik, dan pemrograman software. Prototipe dirancang untuk menguji dan
menguji coba desain baru untuk meningkatkan presisi oleh analis dan pengguna
sistem. Prototyping berfungsi untuk memberikan spesifikasi untuk sistem kerja
yang nyata dan bukan teoretis.

Di banyak bidang, ada ketidakpastian besar apakah desain baru benar-benar akan
melakukan apa yang diinginkan. Desain baru seringkali memiliki masalah yang
tidak terduga. Sebuah prototipe sering digunakan sebagai bagian dari proses desain
produk untuk memungkinkan kemampuan teknisi dan kemampuan desainer untuk
mengeksplorasi alternatif desain, menguji teori dan mengkonfirmasi kinerja
sebelum memulai produksi produk baru. Teknisi menggunakan pengalaman mereka
untuk menyesuaikan prototipe sesuai dengan yang tidak diketahui spesifik masih
ada dalam desain yang dimaksud. Sebagai contoh, beberapa prototipe digunakan
untuk mengkonfirmasi dan memverifikasi minat konsumen dalam desain yang
diusulkan sedangkan prototipe lain akan berusaha untuk memverifikasi kinerja atau
kesesuaian pendekatan desain tertentu.

Secara umum, serangkaian prototipe berulang akan dirancang, dibangun, dan diuji
ketika desain akhir muncul dan disiapkan untuk produksi. Dengan pengecualian
yang jarang, beberapa iterasi prototipe digunakan untuk secara progresif
memperbaiki desain. Strategi umum adalah merancang, menguji, mengevaluasi,
dan kemudian memodifikasi desain berdasarkan analisis prototipe.

Dalam banyak organisasi pengembangan produk, spesialis prototipe dipekerjakan -

individu dengan keterampilan khusus dan pelatihan dalam teknik fabrikasi umum
yang dapat membantu menjembatani antara desain teoritis dan pembuatan
prototipe.

3.6 Jenis-jenis Design Process Model

Terdapat beberapa jenis dalam desain proses model yang digunakan dalam dunia
industri, yaitu model Waterfall, V, Incremental, dan Spiral.

3.7.1 Model Waterfall

Model air terjun (Waterfall Model) adalah pendekatan klasik dalam pengembangan
perangkat lunak yang menggambarkan metode pengembangan linier dan berurutan.
Ini terdiri dari lima hingga tujuh fase, setiap fase didefinisikan oleh tugas dan tujuan
yang berbeda, di mana keseluruhan fase menggambarkan siklus hidup perangkat
lunak hingga pengirimannya. Setelah fase selesai, langkah pengembangan
selanjutnya mengikuti dan hasil dari fase sebelumnya mengalir ke fase berikutnya.

Model air terjun (Waterfall Model) adalah metode pertama yang banyak digunakan
dalam industri perangkat lunak. model ini merupakan pendekatan tradisional, dan
jauh kurang fleksibel daripada metodologi gesit dengan pengembangan dipecah
menjadi sprint tunggal, tetapi dapat dilengkapi dengan loop umpan balik dan
loopback. Saat ini masih digunakan dalam berbagai versi jika persyaratan dan
karakteristik suatu perangkat lunak dapat didefinisikan dengan jelas selama fase
konseptual.
 Gambar 5. Model Waterfall.

Model air terjun Waterfall Model pada dasarnya terdiri dari tujuh fase berturut-
turut:

a) Persyaratan sistem: Tahap pertama berkaitan dengan persyaratan yang tidak

terkait dengan produk digital itu sendiri melainkan dengan aspek yang relevan
dengan bisnis seperti harga dan ketersediaan. Aspek dokumentasi dan
keselamatan juga ditentukan di sini. Secara umum, persyaratan non-fungsional
disebutkan di sini.
b) Persyaratan perangkat lunak: Persyaratan fungsional untuk perangkat lunak
didefinisikan pada fase kedua. Pertanyaan tentang apa yang harus dapat
dilakukan oleh perangkat lunak dijawab di sini dan diklarifikasi dalam
“spesifikasi,” yang juga mencakup hasil tahap pertama.
c) Analisis persyaratan: Pada fase analisis persyaratan, fungsi-fungsi perangkat
lunak dibedah dan disusun sedemikian rupa sehingga elemen-elemen
fungsional individu dan unit-unit fungsional dapat dipisahkan satu sama lain.
Analisis persyaratan dimaksudkan untuk menguji fungsi untuk kelayakan dan
kepentingannya. Hasil dari fase ini adalah spesifikasi yang berisi persyaratan
yang perlu dikembangkan.
d) Desain program: Desain teknis sekarang diimplementasikan dengan bantuan
spesifikasi persyaratan ini. Komponen fase ini juga termasuk keputusan tentang
arsitektur informasi dan teknologi terapan seperti bahasa pemrograman,
perpustakaan kelas, dan urutan program. Hasil desain program biasanya
direkam dalam diagram yang menggambarkan perilaku teoritis perangkat
lunak.
e) Implementasi: Selama implementasi, struktur dan alur kerja dilaksanakan
dengan mempertimbangkan kondisi dan tujuan kerangka kerja sistemik. Desain
perangkat lunak menjadi program yang terkait langsung dengan sistem operasi,
satu atau lebih bahasa pemrograman, dan infrastruktur. Hasilnya biasanya
berupa perangkat lunak operasional, seringkali sebagai versi beta.
f) Pengujian: Tahap implementasi diikuti oleh pengujian semua komponen
perangkat lunak, modul, dan seluruh sistem. Integrasi ke dalam sistem operasi
spesifik juga diperiksa. Jika kesalahan dan konflik terjadi, mereka harus segera
diperbaiki. Hal ini dapat menyebabkan peningkatan biaya keseluruhan karena
kesalahan yang mungkin dapat dikaitkan dengan fase yang berbeda dan tidak
selalu disebabkan pada fase sebelumnya.
g) Peluncuran: Perangkat lunak diimplementasikan setelah penerimaan oleh klien.
Pembaruan dan pemeliharaan mungkin diperlukan sebelum produk memasuki
toko atau dikirim ke pelanggan.

3.7.2 Model V

Model V adalah model pengembangan perangkat lunak yang didasarkan pada

hubungan antara setiap fase pengembangan siklus hidup yang tercantum dalam
model Watterfall yang merupakan pengembangan perangkat lunak dan fase yang
terkait pengujian.

Model V biasa disebut Model Verifikasi dan Validasi. Setiap proses untuk menguji
sebuah perangkat lunak harus mengikuti berbagai tahap dan Model V adalah salah
satu metode pengembangan yang sangat tepat untuk digunakan dalam pengujian
sebuah piranti lunak. Didalam metode ini ada beberapa tahap yang spesifik dimana
harus diikuti saat menguji performa sebuah piranti lunak. Setelah sebuah tahap telah
selesai dilaksanakan, maka akan berlanjut ke tahap berikutnya sampai tahap yang
ada berakhir. Rangkaian uji ini berbentuk seperti huruf V. Dalam sikus
pengembangan piranti lunak, pengujian dengan Model V dimulai dari awal proyek
dilaksanakan dimana syarat dan kebutuhan telah ditentukan.

Gambar 6. Model V.

Fase verifikasi lebih mengacu pada usaha penyesuaian spesifikasi piranti lunak
dengan kebutuhan pengguna, tahapan ini meliputi :

a) Requirements analysis, menganalisa dan mengumpulkan semua syarat dan

kebutuhan pengguna
b) System design, pengembang menganalisa untuk memastikan persyaratan dan
kebutuhan telah layak untuk membangun sistem yang diminta
c) Architecture Design, dapat juga disebut “high-level design” dimana arsitektur
sistem ditentukan selama fase ini.
d) Module Design, dapat juga disebut “low-level design” dimana sistem dipecah
menjadi beberapa bagian agar mempermudah para pengembang untuk menulis
kode.
Fase Validasi lebih mengacu pada penyesuaian dari seluruh proses tahapan
verifikasi dengan spesifikasi dan persyaratan yang sudah ditetapkan dengan tahapan
sebagai berikut :

a) Unit testing, menguji setiap bagian system secara terpisah.

b) Integration testing, menguji beberapa bagian system secara bersamaan untuk
memastikan system dapat berfungsi san bekerja secara bersama-sama.
c) System testing, menguji keseluruhan system yang telah dibangun.
d) User acceptance testing, penentuan apakah system yang dibangun telah
memenuhi permintaan dan memuaskan pengguna atau tidak.
e) Release testing, menguji system untuk memastikan bahwa piranti lunak dapat
di implemetasikan di lingkungan yang akan di terapkan.

3.7.3 Model Incremental

Incremental model adalah model pengembangan sistem pada software engineering

berdasarkan requirement software yang dipecah menjadi beberapa fungsi atau
bagian sehingga model pengembangannya secara bertahap. dilain pihak ada
mengartikan model incremental sebagai perbaikan dari model waterfall dan
sebagai standar pendekatan topdown. Layaknya Model Waterfall, model ini pun
juga memiliki tahapan tahapan untuk perancangan perangkat lunaknya, yaitu:

a) Requirement, Requirment adalah proses tahapan awal yang dilakukan pada

incremental model adalah penentuan kebutuhan atau analisis kebutuhan.
b) Specification, Specification adalah proses spesifikasi dimana menggunakan
analisis kebutuhan sebagai acuannya.
c) Architecture Design, adalah tahap selanjutnya, perancangan software yang
terbuka agar dapat diterapkan sistem pembangunan per-bagian pada tahapan
selanjutnya.
d) Code setelah melakukan proses desain selanjutnya ada pengkodean.
e) Test merupakan tahap pengujian dalam model ini.
 Gambar 7. Model Incremental.

Tahapan-tahapan tersebut dilakukan secara berurutan. Setiap bagian yang sudah

selesai dilakukan testing, dikirim ke pemakai untuk langsung dapat digunakan.
Pada incremental model, tiga tahapan awal harus diselesaikan terlebih dahulu
sebelum sebelum tahap membangun tiap increment. Untuk mengantisipasi kondisi
yang terjadi pada incremental model, diperkenalkan model More Risky Incremental
Model. Model ini menerapkan sistem kerja yang paralel. Setelah daftar kebutuhan
didapatkan dari pemakai, tim spesifikasi membuat spesifikasi untuk modul pertama.
Setelah spesifikasi pertama selesai, tim desain menindak lanjuti. Tim spesifikasi
sebelumnya juga langsung membuat spesifikasi untuk model kedua, dan seterusnya.
Jadi, tidak harus menunggu modul pertama selesai hingga dikirim ke user.

3.7.4 Model Spiral

Model Spiral (spiral model) adalah salah satu bentuk dari Metode Pengembangan
Perangkat Lunak atau yang disebut SDLC (Software Development Life Cycle),
yang sangat populer digunakan dalam bidang teknologi informasi. Model Spiral
adalah gabungan dari Model Prototyping dan Model Waterfall dengan penekanan
yang tinggi pada analisis risiko tiap tahapannya.
Bentuk ini bersifat iteratif atau berulang dengan mengontrol aspek yang teratur dari
sekuensial linier. Fungsi Model Spiral ini adalah untuk melakukan perubahan,
penambahan dan pengembangan suatu software dengan deretan pertambahan
menjadi lebih baik secara cepat dan tepat berdasarkan keinginan dan kebutuhan
penggunanya.

Gambar Spiral Model Process

Dalam Model Spiral terdapat lima tahap untuk merealisasikan penggunaannya

sebagai berikut :

a) Tahap Liason

Tahap ini berhubungan dengan komunikasi antara orang yang akan

mengembangkan software (system analyst) dengan pelanggan. Tujuannya
adalah agar dapat memuaskan pelanggan dengan memperbaiki dan
mengembangkan software sesuai dengan kebutuhan, kepentingan dan
keinginannya.
b) Tahap Planning

Tahap perencanaan meliputi estimasi biaya yang digunakan, batas waktu,

pengaturan jadwal, identifikasi lingkungan kerja, sumber-sumber infomasi
untuk melakukan iterasi. Hasilnya adalah dokumen spesifikasi kebutuhan
sistem dan bisnis.

c) Tahap Analisis Risiko

Tahap ini berfungsi untuk mengidentifikasi risiko yang berpotensial untuk

terjadi dan menghasilkan suatu solusi alternatif secara teknis dan manajemen
saat strategi mitigasi risiko direncanakan dan diselesaikan.

d) Tahap Rekayasa (engineering)

Pada tahap ini, yang dilakukan adalah sebagai berikut:

 Menguji, coding dan mengembangkan software

 Menginstal software
 Membuat prototipe
 Mendesain dokumen
 Meringkas suatu pengujian software
 Membuat laporan atas kekurangan dari software agar segera diperbaiki

e) Tahap Evaluasi

Peran pelanggan sangat diperlukan pada tahap ini. Mereka dapat memberikan
masukan dan tanggapan, mengevaluasi produk kerja dan memastikan bahwa
produk yang dibutuhkan sesuai dengan semua ketentuan. Jika terdapat
perubahan, semua tahapan akan diperbaiki sesuai dengan kepuasan pelanggan.
Namun, mengidentifkasi dan memantau risiko yang terjadi juga diperlukan,
seperti cost overrun.
Menurut Boehm, terdapat enam karakteristik di dalam Model Spiral :

a) Menentukan Artefak secara Bersamaan

Dalam pemrograman, sebuah ‘artefak’ adalah setiap hal yang dihasilkan oleh
orang-orang yang terlibat dalam proses pengembangan perangkat lunak. Model
ini menunjukkan bahwa semua artefak dalam siklus hidup suatu proyek harus
didefinisikan sepenuhnya dari awal.

b) Empat Esensial Tugas Model Spiral

Menurut Boehm, setiap siklus model spiral terdiri dari empat tugas berikut :

 Mempertimbangkan tujuan kritis dan kendala stakeholders

 Menguraikan dan mengevaluasi alternatif-alternatif untuk mencapai tujuan
 Mengidentifikasi dan mengatasi risiko kepada solusi alternatif
 Persetujuan dan review stakeholder untuk melanjutkan berdasarkan
kepuasan dalam tujuan kritis dan kendala
c) Risiko ditentukan berdasarkan Usaha

Upaya dialokasikan untuk proyek harus ditentukan berdasarkan tingkat

keparahan risiko yang terkait dengan komponen tersebut.

d) Risiko ditentukan berdasarkan Tingkat Detail

Mengatasi potensi risiko harus menentukan seberapa banyak perhatian terhadap

rincian proyek yang sedang dikerjakan.

e) Menggunakan The Anchor Point Milestones

Pada Modal Spiral terdapat tiga “The Anchor Point Milestones” adalah :

 Life Cycle Objectives (LCO)

Untuk melihat apakah pendekatan teknis suatu proyek cukup untuk

dilanjutkan ke pengembangan berikutnya.
  Life Cycle Architecture (LCA)

Untuk memeriksa apakah pendekatan optimal yang telah ditetapkan dan

segala risiko utama telah direncanakan dan diperhitungkan sebelumnya.

 Initial Operational Capability (IOC)

Untuk memeriksa bahwa persiapan yang ada telah memadai untuk

memuaskan stakeholders sebelum diluncurkan

f) Fokus terhadap Sistem dan Siklus Hidup

Melihat pentingnya sistem secara keseluruhan dan urusan jangka panjang yang
mencakup seluruh siklus hidup.