SOFTWARE PROBLEM

Nama : Annisa Aprilya
Npm : 43A87007150334
Kelas : S1/SI/3/B P

BAB 1

PERMASALAHAN PERANGKAT LUNAK

Mengapa ini menjadi perbedaan selisih produktivitas dalam dua skenario? Mengapa siswa yang sama yang dapat menghasilkan software pada produktivitas beberapa ribu LOC per bulan saat kuliah berakhir hanya memproduksi sekitar seribu LOC per bulan ketika bekerja di sebuah perusahaan?

Jawabannya, tentu saja, adalah bahwa dua hal perbedaan sedang dibangun dalam dua skenario. Pada bagian pertama, sistem mahasiswa sedang dibangun yang terutama dimaksudkan untuk tujuan demonstrasi, dan tidak diharapkan untuk digunakan kemudian. Karena tidak digunakan, tidak ada signifikansi tergantung pada perangkat lunak dan adanya bug dan kurangnya kualitas tidak menjadi perhatian utama. Tidak adalah masalah kualitas lainnya seperti kegunaan, pemeliharaan, portabilitas dll.

Di sisi lain, sistem perangkat lunak industri-kekuatan dibangun untuk memecahkan beberapa masalah klien dan digunakan oleh organisasi klien untuk operasi beberapa bagian dari bisnis, dan kerusakan sistem tersebut dapat memiliki dampak besar dalam hal keuangan atau kerugian 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

Kebutuhan ini untuk kualitas tinggi dan untuk memenuhi pengguna akhir memiliki dampak yang besar pada perangkat lunak cara dikembangkan dan biaya. Aturan praktis Brooks memberikan menunjukkan bahwa perangkat lunak kekuatan industri mungkin biaya sekitar 10 kali perangkat lunak siswa.

Industri perangkat lunak sebagian besar tertarik untuk mengembangkan perangkat lunak industri-kekuatan, dan bidang rekayasa perangkat lunak berfokus pada bagaimana membangun sistem tersebut. Artinya, masalah domain untuk rekayasa perangkat lunak adalah perangkat lunak kekuatan industri. Di sisa lain, ketika kita menggunakan software jangka, kita berarti perangkat lunak kekuatan industri. Dalam sisa bab ini, kita akan belajar:

- Bahwa kualitas, biaya, dan jadwal adalah kekuatan utama yang mendorong (kekuatan industri) proyek perangkat lunak.


- Bagaimana biaya dan produktivitas didefinisikan dan diukur untuk proyek semacam itu, dan bagaimana kualitas software ditandai dan diukur.

- Bahwa skala besar dan perubahan adalah atribut penting dari masalah domain dan solusi pendekatan harus menangani mereka.

1.1. Biaya, Jadwal, dan Kualitas

Software industri-kekuatan sangat mahal terutama karena fakta bahwa pengembangan perangkat lunak sangat padat karya. Untuk mendapatkan ide dari biaya yang terlibat, mari kita perhatikan keadaan saat praktik di industri. Baris kode (LOC) atau ribuan baris kode (KLOC) disampaikan adalah yang palingumum digunakan ukuran ukuran software di industri. Karena biaya utama memproduksi perangkat lunak adalah tenaga yang digunakan, biaya pengembangan perangkat lunak biasanya diukur dalam hal orang-bulan dari usaha menghabiskan dalam pembangunan. Dan produktivitas sering diukur dalam industri dalam hal LOC (atau KLOC) per orang per bulan.

Produktivitas di industri perangkat lunak untuk menulis kode segar biasanya berkisar antara beberapa ratus sampai sekitar 1000 + LOC per orang bulan. Ini produktivity adalah atas seluruh siklus pengembangan, bukan hanya tugas coding. perusahaan perangkat lunak sering mengeluarkan biaya kepada klien untuk siapa mereka yang sedang mengembangkan perangkat lunak menjadi $ 3000 - $ 15.000 per orang per bulan. Dengan produktivitas 1000 LOC per orang per bulan, itu berarti bahwa setiap baris dari biaya kode disampaikan antara $ 3 dan $ 15! Dan bahkan proyek-proyek kecil dapat dengan mudah berakhir dengan software dari 50.000 LOC. Dengan produktivitas ini, seperti proyek software akan biaya antara $ 150.000 dan $ 750.000!

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

