Metode SDLC Extreme Programming (Agile)

Extreme Programming merupakan salah satu dari sekian banyak metodologi pengembangan sistem. Extreme Programming ditujukan kepada mereka yang melakukan pengembangan sistem secara cepat. Extreme Programming merupakan salah satu cara untuk mengatasi perubahan situasi dan kondisi yang cepat. Extreme Programming merupakan salah satu model proses dari Agile Software Development yang merupakan salah satu metodologi dalam pengembangan sistem berbasis Software Development Life Cycle (SDLC). Extreme Programming atau yang dikenal sebagai XP adalah sebuah model pengembangan sistem yang menyederhanakan berbagai tahapan proses pengembangan tersebut agar tercapainya peningkatan efisiensi dan fleksibelitas sebuah proyek pengembangan perangkat lunak. Extreme Programming tidak hanya berfokus pada source code atau coding, tetapi meliputi seluruh area pengembangan.

About

Extreme Programming

       Perkembangan teknologi informasi yang pesat membawa pengaruh yang sangat berarti pada kehidupan manusia dewasa ini. Teknologi informasi memiliki berbagai unsur yang membangunnya menjadi kesatuan yang kokoh. Salah satu unsur teknologi informasi adalah perangkat lunak. Perangkat lunak merupakan kumpulan objek yang membentuk kon gurasi yang dapat berupa program, dokumen, atau data. Perangkat lunak adalah sesuatu yang dikembangkan, bukan dibuat secara pabrikan seperti perangkat keras. Pengembangan perangkat lunak memerlukan langkah-langkah yang tepat, efektif dan e sien untuk menjamin terpenuhinya kebutuhan user. Untuk itulah berkembang berbagai metodologi pengembangan perangkat lunak. Sebelum era 2000-an kita mengenal metodologi waterfall, spiral model, Rapid Application Development, dan masih banyak beberapa lainnya. Semua metodologi tersebut merupakan metodologi yang formal, dalam arti seluruhnya berjalan mengikuti aturan-aturan baku yang telah ditetapkan. Pada era 2000-an mulai berkembang metodologi baru yang sangat eksibel, yaitu Agile Methods. Agile methods merupakan salah satu dari beberapa metode yang digunakan dalam pengembangan sooftware. Agile method adalah jenis pegembangan sistem jangka pendek yang memerlukan adaptasi cepat dan pengembang terhadap perubahan dalam bentuk apapun. Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana. Agile Method juga dapat diartikan sekelompok metodologi pengembangan software yang didasarkan pada prinsip-prinsip yang sama atau pengembangan system jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun. Agile Software Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance. Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development:

• Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus.
• Menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
• Penyerahan hasil/software dalam hitungan waktu beberapa minggu sampai beberapa bulan.
• Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan.
• Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.
• Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan e fisien
• Software yang berfungsi adalah ukuran utama dari kemajuan proyek
• Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan

• Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile
• Kesederhanaan penting
• Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri
• Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.

Dua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip prinsip tersebur Agile Process Model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya:

• Kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek.
• Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan.
• Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.

Kelebohan Agile Methods:

• Meningkatkan kepuasan kepada klien
• Pembangunan system dibuat lebih cepat
• Mengurangi resiko kegagalan implementasi software dari segi non-teknis
• Jika pada saat pembangunan system terjadi kegagalan,kerugian dar segi materi relative kecil.

Agile Methods dikembangkan karena pada metodologi tradisional terdapat banyak hal yang membuat proses pengembangan tidak dapat berhasil dengan baik sesuai tuntutan user. Saat ini metodologi ini sudah cukup banyak berkembang, di antaranya adalah :

• eXtreme Programming (XP)
• Scrum Methodology
• Crystal Family
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development (ASD)
• Feature Driven Development (FDD)

Pada penulisan buku ini hanya extreme programming yang akan dibahas, karena extreme programming merupakan metodologi yang paling kecil tingkat keformalannya.

• Sejarah Extreme Programming

