Rabu, 08 Maret 2017

Metode - Metode SDLC (Systems Development Life Cycle)

1. Model Waterfall
Waterfall merupakan salah satu metode dalam SDLC yang mempunyai ciri khas pengerjaan setiap fase dalam watefall harus diselesaikan terlebih dahulu sebelum melanjutkan ke fase selanjutnya. Artinya fokus terhadap masing-masing fase dapat dilakukan maksimal karena tidak adanya pengerjaan yang sifatnya paralel.

Fase dalam Metode Waterfall
Tahapan tahapan dari metode waterfall adalah sebagai berikut :

  • Requirement Analysis
    Seluruh kebutuhan software harus bisa didapatkan dalam faseini, 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.
  • System Design
    Tahap ini dilakukan sebelum melakukan coding. Tahap inibertujuan  untuk  memberikan  gambaran  apa  yang  seharusnyadikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan  kebutuhan  hardware  dan  sistem  sertamendefinisikan arsitektur sistem secara keseluruhan.
  • Implementation
    Dalam tahap ini dilakukan pemrograman. Pembuatan softwaredipecah  menjadi  modul-modul  kecil  yang  nantinya  akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap inijuga dilakukan pemeriksaaan terhadap modul yang dibuat, apakahsudah memenuhi fungsi yang diinginkan atau belum
  • Integration & Testing
    Di  tahap  ini  dilakukan  penggabungan modul-modul  yangsudah  dibuat  dan  dilakukan  pengujian  ini  dilakukan  untuk mengetahui apakah software yang dibuat telah sesuai dengandesainnya dan masih terdapat kesalahan atau tidak
  • Operation & Maintenance
    Ini merupakan tahap terakhir dalam model waterfall. Softwareyang  sudah  jadi  dijalankan  serta  dilakukan  pemeliharaan. Pemeliharaan termasuk dalam memperbaiki  kesalahan yang tidakditemukan pada langkah sebelumnya. Perbaikan implementasi unitsistem dan peningkatan jasa sistem sebagai kebutuhan baru. 



Kapan sebaiknya model water fall digunakan? 
Teori-teori menyimpulkan beberapa hal, yaitu:
  1. Ketika semua persyaratan sudah dipahami dengan baik di awal pengembangan.
  2. Definisi produk stabil dan tidak ada perubahan saat pengembangan untuk alasan apapun seperti perubahan eksternal, perubahan tujuan, perubahan anggaran atau perubahan teknologi. Untuk itu, teknologi yang digunakan pun harus sudah dipahami dengan baik.
  3. Menghasilkan produk baru, atau versi baru dari produk yang sudah ada. Sebenarnya, jika menghasilkan versi baru maka sudah masuk incremental development, yang setiap tahapnya sama dengan Waterfall kemudian diulang-ulang.
  4. Portingproduk yang sudah ada ke dalam platform
Dengan demikian, Waterfall dianggap pendekatan yang lebih cocok digunakan untuk proyek pembuatan sistem baru. Tetapi salah satu kelemahan paling dasar adalah menyamakan pengembangan perangkat keras dengan perangkat lunak dengan meniadakan perubahan saat pengembangan. Padahal, galat diketahui saat perangkat lunak dijalankan, dan perubahan-perubahan akan sering terjadi.


Contoh Penerapan Metode Waterfall
Implementasi  waterfall pada sistem pendaftaran siswa  online di SMA 1 Bandung. Di SMA 1 Bandung, sebelumnya, pendaftaran/ registrasi dilakukan secara tatap muka dating langsung ke lingkungan sekolah. Sistem akan dibuat  menggunakan bahasa pemrograman PHP, dengan basis data yang digunakan adalah MySQL yang dilakukan di perangkat keras PC (personal computer) dengan sistem operasi Microsoft Windows XP, Linux, dan lain sebagainya, yang digunakan untuk mempermudah siswa – siswi yang ingin mendaftar pada suatu sekolah, universitas, akademik tanpa harus ke suatu sekolah yang ingin kita masuki.


Kelebihan metode waterfall 
  • Proses menjadi lebih teratur, urutan proses pengerjaan menggunakan metode ini menjadi lebih teratur dari satu tahap ke tahap yang selanjutnya.
  • Dari sisi user juga lebih menguntungkan karena dapat merencanakan dan menyiapkan seluruh kebutuhan data dan proses yang akan dipperlukan.
  • Jadwal menjadi lebih menentu, jadwal setiap proses dapat ditentukan secara pasti. Sehingga dapat dilihat jelas target penyelesaian pengembangan program. Dengan adanya urutan yang pasti, dapat dilihat pula progress untuk setiap tahap secara pasti.
