tugas rpl 2

The Software Problem

Tanyakan pada setiap mahasiswa yang telah memiliki beberapa pengalaman membuat program, berikut pertanyaannya :

Pertanyaan: Anda diberi masalah dimana anda harus membuat sebuah program yang sebagian besar siswa akan membuat sekitar 10.000 baris (katakanlah bahasa pemograman C atau Java) kode. Jika Anda membuatnya, berapa lama akan menyelesaikannya?

Jawaban dari mahasiswa umumnya 1 sampai 3 bulan. Dan, mengingat programming yang menjadi keahlian mahasiswa, ada kesempatan mereka dapat membuat program dan demo ke profesor/dosen dalam waktu 2 bulan. Dengan 2 bulan sebagai waktu penyelesaian, produktivitas mahasiswa akan membuat 5000 baris kode (LOC) per bulan. Meskipun tidak ada angka standar produktivitas dan itu bervariasi , wajar untuk mengatakan angka produktivitas 1000 LOC per bulan cukup baik (Meskipun terendah 100 LOC per bulan untuk embedded system). 

Dengan produktivitas ini, tim profesional di organisasi perangkat lunak akan mengambil 10 orang untuk membuat program. Mengapa perbedaan ini dengan produktivitas dalam dua skenario? Mengapa bahwa mahasiswa yang sama yang dapat menghasilkan software pada produktivitas beberapa ribu LOC per bulan saat kuliah berakhir dan hanya memproduksi sekitar 1000 LOC per bulan ketika bekerja di sebuah perusahaan?

Jawabannya tentu saja, bahwa ada dua hal yang berbeda yang sedang dibuat dalam dua skenario. Pada bagian pertama, sistem mahasiswa sedang dibuat dan tidak digunakan. Karena, tidak ada signifikansi tergantung pada perangkat lunak dan kehadiran bug dan kurangnya kualitas tidak menjadi perhatian utama. Baik kualitas lain seperti kegunaan, pemeliharaan, portabilitas dll. Di sisi lain, sistem perangkat lunak industri  dibuat untuk memecahkan beberapa masalah klien dan digunakan oleh organisasi klien untuk operasi beberapa bagian bisnis, dan jika ada kerusakan sistem , dapat memiliki dampak besar dalam hal kerugian keuangan atau bisnis, ketidaknyamanan kepada pengguna, atau kerugian harta benda dan kehidupan.  Akibatnya, sistem perangkat lunak harus berkualitas tinggi sehubungan dengan sifat seperti keandalan, kegunaan, portabilitas, dll.

Industri perangkat lunak sebagian besar tertarik untuk mengembangkan industri software, dan bidang rekayasa perangkat lunak yang berfokus pada bagaimana membuat sistem. Artinya, masalah domain untuk rekayasa perangkat lunak adalah industrial software. Dalam sisa bab ini, kita akan belajar :

• Bahwa kualitas, biaya dan jadwal adalah kekuatan utama yang mendorong  industrial project perangkat lunak.
• Bagaimana biaya dan produktivitas didefinisikan dan diukur untuk project tersebut, dan bagaimana kualitas dari software akan ditandai dan diukur.
• Bahwa skala besar dan perubahan adalah atribut penting dari domain masalah dan pendekatan solusi harus menangani mereka.

1.1          Cost, Schedule, and Quality

Kualitas tinggi membedakan software industri dari yang lain, biaya dan jadwal yang menjadi kekuatan pendorong utama lainnya untuk perangkat lunak tersebut. Dalam kekuatan industri domain software, ada tiga kekuatan yang dasar yaitu biaya, jadwal, dan kualitas. Perangkat lunak ini harus diproduksi dengan biaya murah, diwaktu yang wajar, dan harus berkualitas baik.

