MODEL-MODEL PENGEMBANGAN SOFTWARE

1.

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

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 dimu lai. 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. Keuntungan : 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.

Kerugian : 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.

2.

Spiral Model spiral pada awalnya diusulkan oleh Boehm, adalah model proses perangkat lunak evolusioner yang merangkai sifat iteratif dari prototype dengan cara kontrol dan aspek sistematis model sequensial linier.

Model iteratif ditandai dengan tingkah laku yang memungkinkan pengembang mengembangkan versi perangkat lunak yang lebih lengkap secara bertahap. Perangkat lunak dikembangkan dalam deretan pertambahan. Selama awal iterasi, rilis inkremantal bisa berupa model/prototype kertas, kemudian sedikit demi sedikit dihasilkan versi sistem yang lebih lengkap.

Tahapan-Tahapan

Model

Spiral

Model spiral dibagi menjadi enam wilayah tugas yaitu: 1. Komunikasi pelanggan Yaitu tugas-tugas untuk membangun komunikasi antara pelanggan dan kebutuhankebutuhan yang diinginkan oleh pelanggan 2. Yaitu tugas-tugas untuk informasi mendefinisikan sumber lain Analisis dibutuhkan untuk daya, ketepatan yg waktu, Perencanaan dan proyek berhubungan. Resiko teknis.

3. Yaitu 4. Yaitu tugas yang tugas-tugas yang

menaksir

resikomanajemen

dan

dibutuhkan

untuk membangun apikasi

satu

atau

lebih

Perekayasaan representasi dari tersebut. peluncuran

5.

Konstruksi

dan

Yaitu

tugas-tugas yang memberi

dibutuhkan

untuk mengkonstruksi, menguji, pelayanan kepada Evaluasi mendapatkan

memasang

, dan pemakai.

6. Yaitu tugas-tugas untuk

umpan

balik

dari

Pelanggan pelanggan.

Kelebihan

dan

Kelemahan

Model

Spiral

a.

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.

b.

3.

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 Incremental

Incremental model adalah model pengembangan sistem pada software engineering berdasarkan requirement software yang dipecah menjadi beberapa fungsi atau bagian sehingga model pengembangannya secara bertahap. dilain pihak ada mengartikan model incremental sebagai perbaikan dari model waterfall dan sebagai standar pendekatan topdown. Layaknya Model Waterfall, model ini pun juga memiliki tahapan tahapan untuk perancangan perangkat lunaknya, yaitu:

1. 2. 3. 4. 5.

Requirement , Requirment adalah proses tahapan awal yang dilakukan pada incremental model adalah penentuan kebutuhan atau analisis kebutuhan. Specification, Specification adalah proses spesifikasi dimana menggunakan analisis kebutuhan sebagai acuannya. Architecture Design, adalah tahap selanjutnya, perancangan software yang terbuka agar dapat diterapkan sistem pembangunan per-bagian pada tahapan selanjutnya. Code setelah melakukan proses desain selanjutnya ada pengkodean. Test merupakan tahap pengujian dalam model ini.

gambar

1.2

desain

pemodelan

Incremental

Tahapan-tahapan tersebut dilakukan secara berurutan. Setiap bagian yang sudah selesai dilakukan testing, dikirim ke pemakai untuk langsung dapat digunakan. Pada incremental model, tiga tahapan awal harus diselesaikan terlebih dahulu sebelum sebelum tahap membangun tiap increment. Untuk mengantisipasi kondisi yang terjadi pada incremental model, diperkenalkan model More Risky Incremental Model. Model ini menerapkan sistem kerja yang paralel. Setelah daftar kebutuhan didapatkan dari pemakai, tim spesifikasi membuat spesifikasi untuk modul pertama. Setelah spesifikasi pertama selesai, tim desain menindak lanjuti. Tim spesifikasi sebelumnya juga langsung membuat spesifikasi untuk model kedua, dan seterusnya. Jadi, tidak harus menunggu modul pertama selesai hingga dikirim ke user. Beberapa Kelebihan Dari Mode Incremental atara lain : 1. 2. Merupakan model dengan manajemen yang sederhana Pengguna tidak perlu menunggu sampai seluruh sistem dikirim untuk mengambil keuntungan dari sistem tersebut. Increment yang pertama sudah memenuhi persyaratan mereka yang paling kritis, sehingga perangkat lunak dapat segera digunakan. Resiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah masih dapat ditemukan pada beberapa increment. Karena layanan dengan prioritas tertinggi diserahkan pertama dan increment berikutnya diintegrasikan dengannya, sangatlah penting bahwa layanan sistem yang paling penting mengalami pengujian yang ketat. Ini berarti bahwa pengguna akan memiliki kemungkinan kecil untuk memenuhi kegagalan perangkat lunak pada increment sistem yang paling bawah. Nilai penggunaan dapat ditentukan pada setiap increment sehingga fungsionalitas sistem disediakan lebih awal. Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem, Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji

