Systems Development Life Cycle

Systems Development Life Cycle

April 16, 2017
 WATERFALL




 


Model Sekuensial Linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan system seluruh analisis, desain, kkode, pengujian, dan pemeliharan. Dimodelkan setelah siklus rekayasa konvensional, model skuensial linier melingkupi aktivitas-aktivitas sebagai berikut :

  • Rekayasa dan Pemodelan Sistem / Informasi
    Karena perangkat lunak selalu merupakan bagian membangun dari sebuah system (bisbis) yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen system dan mengalokasi beberapa subset dari kebutuhan perangkat lunak tersebut. Pandangan system ini penting ketika perangkat lunak harus berhubungan dengan elemen-elemen lain seperti perangkat lunak, manusia, dan database. Rekayasa dan analisis system menyangkut pengumpulan kebutuhan pada tingkat system dengan sejumlah kecil analisis serta desain tingkat puncak. Rekayasa informasi mencakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.
  • Analisis Kebutuhan Perangkat Lunak
    Proses pengumpulan perangkat diintensifkan dan difokuskan, khusunya pada perangkat lunak. Untuk memahami sifat program yang dibangun, perekayasa perangkat lunak (analis) harus memahami domain informasi, tingkah laku, untuk kerja, dan antar muka (interface) yang diperlukan. Kebutuhan baik system maupun perangkat lunak didokumentasikan dan dilihat lagi dengan pelanggan.
  • Desain
    Desain perangkat lunak sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda: struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) procedural. Proses desain menterjemahkan syarat / kebutuhan ke dalam sebuah representasi perangkat lunak yang dapat diperkirakan demi kualitas sebelumpemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi perangkat lunak.
  • Generasi Kode
    Desain harus diterjemahkan ke dalam bentuk mesin yang bias dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat dilakukan dengan cara mekanis.
  • Pengujian
    Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal perangkat lunak, memastikan bahwa semua pernyataan sudah diuji, pada eksternal fungsional yaitu mengarahkan pengujian untuk menemukan kesalah-kesalahan dan memastikan bahwa input yang dibatasi akan memberikan hasil yang aktual yang sesuai dengan hasil yang dibuthkan.
  • Pemeliharaan
    Perangkat lunak akan mengalami perubahan setelah disampaikan pada pelanggan (perkecualian yang mungkin adalah perangkat lunak yang dilekatkan). Perubahan akan terjadi karena kesalahan-kesalahan ditentukan, karena perangkat lunak harus disesuaikan untuk mengakomodasi perubahan-perubahan didalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau system operasi yang baru), atau karena pelanggan membutuhkan perkembangan untuk perkembangan fungsional atau untuk kerja. Pemeliharaan perangkat lunak mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi.
Model sekuen linier ini adalah paradigma rekayasa perangkat lunak yang paling luas dipakai dan yang paling tua. Tetapi kritik dari paradigma tersebut telah menyebabkan dukungan aktif untuk mempertanyakan kehandalannya [HAN95]. Masalah-masalah yang kadang-kadang terjadi ketika model sekuensial linier di aplikasikan adalah :
  1. Jarang sekali proyek nyata mengikuti aliran sekuensia yang dianjurkan oleh model. Meskipun model linier bias mengakomodasi iterasi, model itu melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan-perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.
  2. Kadang-kadang sulit bagi pelanggan untuk menyatakan semua kebbutuhannya secara eksplisit. Model linier sekuensial memerlukan hal ini dan mengalami kesulitan untuk mengakomodasi ketidakpastian natural yang ada pada bagian awal beberapa proyek.
  3. Pelanggan harus bersikap sabar. Sebuah versi kerja dari program-program itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika terdekteksi sampai program yang bekerja tersebut dikaji ulang bisa menjadi petaka.
  4. Pengembang sering melakukan penundaan yang tidak perlu. Di dalam analisis yang menarik tentang proyek actual, Bradac [BRA94] mendapatkan bahwa sifat alami dari siklus kehidupan klasik membawa kepada blocking state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling ketergantungan. Kenyataannya, waktu yang dipakai untuk menunggu bisa mengurangi waktu usaha produktif !. blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier. 