Software industri  sangat mahal karena faktanya bahwa pengembangan perangkat lunak sangat rumit. Untuk mendapatkan ide dari biaya yang terlibat, kita bisa perhatikan keadaannya saat praktik di industri.  Baris kode (LOC) atau ribuan baris kode (KLOC) yang paling umum digunakan ukuran-ukuran software di industri. Produktivitas di industri perangkat lunak,  untuk menulis kode umumnya berkisar dari beberapa ratus hingga sekitar 1000 LOC per bulan. Jadwal merupakan faktor penting dalam banyak project. Untuk software ini berarti perlu dikembangkan lebih cepat, dan dalam waktu yang ditentukan.

Produktivitas dalam hal Output (KLOC) per bulan dapat memadai biaya dan schedule. Jika produktivitas lebih tinggi, itu harus jelas bahwa biaya dari orang akan lebih rendah (pekerjaan yang sama kini dapat dilakukan dengan lebih sedikit per bulan).

Faktor utama lainnya adalah kualitas. Kualitas yaitu salah satu pokok utama, dan bisnis strategi yang dirancang sesuai dengan prosedur yang ada. Sayangnya, sejumlah kasus besar telah terjadi mengenai tidak dapat diandalkan perangkat lunak. Perangkat lunak sering tidak melakukan apa yang seharusnya dilakukan atau melakukan sesuatu tidak seharusnya dilakukan. Mengembangkan perangkat lunak yang berkualitas tinggi adalah tujuan dasar dari gudang rekayasa perangkat lunak. sementara biaya umumnya dipahami, konsep kualitas dalam konteks perangkat lunak perlu penjelasan lebih lanjut. Standar internasional tentang kualitas produk software menunjukkan bahwa kualitas perangkat lunak terdiri dari enam atribut utama.

                                                                                                                   

Atribut dapat didefinisikan sebagai berikut:

• Functionality,  kemampuan untuk menyediakan fungsi untuk memenuhi kebutuhan yang software gunakan.
• Reability,  kemampuan untuk memperbaiki kegagalan.
• Usability, kemampuan untuk dipahami, dipelajari, dan digunakan.
• Efficiency, kemampuan untuk memberikan kinerja yang relatif dan tepat untuk jumlah sumber daya yang digunakan.
• Maintainability., kemampuan untuk memodifikasi keperluan membuat perbaikan atau adaptasi.
• Portability, kemampuan untuk menyesuaikan dengan lingkungan tertentu yang berbeda tanpa menerapkan tindakan selain yang disediakan untuk tujuan dalam produk.

Untuk menentukan kualitas dari produk software, kita perlu menentukan jumlah bug dalam perangkat lunak yang akan disampaikan. Perlu dijelaskan jika menggunakan definisi kualitas, apa yang cacat pada sebuah software harus didefinisikan secara jelas. Sebuah cacat bisa menjadi masalah dalam perangkat lunak yang menyebabkan software crash atau menjadi masalah yang menyebabkan output menjadi tidak benar, salah mengeja beberapa kata, dll. Selain kehandalan, atribut kualitas lain yang sangat menarik adalah pemelihara kemampuan. Pemeliharaan diperlukan untuk mengubah perangkat lunak yang dikirimkan untuk memenuhi kebutuhan pengguna dan lingkungan, yang mengarah ke pemeliharaan adaptif. Selama sistem perangkat lunak hidup, biaya pemeliharaan dapat jauh melebihi biaya pengembangan asli. Karena biaya yang tinggi ini, atribut maintainability yang disampaikan software harus menarik dan jelas untuk memiliki sistem perangkat lunak yang lebih mudah untuk mempertahankan.

1.2            Scale and Change

Kebanyakan sistem perangkat lunak industri cenderung besar dan kompleks, membutuhkan puluhan ribu baris kode. Seperti yang diharapkan, pengembangan sistem besar membutuhkan satu set yang berbeda dari metode pengembangan sistem kecil, seperti metode yang digunakan untuk mengembangkan sistem yang kecil sering tidak meningkatkan ke sistem yang besar. Sebuah contoh yang akan menggambarkan hal ini. Mempertimbangkan masalah, menghitung orang di sebuah ruangan dan membandingkannya dengan mengambil sensus suatu negara. Keduanya dasarnya sama-sama menghitung masalah. Namun metode yang digunakan untuk menghitung orang di sebuah ruangan akan tidak bekerja.