Kelemahan metode waterfall :

  • Sifatnya kaku, sehingga susah melakukan perubahan di tengah proses.
  • Jika terdapat kekuarangan proses atau prosedur dari tahan sebelumnya, maka tahapan pengembangan harus dilakukan mulai dari awal. Hal ini akan memakan waktu yang cukup lama. Karena jika proses sebelumnya belum selesai sampai akhir, maka proses selanjutnya juga tidak dapat berjalan. Maka, jika terdapat kekuarangan dalam permintaan user, proses pengembangan harus dimulai dari awal.
  • Membutuhkan daftar kebutuhan yang lengkap di awal, tapi jarang konsumen bisa memberikan kebutuhan secara lengkap diawal.
  • Untuk menghindari pengulangan tahap dari awal, user harus memberikan seluruhh prosedur, data dan laporan yang diinginkan mulai dari tahap awal pengembangan. Tetapi di banyak kondisi, user sering melakukan permintaan si tahap pertengahan pengembangan sistem.
  • Dengan metode ini, maka development  harus dilakukan mulai dari tahap awal. Karena development  disesuaikan dengan design hassil user pada saat tahap awal pengembangan.



2. Model Spiral
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:
1. Customer communication.
Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.
2. Planning.
Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.
3. 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.
4. Engineering.
Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.
5. 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.
6. 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:
Kelebihan model Spiral :
  1. Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.
  2. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar.
  3. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .
  4. Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap keadaan di dalam evolusi produk.
  5. Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya ke dalam kerangka kerja iteratif .
  6. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko sebelum menjadi permaslahan yang serius.
Kelemahan model Spiral :
  1. Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.
  2. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur.
  3. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolut



3. Model Prototype 
Proto type adalah suatu proses yang memungkinkan developer membuat sebuah model software,metode ini baik digunakan apabila client tidak bisa memberikan informasi yang maksimal mengenai kebutuhan yang diinginkannya. Seringkali seorang customer sulit menentukan input yang lebih terinci, proses yang diinginkan dan output yang diharapkan hal tersebut menyebabkan developer tidak yakin dengan efisiensi alogoritma yang di buatnya, sehingga sulit dalam menyesuaikan sistem operasi, serta interaksi manusia dan mesin yang harus diambil. Dalam hal seperti ini, pendekatan prototype untuk software engineering merupakan langkah yang terbaik.
Secara ideal prototype berfungsi sebagai subuah mekanisme untuk mengidentivikasi kebutuhan software, bila prototype yang sedang bekerja dibangun pengembangannya harus menggunakan fragmen-fragmen program yang ada atau mengaplikasikan alat-alat bantu (contohnya : report generator, window manager dll) dimana memungkinkan program yang bekerja untuk dimunculkan secara cepat. Prototype dibedakan menjadi 2, yaitu :
  1. Paper Prototype, menggambarkan interaksi manusia dan mesin dalam sebuah bentuk yang memungkinkan user mengerti bagaimana interaksi itu terjadi.
  2.  Working Prototype, adalah prototype yang mengimplementasikan beberapa bagian dari fungsi software yang diinginkan seperti pada pendekatan pengembangan software. Model ini dimulai dengan :

  • Pengumpulan kebutuhan developer dan customer
  • Menentukan semua tujuan software
Tujuan Prototype
Prototyping model sendiri mempunyai tujuan yaitu mengembangkan model awal software menjadi sebuah sistem yang final.
Proses Prototype
Proses-proses dalam model prototyping 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
  1. Perancangan
perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype
  1. Evaluasi Prototype 
klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.
Tahapan-tahapan Prototype
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.
  1. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).
  1. 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.
  1. Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.
  1. 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.
  1. 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.
  1. Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan




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

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.



4. Model Rapid Application Development (RAD)


Rapid Application Development (RAD) adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut : bussiness modeling, data modeling, process modeling, application generation dan testing and turnover.
Model Pengembangan Sistem Informasi Berbasis Web
1. Berikut adalah beberapa model pengembangan informasi berbasis web, yaitu :
Metode RAD (Rapid Application Development)
  • Merupakan metode pengembangan sistem secara linear sequential yang menekankan pada siklus pengembangan yang sangat singkat.
  • Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60-90 hari).
  • Pemakai sistem dapat mendefinisikan kebutuhan perangkat lunak dengan baik.
  • Pemakai sistem bersedia meluangkan waktu yang cukup untuk berkomunikasi intensif dengan pengembang sehubungan dengan pengembangan perangkat lunak