Jelas, oleh karena itu, mengurangi biaya dan waktu siklus untuk perangkat lunak de-Pembangunan adalah tujuan utama dari rekayasa perangkat lunak. Produktivitas dalam hal output (KLOC) satu orang perbulan memadai dapat menangkap biaya dan kekhawatiran schedule. Jika produktivitas lebih tinggi, itu harus jelas bahwa biaya dalam hal satu orang perbulan akan lebih rendah (kerjasama dapatdilakukan dengan lebih sedikit satu orang per bulan). Demikian pula, jika produktivitas lebih tinggi, potensi pengembangan perangkat lunak dalam waktu kurang meningkatkan-tim produktivitas yang lebih tinggi akan menyelesaikan pekerjaan dalam waktu kurang dari tim ukuran yang sama dengan produktivitas rendah. (Waktu yang sebenarnya proyek ini akan mengambil, tentu saja, tergantung juga pada jumlah orang al-terletak proyek.) Oleh karena itu, mengejar produktivitas yang lebih tinggi adalah kekuatan pendorong dasar di balik rekayasa perangkat lunak dan alasan utama untuk menggunakan alat yang berbeda dan teknik.

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

- Fungsi. kemampuan untuk menyediakan fungsi yang memenuhi dinyatakan dan tersirat kebutuhan ketika perangkat lunak yang digunakan.

- Keandalan. kemampuan untuk menyediakan layanan kegagalan bebas.

- Usability. kemampuan untuk dipahami, dipelajari, dan digunakan.

- Efisiensi. kemampuan untuk memberikan kinerja yang relatif sesuai dengan jumlah sumber daya yang digunakan.

- Rawatan. kemampuan yang akan dimodifikasi untuk keperluan membuat cor-rections, perbaikan, atau adaptasi.

- Portabilitas. kemampuan yang akan disesuaikan untuk menetapkan perbedaan lingkungan tanpa menerapkan aksi atau cara lain dengan syarat untuk tujuan di dalam produk.

1.2. Skala dan Perubahan 5

Pendekatan yang digunakan, maka diharapkan proyek ini akan memiliki kerapatan cacat yang sama sebagai proyek masa lalu.

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

Selain kehandalan, atribut kualitas lain yang sangat menarik adalah menjaga-kemampuan. Setelah perangkat lunak disampaikan dan disebarkan, memasuki tahap pemeliharaan. Mengapa pemeliharaan diperlukan untuk perangkat lunak, ketika perangkat lunak tidak memiliki komponen fisik yang dapat menurunkan dengan usia? Software perlu dipertahankan be-penyebab cacat sisa yang tersisa dalam sistem. Hal ini umumnya percaya bahwa keadaan seni saat ini adalah terbatas dan mengembangkan perangkat lunak dengan nol de-fect density tidak mungkin. cacat ini, sekali ditemukan, perlu dihapus, yang mengarah ke apa yang disebut pemeliharaan korektif. Pemeliharaan juga diperlukan untuk mengubah perangkat lunak yang dikirimkan untuk memenuhi kebutuhan disempurnakan pengguna dan lingkungan, yang mengarah ke adaptif pemeliharaan. Selama hidup dari sistem perangkat lunak, biaya pemeliharaan jauh dapat melebihi biaya pengembangan asli.

Setiap proyek software melibatkan penggunaan teknik dan proyek mengelola-ment. Dalam proyek-proyek kecil, metode informal bagi pengembangan dan pengelolaan dapat digunakan. Namun, untuk proyek-proyek besar, keduanya harus jauh lebih ketat, seperti yang diilustrasikan pada Gambar 1.2. Dengan kata lain, untuk berhasil melaksanakan proyek, metode yang tepat untuk rekayasa sistem harus bekerja dan proyek harus dikelola ketat untuk memastikan bahwa biaya, jadwal, dan kualitas berada di bawah kontrol. skala besar adalah karakteristik kunci dari domain masalah dan pendekatan solusi harus menggunakan alat dan teknik yang memiliki kemampuan untuk membangun sistem perangkat lunak besar.