Extrem programming dimunculkan untuk menangani perubahan-perubahan yang biasanya sering terjadi pada saat pengembangan berlangsung bahkan pada saat proses pengembangan sudah hampir berakhir. Selainitu XP juga dimunculkan untuk mengatasi berbagai requirements yang tidak jelasdari user. Sebagai sebuahmetodologi untuk mengembangkan peragkat lunak XP tentu memiliki siklus hidup. Siklus hidup pada XP inierdapat lima fase yaitu : Extreme Programming diciptakan oleh Kent Beck selama bekerja di Chrysler MenyeluruhbSistem Kompensasi (C3) proyek penggajian. Beck C3 menjadi pemimpin proyek Maret 1996 dan mulai untuk memperbaiki metode pengembangan yang digunakan dalam proyek dan menulis sebuah buku tentang   metode (pada Oktober 1999, Extreme Programming Explained diterbitkan). Chrysler membatalkan proyek C3 pada Februari 2000, setelah perusahaan diakuisisi oleh Daimler-Benz. Meskipun Extreme Programming itu sendiri adalah relatif baru, banyak dari praktik sudah ada selama beberapa waktu, metodologi, setelah semua, diperlukan praktek terbaik untuk tingkat ekstrem. Sebagai contoh, tes-praktek pembangunan pertama, perencanaan dan tes tertulis sebelum setiap mikro-increment digunakan sebagai awal NASA Project Mercury, pada awal 1960-an (Larman 2003). Refactoring, modularitas, bottom-up dan desain inkremental digambarkan oleh Leo Brodie dalam bukunya yang diterbitkan pada tahun 1984

• Asal Extreme Programming

Sebagian besar pengembangan perangkat lunak pada 1990-an dibentuk oleh dua pengaruh utama: internal, pemrograman berorientasi objek pemrograman prosedural digantikan sebagai paradigma pemrograman yang disukai oleh beberapa orang dalam industri; eksternal, munculnya internet dan booming dot-com-untuk menekankan kecepatan pasar dan perusahaan-pertumbuhan sebagai faktor bisnis kompetitif. Persyaratan berubah dengan cepat menuntut lebih pendek siklus hidup produk, dan sering tidak sesuai dengan metode tradisional pengembangan perangkat lunak. Chrysler Menyeluruh Sistem Kompensasi dimulai dalam rangka untuk menentukan cara terbaik untuk menggunakan teknologi obyek, dengan menggunakan sistem penggajian di Chrysler sebagai objek penelitian, dengan sebagai bahasa Smalltalk dan batu permata sebagai lapisan akses data. Mereka dibawa di Kent Beck, Smalltalk praktisi terkemuka, untuk melakukan kinerja tuning pada sistem, tetapi perannya diperluas ketika ia melihat adanya beberapa persoalan yang mereka hadapi dengan proses pembangunan mereka. Dia mengambil kesempatan ini untuk mengusulkan dan mengimplementasikan beberapa perubahan dalam praktik mereka didasarkan pada sering bekerja dengan kolaborator, Ward Cunningham. Pertama kali saya diminta untuk memimpin sebuah tim, saya meminta mereka untuk melakukan sedikit hal yang saya pikir itu masuk akal, seperti pengujian dan ulasan. Kedua kali ada lebih banyak di telepon. Saya pikir, Sialan torpedo, setidaknya ini akan membuat artikel yang baik, dan meminta tim untuk mendongkrak semua tombol-tombol untuk 10 pada hal-hal yang saya pikir sangat penting dan meninggalkan segala sesuatu yang lain. -Kent Beck Ron Je ries Beck diundang ke proyek untuk membantu mengembangkan dan memperbaiki metode ini. Je ries kemudian bertindak sebagai pelatih untuk menanamkan praktek-praktek sebagai kebiasaan dalam tim C3. Informasi tentang prinsip-prinsip dan praktek-praktek di belakang XP ini disebarluaskan ke dunia yang lebih uas melalui diskusi di Wiki asli, WikiWikiWeb Cunningham. Berbagai kontributor dibahas dan dikembangkan atas ide-ide, dan beberapa spin-o metodologi yang mengakibatkan (lihat gesit pengembangan perangkat unak). Selain itu, konsep XP telah dijelaskan, selama beberapa tahun, menggunakan sistem teks hiper-peta di website XP di http://www.extremeprogramming.org sekitar tahun 1999 (website XPorg). Beck edited serangkaian buku on XP, mulai dengan dirinya sendiri Extreme Programming Explained (1999, ISBN 0-201-61641-6) , menyebarkan ide-idenya ke yang lebih besar, namun sangat reseptif, penonton. Penulis dalam seri melewati berbagai aspek menghadiri XP dan praktik, bahkan sebuah buku kritis terhadap praktek-praktek. XP cukup menciptakan buzz di akhir 1990-an dan awal 2000-an, melihat adopsi dalam sejumlah lingkungan yang sangat berbeda dari asal-usulnya. Disiplin tinggi yang diperlukan oleh praktek-praktek asli sering pergi di pinggir jalan, menyebabkan beberapa praktik yang dianggap terlalu kaku untuk menjadi usang atau kiri dibatalkan di setiap situs. Praktek-praktek pembangunan tangkas tidak berdiri diam, dan XP masih berkembang, asimilasi lebih banyak pelajaran dari pengalaman di lapangan. Dalam edisi kedua Extreme Programming Dijelaskan, Beck menambahkan lebih banyak nilai-nilai dan praktik-praktik dan dibedakan antara primer dan praktek wajar.