Rapid Application Development adalah seperangkat strategi yang terintegrasi yang ada dalam suatu kerangka kerja meneyeluruh yang disebut Information Engineering (IE).
ALASAN MEMILIH METODE RAD
Di dalam memilih metode RAD harus memperhatikan alasan-alasan berikut ini:
1. Alasan yang Buruk
  • Apabila menggunakan RAD hanya untuk menghemat biaya pengembangan suatu sistem. Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang mengerti betul
    mengenai manajemen biaya. Sebab bila tidak, maka biaya yang dikeluarkan akan menjadi lebih besar.
  • Apabila menggunakan RAD hanya untuk menghemat waktu pengembangan suatu sistem. Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang mengerti betul mengenai manajemen waktu. Sebab bila tidak maka waktu yang dibutuhkan akan menjadi lebih lama.
  1. Alasan yang Baik
  • Apabila menggunakan RAD untuk mendapatkan suatu desain yang dapat diterima oleh konsumen dan dapat dikembangkan dengan mudah.
  • Apabila menggunakan RAD untuk memberikan batasan-batasan pada suatu system supaya tidak mengalami perubahan.
  • Apabila menggunakan RAD untuk menghemat waktu, dan kalau memungkinkan bisa menghemat biaya serta menghasilkan produk yang berkualitas.
Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut :
  1. Bussiness modeling
Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan berikut : informasi apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya? 
  1. 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.
  1. Prosess modelling
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.
  1. 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. 
  1. 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 RAD
Beberapa keuntungan dalam menggunakan metode RAD adalah sebagai berikut:
  • Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.
  • Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.
  • Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.
  • Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.
  • Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.
  • Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.
  • Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).
  • Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.
  • Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.
Kelemahan RAD
Beberapa kerugian dalam menggunakan metode RAD adalah sebagai berikut :

  • Dengan melakukan pembelian belum tentu bisa menghemat biaya dibanding-
    kan dengan mengembangkan sendiri.
  • Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.
  • Kesulitan melakukan pengukuran mengenai kemajuan proses.
  • Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.
  • Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal
    dalam melakukan pengkodean.
  • Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan diban-
    dingkan dengan biaya dan kualitas.
  • Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.
  • Sistem sulit diaplikasikan di tempat yang lain.
  • Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.



5. Model Iteratif


Dalam model Iteratif, proses berulang dimulai dengan implementasi sederhana dari satu set kecil dari persyaratan perangkat lunak dan iteratif meningkatkan versi berkembang hingga sistem lengkap diimplementasikan dan siap untuk digunakan.
Model siklus hidup berulang tidak mencoba untuk memulai dengan spesifikasi lengkap dari persyaratan. Sebaliknya, pembangunan dimulai dengan menentukan dan melaksanakan hanya bagian dari perangkat lunak, yang kemudian Ulasan untuk mengidentifikasi persyaratan lebih lanjut. Proses ini kemudian diulang, memproduksi versi baru dari perangkat lunak pada akhir setiap iterasi dari model.

Desain Model Iteratif

proses berulang dimulai dengan implementasi sederhana dari subset dari kebutuhan perangkat lunak dan iteratif meningkatkan versi berkembang sampai sistem penuh diimplementasikan. Pada setiap iterasi, modifikasi desain yang dibuat dan kemampuan fungsional baru ditambahkan. Ide dasar di balik metode ini adalah untuk mengembangkan sistem melalui siklus berulang (iteratif) dan dalam porsi yang lebih kecil pada waktu (incremental).
Berikut ini adalah representasi bergambar model Iterative dan Incremental:


pengembangan berulang dan Incremental adalah kombinasi dari kedua desain iteratif atau metode iteratif dan incremental membangun model untuk pembangunan. "Selama pengembangan perangkat lunak, lebih dari satu iterasi dari siklus pengembangan perangkat lunak mungkin berlangsung pada saat yang sama." dan "Proses ini dapat digambarkan sebagai" akuisisi evolusi "atau" inkremental membangun "pendekatan."
Dalam model inkremental seluruh persyaratan dibagi menjadi berbagai membangun. Pada setiap iterasi, modul pengembangan melewati fase persyaratan, desain, implementasi dan pengujian. Setiap rilis berikutnya dari modul menambahkan fungsi untuk rilis sebelumnya. Proses berlanjut sampai sistem lengkap siap sesuai kebutuhan.
Kunci keberhasilan penggunaan suatu siklus pengembangan perangkat lunak berulang adalah validasi yang ketat dari persyaratan, dan verifikasi & testing setiap versi dari perangkat lunak terhadap persyaratan dalam setiap siklus model. Sebagai perangkat lunak berkembang melalui siklus berturut-turut, tes harus diulang dan diperluas untuk memverifikasi setiap versi perangkat lunak.

Aplikasi Model berulang

Seperti model lain SDLC, pengembangan Iteratif dan incremental memiliki beberapa aplikasi spesifik di industri perangkat lunak. Model ini paling sering digunakan dalam skenario berikut:

  • Persyaratan sistem lengkap yang jelas dan dipahami.
  • Persyaratan utama harus didefinisikan; Namun, beberapa fungsi atau perangkat tambahan yang diminta dapat berkembang dengan waktu.
  • Ada waktu untuk kendala pasar.
  • Sebuah teknologi baru yang digunakan dan sedang dipelajari oleh tim pengembangan saat bekerja pada proyek.
  • Sumber daya dengan keahlian yang dibutuhkan tidak tersedia dan direncanakan akan digunakan atas dasar kontrak untuk iterasi tertentu.
  • Ada beberapa fitur berisiko tinggi dan tujuan yang mungkin berubah di masa depan.