Perubahan adalah karakteristik lain dari domain masalah yang ap-proaches untuk pembangunan harus menangani. Sebagai set lengkap persyaratan untuk sistem ini umumnya tidak diketahui (sering tidak bisa diketahui pada awal proyek) atau menyatakan, sebagai hasil pengembangan dan waktu berlalu, persyaratan tambahan diidentifikasi, yang perlu dimasukkan dalam perangkat lunak menjadi- ing dikembangkan. Hal ini perlu untuk perubahan mengharuskan metode untuk pengembangan merangkul perubahan dan mengakomodasi efisien. permintaan perubahan bisa sangat mengganggu proyek, dan jika tidak ditangani dengan baik, dapat mengkonsumsi sampai 30 sampai 40% dari biaya pembangunan.
Seperti dibahas di atas, software harus berubah bahkan setelah dikerahkan. Meskipun secara tradisional perubahan software selama pemeliharaan telah dibedakan dari perubahan yang terjadi saat pembangunan berlangsung, garis ini kabur, sebagai fundamental perubahan kedua skenario tersebut.

Secara keseluruhan, karena dunia berubah lebih cepat, software harus berubah lebih cepat, bahkan saat dalam pengembangan. Oleh karena itu perubahan kebutuhan adalah characteris-tic dari domain masalah. Dalam dunia sekarang ini, pendekatan yang tidak dapat menerima dan mengakomodasi perubahan yang sedikit digunakan-mereka dapat memecahkan hanya mereka beberapa masalah yang tahan perubahan.

1.3. Ringkasan

- Masalah domain untuk rekayasa perangkat lunak adalah perangkat lunak kekuatan 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 domain ini harus memastikan produktivitas yang tinggi dan kualitas tinggi.

- Produktivitas diukur sebagai jumlah output per unit dari sumber daya input. Dalam perangkat lunak, output dapat diukur dalam hal baris kode disampaikan, dan sebagai waktu manusia adalah sumber daya utama, input dapat diukur sebagai orang-bulan. Produktivitas sehingga dapat diukur sebagai baris kode disampaikan per orang bulan.

- Kualitas Software memiliki banyak atribut yang meliputi fungsi, reliabil-ity, kegunaan, e FFI efisiensi, maintainability, dan portabilitas. Keandalan sering


1.4. Masalah Perangkat Lunak

- Dianggap sebagai atribut kualitas utama, dan seperti tidak dapat diandalkan dalam perangkat lunak adalah disebabkan oleh cacat pada perangkat lunak, kualitas dapat ditandai dengan jumlah cacat per seribu baris kode.

- Masalah dalam domain ini sering cenderung sangat besar dan di mana kebutuhan pelanggan berubah cepat. Oleh karena itu teknik yang digunakan untuk mengembangkan perangkat lunak industri-kekuatan harus sedemikian rupa sehingga mereka mampu membangun sistem perangkat lunak besar, dan memiliki kemampuan untuk menangani perubahan.

TUGAS 1 RPL (Sistem Pengembangan Software)

NAMA: ANNISA APRILYA

KELAS: S1/SI/3/B/P

NPM: 43A87007150334

 

1. WATERFALL MODEL

 

Pengertian Waterfall Model

Model waterfall adalah sesuatu proses perkembangan perangkat lunak secara beruntun, dimana kemajuan dari perangkat lunak dipandang sebagai terus mengalir ke bawah diibaratkan seperti air terjun yang melewati fase-fase perencanaan,implementasi (kontruksi), dan pengujian. Model Pengembangan Air Terjun, merupakan paradigma model pengembangan perangkat lunak paling tua, dan paling banyak dipakai. Model ini mengusulkan sebuah pendekatan perkembangan perangkat lunak yang sistematik dan sekunsial yang dimulai pada tingkat dan kemajuan sistem pada seluruh tahapan analisis, desain , kode, pengujian, dan pemeliharaan. 

DIAGRAM WATERFALL MODEL

Proses Kerja Waterfall Model

• Rekayasa dan pemodelan sistem/informasi

Langkah pertama dimulai dengan membangun keseluruhan elemen sistem dan memilah bagian-bagian mana yang akan dijadikan bahan pengembangan perangkat lunak, dengan memperhatikan hubungannya dengan Hardware, User, dan Database.

• Analisis kebutuhan perangkat lunak

