Ringkasan The Software Problem

Masalah software

Dalam masalah perangkat lunak biaya, jadwal, dan kualitas adalah kekuatan pendorong dasar. Oleh karena itu, metode dan alat-alat yang akan digunakan untuk memecahkan masalah dalam hal ini harus memastikan produktivitas yang tinggi dan kualitas tinggi. Biaya, Jadwal, dan Kualitas:

1.Biaya

Biaya jadwal dan kualitas menjadi kekuatan pendorong utama dalam software. dalam software ada tiga kekuatan dasar yaitu biaya, jadwal, dan kualitas. perangkat lunak ini harus diproduksi dengan biaya yang murah,dan dalam waktu yang wajar, serta harus berkualitas baik. Ketiga parameter tersebut sangat menentukan dalam proyek software. Software industri sangat mahal terutama karena  pengembangan perangkat lunak sangat padat karya. Untuk mendapatkan ide dari biaya yang terlibat,  mari kita perhatikan keadaan saat praktik di industri. Baris kode (LOC) atau ribuan baris kode (KLOC) disampaikan adalah yang paling umum digunakan ukuran ukuran software di industri.  Karena biaya utama memproduksi perangkat lunak adalah tenaga yang digunakan. produktivitas sering diukur dalam industri dalam hal LOC (atau KLOC) per bulan.

2.Jadwal

Jadwal merupakan faktor penting dalam banyak proyek. tren bisnis mendikte bahwa waktu dari pasar ke produk harus dikurangi; yaitu, waktu siklus dari konsep untuk pengiriman harus kecil. Untuk software ini berarti bahwa perlu dikembangkan lebih cepat, dan dalam waktu yang ditentukan. Sayangnya, sejarah perangkat lunak ini penuh dengan kasus di mana proyek telah secara substansial terlambat.

Oleh karena itu,perlu mengurangi biaya dan waktu siklus untuk perangkat lunak karna pembangunan adalah tujuan utama dari rekayasa perangkat lunak. Produktivitas dalam hal output (KLOC) per orang memadai dapat menangkap biaya dan kekhawatiran jadwal. Jika produktivitas lebih tinggi, biaya akan lebih rendah (pekerjaan yang sama kini dapat dilakukan dengan lebih sedikit orang perbulan). Demikian pula, jika produktivitas lebih tinggi, potensi pengembangan perangkat lunak dalam waktu kurang meningkatkan-tim produktivitas yang lebih tinggi akan menyelesaikan pekerjaan dalam waktu kurang dari tim yang sama dengan produktivitas rendah tentu saja, tergantung juga pada jumlah orang yang terletak pada proyek tersrebut. Oleh karena itu, mengejar produktivitas yang lebih tinggi adalah kekuatan pendorong dasar di balik rekayasa perangkat lunak.

3.Kualitas

Selain biaya dan jadwal, software faktor utama pendorong adalah kualitas. Hari ini, kualitas adalah salah satu mantra utama, dan strategi bisnis yang dirancang di sekitar. Sayangnya, sejumlah besar kasus terjadi mengenai tidak dapat diandalkan perangkat lunak-perangkat lunak sering tidak melakukan apa yang seharusnya dilakukan atau melakukan sesuatu tidak seharusnya dilakukan. Jelas, mengembangkan perangkat lunak berkualitas tinggi adalah tujuan mendasar lain dari rekayasa software. Namun, sementara biaya umumnya dipahami, konsep kualitas dalam konteks perangkat lunak perlu penjelasan lebih lanjut. Kualitas perangkat lunak terdiri dari enam atribut utama:

1.      Functionality: Kemampuan untuk menyediakan fungsi yang memenuhi dinyatakan dan tersirat kebutuhan ketika perangkat lunak yang digunakan

2.      Reliability: Kemampuan untuk menyediakan layanan kegagalan bebas

3.      Usability: Kemampuan untuk memberikan kinerja yang relatif sesuai dengan jumlah   sumber daya