• Latar Belakang Extreme Programming

Requirement yang berubah dengan cepat menuntut lifecycles yang lebih pendek, dan tidak selaras dengan metoda pengembangan tradisional, yang pada umumnya memerlukan disain luas di awal dan mengakibatkan perubahan desain yang terjadi kemudian memerlukan biaya yang lebih tinggi atau kehilangan milestones. Berdasarkan hal ini kemudian dilahirkan konsep XP yang digagas oleh Kent Beck dan Ward Cunningham pada Maret 1996. Metode XP merupakan yang terpopuler dari beberapa metodologi pengembangan software yang dipakai untuk mengimplementasikan proyek pengembangan perangkat lunak.

• Pengertian Extreme Programing

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 see sien 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 Je ries, 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. Dalam Extreme Programming ada penekanan kuat pada komunikasi informal dan langsung , tes otomatis dan pasangan pemrograman , yang memantau kemajuan pengembangan perangkat lunak , yang memungkinkan umpan balik terus menerus pada skala waktu yang berbeda .Akar XP terletak pada masyarakat Smalltalk dan khususnya, dalam kolaborasi dekat Kent Beck dan Ward Cunningham dimulai padaakhir 1980-an . Keduanya menyempurnakan praktik ini pada berbagai proyek selama awal 1990-an , memperluas ide-ide mereka dari pengembangan perangkat lunak Pendekatan yang kedua adaptif dan berorientasi pada orang langkah dari praktek informal metodologi terjadi pada tahun 1997 ketika Kent Beck berhasil menggunakan XP untuk melaksanakan proyek penggajian untuk Daimler Chrysler. Sejak itu , XP telah berhasil digunakan di banyak perusahaan , seperti Bayerische Landesbank , Kredit Swiss Life, Pertama Union National Bank , Ford Motor Company dan UBS. XP didasarkan pada Beck dan Cunningham pengamatan dari apa yang membuat pengembangan program lebih cepat dan apa yang membuatnya lebih lambat . XP merupakan metodologi penting karena merupakan salah satu dari beberapa metodologi perangkat lunak baru yang diciptakan untuk menghasilkan perangkat lunak berkualitas tinggi dan mengurangi biaya perangkat lunak. Pengalaman ini kemudian diformalkan dan diterbitkan pada tahun 1999 oleh Kent Beck yang mende nisikan satu praktik dapat mewujudkan empat nilai-nilai fundamental yaitu komunikasi, umpan balik, keberanian , kesederhanaan. Extreme programming memiliki lima nilai yaitu :

• Komunikasi: Nilai ini berfokus pada membangun orang-ke – orang,saling pengertian dari lingkungan
• 
  
• masalah melalui minimal resmi dokumentasi dan melalui interaksi tatap muka maksimal . Praktek XP
• 
  
• dirancang untuk mendorong interaksi , pengembang – to- developer dan pengembang – ke-pelanggan .