3.

4. 5. 6.

Kelemahannya adalah : a. b. c. kemungkinan tiap bagian tidak dapat diintegrasikan Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung Harus Open Architecture

d.

Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment.

4.

RAD (Rapid Application Development) Rapid Aplication Development (RAD) adalah sebuah model proses perkembangan perangkat lunak sekuensial linier yg menekankan siklus perkembangan yg sangat pendek. Model RAD ini merupakan sebuah adaptasi kecepatan tinggi dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan sistem fungsional yg utuh dalam periode waktu yg sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase-fase sebagai berikut: Bussines Modelling. Aliran informasi diantara funsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut: Informasi apa yg mengendalikan proses bisnis? Informasi apa yg dimunculkan? Siapa yg memunculkan? Ke mana informasi itu pergi? Siapa yg memprosesnya? Data Modelling. Aliran informasi yg di definisikan sebagai bagian dari fase bussiness modelling di saring ke dalam serangkaian objek data yg dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing-masing objek diidentifikasi dan hubungan antara objekobjek tersebut didefinisikan. Prosess Modeling. Aliran informasi yg didefinisikan di dalam fase data modelling ditransformasikan untuk mencapai aliran informasi yg perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan digunakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data. Aplication generation. RAD mengasumsikan pemakaian teknik generasi ke-empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ke-tiga yg konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yg ada (pada saat memungkinkan) atau menciptakan komponen yg bisa dipakai lagi (bila perlu). Pada semua kasus, alat-alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak. 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 diuji dan semua interface harus dilatih secara penuh. Seperti semua proses model yg lain, pendekatan RAD emiliki kekurangan : 1. Bagi proyek yg besar tetapi berskala, RAD memerlukan sumber daya manusia yg memadai untuk menciptakan jumlah tim RAD yg baik. 2. RAD menurut pengembang dan pelanggan memiliki komitmen di dalamaktifitas rafid-fire yg diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yg sangat diperpendek. Jika komitmen tersebut tidak ada dari tiap konstitueb, proyek RAD akan gagal. Tidak semua aplikasi sesuai untuk RAD. Bila sistem tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematis. RAD menjadi tidak sesuai jika risiko teknisnya tinggi. Hal ini terjadi bila sebuah aplikasi baru memforsir teknologi baru atau bila perangkat lunak baru membutuhkan tingkat interoperabilitas yg tinggi dengan program komputer yg ada. RAD menekankan perkembangan komponen program yg bisa dipakai kembali (Reusabilitas).

5.

Prototipe

Pendekatan Prototyping adalah proses iterative yang melibatkan hubunan kerja yang dekat antara perancang dan pengguna. Pressman (2001) menyatakan bahwa seringkali seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak mengidentifikasi kebutuhan input, pemrosesan, ataupun output detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemapuan penyesuaian dari sistem operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dan mesin. Dalam situasi seperti ini salah satu model yang cocok digunakan adalah model prototype (Prototyping paradigm). Model Prototype dapat dilihat pada gambar dibawah ini.

Gambar 1 Prototype Paradigm Pendekatan Prototyping melewati tiga proses, yaitu pengumpulan kebutuhan, perancangan, dan evaluasi Prototype. Proses-proses tersebut dapat dijelaskan sebagai berikut: 1. 2. 3. Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya; Perancangan: perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype; Evaluasi Prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari Prototype. Pendekatan ini memiliki beberapa keuntungan : 1. Pemodelan membutuhkan partisipasi aktif dari end-user. Hal ini akan meningkatkan sikap dan dukungan pengguna untuk pengerjaan proyek. Sikap moral pengguna akan meningkat karena system berhubungan nyata dengan mereka. Perubahan dan iterasi merupakan konsekuensi alami dari pengembangan system-sehingga end user memiliki keinginan untuk merubah pola pikirnya. Prototyping lebih baik menempatkan situasi alamiah ini karena mengasumsikan perubahan model melalui iterasi kedalam system yang dibutuhkan.

2.

3. 4. 5. 6. 7.

Prototyping mematahkan folosofi end user tidak mengetahui secara detail apa yang dibutuhkan sampai mereka melihat implementasinya Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat, merasakan, dan mengalaminya. Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini Prototyping dapat meningkatkan kreatifitas karena membolehkan adanya feedback dari end user. Hal ini akan memberikan solusi yang lebih baik. Prototyping mempercepat beberapa fase hidup dari programmer.