Kelebihan dari Waterfall
  • Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.
  • Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan pemeliharaan. 
  • Cocok digunakan untuk produk software yang sudah jelas kebutuhannya di awal, sehingga minim kesalahannya. 
  • Cocok untuk system software berskala besar dan bersifat generik. 
  • Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol. 
  • Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. setiap fase atau tahapan akan mempunyai dokumen tertentu.
  • Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.
Kekurangan dari Waterfall
  • Diperlukanya sebuah management proyek yang baik karena sangat berpengaruh 
  • Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses. 
  • Customer harus sabar untuk menanti produk selesai, karena dikerjakan tahap pertahap, menyelesaikan tahap awal baru bisa ke tahap selanjutnya. 
  • Sulit untuk mengadaptasi jika terjadi perubahan spesifikasi pada suatu tahapan pengembangan. 
  • 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.

    Model Prototyping


    Metode prototyping adalah sistem informasi yang menggambarkan hal-hal penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu.


    Proses pada model prototyping yang dapat dijelaskan sebagai berikut:
    • User Requirements
      Pada tahap ini developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan pada tahap ini.
    • Develope Prototype
      Pada tahap ini dilakukan perancangan prototype sistem oleh developer, perancangan sistem dilakukan secara cepat dan rancangan diusahakan mewakili semua aspek software yang telah diketahui.
    • Revise Prototype
      Pada tahap ini dilakukan evaluasi prototype sistem oleh klien. Apabila klien merasa prototype sistem yang telah dikembangkan sesuai dengan keinginannya maka prototype tersebut dapat digunakan, akan tetapi jika prototype tersebut tidak sesuai, maka prototype tersebut akan dilakukan revisi dan digunakan sebagai acuan dalam memperjelas kebutuhan software dan kemudian dikembangkan prototype selanjutnya. Siklus ini (develop-revise prototype) akan terus berlangsung hingga didapatkan prototype sistem yang sesuai dengan kebutuhan klien atau user.


    Keunggulan dan kelemahan pada pengembangan software menggunakan metode prototyping.

    Keunggulan:

    • Meningkatnya komunikasi antara user dan developer
    • Peningkatan peran aktif user didalam proses pengembangan
    • Peningkatan efisiensi waktu
    • Implementasi sistem menjadi lebih mudah karena user turut berperan aktif didalam proses pengembangan

    Kelemahan:

    • Kurangnya fitur keamanan dan kontrol pada prototype akhir sistem
    • Sistem akan sulit terbentuk jika proses evaluasi pada siklus prototype tidak mendapatkan titik temu.
    • Dapat menyebabkan dokumentasi akhir yang tidak lengkap
    • Developer lebih sulit mengendalikan ekspektasi user

Model Spiral

 



Model spiral pada awalnya diusulkan oleh Boehm, adalah model proses perangkat lunak evolusioner yang merangkai sifat iteratif dari prototype dengan cara kontrol dan aspek sistematis model sequensial linier. Model iteratif ditandai dengan tingkah laku yang memungkinkan pengembangmengembangkan versi perangkat lunak yang lebih lengkap secara bertahap. Perangkat lunak dikembangkan dalam deretan pertambahan. Selama awal iterasi, rilis inkremantal bisaberupa model/prototype kertas, kemudian sedikit demi sedikit dihasilkan versi sistem yanglebih lengkap.


Tahapan-Tahapan Model Spiral

Model spiral dibagi menjadi enam wilayah tugas yaitu:
  1. Komunikasi pelanggan
    Yaitu tugas-tugas untuk membangun komunikasi antara pelanggan dan kebutuhankebutuhan yang diinginkan oleh pelanggan.
  2. Perencanaan
    Yaitu tugas-tugas untuk mendefinisikan sumber daya, ketepatan waktu, dan proyek informasi lain yg berhubungan.
  3. Analisis Resiko
    Yaitu tugas-tugas yang dibutuhkan untuk menaksir resikomanajemen dan teknis.
  4. Perekayasaan
    Yaitu tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari apikasi tersebut.
  5. Konstruksi dan peluncuran
    Yaitu tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang , dan memberi pelayanan kepada pemakai.
  6. Evaluasi Pelanggan
    Yaitu tugas-tugas untuk mendapatkan umpan balik dari pelanggan.
