MAKALAH

REKAYASA PERANGKAT LUNAK

V MODEL

DOSEN PEMBIMBING

Nisar [Link],M.T

DISUSUN OLEH

Angga Padela 1711010147

Muhammad Alifiya 1711010149

INSTITUT INFORMATIKA DAN BISNIS DARMAJAYA

FAKULTAS ILMU KOMPUTER

2019/2020

1
 BAB I

PENDAHULUAN

[Link] 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 [Link] 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 [Link] 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.

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:

2
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.

[Link] Masalah

Adapun rumusan masalah yaitu:

[Link] yang dimaksud V model?
[Link] model pengembangan v Model?
[Link] kelebihan dan kekurangan V model?

[Link]

[Link] memahami lebih dalam tentang V Model

[Link] mengetahui dan memahami model pengembangan V Model
[Link] Mengetahui kelebihan dan kekurangan V model sehingga dapat
menjadikan sebagai tolok ukur dalam memilih teknik pengembangan yang
dianggap baik
4. Untuk memenuhi tugas makalah dari mata kuliah Rekayasa Perangkat Lunak

[Link]

Adapun manfaat dari pembahasan ini yaitu:

[Link] dapat menambah wawasan mengenai model pengembangan
system informasi berbasis v model
2. Melalui pemaparan materi mengenai v model mahasiswa memiliki
kemampuan untuk memilih model pengembangan system informasi dengan
melihat berbagai perspektif yang dijabarkan.

3
 Bab II

TINJAUAN PUSTAKA

2.1 Konsep 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 [Link] adalah independen dari proyek
individu sejak layanan mereka diwajibkan oleh semua proyek. Contoh umum

4
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- .

2.2 Peran di V-Model

Peran di V-Model adalah:

• Manajer Proyek
• Pemimpin Proyek
• Hukum Perwakilan
• Proyek Administrator
• Pengawas
• Q Manajer
• QA Manajer
• Penaksir

5
• 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

6
menggunakan hasil dari proses lama sebagai acuannya. Ini memungkinkan
meminimalisasikan kesalahan pada prosesnya

Kelebihan dan Kekurangan v Model

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

[Link] 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.

[Link] hanya secara sementara. Ketika project selesai, jalannya proses model
dihentikan. Tidak berlangsung untuk keseluruhan organisasi.

3. Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang

7
dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan
jika ada tools lain yang lebih baik.

[Link] 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.

5.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).

[Link]

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

8
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

9
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.

1. Nama dari activity menggambarkan nama dan nomor dari activity. Activity di
sini dapat berupa main activity atau subactivity. Subactivity diberi nomor dengan
notasi titik.

[Link] 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

[Link] menggambarkan activity yang harus dilakukan. Jika main activity,

maka subactivity, hubungan antar subactivity, dan hasil dari subactivity harus
digambarkan.

[Link] 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

1. Pada state planned product masih dalam masa perencanaan. Product belum
exist. State ini merupakan initial state dari setiap product.

2. Pada state being processed product sedang dalam pemrosesan dan dalam
kontrol developer.

10
3. 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

4. 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.

11
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

12
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:

1. 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.

13
2. Placement atau 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.
3. 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.
4. 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.
5. Cost/benefit analysis
Tujuan dari activity ini adalah untuk menentukan seberapa profitable
solusi yang sudah direncanakan. Setiap solusi dievaluasi berdasarkan cost
dan benefit-nya.
6. 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.
7. 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.
8. 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.
9. Information service/reporting
Tujuan dari activity ini adalah untuk membuat informasi tentang proyek
available bagi customer, subcontractor, dan project member.
10. Training/instruction
Tujuan dari activity ini adalah untuk memberikan training bagi project
member sehingga mereka dapat memiliki pengetahuan yang diperlukan
untuk melakukan role-nya.
11. Supplying resources
Tujuan dari activity ini adalah untuk memberikan resource yang
dibutuhkan agar goal dari proyek dapat tercapai.
11. Allocation of work order
Tujuan dari activity ini adalah untuk melakukan pembagian kerja
berdasarkan work order.
12. Staff training
Tujuan dari activity ini adalah untuk memperkenalkan project member
pada pekerjaan mereka. Tugas dari setiap project member dijelaskan dan
diberitahukan.
[Link] completion

14
 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:

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.

System design
Termasuk dalam activity ini adalah pemilihan system architecture dan membuat
integration plan untuk architecture tersebut.

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.

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.

Detailed software design

Pada activity ini software architecture dan interface description dijelaskan lebih
lanjut. Spesifikasi dan detail untuk setiap module, component, dan database
dibuat.
Software implementation
Pada activity ini dilakukan implementasi dari module, component, dan database
dalam beberapa tahap.

Software integration
Pada activity ini dilakukan integrasi antara module, component, dan database.

System integration
Pada activity ini dilakukan integrasi sistem. Software dan hardware component
diintegrasikan berdasarkan system architecture.