– Kesederhanaan : Nilai ini menantang setiap anggota tim untuk terus bertanya, Apa hal paling sederhana yang mungkin bisa bekerja ? XP berpendapat bahwa lebih baik untuk melakukan hal yang sederhana dan membayar sedikit lebih besok untuk perubahan daripada melakukan lebih rumit,hal hari ini yang mungkin tidak akan pernah digunakan .
– Tanggapan : Dalam extreme programming team mendapatkan umpan balik dengan menguji perangkat lunak mereka,memberikan sistem ke pelanggan sedini mungkin dan mengimplementasikan perubahan dan prioritas seperti yang disarankan oleh umpan balik dari pelanggan .
– Keberanian : Pengembang sering mengutip tekanan untuk kapal produk buggy. Itu Dibutuhkan keberanian untuk menolak tekanan ini. Beck juga menyatakan bahwa tim harus berani dan bersedia untuk membuat perubahan di akhir proyek atau bahkan membuang kode dan mulai dari awal lagi.
– Menghormati : Jika anggota tim tidak peduli satu sama lain dan pekerjaan mereka , ada metodologi dapat bekerja . Anda harus menghormati kepada rekan-rekan Anda dan kontribusi mereka , untuk organisasi Anda , untuk orang-orang yang hidupnya tersentuh oleh sistem. Beck mengatakan Praktek adalah bukti dari nilai-nilai Tugas yang dapat dijatuhkan jika kita mendapatkan kendala . Dengan cara ini akan tetap margin keamanan dan memecahkan kasus masalah.
– Seluruh : Tim tim harus terdiri dari anggota dengan semua keterampilan dan perspektif yang dibutuhkan untuk proyek untuk berhasil . Mereka harusmemiliki rasa yang kuat milik , dan harus membantu satu sama lain . Informatif Workspace : ruang kerja harus dilengkapi dengan poster informatif dan hal-hal lain , memberikan informasi tentang status proyek dan pada tugas-tugas yang akan dilakukan.
– Kerja : Berenergi pengembang harus di-refresh , sehingga dapat fokus pada pekerjaan mereka dan menjadi produktif . Akibatnya setiap orang bisa menghabiskan waktu untuk nya atau kehidupan pribadinya sendiri . praktek ini dalam versi lama XP disebut “kecepatan berkelanjutan ” .
– Pair : Programming : kode selalu ditulis oleh dua programmer di salah satu mesin . Praktek ini keluar pada extrme programming asli .
– Tambahan : Desain extreme programming menentang menghasilkan desain yang lengkap di depan .Tim pengembangan menghasilkan kode sesegera mungkin dalam rangka untuk mendapatkan umpan balik dan memperbaiki sistem terus menerus. Desain diperlukan untuk mendapatkan kode yang baik Pertanyaannya adalah ketika merancang XP menyarankan untuk melakukannya secara bertahap selama coding . Cara membantu memperoleh ini adalah untuk menghilangkan duplikasi dalam kode.
– Pemrograman Test- Pertama : sebelum memperbarui dan menambahkan kode perlu untuk menulis tes untuk memveri kasi kode. Hal ini memecahkan empat masalah :

• Cowboy coding yaitu sangat mudah untuk mendapatkan,dapat dibawa pergi dengan program cepat dan menempatkan semuanya dalam pikiran serta dalam kode. Tes membantu kita fokus pada masalah yang dihadapi dan dapat membuktikan bahwa desain kami adalah benar.

• Coupling dan kohesi yaitu jika tidak mudah untuk menulis tes , ini berarti bahwa anda memiliki masalah desain , bukan dari pengujian atau coding
• Kepercayaan yaitu jika Anda menulis kode dokumen dengan tes otomatis , rekan kerja Anda akan mempercayai Anda .

• Rhythm yaitu mudah untuk tersesat dan mengembara selama berjam-jam ketika kita coding . Jika kita membiasakan diri dengan: tes, kode ,refactor , tes, kode , refactor , itu tidak akan terjadi .

• Tujuan Extreme Programming

Tujuan utama dalam extreme programming adalah menurunkan biaya dari adanya perubahan software .Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan padatahap awal pengembangan proyek dan bersifat xed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi pada tahap selanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya dari adanya perubahan dengan memperkenalkan nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangan suatu sistem haruslah lebih eksibel terhadap perubahan. Sasaran XP 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. XP dimunculkan untuk menangani perubahan-perubahan yang biasanya sering terjadi pada saat pengembangan berlangsung bahkan pada saat proses pengembangan sudah hampir berakhir.

• Kelebihan dan Kelemahan Extreme Programing

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 yangsemi formal. (Planning Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima, atau dengan
• kata lain eksibel. (Maintenance Phase)

Kelemahan :

• Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan

apa yang diperlukan hari itu juga). Selain dari keunggulan dan kelemahan XP yang telah disebutkan diatas, 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.

• Prinsip Dasar Extreme Programming

Terdapat lima prinsip dasar yang sangat fundamental dalam Extreme Programming, dimana prinsip -prinsip ini digunakan untuk menentukan apakah semua tindakan/pekerjaan yang telah dilakukan akan sukses atau sebaliknya (dalam konteks Extreme Programming). Kelima prinsip tersebut adalah:

• Aliran umpan balik (Rapid Feedback)
• Asumsi kesederhanaan (Asume Simplicity)
• Penambahan perubahan (Incremental Change)
• Pemelukan pekerjaan (Embrace Work)
• Kualitas kerja (Quality Work)

Extreme programming merupakan suatu disiplin ilmu dari software development yang didasarkan pada nilai dari kelima aspek di atas. Dalam extreme programming seluruh team bekerja sebagai satu kesatuan dalam bekerja, dengan feedback yang cukup maka mereka akan mengetahui sudah sampai mana mereka bekerja, dan apabila terdapat sesuatu hal mereka ingin melihat ke belakang tentang apa yang telah dikerjakan mereka dapat menggunakan feedback tersebut. Jadi feedback menyimpan informasi tentang apa apa saja yang telah dilakukan oleh team.Disamping kelima prinsip tersebut terdapat sepuluh prinsip lainnya yang bersifat opsional,namun sebaiknya perlu diperhatikan agar hasil yang dihasilkan memuaskan. kesepuluh prinsip tersebut adalah

