Perbedaan beberapa model pengembangan software

 

photodune-3333036-word-cloud-software-development-s

  1. Agile Software Development Methodology

          Agile development methods merupakan salah satu dari Metodologi pengembangan perangkat lunak yang digunakan dalam pengembangan perangkat lunak. Agile memiliki pengertian bersifat cepat, ringan, bebas bergerak, dan waspada. Sehingga saat membuat perangkat lunak dengan menggunakan agile development methods diperlukan inovasi dan responsibiliti yang baik antara tim pengembang dan klien agar kualitas dari perangkat lunak yang dihasilkan bagus dan kelincahan dari tim seimbang.

a. Prinsip agile software development

  1. Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus.
  2. Menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
  3. Penyerahan hasil/software dalam hitungan waktu dua minggu sampai dua bulan.
  4. Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung.
  5. Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.
  6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien.
  7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek.
  8. Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan.
  9. Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile.
  10. Kesederhanaan penting.
  11. Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri.
  12. Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.

a. Cara bekerja Agile Software Development

    Komposisi tim

Secara umum komposisi dari sebuah tim pengembang perangkat lunak yaitu :

  • Owner/ Klien, bersama dengan developer sebagai bagian terpenting dalam proyek, tugas dari klien menentukan fungsi dari perangkat lunak yang akan di buat, melakukan testing dan memberikan feedback.
  • Manajer / Scrum Master, bertugas mengkolaborasikan developer dengan klien, membuat dan mengevaluasi target pengerjaan perangkat lunak.
  • Sistem Analis, membuat arsitektur sistem dari perangkat lunak yang akan dibuat.
  • Developer, merupakan titik vital dalam tim, tanpa developer perangkat lunak tidak akan bisa dibuat.

 Story

Story adalah daftar kebutuhan atau fitur yang nanti akan dibuat. Story berisi apa yang klien kehendaki, dan ditulis dalam bahasa yang dimengerti klien. Dengan kata lain dapat disimpulan Story adalah bagian terpenting dari Scrum.

Story terdiri dari kolom-kolom berikut ini:

  • ID – Identifikasi unik, biasanya berupa nomor urut. Hal ini untuk menghindari kehilangan jejak story kalau kita mengganti namanya.
  • Nama – Nama story bersifat deskriptif, padat, singkat, dan jelas (2-10 kata), sehingga tim dan klien memahami kira-kira story yang dibicarakan.
  • Kepentingan – Derajat kepentingan yang diberikan oleh klien terhadap story. Pemberian derajat kepentingan biasanya menggunakan deret fibonacci (1,1,2,3,5,dst). Semakin tinggi nilainya maka semakin tinggi pula prioritas pengerjaannya.
  • Perkiraan awal – Perkiraan awal tim tentang berapa banyak kerja yang diperlukan untuk mengimplementasikan sebuah story.
  • Demo – deskripsi umum bagaimana cara story ini didemokan pada waktu sprint demo (lakukan ini, klik itu, lalu ini akan muncul,dll).

Sprint

Sprint (Rapat perencanaan pembuatan perangkat lunak dilakukan 2-8 minggu sekali), yang perlu diperhatikan saat melaksanakan sprint antara lain :

  • Tujuan sprint.
  • Daftar anggota tim harus lengkap.
  • Sprint backlog (daftar story yang akan diikutkan dalam sprint).
  • Tanggal demo yang pasti.
  • Tempat dan waktu yang jelas untuk pelaksanaan sprint berikutnya.

Tim akan melakukan sprint secara simultan sampai perangkat lunak selesei dikerjakan, sebagai contoh:

Sprint 1, tim membuat fungsi login,logout dan demo perangkat lunak akan dilakukan 3 minggu kemudian. Setelah dilakukan demo untuk mengevaluasi kerja yang dilakukan tim pada Sprint 1, maka Sprint 1 dianggap selesei. Bahan evaluasi dari Sprint 1 akan dibawa ke Sprint 2 begitu seterusnya sampai aplikasi selesei dikerjakan.

 

a.       Kelebihan dan kerungan Agile Software Development

  • Kelebihan:

Beberapa kelebihan dari agile diantaranya :

  1. Menambah produktivitas tim.
  2. Menambah kualitas perangkat lunak.
  3. Menambah kepuasan klien.
  4. Menghemat biaya.
  • Kekurangan:
  1. Agile tidak akan berjalan dengan baik jika komitmen tim kurang.
  2. Tidak cocok dalam skala tim yang besar (>20 orang).
  3. Perkiraan waktu release dan harga perangkat lunak sulit ditentukan.

2. Rapid Application Development

     Rapid Application Development (RAD) adalah metodologi pengembangan perangkat  lunak yang berfokus pada membangun aplikasi dalam waktu yang sangat singkat. Istilah ini menjadi kata kunci pemasaran yang umum menjelaskan aplikasi yang dapat dirancang dan  dikembangkan dalam waktu 60­90 hari. . Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem di mana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan.

