Mengenal macam-macam model Rekayasa perangkat lunak

Rekayasa perangkat lunak (Model RAD)

-Pengertian


Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

-Sejarah


Rapid Application Development ( RAD ) adalah istilah awalnya digunakan untuk menggambarkan proses pengembangan perangkat lunak pertama kali dikembangkan dan berhasil digunakan selama pertengahan 1970-an oleh Sistem Pusat Pengembangan New York Telephone Co di bawah arahan Dan Gielan. Setelah serangkaian implementasi sangat berhasil dari proses ini, Gielan kuliah secara ekstensif di berbagai forum pada metodologi , praktek, dan manfaat dari proses ini.

RAD melibatkan pengembangan dan pembangunan prototipe iteratif . Pada tahun 1990 , dalam buku RAD, Rapid Application Development, James Martin didokumentasikan penafsirannya tentang metodologi. Baru-baru ini, istilah dan singkatan yang telah datang untuk digunakan dalam lebih luas, pengertian umum yang mencakup berbagai metode yang bertujuan untuk mempercepat pengembangan aplikasi, seperti penggunaan kerangka perangkat lunak dari berbagai jenis, seperti kerangka kerja aplikasi web.

Pengembangan aplikasi yang cepat merupakan respon terhadap proses yang dikembangkan pada 1970-an dan 1980-an, seperti Structured Sistem Metode Analisis dan Desain dan model Waterfall lainnya. Satu masalah dengan metodologi sebelumnya adalah bahwa aplikasi begitu lama untuk membangun bahwa persyaratan telah berubah sebelum sistem itu selesai, sehingga sistem tidak memadai atau bahkan tidak dapat digunakan. Masalah lain adalah asumsi bahwa persyaratan metodis tahap analisis saja akan mengidentifikasi semua persyaratan penting. Membuktikan fakta bahwa ini adalah jarang terjadi, bahkan untuk proyek-proyek dengan profesional yang sangat berpengalaman di semua tingkatan.

Dimulai dengan ide-ide dari Brian Gallagher, Alex Balchin, Barry Boehm dan Scott Shultz, James Martin mengembangkan pendekatan pengembangan aplikasi yang cepat selama tahun 1980 di IBM dan akhirnya diresmikan itu dengan menerbitkan sebuah buku pada tahun 1991, Rapid Application Development.

Tahapan-tahapan dalam RAD


RAD digunakan pada aplikasi sistem konstruksi, maka menekankan fase-fase. Ada tiga fase dalam RAD yaitu (Kendall dan Kendall, 2008):


1. Requirement Planning, dalam tahap ini diketahui apa saja yan menjadi kebutuhan sistem yaitu dengan mengidentifikasikan kebutuhan informasi dan masalah yang dihadapi untuk menentukan tujuan, batasan-batasan sistem, kendala dan juga alternatif pemecahan masalah. Analisis digunakan untuk mengetahui perilaku sistem dan juga untuk mengetahui aktivitas apa saja yang ada dalam sistem tersebut.


2. Design Workshop, yaitu mengidentifikasi solusi alternatif dan memilih solusi yang terbaik. Kemudian membuat desain proses bisnis dan desain pemrograman untuk data-data yang telah didapatkan dan dimodelkan dalam arsitektur sistem informasi. Tools yang digunakan dalam pemodelan sistem biasanya menggunakan Unified Modeling Language (UML).


3. Implentation, setelah Design Workshop dilakukan, selanjutnya sistem diimplementasikan (coding) ke dalam bentuk yang dimengerti oleh mesin yang diwujudkan dalam bentuk program atau unit program. Tahap implementasi sistem merupakan tahap meletakkan sistem supaya siap untuk dioperasikan.






Contoh dari Penerapan dalam Kehidupan

Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :

1. Component based construction (pemrograman berbasis komponen bukan prosedural).

2. Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.

3. Pembangkitan kode program otomatis/semi otomatis.

4. Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.


Kelebihan dan Kekurangan Menggunakan RAD

Berikut adalah keunggulan dan kelemahan menggunakan RAD (Whitten, Bentley, Ditman, 2004):

Kelebihan dari RAD :

1. Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.

2. Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.

3. Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.

4. Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.


Kelemahan dari RAD :

1. Dengan melakukan pembelian belum tentu bisa menghemat biaya dibandingkan dengan mengembangkan sendiri.


2. Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.

3. Kesulitan melakukan pengukuran mengenai kemajuan proses.

4. Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.

Model Spiral