• Teach Learning
• Small initial investment
• Play to win
• Cncrete experiments
• Open, honest communication
• Work with people’s instinct not against them
• Accepted responsibility
• Local adaptation
• Travel light
• Honest measurement

Kegiatan Exreme Programming
Dalam extreme programming menggambarkan empat kegiatan dasar yang dilakukan dalam proses pengembanganperangkat lunak yaitu :
 

– Coding : Pendukung XP berpendapat bahwa satu-satunya benar-benar produk yang penting dari proses pengembangan sistem kode instruksi perangkat lunak komputer dapat menafsirkan. Tanpa kode, tidak ada produk kerja.Coding juga dapat digunakan untuk mengetahui solusi yang paling cocok. Sebagai contoh, XP akan menganjurkan bahwa dihadapkan dengan beberapa alternatif untuk masalah pemrograman, satu kode hanya perlu semua solusi dan menentukan dengan tes yang otomatis solusi yang paling sesuai. Coding juga dapat membantu untuk mengkomunikasikan pikiran tentang masalah pemrograman. Seorang pemrogram berurusan dengan masalah pemrograman yang kompleks dan sulit untuk menjelaskan solusi untuk sesama programer mungkin kode ini dan gunakan kode untuk menunjukkan apa yang dia berarti. Kode, mengatakan para pendukung posisi ini, selalu jelas dan ringkas dan tidak dapat ditafsirkan dengan lebih dari satu cara. Pemrogram lain dapat memberikan umpan balik kode ini oleh juga pengkodean pikiran mereka.

– Pengujian : Satu tidak bisa memastikan bahwa fungsi bekerja kecuali satu tes itu. Desain bug dan masalah kesalahan yang meresap dalam pengembangan software. Extreme Programming Pendekatan adalah bahwa jika sedikit pengujian dapat menghilangkan beberapa kekurangan, banyak pengujian dapat menghilangkan banyak kelemahan. Unit tes menentukan apakah tur yang diberikan bekerja sebagaimana dimaksud. Seorang pemrogram menulis sebagai banyak tes otomatis mereka bisa memikirkan yang dapat memecahkan kode; jika semua tes berjalan dengan sukses, maka pengkodean selesai. Setiap potongan kode yang tertulis diuji sebelum pindah ke tur berikutnya. * Tes Penerimaan memveri kasi bahwa persyaratan sebagaimana yang dipahami oleh para programer memenuhi persyaratan pelanggan yang sebenarnya. Ini terjadi pada tahap eksplorasi perencanaan rilisSebuah testathon adalah sebuah peristiwa ketika programmer bertemu untuk melakukan tes kolaboratif menulis, semacam brainstorming relatif terhadap pengujian perangkat lunak.

– Mendengarkan : Programmer harus mendengarkan apa yang pelanggan membutuhkan sistem untuk melakukan, apa yang logika bisnis diperlukan. Mereka harus memahami kebutuhan-kebutuhan ini cukup baik untuk memberikan umpan balik pelanggan tentang aspek teknis bagaimana masalah bisa dipecahkan, atau tidak dapat dipecahkan. Pemahaman masalah nya. Komunikasi antara pelanggan dan pemrogram adalah dibahas lebih lanjut dalam The Perencanaan Game.

– Merancang : Dari sudut pandang kesederhanaan, orang bisa mengatakan bahwa pengembangan sistem tidak membutuhkan lebih dari coding, pengujian dan mendengarkan. Jika kegiatan tersebut dilakukan dengan baik, hasilnya harus selalu menjadi sistem yang bekerja. Dalam prakteknya, ini tidak akan bekerja. Satu dapat datang jauh tanpa merancang tetapi pada waktu tertentu seorang pun akan terjebak. Sistem menjadi terlalu kompleks dan dependensinya di dalam sistem berhenti menjadi jelas. Satu dapat menghindari hal ini dengan menciptakan sebuah desain struktur yang mengatur logika dalam sistem. Desain yang baik akan menghindari banyak dependensi dalam sistem ini berarti bahwa mengubah salah satu bagian dari sistem tidak akan mempengaruhi bagian lain dari sistem.

Metode SDLC Synchronize & Stabilize