4.      Efficiency: Kemampuan untuk memberikan kinerja yang relatif sesuai dengan jumlah sumber daya yang digunakan.

      5    Maintainability: Kemampuan yang akan dimodifikasi untuk keperluan membuat

           koreksi

6.      Portability: Kemampuan yang akan disesuaikan untuk different ditentukan environ tanpa tindakan menerapkan atau berarti selain yang disediakan untuk tujuan ini dalam produk

Untuk menentukan kualitas produk perangkat lunak, kita perlu menentukan jumlah cacat pada perangkat lunak yang disampaikan. Jumlah ini jelas tidak diketahui pada waktu pengiriman dan mungkin tidak akan pernah diketahui. Salah satu pendekatan untuk mengukur kualitas adalah untuk log cacat ditemukan dalam 6 bulan (atau 1 tahun) setelah melahirkan dan menentukan kualitas sehubungan dengan cacat ini. Ini berarti bahwa kualitas perangkat lunak yang dikirimkan hanya dapat ditentukan 6 bulan setelah pengiriman. Kepadatan cacat bisa, bagaimanapun, juga diperkirakan dari data masa lalu yang sama proyek-jika sama pendekatan yang digunakan, maka diharapkan proyek ini akan memiliki kerapatan cacat yang sama sebagai proyek masa lalu.

Perlu menunjukkan bahwa menggunakan definisi kualitas, apa cacat yang harus didefinisikan secara jelas. Sebuah cacat bisa ada beberapa masalah dalam perangkat lunak yang menyebabkan perangkat lunak untuk crash atau masalah yang menyebabkan output untuk tidak selaras dengan benar atau yang salah mengeja beberapa kata, dll yang tepat definisi apa yang dianggap cacat jelas akan tergantung pada proyek atau standar organisasi mengembangkan penggunaan proyek (biasanya itu adalah yang terakhir)

1.2 Skala dan Perubahan

 

Meskipun biaya, jadwal, dan kualitas adalah kekuatan pendorong utama untuk project (perangkat lunak industri), ada beberapa artribut lainnya skala dan perubahan dari domain masalah juga mempengaruhi pendekatan solusi yang dipekerjakan. Kebanyakan sistem perangkat lunak industri cenderung besar dan kompleks, membutuhkan puluhan ribu baris kode. Seperti yang diharapkan, pengembangan sistem besar membutuhkan satu set yang berbeda dari metode pengembangan sistem kecil, seperti metode yang digunakan untuk mengembangkan sistem yang kecil sering tidak meningkatkan ke sistem yang besar 

Setiap project software melibatkan penggunaan teknik dan management project. Dalam project kecil, metode informal bagi pengembangan dan pengelolaan dapat digunakan. Namun, untuk project-project besar harus jauh lebih ketat, dengan kata lain, untuk berhasil melaksanakan proyek, sebuah metode yang tepat untuk rekayasa sistem harus bekerja dan proyek telah dikelola ketat untuk memastikan biaya yang, jadwal, dan kualitas tetap dapat terkontrol. Seperti yang dibahas diatas, software harus berubah bahkan setelah itu diserahkan. dari berlangsung.

Seperti kode sumber, perlu diubah karena beberapa perubahan persyaratan atau karena beberapa hal cacat yang perlu dihapus. perubahan kebutuhan adalah karateristik dari domain masalah. Dalam dunia sekarang ini, pendekatan yang tidak dapat menerima dan mengakomodasi perubahan jarang digunakan, mereka dapat memecahkan hanya beberapa masalah yang tahan perubahan

Continue

Penjelasan model Waterfall,Prototyping,Iterative Development,RationalUnfieldProses,Time Boxing Model,Extreme Programming Dan Agile

                                                     Nama : Dwiki Ardiansyah
                                                     Npm : 43A87007150390
                                                     Kelas : S1/SI/3B(pagi)
                                           Tugas 1 Rekayasa Perangkat Lunak

1.     WATERFALL

      Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan. Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE).

Proses pada metodologi Waterfall:

1.   Requirement Analysis
     Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.

2.  System Design
Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.

3.  Implementation
Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.

4.  Integration & Testing
Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.