Pengembangan software terdapat cara-cara pengembangannya dengan menggunakan model pengembangan, salah satunya Spiral Model (Model Spiral). Model pengembangan software ini cukup baru dikenalkan oleh Barry Boehm di tahun 1988 didalam artikelnya yang berjudul “A Spiral Model of Software Development and Enhancement“.

Spiral Model merupakan penggabungan ide pengembangan berulang (prototyping) dengan, aspek sistematis terkendali model air terjun (waterfall). Model spiral juga secara eksplisit meliputi manajemen resiko dalam pengembangan perangkat lunak. Mengidentifikasi risiko utama, baik teknis maupun manajerial, dan menentukan bagaimana untuk mengurangi risiko membantu menjaga proses pengembangan perangkat lunak di bawah kontrol .


Spiral model dibagi menjadi beberapa framework aktivitas, yang disebut dengan task regions. Kebanyakan aktivitas-aktivitas tersebut dibagi antara 3 sampai 6 aktivitas. Berikut adalah aktivitas-aktivitas yang dilakukan dalam spiral model:

Customer communication. Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.


Planning. Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.


Analysis risk. Aktivitas analisis resiko ini dijalankan untuk menganalisis baik resiko secara teknikal maupun secara manajerial. Tahap inilah yang mungkin tidak ada pada model proses yang juga menggunakan metode iterasi, tetapi hanya dilakukan pada spiral model.


Engineering. Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.


Construction & Release. Aktivitas yang dibutuhkan untuk develop software, testing, instalasi dan penyediaan user / costumer support seperti training penggunaan software serta dokumentasi seperti buku manual penggunaan software.


Customer evaluation. Aktivitas yang dibutuhkan untuk mendapatkan feedback dari user / customer berdasarkan evaluasi mereka selama representasi software pada tahap engineering maupun pada implementasi selama instalasi software pada tahap construction and release.


Adapun kelebihan dan kekurangan dari model spiral sebagai berikut.


a. 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 terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .


Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap keadaan 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.




b. 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 absolut


Rekayasa Perangkat Lunak (Model Prototype)



Dalam pembuatan software, dikenal beberapa metode untuk membuat software yang dibutuhkan untuk memenuhi kebutuhan user yang memerlukan software tersebut.


Sebelum memasuki lebih mendalam mengenai pembuatan software menggunakan metode prototype, kita harus terlebih dahulu mengetahui apa yang dimaksud dengan prototype itu sendiri. Prototype adalah model atau simulasi dari semua aspek produk sesungguhnya yang akan dikembangkan yang dimana model tersebut harus representative dari produk akhirnya. Setelah mengetahui arti prototype mungkin masih menganjal dibenak kita bagaimana sih software itu terbentuk menggunakan metode prototype? Apakah model prototype lebih bagus digunakan daripada model lain? Apakah resiko-resiko dari penggunaan model tersebut? Dan mungkin masih banyak pertanyaan lain yang akan muncul. Oleh sebab itu, pada postingan kali ini saya sendiri akan menjelaskan lebih lanjut mengenai pembuatan software dengan menggunakan metode prototype tersebut.


Model Prototype
Menurut saya sendiri prototyping model adalah suatu proses pembuatan software yang yang bersifat berulang dan dengan perencanaan yang cepat yang dimana terdapat umpan balik yang memungkinkan terjadinya perulangan dan perbaikan software sampai dengan software tersebut memenuhi kebutuhan dari si pengguna. Sedangkan dari beberapa referensi yang saya temukan, prototyping model adalah salah satu model sederhana pembuatan software yang dimana mengijinkan pengguna memiliki suatu gambaran awal/dasar tentang program serta melakukan oengujian awal yang didasarkan pada konsep model kerja(working model).


Tujuan Prototype
Prototyping model sendiri mempunyai tujuan yaitu mengembangkan model awal software menjadi sebuah sistem yang final.


A. Proses


Proses-proses dalam model prototyping menurut saya yaitu:


Komunikasi terlebih dahulu yang dilakukan antara pelanggan dengan tim pemgembang perangkat lunak mengenai spesifikasi kebutuhan yang diinginkan


Akan dilakukan perencanaan dan pemodelan secara cepat berupa rancangan cepat(quick design) dan kemudian akan memulai konstruksi pembuatan prototype


Prototipe kemudian akan diserahkan kepada para stakeholder untuk dilakukan evaluasi lebih lanjut sebelum diserahkan kepada para pembuat software