Pada proses ini, dilakukan penganalisaan dan pengumpulan kebutuhan sistem yang meliputi Domain informasi, fungsi yang dibutuhkan unjuk kerja/performansi dan antarmuka. Hasil penganalisaan dan pengumpulan tersebut didokumentasikan dan diperlihatkan kembali kepada pelanggan.

• Desain

Pada proses Desain, dilakukan penerjemahan syarat kebutuhan sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuatnya proses pengkodean (coding). Proses ini berfokus pada struktur data, arsitektur perangkat lunak, representasi interface, dan detail algoritma prosedural.

• Pengkodean

Pengkodean merupakan proses menterjemahkan perancangan desain ke bentuk yang dapat dimengerti oleh mesin, dengan menggunakan bahasa pemrograman.

• Pengujian

Setelah Proses Pengkodean selesai, dilanjutkan dengan proses pengujian pada program perangkat lunak, baik Pengujian logika internal, maupun Pengujian eksternal fungsional untuk memeriksa segala kemungkinan terjadinya kesalahan dan memeriksa apakah hasil dari pengembangan tersebut sesuai dengan hasil yang diinginkan.

• Pemeliharaan

Proses Pemeliharaan erupakan bagian paling akhir dari siklus pengembangan dan dilakukan setelah perangkat lunak dipergunakan. Kegiatan yang dilakukan pada proses pemeliharaan antara lain :

• Corrective Maintenance : yaitu mengoreksi apabila terdapat kesalahan pada perangkat lunak, yang baru terdeteksi pada saat perangkat lunak dipergunakan.
• Adaptive Maintenance : yaitu dilakukannya penyesuaian/perubahan sesuai dengan lingkungan yang baru, misalnya hardware, periperal, sistem operasi baru, atau sebagai tuntutan atas perkembangan sistem komputer, misalnya penambahan driver, dll.
• Perfektive Maintenance : Bila perangkat lunak sukses dipergunakan oleh pemakai. Pemeliharaan ditujukan untuk menambah kemampuannya seperti memberikan fungsi-fungsi tambahan, peningkatan kinerja dan sebagainya.

• Contoh Penerapan dari Pengembangan Waterfall Model

Contoh dari penerapan model pengembangan ini adalah pembuatan program pendaftaran online ke suatu Instansi Pendidikan. Program ini akan sangat membantu dalam proses pendaftaran, karena dapat meng-efektifkan waktu serta pendaftar tidak perlu repot-repot langsung mendatangi Instansi Pendidikan. Teknisnya adalah sebagai berikut :

• Sistem program untuk pendaftaran dibuat menggunakan bahasa pemrograman PHP, dengan Sistem Database yang dibuat menggunakan MySQL, dan diterapkan (diaplikasikan) pada PC (personal computer) dengan sistem operasi berbasis Microsoft Windows, Linux, dan sebagainya.
• Setelah program selesai dibuat dan kemudian dipergunakan oleh user, programmer akan memelihara serta menambah atau menyesuaikan program dengan kebutuhan serta kondisi user.

• Kelebihan Waterfall Model :
• Tahapan proses pengembangannya tetap (pasti), mudah diaplikasikan, dan prosesnya teratur.
• Cocok digunakan untuk produk software/program yang sudah jelas kebutuhannya di awal, sehingga minim kesalahannya.
• Software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
• Documen pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

• Kekurangan Waterfall Model :
• Proyek yang sebenarnya jarang mengikuti alur sekuensial seperti diusulkan, sehingga perubahan yang terjadi dapat menyebabkan hasil yang sudah didapatkan tim pengembang harus diubah kembali/iterasi sering menyebabkan masalah baru.
• Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses.
• Sulit untuk mengalami perubahan kebutuhan yang diinginkan oleh customer/pelanggan.
• Pelanggan harus sabar untuk menanti produk selesai, karena dikerjakan tahap per tahap, dan proses pengerjaanya akan berlanjut ke setiap tahapan bila tahap sebelumnya sudah benar-benar selesai.
• Perubahan ditengah-tengah pengerjaan produk akan membuat bingung tim pengembang yang sedang membuat produk.
• Adanya waktu kosong (menganggur) bagi pengembang, karena harus menunggu anggota tim proyek lainnya menuntaskan pekerjaannya.

2. PROTOTYPING

Pengertian Prototyping