5.  Operation & Maintenance
Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki  kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.

Gambaran Tahapan Umum Proses Waterfall:

Keuntungan  Waterfall:

1.         Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.

2.         Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi  setiap fase atau tahapan akan mempunyai dokumen tertentu.

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

Kelemahan Waterfal:

1.        Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.

2.         Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.

3.        Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.

4.         Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.

5.      Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru.

   2. Prototyping 

       

     Prototyping adalah proses iterative dalam pengembangan sistem dimana requirement diubah ke dalam sistem yang bekerja (working system) yang secara terus menerus diperbaiki melalui kerjasama antara user dan analis. Prototype juga bisa dibangun melalui beberapa tool  pengembangan untuk menyederhanakan proses.

Diagram of Prototyping Model

 

 Tujuan Prototype :

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

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 software itu. 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 keseluruhan 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 :

1.        Komunikasi akan terjalin baik antara pengembang dan pelanggan.

2.        Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap pelanggannya.

3.        Pelanggan berperan aktif dalam proses pengembangan sistem.

4.       Lebih menghemat waktu dalam pengembangan sistem.

5.      Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

Kelemahan prototyping :

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

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

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

3. Iterative Development

      Merupakan model pengembangan sistem yang bersifat dinamis dalam artian setiap tahapan proses pengembangan sistem dapat diulang jika terdapat kekurangan atau kesalahan. Setiap tahapan pengembangan system dapat dikerjakan berupa ringkasan dan tidak lengkap, namun pada akhir pengembangan akan didapatkan sistem yang lengkap pada pengembangan system.

     

Iterative Development berarti menciptakan versi yang lebih fungsional dari sebuah system dalam siklus pembangunan pendek. Setiap versi ditinjau dengan klien untuk menghasilkan persyaratan untuk membuat versi berikutnya. Proses ini diulang sampai semua fungsionalitas telah dikembangkan. Panjang ideal iterasi adalah antara satu hari (yang lebih dekat dengan Metodologi Agile) dan tiga minggu. Setiap siklus pengembangan memberikan pengguna kesempatan untuk memberikan umpan balik,memperbaiki persyaratan, dan kemajuan melihat (dalam pertemuan sesi fokus grup). Hal ini akhirnya pembangunan berulang yang memecahkan masalah yang melekat dalam metodologi fleksibel dibuat pada 1970an.

A . Keuntungan dari Iterative model :

             1. User dapat mencoba sistem yg sudah dikembangkan dan kemudian dapat memberikan masukan keterlibatan user semakin intens dampak positif dalam pengembangan 

                    

      2. Prototype relatif lebih mudah dibangun dan tidak memerlukan waktu yang lam

 

      3. Dengan prototype, kesalahan & kelalaian dalam pengembangan dapat segera diketahui

B. Kelemahan dari Iterative model :

            1. Setiap iterasi bergantung prototype sebelumnya solusi final umumnya terjadi apabila ada     perbedaan yg nyata pada prototype sebelumnya.

           2. Formal end-of-phasemungkin tidak terjadi, karena sangat sulit menentukan scope dari suatu prototype > proyek tidak pernah selesai

  

    3. Dokumentasi seringkali tdk lengkap > fokus pada pembuatan prototype

     Proses Iterative Development

  

4.  Rational Unfield Process

      Rasional Unified Process (RUP) adalah metodologi berorientasi objek dan pengembangan program Web-enabled. Menurut Rasional (pengembang Rational Rose dan Bersatu Modeling Language ), RUP adalah seperti mentor online yang menyediakan pedoman, template, dan contoh untuk semua aspek dan tahapan pengembangan program. RUP dan sejenis produk - seperti Process Object-Oriented Software (OOSP), dan Proses OPEN - alat rekayasa perangkat lunak komprehensif yang menggabungkan aspek prosedural pembangunan (seperti tahap didefinisikan, teknik, dan praktek) dengan komponen lain dari pembangunan (seperti dokumen, model, manual, kode, dan sebagainya) dalam kerangka pemersatu.


Diagram Rational Unfield Process :

 Proses/cara kerja:

Cara kerja RUP itu didasarkan pada 6 kunci prinsip bagi perkembangan bisnis yang terkendali yaitu :
1.   Mengadaptasi proses
2.   Menyeimbangkan prioritas dari para stakeholders
3.   Melakukan kolaborasi antar tim
4.   Mendemonstrasikan hasil-hasil yang ada secara berulang-ulang
5.   Menaikkan level abtraksi dari sebuah software
6.   Memfokuskan pada kualitas secara terus-menerus

Kelebihan dan kekurangan:

Ada beberapa keuntungan dengan mengunakan RUP di antaranya :
1.     Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
2.     Menyediakan petunjuk bagaimana menggunakan UML secara efektif.
3.     Mendukung proses pengulangan dalam pengembangan software.
4.     Memungkinkan adanya penambahan-penambahan pada proses.
5.     Memungkinkan untuk secara sistematis mengontrol perubahan- perubahan yang terjadi pada
        software selama proses pengembangannya.
6.      Memungkinkan untuk menjalankan test case dengan menggunakan Rational TestManager Tool
         kekurangan Pengembangan Perangkat Lunak RUP.

KEKURANGANNYA:

1.     Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak yangberorientasi objek dengan berfokus pada UML (Unified Modeling Language)

5. Time Boxing Model

       Time boxing adalah proses menunda fitur untuk versi aplikasi di masa mendatang untuk melengkapi versi saat ini sebagai ketepatan waktu.Ketepatan waktu merupakan aspek penting dari RAD, karena tanpa itu ruang lingkup dapat mengancam untuk memperpanjang iterasi pembangunan, sehingga membatasi umpan balik dari klien, meminimalkan manfaat dari pembangunan berulang, dan berpotensi mengembalikan proses kembali ke pendekatan metodologi air terjun.

    Dengan waktu kotak tiga tahap, paling banyak tiga iterasi dapat bersamaan berlangsung. Jika kotak waktu adalah hari ukuran T, maka pengiriman perangkat lunak pertama akan terjadi setelah hari T. Pengiriman berikutnya, bagaimanapun, akan berlangsung setelah setiap T / 3 hari. Misalnya, jika waktu durasi kotak T adalah 9 minggu (dan masing-masing durasi tahap adalah 3 minggu), pengiriman pertama dilakukan 9 minggu setelah dimulainya proyek. Pengiriman kedua dilakukan setelah 12 minggu, ketiga setelah 15 minggu, dan sebagainya. Kontras ini dengan eksekusi linear iterasi, dimana pengiriman pertama akan dilakukan setelah 9 minggu, yang kedua setelah 18 minggu, ketiga setelah 27 minggu, dan sebagainya

Tabel Keuntungan dan Kerugian dari TIME BOXING MODEL :

Keuntungan	kekurangan
Mempercepat proses pembangunan dan memperpendek waktu pengiriman Nah cocok untuk mengembangkan proyek-proyek dengan sejumlah fitur dalam periode waktu yang singkat.	Manajemen proyek menjadi lebih kompleks. Tidak cocok untuk proyek-proyek di mana seluruh pekerjaan pembangunan tidak dapat dibagi menjadi beberapa iterasi hampir, durasi yang sama.

6. Extreme Programming Dan Agile

 

Extreme Programming (XP) merupakan salah satu metode pengembangan software yang termasuk dalam Agile Software Development. XP menggunakan pendekatan object-oriented.

Dalam XP, terdapat 5 nilai yang menjadi pondasi yaitu communication, simplicity, feedback, courage, dan respect. Komunikasi yang efektif antara pengembang perangkat lunak dan pihak-pihak yang terlibat sangatlah penting. Dalam XP, desain dijadikan kebutuhan intermediate. Desain dibuat sesederhana mungkin agar mudah mengimplementasikan code. Disini dapat terjadi perubahan struktur desain atau perubahan source code tanpa mengubah fungsi utamanya (refactoring). Feedback akan diberikan saat peningkatan dan pengimplementasian perangkat lunak.

