METODE PENGEMBANGAN PERANGKAT LUNAK. docx
Nama Kelompok:
NADIA ARIFI ANANDA
G.211.12.0137
AVIANTO NUGROHO
G.211.12.0139
ADITYA WISNU G.
G.211.12.0147
METODE PENGEMBANGAN PERANGKAT LUNAK
1.
MODEL LINEAR SEQUENTIAL/WATERFALL
Model Linear Sequential/Waterfall merupakan paradigma rekayasa perangkat lunak yang
paling tua dan paling banyak dipakai.
Kelebihan model Linear Sequential/Waterfall :
Mudah diaplikasikan
Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan
pemeliharaan
Cocok digunakan untuk produk software yang sudah jelas kebutuhannya di awal,
sehingga minim kesalahannya
Kekurangan model Linear Sequential/Waterfall :
Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen
harus dilakukan pada tahap awal proses
Sulit untuk mengalami perubahan kebutuhan yang diinginkan customer
Customer harus sabar untuk menanti produk selesai, karena dikerjakan tahap per
tahap,menyelesaikan tahap awal baru bisa ke tahap selanjutnya
Perubahan ditengah-tengah pengerjaan produk akan membuat bingung team work yang
sedang membuat produk
Adanya waktu menganggur bagi pengembang, karena harus menunggu anggota tim
proyek lainnya menuntaskan pekerjaannya
2.
MODEL PROSES PERANGKAT LUNAK EVOLUSIONER
Model evolusioner adalah model iterative, ditandai dengan tingkah laku yang
memungkinkan perekayasa perangkat lunak mengembangkan versi perangkat lunak yang
lebih lengkap sedikit demi sedikit. Kebutuhan produk dan bisnis kadang-kadang berubah
seiring dengan laju perkembanganya.
Dalam situasi tersebut maupun lainya, perekayasa perangkat lunak membutuhkan
sebuah model proses yang sudah dirancang secara eksplisit untuk mengakomodasi produk
perkembangan sepanjang waktu. Model ini bukan termasuk rekayasa perangkat lunak
klasik. Model evolusioner meliputi model increment, spiral, perkembangan konkruen dan
rakitan komponen.
3.
MODEL INCREMENT
Model incremental menggabungkan elemen-elemen model sekuensial linier
(diaplikasikan secara berulang) dengan filosofi prototype iterative. Model ini memakai
urutan-urutan linier di dalam model yang membingungkan, seiring dengan laju waktu
kalender. Setiap urutan linier menghasilkan pertambahan, perangkat lunak “yang bisa
disampaikan.” Contoh, perangkat lunak pengolah kata yang dikembangkan dengan
menggunakan paradigm pertambahan akan menyampaikan manajemen file, editing, serta
fungsi penghasilan dokumen pada pertambahan pertama, dan selanjutnya. Pertambahan
pertama dapat disebut sebagai produk inti (core product).
Model ini berfokus pada penyampaian produk operasional dalam Setiap
pertambahanya. Pertambahan awal ada di versi stripped down dari produk akhir, tetapi
memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk
evaluasi oleh pemakai.
Perkembangan pertambahan, khususnya berguna pada staffing, tidak bisa dilakukan
menggunakan implementasi lengkap oleh batas waktu bisnisyang sudah disepakati untuk
proyek tersebut. jika produk inti diterima dengan baik, maka staf tambahan bisa
ditambahkan untuk mengimplementasi pertambahan selanjutnya.
4.
MODEL SPIRAL
Awalnya diusulkan oleh Boehm (BOE88), adalah model proses perangkat lunak yang
evolusioner, merangkai sifat iterative dari prototype dengan cara control dan aspek
sistematis dari model sekuensial linier. Model yang berpotensi untuk pengembangan versi
pertambahan perangkat lunak secara cepat. Model spiral dibagi menjadi sejumlah
aktifitas kerangka kerja atau wilayah tugas, antara lain :
Komunikasi pelanggan, tugas-tugas yang dibutuhkan untuk membangun komunikasi
yang efektif diantara pengembang dan pelanggan.
Perencanaan, tugas-tugas yang dibutuhkan untuk mendefinisikan sumber-sumber
daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
Analisis resiko, tugas-tugas yang dibutuhkan untuk menaksir resiko-resiko, baik
manajemen maupun teknis.
Perekayasaan, tugas-tugas yang dibutuhkan untuk membangun satu atau lebih
representasi dari aplikasi tersebut.
Konstruksi dan peluncuran, tugas-tugas yang dibutuhkan untuk mengkonstruksi,
menguji, memasang (instal), dan memberikan pelayanan kepada pemakai (contohnya
pelatihan dan dokumentasi)
Evaluasi pelanggan, tugas-tugas untuk memperoleh umpan balik dari pelanggan
dengan didasarkan pada evaluasi representasi perangkat lunak, yang dibuat selama
masa perekayasaan, dan dimplementasikan selama masa pemasangan.
Model spiral menjadi pendekatan yang realistis bagi perkembangan system dan perangkat
lunak skala besar. Karena perangkat lunak terus bekerja selama proses bergerak,
pengembang dan pemakai memahami, dan bereaksi lebih baik terhadap resiko dari Setiap
tingkat evolusi. Model spiral menggunakan prototype sebagai mekanisme pengurangan
resiko.
Model spiral membutuhkan keahlian penafsiran resiko yang masuk akal, dan sangat
bertumpu pada keahlian ini untuk mencapai keberhasilan. Jika sebuah resiko tidak dapat
ditemukan dan diatur, pasti akan terjadi masalah. Model ini membutuhkan waktu
bertahun-tahun sampai kehandalannya bisa dipertimbangkan dengan kepastian absolute.
5.
COMPONENT ASSEMBLY MODEL (Model Perakitan Komponen)
Model ini merupakan gabungan dari berbagai sifat dan karakter dari model spiral
Boehm dan sangat erat keterikatannya dengan model RAD (Rapid Application
Development) model karena model CAM ini menggunakan peralatan-peralatan dan GUI
(Graphic User Interface) untuk membangun software. Dengan kata lain, pembuatan
aplikasinya dibuat dari paket perangkat lunak yang berisi serangkaian komponen yang
telah ada sebelumnya. Namun, waktu yang dibutuhkan dapat disesuaikan atau lebih
efektif ketimbang harus mengerjakan program dari awal.
Tahapan-tahapan Model ini adalah:
Tahap Identifikasi calon-calon komponen (kelas objek); Tahap melihat komponenkomponen dalam pustaka; Tahap mengekstrak komponen jika ada; Tahap membangun
komponen jika tidak ada; Tahap menyimpan komponen baru pada pustaka; Tahap
mengkonstruksi iterasi ke-n dari sistem.
Kelebihan model ini adalah tinggal mencaplok atau menggunakan program atau
komponen yang sudah ada dan menyusunnya menjadi sebuah program yang lebih
kompleks dan berkembang sesuai dengan kebutuhan user/pengguna sehingga dapat
mengefisienkan penggunaan waktu dan tenaga. Selain itu, model ini juga menyediakan
kemampuan untuk memvisualisasikan hasil rakitan dengan kesanggupan untuk
mengukur, menganalisa, merancang dan merancang ulang program.
Kekurangan model ini adalah seringnya program atau komponen-komponen terdahulu
tidak kompatibel atau sejalan dengan model perakitan komponen ini sehingga untuk
perusahaan berskala kecil akan kesulitan menemukan komponen yang sesuai untuk
dirakit.
Model ini sangat sesuai digunakan oleh perusahaan besar yang sudah berpengalaman
mengembangkan software. Mereka dapat memanfaatkan software-software yang telah
umum dikembangkan sebelumnya menjadi bentuk baru dari software yang ingin
dikomersilkan.
6.
THE CONCURRENT DEVELOPMENT MODEL
Model ini disebut juga dengan concurrent engineering yang dapat digambarkan secara
skematik sebagai serial dari kegiatan teknis utama, tugas-tugas, dan hubungan antar
bagian-bagian yang saling terkait di mana aktifitas analisa seperti desain/rancangan atau
komunikasi pelanggan dapat diskemakan dengan cara yang sama.
Concurrent process model cocok digunakan untuk pengembangan aplikasi client/server
yang terdiri atas satu set komponen yang fungsional. Terdapat dua dimensi aktivitas yang
digambarkan oleh model ini sebagai berikut.
Dimensi sistem: terdapat tiga proses di dalamnya yakni perancangan, perakitan
(assembly) dan penggunaan (use).
Dimensi komponen: terdapat dua kegiatan utama yaitu perancangan dan realisasi.
Concurrency (pertemuan) dapat diperoleh dengan dua cara: 1) sistem dan komponen
kegiatan (aktifitas) terjadi secara simultan dan dapat diperagakan dengan memanfaatkan
pendekatan yang berdasar pada status sebelumnya; 2) aplikasi client/server yang bersifat
unik/khas di mana dapat diterapkan pada banyak komponen yang tiap-tiap komponen
bisa dirancang dan direalisasikan secara serentak.
7.
MODEL PROTOTYPE
Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara
langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau komponenkomponen perangkat lunak akan bekerja dalam lingkungannya sebelum tahapan
konstruksi aktual dilakukan (Howard, 1997).
Beberapa model prototype adalah sebagai berikut :
Reusable prototype : Prototype yang akan ditransformasikan menjadi produk final.
Throwaway prototype : Prototype yang akan dibuang begitu selesai menjalankan
maksudnya.
Input/output prototype : Prototype yang terbatas pada antar muka pengguna (user
interface).
Processing prototype : Prototype yang meliputi perawatan file dasar dan prosesproses transaksi
System prototype : Prototype yang berupa model lengkap dari perangkat lunak.
Proses pada model prototyping adalah sebagai berikut:
1. pengumpulan kebutuhan
developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang
diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil
kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan
2. perancangan
perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang
diketahui, dan rancangan ini menjadi dasar pembuatan prototype.
3. Evaluasi prototype
klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas
kebutuhan software.
Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan
terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk
memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan
kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa
dimanfaatkan.
Skema dari prototype secara umum adalah sebagai berikut :
Konsep SDLC – Prototype
Pendekatan prototyping memiliki beberapa keuntungan yaitu:
Pemodelan membutuhkan partisipasi aktif dari end-user. Hal ini akan
meningkatkan sikap dan dukungan pengguna untuk pengerjaan proyek. Sikap
moral pengguna akan meningkat karena system berhubungan nyata dengan
mereka.
Perubahan dan iterasi merupakan konsekuensi alami dari pengembangan systemsehingga end user memiliki keinginan untuk merubah pola pikirnya. Prototyping
lebih baik menempatkan situasi alamiah ini karena mengasumsikan perubahan
model melalui iterasi kedalam system yang dibutuhkan.
Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat,
merasakan, dan mengalaminya.
Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini
Prototyping dapat meningkatkan kreatifitas karena membolehkan adanya feedback
dari end user. Hal ini akan memberikan solusi yang lebih baik.
Prototyping mempercepat beberapa fase hidup dari programmer.
Pendekatan prototyping memiliki beberapa kekurangan yaitu:
Prototyping memungkinkan terjadinya pengembalian terhadap kode, implementasi,
dan perbaikan siklus hidup yang dugunakan untuk mendominasi sistem informasi.
8.
Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya
dapat memecahkan masalah yang salah dan memberi kesempatan sebagai sistem
pengembangan konvensional.
Prototyping dapat mengurangi kreatifitas perancangan.
MODEL RAD (Rapid Application Development)
Merupakan model proses pengembangan perangkat lunak secara linear sequential
yang menekankan pada siklus pengembangan yang sangat singkat/pendek. Jika
kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan
menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek
(kira-kira 60-90 hari). Pendekatan RAD model menekankan cakupan :
a.
Pemodelan bisnis (Bussiness Modelling)
Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk
menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses
bisnis ? Kemana informasi itu pergi? Siapa yang memprosesnya ?
b. Pemodelan data (Data Modelling)
Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan bisnis disaring
ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut.
Karakteristik/atribut dari masing-masing objek diidentifikasi dan hubungan antara objekobjek tersebut didefinisikan.
c.
Pemodelan proses (Process Modelling)
Aliran informasi yang didefinisikan dalam fase pemodelan data 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. Pembuatan aplikasi (Application generation)
Selain menciftakan perangkat lunak dengan menggunakan bahasa pemrograman generasi
ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi
komponen program yang telah ada atau menciftakan komponen yang bias dipakai lagi.
Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi kontruksi
perangkat lunak.
e. Pengujian dan pergantian (Testing and turnover)
Karena proses RAD menekankan pada pemakaian kembali, banyak komponen yang telah
diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji.
Kelemahan model RAD :
Untuk proyek dengan skala besar, RAD membutuhkan sumber daya manusia yang
cukup untuk membentuk sejumlah tim RAD yang baik.
RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen dalam
aktivitas rapid-fire untuk melaksanakan aktivitas melengkapi sistem dalam
kerangka waktu yang singkat. Jika komitmen tersebut tidak ada, proyek RAD
gagal.
Tidak semua aplikasi sesuai untuk RAD.bila system tidak dapat dimodulkan
dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat
problematic. RAD menjadi tidak sesuai jika risiko teknisnya tinggi.
9.
FOURTH GENERATION TECHNIQUES (4GT)
Istilah generasi ke empat, mengarah ke perangkat lunak yang umum yaitu tiap
pengembang perangkat lunak menentukan beberapa karakteristik perangkat lunak pada
level tinggi. Saat ini pengembangan perangkat lunak yang mendukung 4GT, berisi tooltool berikut :
i) Bahasa non prosedural untuk query basis data;
ii) Report generation;
iii) Data manipulation ;
iv) Interaksi layar ;
v) Kemampuan grafik level tinggi ;
vi) Kemampuan spreadsheet .
Tiap tool ini ada tapi hanya untuk sauatu aplikasi khusus.
Menggunakan perangkat bantu (tools) yang akan membuat kode sumber secara
otomatis berdasarkan spesifikasi dari pengembang perangkat lunak. Hanya digunakan
untuk menggunakan perangkat lunak yang menggunakan bahasa khusus atau notasi
grafik yang diselesaikan dengan syarat yang dimengerti pemakai.
Cakupan aktivitas 4GT :
1. Pengumpulan kebutuhan, idealnya pelanggan akan menjelaskan kebutuhan yang
akan ditranslasikan ke prototype operasional.
2. Translasi kebutuhan menjadi prototype operasional, atau langsung melakukan
implementasi secara langsung dengan menggunakan bahasa generasi keempat
(4GL) jika aplikasi relatif kecil.
3. Untuk aplikasi yang cukup besar, dibutuhkan strategi perancangan sistem
walaupun 4GL akan digunakan.
4. Pengujian.
5. Membuat dokumentasi
6. Melaksanakan seluruh aktivitas untuk mengintegrasikan solusi-solusi yang
membutuhkan paradigma rekayasa perangkat lunak lainnya.
Salah satu keuntungan penggunaan model 4GT adalah pengurangan waktu dan
peningkatan produktivitas secara besar, sementara kekurangannya terletak pada kesulitan
penggunaan perangkat bantu (tools) dibandingkan dengan bahsa pemrograman, dan juga
kode sumber yang dihasilkannya tidak efisien.
Untuk aplikasi yang yang kecil, adalah mungkin untuk langsung berpindah dari
pengumpulan kebutuhan ke implementasi dengan menggunakan 4GL. Tapi untuk aplikasi
yang besar, dibutuhkan pengembangan strategi desain untuk sistem, walau digunakan
4GL. Penggunaan 4GT tanpa perencanaan yang matang (untuk proyek skala besar) akan
meyebabkan kesulitan yang sama (kualitas dan pemeliharaan yang jelek, ketidakpuasan
pelanggan) seperti dengan metode konvensional.
10.
BERORIENTASI DATA
Sudut pandang pengembangan pada metode ini adalah struktur data daridokumen
masukan/keluaran yang digunakan dalam sistem. Tahap pelaksanaan pengembangannya pada
umumnya mengikuti urutan sebagai berikut:
1. Mengidentifikasi entitas-entitas atau item-item yang menjadi objek
informasi kunci berikut operasi-operasinya.
2. struktur informasi (dari dokumen) secara hirarki dengan menggunakan konstruksi
sequence , selection dan repetition
3. Memetakan hirarki struktur informasi menjadi struktur program.
Beberapa teknik pengembangan perangkat lunak berorientasi struktur data inidiantaranya adalah:
11.
Data Structured System Development (DSSD)
Diperkenalkan pertama kali oleh J.D. Warnier (1974) dan kemudianoleh Ken Orr (1977)
sehingga sering disebut juga teknik Warnier-Orr.Teknik ini menggunakan perangkat entity
diagram,assembly line diagram danWarnier-Orr diagram untuk memodelkan hasil
analisisdan perancangannya.
Jackson System Development (JSD)
Dikembangkan oleh M.A. Jackson (1975) dengan menggunakan perangkat pemodelan yang
disebut structure diagram dan system specification diagram
BERORIENTASI OBJEK
Berbeda dengan pendekatan-pendekatan sebelumnya, metode berorientasi objek memandang perangkat
lunak yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objekobjek dunia nyata. Padametode ini, informasi dan proses yang dipunyai oleh suatu objek
“dienkapsulasi” (dibungkus) dalam satu kesatuan. Gambar 2.9 berikut menunjukkan cara
pandang metode berorientasi objek dibandingkan dengan metode berorientasi fungsi.
Beberapa teknik pengembangan perangkat lunak yang berorientasi objek ini diantaranya adalah:
12.
Object Oriented Analysis (OOA) dan Object Oriented Design (OOD)dari Peter Coad dan Edward
Yourdon (1990).
Object Modeling Technique (OMT) dari James Rumbaugh, MichaelBlaha, William Premerlan,
Frederick Eddy dan William Lorensen(1991).
Object Oriented Software Engineering (OOSE) dari Ivar Jacobson(1992).
Metode Booch dari Grady Booch (1994).
Syntropy dari Steve Cook dan John Daniels (1994).
EXTREME PROGRAMMING (XP) Model
Model proses ini diciptakan dan dikembangkan oleh Kent Beck. Model ini adalah
model proses yang terbaru dalam dunia rekayasa perangkat lunak dan mencoba menjawab
kesulitan dalam pengembangan software yang rumit dan sulit dalam implementasi. Menurut
Kent Beck XP adalah : “A lightweight, efficient, low-risk, flexible,predictable, scientific and
fun way to develop software”.
Penerapan XP
Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia XP adalah
sebagai berikut:
1.
User harus memahami konteks bisnis yang akan dikembangkan sistemnya,
sehingga developer dapat menangkap sistem secara aplikatif dan dapat
mengusulkan teknologi apa yang dapat dikembangkan dalam sistem barunya.
2.
Akan lebih efektif apabila developer pernah menangani proyek pengembangan
sistem yang sejenis sehingga dapat memberikan usulan model sistem baru, di
samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut
untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada
kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template
yang sudah ada.
3.
Extreme programming menuntut komunikasi antar developer dan user secara
intensif dan komunikasi internal antar developer secara komprehensif, sehingga
akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal
yang mendukung proses komunikasi tersebut
4.
XP adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai
kemudahan, komunikasi, umpan balik, dan keberanian. Bekerja dalam whole
team bersama-sama dengan praktek yang mudah. Adapun inti penerapannya
adalah:
1. Planning Game
7. Pair programming
2. Small, frequent releases
8. Collective code
ownership
3. System metaphors
9. Continuous integration
4. Simple design
10. Sustainable pace
5. Testing (unit testing &
TDD)
11. Whole team together
6. Frequent refactoring
12. Coding standards
Keuntungan XP:
Menjalin komunikasi yang baik dengan client.
Meningkatkan komunikasi dan sifat saling menghargai antar developer.
Kerugian XP:
Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk
melakukan apa yang diperlukan hari itu juga).
13.
MODEL FORMAL
Model metode formal mencangkup sekumpulan aktivitas yang membawa kepada
spesifikasi matematis perangkat lunak computer. Metode ini memungkinkan perekayasa
perangkat lunak untuk mengkhususkan, mengembangkan, dan memverifikasi system berbasis
computer dengan menggunakan notasi matematis yang tepat.variasi dalam pendekatan ini,
disebut clean-room rekayasa perangkat lunak, sedang diaplikasikan oleh banyak organisasi
pengembang perangkat lunak.
Bila metode formal dipakai selama masa pengembangan, maka akan memberikan
mekanisme untuk mengeliminasi banyak masalah yang sulit dipecahkan menggunakan
paradigm perangkat lunak yang lain. Ambiguitas, ketidaklengkapan, dan ketidak-konsitenan
bisa ditemukan dan diperbaiki secara mudah, tidak melalui kajian ad hoc tetapi melalui
aplikasi analisis matematis. Jika metode ini dipakai selama proses perancangan, maka
berfungsi sebagai dasar bagi verifikasi program sehingga memungkinkan perekayasa untuk
menemukan dan memperbaiki kesalahan yang mungkin saja tidak terdeteksi.
Metode formal akan banyak memperoleh penganut diantara pengembang perangkat lunak
yang harus membangun perangkat lunak yang kritis untuk keselamatan (missal :
pengembangan perangkat medis, dan penerbangan pesawat), serta diantara yang harus
menderita karena faktor ekonomis yang harus dialami oleh perangkat lunak.
14.
RATIONAL UNIFIED PROCESS
RUP adalah proses pengembangan perangkat lunak berbasis UML (Unified Modeling
Language) yang mempunyai karakteristik:
1. Berulang (iterative)
Tahap pengembangan untuk setiap produk yang diserahkan (release)
dilaksanakan secara berulang.
2. Architecture centric
Menggunakan arsitektur sistem sebagai artifak utama untuk
konseptualisasi, konstruksi, pengelolaan, dan penyusunan system selama
pengembangan.
3. Use case-driven
Menggunakan use case sebagai artifak utama untuk menetapkan perilaku
sistem yang diinginkan dan untuk mengkomunikasikan perilaku sistem
tersebut kepada para stakeholder sistem.
4. Risk-driven
Menghilangkan atau mengurangi resiko-resiko yang dapat menghambat
kesuksesan proyek.
Sasaran RUP adalah menghasilkan perangkat lunak yang berkualitas tinggi,sesuai kebutuhan
pemakai, dengan jadwal dan biaya sesuai dengan yang direncanakan
Gambar 2.8 Model Proses Pengembangan dengan RUP(Sumber:www.rational.com)
Proses pengembangan pada RUP dinyatakan dalam dua dimensi, atau dua sumbu (lihat Gambar
2.8).
sumbu horizontal (sumbu x) merepresentasi waktu dan menunjukkan aspek dinamis dari proses,
yaitu siklus, tahap, iterasi, dan milestone.
sumbu vertikal (sumbu y) merepresentasikan aspek statis dari proses,yaitu aktivitas,
artifak, pelaksana kerja (worker) dan aliran kerja(workflow).
Tahap RUP
Berdasarkan Gambar 2.8, tahap (phases) pelaksanaan pengembangan pada RUP meliputi:
1. Permulaan (inception)
Tahap inception fokus pada penentuan manfaat perangkat lunak yang harus dihasilkan, penetapan
proses-proses bisnis (business case), dan perencanaan proyek.
2. Pemerincian (elaboration)
Tahap untuk menentukan use case(set of activities) dari perangkat lunak berikut rancangan
arsitekturnya.
3. Konstruksi (construction)
Membangun produk perangkat lunak secara lengkap yang siap diserahkan kepada pemakai.
4. Transisi (transition)
Menyerahkan perangkat lunak kepada pemakai, mengujinya ditempat pemakai, dan memperbaiki
masalah-masalah yang muncul saat dan setelah pengujian.
Ada dua jenis aliran kerja (workflow) pada RUP, yaitu aliran kerja utama dan aliran kerja
pendukung.
Aliran Kerja Utama
1. Pemodelan bisnis (business modeling)
Mendeskripsikan struktur dan proses-proses bisnis organisasi.
2. Kebutuhan (requirements)
Mendefinisikan kebutuhan perangkat lunak dengan menggunakan metode use case.
3. Analisis dan perancangan (analysis and design)
Mendeskripsikan berbagai arsitektur perangkat lunak dari berbagai sudut pandang.
4. Implementasi (implementation)
Menulis kode-kode program, menguji, dan mengintegrasikan unit-unit programnya.
5. Pengujian (testing)
Mendeskripsikan kasus uji, prosedur, dan alat ukur pengujian.
6. Deployment
Menangani konfigurasi sistem yang akan diserahkan.
Aliran Kerja Pendukung
1. Manajemen konfigurasi dan perubahan (configuration and change management)
Mengendalikan perubahan dan memelihara artifak-artifak proyek.
2. Manajemen proyek ( project management)
Mendeskripsikan berbagai strategi pekerjaan dengan proses yang berulang.
3. Lingkungan (environment)
Menangani infrastruktur yang dibutuhkan untuk mengembangkan sistem.
Sumber:
https://www.academia.edu/3695277/02-Rekayasa-Perangkat-Lunak-Material
http://rahmasholehah.blogspot.com/2013/03/model-pengembangan-perangkat-lunak.html
http://lsoumeru.mhs.uksw.edu/2012/11/metode-pengembangansistemsoftware1.html
http://resaseptiari05130.wordpress.com/2011/09/16/metode-perangkat-lunak/
http://ahsanjunior.blogspot.com/2011/12/extreme-programming-xp-model.html
NADIA ARIFI ANANDA
G.211.12.0137
AVIANTO NUGROHO
G.211.12.0139
ADITYA WISNU G.
G.211.12.0147
METODE PENGEMBANGAN PERANGKAT LUNAK
1.
MODEL LINEAR SEQUENTIAL/WATERFALL
Model Linear Sequential/Waterfall merupakan paradigma rekayasa perangkat lunak yang
paling tua dan paling banyak dipakai.
Kelebihan model Linear Sequential/Waterfall :
Mudah diaplikasikan
Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan
pemeliharaan
Cocok digunakan untuk produk software yang sudah jelas kebutuhannya di awal,
sehingga minim kesalahannya
Kekurangan model Linear Sequential/Waterfall :
Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen
harus dilakukan pada tahap awal proses
Sulit untuk mengalami perubahan kebutuhan yang diinginkan customer
Customer harus sabar untuk menanti produk selesai, karena dikerjakan tahap per
tahap,menyelesaikan tahap awal baru bisa ke tahap selanjutnya
Perubahan ditengah-tengah pengerjaan produk akan membuat bingung team work yang
sedang membuat produk
Adanya waktu menganggur bagi pengembang, karena harus menunggu anggota tim
proyek lainnya menuntaskan pekerjaannya
2.
MODEL PROSES PERANGKAT LUNAK EVOLUSIONER
Model evolusioner adalah model iterative, ditandai dengan tingkah laku yang
memungkinkan perekayasa perangkat lunak mengembangkan versi perangkat lunak yang
lebih lengkap sedikit demi sedikit. Kebutuhan produk dan bisnis kadang-kadang berubah
seiring dengan laju perkembanganya.
Dalam situasi tersebut maupun lainya, perekayasa perangkat lunak membutuhkan
sebuah model proses yang sudah dirancang secara eksplisit untuk mengakomodasi produk
perkembangan sepanjang waktu. Model ini bukan termasuk rekayasa perangkat lunak
klasik. Model evolusioner meliputi model increment, spiral, perkembangan konkruen dan
rakitan komponen.
3.
MODEL INCREMENT
Model incremental menggabungkan elemen-elemen model sekuensial linier
(diaplikasikan secara berulang) dengan filosofi prototype iterative. Model ini memakai
urutan-urutan linier di dalam model yang membingungkan, seiring dengan laju waktu
kalender. Setiap urutan linier menghasilkan pertambahan, perangkat lunak “yang bisa
disampaikan.” Contoh, perangkat lunak pengolah kata yang dikembangkan dengan
menggunakan paradigm pertambahan akan menyampaikan manajemen file, editing, serta
fungsi penghasilan dokumen pada pertambahan pertama, dan selanjutnya. Pertambahan
pertama dapat disebut sebagai produk inti (core product).
Model ini berfokus pada penyampaian produk operasional dalam Setiap
pertambahanya. Pertambahan awal ada di versi stripped down dari produk akhir, tetapi
memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk
evaluasi oleh pemakai.
Perkembangan pertambahan, khususnya berguna pada staffing, tidak bisa dilakukan
menggunakan implementasi lengkap oleh batas waktu bisnisyang sudah disepakati untuk
proyek tersebut. jika produk inti diterima dengan baik, maka staf tambahan bisa
ditambahkan untuk mengimplementasi pertambahan selanjutnya.
4.
MODEL SPIRAL
Awalnya diusulkan oleh Boehm (BOE88), adalah model proses perangkat lunak yang
evolusioner, merangkai sifat iterative dari prototype dengan cara control dan aspek
sistematis dari model sekuensial linier. Model yang berpotensi untuk pengembangan versi
pertambahan perangkat lunak secara cepat. Model spiral dibagi menjadi sejumlah
aktifitas kerangka kerja atau wilayah tugas, antara lain :
Komunikasi pelanggan, tugas-tugas yang dibutuhkan untuk membangun komunikasi
yang efektif diantara pengembang dan pelanggan.
Perencanaan, tugas-tugas yang dibutuhkan untuk mendefinisikan sumber-sumber
daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
Analisis resiko, tugas-tugas yang dibutuhkan untuk menaksir resiko-resiko, baik
manajemen maupun teknis.
Perekayasaan, tugas-tugas yang dibutuhkan untuk membangun satu atau lebih
representasi dari aplikasi tersebut.
Konstruksi dan peluncuran, tugas-tugas yang dibutuhkan untuk mengkonstruksi,
menguji, memasang (instal), dan memberikan pelayanan kepada pemakai (contohnya
pelatihan dan dokumentasi)
Evaluasi pelanggan, tugas-tugas untuk memperoleh umpan balik dari pelanggan
dengan didasarkan pada evaluasi representasi perangkat lunak, yang dibuat selama
masa perekayasaan, dan dimplementasikan selama masa pemasangan.
Model spiral menjadi pendekatan yang realistis bagi perkembangan system dan perangkat
lunak skala besar. Karena perangkat lunak terus bekerja selama proses bergerak,
pengembang dan pemakai memahami, dan bereaksi lebih baik terhadap resiko dari Setiap
tingkat evolusi. Model spiral menggunakan prototype sebagai mekanisme pengurangan
resiko.
Model spiral membutuhkan keahlian penafsiran resiko yang masuk akal, dan sangat
bertumpu pada keahlian ini untuk mencapai keberhasilan. Jika sebuah resiko tidak dapat
ditemukan dan diatur, pasti akan terjadi masalah. Model ini membutuhkan waktu
bertahun-tahun sampai kehandalannya bisa dipertimbangkan dengan kepastian absolute.
5.
COMPONENT ASSEMBLY MODEL (Model Perakitan Komponen)
Model ini merupakan gabungan dari berbagai sifat dan karakter dari model spiral
Boehm dan sangat erat keterikatannya dengan model RAD (Rapid Application
Development) model karena model CAM ini menggunakan peralatan-peralatan dan GUI
(Graphic User Interface) untuk membangun software. Dengan kata lain, pembuatan
aplikasinya dibuat dari paket perangkat lunak yang berisi serangkaian komponen yang
telah ada sebelumnya. Namun, waktu yang dibutuhkan dapat disesuaikan atau lebih
efektif ketimbang harus mengerjakan program dari awal.
Tahapan-tahapan Model ini adalah:
Tahap Identifikasi calon-calon komponen (kelas objek); Tahap melihat komponenkomponen dalam pustaka; Tahap mengekstrak komponen jika ada; Tahap membangun
komponen jika tidak ada; Tahap menyimpan komponen baru pada pustaka; Tahap
mengkonstruksi iterasi ke-n dari sistem.
Kelebihan model ini adalah tinggal mencaplok atau menggunakan program atau
komponen yang sudah ada dan menyusunnya menjadi sebuah program yang lebih
kompleks dan berkembang sesuai dengan kebutuhan user/pengguna sehingga dapat
mengefisienkan penggunaan waktu dan tenaga. Selain itu, model ini juga menyediakan
kemampuan untuk memvisualisasikan hasil rakitan dengan kesanggupan untuk
mengukur, menganalisa, merancang dan merancang ulang program.
Kekurangan model ini adalah seringnya program atau komponen-komponen terdahulu
tidak kompatibel atau sejalan dengan model perakitan komponen ini sehingga untuk
perusahaan berskala kecil akan kesulitan menemukan komponen yang sesuai untuk
dirakit.
Model ini sangat sesuai digunakan oleh perusahaan besar yang sudah berpengalaman
mengembangkan software. Mereka dapat memanfaatkan software-software yang telah
umum dikembangkan sebelumnya menjadi bentuk baru dari software yang ingin
dikomersilkan.
6.
THE CONCURRENT DEVELOPMENT MODEL
Model ini disebut juga dengan concurrent engineering yang dapat digambarkan secara
skematik sebagai serial dari kegiatan teknis utama, tugas-tugas, dan hubungan antar
bagian-bagian yang saling terkait di mana aktifitas analisa seperti desain/rancangan atau
komunikasi pelanggan dapat diskemakan dengan cara yang sama.
Concurrent process model cocok digunakan untuk pengembangan aplikasi client/server
yang terdiri atas satu set komponen yang fungsional. Terdapat dua dimensi aktivitas yang
digambarkan oleh model ini sebagai berikut.
Dimensi sistem: terdapat tiga proses di dalamnya yakni perancangan, perakitan
(assembly) dan penggunaan (use).
Dimensi komponen: terdapat dua kegiatan utama yaitu perancangan dan realisasi.
Concurrency (pertemuan) dapat diperoleh dengan dua cara: 1) sistem dan komponen
kegiatan (aktifitas) terjadi secara simultan dan dapat diperagakan dengan memanfaatkan
pendekatan yang berdasar pada status sebelumnya; 2) aplikasi client/server yang bersifat
unik/khas di mana dapat diterapkan pada banyak komponen yang tiap-tiap komponen
bisa dirancang dan direalisasikan secara serentak.
7.
MODEL PROTOTYPE
Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara
langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau komponenkomponen perangkat lunak akan bekerja dalam lingkungannya sebelum tahapan
konstruksi aktual dilakukan (Howard, 1997).
Beberapa model prototype adalah sebagai berikut :
Reusable prototype : Prototype yang akan ditransformasikan menjadi produk final.
Throwaway prototype : Prototype yang akan dibuang begitu selesai menjalankan
maksudnya.
Input/output prototype : Prototype yang terbatas pada antar muka pengguna (user
interface).
Processing prototype : Prototype yang meliputi perawatan file dasar dan prosesproses transaksi
System prototype : Prototype yang berupa model lengkap dari perangkat lunak.
Proses pada model prototyping adalah sebagai berikut:
1. pengumpulan kebutuhan
developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang
diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil
kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan
2. perancangan
perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang
diketahui, dan rancangan ini menjadi dasar pembuatan prototype.
3. Evaluasi prototype
klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas
kebutuhan software.
Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan
terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk
memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan
kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa
dimanfaatkan.
Skema dari prototype secara umum adalah sebagai berikut :
Konsep SDLC – Prototype
Pendekatan prototyping memiliki beberapa keuntungan yaitu:
Pemodelan membutuhkan partisipasi aktif dari end-user. Hal ini akan
meningkatkan sikap dan dukungan pengguna untuk pengerjaan proyek. Sikap
moral pengguna akan meningkat karena system berhubungan nyata dengan
mereka.
Perubahan dan iterasi merupakan konsekuensi alami dari pengembangan systemsehingga end user memiliki keinginan untuk merubah pola pikirnya. Prototyping
lebih baik menempatkan situasi alamiah ini karena mengasumsikan perubahan
model melalui iterasi kedalam system yang dibutuhkan.
Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat,
merasakan, dan mengalaminya.
Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini
Prototyping dapat meningkatkan kreatifitas karena membolehkan adanya feedback
dari end user. Hal ini akan memberikan solusi yang lebih baik.
Prototyping mempercepat beberapa fase hidup dari programmer.
Pendekatan prototyping memiliki beberapa kekurangan yaitu:
Prototyping memungkinkan terjadinya pengembalian terhadap kode, implementasi,
dan perbaikan siklus hidup yang dugunakan untuk mendominasi sistem informasi.
8.
Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya
dapat memecahkan masalah yang salah dan memberi kesempatan sebagai sistem
pengembangan konvensional.
Prototyping dapat mengurangi kreatifitas perancangan.
MODEL RAD (Rapid Application Development)
Merupakan model proses pengembangan perangkat lunak secara linear sequential
yang menekankan pada siklus pengembangan yang sangat singkat/pendek. Jika
kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan
menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek
(kira-kira 60-90 hari). Pendekatan RAD model menekankan cakupan :
a.
Pemodelan bisnis (Bussiness Modelling)
Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk
menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses
bisnis ? Kemana informasi itu pergi? Siapa yang memprosesnya ?
b. Pemodelan data (Data Modelling)
Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan bisnis disaring
ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut.
Karakteristik/atribut dari masing-masing objek diidentifikasi dan hubungan antara objekobjek tersebut didefinisikan.
c.
Pemodelan proses (Process Modelling)
Aliran informasi yang didefinisikan dalam fase pemodelan data 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. Pembuatan aplikasi (Application generation)
Selain menciftakan perangkat lunak dengan menggunakan bahasa pemrograman generasi
ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi
komponen program yang telah ada atau menciftakan komponen yang bias dipakai lagi.
Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi kontruksi
perangkat lunak.
e. Pengujian dan pergantian (Testing and turnover)
Karena proses RAD menekankan pada pemakaian kembali, banyak komponen yang telah
diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji.
Kelemahan model RAD :
Untuk proyek dengan skala besar, RAD membutuhkan sumber daya manusia yang
cukup untuk membentuk sejumlah tim RAD yang baik.
RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen dalam
aktivitas rapid-fire untuk melaksanakan aktivitas melengkapi sistem dalam
kerangka waktu yang singkat. Jika komitmen tersebut tidak ada, proyek RAD
gagal.
Tidak semua aplikasi sesuai untuk RAD.bila system tidak dapat dimodulkan
dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat
problematic. RAD menjadi tidak sesuai jika risiko teknisnya tinggi.
9.
FOURTH GENERATION TECHNIQUES (4GT)
Istilah generasi ke empat, mengarah ke perangkat lunak yang umum yaitu tiap
pengembang perangkat lunak menentukan beberapa karakteristik perangkat lunak pada
level tinggi. Saat ini pengembangan perangkat lunak yang mendukung 4GT, berisi tooltool berikut :
i) Bahasa non prosedural untuk query basis data;
ii) Report generation;
iii) Data manipulation ;
iv) Interaksi layar ;
v) Kemampuan grafik level tinggi ;
vi) Kemampuan spreadsheet .
Tiap tool ini ada tapi hanya untuk sauatu aplikasi khusus.
Menggunakan perangkat bantu (tools) yang akan membuat kode sumber secara
otomatis berdasarkan spesifikasi dari pengembang perangkat lunak. Hanya digunakan
untuk menggunakan perangkat lunak yang menggunakan bahasa khusus atau notasi
grafik yang diselesaikan dengan syarat yang dimengerti pemakai.
Cakupan aktivitas 4GT :
1. Pengumpulan kebutuhan, idealnya pelanggan akan menjelaskan kebutuhan yang
akan ditranslasikan ke prototype operasional.
2. Translasi kebutuhan menjadi prototype operasional, atau langsung melakukan
implementasi secara langsung dengan menggunakan bahasa generasi keempat
(4GL) jika aplikasi relatif kecil.
3. Untuk aplikasi yang cukup besar, dibutuhkan strategi perancangan sistem
walaupun 4GL akan digunakan.
4. Pengujian.
5. Membuat dokumentasi
6. Melaksanakan seluruh aktivitas untuk mengintegrasikan solusi-solusi yang
membutuhkan paradigma rekayasa perangkat lunak lainnya.
Salah satu keuntungan penggunaan model 4GT adalah pengurangan waktu dan
peningkatan produktivitas secara besar, sementara kekurangannya terletak pada kesulitan
penggunaan perangkat bantu (tools) dibandingkan dengan bahsa pemrograman, dan juga
kode sumber yang dihasilkannya tidak efisien.
Untuk aplikasi yang yang kecil, adalah mungkin untuk langsung berpindah dari
pengumpulan kebutuhan ke implementasi dengan menggunakan 4GL. Tapi untuk aplikasi
yang besar, dibutuhkan pengembangan strategi desain untuk sistem, walau digunakan
4GL. Penggunaan 4GT tanpa perencanaan yang matang (untuk proyek skala besar) akan
meyebabkan kesulitan yang sama (kualitas dan pemeliharaan yang jelek, ketidakpuasan
pelanggan) seperti dengan metode konvensional.
10.
BERORIENTASI DATA
Sudut pandang pengembangan pada metode ini adalah struktur data daridokumen
masukan/keluaran yang digunakan dalam sistem. Tahap pelaksanaan pengembangannya pada
umumnya mengikuti urutan sebagai berikut:
1. Mengidentifikasi entitas-entitas atau item-item yang menjadi objek
informasi kunci berikut operasi-operasinya.
2. struktur informasi (dari dokumen) secara hirarki dengan menggunakan konstruksi
sequence , selection dan repetition
3. Memetakan hirarki struktur informasi menjadi struktur program.
Beberapa teknik pengembangan perangkat lunak berorientasi struktur data inidiantaranya adalah:
11.
Data Structured System Development (DSSD)
Diperkenalkan pertama kali oleh J.D. Warnier (1974) dan kemudianoleh Ken Orr (1977)
sehingga sering disebut juga teknik Warnier-Orr.Teknik ini menggunakan perangkat entity
diagram,assembly line diagram danWarnier-Orr diagram untuk memodelkan hasil
analisisdan perancangannya.
Jackson System Development (JSD)
Dikembangkan oleh M.A. Jackson (1975) dengan menggunakan perangkat pemodelan yang
disebut structure diagram dan system specification diagram
BERORIENTASI OBJEK
Berbeda dengan pendekatan-pendekatan sebelumnya, metode berorientasi objek memandang perangkat
lunak yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objekobjek dunia nyata. Padametode ini, informasi dan proses yang dipunyai oleh suatu objek
“dienkapsulasi” (dibungkus) dalam satu kesatuan. Gambar 2.9 berikut menunjukkan cara
pandang metode berorientasi objek dibandingkan dengan metode berorientasi fungsi.
Beberapa teknik pengembangan perangkat lunak yang berorientasi objek ini diantaranya adalah:
12.
Object Oriented Analysis (OOA) dan Object Oriented Design (OOD)dari Peter Coad dan Edward
Yourdon (1990).
Object Modeling Technique (OMT) dari James Rumbaugh, MichaelBlaha, William Premerlan,
Frederick Eddy dan William Lorensen(1991).
Object Oriented Software Engineering (OOSE) dari Ivar Jacobson(1992).
Metode Booch dari Grady Booch (1994).
Syntropy dari Steve Cook dan John Daniels (1994).
EXTREME PROGRAMMING (XP) Model
Model proses ini diciptakan dan dikembangkan oleh Kent Beck. Model ini adalah
model proses yang terbaru dalam dunia rekayasa perangkat lunak dan mencoba menjawab
kesulitan dalam pengembangan software yang rumit dan sulit dalam implementasi. Menurut
Kent Beck XP adalah : “A lightweight, efficient, low-risk, flexible,predictable, scientific and
fun way to develop software”.
Penerapan XP
Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia XP adalah
sebagai berikut:
1.
User harus memahami konteks bisnis yang akan dikembangkan sistemnya,
sehingga developer dapat menangkap sistem secara aplikatif dan dapat
mengusulkan teknologi apa yang dapat dikembangkan dalam sistem barunya.
2.
Akan lebih efektif apabila developer pernah menangani proyek pengembangan
sistem yang sejenis sehingga dapat memberikan usulan model sistem baru, di
samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut
untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada
kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template
yang sudah ada.
3.
Extreme programming menuntut komunikasi antar developer dan user secara
intensif dan komunikasi internal antar developer secara komprehensif, sehingga
akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal
yang mendukung proses komunikasi tersebut
4.
XP adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai
kemudahan, komunikasi, umpan balik, dan keberanian. Bekerja dalam whole
team bersama-sama dengan praktek yang mudah. Adapun inti penerapannya
adalah:
1. Planning Game
7. Pair programming
2. Small, frequent releases
8. Collective code
ownership
3. System metaphors
9. Continuous integration
4. Simple design
10. Sustainable pace
5. Testing (unit testing &
TDD)
11. Whole team together
6. Frequent refactoring
12. Coding standards
Keuntungan XP:
Menjalin komunikasi yang baik dengan client.
Meningkatkan komunikasi dan sifat saling menghargai antar developer.
Kerugian XP:
Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk
melakukan apa yang diperlukan hari itu juga).
13.
MODEL FORMAL
Model metode formal mencangkup sekumpulan aktivitas yang membawa kepada
spesifikasi matematis perangkat lunak computer. Metode ini memungkinkan perekayasa
perangkat lunak untuk mengkhususkan, mengembangkan, dan memverifikasi system berbasis
computer dengan menggunakan notasi matematis yang tepat.variasi dalam pendekatan ini,
disebut clean-room rekayasa perangkat lunak, sedang diaplikasikan oleh banyak organisasi
pengembang perangkat lunak.
Bila metode formal dipakai selama masa pengembangan, maka akan memberikan
mekanisme untuk mengeliminasi banyak masalah yang sulit dipecahkan menggunakan
paradigm perangkat lunak yang lain. Ambiguitas, ketidaklengkapan, dan ketidak-konsitenan
bisa ditemukan dan diperbaiki secara mudah, tidak melalui kajian ad hoc tetapi melalui
aplikasi analisis matematis. Jika metode ini dipakai selama proses perancangan, maka
berfungsi sebagai dasar bagi verifikasi program sehingga memungkinkan perekayasa untuk
menemukan dan memperbaiki kesalahan yang mungkin saja tidak terdeteksi.
Metode formal akan banyak memperoleh penganut diantara pengembang perangkat lunak
yang harus membangun perangkat lunak yang kritis untuk keselamatan (missal :
pengembangan perangkat medis, dan penerbangan pesawat), serta diantara yang harus
menderita karena faktor ekonomis yang harus dialami oleh perangkat lunak.
14.
RATIONAL UNIFIED PROCESS
RUP adalah proses pengembangan perangkat lunak berbasis UML (Unified Modeling
Language) yang mempunyai karakteristik:
1. Berulang (iterative)
Tahap pengembangan untuk setiap produk yang diserahkan (release)
dilaksanakan secara berulang.
2. Architecture centric
Menggunakan arsitektur sistem sebagai artifak utama untuk
konseptualisasi, konstruksi, pengelolaan, dan penyusunan system selama
pengembangan.
3. Use case-driven
Menggunakan use case sebagai artifak utama untuk menetapkan perilaku
sistem yang diinginkan dan untuk mengkomunikasikan perilaku sistem
tersebut kepada para stakeholder sistem.
4. Risk-driven
Menghilangkan atau mengurangi resiko-resiko yang dapat menghambat
kesuksesan proyek.
Sasaran RUP adalah menghasilkan perangkat lunak yang berkualitas tinggi,sesuai kebutuhan
pemakai, dengan jadwal dan biaya sesuai dengan yang direncanakan
Gambar 2.8 Model Proses Pengembangan dengan RUP(Sumber:www.rational.com)
Proses pengembangan pada RUP dinyatakan dalam dua dimensi, atau dua sumbu (lihat Gambar
2.8).
sumbu horizontal (sumbu x) merepresentasi waktu dan menunjukkan aspek dinamis dari proses,
yaitu siklus, tahap, iterasi, dan milestone.
sumbu vertikal (sumbu y) merepresentasikan aspek statis dari proses,yaitu aktivitas,
artifak, pelaksana kerja (worker) dan aliran kerja(workflow).
Tahap RUP
Berdasarkan Gambar 2.8, tahap (phases) pelaksanaan pengembangan pada RUP meliputi:
1. Permulaan (inception)
Tahap inception fokus pada penentuan manfaat perangkat lunak yang harus dihasilkan, penetapan
proses-proses bisnis (business case), dan perencanaan proyek.
2. Pemerincian (elaboration)
Tahap untuk menentukan use case(set of activities) dari perangkat lunak berikut rancangan
arsitekturnya.
3. Konstruksi (construction)
Membangun produk perangkat lunak secara lengkap yang siap diserahkan kepada pemakai.
4. Transisi (transition)
Menyerahkan perangkat lunak kepada pemakai, mengujinya ditempat pemakai, dan memperbaiki
masalah-masalah yang muncul saat dan setelah pengujian.
Ada dua jenis aliran kerja (workflow) pada RUP, yaitu aliran kerja utama dan aliran kerja
pendukung.
Aliran Kerja Utama
1. Pemodelan bisnis (business modeling)
Mendeskripsikan struktur dan proses-proses bisnis organisasi.
2. Kebutuhan (requirements)
Mendefinisikan kebutuhan perangkat lunak dengan menggunakan metode use case.
3. Analisis dan perancangan (analysis and design)
Mendeskripsikan berbagai arsitektur perangkat lunak dari berbagai sudut pandang.
4. Implementasi (implementation)
Menulis kode-kode program, menguji, dan mengintegrasikan unit-unit programnya.
5. Pengujian (testing)
Mendeskripsikan kasus uji, prosedur, dan alat ukur pengujian.
6. Deployment
Menangani konfigurasi sistem yang akan diserahkan.
Aliran Kerja Pendukung
1. Manajemen konfigurasi dan perubahan (configuration and change management)
Mengendalikan perubahan dan memelihara artifak-artifak proyek.
2. Manajemen proyek ( project management)
Mendeskripsikan berbagai strategi pekerjaan dengan proses yang berulang.
3. Lingkungan (environment)
Menangani infrastruktur yang dibutuhkan untuk mengembangkan sistem.
Sumber:
https://www.academia.edu/3695277/02-Rekayasa-Perangkat-Lunak-Material
http://rahmasholehah.blogspot.com/2013/03/model-pengembangan-perangkat-lunak.html
http://lsoumeru.mhs.uksw.edu/2012/11/metode-pengembangansistemsoftware1.html
http://resaseptiari05130.wordpress.com/2011/09/16/metode-perangkat-lunak/
http://ahsanjunior.blogspot.com/2011/12/extreme-programming-xp-model.html