a.       Cara bekerja RAD

Metodelogi RAD  mengunakan  Prototyping dan Throw­away Prototyping

  • RAD Prototyping

prototyping

Karena keunggulan metode ini menggabungkan teknik SDLC, Prototyping, teknik joint application development (JAD)   dan computer aided software engineering (CASE  Tools) yang bertujuan untuk membuat system dalam waktu singkat ( kurang dari 6 bulan ).  Pada  gambar 2 diatas Metodologi prototyping melakukan analisis, desain dan implementasi secara   bersamaan untuk menghadirkan sebuah sistem dengan skala kecil dalam fungsi  minimal  kemudian di review oleh user untuk dilakukan proses development secara berulang  hingga menghasilkan  sebuah system.

  • RAD Throw-away Prototyping

throwaway

 Untuk gambar 3 adalah metode Throwaway Prototyping, pada metodologi ini Analisa  dilakukan lebih mendalam, prototype dibuat dan ditest, pengalaman yang diperoleh dari latihan ini digunakan untuk membuat produk finalnya, tetapi prototype­nya sendiri dibuang.

b.      Model RAD

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 tetapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.

Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

c. Kelebihan dan keuntungan RAD

  • Kelebihan

1.Sangat berguna dilakukan pada kondisi user tidak memahami  kebutuhankebutuhan apa saja yang digunakan pada proses pengembangan perangkat lunak.

2.RAD mengikuti tahapan pengembangan sistem sepeti umumnya, tetapi  mempunyai kemampuan untuk menggunakan kembali komponen yang ada  (reusable object) sehingga pengembang tidak perlu membuat dari awal lagi  dan waktu lebih singkat berkisar antara 60 hari­90 hari.

3.Karena mempunyai kemampuan untuk menggunakan komponen yang su dah  ada dan waktu yang lebih singkat maka membuat biaya menjadi lebih rendah  dalam menggunakan RAD.

  • Kekurangan

1.Proyek yang berskala besar, RAD memerlukan sumber daya manusia yang  memadai untuk menciptakan jumlah tim yang baik.

2.RAD menuntut pengembang dan pelanggan memiliki komitmen dalam  aktivitas rapid fire yang diperlukan untuk melengkapi sebuah sistem dalam waktu yang singkat. Jika komitmen tersebut tidak ada maka proyek RAD akan  gagal.

3. Dynamic System Development Model Methodology

Merupakan Metodologi Pengembangan Software yang dikembangkan oleh Konsorsium Vendor dan Para Expert dalam bidang pengembangan Sistem Informasi(IS) di United Kingdom pada tahun 1990 dan pertamakali go public pada tahun 1995. Metodologi ini merupakan pengembangan tahap lanjut dari metode Rapid Application Development (RAD) yang sangat menerapkan  metode incremental dan iteratif. metode ini sangat ideal digunakan ketika suatu software dituntut untuk sangat fokus dan mementingkan tampilan yang mudah dan aspek kegunaan yang baik dari produk tersebut.

DSDM memperbaiki biaya, kualitas dan waktu sejak awal dan menggunakan prioritas MoSCoW dalam lingkup menjadi musts , shoulds , coulds dan tidak akan dapat menyesuaikan deliverable proyek untuk memenuhi batasan waktu yang disebutkan. DSDM adalah salah satu dari sejumlah metode Agile untuk mengembangkan solusi perangkat lunak dan non-TI, dan ini merupakan bagian dari Agile Alliance.

a.       Prinsip DSDM

Ada delapan prinsip yang mendasari DSDM Atern. Prinsip-prinsip ini mengarahkan tim dalam sikap yang harus mereka ambil dan pola pikir yang harus mereka adopsi agar dapat disampaikan secara konsisten.

1.     Fokus pada kebutuhan bisnis

2.     Kirim tepat waktu

3.     Berkolaborasi

4.     Jangan kompromi kualitas

5.     Bangun secara bertahap dari fondasi yang kuat

6.     Kembangkan secara iteratif

7.     Berkomunikasi terus menerus dan jelas

8.     Tunjukkan kontrol

 

b.      Kelebihan dan kelemahan DSDM

1.      Kelebihan:

1.      Menyajikan kerangka kerja (framework) untuk membangun dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototyping yang incremental dalam lingkungan yang terkondisikan.

2.      Membangun software dengan cepat.

3.      DSDM dapat dikombinasikan dengan XP menghasilkan kombinasi model proses yang mengikuti DSDM dan praktek yang sejalan dengan XP

2.      Kekurangan:

1.      Setiap iterasi bergantung pada prototype sebelumya.

2.      Menentukan scope dari suatu prototype proyek tidak pernah selesai.

3.      Dokumentasi sering kali tidak lengkap fokus pada pembuatan prototype.

4.      Isu-isu mengenai system backup and recovery, system performance dan system security kurang/tidak diperhatikan dan sering terlupakan.

 