Setiap project software melibatkan penggunaan teknik dan management project. Dalam project kecil, metode informal bagi pengembangan dan pengelolaan dapat digunakan. Namun, untuk project-project besar harus jauh lebih ketat seperti yang diilustrasikan pada Gambar 1.2. Dengan kata lain, untuk berhasil melaksanakan proyek, sebuah metode yang tepat untuk rekayasa sistem harus bekerja dan proyek telah dikelola ketat untuk memastikan biaya, jadwal, dan kualitas tetap dapat terkontrol. Skala besar adalah karakteristik kunci dari domain masalah dan pendekatan solusi yang harus menggunakan alat dan teknik yang memiliki kemampuan untuk membangun sistem perangkat lunak besar.

Seperti yang dibahas diatas, software harus berubah bahkan setelah itu diserahkan. Meskipun secara perubahan tradisional dalam perangkat lunak, selama pemeliharaan telah dibedakan dari perubahan yan terjadi pada saat pembuatan berlangsung.

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

1.3            Summary

                

•  Masalah domain untuk rekayasa perangkat lunak adalah perangkat lunak industri. Perangkat lunak ini dimaksudkan untuk memecahkan beberapa masalah,  beberapa set pengguna, dan diharapkan menjadi berkualitas tinggi.
• Dalam domain masalah ini, biaya, jadwal, dan kualitas kekuatan pendorong dasar. Oleh karena itu, metode dan alat-alat yang akan digunakan untuk memecahkan masalah dalam hal ini domain harus memastikan produktivitas yang tinggi dan kualitas tinggi.
• Produktivitas diukur sebagai jumlah output per unit dari sumber daya input. Di software, output dapat diukur dalam hal baris kode yang disampaikan, dan sebagai waktu,  manusia adalah sumber daya utama, input dapat diukur sebagai orang.
• Kualitas Software memiliki banyak atribut yang meliputi fungsi, reliabilitas, kegunaan, efisiensi, pemeliharaan, dan portabilitas. Keandalan sering dianggap sebagai atribut kualitas utama, dan seperti tidak dapat diandalkan dalam perangkat lunak adalah karena cacat dalam perangkat lunak, kualitas dapat dicirikan oleh jumlah cacat per seribu baris kode.
• Masalah dalam domain ini sering cenderung sangat besar dan dimana kebutuhan pelanggan berubah cepat. Oleh karena itu teknik yang digunakan untuk mengembangkan  software kekuatan industri harus sedemikian rupa sehingga mereka mampu membangun sistem perangkat lunak yang besar, dan memiliki kemampuan untuk menangani perubahan.

Self-Assessment Exercises

1. Apa perbedaan antara perangkat lunak utama mahasiswa dan industri perangkat lunak
2.  Jika mengembangkan program untuk memecahkan masalah membutuhkan usaha E, diperkirakan bahwa perangkat lunak industri  untuk memecahkan masalah yang akan membutuhkan 10E upaya. Darimana anda pikir biaya usaha ekstra ini dihabiskan?
3. Pengukuran Apa yang akan anda ambil dalam sebuah proyek untuk mengukur produktivitas, dan bagaimana anda akan menentukan produktivitas dari langkah-langkah ini?
4.  Apa atribut yang berbeda dari kualitas perangkat lunak? Jika untuk sistem akuntansi,  kita paling tertarik untuk memastikan bahwa perangkat lunak tidak membuat kesalahan perhitungan, maka yang dari atribut kualitas mana yang harus kita paling dahulukan
5. Apa beberapa tugas manajemen proyek yang akan anda lakukan secara berbeda untuk proyek besar dibandingkan dengan proyek kecil? Bagaimana eksekusi ini dapat berubah.
6. Perubahan, misalkan harus membuat untuk perangkat lunak sistem yang beroperasi. Mengapa akan perubahan sistem seperti biaya lebih banyak daripada hanya membuat perubahan pada file kode?