Pro Model berulang dan Kontra

Keuntungan dari model ini adalah bahwa ada model kerja sistem pada tahap yang sangat awal pembangunan yang membuatnya lebih mudah untuk menemukan kekurangan fungsional atau desain. Menemukan masalah pada tahap awal pengembangan memungkinkan untuk mengambil langkah-langkah perbaikan dalam anggaran yang terbatas.
Kerugian model SDLC ini adalah bahwa hal itu hanya berlaku untuk proyek-proyek pengembangan perangkat lunak besar dan besar. Hal ini karena sulit untuk memecahkan sistem software kecil ke lebih kecil berguna bertahap / modul.

berikut berisi daftar pro dan kontra dari Iteratif dan Incremental SDLC Model:

PRO :

  • Beberapa fungsi kerja dapat dikembangkan dengan cepat dan di awal siklus hidup.
  • Hasil yang diperoleh lebih awal dan berkala.
  • pembangunan paralel dapat direncanakan.
  • Kemajuan dapat diukur.
  • Lebih murah untuk mengubah lingkup / persyaratan.
  • Pengujian dan debugging selama iterasi yang lebih kecil mudah.
  • Risiko diidentifikasi dan diselesaikan selama iterasi; dan setiap iterasi merupakan tonggak mudah dikelola.
  • Mudah untuk mengelola risiko - bagian risiko tinggi dilakukan pertama.
  • Dengan setiap kenaikan operasional produk disampaikan.
  • Permasalahan, tantangan & risiko yang teridentifikasi dari setiap kenaikan dapat dimanfaatkan / diterapkan pada kenaikan berikutnya.
  • analisis risiko yang lebih baik.
  • Mendukung perubahan kebutuhan.
  • Waktu operasi awal kurang.
  • Lebih baik cocok untuk proyek-proyek besar dan mission-critical.
  • Selama hidup perangkat lunak siklus diproduksi awal yang memfasilitasi evaluasi pelanggan dan umpan balik.


KONTRA :

  • Lainnya mungkin diperlukan.
  • Meskipun biaya perubahan yang lebih rendah tetapi tidak sangat cocok untuk mengubah persyaratan.
  • Lebih perhatian manajemen diperlukan.
  • arsitektur sistem atau desain masalah mungkin timbul karena tidak semua persyaratan yang berkumpul di awal seluruh siklus hidup.
  • Mendefinisikan bertahap mungkin memerlukan definisi dari sistem yang lengkap.
  • Tidak cocok untuk proyek-proyek kecil.
  • kompleksitas manajemen lebih.
  • Akhir proyek mungkin tidak diketahui yang merupakan risiko.
  • sumber yang sangat terampil yang diperlukan untuk analisis risiko.
  • kemajuan Project.s sangat tergantung pada fase analisis risiko.




6. Model Build & Fix

 Metode Build and fix pertama kali di pakai oleh perusahaan Volkswagen pada tahun 1950 – 1960 untuk memproduksi dan memasarkan serta membuat customer merasa puas dengan produk mereka. Oleh karena itu, Volkswagen selalu melakukan update terhadap produk mereka tanpa melakukan tes apakah mobil itu dirasa cocok oleh customer atau tidak. Maka dari itu, customerlah yang menentukan sendiri sikap mereka terhadap produk Volkswagen apakah sudah sesuai ataukah harus ada perbaikan di sana sini karena adanya laporan dari beberapa masalah / problem ( bisa di sebut juga : damage control ). Metode ini berjalan dengan sangat baik. Tapi, ini tergantung bagaimana setiap pelanggan, user, client memperlakukan produk anda. Setiap pernyataan terhadap produk anda akan berbeda – beda dari setiap customer karena di proses awal tidak di lakukan proses testing dan analisa terlebih dahulu. Hal inilah yang membuat perusahaan mobil Volkswagen selalu melakukan update terbaru atau hanya sekedar melakukan pembenahan, perbaikan produk – produk mereka hanya untuk memenuhi keinginan kepuasan customer. 



Hal itu semua sangat sama dengan pengembangan produk dari sebuah software. Karena software yang di kembangkan dengan Build and fix, tidak memiliki identitas dari kualitas software itu sendiri. hal itu di karenakan software tersebut tidak menjalani proses testing sebelumnya dan menggunakan end user sebagai tester.