Cara Kerja Extreme Programming :

• Perencanaan XP: pengumpulan user stories dari klien yang klien tetapkan prioritasnya. Setiap story ditetapkan harga dan lama pembangunan, jika terlalu besar, story dapat dipecah menjadi beberapa story yang lebih kecil. Periksa dan pertimbangkan resiko
• Desain XP berprinsip: sederhana memanfaatkan kartu CRC (Class-Responsibility-Collaborator) untuk identifikasi dan mengatur class-class di konsep OO. Jika temui kesulitan, prototype dibangun (ini namanya spike solution). Lakukan refactoring, yaitu mengembangkan desain dari program setelah ditulis.
• Pengkodean XP: siapkan unit test sebelum pengkodean dipakai sebagai fokus pemrogram untuk membuat program. Pair programming dilakukan untuk real time program solving dan real time quality assurance
• Pengujian XP: menggunakan unit test yang dipersiapkan sebelum pengkodean.

Keunggulan:

• Menjalin komunikasi yang baik dengan klien. (Planning Phase)
• Menurunkan biaya pengembangan (Implementation Phase)
• Meningkatkan komunikasi dan sifat saling menghargai antar developer. (Implementation Phase)
• XP merupkan metodologi yang semi formal. (Planning Phase)
• Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima, atau dengan kata lain fleksibel. (Maintenance Phase)

Kelemahan :

• Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).XP juga memiliki keunggulan yang sekaligus menjadi kelemahannya, yaitu XP tidak memiliki dokumentasi formal yang dibuat selama pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user.

AGILE

Agile Development Methods adalah sekelompok metodologi pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun. 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.^[1] 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.

Dalam proses pengembangan agile kita mengenal dengan iterasi atau perulangan. Jika suatu proyek pengembangan software dikerjakan dengan menggunakan metode agile, maka selama waktu pengerjaannya akan selalu dijumpai proses pengembangan yang dilakukan berulang. Setiap perulangan (iterasi) meliputi berbagai kegiatan yang wajib dilakukan dalam proyek pengembangan software itu sendiri, yaitu:

a.  Requierements Analysis: langkah ini merupakan analisa terhadap kebutuhan system. Pengumpulan data dalam tahap ini bisa melakukan sebuah penelitian, wawancara atau study literature. Seorang system analisis akan menggali informasi sebanyak-banyaknya dari user sehingga akan tercipta sebuah sistem komputer yang bisa melakukan tugas-tugas yang diinginkan oleh user tersebut. Tahapan ini akan menghasilkan dokumen user requierements atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan system. Dokumen inilah yang akan menjadi acuan system analis untuk menerjemahkan ke dalam bahasa pemrograman.

b.     Desain: Proses desain akan menerjemahkan syarat kebutuhan ke sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat koding. Proses ini berfokus pada: struktur data arsitektur perangkat lunak, representasi interface, dan detail (algoritma) procedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirement. Dokumen inilah yang akan digunakan programmer untuk melakukan aktivitas pembuatan sistemnya.

c.    Coding: Coding merupakan penerjemahan design dalam bahasa yang bisa dikenali oleh computer. Dilakukan oleh programmer yang akan menterjemahkan transaksi yang diminta oleh user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan suatu system. Dalam artian penggunaan computer akan dimaksimalkan dalam tahapan ini.

d.   Testing: Testing adalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki.

Kelebihan dari agile:

1.       Meningkatkan kepuasan kepada klien.

2.       Dapat melakukan review pelanggan mengenai software yang dibuat lebih awal.

3.       Pembangunan system dibuat lebih cepat.

4.       Mengurangi resiko kegagalan implementasi software dari segi non-teknis.

5.       Jika pada saat pembangunan system terjadi kegagalan kerugian dari segi materi relatif kecil.

Kekurangan dari agile:

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

2.       Agile tidak akan berjalan dengan baik jika komitmen tim kurang.

3.       Tidak cocok dalam skala tim yang besar (>20 orang).

4.       Perkiraan waktu release dan harga perangkat lunak sulit ditentukan

 

Continue