Model Synchronize & Stabilize

      Model ini adalah model yang digunakan oleh Microsoft.  Secara garis besar, Model Synchronize and Stabilize ini sama dengan model incremental, tetapi oleh CUsamano dan Selby tahun 1997 menyebutnya sebagai model Syncronize and Stabilized Model karena ada beberapa proses manajemen yang ditekannya oleh microsoft.

    Analisis kebutuhan dilakukan dengan wawancara dengan sejumlah konsumen yang potensial.  Kemudian kebutuhan-kebutuhan tersebut dibuat paket dan disusun daftar secara prioritas.  Kemudian spesifikasi ditulis.  Selanjutnya pekerjaan dibagi dalam tiga atau empat bagian pembangunan software.  Bagian pertama menangani hal-hal yang paling kritis, bagian selanjutnya menangani hal-hal yang krisis selanjutnya, dan seterusnya.

       Pada akhirnya, setiap hari dilakukan proses sinkronisasi, yaitu menggabungkan bagian-bagian yang terpisah tersebut kemudian ditesting.  Proses stabilisasi dilakukan pada akhir pembangunan setiap bagian.  Kesalahan yang terjadi akan diperbaiki, dan tidak akan ada perubahan spesifikasi.

 

Keuntungan Dari Synchronize-And-Stabilize

     Walaupun prinsip-prinsip dibalik synchronize and stabilizememberikan 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 mensynchronizing 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.

• Mengijinkan suatu tim produk menjadi lebih responsive dalam penempatan produk di pasar dengan “selalu” mempunyai produk yang siap untuk dijual, mempunyai keakuratan fitur yang komplit dan fleksibilitas produk yang tinggi.

Metode SDLC Build and Fix

Dari sangat banyaknya metode – metode dari SDLC, kami akan membahas metode yang paling lemah dari semua metode yang ada. Dan merupakan awal dan menjadi bahan pengembangan untuk metode – metode SDLC yang selanjutnya. Metode itu adalah metode SDLC Build and 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 ”





sumber : http://ziziramzi7.blogspot.co.id/2012/10/v-behaviorurldefaultvmlo.html

Metode SDLC Rapid Prototyping

Merupakan model pengembangan system yang 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. Prototyping merupakan bentuk dari Rapid Application Development (RAD). Model Prototypig digambarkan sebagai berikut :

Rapid Prototyping (RP) didefinisikan sebagai proses untuk mempercepat pengembangan produk dengan membuat prototipe langsung dari gambar/desain rancangan yang berbentuk file/model CAD (Computer Aided Design) tiga dimensi. Beberapa tahap dasar dari arti proses adalah:

1. Membuat CAD model dari objek yang dirancang.
2. Mengubah CAD model menjadi STL Format.
3. Mengiris STL File kedalam beberapa potongan (layer).
4. Membangun model secara lapis perlapis.
5. Membersihkan dan penyempurnaan model.

Dalam perkembangannya, dikenal pula istilah Rapid Tooling dan Rapid  Manufacturing sebagai pengembangan Rapid Prototyping, sehingga disebut juga Rapid Prototyping and Tooling (RP/T) dan Rapid Prototyping and Manufacturing (RP/M).

Rapid Tooling adalah penggunaan teknik Rapid Prototyping untuk memproduksi tooling untuk proses semacam moulding injeksi plastik. Rapid Manufacturing adalah penggunaan sistem Rapid Prototyping  untuk memproduksi parts dalam jumlah tertentu.

Pinsip dasar Rapid Prototyping adalah menggunakan gambar rancangan CAD tiga dimensi dalam format STL (Stereolithography) yang dikirim ke mesin Rapid Prototyping. Di mesin Rapid Prototyping , gambar tersebut diiris (slice) menjadi layer-layer dengan ketebalan tertentu sesuai spesifikasi mesin. Untuk membentuk layer-layer tersebut menjadi prototipe tiga dimensi, terdapat beberapa teknik. Beberapa teknik Rapid Prototyping yang dikenal luas, antara lain :

1.          Stereolithography Apparatus (SLA)

Dalam teknik SLA, sebuah prototipe dibuat dengan cara menembakkan sinar laser ke permukaan sebuah wadah (vat) yang berisi cairan photopolymer (resin). Cairan ini akan langsung mengeras saat laser mengenai permukaannya. Setelah satu layer selesai dikerjakan, sebuah platform digerakkan turun beberapa milimeter, sebuah penyapu (recoater blade) membersihkan sisa-sisa resin di permukaan, dan layer berikutnya dikerjakan di atas layer yang telah diselesaikan

2. Fused Deposition Modeling (FDM)

Seperti terlihat pada Gambar 2., cara kerja FDM menggunakan sebuah head (kepala penyemprot) yang dipanaskan digerakkan menurut sumbu x dan y untuk membentuk layer menggunakan material plastis yang disemprotkan ke atas platform. Material itu akan segera mendingin dan mengeras saat mengenai platform. Platform kemudian digerakkan turun, dan layer berikutnya segera dikerjakan. Untuk prototipe yang membutuhkan penyangga (support), maka disemprotkan material penunjang dari head di sekeliling prototipe. Material penunjang ini dapat dengan mudah dibuang setelah prototipe selesai dikerjakan.

    3. Three-Dimensional Printing (3DP) 