Didalam Build and fix sendiri juga tidak ada tahap analisis. Dimana seharusnya di metode  - metode SDLC lainnya selalu ada dan sangat di perlukan sekali karena merupakan langkah yang paling vital. Tanpa menganalisis terlebih dahulu, seorang developer tidak dapat mengetahui system yang akan dibuat dan juga tidak mengetahui keperluan dari user itu seperti apa dan sampai sejauh mana. Oleh karena itu, di dalm metode ini seorang developer langsung masuk ketahap design.

 Tahap design dalam Build and fix di bagi menjadi dua yaitu :

  1. Functional design
    Dalam Functional design, seorang developer melakukan perancangan fungsi terhadap produk yang akan dibuatnya. Initinya adalah, software seperti apa yang akan dibuat dan untuk apa
  2. Technical Design
    Dalam Technical Design, seorang developer melakukan perancangan teknis terhadap produk yang akan dibuatnya. Initinya adalah, software yang dibuat akan berjalan seperti apa dan bagaimana.
Setelah melakukan proses design, seorang developer yang memakai metode build and Fix memasuki proses implementasi. Arti dari implementasi disini sendiri adalah, melaksanakan dan membuat produk berdasarkan rencana rancangan design yang telah di tetapkan sebelumnya. Setelah produk yang dibuat jadi, maka developer memasuki tahap pemasaran / peluncuran / Deployment. Di tahap ini, seorang developer memasarkan atau menjual produk yang telah jadi ke customer dan digunakan oleh customer untuk dalam tahapan Usage. Ditahapan Usage inilah, customer juga bertindak sebagai tester. Jika dalam penggunaannya di ketahui ada masalah atau ada kekurangan maka customer melaporkan masalah tersebut ke vendor dari produk yang telah dipasarkan oleh developer sebagai sebuah kerusakan dan kekurangan dari produk yang bersangkutan. Dari laporan itu, pihak vendor mengevaluasi kerusakan yang dilaporkan oleh customer. Dengan bantuan dari developer, vendor lalu memperbaiki kerusakan yang dialami oleh customer. Dari laporan kerusakan dan serba kekurangan itu developer dapat memperbarui produk mereka demi kepuasan pelanggan.

Karena Build and fix lebih mengarah kepada “ damage control ” dan kepuasan pelanggan maka build and fix mulai ditinggalkan. Meskipun masih banyak juga pengembang software yang menggunakan metode ini. Pastinya, pengembang software yang memakai metode ini adalah pengembang software yang bonafit atau berbudget besar. Karena di metode ini, developer harus menggelontorkan banyak sekali modal hanya untuk di pembiayaan maintenance saja


         Bisa dilihat dari diagram diatas, planning di dalam Build and fix sangatlah sedikit. Menyusul berikutnya requirements yang juga tidak terlalu di perhatikan. Begitu juga analisis yang begitu sangat sedikit prosesnya dan cenderung masuk ke bagian design yang ada di urutan ke-empat. proses implementasi, integrasi masih begitu di perlukan dalam metode ini. Dan yang paling mencolok adalah maintenance yang begitu besar.


Proses Build and fix dapat di persingkat gambar alur tahapan prosesnya menjadi seperti berikut :


Kelebihan dari Build and fix sendiri sangatlah minim. Karena kelebihan itu sendiri merupakan gambaran dari kelemahannya. Karena seperti kita ketahui, build and fix dibuat tanpa melalui tahapan analisis dulu. Karena itu Build and fix sangat cocok di gunakan ketika harus membuat software yang tidak memiliki kompleksitas tinggi sehingga mengurangi kesempatan program untuk mengalami error, bug, hang, atau semacamnya. Dengan begitu pihak pengembang dapat mengurangi seminimal mungkin pembiayaan untuk maintenance.
Oleh karene itu, build and fix memiliki kelemahan tidak cocok ketika di pakai untuk membuat produk dengan kompleksitas tinggi dan dengan ukuran yang besar. Biaya yang di butuhkan akan menjadi sangat membengkak dan membesar ketika build and fix di gunakan untuk membuat projek berskala besar. Karena semakin besar produk yang di hasilkan maka, akan sangat sering maintenance di lakukan.  Kembali lagi ke masalah utama dari build and fix adalah metode ini tidak memasukkan analisa sebagai tahapan awalnya dan testing dalam pembuatannya, maka produk yang di hasilkan dengan metode ini sangat standart atau bahkan cenderung buruk. Jikapun kalau produk yang di hasilkan berkualitas sangat bagus, pasti produk tersebut di buat oleh pengembang – pengembang software yang berpengalaman dan berkantong tebal ( yang tentunya harus melalui berbagai update  ).
Karena begitu banyak kelemahannya, Build and fix menjadi sangat cocok untuk digunkan sebagai metode pembelajaran dalam membuat suatu produk. Karena produk yang dibuat harus berukuran kecil ( produk disini berarti software ) .