Transition to utilization

15
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:

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.

Assessment preparation
Activity ini meliputi pembuatan assessment plan, di mana di dalamnya terdapat
definisi dari assessment method, criteria, environment, dan test case.

Process assessment of activity

Activity ini meliputi dilakukannya assessment pada proses untuk menentukan
apakah proses tersebut memadai atau tidak.

Product assessment
Activity ini meliputi dilakukannya assessment pada product.

Quality assurance reporting

16
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:

1. 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.

[Link] and configuration management

Activity ini meliputi pengelolaan product library dengan melakukan
pengkatalogan product.

[Link] 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.

[Link] management service

Termasuk di dalam activity ini adalah pengkatalogan software product, koordinasi
interface, backup, release management, dan pencatatan project history.

17
 Bab III

PEMBAHASAN

2.1 Pengertian v model

Model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan
karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika
dalam model waterfall proses dijalankan secara linear, maka dalam model V
proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara
tahap pengembangan software dengan tahap pengujiannya.

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 suatu 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

18
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.

2.2 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:

19
• 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.

20
• 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.

2.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.

2.4 Sub-sub models

Seperti disebutkan sebelumnya, ada empat submodels dalam Model V-. Dalam
bagian ini ada dijelaskan dalam lebih detail dari Model Proses Siklus Hidup titik
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.

21
2.5 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.

22
2.6 Pengembangan Sistem
Submodel SD mengatur kegiatan pengembangan sistem. Ini kompromi
kesembilan utama kegiatan:
•Sistem Analisis Persyaratan - Kegiatan ini melibatkan pengaturan persyaratan
sistem dari pengguna sudut pandang. Sistem ini ditentukan dari sudut pandang
eksternal.
•Desain Sistem - Kegiatan ini melibatkan pengaturan arsitektur sistem dan
rencana integrasi untuk arsitektur.
•SW / HW Analisis Persyaratan - Kegiatan ini melibatkan memperbarui
persyaratan teknis dan operasional informasi yang berkaitan dengan perangkat
lunak dan persyaratan perangkat keras. Hal ini dilakukan dengan membantu dari
kebutuhan pengguna, arsitektur sistem dan persyaratan teknis yang sebelumnya
berasal.
•Awal SW Desain - Kegiatan ini melibatkan merancang arsitektur perangkat
lunak. Ini termasuk menyelesaikan deskripsi antarmuka dan memperbarui rencana
integrasi perangkat lunak.
•Detil SW Desain - Arsitektur perangkat lunak dan deskripsi antarmuka yang
lebih rinci. Itu 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

23
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.

2.8 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.

2.9 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.

24
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

25
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.

[Link] 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.

[Link] 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

26
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.

27
 BAB IV

A. Kesimpulan

Berdasarkan materi di atas dapat disimpulkan bahwa v model

merupakan suatu metodologi pengembangan system yang mula-mula
digunakan untuk merancang suatu system yang berbasis-komputer,
tetapi dapat diberlakukan bagi setiap proses pengembangan yang
melibatkan interaksi berkelanutan dengan pemakai dengan perancang
yang berbeda system pengembangan. Model dalam pengembangan
berbasis v model memiliki model pengembangan secara bersama oleh
pengembang dengan pengguna. Kelebihan dalam v model menghasilkan
produk yang bermutu dan kekurangannya yaitu mahal. Dalam makalah
ini kami menyajikan kasus untuk mengintegrasikan v model dan
sebuah protokol kelompok yang dirancang untuk memecahkan masalah
yang serupa dengan yang ditemukan di v model . Kami menguji
proposisi kami dalam percobaan pengujian dari jurnal terkait, di mana
fasilitator v model profesional memimpin beragam kelompok
profesional bisnis, manajer, dan mahasiswa bisnis tingkat lanjut dalam
menetapkan persyaratan tingkat tinggi di bawah v model . Langkah-
langkah netral dan objektif dari mereka berefek pada kualitas
persyaratan yang dihasilkan menunjukkan bahwa kombinasi dari proses
kelompok ini, strukturnya tampaknya menetralisir dampak negatif dari
dinamika kelompok yang sering dialami dalam sesi v model , dan
berkontribusi pada peningkatan kualitas persyaratan.

B. Saran
Adapun sarannya yaitu melalui makalah ini dalam
pengembangan system informasi dapat lebih baik dengan menghindari
kekurangan serta meningkatkan kelebihan yang dimiliki oleh
pengembangan v model.

28
 Daftar pustaka

[Link]
[Link]
%E2%80%9Dperbedaan-pengembangan-software-dengan-pengembangan-sistem-
informasi%E2%80%9D-2/
[Link]
perkenalan/
[Link] [Link]
[Link]/[Link]?option=com_docman&task=%20cat_view&gid=16&Ite
mid=30
[Link]
[Link]
[Link]
[Link]
[Link]

29