V-Model
Kata Pengantar
Puji dan syukur penulis haturkan kehadirat Tuhan Yang Maha Esa,
karena tanpa perlindungan-Nya maka tugas softskill ini tidak dapat
kami selesaikan dalam waktu yang telah ditentukan. Dalam makalah
ini penulis menjelaskan tentang Materi Softskill yang berjudul _V-
MODEL_ beserta dengan contoh peristiwa yang berkaitan dengan
judul tersebut.
Penulis menyadari dalam menyelesaikan makalah ini masih jauh dari
kata sempurna, hal itu disebabkan karena keterbatasan waktu yang
dimiliki penulis maupun sumber referensi yang digunakan. Oleh
karena itu mohon maaf jika makalah ini kurang sempurna. Tak
lupa penulis ingin menyampaikan terimakasih kepada seluruh anggota
kelompok yang lainnya yang telah membantu dalam penulisan serta
penyelesaian makalah ini. Demikian makalah ini dibuat semoga dapat
bermanfaat bagi pihak _ pihak yang memerlukannya.
Jika terdapat kesalahan kami selaku penulis memohon maaf atas keter-
batasan yang kami miliki. Atas perhatian dan pengertiannya kami
ucapkan Terima Kasih Depok,17-Januari-2015
Penulis
Daftar Isi
Kata Pengantar
Daftar Isi
Bab I Pendahuluan
A. Latar Belakang
B. Batasan Masalah
C. Tujuan Penulisan
Bab II Konsep V- Model
1.Pengertian V-Model
2.Arsitektur
_ Lifecycle process model
- Activitiy dan product
- Activity schema
- Product state
_ Allocation of methods
2
_ Functional tool requirements
- Project management (PM)
- Quality assurance (QA)
- System development (SD)
- Con_guration management (CM)
3. Macam- Macam V-Model
-V Model Aristoteles
-V Model Lasswell
-V Model Shannon dan Weaver
-V Model Newcomb
-V Model Gerbner
-V Model Berlo
-V Model DeFleur
-V Model Tubbs
-V Model Gudykunst dan Kim
-V Model Interaksional
Bab III Software Pendukung
1. Weighted Product Model (wpm)
- Underwriting
- Fuzzy AHP
2. Umbrella FrameWorks
3. V Standalone
4. V Streaming
5. V Full Infrastructure
Bab IV Kasus / Contoh Pemanfaat Software
Bab V Penutup
A. Kesimpulan
B. Saran
Daftar Pusaka
Chapter 1
Pendahuluan
1.1 Latar Belakang
V-Model, juga disebut Vee-Model, adalah proses pengembangan produk awalnya
dikembangkan di Jerman untuk proyek-proyek pertahanan pemerintah. Hal
ini telah menjadi standar umum dalam pengembangan perangkat lunak. The
V-Model mendapatkan namanya dari fakta bahwa proses ini sering dipetakan
sebagai _owchart yang mengambil bentuk surat V.
Hasil proses pembangunan dari sudut kiri atas V ke kanan, berakhir pada
titik kanan atas. Dalam cabang kiri, miring ke bawah dari V, personil
pengembangan
mende_nisikan kebutuhan bisnis, parameter desain aplikasi dan proses
desain. Pada titik dasar V, kode ditulis. Dalam cabang kanan, miring ke
atas
dari V, pengujian dan debugging dilakukan. Unit testing dilakukan pertama,
diikuti oleh bottom-up pengujian integrasi. Titik ekstrim kanan atas dari
V
merupakan rilis produk dan dukungan yang berkelanjutan.
V-Model telah memperoleh penerimaan karena kesederhanaan dan
keterusterangan.
Namun, beberapa pengembang percaya terlalu kaku untuk sifat berkembang
TI (teknologi informasi) lingkungan bisnis.
Yang pertama V-model dikembangkan 1986 di Jerman. Pertama itu dimaksudkan
untuk TI-proyek dari sisi masyarakat, lama di samping, di sektor swasta
digunakan.
Biasanya sebuah varian baru dari model V-dari varian sebelumnya dalam
setiap kasus dikembangkan, segera sebagai kebutuhan perbaikan diakui.
Karakteristik
umum dari varian dan pro dan kontra, yang menyertai dengan aplikasi
3
CHAPTER 1. PENDAHULUAN 4
mereka, yang dijelaskan dalam artikel terpisah (model prosedural
(software),
konsep pengolahan (software)).
Bertentangan dengan model fase klasik di V-model kegiatan dan hasil hanya
dide_nisikan dan tidak ada suksesi temporal yang ketat dituntut. Secara
khusus
satu mencari penerimaan yang khas, yang menentukan akhir fase, di sini sia-sia.
Hal ini dimungkinkan tetap untuk menggambarkan kegiatan misalnya V-model
dalam kasus air drop atau model spiral.
Sejarah
Pada tahun 1986 Kementerian Federal untuk pertahanan memulai dua proyek
Software lingkungan pengembangan untuk sistem informasi (Seu-IS) dan
Software lingkungan pengembangan untuk sistem pengiriman senjata dan
senjata
(Seu-WS) dengan tujuan sebagai berikut:
Untuk membuat biaya atas pengembangan perangkat lunak keseluruhan dan
transparansi proses dan perawatan juga membatasi akibatnya. Untuk menjamin
dan / atau ini lebih meningkatkan dengan tindakan yang sesuai standar
minimum
untuk kualitas perangkat lunak. Untuk mencapai oleh komparatif dari
tawaran ketiga kemandirian yang lebih besar dari o_erers individu untuk.
Untuk
standarisasi dan mengatur lebih transparan dalam pengembangan perangkat
lunak di rumah sendiri. Asal Militer
Untuk hal ini pada prinsipnya juga pengolahan konsep dari NATO-sekutu
seharusnya dapat diterapkan, seperti misalnya Amerika standar DoD 2.167
STD
A atau standar Perancis GAM T 17. Sebuah pemeriksaan rinci dari model ini
menunjukkan bahwa bagaimanapun mereka tidak mampu, semua persyaratan
untuk menjadi adil. Jadi salah satu memutuskan untuk pengembangan diri,
yang membawa versi pertama keluar dari model V-pada tahun 1988 - sebagai
hasil dari proyek Seu-WS -. Ke ini sampai April 1990 realisasi dari proyek
Seu-IS kemudian diintegrasikan dan versi perbaikan dari model V-dekrit itu
tetap dari bulan Februari 1991 oleh Menteri Federal untuk pertahanan
sebagai
tingkat pool pengembangan perusahaan penyiaran untuk produksi software
dengan Angkatan
Bersenjata Jerman Federal.
1.2 Batasan Masalah
The sipil V-model Karena pemerintah federal juga berbeda melihat diri
mereka
dihadapkan dengan masalah benar-benar sama disimpan, V-model pada akhir
tahun 1991 dialihkan kepada Pemerintah Federal untuk teknologi informasi
CHAPTER 1. PENDAHULUAN 5
pada koordinasi dan dewan penasihat dalam pemerintahan federal (KBSt)
untuk
menyediakan dengan tugas versi sipil dari model V-. Pekerjaan ini adalah
_nal dan oleh Menteri Federal pertahanan dan Menteri Federal Dalam Negeri
diterbitkan dan tetap versi seragam model V-akibat pada bulan Agustus
1993.
V-model 97
Awal pengembangan software baru (misalnya Obyek orientasi, dll) dibuat
diperlukan revisi dari model V-, terutama karena ini sangat kuat untuk
"pengembangan
perangkat lunak klasik mulai" potong hingga saat ini. Akibatnya pada
bulan Juni 1997 V-model '97 diterbitkan, yang dianjurkan karena untuk
setiap
pengembangan perangkat lunak dalam pemerintahan federal untuk aplikasi.
V-model XT
Karya ini diganti dalam kursus dengan realisasi baru dalam pengembangan
perangkat lunak pada bulan Februari 2005 oleh versi model V-1.0 dari XT
(XT
= ekstrem Menjahit). Poin perubahan utama di sini
V-model menjadi disesuaikan dengan kebutuhan masing-masing (tailorbar).
Integrasi klien: Sejauh default yang selaras kepada kontraktor. Sekarang
ada
juga prosedur komponen untuk klien. Modularitas Stronger: Empat Submodelle
masa lalu ada di formulir ini tidak lagi, tetapi hanya komponen prosedur,
dari mana model prosedural beton proyek diatur ("menjahit").
Kuat orientasi
terhadap agiler dan awal tambahan: "Jalan seperti, yang." The
V-Model XT
tidak memberikan peraturan atas suksesi temporal komponen prosedur. Produk
yang dihasilkan terletak di pusat dan tidak dokumentasi seperti RUP. Satu
menemukan gambaran pengantar dalam basis dari model V-.
Karena V-model setengah-tahunan jarak diperbarui, versi 1.2 (dari
2006/01/02)
diganti ke 2006/01/08 oleh versi 1.3. Ekstensif dokumentasi dan alat,
program
Proyek asisten] jadi misalnya ada sudah sekarang, yang membuat memproduksi
dan Menjahit kemungkinan dokumen yang diperlukan.
Penting struktur V-model Struktur dokumentasi Dokumentasi V-model XT
terdiri dari 9 bagian, tentang yang hanya dua bagian pertama mewajibkan
untuk
semua model V_pengguna. The 7 tersisa bagian memahami dirinya sebagai
buku referensi. V-model XT terdiri dari bagian-bagian berikut:
Bagian 1: Basis model V-(pendahuluan, konsep, "??)
Bagian 2: Sebuah rute oleh V-model (proyek contoh kecil)
Bagian 3: V-model-referensi Menjahit (seperti yang saya menyesuaikan
Vmodel
untuk saya
Bagian 4: V-model-referensi peran (yang perlu saya untuk saya
CHAPTER 1. PENDAHULUAN 6
Bagian 5: V-model-referensi produk (sebagai hasil proyek adalah untuk
melihat,
yang mereka
Bagian 6: V-model-referensi kegiatan (seperti yang saya berikan
Bagian 7: ilustrasi konvensi V-model-referensi (saya sudah tahu VM97/CMMI
/ "Dimana di V-model XT saya menemukannya?
Bagian 8: Lampiran (yang alat dan metode / aku bisa Glosarium "??)
Bagian 9: listrik Mengumpulkan (mengumpulkan _le utama (rtf) dengan
deskripsi dari aplikasi) V-model-core
V-model merangkum satu set dari kegiatan serupa disimpan ke komponen
prosedur sedemikian rupa ditentukan. Beberapa komponen prosedur menemukan
dengan semua aplikasi proyek dan karena itu sebagai V-model inti yang
ditunjuk. Selain milik:
PM: Proyek manajemen QA: Jaminan Mutu Mk: Manajemen Kon_gurasi
Pa: Masalah dan manajemen perubahan Produk dan kegiatan
V-model mende_nisikan satu set dokumen, yang disebut produk. Ini terdiri
dari topik individu. Produk, yang memiliki koneksi contentwise kuat,
terlalu
diatur lagi kelompok produk yang sama.
Setiap produk dide_nisikan berjalan melalui empat kondisi:
berencana dalam pengobatan disampaikan diterima dimana transisi berikut
antara kondisi yang mungkin:
Satu panggilan kegiatan, yang mengubah produk, aktivitas, ini adalah untuk
senyawa bagian mereka dari kegiatan parsial individu, yang kemudian
mengobati
tepat dalam setiap kasus topik. Kegiatan yang terkait Contentwise
digabungkan
sehingga kembali ke dalam kelompok kegiatan. Untuk setiap kegiatan persis
disimpan, yang produk itu harus dan / atau berubah dan prosedur kerja yang
diperlukan untuk menyebabkan modi_kasi yang diinginkan. Untuk tujuan ini
setiap kegiatan sungai produk dan penyelesaian yang dide_nisikan.
Sementara
sungai produk menjelaskan, dari mana kegiatan produk masukan yang
diperlukan
dengan kondisi yang datang, agar dalam bentuk dimodi_kasi dan / atau
kondisi dimodi_kasi untuk kegiatan berikut untuk kemudian diteruskan,
berisi
petunjuk penyelesaian yang lebih tepat untuk pelaksanaan kegiatan .
Suksesi temporal kegiatan hasil sehingga dari ketersediaan (bagian) produk
yang diperlukan dalam kondisi tertentu.
Karakteristik
Model prosedural digunakan untuk pengembangan aplikasi oleh IT-sistem
ukuran yang paling beragam dan kompleksitas. Untuk menghasilkan dengan
penyelesaian proyek-proyek kecil dan menengah tidak ada pengeluaran tambaCHAPTER
1. PENDAHULUAN 7
han terlalu besar, V-model untuk kondisi proyek caper ukuran, yang
mengurangi
jumlah kegiatan dan produk dengan ukuran yang diperlukan, mende_nisikan.
Satu panggilan prosedur dari adaptasi dari model V-pada proyek-spesi_k
kebutuhan
Menjahit.
Alat
pada langkah (V-model 97 dan V-model XT) XT Editor XT asisten proyek
The V-Model adalah istilah yang digunakan untuk berbagai model, dari model
konseptual yang dirancang untuk menghasilkan pemahaman yang sederhana
dari kompleksitas yang terkait dengan pengembangan sistem untuk rinci,
model
siklus pengembangan yang ketat dan model manajemen proyek.
Ada bentuk radikal berbeda dari model V-, dan hal ini menciptakan kebingungan
yang cukup besar. The V-Model jatuh ke dalam tiga kategori besar.
Pertama ada adalah V-Model Jerman "Das V-Modell", manajemen
metodologi
proyek resmi pemerintah Jerman. Ini kira-kira setara dengan PRINCE2,
tetapi
lebih langsung relevan dengan pengembangan perangkat lunak. AS juga
memiliki
standar pemerintah V-Model, yang tanggal kembali sekitar 20 tahun, seperti
rekan Jerman-nya. Jangkauannya agak sempit, menjadi pengembangan sistem
siklus hidup model, tetapi masih lebih jauh lebih rinci dan lebih ketat
daripada
praktisi Inggris kebanyakan dan penguji akan mengerti dengan Model V.
Di Inggris, dan seluruh pengujian masyarakat di seluruh dunia, V-Model
secara
luas dilihat sebagai gambaran, samar ilustrasi dari proses pengembangan
perangkat lunak, seperti yang dijelaskan dalam Silabus Yayasan ISTQB untuk
penguji perangkat lunak. Tidak ada de_nisi tunggal yang diterima dari
model
ini, yang lebih langsung dibahas dalam artikel alternatif pada V-Model
(software
development). Karena itu ada beberapa variasi dari versi ini. Masalah ini
harus diingat ketika membahas V-Model. Isi
1 Ikhtisar 2 Tujuan 3 V Model topik 3.1 Sistem Teknik dan veri_kasi 3.2
Aliran Spesi_kasi 4 Aplikasi 5 Keuntungan 6 Batas 7 Lihat juga 8 Referensi
9
Pranala luar
Ikhtisar
The V-Model adalah representasi gra_s dari pengembangan siklus hidup
sistem.
Ini merangkum langkah-langkah utama yang harus diambil dalam hubungannya
dengan kiriman yang sesuai dalam kerangka validasi sistem komputerisasi.
The V merupakan urutan langkah-langkah dalam pengembangan kehidupan
siklus proyek. Ini menggambarkan kegiatan yang akan dilakukan dan hasil
yang
harus dihasilkan selama pengembangan produk. Sisi kiri dari "V"
merupakan
CHAPTER 1. PENDAHULUAN 8
dekomposisi dari persyaratan, dan penciptaan spesi_kasi sistem. Sisi kanan
V
merupakan bagian integrasi dan validasi mereka . Kadang-kadang dikatakan
validasi yang dapat dinyatakan dengan query "Apakah Anda membangun
hal
yang benar?" dan veri_kasi oleh "Apakah Anda membangun dengan
benar?"
Dalam prakteknya, penggunaan istilah-istilah ini bervariasi. Kadang-kadang
mereka bahkan digunakan secara bergantian.
Panduan PMBOK, standar IEEE, mende_nisikan mereka sebagai berikut
dalam edisi ke-4: "Validasi Jaminan bahwa produk, layanan, atau
sistem memenuhi
kebutuhan pelanggan dan stakeholder lainnya diidenti_kasi.. Ini sering
melibatkan
penerimaan dan kesesuaian dengan pelanggan eksternal Kontras dengan
veri_kasi.." "Veri_kasi Evaluasi Kontras atau tidaknya suatu
produk, layanan,
atau sistem sesuai dengan peraturan, persyaratan, spesi_kasi, atau kondisi
yang
ditetapkan. Hal ini sering proses internal. Dengan validasi.."
1.3 Tujuan
Meminimalkan Risiko Proyek: The V-Model meningkatkan transparansi proyek
dan pengendalian proyek dengan menentukan pendekatan standar dan
menggambarkan
hasil yang sesuai dan peran yang bertanggung jawab. Ini memungkinkan
pengakuan awal perencanaan penyimpangan dan risiko dan manajemen proses
membaik, sehingga mengurangi risiko proyek.
Peningkatan dan Jaminan Mutu: Sebagai model proses standar, V-Model
memastikan bahwa hasil yang akan diberikan adalah lengkap dan memiliki
kualitas
yang diinginkan. Hasil sementara Ditetapkan dapat diperiksa pada tahap
awal. Isi produk yang seragam akan lebih mudah dibaca, dimengerti dan
pemastian.
Pengurangan Biaya Total lebih dari Proyek Seluruh dan Siklus Hidup Sistem:
Upaya untuk, produksi operasi pembangunan, dan pemeliharaan sistem
dapat dihitung, diperkirakan dan dikendalikan secara transparan dengan
menerapkan
model proses standar. Hasil yang diperoleh adalah seragam dan mudah
menelusuri kembali. Ini mengurangi ketergantungan pada pemasok acquirers
dan upaya untuk kegiatan selanjutnya dan proyek.
Peningkatan Komunikasi antara semua Stakeholder: Deskripsi standar dan
seragam dari semua elemen yang relevan dan persyaratan merupakan dasar
untuk saling pengertian antara semua stakeholder. Dengan demikian,
kerugian
gesekan antara pengguna, pemasok acquirer, dan pengembang berkurang.
CHAPTER 1. PENDAHULUAN 9
Dalam proses modelWaterfall dasar melihat beberapa kelemahan atau
keterbatasan
dalam model yang mulai model SDLC baru. Seperti yang kita lihat
dalam model Waterfall isu-isu yang ditemukan di akhir SDLC, hal ini
disebabkan
pengujian yang terjadi pada tahap akhir dari SDLC Anda. Untuk
mengatasi masalah ini V-Model yang datang ke dalam gambar. Itu selalu
lebih baik untuk memperkenalkan pengujian dalam tahap awal SDLC, seperti
dalam model ini kegiatan pengujian akan dimulai dari tahap awal SDLC.
Sebelum
memulai pengujian yang sebenarnya, tim pengujian harus bekerja pada
berbagai kegiatan seperti penyusunan Strategi Uji, Uji Perencanaan,
Penciptaan
kasus Uji & Test Scripts yang bekerja paralel dengan kegiatan
pembangunan
yang membantu untuk mendapatkan tes diserahkan tepat waktu. Dalam
Model Pengembangan Perangkat Lunak Siklus Hidup V, berdasarkan informasi
yang sama (persyaratan spesi_kasi dokumen) kegiatan pembangunan &
pengujian
dimulai. Berdasarkan dokumen persyaratan tim pengembang mulai bekerja
pada desain & setelah selesai pada desain mulai implementasi aktual
dan tim
pengujian mulai bekerja pada perencanaan pengujian, menulis uji kasus,
script
pengujian. Kedua kegiatan bekerja sejajar satu sama lain. Dalam model
Waterfall
& V-model mereka cukup mirip satu sama lain. Karena itu adalah Uji
Perangkat Lunak paling populer Hidup Model Siklus sehingga sebagian besar
organisasi mengikuti model ini. V-model juga disebut sebagai Veri_kasi dan
model Validasi. Kegiatan pengujian tampil dalam setiap fase dari fase
Siklus
Hidup Uji Perangkat Lunak. Di paruh pertama model kegiatan validasi
pengujian terintegrasi dalam setiap fase seperti kebutuhan pengguna
review,
dokumen Sistem Desain & di babak berikutnya kegiatan pengujian
Veri_kasi
datang dalam gambar. Khas V-Model menunjukkan kegiatan Pengembangan
Perangkat Lunak di sisi kiri dari model dan sisi kanan dari Fase Pengujian
model yang sebenarnya dapat dilakukan. Dalam proses ini _Do-Prosedur_ akan
diikuti oleh tim pengembang dan _Check-Prosedur_ akan diikuti oleh tim
pengujian
untuk memenuhi persyaratan yang disebutkan. Dalam siklus V-Model
hidup pengembangan perangkat lunak langkah yang berbeda yang diikuti Namun
di sini kita akan mengambil jenis yang paling umum dari V-model contoh.
V-model biasanya terdiri dari beberapa tahap sebagai berikut: 1. Unit
Pengujian: Persiapan Kasus Uji Satuan 2. Integrasi Pengujian: Persiapan
Uji
Kasus Integrasi 3. Sistem Pengujian: Persiapan kasus uji Sistem 4.
Penerimaan
Pengujian: Persiapan Uji Kasus Penerimaan V-model dikembangkan di Jerman
untuk aplikasi pertahanan. Didalam V-model terdapat 3 kompomen kerja
yang pokok yakni Project De_nition yakni mendefenisian project apa yang
akan
CHAPTER 1. PENDAHULUAN 10
dibuat, Time yakni waktu yang dibutuhkan dalam pengimplementasiannya dan
Project Test And Integration atau pengujian dan integrasi project
tersebut.
Model ini berpusat pada user. Dimana pengulangan selalu dibutuhkan jika
kebutuhan untuk user belum terpenuhi _ketidaktahuannya_ tanpa harus
memberikan
software dengan lingkungan yang baru. Resiko pada setiap tahap dalam
pengembangan dapat dikurangi dengan memahami kebutuhan user. Didalam
pendefenisian project terdapat aktivitas Concept Operation (konsepsi
project)
yakni menentukan tujuan yang akan di capai dalam pembuatan project
tersebut.
Requirement and Architecture (persyaratan dan arsitektur) yakni harus
dapat menjelaskan apa saja yang diinginkan dan diperlukan oleh user. Untuk
itu diperlukan adanya psroses klari_kasi, perbaikan, penentuan
kelengkapan,
dan ruang lingkup. Sebagai masukannya dapat berupa dokumen persyaratan
dan keluarannya adalah ketetapan persyaratan. Terdapat bermacam-macam
persyaratan yang dapat dihasilkan : _ Fungsional : menjelaskan tentang apa
saja yang dapat dilakukan oleh system _ Non fungsional : dapat berupa ukuran
memori, jangka waktu respon. _ Data : data apa saja yang perlu disimpan
dan bagaimana penyimpanannya. Detailed Design yakni memperincikan desain
sebuah aplikasi yang akan dibuat. Selanjutnya setelah Project tersebut
telah
ditetapkan maka Diimplementasikan lah atau di jalankan. Selanjutnya dalam
tahap Project Test and Integration aplikasi/software yang telah dilakukan
Integration
test and Veri_cation yang mana dalam tahap ini aplikasi yang telah
diimplementasikan di lakukan veri_kasi atau ditinjuau kegunaan nya apakah
sesaui dengan kebutuhan user. Selanjutnya Operation and Maintenance yakni
melakukan perbaikan atas apa yg telah di veri_kasi dan di sesuaikan dengan
kebutuhan user. Dan pada akhirnya dalam model ini akan dilakukan proses
Verivikasi dan Validitas kepada user apakah sudah bekerja sesuai dengan
yang
diharapkan dan apakah rancangan sesuai dengan apa nyang diinginkan.
The V-Model adalah representasi gra_s dari pengembangan siklus hidup
sistem.
Ini merangkum langkah-langkah utama yang harus diambil dalam hubungannya
dengan kiriman yang sesuai dalam kerangka validasi sistem komputerisasi.
The V merupakan urutan langkah-langkah dalam pengembangan kehidupan
siklus proyek. Ini menggambarkan kegiatan yang akan dilakukan dan hasil
yang
harus dihasilkan selama pengembangan produk. Sisi kiri dari "V"
merupakan
dekomposisi dari persyaratan, dan penciptaan spesi_kasi sistem. Sisi kanan
V
merupakan bagian integrasi dan validasi mereka.
Kadang-kadang dikatakan validasi yang dapat dinyatakan dengan query
"Apakah
CHAPTER 1. PENDAHULUAN 11
Anda membangun hal yang benar?" dan veri_kasi oleh "Apakah Anda
membangun
dengan benar?"
Dalam prakteknya, penggunaan istilah-istilah ini bervariasi. Kadang-kadang
mereka bahkan digunakan secara bergantian.
Panduan PMBOK, standar IEEE, mende_nisikan mereka sebagai berikut
dalam edisi ke-4:
"Validasi Jaminan bahwa produk, layanan, atau sistem memenuhi
kebutuhan
pelanggan dan stakeholder lainnya diidenti_kasi.. Ini sering melibatkan
penerimaan dan kesesuaian dengan pelanggan eksternal Kontras dengan veri-
_kasi.." "Veri_kasi Evaluasi Kontras atau tidaknya suatu produk,
layanan, atau
sistem sesuai dengan peraturan, persyaratan, spesi_kasi, atau kondisi yang
ditetapkan.
Hal ini sering proses internal. Dengan validasi.." Tujuan Ini
memungkinkan
pengakuan awal perencanaan penyimpangan dan risiko dan manajemen
proses membaik, sehingga mengurangi risiko proyek. Peningkatan dan
Jaminan Mutu: Sebagai model proses standar, V-Model memastikan bahwa
hasil yang akan diberikan adalah lengkap dan memiliki kualitas yang
diinginkan.
Hasil sementara Ditetapkan dapat diperiksa pada tahap awal. Isi produk
yang
seragam akan lebih mudah dibaca, dimengerti dan pemastian.
Pengurangan Biaya Total lebih dari Proyek Seluruh dan Siklus Hidup Sistem:
Upaya untuk, produksi operasi pembangunan, dan pemeliharaan sistem
dapat dihitung, diperkirakan dan dikendalikan secara transparan dengan
menerapkan
model proses standar. Hasil yang diperoleh adalah seragam dan mudah
menelusuri kembali. Ini mengurangi ketergantungan pada pemasok acquirers
dan upaya untuk kegiatan selanjutnya dan proyek. Peningkatan Komunikasi
antara semua Stakeholder: Deskripsi standar dan seragam dari semua elemen
yang relevan dan persyaratan merupakan dasar untuk saling pengertian
antara
semua stakeholder. Dengan demikian, kerugian gesekan antara pengguna,
pemasok
acquirer, dan pengembang berkurang.
Sistem rekayasa dan veri_kasi. Sistem Teknik dan veri_kasi
Rekayasa Sistem Proses (SEP) menyediakan jalur untuk meningkatkan
efektivitas
biaya sistem yang kompleks seperti yang dialami oleh pemilik sistem
selama masa seluruh sistem, dari konsepsi untuk pensiun.
Ini melibatkan identi_kasi awal dan komprehensif tujuan, konsep operasi
yang menggambarkan kebutuhan pengguna dan lingkungan operasi, persyaratan
sistem menyeluruh dan dapat diuji, desain rinci, implementasi, pengujian
penerimaan
yang ketat dari sistem yang diterapkan untuk memastikan memenuhi
persyaratan yang dinyatakan (sistem veri_kasi ), mengukur efektivitas
dalam
CHAPTER 1. PENDAHULUAN 12
menangani tujuan (validasi sistem), yang sedang berlangsung operasi dan
pemeliharaan,
upgrade sistem dari waktu ke waktu, dan akhirnya pensiun.
Proses ini menekankan persyaratan-driven desain dan pengujian. Semua
elemen desain dan tes penerimaan harus dapat dilacak dari satu atau lebih
persyaratan sistem dan setiap kebutuhan harus ditangani oleh setidaknya
satu
elemen desain dan uji penerimaan. Kekakuan tersebut memastikan tidak ada
yang dilakukan tidak perlu dan segala sesuatu yang diperlukan tercapai.
Aliran
Spesi_kasi
Aliran Spesi_kasi terutama terdiri dari: Pengguna Persyaratan Spesi_kasi
Fungsional Kebutuhan Spesi_kasi Desain Spesi_kasi Aliran pengujian umumnya
terdiri dari:
Instalasi Kuali_kasi (IQ)
Operasional Kuali_kasi (OQ)
Kinerja Kuali_kasi (PQ)
Aliran pembangunan dapat terdiri (tergantung pada jenis sistem dan ruang
lingkup pengembangan) kustomisasi, kon_gurasi atau coding.
Chapter 2
Konsep V-model
2.1 Pengertian V-model
Dalam V-Model , alokasi tugas ( kegiatan ) kepada orang-orang yang
terorganisir
melalui peran. Dalam kaitan ini, peran menggambarkan dibutuhkan
pengetahuan dan kemampuan seseorang harus memiliki dalam rangka untuk
memenuhi tugas-tugas yang dialokasikan kepadanya. Dengan demikian,
berkaitan
dengan organisasi, V-Model tidak memihak. Berkenaan dengan proyek
penanganan ini berarti bahwa peranan dari model V- harus dialokasikan
untuk
perorangan pada saat proyek (kegiatan PM1 - Inisialisasi Proyek )
diinisialisasi.
Di pihak berwenang dan perusahaan, orang-orang selalu unit organisasi
terkecil.
Oleh karena itu, alokasi orang untuk peran juga untuk mempertimbangkan
struktur organisasi dan penanganan organisasi. Peran mengidenti_kasi
kegiatankegiatan
yang mungkin memerlukan hanya sebagian dari jam kerja anggota staf,
atau, dalam kasus lain, mereka mungkin memerlukan beberapa kali jam kerja
dari anggota staf.
Oleh karena itu, anggota staf mungkin memiliki beberapa peran yang dialokasikan
kepadanya, atau satu peran dapat dipenuhi oleh beberapa anggota
staf. Bagian penting dalam alokasi ini adalah bahwa peran sendiri tidak
akan
mengganggu satu sama lain dan dengan demikian mungkin menjadi masalah
yang tak terpecahkan bagi orang yang bertanggung jawab atas peran
(misalnya
berkaitan dengan peran konstruktif SD di satu sisi dan dengan penguji
pada lainnya tangan). Misalnya, peran Pimpinan Proyek tidak boleh
dikombinasikan
dengan peran orang yang bertanggung jawab QA, karenaPemimpin
13
CHAPTER 2. KONSEP V-MODEL 14
Proyek terutama bertanggung jawab untuk waktu dan anggaran, dan manajer
QA untuk kualitas. Sebagai contoh lain, peran manajer QA kompatibel dengan
peran Perwakilan CM .
Kriteria untuk alokasi adalah bahwa seseorang tidak harus berada dalam
kon_ik kepentingan, struktur tanggung jawab dan pengalaman, pengetahuan,
kesesuaian, ketersediaan (utilisasi) dari anggota proyek.
Dalam hal tidak ada kegiatan lebih banyak dialokasikan setelah menjahit,
beberapa peran yang dapat dijatuhkan dari proyek tersebut. Dalam
proyekproyek
kecil, tidak dapat dihindari bahwa beberapa peran yang dialokasikan
untuk satu orang. Dalam proyek-proyek besar, peran masing-masing biasanya
ditutupi oleh anggota staf yang berbeda.
Beberapa peran yang relevan untuk proyek tersebut dapat dipindahkan ke
unit organisasi untuk seluruh panjang dari proyek. Ini praktis terutama
dalam
kasus seperti di mana aktivitas peran agak rumit dan peningkatan konstan
dalam pengetahuan dapat diharapkan sambil terus berhubungan dengan materi
pelajaran. Di atas semua itu, peran ini dapat berupa tugas cross-sectional
alam
dan menjadi prasyarat dan dasar untuk semua proyek.Mereka adalah
independen
dari proyek individu sejak layanan mereka diwajibkan oleh semua proyek.
Contoh umum adalah Manajer Proyek , Manajer Q , manajer CM , dan IT
Perwakilan . Contoh untuk alokasi peran untuk orang / unit organisasi
dalam
satu struktur organisasi dapat ditemukan dalam koleksi manual.
The V-Model mengasumsikan bahwa pengembangan sistem atau sistem
pemeliharaan
dan modi_kasi adalah fokus komisi. Biasanya, pelanggan merupakan
unit organisasi yang komisi pengembangan sistem lain unit organisasi baik
di
luar atau di dalam perusahaan otoritas /. Ketika mempertimbangkan pelanggan
dan kontraktor, ini tidak berarti bahwa peran dalam Model V- akan
digandakan
(peran pelanggan dan ontractor rolesc).Komunikasi tambahan dan tugas
koordinasi
harus ditentukan yang dapat menyebabkan pengaturan dari keputusan
lebih lanjut dan kelompok kemudi. R.2 Peran di V-Model Peran yang
diperintahkan
sesuai dengan submodels: dalam setiap submodel, ada _ salah satu
manajer yang mende_nisikan kondisi marjinal untuk kegiatan submodel dan
yang berfungsi sebagai pengambil keputusan atas, _ perencanaan perwakilan,
kemudi dan mengendalikan tugas-tugas dari submodel tersebut, satu atau
beberapa
orang yang bertanggung jawab atas tugas-tugas yang direncanakan dari
submodel tersebut. Tabel R. 1 menggambarkan peranan dari model V- .
CHAPTER 2. KONSEP V-MODEL 15
Tabel R1: Peran di V-Model
Peran di V-Model adalah:
_ Manajer Proyek
_ Pemimpin Proyek
_ Hukum Perwakilan
_ Proyek Administrator
_ Pengawas
_ Q Manajer
_ QA Manajer
_ Penaksir
_ CM Manajer
_ CM Perwakilan
_ CM Administrator
_ System Analyst
_ Sistem Designer
_ SW Pengembang
_ HW Pengembang
_ Teknis Penulis
CHAPTER 2. KONSEP V-MODEL 16
_ IT Perwakilan
_ SD Pengawas
_ Data Administrator
_ Perlindungan Data Spesialis
_ IT Security Perwakilan
_ Pemakai
_ Sistem Administrator
R.3 Alokasi Peran / Kegiatan
Untuk setiap submodel dari Model V- , alokasi peran untuk kegiatan yang
dijelaskan
oleh matriks. Beberapa peran dapat dialokasikan untuk satu kegiatan.
Entri dalam acara matriks jika peran dialokasikan untuk kegiatan yang
_ bertanggung jawab (r),
_ bekerjasama (c) atau
_ menasihati (a).
Tabel R.2 menggambarkan jenis partisipasi:
V model adalah metode pengembangan perangkat lunak yang mengijinkan
pada setiap prosesnya untuk dilakukan testing dan validasi. Jadi proses
baru
menggunakan hasil dari proses lama sebagai acuannya. Ini memungkinkan
meminimalisasikan
kesalahan pada prosesnya.
CHAPTER 2. KONSEP V-MODEL 17
2.2 Keuntungan V Model
_ Bahasa yang digunakan untuk merepresentasikan konsep V model menggunakan
bahasa formal. Contoh : dengan menggunakan objek model ataupun
frame-frame _ Meminimalisasikan kesalahan pada
hasil akhir karena ada test
pada setiap prosesnya
_ Penyesuaian yang cepat pada projek yang baru
_ Memudahkan dalam pembuatan dokumen projek
_ Biaya yang murah dalam perawatan dan modi_kasinya
_ V Model sangat _eksibel. V Model mendukung project tailoring dan
penambahan
dan pengurangan method dan tool secara dinamik. Akibatnya sangat
mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu
proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru
atau menghilangkan method dan tool yang dianggap sudah obsolete.
_ V Model dikembangkan dan di-maintain oleh publik. User dari V Model
berpartisipasi dalam change control board yang memproses semua change
request
terhadap V Model.
CHAPTER 2. KONSEP V-MODEL 18
2.3 Kerugian V Model
Akti_tas V-Model hanya difokuskan pada projectnya saja, bukan pada
keseluruhan
organisasi. V-Model adalah proses model yang hanya dikerjakan sekali
selama project saja, bukan keseluruhan organisasi.
Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses
model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.
Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang
dari metode yang lain. Kita tidak memiliki kesempatan untuk
mempertimbangkan
jika ada tools lain yang lebih baik.
Toolnya tidak selengkap yang dibicarakan. SDE (Software Development
Environment).
Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud
adalah _software yang mendukung pengembangan atau pemeliharaan / modi-
_kasi dari system IT. V Model adalah model yang project oriented sehingga
hanya bisa digunakan sekali dalam suatu proyek.
V Model terlalu _eksibel dalam arti ada beberapa activity dalam V Model
yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan
jelas
apa yang termasuk dalam activity tersebut dan apa yang tidak.
2.4 Penerapan V Model
V model biasa digunakan pada proyek-proyek dengan skala yang besar.
Sebagai
contohnya yaitu digunakan di Jerman untuk mengatur sistem administrasi
pemerintahannya dalam hal ini pada bagian BWB (Bundesamt für Wehrtechnik
und Bescha_ung = German Federal O_ce for Procurement).
2.5 Arsitektur
V Model terdiri dari 3 tahap. Secara garis besar tahap-tahap tersebut adalah
seperti yang akan dijelaskan di bawah ini.
2.5.1 Lifecycle process model
Lifecycle process model menjawab pertanyaan tentang apa yang harus
dilakukan.
Termasuk dalam tahap ini adalah menetapkan activity apa yang harus
dilakukan,
hasil apa yang diperoleh dari activity tersebut, dan apa saja yang
ada di dalam hasil tersebut.
CHAPTER 2. KONSEP V-MODEL 19
_ Allocation of methods
Allocation of methods menjawab pertanyaan bagaimana cara melakukannya.
Termasuk dalam tahap ini adalah penentuan method apa yang akan digunakan
untuk melakukan activity yang sudah ditetapkan pada tahap lifecycle
process
model.
_ Functional tool requirements
Functional tool requirements menjawab pertanyaan tool apa yang bisa digunakan
untuk melakukannya. Termasuk dalam tahap ini adalah penentuan functional
characteristic apa yang harus dimiliki oleh tool yang akan digunakan
untuk melakukan activity pada tahap lifecycle process model.
Pada setiap tahap di atas ada empat area of functionality yang dikenal
dengan
sebutan submodel. Keempat submodel tersebut adalah:
_ Project management (PM)
Submodel ini merencanakan, me-monitor, dan mengontrol proyek. Selain itu
submodel ini juga mengirimkan informasi pada submodel yang lain.
_ System development (SD)
Submodel ini men-develop software yang ingin dibuat.
_ Quality assurance (QA)
Submodel ini menspesi_kasikan standar kualitas yang diinginkan dan
memberitahukannya
pada submodel yang lain. Submodel ini juga menspesi_kasikan
contoh test case dan kriteria untuk memastikan bahwa software yang
dihasilkan
dan proses untuk menghasilkannya berdasarkan dan sesuai dengan standar
yang
telah ditetapkan.
_ Con_guration management (CM)
Submodel ini melakukan administrasi software yang dihasilkan.
Gambaran tentang tahap, submodel, dan hubungan antara tahap dan submodel
dalam V Model dapat dilihat pada gambar di bawah ini.
CHAPTER 2. KONSEP V-MODEL 20
2.5.2 Lifecycle Process Model
Lifecycle process model mempunyai beberapa basic element seperti yang akan
dijelaskan berikut ini.
_ Activitiy dan product
Activity dan product adalah workstep dalam development process. Eksekusi
dan hasil dari activityActivity dapat terdiri dari beberapa subactivity.
Activity
yang terletak pada level yang paling tinggi dikenal dengan sebutan main
activity
dan hasil dari activity adalah product. Activity mengubah state dari
product
atau activity mengubah product. Untuk setiap activityactivity description
yang dibuat berdasarkan suatu activity pattern yang disebut activity
schema.
dideskripsikan dengan tepat. ada sebuah Product dapat berupa document,
software, atau hardware. Product adalah hasil dari activity. Seperti
activity,
product dapat dipecah menjadi beberapa subproduct. Product dideskripsikan
dengan menggunakan product schema, di mana di dalamnya terdapat sinopsis
pendek dari product dan daftar structural item dari product.
_ Activity schema
Activity schema terdiri dari nama dari activity, product _ow, handling,
dan
recommendationexplanation. Berikut ini adalah penjelasan yang lebih detail
tentang masing-masing bagian dari activity schema tersebut.
o Nama dari activity menggambarkan nama dan nomor dari activity. Activity
di sini dapat berupa main activity atau subactivity. Subactivity diberi
nomor dengan notasi titik.
o Product _ow menggambarkan _ow dari product. Product _ow menggambarkan
input product dan output product dari activity. Pada input product,
CHAPTER 2. KONSEP V-MODEL 21
digambarkan dari activity mana input product berasal dan state dari input
product. Pada output product, digambarkan ke activityoutput product akan
dikirimkan dan state dari output product. mana
o Handling menggambarkan activity yang harus dilakukan. Jika main
activity,
maka subactivity, hubungan antar subactivity, dan hasil dari subactivity
harus digambarkan.
o Recommendation dan explanation memberikan saran-saran untuk pelaksanaan
activity dan memberikan penjelasan tentang de_nisi activity agar activity
tersebut lebih mudah dimengerti.
2.5.3 Product state
Product akan melalui berbagai macam state selama masa pembuatan dan
pemrosesannya.
Perubahan state product hanya dapat disebabkan oleh suatu activity.
Pada activity schemastate dari product ketika memasuki suatu activity dan
state dari product ketika keluar dari suatu activity. State dari product
dapat
dibedakan menjadi planned, being processed, submitted, dan accepted.
Berikut
ini adalah penjelasan setiap state tersebut secara lebih detail:
digambarkan
o Pada state planned product masih dalam masa perencanaan. Product
belum exist. State ini merupakan initial state dari setiap product.
o Pada state being processed product sedang dalam pemrosesan dan dalam
kontrol developer.
o Pada state submitted product dianggap sudah selesai berdasarkan sudut
pandang developer. Product lalu dikirimkan ke quality assurance (QA) untuk
penilaian. Kalau quality assuranceproduct akan kembali ke state being
processed. Kalau quality assurance (QA) menerima, maka product ke state
accepted. (QA) menolak, maka
o Pada state accepted product sudah diterima oleh quality assurance (QA)
dan oleh karena itu product sudah siap untuk diedarkan. Product yang sudah
diedarkan hanya dapat dimodi_kasi jika version number product di-update.
State dari product dan transisinya dapat dilihat pada gambar di bawah ini.
CHAPTER 2. KONSEP V-MODEL 22
- Organization dan role
Pembagian tugas kepada project member dilakukan berdasarkan role. Daftar
role dibuat untuk setiap submodel. Setiap role mende_nisikan activity apa
yang dilakukan, responsibility dari role, skill yang dibutuhan,
pengetahuan yang
dibutuhkan, dan ketergantungan role tersebut dengan role-role lainnya.
Organization dibentuk dengan memilih project member untuk setiap submodel
dan memilih role untuk mereka. Sebuah role dapat diberikan ke satu atau
lebih project member. Seorang project member juga dapat memiliki lebih
dari
satu role. Daftar role yang ada pada keempat submodel dari V Model dapat
dilihat di bawah ini.
CHAPTER 2. KONSEP V-MODEL 23
Penjelasan tentang keempat submodel yang ada dalam V Model dilihat dari
sudut pandang lifecycle process model.
2.5.4 Allocation Of Methods
Tahap ini mengatur pemilihan dan penerapaan method untuk semua submodel
yang ada. Tahap ini mendukung lifecycle process model karena tahap ini
menspesi
_kasikan bagaimana cara melakukannya sedangkan lifecycle process model
menspesi_kasikan apa yang harus dilakukan.
Ada dua jenis method, yaitu basic method dan complex method. Basic
method mengarah pada prosedur yang menggambarkan beberapa aspek unik
dari sistem (misal aspek functional atau aspek data oriented) atau bagian
tertentu
dari system development (misal analysis atau design). Basic method dapat
dikategorisasikan. Kategori menggabungkan beberapa basic method yang
menawarkan beberapa solusi yang berbeda untuk suatu problem tertentu.
CHAPTER 2. KONSEP V-MODEL 24
Complex method mengarah pada prosedur yang menggabungkan berbagai
macam methodical component dan mengintegrasikannya ke dalam satu method.
Untuk setiap activity, suatu method dipilih. Untuk membuat proses
pemilihan
ini lebih mudah, maka pada tahap ini telah digambarkan apa saja yang perlu
dilakukan pada pemilihan method. Berikut ini struktur dari suatu method:
- Identi_kasi dan de_nisi dari method
- Karakteristik umum dari method
- Keterbatasan method
-Spesi_kasi dari penggunaan method (bagaimana method akan digunakan
pada activity)
-Interface terhadap method lain yang saling mendukung, misal use case
modeling
mempunyai interface ke class object modeling, state transition modeling,
dan interaction modeling
2.5.5 Functional Tool Requirements
Tahap ini mengatur pemilihan dan penggunaan tool untuk semua submodel.
Tahap ini mendukung lifecycle process model dan allocation of method.
Tool dapat dide_nisikan sebagai suatu software product yang mendukung
development, maintenance, atau modi_cation dari suatu sistem teknologi
informasi.
Tool dikelompokkan menjadi beberapa service unit. Sebuah service
unit mende_nisikan requirement untuk semua tool yang ada pada service unit
tersebut. Service unit ini lalu dikelompokkan ke dalam suatu service
complex.
Service complex ini dapat berupa salah satu dari submodel. Empat tahap
dalam
pemilihan tool adalah:
-Pertama dilakukan spesi_kasi fungsionalitas apa saja yang harus dimiliki
oleh tool berdasarkan fungsionalitas yang dibutuhkan pada proyek. Hasilnya
adalah pemilihan beberapa service unit yang memenuhi fungsionalitas yang
dibutuhkan proyek.
-Tahap kedua dapat dibagi dalam dua bagian. Bagian pertama adalah
memilih service unit dan application condition untuk menggunakan tool
sebagai
input. Dalam melakukannya dipertimbangkan special environmental condition
dan prioritas dari requirement. Hasilnya adalah functional requirement
dari
tool. Bagian kedua adalah menggunakan application condition untuk tool
sebagai
input. Bagian ini menspesi_kasi technical dan organization requirement.
Hasilnya adalah technical requirement dari tool.
CHAPTER 2. KONSEP V-MODEL 25
-Pada tahap ketiga, functional dan technical requirement untuk tool
dirangkum
dan menghasilkan operational criteria catalogue yang menggambarkan
_nal requirement dari tool.
-Pada tahap terakhir dilakukan perbandingan antar tool dengan bantuan
tool description atau pro_le dan operational criteria catalogue. Hasilnya
adalah
applicable tool.
_ Project management (PM)
Submodel ini mengatur aktivitas inisialisasi, planning, dan monitoring
proyek.
Submodel ini terdiri dari empat belas main activity yaitu:
o Project initialization Project initialization mende_nisikan
organizational
framework pada project manual. Tailoring dari V Model untuk suatu proyek
tertentu
dilakukan berdasarkan project criteria dan condition. Preliminary planning
dilakukan berdasarkan project manual dan didokumentasikan di project
plan.
o Placement/procurement Placement/procurement meliputi pengiriman
permintaan
proposal ke beberapa subcontractor yang mungkin digunakan, mengevaluasi
response yang diberikan oleh subcontractor, dan menentukan penawaran
yang paling menguntungkan secara ekonomi.
o Contractor management Tujuan dari activity ini adalah untuk melakukan
supervisi terhadap kontrak yang sudah dibuat untuk memastikan bahwa
kontrak
dipenuhi, baik itu kontrak terhadap customer maupun kontrak terhadap
subcontractor.
o Detailed planning
Tujuan dari activity ini adalah untuk membuat detailed plan dari proyek.
Hal ini dilakukan dengan menggunakan preliminary plan dan spesi_kasi yang
terdapat pada project manual.
o Cost/bene_t analysis
Tujuan dari activity ini adalah untuk menentukan seberapa pro_table solusi
yang sudah direncanakan. Setiap solusi dievaluasi berdasarkan cost dan
bene_t-nya.
o Phase review
Setelah setiap project phase selesai dilakukan, maka dilakukan phase
review.
Phase review dilakukan untuk memeriksa status dari proyek berdasarkan
project
plan yang sudah dibuat.
o Risk management
CHAPTER 2. KONSEP V-MODEL 26
Tujuan dari activity ini adalah untuk mendeteksi risk dari proyek sedini
mungkin. Risk di-manage dengan cara melakukan preventive measure dan
mensupervisi
seberapa efektif langkah yang sudah dilakukan.
o Project control
Tujuan dari activity ini adalah untuk mengontrol perkembangan proyek.
Jika proyek melenceng dari perencanaan, maka harus diambil tindakan untuk
memperbaikinya supaya proyek dapat kembali berjalan sesuai dengan apa yang
sudah direncanakan.
o Information service/reporting
Tujuan dari activity ini adalah untuk membuat informasi tentang proyek
available bagi customer, subcontractor, dan project member.
o Training/instruction
Tujuan dari activity ini adalah untuk memberikan training bagi project
member sehingga mereka dapat memiliki pengetahuan yang diperlukan untuk
melakukan role-nya.
o Supplying resources
Tujuan dari activity ini adalah untuk memberikan resource yang dibutuhkan
agar goal dari proyek dapat tercapai.
o Allocation of work order
Tujuan dari activity ini adalah untuk melakukan pembagian kerja
berdasarkan
work order.
o Sta_ training
Tujuan dari activity ini adalah untuk memperkenalkan project member pada
pekerjaan mereka. Tugas dari setiap project member dijelaskan dan
diberitahukan.
o Project completion
Tujuan dari activity ini adalah untuk closing dari proyek. Termasuk di
dalamnya adalah penulisan _nal project report dan semua project
experience.
_ System development (SD)
Submodel ini melakukan regulasi terhadap semua activity yang berhubungan
dengan pembuatan software. Submodel ini terdiri dari sembilan main
activity
yaitu:
o System requirement analysis
Termasuk dalam activity ini adalah pembuatan software requirement
berdasarkan
sudut pandang user atau dapat dikatakan sebagai pembuatan software
requirement
dari sudut pandang external.
CHAPTER 2. KONSEP V-MODEL 27
o System design
Termasuk dalam activity ini adalah pemilihan system architecture dan
membuat
integration plan untuk architecture tersebut.
o Software/ hardware requirement analysis
Termasuk dalam activity ini adalah melakukan update terhadap technical
requirement dan operational information dengan mempertimbangkan software
dan hardware requirement. Hal ini dilakukan dengan menggunakan user
requirement,
system architecture, dan technical requirement yang sudah dibuat
sebelumnya.
o Preliminary software design
Termasuk dalam activity ini adalah desain dari software architecture, di
mana termasuk di dalamnya adalah menyelesaikan interface description dan
meng-update software integration plan.
o Detailed software design
Pada activity ini software architecture dan interface description
dijelaskan
lebih lanjut. Spesi_kasi dan detail untuk setiap module, component, dan
database
dibuat.
o Software implementation
Pada activity ini dilakukan implementasi dari module, component, dan
database
dalam beberapa tahap.
o Software integration
Pada activity ini dilakukan integrasi antara module, component, dan
database.
o System integration
Pada activity ini dilakukan integrasi sistem. Software dan hardware
component
diintegrasikan berdasarkan system architecture.
o Transition to utilization
Termasuk dalam activity adalah hal-hal yang harus dilakukan untuk
mengoperasikan
sistem pada environment yang telah ditetapkan.
Gambaran tentang kesembilan main activity tersebut dapat dilihat pada
gambar di bawah ini.
CHAPTER 2. KONSEP V-MODEL 28
Gambar 3. Submodel System Development
_ Quality assurance (QA)
Submodel ini mengatur activity dan product dari submodel lain dengan cara
melakukan penilaian. Submodel ini terdiri dari lima main activity:
o Quality assurance initialization
Activity ini meliputi spesi_kasi organizational dan procedural scope dari
quality assurance activity. Semua spesi_kasi untuk product dan proses
didokumentasikan
dalam quality assurance plan.
o Assessment preparation
Activity ini meliputi pembuatan assessment plan, di mana di dalamnya
terdapat
de_nisi dari assessment method, criteria, environment, dan test case.
o Process assessment of activity
Activity ini meliputi dilakukannya assessment pada proses untuk menentukan
apakah proses tersebut memadai atau tidak.
CHAPTER 2. KONSEP V-MODEL 29
o Product assessment
Activity ini meliputi dilakukannya assessment pada product.
o Quality assurance reporting
Activity ini meliputi evaluasi assessment report berdasarkan severity dari
problem, klasi_kasi problem, dan penyebab dari problem.
_ Con_guration management (CM)
Submodel ini menjamin bahwa suatu product dapat diidenti_kasi setiap saat.
Identi_kasi ini dilakukan untuk mengontrol modi_kasi dan menjamin
integritas.
Submodel ini terdiri dari empat main activity yaitu:
o Con_guration management planning
Activity ini meliputi pende_nisian organizational framework dan
pendokumentasiannya
dalam con_guration management plan. Resource dan tool yang
dibutuhkan juga didokumentasikan dalam con_guration management plan.
o Product and con_guration management
Activity ini meliputi pengelolaan product library dengan melakukan
pengkatalogan
product.
o Change management
Activity ini meliputi change management yang dilakukan dalam 3 tahap.
Pertama perubahan di-request dan di-register oleh con_guration management.
Kedua perubahan tersebut dievaluasi dan diambil keputusan apakah perubahan
tersebut diterima atau ditolak. Terakhir, jika perubahan tersebut diterima
maka
perubahan tersebut akan diimplementasikan dan semua yang dipengaruhi oleh
perubahan tersebut diberitahu.
o Con_guration management service
Termasuk di dalam activity ini adalah pengkatalogan software product,
koordinasi
interface, backup,
release management, dan pencatatan project history.
2.6 Macam- Macam V-Model
2.6.1 V Model Aristoteles
Model ini adalah model komunikasi yang paling klasik, yang sering juga
disebut
model retoris. Model ini sering disebut sebagai seni berpidato. Menurut
Aristoteles, persuasi dapat dicapai oleh siapa anda (etos-kererpercayaan
anda),
argumen anda (logos-logika dalam emosi khalayak). Dengan kata lain,
faktorfaktor
yang memainkan peran dalam menentukan efek persuatif suatu pidato
CHAPTER 2. KONSEP V-MODEL 30
meliputi isi pidato, susunannya, dan cara penyampainnya. Salah satu
kelemahan
model ini adalah bahwa komunikasi dianggap sebagai fenomena yang statis.
2.6.2 V Model Lasswell
Model ini berupa ungkapan verbal, yaitu : Who Says What In Which Channel
To Whom With What E_ect Lasswell mengemukakan tiga fungsi komunikasi
yaitu :
1. Pengawasan Lingkungan _ yang mengingatkan anggota-anggota masyarakat
akan bahaya dan peluang dalam lingkungan.
2. Korelasi berbagai bagian terpisah dalam masyarakat yang merespon
lingkungan,
3. Transmisi warisan sosial dari suatu generasi ke generasi lainnya. Akan
tetapi model ini dikritik karena model ini mengisyaratkan kehadiran
komunikator
dan pesan yang bertujuan. Model ini juga terlalu menyederhanakan
masalah.
2.6.3 V Model Shannon dan Weaver
Model yang sering disebut model matematis atau model teori informasi.
Model
itu melukiskan suatu sumber yang menyandi atau menyiptakan pesan dan
menyampaikannya
melalui suatu saluran kepada seorang penerima. Konsep penting
Shannon dan Weaver adalah : Gangguan (noise), Setiap rangsangan tambahan
dan tidak dikendaki yang dapat mengganggu kecermatan pesan yang
disampaikan.
Konsep lain yang ikut andil adalah entropi dan redundasi serta
keseimbangan yang diperlukan diantara keduanya untuk menghasilkan
komunikasi
yang e_sien dan dapat mengatasi gangguan dalam saluran. Sayangnya,
model ini juga memberikan gambaran yang parsial, komunikasi dipandang
sebagai
fenomena satu arah.
2.6.4 V Model Newcomb
Komunikasi adalah suatu cara yang lazim dan efektif yang memungkinkan
orang
orang mengorientasikan diri terhadap lingkungan mereka. Ini adalah model
tindakan
komunikatif dua orang yang disengaja. Model ini mengisyaratkan bahwa
CHAPTER 2. KONSEP V-MODEL 31
setiap sistem ditandai oleh suatu keseimbangan atau simetri,karena
ketidakkeseimbangan
atau kekurangan simetri secara psikologis tidak menyenangkan dan
menimbulkan tekanan internal untuk memulihkan keseimbangan.
2.6.5 V Model Westley dan Maclean
Menurut pakar ini, perbedaan dalam umpan balik inilah yang membedakan
komunikasi
antarpribadi dengan komunikasi massa. Umpan balik dari penerima
bersifat segera dalam komunikasi antarpribadi, dalam komunikasi massa
bersifat
minimal atau tertunda. Sumber dalam komunikasi antar pribadi dapat
langsung
memanfaatkan umpan balik dari penerima sedangkan dalam komunikasi
massa sumber misalnya penceramah agama, calon presiden yang berdebat dalam
rangka kampanye politik. Konsep pentingnya adalah Umpan balik, Perbedaan
dan kemiripan komunikasi antarpribadidengan komunikasi massa. Pesan ini
juga membedakan pesan yang bertujuan dan pesan yang tidak bertujuan.
2.6.6 V Model Gerbner
Model verbal Gerbner adalah :
1. Seseorang ( sumber, komunikator )
2. Mempersepsi suatu kejadian
3. Dan bereaksi
4. Dalam suatu situasi
5. Melalui suatu alat
6. Untuk menyediakan materi
7. Dalam suatu bentuk
8. Dan konteks
9. Yang mengandung isi
10. Yang mempunyai suatu konsekuensi
CHAPTER 2. KONSEP V-MODEL 32
2.6.7 V Model Berlo
Menurut model Berlo, sumber dan penerima pesan dipengaruhi oleh faktor :
1. Keterampilan komunikasi
2. Sikap
3. Pengetahuan
4. Sistem sosial
5. Budaya Salah satu kelebihan model ini adalah model ini tidak terbatas
pada komunikasi publik atau komunikasi massa, namun juga komunikasi
antarpribadi dan berbagai bentuk komunikasi tertulis. Model ini bersifat
heuristik (merangsang penelitian).
2.6.8 V Model DeFleur
Source dan Transmitter adalah dua fase yang berbeda yang dilakukan
seseorang,
fungsi receiver dalam model ini adalah menerima informasi dan menyandi
baliknya mengubah peristiwa _sik informasi menjadi pesan. Menurut DeFleur
komunikasi adalah terjadi lewat suatu operasi perangkat komponen dalam
suatu
sistem teoretis, yang konsekuensinya adalah isomor_sme diantara respons
internal terhadap seperangkat simbol tertentu pada pihak pengirim dan
penerima.
2.6.9 V Model Tubbs
Pesan dalam model ini dapat berupa pesan verbal, juga non verbal, bisa
disengaja
ataupun tidak disengaja. Salurannya adalah alat indera, terutama
pendengaran,
penglihatan dan perabaan
Gangguan dalam model ini ada 2, gangguan teknis dan gangguan semantik.
Gangguan teknis adalah faktor yang menyebabkan si penerima merasakan suatu
perubahan dalam informasi atau rangsangan yang tiba, misalnya kegaduhan.
Ganguan semiatik adalah pemberian makna yang berbeda atas lambang yang
disampaikan pengirim.
2.6.10 V Model Gudykunst dan Kim
Merupakan model antar budaya, yakni komunikasi antara budaya yang
berlainan,
atau komunikasi dengan orang asing.
CHAPTER 2. KONSEP V-MODEL 33
Menurut Gudykunst dan Kim, penyandian pesan dan penyandian balik pesan
merupakan suatu proses interaktif yang dipengaruhi oleh _lter-_lter
konseptual
yang dikategprikan menjadi faktor-faktor budaya, sosial budaya,
psikobudaya,
dan faktor lingkungan.
2.6.11 V Model Interaksional
Para peserta komunikasi menurut model interaksional adalah orang-orang
yang
mengembangkan potensi manusiawinya melalui interaksi sosial, tepatnya
melalui
apa yang disebut pengambilan peran orang lain. Diri berkembang lewat
interaksi
dengan orang lain, dimulai dengan orang terdekatnya seperti keluarga
dalam suatu tahap yang disebut tahap permainan dan terus berlanjut hingga
kelingkungan luas dalam suatu tahap yang disebut tahap pertandingan.
Chapter 3
Software Pendukung
3.1 WEIGHTED PRODUCT MODEL
{Underwriting, Fuzzy-AHP}
Underwriting yaitu aktivitas proses penerbitan polis dimulai dari sejak
calon
pemegang polis akan menandatangani Surat Permintaan (SP) sampai penerbitan
polis dan menyerahkan kepada pemegang polis.
Fungsi seleksi sangat dominan, artinya bahwa proses tersebut telah
didominasi
oleh seleksi lapangan yang meliputi aspek non medis maupun aspek medis.
Adapun sasaran underwriter dalam membuat akseptasi dan penerbitan polis
harus memenuhi 3 kepentingan yaitu adil bagi nasabah, dapat dijual dan
menguntungkan
untuk perusahaan. Sehubungan dengan hal di atas, maka dibuat
Aplikasi pendukung keputusan untuk membantu AJB Bumiputera 1912 dalam
menentukan akseptasi dan penerbitan polis. Dengan adanya sistem diharapkan
dapat membantu AJB Bumiputera 1912 khususnya Departemen Pertanggungan
untuk meningkatkan kualitas keputusan yang dihasilkan dimana keputusan
ini terdiri atas Asuransi diterima (diaksep) standard, Asuransi diterima
substandard,
Asuransi ditolak (decline), asuransi ditunda (postpone), dan asuransi
dipending Metode yang digunakan untuk menentukan penerbitan polis
yaitu Metode Fuzzy-AHP (Analytic Hierarchical Process) dan MetodeWeighted
Product Model kemudian perangkat lunak ini menggunakan PHP dan MySQL
sebagai databasenya. Fuzzy-AHP (Analytic Hierarchical Process) digunakan
untuk proses analisis terhadap suatu masalah secara berjenjang dan terstruktur.
34
CHAPTER 3. SOFTWARE PENDUKUNG 35
Sedangkan untuk Weighted Process Model digunakan pembobotan kriteria
dan dapat digunakan pada keputusan single atau keputusan multidimensional.
Kedua metode digunakan secara serial dan paralel.Berdasarkan hasil pengujian
tingkat kepuasan user yang disebarkan ke lokasi studi kasus penelitian
dengan 6 responden diperoleh rata-rata indeks kepuasan pengguna secara
keseluruhan
sebesar 75.56%. Kata kunci: Underwriting,Weighted Product Model,
Fuzzy-AHP (Analytic Hierarchical Process) Underwriting merupakan seleksi
dan penilaian resiko calon pemegang polis dan calon tertanggung untuk
mendapatkan
polis asuransi. Aktivitas penerbitan polis dimulai dari sejak pemegang
polis
menandatangani surat permintaan (SP) sampai penerbitan polis dan
menyerahkan
kepada pemegang polis.
Seleksi dan penilaian resiko meliputi aspek non medis maupun aspek medis.
Selama ini pengambilan keputusan dilakukan secara manual oleh pihak
Bumiputera
dengan melihat data calon pemegang polis sehingga memungkinkan terjadi
kesalahan dalam pengambilan keputusan yang akibatnya akan merugikan
perusahaan. Sedangkan dalam pengambilan keputusan harus mampu mencapai
sasaran dan tujuan yaitu adil bagi nasabah, dapat dijual agen dan
menguntungkan
bagi perusahaan.
Selama ini banyak aplikasi Sistem Pangambilan Keputusan menggunakan
metode AHP namun menurut beberapa penelitian, metode AHP memiliki beberapa
kekurangan yaitu menggunakan perkiraan skala yang tidak seimbang
pada perbandingan berpasangan [Chan, 2003].
Oleh karena itu, beberapa akademik mencoba mengaplikasikan prinsip logika
fuzzy dengan perluasan AHP yang disebut dengan metode Fuzzy-Analytic
Hierarchy
Process untuk memperbaiki kekurangan dari AHP . Dengan referensi
tersebut penulis mencoba menggunakan metode Fuzzy-AHP pada penerapan
aplikasi pendukung underwriting dan penerbitan polis untuk menghasilkan
alternatif
keputusan .
Dimana Fuzzy-AHP sangat berguna dalam masalah-masalah kompleks yang
tidak terstruktur seperti pada seleksi dan penilaian resiko calon pemegang
polis.
Dengan Fuzzy-AHP, kriteria tersebut dide_nisikan dalam struktur hirarki
sehingga menjadi lebih sederhana dan dipahami. Metode Fuzzy-AHP digunakan
pada penentuan goal keputusan dan pembobotan kriteria pada level induk
pada
aplikasi yang akan penulis buat. Selain menggunakan Fuzzy-AHP, penulis
juga
menggunakan metode Weighted Product Model yang digunakan untuk menentukan
pembobotan kriteria pada level anak kesehatan serta mempercepat proses
perhitungan pada level subkriteria.
CHAPTER 3. SOFTWARE PENDUKUNG 36
WPM digunakan untuk mempermudah user untuk memberikan pembobotan
terhadap kriteria yang memiliki nilai yang hampir sama dan pada aplikasi
pendukung
ini WPM akan membantu pada kasus yang hanya memiliki 1 kriteria
seperti pada seleksi dan resiko calon pemegang polis, selain itu WPM dapat
digunakan untuk pengambilan keputusan single maupun multidimensional.
Kedua
metode digunakan secara serial dan paralel Sehubungan dengan hal di atas,
maka penulis berupaya untuk membuat aplikasi pendukung keputusan untuk
membantu AJB Bumiputera 1912 dalam menentukan underwriting akseptasi
dan penerbitan polis. Dengan adanya aplikasi pendukung keputusan
diharapkan
dapat membantu AJB Bumiputera 1912 khususnya Departemen Pertanggungan
untuk meningkatkan kualitas keputusan serta menghasilkan alternatif
keputusan
dimana keputusan ini terdiri atas Asuransi diterima (diaksep) standard,
Asuransi diterima substandard, Asuransi ditolak (decline), asuransi
ditunda
(postpone), dan asuransi dipending. Alternatif keputusan yang dihasilkan
akan
menjadi rekomendasi bagi pihak AJB Bumiputera 1912.
Tujuan dalam Penelitian ini adalah :
1. Membangun aplikasi pendukung yang mampu memberi pertimbangan keputusan
underwriting akseptasi dan penerbitan polis berdasarkan persyaratan
yang ada.
2. Menerapkan metode pembobotan Fuzzy-AHP danWeighted Product Model
dalam membangun aplikasi pendukung underwriting akseptasi dan penerbitan
polis pada AJB Bumiputera 1912
3. Mengevaluasi alternatif keputusan yang dihasilkan oleh aplikasi
pendukung
underwriting akseptasi dan penerbitan polis pada AJB Bumiputera 1912.
Batasan
Untuk mendukung kegiatan penelitian, sistem yang akan dibuat memiliki
batasanbatasan
sebagai berikut: i. Metode pengambilan keputusan yang digunakan
adalah Fuzzy-AHP dan Weighted Product Model yang digunakan secara serial
dan paralel. ii. Data yang digunakan sebagai studi kasus adalah data dari
AJB
Bumiputera 1912 Surabaya iii. Hanya menangani asuransi jiwa perorangan.
iv.
Proses underwriting akseptasi dan penerbitan polis hanya sampai pada tahap
seleksi resiko. v. Persyaratan yang digunakan sebagai pertimbangan dalam
CHAPTER 3. SOFTWARE PENDUKUNG 37
mendukung pengambilan keputusan underwriting akseptasi dan penerbitan
polis
dikelompokkan menjadi 3 kriteria yaitu:
1. Seleksi _sik kesehatan
2. Seleksi _nancial
3. Pengamatan nilai ekonomis
3.2 Metode Fuzzy-AHP (FAHP)
Analytic Hierarchy Process (AHP) telah digunakan secara luas untuk
menyelesaikan
masalah multicriteria decision-making .
Bagaimanapun, seharusnya untuk kesamaran dan ketidakpastian pada
pertimbangan
pengambilan keputusan, crisp, perbandingan pasangan dengan AHP
konvensional tidak dapat mengambil secara akurat pertimbangan pengambilan
keputusan (Ayað, 2005) Pada AHP konvensional, perbandingan pasangan
menentukan skala 9 poin dimana mengubah preferensi manusia antara
alternatif
yang tersedia secara seimbang, moderat, kuat dan lebih disukai.Walaupun
skala dari AHP memiliki keuntungan dari kesederhanaan dan penggunaan yang
lebih mudah, namun tidak cukup untuk mengambil laporan ketidakpastian yang
diasosiasikan dengan pemetaan pada bilangan.
Oleh karena itu, logika fuzzy diperkenalkan dengan perbandingan
berpasangan
sehingga cocok untuk menutupi kekurangan pada AHP traditional. Yang
kemudian mengarah pada fuzzy-AHP.
Bahasa penaksiran dari perasaan dan pertimbangan manusia adalah tidak
jelas dan tidak beralasan untuk merepresentasikannya pada bilangan yang
tepat.
Untuk memberikan interval keputusan dengan nilai yang tepat pada keputusan
lebih dipercaya oleh pembuat keputusan.
Triangular fuzzy numbers digunakan untuk memutuskan prioritas dari
variabel
satu keputusan pada fuzzy- AHP. (Chan and Kumar, 2005) Fuzzy-AHP
adalah alat yang e_sien untuk menangani ketidakjelasan data di dalam memutuskan
pilihan dari variabel keputusan yang berbeda.
Perbandingan direpresentasikan dalam bentuk triangular fuzzy numbers untuk
membangun matrix perbandingan berpasangan fuzzy (Ghodsypour and
O.Brien, 1998).
Pada pendekatan triangular fuzzy numbers digunakan untuk memilih pilihan
dari satu kriteria dari yang lain dan kemudian menggunakan metode analisis
CHAPTER 3. SOFTWARE PENDUKUNG 38
yang lebih luas, menghitung nilai sintetik luas dari perbandingan
berpasangan,
Berdasarkan pendekatan ini, bobot vektor dapat diputuskan dan
dinormalisasi,
kemudian bobot vektor yang telah dinormalisasi akan diputuskan. Prioritas
terbesar dapat diberikan pada bobot dengan nilai terbesar.
(Chan and Kumar, 2005). Untuk skala perbandingan berpasangan pada
fuzzy-AHP sama dengan skalaperbadingan berpasangan pada AHP.
Weighted Product Model (WPM)
WPM menggunakan perkalian untuk merankingalternatif. Tiap alternatif
dibandingkan dengan yanglainnya dengan mengkalikan bilangan ratio,
satuuntuk
tiap kriteria. Tiap rasio dinaikkan untukkekuatan dari bobot relative dari
kriteria yang cocok. Umumnya, di dalam membandingkan 2 alternatif Akdan
Al, rumus yang digunakan adalah sebagai berikut:
Penggabungan Metode Fuzzy-AHP dan WPM pada Aplikasi Pen-
dukung Underwriting dan Akseptasi Calon Pemegang Polis
Penggabungan metode Fuzzy-AHP dan WPM memiliki alasan sebagai berikut:
1. Pada kasus Underwriting dan Akseptasi Calon Pemegang polis memiliki
kriteria yang kompleks dan tidak terstruktur sehingga dibutuhkan metode
Fuzzy-AHP dan WPM merupakan metode decision analytic yang dapat
menangani masalah yang tidak terstruktur maupun semi terstruktur.
2. Menggabungkan kelebihan dan mengurangi kekurangan yang dimiliki oleh
masing-masing metode.
3.2.1 Fuzzy-AHP
_ Kelebihan metode Fuzzy-AHP adalah:
CHAPTER 3. SOFTWARE PENDUKUNG 39
Memperbaiki metode AHP sehinggametode Fuzzy-AHP mampu mengatasi nilai
antara pada perbandingan nilaiberpasangan(2, 4, 6, 8). Selain itu
memberikan
kemudahan bagi user di dalam menentukan pembobotan karena user hanya
memasukkan tingkat kepentingan berdasarkan perbandingan berpasangan.
_ Kelemahan metode Fuzzy-AHP adalah:
Penggunaan metode Fuzzy-AHP membutuhkan waktu yang lama karena banyak
membutuhkan interaksi user untuk menginputkan untuk menginputkan nilai
perbandingan barpasangan. Selain itu apabila ada 2 kriteria yang memiliki
nilai hampir sama jika menggunakan Fuzzy- AHP akan menghasilkan nilai 0
dan 1.
3.2.2 WPM
_ Kelebihan metode WPM adalah:
Untuk memberikan kemudahan pembobotan terhadap kriteria yang memiliki
nilai yang hampir sama serta dapat digunakan untuk keputusan single atau
keputusan multidimensional.
_ Kelemahan metode WPM adalah:
Apabila user menginputkan bobot lansung dengan nilai 0 maka otomatis hasil
goal dari keputusan akan bernilai 0 sehingga nilai-nilai kriteria yang
lain tidak
berpengaruh.
3.3 Umbrella Frame Works
Struktur kerangka payung mirip dengan kerangka kerja standar, dan aplikasi
tidak membedakan antara kerangka payung dan kerangka kerja standar ketika
terhubung ke mereka. Namun, dua faktor membedakan kerangka payung dari
kerangka kerja lainnya. Yang pertama adalah cara di mana mereka termasuk
_le header. Yang kedua adalah kenyataan bahwa mereka merangkum subframeworks.
Tujuan dari Umbrella Frame Works Tujuan dari Umbrella Frame Works
adalah untuk menyediakan semua yang diperlukan untuk antarmuka pemrograman
dalam lingkungan aplikasi tertentu. Kerangka payung menyembunyikan
kompleks silang-dependensi antara potongan-potongan yang berbeda dari
CHAPTER 3. SOFTWARE PENDUKUNG 40
perangkat lunak sistem. Dengan demikian Anda tidak perlu tahu apa set
kerangka kerja dan perpustakaan Anda harus mengimpor untuk menyelesaikan
tugas tertentu. Kerangka payung juga membuat lebih cepat membangun mungkin
melalui penggunaan precompiled header.
Sebuah frame works hanya mencakup dan hubungan dengan konstituen
subframeworks
dan kerangka kerja umum lainnya. Sebuah kerangka payung mencakup
semua teknologi dan API yang mende_nisikan lingkungan aplikasi atau
lapisan perangkat lunak sistem. Ini juga menyediakan lapisan abstraksi
antara
apa pengembang luar menghubungkan program mereka dengan apa yang Apple
dan rekayasa menyediakan sebagai implementasi.
Subframework adalah kerangka struktural masyarakat yang paket satu
teknologi
Apple yang spesi_k, seperti acara-acara Apple, Quartz, atau Open
Transport.
Namun, subframework adalah masyarakat dengan pembatasan. Meskipun API
dari subframeworks bersifat publik, Apple telah menempatkan mekanisme
untuk
mencegah pengembang dari menghubungkan langsung dengan subframeworks
(lihat "Pembatasan Subframework Menghubungkan"). Subframework A
selalu
berada dalam kerangka payung dipasang di / System / Library / Frameworks,
dan dalam kerangka payung, _le header yang terkena.
Beberapa kerangka payung meliputi kerangka payung lain, ini terutama
terjadi
dengan kerangka payung untuk lingkungan aplikasi Karbon dan Kakao.
Sebagai contoh, baik Karbon dan Kakao (langsung atau tidak langsung) impor
dan link dengan kerangka Layanan payung Inti (CoreServices.framework). Ini
kerangka payung, pada gilirannya, impor dan hubungan dengan subframeworks
seperti Yayasan Inti.
Komposisi yang tepat dari subframeworks dalam kerangka payung adalah
detail subjek implementasi internal untuk mengubah. Dengan menyediakan
tingkat tipuan, kerangka payung melindungi pengembang dari perubahan ini.
Apple mungkin merestrukturisasi subframeworks dalam kerangka payung dan
mungkin menambah, mengubah nama, atau menghapus _le header dalam
subframeworks.
Jika Anda memasukkan _le induk header untuk subframework
tersebut, perubahan ini tidak akan mempengaruhi program Anda.
The Bundle Payung Kerangka Secara _sik, kerangka payung memiliki struktur
yang mirip dengan kerangka kerja standar. Salah satu perbedaan yang
signi_kan adalah penambahan direktori dari Kerangka mengandung
subframeworks
yang membentuk kerangka payung.
Kode 4 menunjukkan pencatatan kerangka Inti Jasa. (Isi subframeworks
tidak termasuk karena mereka tidak dirujuk pula.) Seperti kerangka kerja
stanCHAPTER
3. SOFTWARE PENDUKUNG 41
dar, top-level item adalah link simbolik ke item lebih dalam struktur
direktori
framework. Dalam hal ini, perpustakaan terkait dan direktori berada di
folder
A dari kerangka.
Subframework Setiap dapat dimasukkan dalam lebih dari satu Kerangka
Payung, dan Kerangka Payung mungkin sendiri mengandung Frameworks Payung
lainnya. Misalnya, Kerangka Payung Karbon berisi Core Services Framework
Payung yang berisi Kerangka Yayasan Inti. Sebuah pengembang menciptakan
aplikasi Carbon hanya perlu # include <Carbon.h>. Mencoba untuk #
include
<CoreFoundation/CFString.h> akan menghasilkan pesan kesalahan yang
menjelaskan
bahwa Yayasan Core merupakan subframework dan harus dikaitkan
dengan melalui Kerangka Payung gantinya.
Sistem ini menyediakan Apple dengan banyak _eksibilitas implementasi.
Sifat multi-versi Kerangka menyediakan kompatibilitas mundur, dan segala
sesuatu
tetapi Kerangka Payung itu sendiri dapat dipindahkan, diganti namanya,
dan kembali dilaksanakan tanpa mempengaruhi aplikasi yang ada.
3.4 Bundel Bungkus-up
Sebagian besar dari apa yang orang anggap sebagai "Mac OS X"
adalah semacam
Bundle, biasanya Framework. Kebanyakan dari mereka blok dalam diagram
blok di artikel sebelumnya sesuai dengan Kerangka dari beberapa jenis.
Bahkan
API melalui mana pengembang mengakses dan memanipulasi Kerangka (dan
jenis-jenis Bundel) yang terkandung dalam diri mereka Framework. Semua
orang Frameworks adalah apa yang membuat Mac OS X sangat berbeda dari
yang lain Unix-seperti sistem operasi, termasuk proyek sendiri Darwin
Apple.
Memang, Mac OS X pada dasarnya adalah "Darwin ditambah tumpukan
Frameworks"
(dan aplikasi yang dibangun pada mereka Frameworks).
Seperti yang dijanjikan, sekarang saya akan pindah ke lain topik. Tentu
saja,
Kumpulan sulit untuk menghindari di Mac OS X. penawaran bagian berikutnya
dengan rincian Bundle (a Framework, khusus) yang kita telah dikunjungi
sebelumnya: Quart
3.4.1 V. StandAlone
App-V Standalone biasanya digunakan untuk sebuah organisasi yang relatif
kecil
dan tidak membutuhkan aplikasi yang rumit. Hanya komponen utama App-V
yang perlu disiapkan. Pada model ini manajemen server tidak dibutuhkan
CHAPTER 3. SOFTWARE PENDUKUNG 42
3.4.2 4.V- Streaming
App-V Streaming pada dasarnya mirip dengan App-V Standalone. Namun pada
model ini ada sebuah perbedaan. Yaitu adanya streaming server. Streaming
dalam hal ini adalah pengguna akan mendapatkan aplikasi dari server secara
berurutan paket demi paket. Model ini cocok digunakan untuk jika memiliki
keterbatasan bandwith dan memiliki banyak cabang dibeberapa kota.
3.4.3 V-Full Infrastructure
App-V Full Infrastructure Model digunakan jika perusahaan memiliki
beberapa
cabang, aplikasi yang digunakan beragam serta pengguna yang banyak.
Sehingga
dibutuhkan manajemen server untuk mengelola app-v tersebut. Model
tersebut dibangun berdasarkan komponen-komponen utama. Yaitu :
1. App-V Management Server
2. App-V Management System
3. App-V Streaming Server
4. App-V Client
5. - App-V Sequencer
6. App-V Management Server digunakan untuk mengumpulkan dan menyimpan
informasi. Misal aplikasi apa saja yang ada, lisensi, pengaturan hak
akses dan lain-lain. Tentu saja pada implementasi yang lebih komplek,
management server berkaitan dengan active directory.
7. App-V Management System merupakan management console dan management
service. Berupa web service yang menjadi _perantara_ antara
Microsoft Management Console (MMC) dan SQL Data store.
8. App-V Streaming Server akan menjadi komponen yang diperlukan jika
klien tidak memiliki akses langsung ke management server. Terutama jika
klien berada di kantor cabang.
9. App-V Client adalah komponen yang diinstal pada komputer klien.
Komponen
ini yang mengatur interaksi antara sistem operasi pada klien dengan
App-V Server. Manajemen streaming dan melakukan cache juga dilakukan
oleh komponen ini.
CHAPTER 3. SOFTWARE PENDUKUNG 43
10. App-V Sequencer merupakan komponen yang melakukan konversi aplikasi
agar bisa digunakan oleh app-v server dan app-v client. Bisa dikatakan
merupakan komponen yang membuat App-V application.
3.4.3.1 Mengenal App-V Sequencer
Microsoft Application Virtualization (App-V) Sequencer adalah komponen
yang
digunakan untuk membuat paket aplikasi sehingga bisa digunakan oleh sistem
yang menggunakan App-V Client. Desain dan penggunaan App-V Sequencer
secara benar akan menjadi kunci sukses bagi implementasi application
virtualization
secara global.
Dalam bahasa sederhana, aplikasi bisnis atau aplikasi produktivitas
seperti
MS O_ce dibungkus dalam satu paket. Kemudian paket ini didistribusikan
secara virtual pada komputer yang sudah terinstal App-V Client agent.
Komputer
tersebut tidak perlu melakukan instalasi. Langsung menjalankan aplikasi
yang sudah dipublish oleh server.
Rilis terbaru yang sudah bisa digunakan adalah Microsoft App-V 4.6 SP1
Sequencer. Tentu saja adanya rilis baru selalu menambahkan _tur-_tur baru.
_Fitur-_tur yang dibenamkan pada App-V 4.6 SP1 Sequencer antara lain,
Package Accelerator , Setting Templates dan built-in diagnostics. Semua
ini
didesain agar proses sequencing berjalan lebih cepat dan mudah_, tutur
Bobby
Suandi, Windows Business Group Lead, Microsoft Indonesia.
Pada Microsoft App-V Sequencer ini aplikasi yang akan dikonsumsi oleh
App-V Client disiapkan. Langkah-langkah pembuatan paket dipermudah dengan
adanya wizard.
Hasil dari pembuatan paket di App-V Sequencer akan didistribusikan pada
SCCM Distribution point, App-V Management Server, App-V Streaming Server
atau dalam bentuk MSI yang sudah dipaket ke dalam CD/DVD. Setelah itu
pengguna dapat menjalankan paket tersebut sesuai dengan model yang
digunakan.
Gambar berikut menjelaskan pendistribusian App-V Sequencer pada arsitektur
Microsoft App-V.
CHAPTER 3. SOFTWARE PENDUKUNG 44
Gambar 3. Arsitektur Microsoft App-V Sequencer
3.4.3.2 Langkah-Langkah Mempersiapkan App-V Sequencer
Bagaimana menyiapkan perangkat App-V Sequencer secara maksimal ? Ada
beberapa _best practices_ yang bisa dilaksanakan. Persiapan Perangkat
Keras
dan Perangkat Lunak
_ Minimum menggunakan Intel Pentium 1 Ghz dengan memory 2 GB dan
hard disk 55 GB dengan dua partisi.
_ Sistem operasi yang digunakan adalah Windows XP Profesional SP3, Windows
Vista (Business, Enterprise atau Ultimate) atau Windows 7 (professional,
Enterprise atau Ultimate)
_ Sistem operasi tidak boleh diinstal App-V client atau anti virus. Karena
bisa menyebabkan paket hasil proses menjadi rusak.
_ Sistem operasi sebaiknya disesuaikan dengan aplikasi yang akan dilakukan
pemaketan. Jika aplikasi menggunakan Windows XP, maka App-V Sequencer
diinstal pada Windows XP.
_ Instalasi App-V Sequencer
_ Instalasi yang dilakukan cukup mudah. Cukup mengikuti petunjuk pada
Wizard, App-V akan terinstal. Tentu saja setelah memenuhi persyaratan
yang dibutuhkan oleh App-V Sequencer. Proses Pembuatan Paket Jalankan
App-V Sequencer dan Create a package serta tentukan aplikasi apa saja
yang akan diakses melalui App-V Client. Misal : MS O_ce 2010. Ikuti
langkah demi langkah dari wizard yang muncul.
CHAPTER 3. SOFTWARE PENDUKUNG 45
_
Gambar 4. Layar pembuka App-V Sequencer
Terlampir adalah proses pembuatan paket pada App-V Sequencer yang diambil
berdasarkan panduan App-V dari Microsoft.
Gambar 5. Proses Pembuatan Paket Aplikasi
_ Paket yang sudah jadi akan menghasilkan _le sebagai berikut :
_ File SFT, merupakan aplikasi asli yang dipaket menjadi satu _le.
_ File OSD, merupakan pengontrol aplikasi yang dijalankan. Penghubung
antara client dan _le SFT.
_ File SPRJ, digunakan untuk perubahan aplikasi dimasa depan dan untuk
diimpor ke Management Server.
_ File XML, sebagai manifest atau berisi link _le-_le yang saling terkait. -
File ICO, merupakan _le ikon dari aplikasi.
_ File MSI, digunakan untuk model App-V Standalone. Berisi _le XML,
OSD dan ICO.
_ Proses Menjalankan Paket Aplikasi
Setelah proses pemaketan, langkah selanjutnya adalah menjalankan paket
aplikasi.
Proses tersebut secara garis besar dapat dilihat pada gambar berikut.
CHAPTER 3. SOFTWARE PENDUKUNG 46
Gambar 6. Proses Menjalankan Paket Aplikasi.
Chapter 4
Contoh Pemanfaatan
Software
4.1 Alokasi Metode dan Alat Persyaratan Fung-
sional
Alokasi tingkat Metode mengatur pemilihan dan penerapan metode untuk semua
submodels. Itu melengkapi Model Proses Siklus Hidup. Ini menentukan
bagaimana sesuatu dilakukan, sedangkan yang Lifecycle Model proses
menentukan
apa yang harus dilakukan.
Ada dua macam metode, dasar dan kompleks. Metode dasar mengacu pada
prosedur yang menggambarkan aspek terbatas khusus dari sistem (misalnya
aspek
berorientasi fungsional atau data) atau tertentu bagian dari pengembangan
sistem (untuk analisis contoh atau desain). Metode dasar dikategorikan.
Kategori
A kompromi metode-metode dasar yang menawarkan pendekatan yang
berbeda untuk solusi tugas tertentu masalah. Metode yang kompleks mengacu
pada prosedur yang kompromi berbagai komponen metodis dan mengintegrasikan
mereka ke dalam metode total.
Untuk setiap kegiatan, metode yang dipilih. Ini pemetaan pemilihan atau
kegiatan-metode didokumentasikan dalam Proyek manual. Untuk membuat
pilihan
lebih mudah Alokasi tingkat Metode menggambarkan seperangkat terbatas
metode.
Setiap cara dijelaskan sesuai dengan struktur berikut ini :
47
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 48
_ Identi_kasi dan de_nisi metode.
_ Singkat karakteristik metode.
_ Batas metode.
_ Spesi_kasi alokasi metode - Menentukan bagaimana metode yang akan
digunakan dalam kegiatan.
_ Antarmuka - Antarmuka dengan metode lain yang melengkapi satu sama
lain dijelaskan.
_ Sebagai contoh, menggunakan pemodelan kasus memiliki antarmuka untuk
pemodelan kelas objek, pemodelan keadaan transisi dan interaksi
modeling.
_ Selanjutnya literatur tentang metode.
_ Seperti dengan Alokasi tingkat Metode, Tool tingkat Persyaratan Fungsional
mengatur pemilihan dan penerapan alat untuk semua submodels.
Hal ini juga melengkapi Model Proses Siklus Hidup. Di Selain itu,
mendukung
Alokasi tingkat Metode. Sebuah metode dapat menggunakan alat
satu atau beberapa. Sebuah tool dide_nisikan sebagai "alat adalah
sebuah
produk software yang mendukung pengembangan atau pemeliharaan
/ modi_kasi sistem TI ". Alat-alat yang dikelompokkan ke dalam unit
pelayanan. Sebuah unit pelayanan mende_nisikan persyaratan untuk alat
di unit layanan tertentu. Sebuah unit layanan dapat menjadi salah satu
atau kedua diterapkan dalam suatu kegiatan dalam Model Life Cycle
Proses atau metode dalam Alokasi tingkat Metode. Unit layanan lanjut
dikelompokkan ke dalam kompleks layanan. Sebuah kompleks layanan
dapat misalnya menjadi salah satu submodels. Kompleks layanan membangun
Model Referensi dari Software Development Lingkungan (SDE).
Ini mengatur semua layanan TI yang ditawarkan oleh SDE ke dalam skema
dasar.
_ Pemilihan alat dilakukan dalam empat langkah :
_ Pada langkah pertama Anda menentukan fungsi yang diperlukan dari alat
berdasarkan fungsi diperlukan untuk proyek. Ini hasil langkah dalam
pemilihan beberapa unit layanan yang memenuhi ditentukan diperlukan
fungsi.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 49
_ Pada langkah kedua ada dua kegiatan : _ Pada kegiatan pertama Anda
memiliki unit layanan yang dipilih dan kondisi aplikasi untuk alat sebagai
masukan. Kegiatan ini menganggap alokasi lingkungan khusus dan
mungkin prioritas kebutuhan. Output dari kegiatan ini adalah persyaratan
fungsional alat. _ Pada kegiatan kedua Anda memiliki
kondisi aplikasi untuk
alat sebagai masukan. Kegiatan menetapkan persyaratan teknis dan
organisasi. Output dari kegiatan ini adalah persyaratan teknis.
_ Pada langkah ketiga, persyaratan fungsional dan teknis untuk alat
diringkas.
Itu summarization hasil dalam katalog kriteria operasional. Ini merupakan
persyaratan akhir alat. _ Pada langkah keempat
Anda membandingkan
alat yang berbeda dengan bantuan alat atau deskripsi pro_l dan katalog
kriteria operasional. Hasil perbandingan ke beberapa alat yang berlaku.
4.1.1 Model Proses Siklus Hidup
Model Proses Lifecycle menjelaskan proses dalam dua dasar, kegiatan konsep
dan produk. Itu juga menggambarkan keadaan produk dan saling
ketergantungan
antara kegiatan dan produk dengan skema aliran produk.
Kegiatan yang worksteps dalam proses pembangunan. Pelaksanaan dan
hasil dari suatu kegiatan yang tepatnya dijelaskan. Suatu aktivitas yang
mungkin
terdiri dari subactivities. Kegiatan pada tingkat tertinggi disebut
kegiatan
utamanya. Hasil dari kegiatan suatu produk. Suatu aktivitas yang
menghasilkan,
perubahan negara atau memodi_kasi produk. Untuk setiap kegiatan
ada deskripsi kegiatan yang didasarkan pada pola aktivitas yang disebut
Kegiatan
skema.
Sebuah produk dapat menjadi dokumen, software atau hardware. Sebuah
produk adalah hasil dari suatu kegiatan. Seperti dengan kegiatan, produk
dapat
didekomposisi menjadi subproducts. Sebuah produk digambarkan dengan Produk
skema. Ini berisi sinopsis singkat dari produk dan daftar item struktural
produk.
Kegiatan skema
Pola skema kegiatan terdiri dari:
_ Nama kegiatan - Menjelaskan nama dan jumlah aktivitas. Ini mungkin
utama aktivitas atau subactivity a. Subactivities diberi nomor dengan
notasi titik.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 50
_ Aliran produk - Menjelaskan aliran produk. Ini menggambarkan produk
input dan output dari suatu kegiatan. Dalam input, hal ini dijelaskan dari
mana aktivitas produk berasal dari dan negara itu. Bila produk telah
diproses oleh aktivitas spesi_k itu outputted. Pada output, itu adalah
dijelaskan dimana aktivitas produk diteruskan ke dan negara itu. Lihat
Gambar 4.
Gambar 4
_ Penanganan - Menjelaskan bagaimana kegiatan harus ditangani selama
realisasi. Dalam kegiatan utama, para subactivities, interdependensi dan
hasilnya secara gra_s dijelaskan dalam penanganan Bagian.
_ Rekomendasi dan penjelasan - Memberikan rekomendasi tentang bagaimana
aktivitas dapat ditangani. Penjelasan memperjelas de_nisi aktivitas dan
membuatnya lebih mudah untuk memahami.
Penjelasan untuk Gambar 2 :
_ Orde Proyek berasal dari bagian eksternal dan memiliki keadaan tidak. Ia
tidak pergi lebih jauh ke yang lain negara dan tidak mengubah keadaan.
_ Manual Proyek tidak datang dari aktivitas apapun dan memiliki negara
tidak. Oleh karena itu baru dibuat dalam kegiatan ini. Hal ini disampaikan
kepada kegiatan 01:03 (Generasi Proyek-Spesi_k Model V-) dengan
negara yang sedang diproses. Pedoman Proyek merupakan salah satu
produk masukan kepada PM 1.3 aktivitas.
4.1.2 Produk negara
Sebuah produk mengalami keadaan yang berbeda selama generasi itu dan
pengolahan.
Perubahan negara hanya dapat dipicu oleh suatu kegiatan. Dalam
skema kegiatan itu dijelaskan apa negara produk memiliki ketika memasuki
kegiatan dan ketika ia meninggalkan aktivitas.
Sebuah produk mungkin memiliki negara-negara:
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 51
_ Direncanakan - produk ini sedang direncanakan. Produk belum ada. Ini
adalah keadaan awal dari semua produk.
_ Menjadi diproses - produk ini sedang diproses. Hal ini mengendalikan
pengembang. Hal ini baik check-out dari perpustakaan produk atau checkin
ke perpustakaan produk.
_ Dikirimkan - produk adalah dari titik pengembang pandang selesai. Produk
ini disampaikan ke QA untuk penilaian. Jika penilaian QA menolak
produk itu dikembalikan ke yang Negara diproses jika tidak diterima.
_ Diterima - Produk telah diterima oleh penilaian QA dan karena itu
dibebaskan.
Hal ini dapat hanya dapat dimodi_kasi lebih lanjut jika nomor versi
diperbarui.
Negara-negara dan transisi dimodelkan pada Gambar 5.
Gambar. 5
4.1.3 Organisasi dan Peran
Alokasi tugas kepada anggota proyek individu dilakukan dengan peran. Satu
set peran yang terdaftar untuk masing-masing submodel. Peran masing-masing
telah dide_nisikan yang aktivitas itu mengalokasikan, tanggung jawab itu
telah,
keterampilan yang diperlukan, pengetahuan yang dibutuhkan dan dependensi
dengan peran lainnya.
Organisasi ini dibangun dengan memilih anggota proyek untuk submodel
masing-masing dan memberikan mereka peran. Sebuah peran dapat diberikan
kepada anggota proyek satu atau beberapa. Salah satu anggota proyek juga
dapat memiliki beberapa peran. Ini alokasi peran membuat The V-Model yang
berimbang tentang organisasi proyek.
4.1.4 Sub-sub models
Seperti disebutkan sebelumnya, ada empat submodels dalam Model V-. Dalam
bagian ini ada dijelaskan dalam lebih detail dari Model Proses Siklus
Hidup titik
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 52
pandang. Semua submodels terdiri dari beberapa kegiatan dan menghasilkan
beberapa produk. Mereka juga bekerja sama untuk mencapai tujuan proyek.
Hal ini ditunjukkan pada Gambar 6.
Gambar.7
4.1.5 Proyek Manajemen
The submodel PM mengatur kegiatan memulai, perencanaan dan pengawasan
proyek. Itu kompromi dari 14 kegiatan utama:
_ Proyek Inisialisasi - Mende_nisikan kerangka organisasi di manual proyek.
Sebuah menjahit V-Model menjadi model V-proyek tertentu dilakukan
sesuai dengan kriteria proyek dan kondisi. Perencanaan awal dilakukan
berdasarkan manual proyek dan didokumentasikan dalam rencana proyek.
_ Penempatan / Pengadaan - Termasuk mengirimkan permintaan proposal
untuk subkontraktor mungkin, mengevaluasi tanggapan dan menentukan
tawaran paling ekonomis.
_ Manajemen Kontraktor - Tujuan dari kegiatan ini adalah untuk mengawasi
bahwa syarat-syarat kontrak yang terpenuhi. Hal ini berlaku pada
kontrak dengan pelanggan dan subkontraktor.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 53
_ Perencanaan Detil - Tujuan dari kegiatan ini adalah untuk mewujudkan
rencana rinci untuk proyek tersebut. Ini adalah dilakukan dengan bantuan
dari perencanaan awal yang ada dan spesi_kasi di manual proyek.
_ Biaya / Manfaat Analisis - Tujuan dari kegiatan ini adalah untuk
menentukan
bagaimana menguntungkan yang direncanakan solusi. Setiap usulan
solusi dievaluasi sesuai dengan biaya dan manfaat itu.
_ Ulasan Tahap - Setelah setiap tahapan proyek, review fase dilakukan.
Tinjauan
tersebut dilakukan untuk memeriksa Status proyek yang sebenarnya
sesuai dengan yang direncanakan.
_ Manajemen Risiko - Tujuan dari kegiatan ini adalah untuk mendeteksi
risiko proyek sedini mungkin. Risiko dikelola dengan memulai
langkahlangkah
pencegahan dan mengawasi e_siensi dimulai langkah-langkah.
_ Proyek Pengendalian - Tujuan dari kegiatan ini adalah untuk mengontrol
kemajuan proyek. Jika menyimpang dari nilai yang direncanakan, tindakan
harus diambil untuk memperbaiki masalah.
_ Layanan Informasi / Pelaporan - Tujuan dari kegiatan ini adalah untuk
membuat informasi tentang proyek tersedia untuk subkontraktor pelanggan,
dan anggota proyek.
_ Pelatihan / Instruksi - Tujuan dari kegiatan ini adalah untuk melatih
para anggota proyek, sehingga mereka dapat memperoleh pengetahuan
yang dibutuhkan untuk memenuhi peran mereka / s.
_ Sumber Daya Menyediakan - Tujuan dari kegiatan ini adalah untuk memasok
sumber daya yang dibutuhkan untuk mewujudkan Tujuan proyek.
_ Alokasi Perintah Kerja - Tujuan dari kegiatan ini adalah untuk memulai
bagian pekerjaan yang dialokasikan oleh bekerja pesanan.
_ Pelatihan Staf - Tujuan dari kegiatan ini adalah untuk memperkenalkan
para anggota proyek ke bagian pekerjaan mereka. Proyek Anggota Tugas
dijelaskan dan mereka diberitahu tentang tugas.
_ Penyelesaian Proyek - Tujuan dari kegiatan ini adalah untuk menyelesaikan
proyek. Ini melibatkan menulis tugas akhir laporan dengan semua
pengalaman proyek.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 54
4.1.6 Pengembangan Sistem
Submodel SD mengatur kegiatan pengembangan sistem. Ini kompromi kesembilan
utama kegiatan:
_ Sistem Analisis Persyaratan - Kegiatan ini melibatkan pengaturan
persyaratan
sistem dari pengguna sudut pandang. Sistem ini ditentukan dari
sudut pandang eksternal.
_ Desain Sistem - Kegiatan ini melibatkan pengaturan arsitektur sistem dan
rencana integrasi untuk arsitektur.
_ SW / HW Analisis Persyaratan - Kegiatan ini melibatkan memperbarui
persyaratan teknis dan operasional informasi yang berkaitan dengan
perangkat
lunak dan persyaratan perangkat keras. Hal ini dilakukan dengan membantu
dari kebutuhan pengguna, arsitektur sistem dan persyaratan teknis
yang sebelumnya berasal.
_ Awal SW Desain - Kegiatan ini melibatkan merancang arsitektur perangkat
lunak. Ini termasuk menyelesaikan deskripsi antarmuka dan memperbarui
rencana integrasi perangkat lunak.
_ Detil SW Desain - Arsitektur perangkat lunak dan deskripsi antarmuka
yang lebih rinci. Itu spesi_kasi dan rincian untuk masing-masing komponen
perangkat lunak modul, dan database yang dibuat.
_ SW Implementasi - modul Perangkat lunak, komponen dan database
direalisasikan.
Kode ini dihasilkan dan dikompilasi ke dalam bentuk yang
dapat dijalankan.
_ SW Integrasi - Integrasi modul, komponen dan database direalisasikan.
Ini adalah mungkin dilakukan dalam beberapa langkah.
_ Integrasi Sistem - Integrasi sistem tersebut direalisasikan. Kedua
perangkat
lunak dan perangkat keras komponen yang terintegrasi sesuai dengan
arsitektur
sistem.
_ Transisi ke Pemanfaatan - Kegiatan ini kompromi tugas yang diperlukan
untuk menempatkan sistem dalam operasi di lingkungan dimaksudkan.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 55
4.1.7 Jaminan Kualitas
Submodel QA mengatur kegiatan dan produk dari submodels lain dengan
menilai
itu sebelum diterima. Ini kompromi kegiatan utama lima:
_ Inisialisasi QA - Kegiatan ini melibatkan menentukan ruang lingkup
organisasi
dan prosedural Kegiatan QA. Semua spesi_kasi untuk produk dan
proses yang didokumentasikan dalam rencana QA.
_ Persiapan Penilaian - Kegiatan ini melibatkan menghasilkan rencana
penilaian.
Ini berisi de_nisi metode penilaian, kriteria, lingkungan dan uji
kasus.
_ Proses Penilaian Kegiatan - Kegiatan ini melibatkan melakukan penilaian
terhadap proses untuk menentukan apakah mereka cukup.
_ Penilaian Produk - Kegiatan ini melibatkan produk menilai. Sebuah produk
yang baik diterima dan memasuki keadaan diterima atau ditolak dan
kembali ke keadaan diproses menjadi.
_ QA Pelaporan - Kegiatan ini melibatkan mengevaluasi laporan penilaian.
Hal ini dilakukan di QA pelaporan dan didasarkan pada sejumlah masalah,
tingkat keparahan masalah, klasi_kasi masalah dan penyebab masalah.
4.1.8 Kon_gurasi Manajemen
Submodel CM menjamin bahwa produk dapat diidenti_kasi secara unik setiap
saat. Identi_kasi berfungsi untuk mengontrol modi_kasi dan untuk menjamin
integritas. Ini kompromi kegiatan utama empat :
_ Perencanaan CM - Kegiatan ini melibatkan mende_nisikan kerangka organisasi
dan untuk mendokumentasikan dalam rencana CM. Sumber daya
yang dibutuhkan dan alat juga didokumentasikan dalam rencana CM.
_ Produk dan Manajemen Kon_gurasi - Kegiatan ini melibatkan mengelola
perpustakaan produk dengan katalogisasi produk. Sebuah kon_gurasi
seluruh sistem juga berhasil.
_ Manajemen Perubahan - Kegiatan ini melibatkan mengelola perubahan
melalui tiga langkah. Pertama perubahan yang diminta dan didaftarkan
oleh CM. Pada langkah berikutnya perubahan dievaluasi dan baik diterima
atau ditolak. Pada langkah ketiga, jika diterima, perubahan tersebut
dilaksanakan dan semua dipengaruhi oleh perubahan diinformasikan.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 56
Layanan CM
_ Layanan CM adalah mereka yang melayani kegiatan proyek dalam beberapa
cara. Ini mencakup katalogisasi produk perangkat lunak, mengkoordinasikan
antarmuka, backup, manajemen rilis dan merekam sejarah
proyek.
Pengembangan Sistem Software
Pengembangan Sistem Software (Software Development) adalah pengembangan
suatu produk software melalui suatu perencanaan dan proses yang
terstruktur.
Pengembangan software ini dapat ditujukan untuk berbagai kepentingan
dimana pada umumnya dapat dibagi menjadi 3 , yaitu :
1. Kebutuhan khusus bagi bisnis tertentu
2. Kebutuhan yang diharapkan oleh pengguna potensial
3. Keputuhan untuk kepentingan peribadi.
Berikut ini gambaran Process Software
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 57
Gambar. 8
Sedangkan Pengembangan sistem informasi merupakan proses pengembangan
sistem untuk menghasilkan sistem informasi (CBIS atau computer based
information
system) dimana metodologi pengembangan sistem digunakan sebagai
sarana untuk meningkatkan pengelolaan dan pengendalian komponen sistem
informasi
(sumber daya manusia, hardware, software, jaringan, sumberdaya data
dan produk informasi). Berikut ini penjelasan lebih detail karakteristik
antara
Pengembangan Software dan Pengembangan sistem Informasi.
4.1.9 Pengembangan Software
Ada dual hal yang perlu di pertimbangkan dalam pengembangan software yaitu
:
1. Produk dan software. Produk, terdiri dari program, dokumen, dan data
2. Proses pengembangannya. proses terdiri dari proses manajemen dan proses
teknikal.
Produk dari perangkat lunak dipantau melewati beberapa tahap pengembangan
yang dikenal juga sebagai system development life cycle (SDLC). Contoh
dari
SDLC antara lain model waterfall, model V, model spiral, prototyping dan
lain-lain. Sedangkan proses manajemen dalam pengembangan software lunak
terdiri atas manajemen proyek, con_guration management, quality assurance
management. Sementara, proses teknikal merupakan metode yang diaplikasikan
pada tahap tertentu dalam pengembangan software, yang didalamnya termasuk
metode analisis, metode desain, metode pemrograman, dan metode testing.
Proses pengembangan software, memiliki 3 elemen kunci yang terdiri dari:
4.1.10 Metode
Metode software engineering memberikan tehnik-tehnik bagaimana membentuk
software. Metode ini terdiri dari serangkaian tugas seperti :
_ Perencanaan & estimasi proyek Software merupakan bagian terbesar dari
sistem, sehingga pekerjaan dimulai dengan cara menerapkan kebutuhan
semua elemen sistem dan mengalokasikan sebagian kebutuhan tersebut
ke software. Pandangan terhadap sistem adalah penting, terutama pada
saat software harus berhubungan dengan elemen lain, seperti hardware,
software lain dan database
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 58
_ Analisis kebutuhan sistem dan software Merupakan suatu proses pengumpulan
kebutuhan software untuk mengerti sifat -sifat program yang dibentuk
software engineering, atau analis harus mengerti fungsi software yang
diinginkan,
performance dan interfase terhadap elemen lainnya. Hasil dari
analisis ini didokumentasikan dan ditinjau bersama-sama klien.
_ Desain struktur data Desain software sesungguhnya adalah proses multi
step (proses yang terdiri dari banyak langkah) yang memfokuskan pada
3 atribut program yang berbeda, yaitu struktur data, arsitektur software
dan rincian prosedur. Proses desain menterjemahkan kebutuhan kedalam
representasi software yang dapat diukur kualitasnya sebelum coding
dimulai.
Hasil dari desain ini didokumentasikan dan menjadi bagian dari
kon_gurasi software.
_ Arsitektur program dan prosedur algoritma
_ Coding Merupakan proses penterjemahan desain ke dalam bentuk yang
dapat dibaca oleh mesin
_ Testing dan pemeliharaan Setelah objek program dihasilkan, testing program
dimulai. Proses testing difokuskan pada logika internal software.
Jaminan bahwa semua pernyataan atau statements sudah dites dan lingkungan
external menjamin bahwa de_nisi input akan menghasilkan output
yang diinginkan. Sementara proses pemeliharaaan atau maintenance dilakukan
karena software mengalami error, atau harus diadaptasi untuk
menyesuaikan dengan lingkungan external.
4.1.11 Peralatan atau tools
Peralatan pengembangan software memberikan dukungan atau semiautomasi
untuk metode, contohnya:
1. CASE (Case Aided Software Engineering), yaitu suatu software yang
menggabungkan software, hardware, dan database software engineering
untuk menghasilkan suatu lingkungan software engineering.
2. Database Software Engineering, adalah sebuah struktur data yang berisi
informasi penting tentang analisis, desain, kode dan testing.
3. Analogi dengan CASE pada hardware adalah : CAD, CAM, CAE.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 59
4.1.12 Prosedur
Prosedur terdiri dari, urut-urutan di mana metode tersebut diterapkan,
dokumen,
laporan-laporan, formulir-formulir yang diperlukan, kontrol kualitas
software,
dan koordinasi perubahan yang terjadi pada software.
Dalam model atau paradigma pengembangan software, terdapat 3 metode
yang secara luas dipergunakan, yaitu:
4.1.12.1 1. System Development Life Cycle (SDLC)
System Development Life Cycle (SDLC) adalah proses pengembangan dimana
keseluruhan proses pengembangan sistem dilakukan melalui proses
multi-langkah
dari investigasi persyaratan awal melalui analisis, desain, implementasi
dan
pemeliharaan (sumber: Russel Kay, Computer World). SDLC terdiri dari
beberapa
jenis model antara lain model Waterfall, Fountain, dan Spiral. Pada
modelwaterfall output dari langkah yang satu akan menjadi input bagi
langkah
selanjutnya, seperti gambar dibawah ini:
A. Spiral Model Model spiral (spiral model) adalah model pengembangan
software dimana proses digambarkan sebagai spiral. Setiap loop akan
mewakili
satu fase dari software process. Loop paling dalam berfokus pada kelayakan
dari sistem, loop selanjutnya tentang de_nisi dari kebutuhan, loop
berikutnya
berkaitan dengan desain sistem dan seterusnya, seperti gambar berikut :
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 60
Pada spiral model, setiap Loop dibagi dibagi menjadi sejumlah akti_tas
kerangka kerja yang disebut juga wilayah tugas, wilayah tugas tersebut
terdiri
antara tiga sampai enam wilayah tugas, yaitu :
_ Komunikasi Pelanggan.Tugas _ tugas yang dibutuhkan untuk membangun
komunikasi yang efektif di antara pengembangan dan pelanggan.
_ Perencanaan.Tugas_tugas yang dibutuhkan untuk mende_nisikan sumber
_sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
_ Analisis Risiko.Tugas _ tugas yang dibutuhkan untuk menaksir risiko _
risiko, baik manajemen maupun teknis.
_ Perekayasaan.Tugas _ tugas yang dibutuhkan untuk membangun satu atau
lebih representasi dari aplikasi tersebut.
_ Konstruksi dan peluncuran.Tugas _ trugas yang dibutuhkan untuk
mengkonstruksi,
menguji, instalasi dan memberikan pelayanan kepada pemakai
(contohnya pelatihan dan dokumentasi).
_ Evaluasi pelanggan.Tugas _ tugas yang dibutuhkan untuk memperoleh
umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 61
software, yang dibuat selama masa perekayasaan, dan diimplementasikan
selama masa pemasangan software.
B. Waterfall model
Berikut merupakan penjelasan setiap fase atau tahapan yang terjadi pada
waterfall
model :
_ Tahap Investigasi Pada tahap investigasi akan terjadi proses seperti:
1. Initialisas : terjadi proses seperti perencanaan manajemen, kebutuhan
serta potensi dari user.
2. De_nisi formal: dilakukan de_nisi tujuan, motivasi, ruang lingkup,
batasan,
kendala, dan strategi. Selain itu, pada de_nisi formal juga dilakukan veri
_kasi permasalahan sehingga dapat dilakukan penilaian terhadap kebutuhan
yang baru.
3. Uji kelayakan, yang terdiri dari: Uji kelayakan teknis, Uji kelayakan
ekonomis,
Uji kelayakan operasional, Uji kelayakan kelayakan organisasi,
_ Tahap Analisa Dalam tahapan ini sistem yang akan dibangun diselaraskan
dengan kebutuhan user atau pengguna. Pada tahap ini terjadi proses
seperti :
1. Determine requirements atau penentuan kebutuhan, hal ini dilakukan
dengan
cara mempelajari sistem yang telah ada, serta menentukan kebutuhan
struktur dan menghilangkan redundansi.
2. Requirement analysis atau analisa kebutuhan, terdiri dari analisa
kebutuhan
fungsional dan performa (kinerja).
3. Menghasilkan desain sistem alternatif
4. Membandingkan alternatif desain sistem yang dihasilkan dan
5. Merekomendasikan alternatif terbaik kepada klien.
_ Tahap Desain Tahap menentukan bagaimana sistem mencapai tujuan yang
telah dide_nisikan sebelumnya. Tahap ini terdiri dari :
1. User interface design, meliputi tampilan, form, report dan dialog
design.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 62
2. Data design, merupakan proses desain elemen struktur data.
3. Process design, merupakan desain program prosedur sistem
_ Tahap Implementasi Pada tahap ini terjadi beberapa hal seperti :
1. Evaluasi hardware, software dan jasa
2. Modi_kasi dan pengembangan software
3. Dokumentasi, yang merupakan mekanisme komunikasi utama selama proses
pengembangan.
4. Konversi data, pada proses ini terjadi perbaikan dan penyaringan data
yang tidak diinginkan dan konsolidasi data.
5. Testing atau uji coba, pada proses ini dilakukan uji coba dan debugging
software.
6. Training atau pelatihan sistem/software yang telah terbentuk.
7. Konversi, yakni proses pergantian dari sistem lama ke sistem baru.
_ Proses konversi dapat dilakukan melalui 4 macam cara antara lain:
1. Parallel strategy
2. Pilot strategy
3. Phased strategy dan
4. Plunge strategy
_ Tahap Pemeliharaan (maintenance) Pada proses ini terjadi modi_kasi
software,
perbaikan error atau umpan balik dari user terhadapsoftware yang
telah mereka gunakan
Keunggulan dan Kelemahan pada metode SDLC antara lain :
_ Keunggulan :
1. Proses pengembangan sangat terstruktur dan sistematik
2. Melalui de_nisi kebutuhan, sehingga gap atau kesenjangan yang terjadi
antara kebutuhan dan sistem yang dihasilkan dapat dikurangi.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 63
3. Menghasilkan petunjuk arah pengembangan yang jelas bagi manajemen.
_ b. Kelemahan :
1. Tidak adaptif terhadap perubahan yang dapat terjadi selama proses
pengembangan
(kaku atau rigid).
2. Melelahkan karena membutuhkan waktu pengembangan yang lama dan
biaya yang tinggi
3. Proyek yang sebenarnya jarang mengikuti aliran sequential yang
ditawarkan
model ini. Iterasi (Pengulangan) selalu terjadi dan menimbulkan masalah
pada aplikasi yang dibentuk oleh model ini.
4. Seringkali pada awalnya customer sulit menentukan semua kebutuhan
secara
explisit.
5. Klien harus sabar karena versi program yang sedang jalan tidak akan
tersedia sampai proyek pengembangan selesai.
4.1.12.2 Rapid Application Development (RAD)
Rapid Aplication Development (RAD) adalah sebuah metode pengembangan
software yang diciptakan untuk menekan waktu yang dibutuhkan untuk
mendesain
serta mengimplementasikan sistem, informasi sehingga dihasilkan siklus
pengembangan yang sangat pendek.
Model RAD ini merupakan adaptasi dari model sekuensial linier dimana
perkembangan yang cepat dicapai dengan menggunakan pendekatan kontruksi
berbasis komponen. Sehingga, jika kebutuhan sistem dipahami dengan baik,
proses RAD memungkinkan developer menciptakan sistem fungsional yang utuh
dalam periode waktu yang sangat pendek (± 60 sampai 90 hari). Karena
dipakai
terutama pada aplikasi sistem konstruksi, pendekatan RAD meliputi fase _
fase.
Berikut merupakan penjelasan setiap fase yang dilalui metode Rapid
Aplication
Development(RAD):
a. Bussiness modeling Aliran informasi di antara fungsi _ fungsi bis-
nis dimodelkan dengan suatu cara untuk menjawab pertanyaan _ per-
tanyaan seperti :
1. Informasi apa yang mengendalikan proses bisnis?
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 64
2. Informasi apa yang di munculkan?
3. Siapa yang memunculkanya?
4. Ke mana informasi itu pergi?
5. Siapa yang memprosesnya?
b. Data modeling
Aliran informasi yang dide_nisikan sebagai bagian dari fase bussiness
modelling
disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang
bisnis
tersebut. Karakteristik (disebut atribut) masing masing objek
diidenti_kasi
dan hubungan antara objek _ objek tersebut dide_nisikan.
c. Prosess modelling
Aliran informasi yang dide_nisikan di dalam fase data modeling ditransformasikan
untuk mencapai aliran informasi yang perlu bagi implementasi sebuah
fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodi-
_kasi, menghapus, atau mendapatkan kembali sebuah objek data.
d. Aplication generation
RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan
perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga
yang konvensional, RAD lebih banyak memproses kerja untuk memkai lagi
komponen
program yang ada (pada saat memungkinkan) atau menciptakan komponen
yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat _ alat bantu
otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.
e. Testing and turnover
Karena proses RAD menekankan pada pemakaian kembali, banyak komponen
program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian.
Tetapi
komponen baru harus di uji dan semua interface harus dilatih secara penuh.
Keunggulan dan kelemahan model RAD adalah :
_ Keunggulan :
1. Waktu pengembangan yang lebih singkat dan
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 65
2. Biaya yang relatif lebih murah
_ Kelemahan :
1. Tidak cocok untuk proyek skala besar
2. Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
3. Sistem yang tidak bisa dimodularisasi tidak cocok untuk model
4. Resiko teknis yang tinggi juga kurang cocok untuk model ini
Prototyping
Proses pada model prototyping yang digambarkan pada gambar diatas dapat
dijelaskan sebagai berikut :
a. User Requirements Pada tahap ini developer dan klien
bertemu dan
menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagianbagian
yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak
dibicarakan pada tahap ini,
b. Develop Prototype Pada tahap ini dilakukan
perancangan prototype
sistem oleh developer, perancangan sistem dilakukan secara cepat dan
rancangan
diusahakan mewakili semua aspek software yang telah diketahui.
c. Revise Prototype Pada tahap ini dilakukan evaluasi prototype sistem
oleh klien. Apabila klien merasa prototype sistem yang telah dikembangkan
sesuai dengan keinginannya maka prototype tersebut dapat digunakan, akan
tetapi jika prototype tersebut tidak sesuai, maka prototype tersebut akan
dilakukan
revisi dan digunakan sebagai acuan dalam memperjelas kebutuhan software
dan kemudian dikembangkan prototype selanjutnya. Siklus ini (developrevise
prototype) akan terus berlangsung hingga didapatkanprototype sistem
yang sesuai dengan kebutuhan klien atau user.
Gambaran Model Prototyping.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 66
Berikut merupakan keunggulan dan kelemahan pada pengembangan software
menggunakan metode prototyping.
_ Keunggulan :
1. Meningkatnya komunikasi antara user dan developer
2. Peningkatan peran aktif user didalam proses pengembangan
3. Peningkatan e_siensi waktu
4. Implementasi sistem menjadi lebih mudah karena user turut berperan
aktif
didalam proses pengembangan
_ Kelemahan :
1. Kurangnya _tur keamanan dan kontrol pada prototype akhir sistem
2. Sistem akan sulit terbentuk jika proses evaluasi pada siklus prototype
tidak
mendapatkan titik temu.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 67
3. Dapat menyebabkan dokumentasi akhir yang tidak lengkap
4. Developer lebih sulit mengendalikan ekspektasi user
Pengembangan Sistem Informasi
Pengembangan sistem informasi sering disebut sebagai proses pengembangan
sistem (System Development). Pengembangan sistem dide_nisikan sebagai
aktivitas
untuk menghasilkan sistem informasi berbasis komputer untuk menyelesaikan
persoalan (problem) organisasi atau memanfaatkan kesempatan
(opportunities)
yang timbul. Metodologi pengembangan Sistem dipromosikan sebagai
sarana untuk meningkatkan pengelolaan dan pengendalian proses pengembangan
perangkat lunak, penataan dan menyederhanakan proses, dan standarisasi
proses pengembangan dan produk dengan menentukan kegiatan yang harus
dilakukan
dan teknik yang digunakan.
Prinsip-prinsip yang digunakan dalam pengembangan sistem Informasi adalah:
1. Sistem yang dikembangkan adalah untuk manajemen
2. Sistem yang dikembangkan adalah investasi modal yang besar.
3. Sistem yang dikembangkan memerlukan orang-orang yang terdidik.
4. Tahapan kerja dan tugas-tugas yang harus dilakukan dalam proses
pengembangan
sistem.
5. Proses pengembangan sistem tidak harus urut.Jangan takut membatalkan
proyek.
Pengembangan sistem informasi memerlukan keterilbatan komponen _ komponen
dari sistem informasi, yaitu :
1. Sumber daya manusia
2. Perangkat keras (Hardware)
3. Perangkat lunak (Software)
4. Jaringan komunikasi (Communication network)
5. Prosedur dan kebijakan (Policy and Procedures)
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 68
Baik berdasarkan segitiga Pembangunan Sistem Informasi, maupun komponen _
komponen sistem informasi, maka pengembangan perangkat lunak, merupakan
bagian dari pengembangan sistem informasi. Oleh karena itu pengemgangan
sistem perangkat lunak harus dalam koridor pengembangan sistem informasi,
yang mana haru merujuk pada Perencanaan Sistem Informasi.
Reakayasa Perangkat Lunak (RPL)
Istilah Reakayasa Perangkat Lunak (RPL) secara umum disepakati sebagai
terjemahan
dari istilah Software engineering. Istilah Software Engineering mulai
dipopulerkan pada tahun 1968 pada software engineering Conference yang
diselenggarakan
oleh NATO. Sebagian orang mengartikan RPL hanya sebatas pada
bagaimana membuat program komputer. Padahal ada perbedaan yang mendasar
antara perangkat lunak (software) dan program komputer. Perangkat
lunak adalah seluruh perintah yang digunakan untuk memproses informasi.
Perangkat lunak dapat berupa program atau prosedur. Program adalah
kumpulan
perintah yang dimengerti oleh komputer sedangkan prosedur adalah perintah
yang dibutuhkan oleh pengguna dalam memproses informasi (O'Brien, 1999).
Pengertian RPL sendiri adalah suatu disiplin ilmu yang membahas semua
aspek
produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan
pengguna,
menentukan spesi_kasi dari kebutuhan pengguna, disain, pengkodean,
pengujian sampai pemeliharaan sistem setelah digunakan. Dari pengertian
ini
jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program
komputer. Pernyataan _semua aspek produksi_ pada pengertian di atas,
mempunyai arti semnua hal yang berhubungan dengan proses produksi seperti
manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal,
kualitas
sampai dengan pelatihan pengguna merupakan bagian dari RPL
1. Tujuan Rekayasa Perangkat Lunak
Secara umunmm tujuan RPL tidak berbeda dengan bidang rekayasa yang lain.
Hal ini dapat kita lihat pada Gambar di bawah ini.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 69
Dari Gambar di atas dapat diartikan bahwa bidang rekayasa akan selalu
berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan
waktu
penyelesaian yang tepat. Secara leboih khusus kita dapat menyatakan tujuan
RPL adalah :
_ memperoleh biaya produksi perangkat lunak yang rendah
_ menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat
waktu
_ menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis
platform
_ menghasilkan perangkat lunak yang biaya perawatannya rendah.
2. Ruang Lingkup
Sesuai dengan de_nisi yang telah disampaikan sebelumnya, maka ruang
lingkup
RPL dapat digambarkan sebagai berikut :
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 70
_ software Requirements berhubungan dengan spesi_kasi kebutuhan dan
persyaratan perangkat lunak
_ software desain mencakup proses penampilan arsitektur, komponen, antar
muka, dan karakteristik lain dari perangkat lunak
_ software construction berhubungan dengan detail pengembangan perangkat
lunak, termasuk algoritma, pengkodean, pengujian dan pencarian kesalahan
_ software testing meliputi pengujian pada keseluruhan perilaku perangkat
lunak
_ software maintenance mencakup upaya-upaya perawatan ketika perangkat
lunak telah dioperasikan
_ software con_guration management berhubungan dengan usaha perubahan
kon_gurasi perangkat lunak untuk memenuhi kebutuhan tertentu
_ software engineering management berkaitan dengan pengelolaan dan
pengukuran
RPL, termasuk perencanaan proyek perangkat lunak
_ software engineering tools and methods mencakup kajian teoritis tentang
alat bantu dan metode RPL
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 71
_ software engineering process berhubungan dengan de_nisi, implementasi
pengukuran, pengelolaan, perubahan dan perbaikan proses RPL
_ software quality menitik beratkan pada kualitas dan daur hidup perangkat
lunak
3. Metode Rekayasa Perangkat Lunak
Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk
membantu proses pengembangan perangkat lunak. Model-model ini pada
umumnya mengacu pada model proses pengembangan sistem yang disebut System
Development Life Cycle (SDLC) seperti terlihat pada Gambar berikut ini
:
_ Kebutuhan terhadap de_nisi masalah yang jelas. Input utama dari setiap
model pengembangan perangkat lunak adalah pende_nisian masalah yang
jelas. Semakin jelas akan semakin baik karena akan memudahkan dalam
penyelesaian masalah. Oleh karena itu pemahaman masalah seperti dijelaskan
pada Bab 1, merupakan bagian penting dari model pengembangan
perangkat lunak.
_ Tahapan-tahapan pengembangan yang teratur. Meskipun model-model
pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya
model-model tersebut mengikuti pola umum analysis _ design _
coding _ testing - maintenance
_ Stakeholder berperan sangat penting dalam keseluruhan tahapan
pengembangan.
Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna,
pemilik, pengembang, pemrogram dan orang-orang yang terlibat
dalam rekayasa perangkat lunak tersebut.
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 72
_ Dokumentasi merupakan bagian penting dari pengembangan perangkat
lunak. Masing-masing tahapan dalam model biasanya menghasilkan sejumlah
tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi
dan merupakan bagian tak terpisahkan dari perangkat lunak
yang dihasilkan.
_ Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis.
Nilai dari sebuah perangkat lunak sebenarnya agak susah di-rupiah-kan.
Namun efek dari penggunaan perangkat lunak yang telah dikembangkan
haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa
penurunan biaya operasi, e_siensi penggunaan sumberdaya, peningkatan
keuntungan organisasi, peningkatan _image_ organisasi dan lain-lain.
4. Tahapan Rekayasa Perangkat Lunak
Meskipun dalam pendekatan berbeda-beda, namun model-model pendekatan
memiliki kesamaan, yaitu menggunaka pola tahapan analysis _ design _
coding(
construction) _ testing _ maintenance.
1. Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan
sebuah sistem menjadi komponen-komponennya dengan tujuan mempelajari
seberapa bagus komponen-komponen tersebut bekerja dan berinteraksi
untuk meraih tujuan mereka. Analisis mungkin adalah bagian
terpenting dari proses rekayasa perangkat lunak. Karena semua proses
lanjutan akan sangat bergantung pada baik tidaknya hasil analisis. Ada
satu bagian penting yang biasanya dilakukan dalam tahapan analisis yaitu
pemodelan proses bisnis.
2. Model proses adalah model yang memfokuskan pada seluruh proses di
dalam sistem yang mentransformasikan data menjadi informasi (Harris,
2003). Model proses juga menunjukkan aliran data yang masuk dan keluar
pada suatu proses. Biasanya model ini digambarkan dalam bentuk Diagram
Arus Data (Data Flow Diagram / DFD). DFD meyajikan gambaran
apa yang manusia, proses dan prosedur lakukan untuk mentransformasi
data menjadi informasi.
3. Disain perangkat lunak adalah tugas, tahapan atau aktivitas yang
difokuskan
pada spesi_kasi detil dari solusi berbasis computer (Whitten et
al, 2004). Disain perangkat lunak sering juga disebut sebagai physical deCHAPTER
4. CONTOH PEMANFAATAN SOFTWARE 73
sign. Jika tahapan analisis sistem menekankan pada masalah bisnis
(business
rule), maka sebaliknya disain perangkat lunak fokus pada sisi teknis
dan implementasi sebuah perangkat lunak (Whitten et al, 2004). Output
utama dari tahapan disain perangkat lunak adalah spesi_kasi disain.
Spesi_kasi ini meliputi spesi_kasi disain umum yang akan disampaikan
kepada stakeholder sistem dan spesi_kasi disain rinci yang akan digunakan
pada tahap implementasi. Spesi_kasi disain umum hanya berisi gambaran
umum agar stakeholder sistem mengerti akan seperti apa perangkat lunak
yang akan dibangun. Biasanya diagram USD tentang perangkat lunak
yang baru merupakan point penting dibagian ini. Spesi_kasi disain rinci
atau kadang disebut disain arsitektur rinci perangkat lunak diperlukan
untuk merancang sistem sehingga memiliki konstruksi yang baik, proses
pengolahan data yang tepat dan akurat, bernilai, memiliki aspek user
friendly dan memiliki dasar-dasar untuk pengembangan selanjutnya. Desain
arsitektur ini terdiri dari desain database, desain proses, desain user
interface yang mencakup desain input, output form dan report, desain
hardware, software dan jaringan. Desain proses merupakan kelanjutan
dari pemodelan proses yang dilakukan pada tahapan analisis.
4. Konstruksi adalah tahapan menerjemahkan hasil disain logis dan _sik ke
dalam kode-kode program komputer.
5. Pengujian sistem melibatkan semua kelompok pengguna yang telah
direncanakan
pada tahap sebelumnya. Pengujian tingkat penerimaan terhadap
perangkat lunak akan berakhir ketika dirasa semua kelompok pengguna
menyatakan bisa menerima perangkat lunak tersebut berdasarkan
kriteriakriteria
yang telah ditetapkan.
6. Perawatan dan Kon_gurasi. Ketika sebuah perangkat lunak telah dianggap
layak untuk dijalankan, maka tahapan baru menjadi muncul yaitu
perawatan perangkat lunak. Ada beberapa tipe perawatan yang biasa
dikenal dalam dunia perangkat lunak seperti terlihat pada diagram di
Gambar di bawah ini :
CHAPTER 4. CONTOH PEMANFAATAN SOFTWARE 74
_ Tipe perawatan corrective dilakukan jika terjadi kesalahan atau biasa
dikenal
sebagai bugs. Perawatan bisa dilakukan dengan memperbaiki kode
program, menambah bagian yang dirasa perlu atau malah menghilangkan
bagian-bagian tertentu.
_ Tipe perawatan routine biasa juga disebut preventive maintenance dilakukan
secara rutin untuk melihat kinerja perangkat lunak ada atau tidak
ada kesalahan.
_ Tipe perawatan sistem upgrade dilakukan jika ada perubahan dari
komponenkomponen
yang terlibat dalam perangkat lunak tersebut. Sebagai contoh
perubahan platform sistem operasi dari versi lama ke versi baru
menyebabkan
perangkat lunak harus diupgrade
Chapter 5
Penutup
The sipil V-model Karena pemerintah federal juga berbeda melihat diri
mereka
dihadapkan dengan masalah benar-benar sama disimpan, V-model pada akhir
tahun 1991 dialihkan kepada Pemerintah Federal untuk teknologi informasi
pada koordinasi dan dewan penasihat dalam pemerintahan federal (KBSt)
untuk
menyediakan dengan tugas versi sipil dari model V-. Pekerjaan ini adalah
_nal dan oleh Menteri Federal pertahanan dan Menteri Federal Dalam Negeri
diterbitkan dan tetap versi seragam model V-akibat pada bulan Agustus
1993.
Model prosedural digunakan untuk pengembangan aplikasi oleh IT-sistem
ukuran yang paling beragam dan kompleksitas. Untuk menghasilkan dengan
penyelesaian proyek-proyek kecil dan menengah tidak ada pengeluaran
tambahan
terlalu besar, V-model untuk kondisi proyek caper ukuran, yang mengurangi
jumlah kegiatan dan produk dengan ukuran yang diperlukan, mende_nisikan.
Satu panggilan prosedur dari adaptasi dari model V-pada proyek-spesi_k
kebutuhan
Menjahit.
The V-Model adalah representasi gra_s dari pengembangan siklus hidup
sistem.
Ini merangkum langkah-langkah utama yang harus diambil dalam hubungannya
dengan kiriman yang sesuai dalam kerangka validasi sistem komputerisasi.
The V-Model mengasumsikan bahwa pengembangan sistem atau sistem
pemeliharaan dan modi_kasi adalah fokus komisi. Biasanya, pelanggan
merupakan
unit organisasi yang komisi pengembangan sistem lain unit organisasi
baik di luar atau di dalam perusahaan otoritas atau Ketika
mempertimbangkan
pelanggan dan kontraktor, ini tidak berarti bahwa peran dalam Model V-
akan
digandakan (peran pelanggan dan ontractor rolesc).Komunikasi tambahan dan
tugas koordinasi harus ditentukan yang dapat menyebabkan pengaturan dari
75
CHAPTER 5. PENUTUP 76
keputusan lebih lanjut dan kelompok kemudian.
The V merupakan urutan langkah-langkah dalam pengembangan kehidupan
siklus proyek. Ini menggambarkan kegiatan yang akan dilakukan dan hasil
yang
harus dihasilkan selama pengembangan produk.
V-Model memberikan panduan untuk perencanaan dan realisasi proyek.
Tujuannya
dimaksudkan untuk dicapai oleh pelaksanaan proyek: untuk meminimalkan
Risiko Proyek,Peningkatan dan Jaminan Mutu, Pengurangan Biaya
Total lebih dari Proyek Seluruh dan Siklus Hidup Sistem, dan Peningkatan
Komunikasi
antara semua Stakeholder. V model adalah metode pengembangan
perangkat lunak yang mengijinkan pada setiap prosesnya untuk dilakukan
testing
dan validasi. Jadi proses baru menggunakan hasil dari proses lama sebagai
acuannya. Ini memungkinkan meminimalisasikan kesalahan pada prosesnya.
V-model merangkum satu set dari kegiatan serupa disimpan ke komponen
prosedur sedemikian rupa ditentukan. Beberapa komponen prosedur menemukan
dengan semua aplikasi proyek dan karena itu sebagai V-model inti
yang ditunjuk. Selain milik PM: Proyek manajemen QA: Jaminan Mutu Mk:
Manajemen Kon_gurasi Pa: Masalah dan manajemen perubahan Produk dan
kegiatanV-model mende_nisikan satu set dokumen, yang disebut produk. Ini
terdiri dari topik individu. Produk, yang memiliki koneksi contentwise
kuat,
terlalu diatur lagi kelompok produk yang sama.
Pengembangan sistem informasi sering disebut sebagai proses pengembangan
sistem (System Development). Pengembangan sistem dide_nisikan sebagai
aktivitas untuk menghasilkan sistem informasi berbasis komputer untuk
menyelesaikan
persoalan (problem) organisasi atau memanfaatkan kesempatan
(opportunities)
yang timbul. Metodologi pengembangan Sistem dipromosikan sebagai
sarana untuk meningkatkan pengelolaan dan pengendalian proses pengembangan
perangkat lunak, penataan dan menyederhanakan proses, dan standarisasi
proses pengembangan dan produk dengan menentukan kegiatan yang harus
dilakukan
dan teknik yang digunakan.
Demikian yang dapat kami paparkan mengenai materi yang menjadi pokok
bahasan dalam makalah ini, tentunya masih banyak kekurangan dan
kelemahannya,
dengan keterbatasan pengetahuan dan kurangnya rujukan atau referensi
yang ada hubungannya dengan judul makalah ini. Penulis berharap para
pembaca
dapat memberikan kritik dan saran yang membangun kepada penulis demi
kesempurnaan makalah ini dan penulisan makalah di kesempatan-kesempatan
berikutnya. Semoga makalah ini berguna bagi penulis pada khususnya juga
para
pembaca pada umumnya.
CHAPTER 5. PENUTUP 77
Daftar Pustaka
http://irfante06.blog.unsoed.ac.id/_les/2009/06/tugas-1-rpl.doc
http://sasmoyo.blogstudent.
mb.ipb.ac.id/2010/07/21/no-1-uraian-mengenai-%E2%80%9Dperbedaan-pengembangansoftware-
dengan-pengembangan-sistem-informasi%E2%80%9D-2/
http://my_kom.wordpress.com/2012/11/12/model-model-komunikasi-suatuperkenalan/
http://www.informatik.uni-bremen.de/uniform/gdpa
http://v-modell.iabg.de/index.
php?option=com_docman&task=%20cat_view&gid=16&Itemid=30
http://en.wikipedia.org/wiki/V-Model
http://bluewarrior.wordpress.com/2009/10/12/waterfallmodel-
vs-v-model/
http://www.economypoint.org/v/v-model.html
http://lindahadi.blogspot.com/2009/03/v-model.html
http://www.bucanac.com/documents/The_V-Model.pdf