tugas rpl 1

Aisyah Dian Rahmasari
S1/SI/3B/Pagi
43A87007150368

Sebutkan :
- Pengertian
- Diagram
- Proses / Cara kerja
- Advantages / Perbandingan jika dibandingkan dengan program lain
- Disadvantages / Kerugian
Dari masing-masing metode berikut ini :
- Waterfall Model
- Prototyping
- Iteravite Development
- Rational Unified Process
- Timeboxing Model
- Extreme Programming dan Agile Process

Software development process models
1) Waterfall Model
a. Penjelasan
Waterfall atau air terjun adalah model yang dikembangkan untuk pengembangan perangkat lunak, membuat perangkat lunak. Model berkembang secara sistematis dari satu tahap ke tahap lain dalam mode seperti air terjun. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.
b. Diagram

 














 c. Proses / Tahap kerja

• Analisis Kebutuhan
  Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.
• Desain Sistem
  Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.
• Penulisan Kode Sistem
  Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.
• Integration & Testing
  Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.
• Operation & Maintenance
  Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.

d. Keuntungan waterfall

• Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.
• Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi setiap fase atau tahapan akan mempunyai dokumen tertentu.
• Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.
•  Cocok untuk system yang bersifat generic (software banyak orang yang pakai, bersifat umum)

e. Kelemahan Waterfall

• Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.
• Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.
• Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.
• Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.

2) Prototyping
a. Penjelasan
Prototyping perangkat lunak (software prototyping) atau siklus hidup menggunakan protoyping (life cycle using prototyping) adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model). Tujuannya adalah mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat dari pada metode tradisional dan biayanya menjadi lebih rendah. Ada banyak cara untuk memprotoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.
b. Diagram

c. Proses/ tahapan kerja

• Pengumpulan kebutuhan
  Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
• Membangun prototyping
  Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output).
• Evaluasi protoptyping
  Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulang langkah 1, 2 , dan 3.
• Mengkodekan sistem
  Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.
• Menguji sistem
  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.
• Evaluasi Sistem
  Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan. Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.
• Menggunakan sistem
  Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.

d. Keuntungan prototype

• Pelanggan berpartisipasi aktif dalam pengembangan sistem, sehingga hasil produk pengembangan akan semakin mudah disesuaikan dengan keinginan dan kebutuhan pelanggan
• Mempersingkat waktu pengembangan produk perangkat lunak.
• Adanya komunikasi yang baik antara pengembang dan pelanggan.
• Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.
• Lebih menghemat waktu dalam pengembangan sistem.
• Penerapan menjadi lebih mudah karena pelanggan mengetahui apa yang diharapkannya.

e. Kelemahan prototype

• Proses analisis dan perancangan terlalu singkat.
• Biasanya kurang fleksibel dalam mengahadapi perubahan.
• Walaupun pemakai melihat berbagai perbaikan dari setiap versi prototype, tetapi pemakai mungkin tidak menyadari bahwa versi tersebut dibuat tanpa memperhatikan kualitas dan pemeliharaan jangka panjang.
• Pengembang kadang-kadang membuat kompromi implementasi dengan menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak efisien.

3) Iterative development
a. Penjelasan
Metode yang merupakan pengembangan dari prototyping model dan digunakan ketika requirement dari software akan terus berkembang dalam tahapan-tahapan pengembangan aplikasi tersebut

b. .Diagram

c. Tahap kerja