Prototyping adalah sebuah proses penampilan persyaratan, pengaplikasian prinsip analisis, dan penyusuna model perangkat lunakyang akan dibangun untuk penilaian dan pengembangan. Akhirnya ada lingkungan yang membutuhkan kontruksi prototype pada awal analisis, karena model adalah satu satunya alat dimana persyaratan dapat ditarik secara efektf. Model tersebut kemudian dikembangan dalam perangkat lunak produksi..

DIAGRAM PROTOTYPING

Proses Kerja Prototyping

• 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 keinginan pelanggan atau belum. Jika sudah sesuai, maka langkah selanjutnya akan diambil. Namun jika tidak, prototyping direvisi dengan mengulang langkah-langkah sebelumnya.

• 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, kemudian dilakukan proses Pengujian. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur, dll.

• Evaluasi Sistem

Pelanggan mengevaluasi apakah perangkat lunak yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, maka proses akan dilanjutkan ke tahap selanjutnya, namun jika perangkat lunak yang sudah jadi tidak/belum sesuai dengan apa yang diharapkan, maka tahapan sebelumnya akan diulang.

• Menggunakan sistem

Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan. Model Prototyping ini sangat sesuai diterapkan untuk kondisi yang beresiko tinggi di mana masalah-masalah tidak terstruktur dengan baik, terdapat fluktuasi kebutuhan pemakai yang berubah dari waktu ke waktu atau yang tidak terduga, bila interaksi dengan pemakai menjadi syarat mutlak dan waktu yang tersedia sangat terbatas sehingga butuh penyelesaian yang segera. Model ini juga dapat berjalan dengan maksimal pada situasi di mana sistem yang diharapkan adalah yang inovatif dan mutakhir sementara tahap penggunaan sistemnya relatif singkat.

Kelebihan Model Prototype :

• Pelanggan berpartisipasi aktif dalam pengembangan sistem, sehingga hasil produk pengembangan akan semakin mudah disesuaikan dengan keinginan dan kebutuhan pelanggan.
• Penentuan kebutuhan lebih mudah diwujudkan.
• 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.

Kekurangan Model 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

Penjelasan Iterative Development

Iterative Development adalah metode yang merupakan pengembangan dari prototyping model dan digunakan ketika requirement dari software akan terus berkembang dalam tahapan-tahapan pengembangan aplikasi tersebut. Sedikit pengertian tentang requirement software dari developer yang diterapkan pada tahap pertama iterasi, akan mendapatkan tanggapan dari user. Ketika requirement menjadi jelas, tahapan iterasi selanjutnya akan dilaksanakan.

DIAGRAM ITERATIVE DEVELOPMENT

Proses Iterative Development

1. Mendefinisikan tujuan dan kebutuhan bisnis, mengembangkan desain konseptual,

2. Rancangan konsep, rencana pengujian, dan analis terhadap resiko dengan melibatkan pemakai.

3. Mendefinisikan kebutuhan sistem, mengembangkan desail logikal, mengkompilasi (software-build)   rancangan awal, mengevaluasi hasil dengan melibatkan pemakai.

4. Mendefinisikan kebutuhan subsistem, menghasilkan desain fisikal, mengkompilasi rancangan berikutnya, mengevaluasi hasil dengan melibatkan pemakai.

5. Mendefinisikan kebutuhan setiap unit, menghasilkan desain akhir, mengkompilasi rancangan akhir.

Keuntungan Iterative Development 

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

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

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

Kelemahan Iterative Development

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

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

3. Dokumentasi seringkali tdk lengkap > fokus pada pembuatan prototype

4. Isu2 mengenai system backup & recovery, system performance dan system security, kurang/tidak diperhatikan dan sering terlupakan

4. RATIONAL UNIFIED PROCESS

Penjelasan RUP

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

DIAGRAM RATIONAL UNIFIED PROCESS

Proses Kerja RUP

1. Inception
Pada tahap ini pengembang mendefinisikan batasan kegiatan, melakukan analisis kebutuhan user , dan melakukan perancangan awal perangkat lunak (perancangan arsitektural dan user case). Pada akhir fase ini, prototipe perangakat lunak versi Alpha harus sudah dirilis.

