Model Proses Pengembangan PL Spiral dan Incremental

MODEL PROSES PENGEMBANGAN PERANGKAT LUNAK

A.    Spiral

1. Pengertian

1)      Evolutionary proses (pengembangan bertingkat)

2)      Menggabungkan keunggulan waterfall dan prototyping

3)      Perangkat lunak dibangun dengan serangkaian proses pelepasan evolusi.

4)      Pengembang dan pemakai dapat memahami resiko dan bereaksi atas resiko.

2. Tahapan Spiral

1)      Customer Communication

Merupakan Proses penerapan komunikasi antara user dengan developer

2)      Planning

Merupakan tahapan menentukan tujuan, alternatif, batasan sistem, penentuan kebutuhan awal, resource, time line, dll  dilanjutkan dengan hasil evaluasi user

3)      Risk Analysis

Merupakan tahapan analisa resiko, identifikasi resiko baik teknis maupun manajerial dan penanganan resiko

4)      Engineering

Merupakan tahapan pengembangan produk  dimulai dengan prototipe awal sampai akhirnya menjadi produk-jadi

5)      Construction & Release

Merupakan tahap konstruksi, test, install & penyiapan user support (dokumentasi)

6)      Customer Evaluation

Merupakan tahapan penilaian hasil pengembangan produk oleh user  pada tahap pengembangan maupun tahap instalasi

3. Kelebihan Spiral

1)      Pengguna dan developer bisa memahami dengan baik software yang dibangun karena progress dapat diamati dengan baik.

2)      Estimasi menjadi lebih realistik seiring berjalannya proyek karena masalah ditemukan sesegera mungkin.

3)      Lebih mampu menangani perubahan yang sering terjadi pada software development.

4)      Software engineers bisa bekerja lebih cepat pada proyek.

4. Kelemahan Spiral

1)      Membutuhkan waktu yang lama.

2)      Membutuhkan dana yang besar.

3)      Membutuhkan planning jangka panjang yang baik agar program bisa selesai dengan baik.

B.     Incremental

•         Menggabungkan model waterfall dan prototyping

•         Menerapkan pengembangan perangkat lunak secara per bagian hingga menghasilkan perangkat lunak yang lengkap

•         Proses pengembangan berhenti  jika produk telah mencapai keseluruhan fungsi yang diharapkan.

•         Tepat digunakan pada saat ketersediaan sumber daya tidak mencukupi untuk men’deliver’ produk yang lengkap dalam waktu tertentu.

•         Model incremental sangat membantu dalam mengatasi resiko teknis seperti terbatasnya ketersediaan hardware.

Perbedaan Spiral – Incremental

Pada Spiral, proses penambahan dilakukan dengan menggunakan prototype yang terkontrol dan sistematik, Penambahan memperhatikan analisis risiko terhadap tahap-tahap yang telah dilalui sedangkan pada Incremental, proses perancangan dilakukan berurutan dari proses analisis hingga pengetesan pada setiap penambahan hal-hal baru, Proses penambahan dilakukan dengan bertahap secara terencana.

Model Proses Pengembangan PL Extreme Programming, Rational Unified Process, Opportunistic Approach

MODEL PROSES PENGEMBANGAN PERANGKAT LUNAK

A.     Extreme Programming

Extreme Programming dikembangkan oleh Kent Beck, menekankan pada komunikasi, kesederhanaan feedback dan di atas semuanya feedback pelanggan termasuk “lightweight methods”

Extreme Programming dipakai saat :

1. Keperluan berubah dengan cepat
2. Resiko tinggi, proyek dengan tantangan baru
3. Kelompok kecil programer (antara 2-10)
4. Mampu mengotomatiskan tes
5. Peran serta pelanggan secara langsung dimungkinkan

Variabel Extreme Programming

1. Cost

Dengan meningkatkan biaya kita bisa menciptakan program yang lebih baik sebaliknya mengurangi budget untuk proyek tidak akan bisa memecahkan masalah customer akan tetapi biaya yang tak terbatas (infinite cost) juga bisa merusak. 

2. Time

Dengan meningkatkan waktu maka kita akan bisa menciptakan suatu program yang berkualitas dan dengan feature-feature yang lebih banyak akan tetapi jika waktu yang terlalu berlebihan tidak baik karena bisa merusak terhadap diri sendiri. 

Waktu yang terlalu sedikit juga tidak baik karena kualitas yang dihasilkan akan sangat jauh dari yang diharapkan. 

3. Quality