Kesimpulan dari Build and Fix method
Build and fix merupakan metode yang pertamanya ( sebelum digunakan sebagai metode pengembangan software ) digunakan bertujuan untuk memberikan kepercayaan kepada konsumen dengan memberikan layanan berupa perbaikan dan perawatan secara continue terhadap produk yang di gunakan oleh konsumen. Jadi proses maintenance terus berjalan hingga kepuasan customer terpenuhi.
Selain itu, karena build and fix tidak melakukan analisa dan testing sebelumnya, para developer pengguna metode ini menggunakan konsumen mereka sebagai tester untuk mengetahui kekurangan dan juga sebagai feedback untuk upgrade produk yang telah dihasilkan sebelumnya.  
Karena banyak sekali kelemahan dari metode ini, maka metode ini sangat cocok digunakan hanya sebatas untuk pembelajaran dalam membuat software berskala kecil / mikro.
Increment Method dapat menjadi Build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa. Karena proses pertama dari increment method yang melihat dari kemungkinan “ feasibility 





7. Model Fountain




Model Fontain merupakan perbaikan logis dari model waterfall, langkah langkah dan urutan prosedurnya pun masih sama. Namun pada model Fountain ini kita dapat mendahulukan sebuah step ataupun melewati step tersebut, akan tetapi ada yang tidak bisa anda lewati stepnya seperti kita memerlukan design sebelum melakukan coding jika itu di lewati maka akan ada tumpang tindih dalam siklus SDLC.

Langkah – Langkah dalam Model Fountain:
  • User requirements analysis ( Analisis Kebutuhan Pengguna), disini kita sebagai programmer dalam mengembangkan sistem harus menganalisa kebutuhan terhadap pengguna baik itu dalam cara penggunaan yang mudah maupun efisiensi terhadap sistem yang pengguna butuhkan.
  • User requirements specifications (Spesifikasi kebutuhan pengguna), dalam tahap ini kita harus tahu apa saja yang dibutuhkan pengguna dalam sistem yang sedang kita kembangkan.
  • Software requirements specifications (Spesifikasi persyaratan perangkat lunak), dalam tahap ini kita harus menyesuaikan software yang kita buat jika di lihat dari sisi pengguna. Jika pengguna awam tentunya kita harus menciptakan Software yang mudah digunakan.
  • Systems/broad design (logical design), sebelum pengimplementasi dalam coding kita harus mendesain sistem yang akan kita buat / kembangkan.
  • Program/detailed design (physical design), dalam tahap ini kita membuat desain yang mendekati fisik atau secara deail.
  • Implementation/coding, setelah tahap desain barulah kita mengimplementasikan dalam coding
  • Program testing: units, dalam tahap ini kita testing / cek kembali unit nit yang dibutuhkan dalam sistem yang sedang kita kembangkan .
  • Program testing: system, dalam tahap ini kita test kembali sistem yang telah kita buat.
  • Program use, dalam tahap ini kita ajarkan ke pengguna program yang telah kita buat.
  • Software maintenance, setelah sistem di pasang maka tentunya kita harus rutin mengupdate software / sistem yang telah kita buat agar terhindar dari kesalaha / bugs.






8. Synchronize and Stabilize 

Ide dibalik model synchronize and stabilize cukup sederhana: secara berkesinambungan melakukan synchronize terhadap pekerjaan yang dilakukan oleh tim secara paralel, dan secara periodik melakukan stabilize terhadap produk sampai produk itu selesai. Microsoft menggunakan pendekatan dalam pengembangan software dan organisasi tim sejak akhir tahun 1980an terhadap produk-produknya, termasuk Office, Publisher, Windows 95/98, Windows NT dan menuai sukses terhadap hasil produknya.

Secara umum gambaran tim yang dibuat dapat dilihat pada gambar di bawah. Sejak produk-produk Microsoft diluncurkan ke pasar (dalam hal tertentu ke client tertentu), masing-masing produk terdiri atas Manager Produk yang terfokus ke satu produk dimana mempunyai suatu vision statement untuk setiap produk. Vision Statement dikembangkan menggunakan customer feedback, tujuan dari produk dan prioritas terhadap suatu fitur-fitur yang harus diselesaikan untuk membangun sebuah software. Vision Statement digunakan sebagai informasi untuk mendefinisikan fungsi spesifikasi, arsitektur dan interpendensi komponen. Seteleh fungsi spesifikasi didefinisikan, Program Manager berkoordinasi untuk mengatur jadwal terhadap Tim Fitur, dimana untuk masing-masing tim terdiri dari 1 program manager, 3-8 programmer dan 3-8 tester yang bekerja secara paralel 1:1 dengan programmer.


Organisasi tim Synchronize and Stabilize dan pendekatan pengambilan keputusan. 


Setelah fase perencanaan selesai (dimana biasanya memakan waktu antara 3 sampai 12 bulan tergantung dari besarnya dan kompleksitas dari suatu produk), project akan berlanjut ke dalam fase pengembangan. Dalam hal ini, project dibagi menjadi 3 atau 4 subproject, dimana masing-masing team melakukan siklus pengembangan (integrasi, testing dan debugging). Selama siklus tersebut, programmer bebas untuk mengembangkan komponen-komponen dan fitur-fitur secara mandiri. Rasio 1:1 programmer/tester memberikan synchronization harian untuk memastikan hasil yang sempurna dalam siklus pengembangan. Bagaimanapun, kadang-kadang terjadi error yang tidak diinginkan.