Seperti terlihat pada Gambar 3., proses kerja printer tiga dimensi menggunakan sebuah printhead, seperti yang terdapat pada printer inkjet, menyemprotkan binder (perekat) ke lapisan tipis serbuk (powder) pada platform sesuai bentuk geometri layer. Platform kemudian bergerak turun, sebuah mekanisme pasokan serbuk (powder supply) meyapukan lapisan tipis serbuk di atas layer yang telah terbentuk, dan proses di atas diulangi lagi sampai layer terakhir. Serbuk yang tidak terkena binder berfungsi sebagai penunjang (support), dan setelah proses pembuatan prototipe selesai, material penunjang ini dibersihkan dan digunakan untuk proses pembuatan prototipe berikutnya.

4. Selective Laser Sintering (SLS)

Seperti terlihat pada Gambar 4., cara kerja SLS mirip dengan printer tiga dimensi, hanya pada SLS digunakan laser untuk merekatkan material serbuk pada platform.

5. Laminated Object Manufacture (LOM)

Seperti terlihat pada Gambar 5., cara kerja LOM menggunakan material berupa kertas khusus yang digerakkan melewati sebuah platform. Sinar laser ditembakkan menurut bentuk layer, memotong kertas pada platform. Platform akan bergerak turun dan material baru dilewatkan di atas layer yang telah terbentuk, dan proses diulangi lagi sampai semua layer selesai dikerjakan. Sebuah roller pemanas (heated roller) memanaskan layer yang telah terbentuk agar menyatu dengan layer di bawahnya.








sumber:http://winspunakawan.blogspot.co.id/2011/07/rapid-prototypingmanufacturing.html

Metode SDLC 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.

2. Rapid Application Development (RAD)

Rapid Application Development (RAD) merupakan proses pengembangan software / sistem yang mempunyai proses yang sangat cepat dibanding model SDLC lain. RAD dapat selesai dalam jangka waktu 60 – 90 hari. RAD tergolong dalam teknik incremental (bertingkat). Mengapa RAD dalam pembangunan sistem cepat, pendek dan singkat ? karena RAD menggunakan metoda 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.
Berikut adalah penjelasan James Martin RAD Methodology:

•  Requirements Planning phase (Persyaratan Fase Perencanaan),menggabungkan unsur perencanaan sistem dan analisis sistem fase Siklus Hidup Pengembangan Sistem (SDLC).
•  User design phase (Fase Desain Pengguna), selama fase ini , pengguna berinteraksi dengan sistem analis dan mengembangkan model dan prototipe yang mewakili semua sistem proses , input , dan output.
• Construction phase (Tahap konstruksi), dalam fase ini pengguna terus berpartisipasi dan masih dapat menyarankan perubahan atau perbaikan sebagai laporan untuk dikembangkan
• Cutover Phase, menyerupai tugas akhir dalam tahap implementasi SDLC , termasuk konversi data, pengujian , changeover ke sistem baru , dan pelatihan pengguna. 

Metode SDLC Iterative (pengulangan)

Pengertian iterative
Perulangan iterative merupakan perulangan yang melakukan proses perulangan terhadap sekelompok instruksi di mana perulangan tersebut akan berhenti jika batasan syarat sudah tidak terpenuhi.
 
Kelebihan perulangan iterative:
• Mudah dipahami dan mudah melakukan debugging ketika ada perulangan yang salah.
• Dapat melakukan nested loop atau yang disebut dengan looping bersarang.
• Proses lebih singkat karena perulangan terjadi pada kondisi yang telah disesuaikan.
• Jarang terjadi overflow karena batasan dan syarat perulangan yang jelas.

Kelemahan perulangan iteratif:
• Tidak dapat menggunakan batasan berupa fungsi.
• Perulangan dengan batasan yang luas akan menyulitkan dalam pembuatan program perulangan itu sendiri.

1. PERSAMAAN & PERBEDAAN REKURSIF DAN ITERATIVE

Dalam beberapa situasi, pemecahan secara rekursif maupun secara iterative mempunyai keuntungan dan kekurangan yang bisa saling diperbandingkan. Adalah cukup sulit untuk menentukan mana yang paling sederhana, paling jelas, paling efisien dan paling mudah disbanding yang lain. Boleh dikatakan pemilihan cara iterative maupun rekursif merupakan kesenangan seorang programmer dan tergantung konteks permasalahan yang akan dipecahkan sesuai dengan kesanggupan yang bersangkutan.
Persamaan antara perulangan iterative dan rekursif:
• Iterative dan rekursif merupakan metode atau teknik di dalam perulangan (looping).
• Sama-sama mengalami perulangan kondisi.