• Mendefinisikan tujuan dan kebutuhan bisnis, mengembangkan desain konseptual, rancangan konsep, rencana pengujian, dan analis terhadap resiko dengan melibatkan pemakai.
• Mendefinisikan kebutuhan sistem, mengembangkan desail logikal, mengkompilasi (software-build) rancangan awal, mengevaluasi hasil dengan melibatkan pemakai.
• Mendefinisikan kebutuhan subsistem, menghasilkan desain fisikal, mengkompilasi rancangan berikutnya, mengevaluasi hasil dengan melibatkan pemakai.
• Mendefinisikan kebutuhan setiap unit, menghasilkan desain akhir, mengkompilasi rancangan akhir.

d. Keuntungan

• - User dapat mencoba sistem yg sudah dikembangkan dan kemudian dapat memberikan masukkan > keterlibatan user semakin intens dampak positif dalam pengembangan
• - Prototype relatif lebih mudah dibangun dan tidak memerlukan waktu lama
• - Dengan prototype, kesalahan & kelalaian dalam pengembangan dapat segera diketahui

e. Kelemahan

• Setiap iterasi bergantung prototype sebelumnya solusi final umumnya terjadi apabila ada perbedaan yg nyata pada prototype sebelumnya
• Formal end-of-phasemungkin tidak terjadi, karena sangat sulit menentukan scope dari suatu      prototype > proyek tidak pernah selesai
• Dokumentasi seringkali tdk lengkap > fokus pada pembuatan prototype
• Isu2 mengenai system backup & recovery, system performance dan system security, kurang/tidak diperhatikan dan sering terlupakan

4) Rational Unified Process (RUP)
a. Penjelasan
RUP , singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software , suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan mereka.
b. Diagram

c. Proses / tahap kerja

•  Dimensi Horizontal

Mewakili aspek-aspek dinamis dari pengembangan PL. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir dari awal dari phase selanjutnya.

•  Dimensi Vertikal

Mewakili aspek-aspek statis dari pengembangan PL yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing, what, how dan when.

Fase RUP
1) Inception
· Menentukan Ruang lingkup proyek
· Membuat ‘Business Case’
· Menjawab pertanyaan “apakah yang dikerjakan dapat menciptakan ‘good business sense’ sehingga proyek dapat dilanjutkan
2) Elaboration
· Menganalisa berbagai persyaratan dan resiko
· Menetapkan ‘base line’
· Merencanakan fase berikutnya yaitu construction
3) Construction
· Melakukan sederetan iterasi
· Pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan testing
4) Transition
· Membuat apa yang sudah dimodelkan menjadi suatu produk jadi
· Dalam fase ini dilakukan:
- Beta dan performance testing
- Membuat dokumentasi tambahan seperti; training, user guides dan sales kit
- Membuat rencana peluncuran produk ke komunitas pengguna

d. Keuntungan

• · Menyediakan petunjuk bagaimana menggunakan UMC secara efektif.
• · Mendukung proses pengulangan dalam pengembangan software.
• · Memungkinkan adanya penambahan-penambahan ada proses.
• · Memungkinkan untuk secara sistematis mengontrol perubahan-perubahan yang terjadi pada software selama proses pengembangannya.
• · Memungkinkan untuk menjalankan test case dengan enggunakan Rational Test Manager Tool.

e. Kelemahan
· Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak yang berorientasi objek dengan berfokus pada UML (Unified Modeling Language).


5) Time Boxing Model
a. Penjelasan
Dalam model timeboxing, unit dasar dari pembangunan adalah kotak waktu, yang adalah jangka waktu yang tetap. Karena durasi adalah tetap, faktor kunci dalam memilih persyaratan atau fitur yang akan dibangun di kotak waktu yang bisa masuk ke dalam waktu box. Hal ini berbeda dengan pendekatan berulang biasa di mana fungsi dipilih dan kemudian waktu untuk memberikan ditentukan. Perubahan timeboxing perspektif pembangunan dan membuat jadwal non dinegosiasikan dan Komitmen prioritas tinggi.
b. Diagram