Proses tim Synchronize-and-Stabilize dapat dirangkum sebagai berikut :
  • Berorientasi kepada fitur 
  • Synchronize (pengembangan harian) and Stabilize (perbaikan kesalahan di setiap milestone) 
  • Product Managers mengembangkan vision statement dan fitur yang sesuai dengan keinginan customer. 
  • Program Managers mengembangkan fungsional spesifikasi berdasarkan vision statement. 
  • Program Managers membuat jadwal dan tim fitur paralel antara 3-8 pengembang dan penguji berdasarkan fungsional spesifikasi. 
  • Anggota tim dapat bekerja secara mandiri, sehingga dapat menghasilkan kreativitas dan kebebasan di dalam sebuah project. 
  • Fase perencanaan (3-12 bulan, tergantung besarnya suatu project)
    • vision statement 
    • specification 
    • schedule and feature team formation 
  • Fase Pengembangan (6-12 bulan) 
    • subproject I: krusial 1/3 fitur, milestone release I 
    • subproject II: 1/3 fitur, milestone release II 
    • subproject III: final 1/3 fitur, milestone release III — code complete 
  • Fase Stabilization (3-8 bulan) 
  • Internal testing 
  • External testing di bagian “beta tester” 
  • Siap untuk diluncurkan, dimana terdapat “golden master” dan dokumentasi. 



Keuntungan Dari Synchronize-And-Stabilize

Walaupun prinsip-prinsip dibalik synchronize and stabilize memberikan persamaan dalam hal cepatnya pengembangan sistem, disana tidak terdapat suatu tahap yang dapat memecahkam masalah besar dengan dengan solusi yang singkat. Melainkan, terdapat pendekatan yang spesifik, tool dan teknik, beberapa aturan yang kaku dan tingginya kemampuan orang-orang yang menggunakan pendekatan ini. Beberapa elemen membedakan synchronize and stabilize dengan beberapa pengembangan yang lebih lama.

Pendekatan synchronize and stabilize mempunyai beberapa keuntungan bagi para manajer dan engineer dalam mengembangkan suatu produk.
  • Membagi produk yang besar ke dalam bagian-bagian yang lebih kecil (prioritas dari fitur produk yang memiliki tim fitur kecil dapat dibuat dalam beberapa bulan)
  • Membuat project bekerja secara sistematis meskipun mereka tidak dapat menggambarkan dan menyelesaikan suatu produk di awal project. 
  • Mengijinkan tim besar bekerja menjadi tim yang lebih kecil dengan membagi sebuah tim menjadi beberapa bagian, bekerja secara paralel tetapi tetap dapat berkesinambungan dalam men synchronizing setiap perubahan, stabilizing produk dan menemukan serta memperbaiki kesalahan. 
  • Memfasilitasi masukkan dari customer, fitur produk dan waktu pengembangan yang pendek, yang didukung oleh mekanisme masukkan customer, prioritas, menyelesaikan dahulu bagian yang sangat penting dan melakukan perubahan tanpa harus mengurangi fitur yang diperlukan.






9. Extreme Programmning (XP)

Proyek Pemrograman Extreme pertama dimulai 6 Maret 1996. Extreme Programming adalah salah satu dari beberapa Proses Agile populer. Sudah terbukti sangat sukses di banyak perusahaan dari berbagai ukuran dan industri di seluruh dunia.

 Extreme Pemrograman berhasil karena menekankan kepuasan pelanggan. Alih-alih memberikan semua yang anda mungkin inginkan pada tanggal beberapa jauh di masa depan proses ini memberikan perangkat lunak yang Anda butuhkan saat Anda membutuhkannya. Extreme Pemrograman memberdayakan pengembang Anda untuk percaya diri menanggapi perubahan kebutuhan pelanggan, bahkan terlambat dalam siklus hidup.

 Extreme Pemrograman menekankan kerja sama tim. Pengelola, pelanggan, dan pengembang semua mitra setara dalam sebuah tim kolaboratif. Extreme Pemrograman menerapkan, sederhana namun efektif yang memungkinkan tim lingkungan menjadi sangat produktif. Tim mengorganisir diri mengatasi masalah untuk menyelesaikannya seefisien mungkin.

 Extreme Pemrograman meningkatkan proyek perangkat lunak dalam lima cara penting; komunikasi, kesederhanaan, umpan balik, rasa hormat, dan keberanian. Extreme Programmer selalu berkomunikasi dengan pelanggan mereka dan programer sesama. Mereka terus desain mereka yang sederhana dan bersih. Mereka mendapatkan umpan balik dengan menguji perangkat lunak mereka dimulai pada hari pertama. Mereka memberikan sistem ke pelanggan sebagai perubahan sedini mungkin dan melaksanakan seperti yang disarankan. Setiap keberhasilan kecil memperdalam rasa hormat mereka atas kontribusi yang unik dari masing-masing dan setiap anggota tim. Dengan dasar Extreme pemrogram dapat berani merespon perubahan kebutuhan dan teknologi.
