KELOMPOK 1
( V-MODEL )
Diajukan Sebagai Tugas Softskill Mata Pelajaran Menajemen Proyek & Resiko #
Dosen : I Made Wiryana
YUDHI PRAKOSO ( 27111615 )
M. FAUZI IRAWAN ( 24111215 )
KHOERUL UMAM ( 23111977 )
ADI TRISNO HADI KUSUMA ( 20111185)
ORIZA GIUSTIKA ( 25111474 )
Universitas Gunadarma
Fakultas Ilmu Komputer Dan Terknologi Informasi
Jurusan Sistem Komputer
ATA 2012/2013
The V-model Merupakan Proses Pengembangan Perangkat Lunak (Juga Berlaku Untuk Pengembangan Hardware) Yang Dapat Dianggap Sebagai Perluasan Dari Model Air Terjun. Alih-alih Bergerak Turun Dengan Cara Yang Linear, Langkah-langkah Proses Yang Bengkok Ke Atas Setelah Fase Coding, Untuk Membentuk Bentuk V Yang Khas. The V-model Menunjukkan Hubungan Antara Setiap Fase Siklus Hidup Pengembangan Dan Fase Terkait Pengujian. Sumbu Horisontal Dan Vertikal Merupakan Kelengkapan Waktu Atau Proyek (Kiri Ke Kanan) Dan Tingkat Abstraksi (Yang Kasar-butiran Menonjol Abstraksi), Masing-masing.
Unit Testing Artikel Utama: Unit Pengujian Dalam Pemrograman Komputer, Unit Testing Adalah Metode Dimana Unit Individu Dari Kode Sumber Yang Diuji Untuk Menentukan Apakah Mereka Cocok Untuk Digunakan. Unit Adalah Bagian Terkecil Dari Diuji Aplikasi. Dalam Pemrograman Prosedural Unit Mungkin Merupakan Fungsi Individual Atau Prosedur. Unit Test Yang Dibuat Oleh Programmer Atau Kadang-kadang Oleh Penguji Kotak Putih. Tujuannya Adalah Untuk Memverifikasi Kode Logika Internal Dengan Menguji Setiap Cabang Mungkin Dalam Fungsi, Juga Dikenal Sebagai Cakupan Tes. Alat Analisis Statis Digunakan Untuk Memudahkan Dalam Proses Ini, Di Mana Variasi Data Masukan Yang Dilewatkan Ke Fungsi Untuk Menguji Setiap Kemungkinan Kasus Eksekusi. Integrasi Pengujian Artikel Utama: Pengujian Integrasi Dalam Pengujian Integrasi Modul Terpisah Akan Diuji Bersama-sama Untuk Mengekspos Kesalahan Dalam Antarmuka Dan Dalam Interaksi Antara Komponen Terintegrasi. Pengujian Biasanya Kotak Hitam Sebagai Kode Ini Tidak Langsung Diperiksa Untuk Kesalahan. Sistem Pengujian Artikel Utama: Sistem Pengujian Pengujian Sistem Akan Membandingkan Spesifikasi Sistem Terhadap Sistem Yang Sebenarnya. Setelah Tes Integrasi Selesai, Tingkat Tes Berikutnya Adalah Tes Sistem. Pengujian Sistem Memeriksa Apakah Produk Terintegrasi Memenuhi Persyaratan Yang Ditentukan. Mengapa Ini Masih Diperlukan Setelah Tes Komponen Dan Integrasi? Alasan Untuk Ini Adalah Sebagai Berikut: Alasan Untuk Pengujian Sistem Pada Tingkat Yang Lebih Rendah Pengujian, Pengujian Dilakukan Terhadap Spesifikasi Teknis, Yaitu, Dari Perspektif Teknis Dari Produsen Software. Tes Sistem, Meskipun, Melihat Sistem Dari Perspektif Pelanggan Dan Pengguna Di Masa Depan. Para Penguji Memvalidasi Apakah Persyaratan Benar-benar Dan Tepat Bertemu. Contoh: Pelanggan (Yang Telah Dipesan Dan Dibayar Untuk Sistem) Dan Pengguna (Yang Menggunakan Sistem) Bisa Menjadi Berbagai Kelompok Orang Atau Organisasi Dengan Kepentingan Mereka Sendiri Yang Spesifik Dan Persyaratan Sistem. Banyak Fungsi Dan Sistem Hasil Karakteristik Dari Interaksi Semua Komponen Sistem, Akibatnya, Mereka Hanya Terlihat Pada Tingkat Seluruh Sistem Dan Hanya Dapat Diamati Dan Diuji Di Sana. Pengguna Pengujian Penerimaan Artikel Utama: Penerimaan Pengujian Pengujian Penerimaan Adalah Tahap Pengujian Digunakan Untuk Menentukan Apakah Sistem Memenuhi Persyaratan Yang Ditentukan Dalam Tahap Analisis Persyaratan. Desain Tes Penerimaan Berasal Dari Dokumen Persyaratan. Tahap Uji Penerimaan Adalah Fase Yang Digunakan Oleh Pelanggan Untuk Menentukan Apakah Akan Menerima Sistem Atau Tidak. Pengujian Penerimaan Membantu Untuk Menentukan Apakah Sistem Memenuhi Kriteria Penerimaan Atau Tidak. Untuk Memungkinkan Pelanggan Untuk Menentukan Apakah Akan Menerima Sistem Atau Tidak. Untuk Menguji Perangkat Lunak Di "Dunia Nyata" Oleh Audiens. Tujuan Pengujian Penerimaan: Untuk Memverifikasi Sistem Atau Perubahan Sesuai Dengan Kebutuhan Aslinya. Prosedur Tentukan Kriteria Penerimaan: Fungsi Persyaratan. Persyaratan Kinerja. Antarmuka Persyaratan Mutu. Kualitas Perangkat Lunak Persyaratan Keseluruhan. Mengembangkan Rencana Penerimaan: Uraian Proyek. Pengguna Tanggung Jawab. Penerimaan Deskripsi.
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 keterbatasan yang kami miliki. Atas perhatian dan pengertiannya kami ucapkan Terima Kasih
Depok,30-Januari-2013
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
• Functional tool requirements
- Project management (PM)
- Quality assurance (QA)
- System development (SD)
- Configuration 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
1.Pengertian V-Model
2.Arsitektur
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
http://myfikom.wordpress.com/2012/11/12/model-model-komunikasi-suatu-perkenalan/
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/waterfall-model-vs-v-model/
http://www.economypoint.org/v/v-model.html
http://lindahadi.blogspot.com/2009/03/v-model.html
Bab I
PENDAHULUAN
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 flowchart 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 mendefinisikan 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 mereka, yang dijelaskan dalam artikel terpisah (model prosedural (software), konsep pengolahan (software)).
Bertentangan dengan model fase klasik di V-model kegiatan dan hasil hanya didefinisikan 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 offerers 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.
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 pada koordinasi dan dewan penasihat dalam pemerintahan federal (KBSt) untuk menyediakan dengan tugas versi sipil dari model V-. Pekerjaan ini adalah final 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 V-model untuk saya
Bagian 4: V-model-referensi peran (yang perlu saya untuk saya
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 file 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 Konfigurasi Pa: Masalah dan manajemen perubahan Produk dan kegiatan
V-model mendefinisikan 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 didefinisikan 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 modifikasi yang diinginkan. Untuk tujuan ini setiap kegiatan sungai produk dan penyelesaian yang didefinisikan. Sementara sungai produk menjelaskan, dari mana kegiatan produk masukan yang diperlukan dengan kondisi yang datang, agar dalam bentuk dimodifikasi dan / atau kondisi dimodifikasi 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 tambahan terlalu besar, V-model untuk kondisi proyek caper ukuran, yang mengurangi jumlah kegiatan dan produk dengan ukuran yang diperlukan, mendefinisikan. Satu panggilan prosedur dari adaptasi dari model V-pada proyek-spesifik 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 definisi 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 verifikasi 3.2 Aliran Spesifikasi 4 Aplikasi 5 Keuntungan 6 Batas 7 Lihat juga 8 Referensi 9 Pranala luar
Ikhtisar
The V-Model adalah representasi grafis 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 spesifikasi 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 verifikasi oleh "Apakah Anda membangun dengan benar?"
Dalam prakteknya, penggunaan istilah-istilah ini bervariasi. Kadang-kadang mereka bahkan digunakan secara bergantian.
Panduan PMBOK, standar IEEE, mendefinisikan mereka sebagai berikut dalam edisi ke-4: "Validasi Jaminan bahwa produk, layanan, atau sistem memenuhi kebutuhan pelanggan dan stakeholder lainnya diidentifikasi.. Ini sering melibatkan penerimaan dan kesesuaian dengan pelanggan eksternal Kontras dengan verifikasi.." "Verifikasi Evaluasi Kontras atau tidaknya suatu produk, layanan, atau sistem sesuai dengan peraturan, persyaratan, spesifikasi, atau kondisi yang ditetapkan. Hal ini sering proses internal. Dengan validasi.."
Tujuan Masalah
V-Model memberikan panduan untuk perencanaan dan realisasi proyek. Tujuan berikut ini dimaksudkan untuk dicapai oleh pelaksanaan proyek:
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.
Dalam proses model Waterfall 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 spesifikasi 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 Verifikasi 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 Verifikasi 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 Definition yakni mendefenisian project apa yang akan 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 klarifikasi, 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 Verification yang mana dalam tahap ini aplikasi yang telah diimplementasikan di lakukan verifikasi atau ditinjuau kegunaan nya apakah sesaui dengan kebutuhan user. Selanjutnya Operation and Maintenance yakni melakukan perbaikan atas apa yg telah di verifikasi 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 grafis 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 spesifikasi 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 verifikasi oleh "Apakah Anda membangun dengan benar?"
Dalam prakteknya, penggunaan istilah-istilah ini bervariasi. Kadang-kadang mereka bahkan digunakan secara bergantian.
Panduan PMBOK, standar IEEE, mendefinisikan mereka sebagai berikut dalam edisi ke-4:
"Validasi Jaminan bahwa produk, layanan, atau sistem memenuhi kebutuhan pelanggan dan stakeholder lainnya diidentifikasi.. Ini sering melibatkan penerimaan dan kesesuaian dengan pelanggan eksternal Kontras dengan verifikasi.." "Verifikasi Evaluasi Kontras atau tidaknya suatu produk, layanan, atau sistem sesuai dengan peraturan, persyaratan, spesifikasi, 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 verifikasi. Sistem Teknik dan verifikasi
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 identifikasi 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 verifikasi ), mengukur efektivitas dalam 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 Spesifikasi
Aliran Spesifikasi terutama terdiri dari: Pengguna Persyaratan Spesifikasi Fungsional Kebutuhan Spesifikasi Desain Spesifikasi Aliran pengujian umumnya terdiri dari:
Instalasi Kualifikasi (IQ)
Operasional Kualifikasi (OQ)
Kinerja Kualifikasi (PQ)
Aliran pembangunan dapat terdiri (tergantung pada jenis sistem dan ruang lingkup pengembangan) kustomisasi, konfigurasi atau coding.
Bab II
Konsep V- Model
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 mengidentifikasi kegiatan-kegiatan 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 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 konflik 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 proyek-proyek 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 modifikasi 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 mendefinisikan 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- .
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
• 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
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 modifikasinya
• V Model sangat fleksibel. 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.
Kerugian V Model
Aktifitas 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 / modifikasi dari system IT. V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.
V Model terlalu fleksibel 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.
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 Beschaffung = German Federal Office for Procurement).
2.Arsitektur
V Model terdiri dari 3 tahap. Secara garis besar tahap-tahap tersebut adalah seperti yang akan dijelaskan di bawah ini.
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.
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 menspesifikasikan standar kualitas yang diinginkan dan memberitahukannya pada submodel yang lain. Submodel ini juga menspesifikasikan contoh test case dan kriteria untuk memastikan bahwa software yang dihasilkan dan proses untuk menghasilkannya berdasarkan dan sesuai dengan standar yang telah ditetapkan.
- Configuration 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.
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 flow, 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 flow menggambarkan flow dari product. Product flow menggambarkan input product dan output product dari activity. Pada input product, 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 definisi activity agar activity tersebut lebih mudah dimengerti.
- 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 dimodifikasi jika version number product di-update. State dari product dan transisinya dapat dilihat pada gambar di bawah ini.
Gambar 2. Product State Dan Transisinya
- Organization dan role
Pembagian tugas kepada project member dilakukan berdasarkan role. Daftar role dibuat untuk setiap submodel. Setiap role mendefinisikan 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.
Penjelasan tentang keempat submodel yang ada dalam V Model dilihat dari sudut pandang lifecycle process model.
Allocation Of Methods
Tahap ini mengatur pemilihan dan penerapaan method untuk semua submodel yang ada. Tahap ini mendukung lifecycle process model karena tahap ini menspesifikasikan bagaimana cara melakukannya sedangkan lifecycle process model menspesifikasikan 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.
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:
- Identifikasi dan definisi dari method
- Karakteristik umum dari method
- Keterbatasan method
-Spesifikasi 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
-Literature lain tentang method tersebut
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 didefinisikan sebagai suatu software product yang mendukung development, maintenance, atau modification dari suatu sistem teknologi informasi. Tool dikelompokkan menjadi beberapa service unit. Sebuah service unit mendefinisikan 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 spesifikasi 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 menspesifikasi technical dan organization requirement. Hasilnya adalah technical requirement dari tool.
-Pada tahap ketiga, functional dan technical requirement untuk tool dirangkum dan menghasilkan operational criteria catalogue yang menggambarkan final requirement dari tool.
-Pada tahap terakhir dilakukan perbandingan antar tool dengan bantuan tool description atau profile 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 mendefinisikan 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 spesifikasi yang terdapat pada project manual.
o Cost/benefit analysis
Tujuan dari activity ini adalah untuk menentukan seberapa profitable solusi yang sudah direncanakan. Setiap solusi dievaluasi berdasarkan cost dan benefit-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
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 Staff 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 final 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.
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. Spesifikasi 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.
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 spesifikasi organizational dan procedural scope dari quality assurance activity. Semua spesifikasi untuk product dan proses didokumentasikan dalam quality assurance plan.
o Assessment preparation
Activity ini meliputi pembuatan assessment plan, di mana di dalamnya terdapat definisi 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.
o Product assessment
Activity ini meliputi dilakukannya assessment pada product.
o Quality assurance reporting
Activity ini meliputi evaluasi assessment report berdasarkan severity dari problem, klasifikasi problem, dan penyebab dari problem.
- Configuration management (CM)
Submodel ini menjamin bahwa suatu product dapat diidentifikasi setiap saat. Identifikasi ini dilakukan untuk mengontrol modifikasi dan menjamin integritas. Submodel ini terdiri dari empat main activity yaitu:
o Configuration management planning
Activity ini meliputi pendefinisian organizational framework dan pendokumentasiannya dalam configuration management plan. Resource dan tool yang dibutuhkan juga didokumentasikan dalam configuration management plan.
o Product and configuration 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 configuration 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 Configuration management service
Termasuk di dalam activity ini adalah pengkatalogan software product, koordinasi interface, backup, release management, dan pencatatan project history.
3. Macam- Macam V-Model
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, faktor-faktor yang memainkan peran dalam menentukan efek persuatif suatu pidato meliputi isi pidato, susunannya, dan cara penyampainnya. Salah satu kelemahan model ini adalah bahwa komunikasi dianggap sebagai fenomena yang statis.
V Model Lasswell
Model ini berupa ungkapan verbal, yaitu : Who Says What In Which Channel To Whom With What Effect 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.
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 efisien dan dapat mengatasi gangguan dalam saluran. Sayangnya, model ini juga memberikan gambaran yang parsial, komunikasi dipandang sebagai fenomena satu arah.
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 setiap sistem ditandai oleh suatu keseimbangan atau simetri,karena ketidakkeseimbangan atau kekurangan simetri secara psikologis tidak menyenangkan dan menimbulkan tekanan internal untuk memulihkan keseimbangan.
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.
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
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).
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 fisik informasi menjadi pesan. Menurut DeFleur komunikasi adalah terjadi lewat suatu operasi perangkat komponen dalam suatu sistem teoretis, yang konsekuensinya adalah isomorfisme diantara respons internal terhadap seperangkat simbol tertentu pada pihak pengirim dan penerima.
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.
V Model Gudykunst dan Kim
Merupakan model antar budaya, yakni komunikasi antara budaya yang berlainan, atau komunikasi dengan orang asing.
Menurut Gudykunst dan Kim, penyandian pesan dan penyandian balik pesan merupakan suatu proses interaktif yang dipengaruhi oleh filter-filter konseptual yang dikategprikan menjadi faktor-faktor budaya, sosial budaya, psikobudaya, dan faktor lingkungan.
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.
Bab III
Software Pendukung
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 Metode Weighted 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.
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 didefinisikan 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.
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
Tujuan dalam Penelitian ini adalah :
i Membangun aplikasi pendukung yang mampu memberi pertimbangan keputusan underwriting akseptasi dan penerbitan polis berdasarkan persyaratan yang ada.
ii. Menerapkan metode pembobotan Fuzzy-AHP dan Weighted Product Model dalam membangun aplikasi pendukung underwriting akseptasi dan penerbitan polis pada AJB Bumiputera 1912
iii. 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 batasan-batasan 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 mendukung pengambilan keputusan underwriting akseptasi dan penerbitan polis dikelompokkan menjadi 3 kriteria yaitu:
a. Seleksi fisik kesehatan
b. Seleksi financial c. Pengamatan nilai ekonomis
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 efisien 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 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 Pendukung Underwriting dan Akseptasi Calon Pemegang Polis
Alasan penggabungan metode Fuzzy-AHP dan WPM
Penggabungan metode Fuzzy-AHP dan WPM memiliki alasan sebagai berikut:
i. 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.
ii. Menggabungkan kelebihan dan mengurangi kekurangan yang dimiliki oleh masing-masing metode.
a. Fuzzy-AHP
-Kelebihan metode Fuzzy-AHP adalah:
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.
b. 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.
2. 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 file 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 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 mendefinisikan 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 spesifik, 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, file 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 file header dalam subframeworks. Jika Anda memasukkan file induk header untuk subframework tersebut, perubahan ini tidak akan mempengaruhi program Anda.
The Bundle Payung Kerangka Secara fisik, kerangka payung memiliki struktur yang mirip dengan kerangka kerja standar. Salah satu perbedaan yang signifikan 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 standar, 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 fleksibilitas 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.
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: Quartz.
3 . 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
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.
5.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.
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.
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 Office 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 fitur-fitur baru.
“Fitur-fitur 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.
Gambar 3. Arsitektur Microsoft App-V Sequencer
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 Office 2010. Ikuti langkah demi langkah dari wizard yang muncul.
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 file sebagai berikut :
- File SFT, merupakan aplikasi asli yang dipaket menjadi satu file.
- File OSD, merupakan pengontrol aplikasi yang dijalankan. Penghubung antara client dan file SFT.
- File SPRJ, digunakan untuk perubahan aplikasi dimasa depan dan untuk diimpor ke Management Server.
- File XML, sebagai manifest atau berisi link file-file yang saling terkait. - File ICO, merupakan file ikon dari aplikasi.
- File MSI, digunakan untuk model App-V Standalone. Berisi file 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.
Gambar 6. Proses Menjalankan Paket Aplikasi.
Bab IV
Contoh Pemanfaatan Software
Alokasi Metode dan Alat Persyaratan Fungsional
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 :
• Identifikasi dan definisi metode.
• Singkat karakteristik metode.
• Batas metode.
• Spesifikasi 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 didefinisikan sebagai "alat adalah sebuah produk software yang mendukung pengembangan atau pemeliharaan / modifikasi sistem TI ". Alat-alat yang dikelompokkan ke dalam unit pelayanan. Sebuah unit pelayanan mendefinisikan 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.
• 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 profil dan katalog kriteria operasional. Hasil perbandingan ke beberapa alat yang berlaku.
Model Proses Siklus Hidup
Dasar elemen
Kegiatan dan Produk
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 memodifikasi 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.
• 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 spesifik itu outputted. Pada output, itu adalah dijelaskan dimana aktivitas produk diteruskan ke dan negara itu. Lihat Gambar 2.
Gambar 2.
• Penanganan - Menjelaskan bagaimana kegiatan harus ditangani selama realisasi. Dalam kegiatan utama, para subactivities, interdependensi dan hasilnya secara grafis dijelaskan dalam penanganan Bagian.
• Rekomendasi dan penjelasan - Memberikan rekomendasi tentang bagaimana aktivitas dapat ditangani. Penjelasan memperjelas definisi 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-Spesifik Model V-) dengan negara yang sedang diproses. Pedoman Proyek merupakan salah satu produk masukan kepada PM 1.3 aktivitas.
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:
• 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 check-in 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 dimodifikasi lebih lanjut jika nomor versi diperbarui.
Negara-negara dan transisi dimodelkan pada Gambar 3.
Gambar 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 didefinisikan 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.
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 pandang. Semua submodels terdiri dari beberapa kegiatan dan menghasilkan beberapa produk. Mereka juga bekerja sama untuk mencapai tujuan proyek. Hal ini ditunjukkan pada Gambar 4.
Proyek Manajemen
The submodel PM mengatur kegiatan memulai, perencanaan dan pengawasan proyek. Itu kompromi dari 14 kegiatan utama:
• Proyek Inisialisasi - Mendefinisikan 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.
• 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 spesifikasi 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 langkah-langkah pencegahan dan mengawasi efisiensi 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.
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 spesifikasi 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.
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 spesifikasi untuk produk dan proses yang didokumentasikan dalam rencana QA.
• Persiapan Penilaian - Kegiatan ini melibatkan menghasilkan rencana penilaian. Ini berisi definisi 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, klasifikasi masalah dan penyebab masalah.
Konfigurasi Manajemen
Submodel CM menjamin bahwa produk dapat diidentifikasi secara unik setiap saat. Identifikasi berfungsi untuk mengontrol modifikasi dan untuk menjamin integritas. Ini kompromi kegiatan utama empat :
• Perencanaan CM - Kegiatan ini melibatkan mendefinisikan kerangka organisasi dan untuk mendokumentasikan dalam rencana CM. Sumber daya yang dibutuhkan dan alat juga didokumentasikan dalam rencana CM.
• Produk dan Manajemen Konfigurasi - Kegiatan ini melibatkan mengelola perpustakaan produk dengan katalogisasi produk. Sebuah konfigurasi 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.
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
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.
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, configuration 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:
1. 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
• 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 konfigurasi 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 definisi input akan menghasilkan output yang diinginkan. Sementara proses pemeliharaaan atau maintenance dilakukan karena software mengalami error, atau harus diadaptasi untuk menyesuaikan dengan lingkungan external.
2. 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.
3. 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:
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 definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya, seperti gambar berikut :
Pada spiral model, setiap Loop dibagi dibagi menjadi sejumlah aktifitas kerangka kerja yang disebut juga wilayah tugas, wilayah tugas tersebut terdiri antara tiga sampai enam wilayah tugas, yaitu :
a. Komunikasi Pelanggan.Tugas – tugas yang dibutuhkan untuk membangun komunikasi yang efektif di antara pengembangan dan pelanggan.
b. Perencanaan.Tugas–tugas yang dibutuhkan untuk mendefinisikan sumber–sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
c. Analisis Risiko.Tugas – tugas yang dibutuhkan untuk menaksir risiko – risiko, baik manajemen maupun teknis.
d. Perekayasaan.Tugas – tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut.
e. Konstruksi dan peluncuran.Tugas – trugas yang dibutuhkan untuk mengkonstruksi, menguji, instalasi dan memberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi).
f. Evaluasi pelanggan.Tugas – tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi 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 :
1) Tahap Investigasi Pada tahap investigasi akan terjadi proses seperti:
a) Initialisas : terjadi proses seperti perencanaan manajemen, kebutuhan serta potensi dari user.
b) Definisi formal: dilakukan definisi tujuan, motivasi, ruang lingkup, batasan, kendala, dan strategi. Selain itu, pada definisi formal juga dilakukan verifikasi permasalahan sehingga dapat dilakukan penilaian terhadap kebutuhan yang baru.
c) Uji kelayakan, yang terdiri dari:
1. Uji kelayakan teknis, merupakan uji terhadap ketersediaan hardware dan software.
2. Uji kelayakan ekonomis, yaitu menilai apakah manfaat yang didapat dari pengembangan software akan sebanding dengan biaya yang dikeluarkan.
3. Uji kelayakan operasional, uji kelayakan yang berkaitan dengan kemampuan orang yang bekerja dalam sistem untuk melakukan pekerjaan mereka dengan cara yang telah ditentukan.
4. Uji kelayakan kelayakan organisasi, menilai kesiapan perusahaan atau organisasi untuk mengembangkan penjualan pemasaran dan sistem keuangan berbasis Web (e-commerce system).
2) Tahap Analisa Dalam tahapan ini sistem yang akan dibangun diselaraskan dengan kebutuhan user atau pengguna. Pada tahap ini terjadi proses seperti :
a) Determine requirements atau penentuan kebutuhan, hal ini dilakukan dengan cara mempelajari sistem yang telah ada, serta menentukan kebutuhan struktur dan menghilangkan redundansi.
b) Requirement analysis atau analisa kebutuhan, terdiri dari analisa kebutuhan fungsional dan performa (kinerja).
c) Menghasilkan desain sistem alternatif
d) Membandingkan alternatif desain sistem yang dihasilkan dan
e) Merekomendasikan alternatif terbaik kepada klien.
3) Tahap Desain Tahap menentukan bagaimana sistem mencapai tujuan yang telah didefinisikan sebelumnya. Tahap ini terdiri dari :
a) User interface design, meliputi tampilan, form, report dan dialog design.
b) Data design, merupakan proses desain elemen struktur data.
c) Process design, merupakan desain program prosedur sistem
4) Tahap Implementasi Pada tahap ini terjadi beberapa hal seperti :
a) Evaluasi hardware, software dan jasa
b) Modifikasi dan pengembangan software
c) Dokumentasi, yang merupakan mekanisme komunikasi utama selama proses pengembangan.
d) Konversi data, pada proses ini terjadi perbaikan dan penyaringan data yang tidak diinginkan dan konsolidasi data.
e) Testing atau uji coba, pada proses ini dilakukan uji coba dan debugging software.
f) Training atau pelatihan sistem/software yang telah terbentuk.
g) 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
5) Tahap Pemeliharaan (maintenance) Pada proses ini terjadi modifikasi software, perbaikan error atau umpan balik dari user terhadapsoftware yang telah mereka gunakan.
Keunggulan dan Kelemahan pada metode SDLC antara lain :
a. Keunggulan :
1) Proses pengembangan sangat terstruktur dan sistematik
2) Melalui definisi kebutuhan, sehingga gap atau kesenjangan yang terjadi antara kebutuhan dan sistem yang dihasilkan dapat dikurangi.
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.
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 bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan seperti :
1) Informasi apa yang mengendalikan proses bisnis?
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 didefinisikan sebagai bagian dari fase bussiness modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan.
c. Prosess modelling
Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, 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
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 bagian-bagian 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 (develop-revise prototype) akan terus berlangsung hingga didapatkanprototype sistem yang sesuai dengan kebutuhan klien atau user.
Gambaran Model Prototyping.
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 efisiensi waktu
4. Implementasi sistem menjadi lebih mudah karena user turut berperan aktif didalam proses pengembangan
Kelemahan :
1. Kurangnya fitur keamanan dan kontrol pada prototype akhir sistem
2. Sistem akan sulit terbentuk jika proses evaluasi pada siklus prototype tidak mendapatkan titik temu.
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 didefinisikan 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 yaitu :
1. Sistem yang dikembangkan adalah untuk manajemen.
Setelah sistem selesai dikembangkan, maka yang akan menggunakan informasi dari sistem ini adalah manajemen, sehingga sistem harus dapat mendukung, kebutuhan yang diperlukan oleh manajemen. Pada waktu Anda mengembangkan sistem, maka prinsip ini harus selalu diingat.
2. Sistem yang dikembangkan adalah investasi modal yang besar.
Sistem informasi yang akan Anda kembangkan membutuhkan dana modal yang tidak sedikit, apalagi dengan digunakannya teknologi yang mutakhir. Sistem yang dikembangkan ini merupakan investasi modal yang besar. Seperti halnya dengan investasi modal lainnya yang dilakukan oleh perusahaan, maka setiap investasi modal harus mempertimbangkan 2 hal berikut ini :
a. Semua alternatif yang ada harus diinvestigasi.
b. Investasi yang terbaik harus bernilai.
3. Sistem yang dikembangkan memerlukan orang-orang yang terdidik.
Manusia merupakan faktor utama yang menentukan berhasil tidaknya su atu sistem, baik dalam proses pengembangannya, penerapannya, maupun dalam proses operasinya. Oleh karena itu orang yang terlibat dalam pengembangan maupun penggunaan sistem ini harus merupakan orang yang terdidik tentang permasalahan-permasalahan yang ada dan terhadap solusi-solusi yang mungkin dilakukan.
4. Tahapan kerja dan tugas-tugas yang harus dilakukan dalam proses pengembangan sistem.
Proses pengembangan sistem umumnya melibatkan beberapa tahapan kerja dan melibatkan beberapa personil dalam bentuk suatu team untuk mengerjakannya. Pengalaman menunjukan bahwa tanpa adanya perencanaan dan koordinasi yang baik, maka proses pengembangan sistem tidak akan berhasil dengan memuaskan. Untuk maksud ini sebelum proses pengembangan sistem dilakukan, maka harus dibuat terlebih dahulu skedul kerja yang menunjukkan tahapan-tahapan kerja dan tugas-tugas pekerjaan yang akan dilakukan, sehingga proses pengembangan sistem dapat dilakukan dan selesai dengan berhasil sesuai dengan waktu dan anggaran yang direncanakan.
5. Proses pengembangan sistem tidak harus urut.
Prinsip ini kelihatannya bertentangan dengan prinsip nomor 4, tetapi tidaklah sedemikian. Tahapan kerja dari pengembangan sistem di prinsip nomor 4 menunjukkan langkah-langkah yang harus dilakukan secara bersama-sama. Ingatlah waktu adalah uang. Misalnya di dalam pengembangan sistem, perancangan output merupakan tahapan yang harus dilakukan sebelum melakukan perancangan file. Ini tidak berarti bahwa semua output harus dirancang semuanya terlebih dahulu baru dapat melakukan perancangan file, tetapi dapat dilakukan secara serentak, yaitu sewaktu proses pengadaan hardware.
6. Jangan takut membatalkan proyek.
Umumnya hal ini merupakan pantangan untuk membatalkan suatu proyek yang sedang berjalan. Keputusan untuk meneruskan suatu proyek atau membatalkannya memang harus dievaluasi dengan cermat. Untuk kasus-kasus yang tertentu, dimana suatu proyek terpaksa harus dihentikan atau dibatalkan karena sudah tidak layak lagi, maka harus dilakukan dengan tegas. Keraguan untuk terus melanjutkan proyek yang tidak layak lagi karena sudah terserapnya dana kedalam proyek ini hanya akan memubang dana yang sia-sia. Sistem Informasi dibangun untuk mendukung proses yang berjalan dalam sebuah organisasi, dimana didalamnya tercakup antara lain: proses perencanaan (Planning), pengorganisasian (Organizing) dan pengendalian (Controlling). Pengembangan Sitem Informasi akan bermula dasi PSI (Perencanaan Sistem Informasi), Analisa, Perancangan hingga Implmentasi. Sedangkan Pengembangan Sistem Software bermula dari Anlisa, Perencanaan hingga Implementasi.
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)
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 spesifikasi 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.
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 :
a. memperoleh biaya produksi perangkat lunak yang rendah
b. menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
c. menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
d. menghasilkan perangkat lunak yang biaya perawatannya rendah
2. Ruang Lingkup
Sesuai dengan definisi yang telah disampaikan sebelumnya, maka ruang lingkup RPL dapat digambarkan sebagai berikut :
• software Requirements berhubungan dengan spesifikasi 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 configuration management berhubungan dengan usaha perubahan konfigurasi 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
• software engineering process berhubungan dengan definisi, 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 :
..jpg)
• Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap model pengembangan perangkat lunak adalah pendefinisian 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.
• 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, efisiensi 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 spesifikasi detil dari solusi berbasis computer (Whitten et al, 2004). Disain perangkat lunak sering juga disebut sebagai physical design. 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 spesifikasi disain. Spesifikasi ini meliputi spesifikasi disain umum yang akan disampaikan kepada stakeholder sistem dan spesifikasi disain rinci yang akan digunakan pada tahap implementasi. Spesifikasi 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. Spesifikasi 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 fisik 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 kriteria-kriteria yang telah ditetapkan.
6. Perawatan dan Konfigurasi. 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 :
• 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 komponen-komponen yang terlibat dalam perangkat lunak tersebut. Sebagai contoh perubahan platform sistem operasi dari versi lama ke versi baru menyebabkan perangkat lunak harus diupgrade.
Bab V
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 final 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, mendefinisikan. Satu panggilan prosedur dari adaptasi dari model V-pada proyek-spesifik kebutuhan Menjahit.
The V-Model adalah representasi grafis 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 modifikasi 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 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 Konfigurasi Pa: Masalah dan manajemen perubahan Produk dan kegiatanV-model mendefinisikan 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 didefinisikan 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.
Daftar pustaka
http://irfante06.blog.unsoed.ac.id/files/2009/06/tugas-1-rpl.doc http://sasmoyo.blogstudent.mb.ipb.ac.id/2010/07/21/no-1-uraian-mengenai-%E2%80%9Dperbedaan-pengembangan-software-dengan-pengembangan-sistem-informasi%E2%80%9D-2/
http://myfikom.wordpress.com/2012/11/12/model-model-komunikasi-suatu-perkenalan/
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/waterfall-model-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
yuhuuu...bermanfaat sekali
BalasHapusSolder Temperatur