c. Langkah kerja
Timeboxing model menentukan jangka waktu tertentu yang dialokasikan untuk menyelesaikan berbagai macam tugas. Apabila waktu yang ditentukan tersebut selesai, maka pembangunan sistem akan pindah ke tugas berikutnya, dengan harapan bahwa sebagian besar dari critical work telah berhasil diselesaikan sebelum waktu keseluruhan berakhir.

d. Keuntungan

• · Kecepatan model ini sampai proses pengerjaan dan dapat mempersingkat waktu pengiriman.
• · Model ini cocok untuk mengembangkan projek dengan beberapa fitur dalam waktu singkat.

e. Kelemahan

• · Managemen projek akan menjadi lebih kompleks
• · Tidak cocok untuk projek dimana seluruh pengerjaan tidak dapat dibagi menjadi beberapa iterations.

6) Extreme programming
a. Penjelasan
Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak.
XP mengambil pendekatan ‘ekstrim’ dalam iterative development.
b. Diagram

c. Proses / tahap kerja

• Planning/Perencanaan

Pada tahap perencanaan ini dimulai dari pengumpulan kebutuhan yang membantu tim teknikal untuk memahami konteks bisnis dari sebuah aplikasi. Selain itu pada tahap ini juga mendefinisikan output yang akan dihasilkan, fitur yang dimiliki oleh aplikasi dan fungsi dari aplikasi yang dikembangkan.

• Design/Perancangan

Metode ini menekankan desain aplikasi yang sederhana, untuk mendesain aplikasi dapat menggunakanClass-Responsibility-Collaborator (CRC) cards yang mengidentifikasi dan mengatur class pada object-oriented.

• Coding/Pengkodean

Konsep utama dari tahapan pengkodean pada extreme programming adalah pair programming, melibatkan lebih dari satu orang untuk menyusun kode.

• Coding/Pengujian

Pada tahapan ini lebih fokus pada pengujian fitur dan fungsionalitas dari aplikasi.

d. Keuntungan

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

e. Kelemahan

• Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).
• Dokumentasi formal yang dibuat selama pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user.
• Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.

7) Agile
a. Penjelasan
Agile Modeling merupakan filosofi tentang bagaimana membangun model, dengan beberapa diantaranya dilakukan secara format dan terperinci dan yang lainnya dilakukan secara samar dan minim. Agile Software Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya


b. Diagram

c. Proses / tahap kerja

• Perencanaan

· Requierements Analysis: langkah ini merupakan analisa terhadap kebutuhan system. Pengumpulan data dalam tahap ini bisa melakukan sebuah penelitian, wawancara atau study literature. Seorang system analisis akan menggali informasi sebanyak-banyaknya dari user sehingga akan tercipta sebuah sistem komputer yang bisa melakukan tugas-tugas yang diinginkan oleh user tersebut. Tahapan ini akan menghasilkan dokumen user requierements atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan system. Dokumen inilah yang akan menjadi acuan system analis untuk menerjemahkan ke dalam bahasa pemrograman.
· Desain: Proses desain akan menerjemahkan syarat kebutuhan ke sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat koding. Proses ini berfokus pada: struktur data arsitektur perangkat lunak, representasi interface, dan detail (algoritma) procedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirement. Dokumen inilah yang akan digunakan programmer untuk melakukan aktivitas pembuatan sistemnya.
· Coding: Coding merupakan penerjemahan design dalam bahasa yang bisa dikenali oleh computer. Dilakukan oleh programmer yang akan menterjemahkan transaksi yang diminta oleh user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan suatu system. Dalam artian penggunaan computer akan dimaksimalkan dalam tahapan ini.
· Testing: testing adalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki.

d. Keuntungan

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

e. Kelemahan

• Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
• Agile tidak akan berjalan dengan baik jika komitmen tim kurang.
• Tidak cocok dalam skala tim yang besar (>20 orang).
• Perkiraan waktu release dan harga perangkat lunak sulit ditentukan.