Aspek yang paling mengejutkan dari Extreme Programming adalah aturan sederhana. 

 Extreme Pemrograman sangat mirip jig gergaji teka-teki. Ada banyak potongan-potongan kecil. Individual potongan

 Extreme Programming adalah metode pengembangan perangkat lunak yang ringan dan termasuk salah satu agile methods yang dipelopori oleh Kent Beck, Ron Jeffries, dan Ward Cunningham. Extreme Programming merupakan agile methods yang paling banyak digunakan dan menjadi sebuah pendekatan yang sangat terkenal. Sasaran Extreme Programming adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini dimaksudkan untuk menghadapi requirements yang tidak jelas maupun terjadinya perubahan-perubahan requirements yang sangat cepat.

 Extreme Programming sebagai sebuah metode yang dinamis diperlihatkan dalam empat values yang dimilikinya dan keempatnya merupakan dasar-dasar yang diperlukan dalam Extreme Programming. Kent Beck menyatakan bahwa tujuan jangka pendek individu sering berbenturan dengan tujuan sosial jangka panjang. Karena itu dibuatlah values yang menjadi aturan, hukuman, dan juga penghargaan. Keempat values tersebut adalah :

  • Komunikasi (Communication)

Tugas utama developer dalam membangun suatu sistem perangkat lunak adalah mengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak. Komunikasi dalam Extreme Programmning dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Tujuannya untuk memberikan pandangan pengembang sesuai dengan pandangan pengguna sistem.

  • Kesederhanaan (Simplicity)

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

  • Umpan Balik (Feedback)

Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dari aplikasi yang dibangun. Informasi ini harus dikumpulkan setiap interval waktu yang singkat secara konsisten. Ini dimaksudkan agar hal-hal yang menjadi masalah dalam proses pengembangan dapat diketahui sedini mungkin. Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).

  • Keberanian (Courage)

Berani mencoba ide baru. Berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki. Contoh dari courage adalah komitmen untuk selalu melakukan design dan coding untuk saat ini dan bukan untuk esok. Ketika ada kode yang terlalu rumit, sulit dibaca dan dipahami, tidak sesuai dengan kemauan pelanggan, dll maka seharusnya kode program seperti itu di refactor (kalau perlu dibangun ulang). Hal ini menjadikan pengembang merasa nyaman dengan refactoring program ketika diperlukan.


Berikut merupakan proses Extreme Programming menurut Pressman (2010):
  1. Planning. Tahap planning dimulai dengan membuat user stories yang menggambarkan output, fitur, dan fungsi-fungsi dari software yang akan dibuat. User stories tersebut kemudian diberikan bobot seperti prioritas dan dikelompokkan untuk selanjutnya dilakukan proses delivery secara incremental. 
  2. Design. Design di Extreme Programming mengikuti prinsip Keep It Simple (KIS). Untuk design yang sulit, Extreme Programming akan menggunaan Spike Solution dimana pembuatan design dibuatlangsung ke tujuannya. Extreme Programming juga mendukung adanya refactoring dimana software system diubah sedemikian rupa dengan cara mengubah stuktur kode dan menyederhanakannya namun hasil dari kode tidak berubah. 
  3. Coding. Proses coding pada XP diawali dengan membangun serangkaian unit test. Setelah itu pengembang akan berfokus untuk mengimplementasikannya. Dalam Extreme Programmingdiperkenalkan istilah Pair Programming dimana proses penulisan program dilakukan secara berpasangan. Dua orang programmer saling bekerjasama di satu komputer untuk menulis program. Dengan melakukan ini akan didapat real-time problem solving dan real-time quality assurance. 
  4. Testing. Tahap ini dilakukan pengujian kode pada unit test. Dalam Extreme Programming,diperkenalkan XP acceptance test atau biasa disebut customer test. Tes ini dilakukan oleh customer yang berfokus kepada fitur dan fungsi sistem secara keseluruhan. Acceptance test ini berasal dari user stories yang telah diimplementasikan.





Sumber : 

- https://rifkanisa19.wordpress.com/2014/08/23/macam-macam-model-pengembangan-software/
- http://www.w3ii.com/id/sdlc/sdlc_iterative_model.html
- http://ziziramzi7.blogspot.co.id/2012/10/v-behaviorurldefaultvmlo.html
- http://catatanngampusku.blogspot.co.id/2014/10/metodologi-sdlc.html
- http://adikristanto.net/synchronize-and-stabilize/
- https://dwijaantara.wordpress.com/2010/10/25/agile-method/
- http://infodanpengertian.blogspot.co.id/2016/01/pengertian-dan-proses-extreme.html


Diposting oleh di Tidak ada komentar:
Langganan: Komentar (Atom)