Softskill

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