NAMA : LA ODE MUHAMMAD ILHAM SETIAWAN

NIM : F1G120006
PROGRAM STUDI : ILMU KOMPUTER

TUGAS 5 REKAYASA PERANGKAT LUNAK

Terkadang kita perlu memiliki pengetahuan mendalam tentang proses dan praktik rekayasa
perangkat lunak terbaru untuk mengirimkan produk tepat waktu. Terkadang yang kita
butuhkan hanyalah editor teks, keyboard, dan ide kasar tentang apa yang harus dilakukan.
Apa yang saya lakukan di sini adalah untuk membantu Anda memahami berbagai proses
yang tersedia untuk Anda, sehingga Anda dapat membuat pilihan terbaik untuk proyek Anda.
Model proses linier mengikuti pola fase yang diselesaikan satu demi satu tanpa mengulangi
fase sebelumnya. Produk dirancang, dikembangkan, dan dirilis tanpa meninjau kembali fase
sebelumnya. Silakan pilih model proses linier dari daftar. A. setiap fase terjadi secara
berurutan dan kemudian mengulang kembali ke awal ketika semua fase selesai. B. setiap fase
terjadi secara paralel dengan fase lainnya, sampai produk selesai tanpa pengulangan di antara
atau di dalam fase. C. setiap fase terjadi secara berurutan dan tidak pernah berulang atau
berulang. Atau D. setiap fase dapat diulang, sampai produk selesai. Jawaban yang benar
adalah C, model proses linier adalah model yang tidak mendukung perulangan di dalam atau
di antara fase proses. Model proses yang memungkinkan perulangan disebut model iteratif.
Model linier juga mengharuskan fase dilakukan secara berurutan, tanpa tumpang tindih antar
fase. Model proses yang memungkinkan terjadinya overlap disebut model paralel. Jadi
pertama-tama mari kita bicara tentang yang mungkin paling sering Anda dengar. Model
proses air terjun. Jika Anda mencari ke dalam rekayasa perangkat lunak, Anda mungkin
pernah mendengar tentang yang satu ini. Model air terjun yang lebih tua dikritik karena tidak
efisien dan membatasi. Mari kita bicara tentang model air terjun lebih detail, sehingga kita
bisa melihat kekuatan dan kelemahannya. Waterfall menempatkan banyak penekanan pada
pendokumentasian hal-hal seperti persyaratan dan arsitektur, untuk menangkap pemahaman
tertulis umum dari perangkat lunak oleh tim pengembangan. Namun, model air terjun tidak
terlalu mudah beradaptasi dengan perubahan, artinya, tidak terlalu gesit. Salah satu
kemunduran utama model air terjun adalah, tidak memungkinkan tim pengembangan untuk
meninjau dan memperbaiki produk mereka. Seperti yang kami katakan sebelumnya,
perangkat lunak adalah hal yang sangat dinamis. Model air terjun sama sekali tidak dirancang
untuk mengatasi perubahan arus tengah, yang mungkin memerlukan peninjauan kembali
fase-fase sebelumnya. Akibatnya, ada variasi model air terjun yang memungkinkan peluang
umpan balik ke fase sebelumnya dan aktivitasnya untuk mendukung perubahan tertentu.
Tetapi bagaimana jika klien Anda membutuhkan perubahan sejak dokumen persyaratan
disetujui. Model air terjun memenuhi tujuannya, tetapi ketidakmampuannya untuk
memastikan bahwa pekerjaan yang dilakukan diverifikasi dengan tepat adalah kekurangan
yang serius. Untuk mencoba mengatasi hal ini, model V pengembangan perangkat lunak
muncul. Ini sangat mirip dengan model air terjun di mana satu hal terjadi setelah yang lain
secara berurutan. Perbedaannya adalah menekankan kegiatan verifikasi untuk memastikan
implementasi sesuai dengan perilaku desain. Ini juga memastikan bahwa desain yang
diterapkan sesuai dengan persyaratan. Idenya adalah untuk mengatur setiap tingkat verifikasi
ke fase yang sesuai, bukan sekaligus. Apa yang membedakan model-V dari model air terjun
adalah bahwa model-V secara khusus membagi dirinya menjadi dua cabang, oleh karena itu,
nama V. Seperti model air terjun, model-V dimulai dengan persyaratan, dan dimasukkan ke
dalam arsitektur dan desain sistem. Cabang ini diwakili oleh sisi kiri V. Diikuti dari atas ke
bawah. Di akhir cabang ini, penekanan bergeser dari desain ke penerapan. Ini adalah bagian
bawah V. Setelah implementasi selesai, model kemudian mengalihkan penekanannya ke
kegiatan verifikasi, yang diwakili oleh sisi kanan V, diikuti dari bawah ke atas. Setiap fase di
sisi kanan dimaksudkan untuk memeriksa fase yang sesuai di sisi kiri V. Berikut ini
contohnya. Di sisi kiri V-Model, tim pengembangan Anda merencanakan pengujian unit
untuk diterapkan nanti. Tes unit ini dirancang untuk memastikan bahwa kode yang Anda tulis
benar-benar mengatasi masalah yang Anda coba selesaikan. Ketika dalam fase pengujian unit
di sisi kanan V, pengujian unit ini kemudian dijalankan dalam kode untuk memastikan
bahwa, setelah semuanya ditulis, semua kode Anda berjalan dengan benar. Setelah pengujian
dijalankan, dan semuanya berjalan lancar, tim beralih ke fase pengujian integrasi. Jadi dengan
cara ini, sisi kanan V, memverifikasi sisi kiri. Model V memiliki kelebihan dan kekurangan
yang sama dengan model air terjun. Ini mudah diterapkan, tetapi tidak memperhitungkan
aspek penting dari pengembangan perangkat lunak. Seperti keniscayaan perubahan. Namun,
model-V memungkinkan tim pengembangan untuk memverifikasi pekerjaan fase konstruktif
dari proses. Jadi kita akan sampai di suatu tempat, tetapi klien ini masih belum bisa melihat
produk jadi sampai akhir ketika semuanya sudah selesai. Pelajari diagram kami yang
menggambarkan model-V pengembangan perangkat lunak. Saat Anda berada dalam fase
desain tingkat tinggi, Anda membuat pengujian yang kemudian dijalankan dalam fase
pengujian integrasi. Anda tidak menjalankan tes dari fase berikutnya atau terakhir, atau dari
fase pengkodean. Jadi, sekarang kita membutuhkan proses yang memungkinkan kita untuk
melibatkan klien di sepanjang jalan, bukan hanya di akhir ketika produk dianggap selesai. Di
situlah model Sawtooth masuk. Model ini sangat mirip dengan dua model terakhir. Dan itu
juga merupakan model linier dari pengembangan perangkat lunak. Namun, ini juga
meningkatkan mereka karena memberi Anda interaksi klien yang sangat dibutuhkan selama
proses berlangsung. Apa yang membuat model gigi gergaji berbeda adalah membedakan
antara klien dan tim pengembangan. Dalam model ini, tugas yang membutuhkan kehadiran
klien dan tugas yang hanya membutuhkan tim pengembangan dibuat berbeda. Tugas klien ini
diselingi sepanjang proses, sehingga umpan balik dapat dikumpulkan pada waktu yang
berarti. Jadi karena mirip dengan dua konsep terakhir, Pada kenyataannya, mengembangkan
produk perangkat lunak adalah upaya kreatif, yang memerlukan eksperimen dan pengerjaan
ulang yang konstan. Juga, di masa lalu, waktu komputer mahal dibandingkan dengan tenaga
manusia. Fokusnya adalah membuat tugas-tugas seperti pemrograman menjadi efisien untuk
komputer, meskipun belum tentu untuk orang. Untuk pengembangan perangkat lunak, waktu
siklus antara menulis satu baris kode dan melihat hasilnya bisa berjam-jam. Ini tidak
mendukung pengembang mencoba eksperimen pemrograman kecil untuk menguji ide mereka
dengan cepat. Ini, bagaimanapun, menempatkan fokus pada mencoba untuk mendapatkan
hal-hal yang benar pertama kali dan menghindari kerja ulang. Model proses linier cocok
dengan pemikiran awal ini. Namun demikian, ketika mendokumentasikan internal produk
perangkat lunak untuk pengembang baru. Anda mungkin masih menggambarkan proyek
secara linier, melalui fase dan dokumen terkait. Meskipun mungkin telah mengikuti beberapa
proses lain. Ini menempatkan beberapa kemiripan ketertiban. Sehingga pengembang baru
tidak perlu menghidupkan kembali keseluruhan proyek, hanya belajar awalnya tentang
implementasinya saat ini. Ini mirip dengan versi rasional yang bersih dari bukti matematika
dan teori ilmiah yang Anda temukan di buku teks. Model proses perangkat lunak berulang
adalah model yang memungkinkan untuk mengulangi tahapan proses. Mereka adalah siklus.
Model berulang, memperluas model linier, yang telah kita bicarakan sebelumnya.
Keuntungan terbesar yang mereka bawa ke meja adalah bahwa mereka menambahkan
kemampuan untuk mengulang kembali langkah-langkah sebelumnya. Setiap loop kembali
adalah iterasi, maka model iteratif. Iterasi memungkinkan umpan balik dalam proses. Model
berulang dapat dianggap sebagai cikal bakal praktik yang benar-benar gesit, namun juga,
mewujudkan langkah-langkah berurutan, yang mengingatkan pada proses linier sebelumnya.
Ketika model Spiral diperkenalkan oleh Barry Boehm pada tahun 1986, itu menguraikan
proses dasar untuk merancang dan mengimplementasikan sistem perangkat lunak, dengan
meninjau kembali fase proses, setelah selesai. Pada tingkat dasar, model terdiri dari empat
kuadran. Saat Anda bergerak melalui proses ini, idenya adalah Anda berpindah dari satu
kuadran ke kuadran lainnya. Pertimbangkan masing-masing dari empat kuadran ini, sebagai
fase dari sebuah iterasi. Di mana iterasi adalah, durasi satu spiral penuh atau keempat fase
kuadran, diselesaikan satu kali. Masing-masing fase ini berisi aktivitas, seperti yang
didefinisikan Morgan dalam modul pertama. Di Spiral, Anda mulai dengan membuat tujuan
dan kebutuhan, dan menghasilkan solusi untuk iterasi saat ini. Kemudian, Anda
mengidentifikasi dan menilai risiko, dan mengevaluasi solusi tersebut. Anda kemudian
beralih ke pengembangan dan pengujian produk dalam iterasi saat ini. Setelah Anda memiliki
produk yang memenuhi tujuan, Anda melanjutkan ke perencanaan iterasi berikutnya. Jika
setiap kuadran adalah fase dari sebuah iterasi, maka setelah Anda menyelesaikan sebuah
iterasi, Anda pindah ke yang berikutnya. Itulah aliran dasar yang terkait dengan model Spiral.
Anda secara bertahap membangun produk, dengan mengulangi siklus fase. Pada iterasi
berikutnya, Anda dapat memulai lagi dengan menentukan tujuan dari iterasi. Mungkin, fitur
yang akan ditambahkan ke prototipe yang baru saja Anda buat. Kemudian, Anda akan
mengevaluasi fitur-fitur ini, dan beralih ke membangun fitur yang Anda anggap tepat. Anda
kemudian meninjau apa yang perlu dilakukan untuk iterasi berikutnya, dan melanjutkan dari
sana. Sampai proyek telah selesai untuk kepuasan klien Anda. Jadi tidak seperti model linier,
yang kami jelaskan dalam pelajaran terakhir, model berulang, seperti Spiral, cenderung
mengulangi elemen proses secara keseluruhan. Ini berarti bahwa model Spiral
memungkinkan tim pengembangan untuk meninjau produk mereka di akhir setiap iterasi
spiral. Melakukannya dapat lebih memastikan bahwa produk Anda dibuat sesuai spesifikasi. .
Meskipun beberapa aspek proyek mengikuti model Spiral dapat berubah dari proyek ke
proyek, enam kondisi hampir selalu tetap sama. Ini disebut invarian dari model Spiral. Yang
menarik dari ini, adalah sebagian besar, invarian sebenarnya juga berlaku untuk banyak
model proses lainnya. Sekarang invarian ini bisa menjadi sangat teknis. Jadi, daripada
membahas secara rinci tentang keenamnya, saya hanya akan membahas konsep inti dari
beberapa invarian kunci. . Invarian pertama model Spiral menyatakan bahwa semua produk
kerja, dari proyek perangkat lunak, harus dibuat secara bersamaan, pada waktu yang sama.
Ini mungkin tampak aneh, tetapi ide dasarnya adalah bahwa tanpa mendefinisikan hal-hal
pada saat yang sama, Anda membahayakan proyek Anda. Ini karena dengan metode
Waterfall yang biasa, melakukan sesuatu secara berurutan berarti membuat keputusan hanya
berdasarkan informasi yang terbatas. Invarian kedua dari model Spiral sangat sederhana.
Semua kuadran dalam model harus ditangani, tidak ada langkah yang dilewati. Ini karena
setiap kuadran model, membawa nilai, jika Anda melewatkan satu, Anda menempatkan
proyek Anda pada risiko yang tidak perlu. Karena apa yang mungkin Anda lakukan adalah
membuat asumsi tentang proyek tersebut. Asumsi, tentu saja, bisa salah. Anda tidak ingin
membangun proyek berdasarkan asumsi yang salah. Empat invarian terakhir cukup teknis,
jadi saya tidak akan membahas banyak detail. Pada dasarnya mereka mengatakan ini, setiap
proyek yang menerapkan model Spiral harus mendasarkan jumlah waktu yang mereka
habiskan untuk aktivitas tertentu, pada jumlah risiko yang terlibat dalam melaksanakan
aktivitas itu. Ini banyak berfokus untuk memastikan bahwa Anda mendasarkan keputusan
Anda pada data risiko. Invarian lain juga menyebutkan bahwa setiap iterasi Spiral harus
menghasilkan produk kerja yang nyata. Dan bahwa fokus proses harus pada peningkatan
proses, secara keseluruhan. Jadi semua invarian ini membangun untuk membuat model
Spiral. Model Spiral adalah contoh yang bagus dari proses berulang. Hal-hal dilakukan
dengan cara yang memungkinkan revisi produk dalam interval tertentu. Seperti model proses
lainnya, ia memiliki kelemahan. . Model spiral adalah model iteratif dari pengembangan
perangkat lunak. Artinya produk dibangun dalam serangkaian fase yang berulang. Ini berbeda
dengan model proses linier, yang telah kita bahas di awal modul ini. Seperti model Waterfall
dan model V. Dalam pelajaran ini, saya akan berbicara tentang model iteratif lain dari
pengembangan perangkat lunak. Model Proses Terpadu atau hanya Proses Terpadu. Seperti
yang saya katakan sebelumnya, proses terpadu adalah model iteratif dari pengembangan
perangkat lunak. Struktur dasarnya adalah bekerja dalam serangkaian fase yang diulang
sampai fase akhir dianggap selesai. Dalam sebagian besar fase proses terpadu, pengembangan
terjadi dalam iterasi kecil hingga fase dianggap selesai. Biasanya, fase dianggap selesai ketika
tonggak pencapaian tercapai. Proses terpadu mencoba untuk menekankan perkembangan
bertahap sebanyak mungkin. Arsitektur adalah seperangkat desain di mana produk perangkat
lunak dibangun. Jadi dalam proses terpadu, fokus tim pengembangan adalah mengembangkan
model desain bersama dengan produk yang berfungsi. Sementara struktur umum unified
adalah membangun secara iteratif, model memungkinkan tugas yang dilakukan dalam satu
fase tumpang tindih dengan yang lain. Ini disebut melakukan pekerjaan secara paralel. Jadi,
alih-alih hanya melalui serangkaian fase, pengembang sebenarnya dapat melakukan hal-hal
seperti mendesain arsitektur produk sambil mengembangkan pengujian pada saat yang
bersamaan. Fase pertama dari proses terpadu disebut fase awal. Fase ini dimaksudkan untuk
menjadi kecil, hanya cukup waktu untuk memastikan bahwa Anda memiliki dasar yang
cukup kuat untuk melanjutkan ke fase berikutnya. Faktanya fase awal adalah satu-satunya
fase dalam proses terpadu di mana pengembangan tidak terjadi dalam iterasi. Jika fase awal
Anda panjang, ini mungkin menunjukkan bahwa Anda telah menghabiskan terlalu banyak
waktu untuk membangun persyaratan di fase awal. Tujuan utama Anda adalah untuk melihat
apakah ada kasus bisnis yang cukup kuat untuk melanjutkan pengembangan. Artinya, harus
ada alasan keuangan yang cukup baik untuk membangun produk. Untuk melakukan ini, fase
awal memerlukan pembuatan kasus penggunaan dasar. Kasus penggunaan menguraikan
interaksi pengguna utama dengan suatu produk. Pada fase ini, Anda juga menentukan ruang
lingkup proyek dan potensi risiko. Jika Anda ingin mempelajari lebih lanjut tentang kasus
penggunaan dan cara membuatnya, silakan lihat kursus tentang kebutuhan klien dan
persyaratan perangkat lunak. Pada akhir fase awal Anda mencapai tonggak tujuan siklus
hidup. Pada titik ini, Anda akan memiliki deskripsi yang masuk akal tentang seberapa layak
produk tersebut dan siap untuk melanjutkan ke fase proses berikutnya, fase elaborasi. Fase
elaborasi adalah yang pertama dari fase proses terpadu untuk mengimplementasikan iterasi
kecil itu, yang saya sebutkan sebelumnya dalam pelajaran ini. Tujuan fase ini pada dasarnya
adalah membuat model, atau prototipe produk, yang akan Anda perbaiki nanti. Kita akan
berbicara lebih banyak tentang berbagai jenis prototipe nanti dalam modul ini. Untuk saat ini
tujuan dari fase ini adalah untuk mendefinisikan arsitektur sistem. Pengembang
mendefinisikan persyaratan yang dikandung dalam fase awal. Mereka juga mengembangkan
persyaratan utama dalam dokumentasi arsitektur, seperti diagram use case dan diagram kelas
tingkat tinggi. Ini memberikan dasar di mana pembangunan yang sebenarnya akan dibangun.
Di akhir fase elaborasi, pengembang menyampaikan rencana pengembangan di fase
selanjutnya, fase konstruksi. Rencana ini pada dasarnya dibangun di atas apa yang
dikembangkan selama awal dan mengintegrasikan semua yang dipelajari selama elaborasi
sehingga konstruksi dapat terjadi secara efektif. Ingat, dalam model proses terpadu,
pengembangan dapat terjadi secara paralel. . Tahap konstruksi sangat mudah. Ini adalah fase
lain di mana pengembangan dapat terjadi secara berulang. Ini berfokus pada pembangunan di
atas pekerjaan yang dilakukan dalam elaborasi. Pada fase konstruksi, kasus penggunaan
menyeluruh dikembangkan untuk mendorong pengembangan produk. Kasus penggunaan ini
lebih kuat daripada yang dibuat pada fase awal. Kasus penggunaan fase konstruksi
menawarkan wawasan yang lebih spesifik tentang bagaimana produk Anda harus dibuat.
Produk Anda dibuat secara berulang selama fase konstruksi ini hingga produk Anda siap
untuk dirilis. Pada saat itu, tim pengembangan Anda mulai mentransisikan produk Anda ke
klien dan pengguna Anda. Bukan berarti produk kerja ini tidak juga terjadi pada tahap
konstruksi. Hanya saja mereka lebih fokus dalam elaborasi. Anda mengidentifikasi kasus
bisnis yang kuat untuk proyek di fase awal. Dalam fase transisi ini, Anda memiliki
peluncuran besar produk Anda. Tim pengembangan Anda menerima umpan balik dari
pengguna Anda. Pada titik inilah Anda benar-benar melihat seberapa baik desain Anda sesuai
dengan kebutuhan pengguna Anda. Dengan mengumpulkan umpan balik ini, tim
pengembangan Anda dapat meningkatkan produk Anda, membuat perbaikan bug, dan rilis
lainnya. Setelah produk Anda menyelesaikan iterasinya, dimungkinkan untuk mengulang
kembali fase-fase proses terpadu.
Sebelum itu, saya membahas proses berulang lain yang disebut spiral. Semoga Anda dapat
melihat bahwa saat saya memperkenalkan proses ini, masing-masing menjadi lebih canggih
daripada yang terakhir. Kami sedang membangun proses yang lebih maju, tetapi itu tidak
berarti bahwa belajar tentang proses yang lebih sederhana ini tidak penting. Sementara yang
satu mungkin kurang canggih dari yang lain, itu tidak berarti bahwa itu tidak memiliki nilai.
Faktanya, semua proses yang telah saya bahas sejauh ini sebenarnya cukup sering digunakan
di industri saat ini. Dalam pelajaran ini, saya akan berbicara tentang sesuatu yang berlaku
untuk model proses spiral dan terpadu, yang baru saja kita bicarakan, prototipe. Ada lima
jenis prototipe yang akan saya bahas dalam pelajaran ini. Mereka dapat berupa gambar di atas
serbet, tayangan slide singkat, atau bahkan beberapa kartu indeks dengan komponen yang
digambar di atasnya. Prototipe ilustratif membantu mendapatkan tampilan dan nuansa sistem
yang benar, tanpa menginvestasikan banyak waktu atau uang untuk mengembangkan produk.
Ketika saya membuat prototipe, saya pribadi suka membuat prototipe dengan fungsionalitas
yang saya rencanakan untuk diterapkan. Prototipe kemudian menjadi contoh yang sedikit
lebih realistis tentang bagaimana sebuah produk terlihat tanpa harus mengeluarkan banyak
energi ekstra. Anda dapat mencapai hasil yang serupa dengan fitur yang digambar di atas
kertas. Anda dapat mendemonstrasikan sebuah ide dengan menukar satu layar kertas dengan
yang lain, ketika pengguna akhir memilih elemen tertentu. Teknik ini biasanya digunakan
ketika waktunya singkat, dan hanya ide dasar yang diperlukan untuk menyampaikan
maksudnya. Salah satu cara yang saya lihat berhasil adalah pada proyek yang menggunakan
komunikasi nirkabel antar perangkat sebagai aspek kunci dari fungsinya. Menulis kode yang
memungkinkan pengguna untuk benar-benar berkomunikasi secara nirkabel ke perangkat lain
akan memakan waktu lama, jadi tim pengembang malah menjadi kreatif. Saya memiliki
program tayangan slide yang menjalankan setiap perangkat. Ketika satu perangkat akan
mengirim data ke yang lain, para pengembang akan dengan cerdik memajukan tayangan slide
di perangkat lain. Tim pengembangan melakukan ini dengan waktu yang cukup baik
sehingga sepertinya data benar-benar telah ditransmisikan di antara kedua perangkat. Dan itu
bisa memberi Anda gambaran yang sangat bagus tentang bagaimana produk Anda akan
terlihat setelah selesai. Jika Anda memiliki lebih banyak waktu dan Anda ingin pemahaman
yang lebih komprehensif tentang seperti apa produk itu nantinya, beberapa tim beralih ke apa
yang kami sebut prototipe eksplorasi. Anda juga dapat menentukan upaya yang diperlukan
untuk membangun proyek itu. Anda membangun kode yang berfungsi sehingga Anda benar-
benar dapat melihat apa yang mungkin. Versi pertama yang Anda buat adalah apa yang
disebut prototipe sekali pakai. Mungkin ada banyak pelajaran berguna untuk dipelajari dan
masalah yang harus dihindari dalam versi kedua. Setelah melihat desain produk, mereka
menyarankan pendekatan berbeda yang menggunakan beberapa fitur yang sudah dibangun.
Carly mulai dengan prototipe kerja yang kemudian diperluas. Oke, jadi semoga, Anda tidak
berakhir dengan prototipe sekali pakai yang tidak disengaja. Tiga jenis prototipe yang baru
saja saya uraikan adalah semua prototipe yang pada akhirnya tidak digunakan secara
langsung dalam versi final produk. Ide utamanya adalah memiliki perangkat lunak yang
berfungsi untuk setiap prototipe yang berurutan, yang mana pun dapat dirilis sebagai versi
produk perangkat lunak Anda. Anda akan mengembangkan produk Anda dari yang paling
penting hingga yang paling tidak penting. Jadi, Anda menetapkan prioritas fitur produk
berdasarkan apa yang harus dilakukan, harus dilakukan, dan apa yang bisa dilakukan. Anda
menetapkan fitur inti Anda ke prioritas yang harus dilakukan. Kemudian, Anda menetapkan
semua fitur yang akan mendukung produk Anda tetapi tidak terlalu penting untuk dilakukan.
Segala sesuatu yang lain yang tampak seperti fitur asing kemudian akan ditetapkan ke
prioritas yang dapat dilakukan. Berdasarkan peringkat ini, Anda kemudian akan
mengembangkan produk Anda dengan memulai dengan fitur yang Anda tetapkan sebagai
prioritas yang harus dilakukan. Produk perangkat lunak yang dihasilkan berisi fitur inti dan
dapat dirilis sebagai prototipe tambahan. Kemudian, jika sumber daya mengizinkan, Anda
mengembangkan fitur di bawah prioritas yang harus dilakukan. Dan kemudian fitur-fitur
yang bisa dilakukan, yang menghasilkan prototipe inkremental berfitur lebih lengkap. Apa
pun yang terkait dengan itu, seperti mengintegrasikan kemampuan untuk menemukan pesan
pengguna lain, mengirim dan menerima fungsi, atau mengedit teks, bisa menjadi prioritas
tertinggi Anda. Jadi fitur-fitur ini akan ditetapkan ke prioritas yang harus dilakukan. Fitur-
fitur ini akan dianggap sebagai fungsi yang harus dilakukan. Fitur apa pun seperti dapat
mengubah font pesan, mengirim gambar khusus ke pengguna lain, atau memposting tautan,
mungkin akan ditetapkan ke yang bisa dilakukan. Sebenarnya, gagasan untuk
memprioritaskan fitur Anda dan mengerjakan rencana Anda adalah konsep dasar, yang akan
Anda lihat berulang dalam kursus Perencanaan Agile untuk Persyaratan Perangkat Lunak.
Mari kita uji pengetahuan Anda dan lihat apa yang Anda ingat. Dan/atau D, Prototipe
tambahan mungkin berisi perangkat lunak yang berfungsi untuk produk akhir. Jawaban yang
benar adalah A dan D. Prototipe tambahan berbeda dari yang sebelumnya yang kita
bicarakan, karena mereka memungkinkan tim pengembangan Anda untuk membuat produk
yang berpotensi dirilis. Hal ini dilakukan dengan mengembangkan fitur-fitur yang telah
diprioritaskan menggunakan sistem triage. Jenis prototipe terakhir, yang akan saya bicarakan,
adalah prototipe evolusioner. Mari kita bandingkan ini menggunakan contoh aplikasi
perpesanan yang saya uraikan sebelumnya. Kemudian, kami membangun prototipe produk
secara bertahap yang menyertakan fitur yang paling penting hingga yang paling tidak
penting. Misalnya, prototipe evolusi selanjutnya dapat membuat fitur yang ada lebih mudah
atau lebih fleksibel untuk digunakan. Awalnya, pengguna mungkin harus menentukan jalur
foto yang akan ditambahkan ke profil. Bukan cara yang sangat efisien dalam melakukan
sesuatu, tetapi berhasil. Di prototipe lain, pengembang itu mungkin mengizinkan pengguna
untuk memilih foto dari menu tarik-turun foto yang tersedia. Jadi dengan cara ini, produk
Anda berkembang dari prototipe kerja yang belum sempurna menjadi sesuatu yang kaya fitur
dan kuat. Prototyping inkremental dan evolusioner adalah cara untuk membuat perangkat
lunak yang berfungsi yang dapat ditampilkan secara berkala untuk mendapatkan umpan balik
lebih lanjut. Ini adalah dorongan moral yang nyata bagi tim pengembangan Anda untuk
melihat produk seiring berjalannya waktu. Baiklah, jadi Anda sekarang mengetahui beberapa
jenis proses yang berbeda. Sekarang, pikirkan kembali apa yang Anda pelajari dalam
pelajaran sebelumnya tentang model spiral dan proses terpadu. Dengan membuat prototipe,
Anda dapat memvisualisasikan dengan lebih baik apa yang dilakukan produk Anda, dan oleh
karena itu, membuat keputusan fitur berdasarkan tampilan produk tersebut. Versi pertama
Anda hanyalah sebuah ide yang ditulis di beberapa lembar kertas.