4.      Extreme programming methodology

Metodologi pengembangan perangkat lunak yang ditujukan untuk meningkatkan kualitas perangkat lunak dan daya tanggap terhadap perubahan kebutuhan pelanggan. Sebagai jenis pengembangan perangkat lunak tangkas , ini sering menganjurkan “rilis” dalam siklus pengembangan singkat, yang dimaksudkan untuk meningkatkan produktivitas dan mengenalkan pos pemeriksaan di mana persyaratan pelanggan baru dapat diadopsi. Metodologi ini mengambil namanya dari gagasan bahwa unsur-unsur yang menguntungkan dari praktik rekayasa perangkat lunak tradisional dibawa ke tingkat “ekstrim”. Sebagai contoh, review kode dianggap sebagai praktik yang bermanfaat; Yang diambil secara ekstrem, kode bisa ditinjau terus menerus , yaitu praktek pemrograman pair .

a.       Prinsip EPM:

1.Rapid Feedback Menurut ilmu psikologi, waktu antara sebuah aksi dengan feedbacknya sangat penting untuk dipelajari. Dalam sebuah proyek XP, developer memperoleh feedback sesegera mungkin, menginterpretasikannya, lalu mengambil inti sarinya dan meletakkannya ke dalam system. Feedback dari pelanggan terhitung harian, bukan bulanan, dan feedback dari developer terhitung menitan, bukan mingguan.

2.Assume Simplicity Hanya mendesain untuk masalah saat ini dan menghemat waktu 98% dari masalah tersebut dan hanya menekuni sekitar 2% untuk bagian yang sulit. XP berencana untuk masa depan sehingga desainnya bias di-reuse, lakukan pekerjaan yang penting, dan percayalah bahwa untuk kekompleksitasan bias ditambahkan kemudian.

3.Incremental Change Pemecahan problem yaitu dengan bagian-bagian kecil perubahan saja. Jadi perubahan-perubahan yang terjadi pada XP melalui tahap-tahap kecil dan waktu yang singkat.

4.Embracing Change Mencari dan menyediakan terlebih dahulu sebanyak mungkin pilihan ketika menyelesaikan masalah yang begitu menekan.

5.Quality Work setiap orang suka mengerjakan pekerjaan yang bagus dan layak dan kualitas yang dimaksud di sini adalah kualitas yang sempurna dan kualitas yang sempurna secara ekstrim. Karena tanpa kualitas kita tidak akan suka melakukan pekerjaan tersebut, hasilnya tidak akan sempurna dan proyeknya akan jatuh berantakan.

b.      Kelebihan dan kekurangan EPM

  • Kelebihan:

1. Komunikasi dalam XP 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. Selain itu perkiraan beban tugas juga diperhitungkan.

2.Setiap feed Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).

3. Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.

4.Menjalin komunikasi yang baik dengan klien. (Planning Phase).

5.Menurunkan biaya pengembangan (Implementation Phase).

6.Meningkatkan komunikasi dan sifat saling menghargai antar developer.                             (Implementation Phase).

  • Kekurangan:

1.Developer harus selalu siap dengan perubahan karena perubahan akan selalu                diterima.

2. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga                          anjuran untuk melakukan apa yang diperlukan hari itu juga).

5. Scrum Development Methodology

Scrum merupakan framework untuk manajemen pengembangan software dengan karakteristik cekatan dan bersifat iteratif dan incremental. Scrum mendefinisikan dirinya fleksible, strategi pengembangan yang menyeluruh di mana seluruh team bekerja sebagai satu unit dalam mencapai sebuah gol yang sama. Prinsip kunci dari scrum adalah memahami bahwa dalam project yang tengah berlangsung, klien mungkin mengubah apa yang menjadi kebutuhan dan keinginannya. Perubahan sulit diadaptasi oleh framework pengembangan aplikasi yang bersifat tradisional.  Scrum menerima perubahan ini dan memaksimalkan seluruh anggota team untuk menyesuaikan perubahan mendadak ini.

a. Prinsip Scrum:

1.Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan                            memberdayakan satu sama lainProses dapat beradaptasi terhadap perubahan teknis        dan bisnis.

2. Proses menghasilkan beberapa software increment.

3. Pembangunan dan orang yang membangun dibagi dalam tim yang kecil.

4.Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun.

5.Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan.

c.       Kelebihan dan kekurangan :

  •  Kelebihan:

1. Keperluan berubah dengan cepat.

2 .Tim berukuran kecil sehingga melancarkan komunikasi, mengurangi biaya dan                 memberdayakan satu sama lain.

3.Pekerjaan terbagi-bagi sehingga dapat diselesaikan dengan cepat.

4.Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun.

5.Proses Scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

  • Kekurangan:

Developer harus selalu siap dengan perubahan karena perubahan akan selalu                   diterima.

 

 

 

 

 

 

 

Tinggalkan komentar