Kelebihan dan Kelemahan Model Spiral
 
Kelebihan model Spiral :
  • Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.
  • Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar.
  • Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadapresiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .
  • Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiapkeadaan di dalam evolusi produk.
  • Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya ke dalam kerangka kerja iteratif.
  • Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko sebelum menjadi permaslahan yang serius.
Kelemahan model Spiral:
  • Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.
  • Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur.
  • Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolutD.


Rapid Aplication Model

 




Rapid Aplication Development (RAD) adalah sebuah metode pengembangan software yang diciptakan untuk menekan waktu yang dibutuhkan untuk mendesain serta mengimplementasikan sistem, informasi sehingga dihasilkan siklus pengembangan yang sangat pendek.

Model RAD ini merupakan adaptasi dari model sekuensial linier dimana perkembangan yang cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Sehingga, jika kebutuhan sistem dipahami dengan baik, proses RAD memungkinkan developer menciptakan sistem fungsional yang utuh dalam periode waktu yang sangat pendek (± 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD meliputi fase – fase dibawah ini:

Bussiness Modeling
Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan sebagai berikut :
  • Informasi apa yang mengendalikan proses bisnis?
  • Informasi apa yang di munculkan?
  • Siapa yang memunculkanya?
  • Ke mana informasi itu pergi? Siapa yang memprosesnya?
Data Modeling
Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan.

Prosess Modeling
Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.

Aplication Generation
RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memkai lagi komponen program yang ada (pada saat memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

Testing and Turnover
Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh.

Kelebihan Penggunaan Model RAD
  • Dimungkinkan dalam proses pembuatan membutuhkan waktu yang sangat singkat (60-90 hari).
  • Menghemat biaya, karena penekannya adalah penggunaan komponen-komponen yang sudah ada.
  • RAD menggunakan kembali komponen-komponen yang sudah ada, maka beberapa komponen program sudah diuji sehingga kita dapat melakukan penghematan waktu dalam uji coba

Kekurangan Penggunaan Model RAD
  • Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
  • RAD menuntut pengembangan dan pelanggan yang memiliki komitmen di dalam aktifitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal. RAD menekankan perkembangan komponen program yang bisa dipakai kembali. Reusable menjadi batu pertama teknologi objek dan ditemui di dalam proses rakitan komponen
  • Tidak semua aplikasi sesuai untuk RAD. Bila sistem tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematis.
  • RAD menjadi tidak sesuai jika risiko teknisnya tinggi. Hal ini terjadi bila sebuah aplikasi baru memforsir teknologi baru atau bila perangkat lunak baru membutuhkan tingkat interoperabilitas yang tinggi dengan program komputer yang ada.

Rational Unified Process






RUP, singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan mereka.

RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language(UML). Melalui gambar dibawah dapat dilihat bahwa RUP memiliki, yaitu: dimensi pertama di gambarkan secara horizontal. Dimensi ini mewakili aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestoneyang menandakan akhir dari awal dari phase selanjutnya. Setiap phase dapat berdiri dari satu beberapa iterasi. Dimensi ini terdiri atas Inception, Elaboration, Construction, dan Transition. Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing, what, howdan when.

Dimensi ini terdiri atas:

Business Modeling, Requirement, Analysis and Design, Implementation, Test, Deployment, Configuration dan Change Manegement, Project Management, Environtment. Pada penggunaan kedua standard tersebut diatas yang berorientasi obyek (Object Oriented) memiliki menfaat yakni:

  • Improve productivity
    Standard ini dapat memanfaatkan kembali komponen-komponen yang telah tersedia/dibuat sehingga dapat meningkatkan produktifitas.
  • Deliver hight quality system
    Kualitas sistem dapat informasi dapat ditingkatkan sebagai sistem yang telah dibuat pada komponen-komponen yang telah teruji (well -tested dan well -proven) sehingga dapat mempercepat delivery sistem informasi yang telah dibuat dengan kualitas yang tinggi.
  • Lower maintenance cost
    Standard ini dapat membantu untuk meyakinkan dampak perubahan yang teralokasi dan masalah dapat dengan mudah terdeteksi sehingga hasilnya biaya pemeliharaan dapat dioptimalkan atau lebih rendah dengan pengembangan informasi tanpa standar yang jelas.
  • Facilitate reuse
    Standard ini memiliki kamampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk pengembangan aplikasi yang lainnya.
  • Manage complexity
    Standard ini mudah untuk mengatur dan monitor semua proses dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang amat kompleks dapat dilakukan dengan aman sesuai dengan harapan semua manager proyek IT/IS yakni deliver good quality software within cost and schedule time and the users accepted.

Fase RUP
Inception/insepsi
  • Menentukan Ruang lingkup proyek
  • Membuat 'Business Case'
  • Menjawab pertanyaan 'apakah yang dikerjakan dapat menciptakan 'good business sense' sehingga proyek dapat dilanjutkan
Elaboration/elaborasi
  • Menganalisa berbagai persyaratan dan resiko
  • Menetapkan 'Base line'
  • Merencanakan fase berikutnya yaitu construction
Construction/kontruksi
  • Melakukan sederetan iterasi
  • Pada setiap iterasi akan melibatkan prose berikut : analisa desain, implementasi dan testing
Transition/Transisi
Membuat apa yang sudah dimodelkan menjadi suatu produk jadi

Dalam fase ini dilakukan:
  • Beta dan performance testing
  • Membuat dokumentasi tambahan seperti: training, user guide dan sales kit
  • Membuat rencana peluncuran produk ke komunitas pengguna
  • Peran Use Case Pada Setiap Fase
Inception
  • Menolong mengembangkan scope proyek
  • Menolong menetapkan penjadwalan dan anggaran


Kelebihan dan Kekurangan dalam Rational Unified Proccess

Keuntungan Pengembangan Perangkat Lunak RUP :
  • Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
  • Menyediakan petunjuk bagaimana menggunakan UML secara efektif
  • Mendukung proses pengulangan dalam pengembangan software
  • Memungkinkan adanya penambahan-penambahan pada proses
  • Memungkinkan untuk secara sistematis mengontrol perubahan- perubahan yangterjadi pada software selama proses pengembangannya
  • Memungkinkan untuk menjalankan test case dengan menggunakan Rational TestManager Tool
Kekurangan Pengembangan Perangkat Lunak RUP :
  • Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak yangberorientasi objek dengan berfokus pada UML (Unified Modeling Language) 

Extreme Program







Extreme Programming (XP) merupakan salah satu metodologi dalam rekayasa perangkat lunak dan juga merupakan satu dari beberapa agile software development methotodogies yang berfokus pada coding sebagai aktivitas utama di semua tahap pada siklus pengembangan yang lebih responsive terhadap kebutuhan costumer (“agile”) di bandingkan dengan metode – metode tradisional sambil membangun suatu software dengan kualitas yang lebih baik, selain itu extreme programming meliputi seluruh area pengembangan perangkat lunak.

Aspek Dasar XP
Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada
C3 Project.
  • The Planning Game
    Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan terminologi “game” karena Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut.
  • Small Releases
    Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem.
  • Metaphor
    Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. 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.
  • Simple Design
    Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP 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.
  • Refactoring
    Refactoring adalah salah satu aspek paling khas dari XP. 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”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.
  • Testing
    XP menganut paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih dahulu. 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. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis a test a code a design. Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan tentang XP.
  • Pair Programming
    Pair programming adalah melakukan proses menulis program dengan berpasangan. 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. Aspek ini mungkin akan sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama rekannnya.
  • Collective Ownership
    Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP 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.
  • Coding Standards
    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. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program.
  • Continous Integration
    Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. 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 XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi.
  • 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.
  • On-Site Customer
    Sebuah pendekatan klasik, di mana XP 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.

Keunggulan dan Kekurangan Extreme Programming
Keunggulan yang dimiliki adalah :
  • Menjalin komunikasi yang baik dengan client.
  • Meningkatkan komunikasi dan sifat saling menghargai antar developer.

Kelemahan yang dimiliki adalah :
  • 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).



Pressman RS. 2010. Software Engineering : A Practitioner’s Approach, 7th ed.Mc Grow Hill.
Pressman S Roger, Ph.D. 1997.  Rekayasa Perangkat Lunak. Yogyakarta : Andi
Latest
First


EmoticonEmoticon

Subscribe to: Post Comments (Atom)