Mutu merupakan suatu variable pengendali yang sangat “mengerikan” karena merupakan sesuatu hal yang sangat diperhatikan konsumer. 

4. Scope

Scope merupakan variable primer. Jika kita mengurangi Scope, maka maka kita bisa mengurangi dan biaya serta meningkatkan kualitas.

Nilai dasar Extreme Programming

1. Communication (Komunikasi)

Komunikasi dalam Extreme Programming dibangun dengan melakukan pemrograman berpasangan (pair programming). 

Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Tujuannya untuk memberikan pandangan pengembang sesuai dengan pandangan pengguna sistem.

2. Simplicity (Kesederhanaan)

Extreme Programming mencoba untuk mencari solusi paling sederhana dan praktis. 

Perbedaan metode ini dengan metodologi pengembangan sistem konvensional lainnya terletak pada proses desain dan coding yang terfokus pada kebutuhan saat ini daripada kebutuhan besok, seminggu lagi atau sebulan lagi. Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan.

3. Feedback (Masukan)

Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dari aplikasi yang dibangun. Ini dimaksudkan agar hal-hal yang menjadi masalah dalam proses pengembangan dapat diketahui sedini mungkin. 

Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena  biaya akan membengkak (uang, tenaga, waktu).

4. Courage (Keberanian)

Para anggota tim dan penanggungjawab pengembangan perangkat lunak harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. 

Untuk dapat melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh Extreme Programmingpada berbagai aspeknya. 

5. Quality Work 

Semua nilai di atas berujung pada sebuah kondisi di mana kita melakukan pekerjaan dengan berkualitas. Dengan proses yang berkualitas maka implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai hasil akhirnya.

Aspek Dasar Extreme Programming

•         The Planning Game

Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut.

•         Simple Design

Pada Extreme Programming desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil.

•         Pair Programming

Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program.

•         40 hours week

Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan.lebih cepat lagi.

•         Coding Standard

Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim.

•         Testing

Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. 

•       Metaphor

Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor. 

•         Small Frequent Release

Setiap release dilakukan dalam lingkup sekecil mungkin pada Extreme Programming. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien.

•         Refactoring

Refactoring adalah salah satu aspek paling khas dari Extreme Programming. Refactoring seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja”. 

•         Collective Ownership

Extreme Programming menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya. 

•         Continous Integration

Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada Extreme Programming hal tersebut adalah maksimum. Pada Extreme Programming tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi. 

•         On Site Customer

Sebuah pendekatan klasik, di mana Extreme Programming menganjurkan bahwa ada anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera memberikan masukan untuk koreksinya.

B.     Rational Unified Process

Ciri utama metode ini adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus pengembangan perankat lunak. 

Rational Unified Process menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language(UML). 

1. Dimensi Horizontal

Mewakili aspek-aspek dinamis dari pengembangan Perangkat Lunak. 

Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir dari awal dari phase selanjutnya. 

2. Dimensi Vertikal 

Mewakili aspek-aspek statis  dari pengembangan Perangkat Lunak yang dikelompokkan kedalam beberapa disiplin. 

            

Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing, what, how dan when

Fase Rational Unified Process

1. Inception

Merupakan fase yang menentukan Ruang lingkup proyek, membuat ‘Business Case’, menjawab pertanyaan “apakah yang dikerjakan dapat menciptakan ‘good business sense’ sehingga proyek dapat dilanjutkan

2. Elaboration

Merupakan fase yang menganalisa berbagai persyaratan dan resiko, menetapkan ‘base line’, merencanakan fase berikutnya yaitu construction 

3. Construction

Merupakan fase yang melakukan sederetan iterasi pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan testing

4. Transition

Merupakan fase membuat apa yang sudah dimodelkan menjadi suatu produk jadi, Dalam fase ini dilakukan:

a)      Beta dan performance testing

b)      Membuat dokumentasi tambahan seperti; training, user guides dan sales kit

c)      Membuat rencana peluncuran produk ke komunitas pengguna

C.    Opportunistic Approach

Peningkatan permintaan pengguna dan biaya yang mendorong industri pengembangan perangkat lunak Komposisi sistem baru dari komponen perangkat lunak tersedia, termasuk sistem lain.

Sistem oportunistik tidak terdiri dari rapi dirancang buah software homogen dengan batas-batas yang jelas dan juga dijelaskan fungsi.

Dalam pendekatan ini, hanya sedikit aturan yang ada untuk:

1.       Desain

2.       Konstruksi

3.      Proses manajemen