Metode SDLC Iterative merupakan model pengembangan system yang bersifat dinamis dalam artian setiap tahapan proses pengembangan system dapat diulang jika terdapat kekurangan atau kesalahan. Setiap tahapan pengembangan system dapat dikerjakan berupa ringkasan dan tidak lengkap, namun pada akhir pengembangan akan didapatkan system yang lengkap pada pengembangan system. Terdapat dua jenis model iterasi, yaitu :

–        Model Incremental, merupakan model pengembangan system yang dipecah sehingga model pengembangannya secara increment/bertahap. Kebutuhan pengguna diprioritaskan dan prioritas tertinggi dimasukkan dalam awal increment. Model Incremental digambarkan sebagai berikut :

Metode SDLC Spiral (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

sumber : https://rifkanisa19.wordpress.com/2014/08/23/macam-macam-model-pengembangan-software/
https://itsum.wordpress.com/2010/09/26/model-pada-software-development-life-cycle-sdlc/

Metode SDLC Waterfall (air terjun)

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). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement.

Secara umum tahapan pada model waterfall dapat dilihat pada gambar berikut :

 

Gambar di atas adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:

• System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.
• Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
• Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
• Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
• Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
• Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

Mengapa model ini sangat populer??? Selain karena pengaplikasian menggunakan model ini mudah, kelebihan dari model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal project, maka SE dapat berjalan dengan baik dan tanpa masalah. Meskipun seringkali kebutuhan sistem tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

Meskipun demikian, karena model ini melakukan pendekatan secara urut / sequential, maka ketika suatu tahap terhambat, tahap selanjutnya tidak dapat dikerjakan dengan baik dan itu menjadi salah satu kekurangan dari model ini. Selain itu, ada beberapa kekurangan pengaplikasian model ini, antara lain adalah sebagai berikut:

• Ketika problem muncul, maka proses berhenti, karena tidak dapat menuju ke tahapan selanjutnya. Bahkan jika kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. Hal-hal seperti ini yang dapat membuang waktu pengerjaan SE.
• 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. Oleh karena itu, seringkali model ini berlangsung lama pengerjaannya.
• Pada setiap tahap proses tentunya dipekerjakan sesuai spesialisasinya masing-masing. Oleh karena itu, ketika tahap tersebut sudah tidak dikerjakan, maka sumber dayanya juga tidak terpakai lagi. Oleh karena itu, seringkali pada model proses ini dibutuhkan seseorang yang “multi-skilled”, sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya.

Menurut saya, tahapan-tahapan model ini sudah cukup baik dalam artian minimal untuk melakukan SE, maka harus ada tahapan-tahapan ini. Tahapan-tahapan ini jugalah yang digunakan oleh model-model yang lain pada umumnya. Ada filosofi yang mengatakan sesuatu yang sukses diciptakan pertama kali, maka akan terus dipakai di dalam pengembangannya. Hal ini juga berlaku pada waterfall model ini. Mungkin dapat dikatakan bahwa inilah standar untuk melakukan SE.

Akan tetapi, yang mungkin menjadi banyak pertimbangan mengenai penggunaan dari model ini adalah metode sequential-nya. Mungkin untuk awal-awal software diciptakan, hal ini tidak menjadi masalah, karena dengan berjalan secara berurutan, maka model ini menjadi mudah dilakukan. Sesuatu yang mudah biasanya hasilnya bagus. Oleh karena itu model ini sangat populer. Akan tetapi, seiring perkembangan software, model ini tentu tidak bisa mengikutinya. Yang menjadi kelemahan adalah pada pengerjaan secara berurutan tadi, seperti yang sudah saya utarakan sebelumnya. Kelemahan-kelemahan yang lain juga sudah saya utarakan di atas, atau bahkan masih ada yang lainnya.

Dari sini, nantinya akan dikembangkan model-model yang lain, bahkan ada tahap evolusioner dari suatu model proses untuk mengatasi kelemahan-kelemahan tadi. Meskipun secara tahapan masih menggunakan standar tahapan waterfall model. Kesimpulannya adalah ketika suatu project skalanya sedang mengarah kecil bisa menggunakan model ini. Akan tetapi kalau sudah project besar, tampaknya kesulitan jika menggunakan model ini.

sumber : http://fopsoft.blogspot.co.id/2013/09/metode-sdlc-model-waterfall.html