Pembuatan software sesuai dengan prototype yang telah dievaluasi yang kemudian akan diserahkan kepada pelanggan


Jika belum memenuhi kebutuhan dari pelanggan maka akan kembali ke proses awal sampai dengan kebutuhan dari pelanggan telah terpenuhi


Sedangkan proses-proses dalam model prototyping secara umum adalah sebagai berikut:


1. Pengumpulan kebutuhan
developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya

2. Perancangan
Perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype

3. Evaluasi Prototype
Klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

B. Tahapan

Selain itu, untuk memodelkan sebuah perangkat lunak dibutuhkan beberapa tahapan di dalam proses pengembangannya. Tahapan inilah yang akan menentukan keberhasilan dari sebuah softwareitu .Pengembang perangkat lunak harus memperhatikan tahapan dalam metode prototyping agar software finalnya dapat diterima oleh penggunanya. Dan tahapan-tahapan dalam prototyping tersebut adalah sebagai berikut :


1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).

3. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.

4. Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.

5. Menguji system
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.

6. Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi langkah 4 dan 5.

7. Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan


C. Keunggulan dan kelemahan metode prototype

Keunggulan prototyping :

Komunikasi akan terjalin baik antara pengembang dan pelanggan.

Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap pelanggannya.

Pelanggan berperan aktif dalam proses pengembangan sistem.

Lebih menghemat waktu dalam pengembangan sistem.

Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

Kelemahan prototyping :

Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama.


Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan sebuah kerangka kerja(blueprint) dari sistem .

Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik dan benar.

Dalam setiap metode mempunyai kelebihan maupun kekurangan, namun kekurangan tersebut dapat diminimalisir yaitu dengan mengetahui kunci dari model prototype tersebut. Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan.

Rekayasa perangkat lunak (Waterfall Model)


Sejarah model waterfall

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini pertama kali yang diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan berurutan. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.

Pengertian Waterfall


Waterfall atau AIR terjun adalah model yang dikembangkan untuk pengembangan perangkat lunak, membuat perangkat lunak. model berkembang secara sistematis dari satu tahap ke tahap lain dalam mode seperti air terjun.

Model ini mengusulkan sebuah pendekatan kepada pengembangan software yang sistematikdan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Model ini melingkupi aktivitas-aktivitas sebgai berikut : rekayasa dan pemodelan sistem informasi, analisis kebutuhan, desain, koding, mengujian dan pemeliharaan.

Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya.


Karakteristik

Dalam model ini terdapat beberapa sifat-sifat yang menojol dan cenderung menjadi permasalahan pada model waterfall.

1) Ketika problem muncul, maka proses berhenti karena tidak dapat menuju ke tahapan selanjutnya. Apabila terdapat kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agarproblem ini tidak muncul.

2) Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya.

Tahap Pengembangan Waterfall

Tahap – tahap pengembangan waterfall model adalah :
1)      Analisis dan definisi persyaratan Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user.
2)      Perancangan sistem dan perangkat lunak Kegiatan ini menentukan arsitektur sistem secara keseluruhan.
3)      Implementasi dan pengujian unit Perancangan perangkat lunak direalisasikan sebagai serangkaian program.
4)      Integrasi dan pengujian sistem Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sitem telah terpenuhi
5)      Operasi dan pemeliharaan Merupakan fase siklus yang paling lama. Sistem diinstall dan dipakai. Perbaikan mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.

Keuntungan dari Model Waterfall

1)      Merupakan model pengembangan paling handal dan paling lama digunakan.
2)      Cocok untuk system software berskala besar.
3)       Cocok untuk system software yang bersifat generic.
4)       Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol

Rekayasa perangkat lunak (Extreme Programming (XP) Model)

(berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak.
XP mengambil pendekatan ‘ekstrim’ dalam iterative development.

Sejarah XP

Extreme Programming diciptakan oleh Kent Beck selama Ia bekerja di proyek Chrysler Comprehensive Compensation (C3). Beck menjadi pemimpin proyek C3 pada bulan Maret 1996 dengan mulai memperbaiki metodologi pengembangan yang digunakan dalam proyek penggajian 10.000 karyawan Chrysler, yang terdiri dari kira-kira 2000 class dan 30.000 method.  Beck juga menulis sebuah buku tentang metodologi <i>Extreme Programming Explained</i> yang diterbitkan (bulan Oktober 1999. Kemudian Chrysler membatalkan proyek C3 pada bulan Februari 2000, setelah 7 tahun, ketika perusahaan ini diakuisisi oleh Daimler-Benz.

Aspek Dasar XP

Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut antara lain:

Whole Team
Seluruh kontributor dalam proyek yang menggunakan pendekatan XP duduk bersama sebagai suatu tim. Tim ini terdiri beberapa peran, antara lain programmer, penguji,orang yang mengerti bisnis, analis, manajer, dan lain-lain. Setiap peran yang ada tidak mutlak menjadi peran dari satu orang saja. Tim terbaik dalam XP tidak harus memiliki pakar, hanya kontributor umum dengan keterampilan khusus saja. Semua orang di tim XP memberikan kontribusi dengan cara apapun yang mereka dapat lakukan.

Planning game
Perencanaan dalam XP mengemukakan dua pertanyaan kunci dalam pengembangan perangkat lunak, yaitu  memprediksi apa yang akan dicapai pada waktu tertentu, dan menentukan apa yang harus dilakukan setelah itu. Ada dua langkah kunci dalam perencanaan XP, yang menangani dua pertanyaan tersebut:

Release Planning yaitu praktek dimana Customer mengutarakan fitur yang diinginkannya ke programer, dan programer memperkirakan tingkat kesulitannya. Dengan estimasi biaya di tangan, dan dengan pengetahuan tentang pentingnya fitur yang diinginkan, Pelanggan meletakkan satu rencana untuk proyek tersebut. Rencana rilis awal yang selalu tepat: baik prioritas maupun perkiraan yang benar-benar solid, dan sampai tim mulai bekerja, kita tidak akan tahu seberapa cepat mereka akan pergi. Bahkan rencana rilis pertama cukup akurat untuk pengambilan keputusan, namun, dan tim XP melakukan revisi terhadap rencana rilis secara teratur.

Iteration Planning adalah praktek di mana tim diberikan petunjuk atau arahan setiap beberapa minggu sekali. Tim XP membangun perangkat lunak dalam “iterasi” dua minggu, memberikan menjalankan perangkat lunak yang berguna pada setiap akhir iterasi. Selama Iteration Planning, Customer mengutarakan fitur yang diinginkan selama dua minggu ke depan. Para programer memecahnya ke dalam pekerjaan yang lebih kecil, dan memperkirakan biaya yang diperlukan.

Customer Tests
Sebagai bagian dari presentasi masing-masing fitur yang diinginkan, Customer XP mendefinisikan satu atau lebih  tes penerimaan otomatis untuk menunjukkan bahwa fitur tersebut bekerja dengan baik. Tim membangun tes ini dan menggunakannya untuk membuktikan pada kepada Customer bahwa fitur ini telah diimplementasikan dengan benar. Tes secara otomatis ini penting karena dalam XP hanya diberikan waktu yang singkat sehingga tes manual tidak akan digunakan karena memakan waktu yang lama.

Small Release
Pada setiap Iterasi, tim mengerjakan sebuah unit atau bagian dari perangkat lunak, melakukan tes terhadap unit perangkat lunak yang dibangun, kemudian di akhir iterasi perangkat lunak yang dibangun diberikan kepada Customer. Oleh customer, perangkat lunak ini bisa dijadikan bahan evaluasi maupun langsung dirilis kepada end user. Bisa juga tim XP langsung merilis ke end user secara rutin.

Simple Design
Tim XP membangun perangkat lunak dengan desain yang sederhana. Dimulai dengan desain yang sederhana, kemudian melalui pengujian program dan perbaikan desain. Desain yang dibuat harus benar-benar cocok untuk fungsi saat ini dari sistem sehingga tidak ada yang sia-sia dan perangkat lunak siap dikembangkan lagi selanjutnya. Namun, pembuatan desain dalam XP tidak dilakukan hanya sekali. Tahapan desain dalam Extreme Programming yang menghasilkan desain yang bagus dianggap sangat penting, sehingga selama proses development banyak difokuskan ke tahapan desain.

Pair Programming
Semua perangkat lunak yang dibangun dengan pendekatan XP dibangun oleh dua orang programmer. Keduanya duduk berdampingan di satu komputer yang sama. Seorang programmer akan membuat code dan programmer yang lainnya akan mengoreksinya. Praktik seperti ini mungkin kelihatan tidak efisien. Namun dari segi hasil dari pair programming, desain akan lebih baik, pengujian lebih baik, dan code yang dihasilkan pun akan lebih baik.

Test-Driven Development
XP begitu terobsesi dengan umpan balik, dan dalam pengembangan perangkat lunak, umpan balik yang baik mensyaratkan pengujian yang baik pula. Test-Driven Development bergantung pada pengulangan siklus development yang sangat pendek. Pertama tim XP akan menuliskan automated test case yang mendefinisikan perbaikan yang diinginkan atau fungsi baru. Kemudian dari test case tersebut dihasilkan jumlah minimal code yang harus dituliskan untuk lulus tes tersebut. Setelah itu melakukan refactoring code baru agar memenuhi standar baru.

Design Improvement
XP berfokus pada memberikan nilai bisnis dalam setiap perulangan. Agar dapat mencapai tujuan tersebut selama proyek berlangsung, perangkat lunak harus dirancang dengan baik. XP menggunakan proses perbaikan desain secara terus menerus dengan Refactoring. Proses refactoring berfokus pada penghapusan duplikasi dari code yang telah dibuat. Disamping itu, proses refactoring didukung dengan pengujian yang komprehensif utnuk memastikan bahwa desain yang dibuat berkembang dan tiidak ada yang rusak.

Continuous Integration
Beberapa kali dalam sehari, tim XP akan menggabungkan seluruh salinan pekerjaan tim menjadi satu dalam jaringan utama. Sehingga tim XP harus menjaga tim agar terintegrasi setiap saat.

Collective Code Ownership
Pada proyek XP, setiap pasang programmer dapat meningkatkan code apapun setiap saat. Semua code yang ada dimiliki secara kolektif oleh tim. Manfaatnya setiap code akan mendapat perhatian dari banyak orang, sehingga dapat meningkatkan kualitas code dan mengurangi cacat. Selain itu dapat mengurangi duplikasi code yang sama walaupun dibuat oleh pasangan programmer yang berbeda.

Coding Standard
Setiap anggota tim XP harus mengikuti standar coding yang umum, sehingga semua code dalam sistem seolah-olah tampak dibuat oleh satu orang yang sangat kompeten. Selain itu hal ini sangat mendukung Collective Code Ownership.

Metaphor
Tim XP akan membuat suatu deskripsi umum bagaimana program yang mereka kembangkan bekerja dengan benar.

Sustainable Pace
Tim XP akan bekerjasama dalam jangka waktu lama. Mereka bekerja keras dengan kecepatan tertentu tanpa batas waktu. Tim XP akan bekerja lembur pada hari efektif dan memaksimalkan produktivitas setiap minggunya.  Hal ini perlu diperhatikan dengan baik, karena akan mengurangi produktivitas atau sebaliknya menghasilkan perangkat lunak yang berkualitas.

 Rekayasa perangkat lunak RUP (Rational Unified Process)

RUP, singkatan dari Rational Unified Process,

Pengertian

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

1. improve productivity

standard ini dapat memanfaatkan kembali komponen-komponen yang telah tersedia/dibuat sehingga dapat meningkatkan produktifitas.

2. Deliver hight quality system

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

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

4. Facilitate reuse

Standard ini memiliki kamampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk pengembangan aplikasi yang lainnya.

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

1. Inception/insepsi

a. Menentukan Ruang lingkup proyek

b. Membuat 'Business Case'

c. Menjawab pertanyaan 'apakah yang dikerjakan dapat menciptakan 'good business sense' sehingga proyek dapat dilanjutkan

2.Elaboration/elaborasi

a. Menganalisa berbagai persyaratan dan resiko

b. Menetapkan 'Base line' 

c. Merencanakan fase berikutnya yaitu construction

3. Construction/kontruksi

a. Melakukan sederetan iterasi 

b. Pada setiap iterasi akan melibatkan prose berikut : analisa desain, implementasi dan testing

4. Transition/Transisi

a. Membuat apa yang sudah dimodelkan menjadi suatu produk jadi 

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

     2. Elaboration 

Menolong dalam melakukan analisa resiko

Menolong mempersiapkan fase berikutnya yaitu konstruksi

     3. Construction 

 Melakukan sederetan iritasi 

Pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan testing

     4. Transition 

Membuat apa yang sudah dimodelkan menjadi suatu produk jadi 

Dalam fasi ini dilakukan:

          a. Beta dan performance testing

          b. Membuat dokumentasi tambahan seperti: training, user guide dan sales kit

          c. Membuat rencana peluncuran produk ke komunitas pengguna

 

sumber ; ardlogicom.blog.widyatama.ac.id/2015/02/15/proses-rekayasa-perangkat-lunak-menggunakan-model-prototype/