McLeod dan Schell (2001) mengemukakan bahwa alasan-alasan pemakai maupun spesialis informasi menyukai model prototype adalah: 1. 2. 3. 4. 5. Komunikasi antara analis sistem dan pemakai membaik; Analis dapat bekerja dengan lebih baik dalam menemukan kebutuhan pemakai; Pemakai berperan lebih aktif dalam pengembangan sistem; Spesialis informasi dan pemakai menghabiskan lebih sedikit waktu dan usaha dalam mengembangkan sistem; Implementasi menjadi lebih mudah karena pemakai mengetahui sistem yang diharapkan.

Tetapi, terdapat beberapa kelemahan dari prototyping, kelemahan tersebut antara lain : 1. 2. 3. 4. Prototyping memungkinkan terjadinya pengembalian terhadap kode, implementasi, dan perbaikan siklus hidup yang dugunakan untuk mendominasi sistem informasi. Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya dapat memecahkan masalah yang salah dan memberi kesempatan sebagai sistem pengembangan konvensional. Perancangan issu numerik tidak dialamaykan oleh prototyping. Isu tersebut dapat dilupakan jika pengguna tidak berhati-hati. Prototyping dapat mengurangi kreatifitas perancangan.

Prototyping terkadang dapat memberikan performansi yang lambat, membantu mendapatkan kebutuhan detil lebih baik namun demikian Prototype juga menimbulkan masalah: 1. Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya. Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana. Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

2.

3.

6.

Agile 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 Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development: 1. 2. 3. 4. 5. 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. 6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien 7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek 8. Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan 9. Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile 10. Kesederhanaan penting 11. Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri 12. Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya. Kelebihan dari Agile Method 1. 2. 3. 4. 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.

7.

Extreme Program (XP) Extreme Programming (XP) merupakan salah satu metodologi dalam rekayasa perangkat lunak dan juga merupakan satu dari beberapa agile software development methodologies yang berfokus pada coding sebagai aktivitas utama di semua tahap pada siklus pengembangan perangkat lunak ( software development lifecycle). Metodologi ini mengedepankan proses pengembangan yang lebih responsive terhadap kebutuhan customer (agile) dibandingkan dengan metode -metode tradisional sambil membangun suatu software dengan kualitas yang lebih baik. Kata Kunci: Extreme Programming, agile, coding, komunikasi, kesederhanaan, umpan balik, keberanian, menghormati.

Keuntungan XP: Menjalin komunikasi yang baik dengan client. Meningkatkan komunikasi dan sifat saling menghargai antar developer.

Kerugian XP: Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).

8.

Scrum

Pertama kali diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990an, dan dikembangkan selanjutnya dilakukan oleh Schwaber dan Beedle. Pada dasarnya Scrum merupakan salah satu komponen dari metodologi pengembangan Agile mengenai pertemuan harian untuk membahas kemajuan dan XP adalah menekankan metodologi yang berbeda sepasang ujian dulu pemrograman dan pembangunan. Scrum menguraikan proses untuk mengidentifikasi dan katalogisasi pekerjaan yang perlu dilakukan, memprioritaskan yang bekerja dengan berkomunikasi dengan pelanggan atau wakil pelanggan, dan pelaksanaan yang bekerja menggunakan rilis iterative dan memiliki tujuan utama untuk mendapatkan perkiraan berapa lama akan pembangunan. XP lebih lanjut tentang pengembang membantu menyelesaikan pekerjaan secepat dan maintainably mungkin Scrum memiliki prinsip yaitu: Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan memberdayakan satu sama lain Proses dapat beradaptasi terhadap perubahan teknis dan bisnis Proses menghasilkan beberapa software increment Pembangunan dan orang yang membangun dibagi dalam tim yang kecil Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

Scrum memiliki aktifitas yang meliputi : 1. Backlog

Backlog adalah daftar kebutuhan yang jadi prioritas klien, dan daftar yang dibuat dapat bertambah 1. Sprints

Aktifitas Sprints merupakanunit pekerjaan yang diperlukan untuk memenuhi kebutuhan yang ditetapkan dalam backlog sesuai dengan waktu yang ditetapkan dalam time-box (biasanya 30hari). Selama proses ini berlangsung backlog tidak ada penambahan. 1. Scrum Meetings

Aktifitas Scrum Meeting merupakan pertemuan yang rutin dilakukan perhari untuk evaluasi apa yang dikerjakan, hambatan yang ada, dan target penyelesaian untuk bahan meeting selanjutnya.

1.

Demo

Aktifitas Demo adalah penyerahan software increment ke klien didemonstrasikan dan dievaluasi oleh klien.

9.