2. Elaboration
Pada tahap ini dilakukan perancangan perangkat lunak mulai dari menspesifikan fitur perangkat lunak hingga perilisan prototipe versi Betha dari perangkat lunak.

3.Contruction
Pengimplentasian rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini. Pada akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator dirilis beserta dokumentasi perangkata lunak.

4.Transition
Instalasi, deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini.

Keuntungan RUP

• Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
• Menyediakan petunjuk bagaimana menggunakan UML secara efektif.
• Mendukung proses pengulangan dalam pengembangan software.
• Memungkinkan adanya penambahan-penambahan pada proses.
• Memungkinkan untuk secara sistematis mengontrol perubahan-perubahan yang terjadi pada software selama proses pengembangannya.
• Memungkinkan untuk menjalankan test case dengan menggunakan Rational Test

Kekurangan RUP

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

5. TIMEBOXING MODEL

Penjelsan Time boxing

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

DIAGRAM TIMEBOXING MODEL

Proses Kerja Timeboxing Model

Timeboxing model menentukan jangka waktu tertentu yang dialokasikan untuk menyelesaikan berbagai macam Proses / Cara Kerja Timeboxing Model. 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.

Kelebihan Timeboxing Model

a. Kecepatan model ini sampai proses pengerjaan dan dapat mempersingkat waktu pengiriman.

b. Model ini cocok untuk mengembangkan projek dengan beberapa fitur dalam waktu singkat.

Kelemahan Timeboxing Model

a. Managemen projek akan menjadi lebih kompleks 

b. Tidak cock untuk projek dimana seluruh pengerjaan tidak dapat dibagi menjadi beberapa iterations.

6. EXTREME PROGRAMMING

 

Pengertian Extreme Programming (XP)

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

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

DIAGRAM EXTREME PROGRAMMING

Proses Extreme Programming

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

Kelebihan Extreme Programming

1. Menjalin komunikasi yang baik dengan klien. (Planning Phase)

2. Menurunkan biaya pengembangan (Implementation Phase)

3. Meningkatkan komunikasi dan sifat saling menghargai antar developer. (Implementation Phase)

4. 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)

Kelemahan Extreme Programming

1. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukanapa yang diperlukan hari itu juga).

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

3. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user.

7. AGILE PROCESS

Penjelasan Agile methods
Agile Process merupakan sekelompok aktifitas pembangunan perangkat lunak secara iteratif yang menekankan pada aktifitas konstruksi (desain dan koding). Agile Process mengeliminasi sebagian besar waktu untuk melakukan perencanaan sistem dan berusaha sebisa mungkin mematuhi jadwal deliver sistem yang telah dijanjikan. Requirements yang dibutuhkan secara langsung di-drive oleh pelanggan itu sendiri, dan apabila terjadi perubahan terhadap requirements tersebut, pengembang dituntut mampu beradaptasi dengan perubahan yang terjadi.

DIAGRAM AGILE PROCESS

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

1. Perencanaan
2. Requirements Analysis : Langkah ini merupakan analisa terhadap kebutuhan sistem. Pengumpulan data dalam tahap ini bisa malakukan sebuah penelitian, wawancara atau study literatur. Seorang sistemanalis 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 requirment atau bisa dikatakan sebagaidata yang berhubungan dengan keinginan
user dalam pembuatan sistem. Dokumen ini yang akan menjadi acuan sistem analis untuk menterjemahkan ke dalam bahasa pemprogram.
3. Desain : Proses desain akan menerjemahkan syarat kebutuhan kesebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada : struktur data, arsitektur perangkat lunak, representasi interface, dan detail(algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirment. Dokumen yang akan digunakan proggrammer untuk melakukan aktivitas pembuatan sistemnya.
4. Coding : Coding merupakan penerjemahan design dalam bahasa yangbisa dikenali oleh komputer. Dilakukan oleh programmer yang akan meterjemahkan transaksi yang diminta oleh user. Tahapan ini yang merupakan tahapan secara nyata dalam mengerjakan suatu sistem.Dalam artian penggunaan komputer akan dimaksimalkan dalam tahapan ini.
5. Testing :adalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki
6. Dokumentasi

Kelebihan dari agile

• Meningkatkan kepuasan kepada klien.

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

• Pembangunan system dibuat lebih cepat.

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

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

Kekurangan dari agile

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