REKAYASA PERANGKAT LUNAK PERTEMUAN 3: KEBUTUHAN PERANGKAT LUNAK

 1. REKAYASA KEBUTUHAN 

• Kebutuhan untuk suatu sistem adalah deskripsi tentang apa yang harus dilakukan oleh sistem berupa layanan yang diberikan dan kendala dalam operasinya.

 • Kebutuhan ini mencerminkan kebutuhan pelanggan untuk sistem yang melayani tujuan tertentu seperti mengontrol perangkat, menempatkan pesanan, atau mencari informasi. 

• Proses mencari tahu, menganalisis, mendokumentasikan serta memeriksa layanan dan kendala ini disebut Rekayasa Kebutuhan (Requirement Engineering). 

• Rekayasa Kebutuhan harus disesuaikan dengan kebutuhan proses, proyek, produk, dan orang-orang yang melakukan pekerjaan. 

Jenis Kebutuhan: 

1. Kebutuhan pengguna adalah pernyataan, dalam bahasa alami ditambah diagram, dari layanan apa yang diharapkan sistem untuk diberikan kepada pengguna sistem dan kendala di mana ia harus beroperasi. 

2. Kebutuhan sistem adalah deskripsi yang lebih rinci tentang fungsi, layanan, dan kendala operasional sistem perangkat lunak. Dokumen Kebutuhan sistem (kadang-kadang disebut spesifikasi fungsional) harus mendefinisikan secara tepat apa yang akan diimplementasikan. Ini mungkin menjadi bagian dari kontrak antara pembeli sistem dan pengembang perangkat lunak.

Kegiatan pada Rekayasa Kebutuhan: Pengenalan Permasalahan (Inception), Pengenalan Lanjutan (Elicitation), Elaborasi (Elaboration), Negosiasi, Spesifikasi (Specification), Validasi (Validation), Manajemen Kebutuhan (Requirement Management),

 A. Pengenalan Permasalahan (Inception) 

• Proyek PL dimulai ketika kebutuhan bisnis atau pasar atau layanan baru telah diidentifikasi atau ditemukan
• Menetapkan pemahaman dasar tentang masalah, siapa yang menginginkan solusi, sifat solusi, serta keefektifan komunikasi dan kolaborasi antara stakeholder dengan tim PL.

 B. Pengenalan Lanjutan (Elicitation) 

• Bagian penting dari elisitasi adalah untuk menetapkan tujuan bisnis. 

• Masalah yang sering dijumpai: 

✓ Lingkup permasalahan: tentang batasan sistem tidak jelas atau rincian teknis yang membingungkan 

✓ Permasalahan yang berkaitan dengan pemahaman 

✓ Permasalahan yang berkaitan dengan kestabilan

 Kegiatan pada tahap ini adalah: 

1. Kebutuhan penemuan 

adalah proses pengumpulan informasi tentang sistem yang diperlukan dan sistem yang ada, filterisasi pengguna dan kebutuhan sistem. Sumber informasi selama tahap penemuan kebutuhan termasuk dokumentasi, stakeholder, dan spesifikasi sistem.

 2. Klasifikasi Kebutuhan dan Organisasi 

Kegiatan ini mengumpulkan kebutuhan yang tidak terstruktur dan kebutuhan kelompok yang bersifat koheren. Cara pengelompokkan kebutuhan menggunakan model arsitektur sistem untuk mengidentifikasi sub-sistem dan untuk menghubungkan kebutuhan dengan masingmasing sub-sistem. 

3. Kebutuhan Prioritas dan Negosiasi 

Kegiatan ini berkaitan dengan memprioritaskan kebutuhan dan menemukan cara penyelesaian konflik melalui negosiasi.

 C. Elaborasi (Elaboration)  

Elaborasi dilakukan dengan cara membuat dan penyempurnaan skenario pengguna yang menggambarkan bagaimana pengguna akhir (dan aktor lain) akan berinteraksi dengan sistem. 

 D. Negosiasi 

Konflik yang terjadi antara pelanggan, pengguna dan stakeholder harus didamaikan dengan pendekatan yang bersifat iteratif untuk menentukan skala prioritas kebutuhan, menilai biaya-biaya dan risiko masingmasing.

 E. Spesifikasi (Specification)

 • Spesifikasi kebutuhan adalah proses menuliskan kebutuhan pengguna dan kebutuhan sistem ke dalam dokumen kebutuhan. 

• Spesifikasi dapat berupa dokumen tertulis, model grafis, model matematika formal, kumpulan skenario penggunaan sistem/PL, prototipe, atau kombinasi dari semuanya. 

• Kebutuhan pengguna menggambarkan kebutuhan fungsional dan non-fungsional sehingga dapat dimengerti oleh pengguna sistem (perilaku eksternal dari sistem) yang tidak memiliki pengetahuan teknis. 

• Dokumen kebutuhan tidak boleh menyertakan rincian arsitektur atau desain sistem. 

 1). Spesifikasi Bahasa 

• Bahasa alami telah digunakan untuk menulis kebutuhan PL sejak awal RPL yang bersifat ekspresif, intuitif, dan universal. 

• Panduan sederhana: 

1. Buat format standar dan pastikan bahwa semua definisi kebutuhan mematuhi format tsb. 

2. Gunakan bahasa secara konsisten 

3. Gunakan penjelasan teks (tebal, miring, atau warna) untuk memilih bagian-bagian penting dari kebutuhan. 

4. Jangan berasumsi bahwa pembaca memahami bahasa RPL, hindari penggunaan jargon, singkatan, dan akronim. 

5. Sebisa mungkin, harus mencoba mengaitkan alasan dengan setiap kebutuhan pengguna.

 2). Spesifikasi Struktur 

• Bahasa alami terstruktur adalah cara penulisan kebutuhan sistem dimana kebebasan dalam penulisan terbatas dan semua kebutuhan ditulis dengan cara standar. 

• Untuk menentukan kebutuhan fungsional, informasi berikut harus disertakan: 

1. Deskripsi fungsi atau entitas yang ditentukan. 

2. Penjelasan tentang input dan dari mana asalnya. 

3. Penjelasan tentang output dan kemana tujuannya. 

4. Informasi yang diperlukan untuk perhitungan atau entitas lain dalam sistem yang digunakan. 

5. Penjelasan tentang tindakan yang harus diambil. 

6. Penjelasan tentang efek samping dari operasi (jika ada)

 F. Validasi (Validation)

 • Validasi kebutuhan adalah proses pengecekan kebutuhan yang benar-benar menentukan sistem yang diinginkan oleh pelanggan. 

• Validasi melakukan pemeriksaan untuk memastikan bahwa: 

✓ Semua kebutuhan PL telah dinyatakan dengan jelas 

✓ Inkonsistensi, kelalaian, dan kesalahan telah terdeteksi dan diperbaiki 

✓ Produk kerja sesuai dengan standar yang ditetapkan untuk proses, proyek, dan produk.

 Hal-hal yang perlu pemeriksaan: 

1. Pemeriksaan Validitas Suatu sistem diperlukan untuk melakukan fungsi-fungsi tertentu dan dapat mengidentifikasi fungsi tambahan. 

2. Pemeriksaan Konsistensi Kebutuhan dalam dokumen tidak boleh bertentangan. Artinya, tidak ada batasan yang bertentangan atau deskripsi yang berbeda dari fungsi sistem yang sama. 

3. Pemeriksaan Kelengkapan Dokumen Kebutuhan yang mendefinisikan semua fungsi dan batasan yang dimaksudkan oleh pengguna sistem.

 4. Pemeriksaan Realisme, dengan menggunakan pengetahuan tentang teknologi yang ada, kebutuhan harus diperiksa untuk memastikan bahwa mereka benar-benar dapat diimplementasikan. 

5. Verifiability Kebutuhan, sistem harus selalu ditulis sehingga dapat diverifikasi, artinya menulis serangkaian tes yang dapat menunjukkan bahwa sistem yang dikirimkan memenuhi setiap kebutuhan yang ditentukan.

 G. Manajemen Kebutuhan (Requirement Management)

 • Adalah serangkaian kegiatan yang membantu tim proyek untuk mengidentifikasi, mengontrol, dan melacak kebutuhan-kebutuhan dan melacak perubahan terhadap kebutuhan saat proyek berlangsung. 

• Ada beberapa alasan mengapa perubahan tidak dapat dihindari: 

1. Lingkungan bisnis dan teknis sistem selalu berubah setelah instalasi. 

2. Pengguna sistem bukan orang yang sama. 

3. Sistem besar biasanya memiliki komunitas pengguna yang beragam

 

 1). Kebutuhan Perencanaan Manajemen 

Tahap perencanaan menetapkan tingkat detail manajemen kebutuhan yang diperlukan, dengan memutuskan: 

1. Identifikasi Kebutuhan, setiap kebutuhan harus diidentifikasi secara unik sehingga dapat direferensikan dengan kebutuhan lain dan digunakan dalam pelacakan. 

2. Proses manajemen perubahan adalah serangkaian kegiatan yang menilai dampak dan biaya perubahan. 

 3. Kebijakan Pelacakan, menentukan hubungan antara setiap kebutuhan, kebutuhan dengan desain sistem, dan pemeliharaan catatan-catatan. 

4. Dukungan alat, kebutuhan manajemen melibatkan pemrosesan sejumlah besar informasi tentang kebutuhan. Alat yang dapat digunakan berkisar dari sistem manajemen kebutuhan khusus untuk spreadsheet dan sistem basis data sederhana.

 2). Kebutuhan Manajemen Perubahan

 • Kebutuhan manajemen perubahan harus diterapkan untuk semua perubahan yang diajukan pada kebutuhan sistem setelah dokumen kebutuhan disetujui. 

• Ada tiga tahapan utama untuk proses manajemen perubahan: 

1. Analisis masalah dan spesifikasi perubahan 

2. Analisis dan biaya perubahan 

3. Perubahan implementasi

 2. KEBUTUHAN FUNGSIONAL DAN NON-FUNGSIONAL 

• Kebutuhan Fungsional adalah layanan yang harus disediakan sistem, bagaimana sistem harus bereaksi terhadap input tertentu, dan bagaimana sistem harus berperilaku dalam situasi tertentu. 

• Kebutuhan non-fungsional adalah batasan pada layanan atau fungsi yang ditawarkan oleh sistem. Termasuk: Kendala waktu, Kendala pada proses pengembangan, Kendala yang dikenakan oleh standar.

A. Kebutuhan Fungsional

• Kebutuhan fungsional menggambarkan apa yang harus dilakukan oleh sistem. 

• Kebutuhan ini tergantung pada jenis PL yang dikembangkan, pengguna, dan pendekatan umum yang diambil oleh organisasi saat menulis kebutuhan. 

• Kebutuhan pengguna dijelaskan secara abstrak yang dapat dipahami oleh pengguna sistem, terutama untuk kebutuhan sistem yang lebih spesifik menggambarkan fungsi-fungsi sistem, input dan output, dan pengecualian secara rinci

 • Contoh: kebutuhan fungsional untuk sistem informasi tentang pasien: 

✓ User harus dapat mencari daftar janji untuk semua poliklinik sesuai dengan jadwal praktek dokter. 

✓ Setiap hari, untuk setiap poliklinik mencatat daftar pasien yang telah melakukan pendaftaran hari itu. 

✓ Setiap petugas yang menggunakan sistem harus diidentifikasi secara unik dengan nomor karyawan delapan digit miliknya.

 B. Kebutuhan Non-Fungsional 

• Kebutuhan non-fungsional adalah kebutuhan yang tidak secara langsung terkait dengan layanan spesifik yang disampaikan oleh sistem kepada penggunanya. 

• Berhubungan dengan sifat sistem yang muncul seperti keandalan, waktu respon, dll. 

• Dapat berupa kendala pada implementasi sistem seperti kemampuan perangkat I/O, representasi data yang digunakan dalam antarmuka dengan sistem lain. 

• Kebutuhan non-fungsional muncul melalui kebutuhan pengguna, karena keterbatasan anggaran, kebijakan organisasi, kebutuhan interoperabilitas dengan software/hardware, atau faktor eksternal seperti peraturan keselamatan atau undang-undang privasi. 

 Implementasi kebutuhan ini dapat disebarluaskan di seluruh sistem, dengan alasan: 

1. Kebutuhan non-fungsional dapat mempengaruhi keseluruhan arsitektur sistem daripada komponen individu. Misalnya, untuk memastikan bahwa terpenuhinya kebutuhan kinerja harus mengatur sistem untuk meminimalkan komunikasi antar komponen. 

2. Kebutuhan non-fungsional tunggal, seperti kebutuhan keamanan, dapat menghasilkan sejumlah kebutuhan fungsional terkait yang menentukan layanan sistem baru yang diperlukan. 

 Karakteristik kebutuhan non-fungsional 

1. Kebutuhan produk Kebutuhan ini menentukan atau membatasi perilaku perangkat lunak. 

• Kebutuhan kinerja tentang seberapa cepat sistem harus dijalankan dan berapa banyak memori yang dibutuhkan 

• Kebutuhan keandalan yang menetapkan tingkat kegagalan yang dapat diterima 

• Kebutuhan keamanan 

• Kebutuhan kegunaan

2. Kebutuhan Organisasi adalah kebutuhan sistem yang luas yang berasal dari kebijakan dan prosedur di organisasi pelanggan dan pengembang. 

• Kebutuhan operasional yang menentukan bagaimana sistem akan digunakan 

• Kebutuhan proses pengembangan yang menentukan bahasa pemrograman, lingkungan pengembangan atau proses standar yang akan digunakan 

• Kebutuhan lingkungan yang menentukan lingkungan operasi sistem.  

3. Kebutuhan Eksternal Mencakup semua kebutuhan yang berasal dari faktor eksternal ke sistem dan proses pengembangannya. 

• Kebutuhan peraturan yang mengatur apa yang harus dilakukan untuk sistem yang akan disetujui untuk digunakan oleh regulator, seperti bank sentral 

• Kebutuhan legislatif yang memastikan bahwa sistem beroperasi sesuai peraturan 

• Kebutuhan etis yang memastikan bahwa sistem akan diterima oleh pengguna dan masyarakat umum

 Contoh Requirement

REKAYASA PERANGKAT LUNAK PERTEMUAN 2: MODEL PROSES PENGEMBANGAN PERANGKAT LUNAK

1) MODEL WATERFALL

Model Waterfall juga disebut siklus hidup klasik (Classic Life Cycle) merupakan pendekatan sistematis dan berurutan (sequential) pada PL yang dimulai dengan spesifikasi kebutuhan user dan berlanjut melalui beberapa tahapan, dan diakhiri dengan penyerahan sistem/ PL kepada pelanggan. Pada prinsipnya, hasil dari setiap tahap adalah satu atau lebih dokumen yang disetujui (Sign off’). Tahap berikutnya tidak boleh dimulai sampai tahap sebelumnya selesai.

 

Tahapan Model Waterfall: 

1) Requirements Analysis and Definition (analisa kebutuhan sistem). 

Berisi layanan-layanan sistem, kendala, dan tujuan yang ditetapkan melalui konsultasi dengan pengguna sistem, kemudian didefinisikan secara rinci yang berfungsi sebagai spesifikasi sistem. Requirements Analysis and Definition (Lanjutan) Misalkan untuk aplikasi web: Maka analisa kebutuhannya ditinjau dari kebutuhan Admin dan User.

2) System and Software Design Proses, 

design mengalokasikan kebutuhan hardware dan software untuk membangun arsitektur sistem secara keseluruhan (struktur data, arsitektur PL, interface, dan detail/algoritma prosedural). Proses design akan menerjemahkan syarat kebutuhan perancangan PL yang dapat diperkirakan sebelum dibuat coding. Contoh: Aplikasi web ini dibangun dengan beberapa desain, diantaranya desain database menggunakan ERD dan LRS, desain struktur program menggunakan Struktur Navigasi, dan desain sistem menggunakan UML. 

3) Implementation and Unit Testing, 

Perancangan PL direalisasikan sebagai satu set program atau unit program (coding). Coding merupakan penerjemahan design dalam bahasa yang bisa dikenali oleh komputer yang dilakukan oleh programmer. Kemudian dilanjutkan dengan testing terhadap pengujian unit dengan melibatkan verifikasi setiap unit agar memenuhi spesifikasinya. Contoh: Pembuatan code program menggunakan software Dreamweaver CS5, pengolahan database dengan MySQL, script untuk penjelajah web menggunakan Javascript, dst… 

4) Integration and System Testing, 

Program-program diintegrasikan dan diuji sebagai sistem yang lengkap untuk memastikan bahwa kebutuhan/persyaratan PL telah dipenuhi. Setelah pengujian, PL sistem dikirim ke pelanggan. Contoh: Setelah tahap pembuatan code program dilakukan pengujian program untuk menemukan kesalahankesalahan program. Pengujian program menggunakan black box testing untuk memastikan bahwa seluruh input yang memerlukan verifikasi data sudah benar.

5) Operation and Maintenance 

(Operasi dan pemeliharaan) adalah siklus hidup terlama. Sistem ini dipasang dan digunakan oleh user. Perawatan melibatkan koreksi kesalahan yang tidak ditemukan sebelumnya, meningkatkan implementasi sistem dan meningkatkan layanan sistem saat persyaratan baru ditemukan. Contoh: Pemeliharaan sistem akan terus dilakukan dengan korektif terhadap kesalahan yang mungkin terjadi, adaptif dengan peningkatan layanan sistem, dst…

Kelebihan model waterfall: 

a. Memiliki proses yang urut dan bertahap, sehingga kualitas sistem/PL yang dihasilkan akan baik. 

b. Setiap proses memiliiki spesifikasinya sendiri, karena setiap tahap harus terselesaikan dengan lengkap sebelum melanjutkan ke tahap berikutnya. 

c. Setiap proses tidak dapat saling tumpang tindih. 

d. Metode ini akan lebih baik digunakan jika kebutuhan-kebutuhan sudah diketahui.

Kekurangan model waterfall: 

a. Proses yang dilakukan cenderung panjang dan lama, karena proses pengembangan tidak dapat dilakukan berulang sebelum menghasilkan produk. 

b. Kesalahan kecil pada satu tahapan akan menimbulkan masalah besar jika tidak diketahui sejak awal pengembangan, berakibat pada tahapan selanjutnya 

c. Biaya penggunaan metode yang cenderung mahal 

d. Membutuhkan banyak riset dan penelitian pendukung untuk mengembangkan sistem sehingga pelanggan harus sabar karena pembuatan PL baru dimulai pada tahap perancangan. 

e. Kenyataannya sulit untuk mengikuti aturan sequential, karena iterasi sulit dilakukan dan menyebabkan masalah baru. 

 

 2) MODEL PROTOTYPE

Prototype adalah pendefinisian sejumlah sasaran PL berdasarkan kebutuhan dan pemahaman secara umum, tetapi tidak bisa mengidentifikasi kebutuhan secara rinci untuk beberapa fungsi dan fitur-fitur. Tujuannya adalah untuk membantu dalam tahap analisis dan desain yang memungkinkan pengguna untuk melihat lebih awal apa yang akan dilakukan sistem, yaitu untuk memfasilitasi validasi. Prototype dapat digunakan sebagai model proses yang berdiri sendiri.

Pembuatan prototipe biasanya digunakan sebagai teknik yang dapat diimplementasikan di dalam konteks setiap model proses PL, sehingga membantu stakeholder untuk lebih memahami apa yang akan dikembangkan ketika spesifikasi kebutuhan belum jelas.

 

 Tahapan dalam Model Prototype:

1. Dimulai dengan dilakukannya komunikasi antara tim pengembang PL dengan pelanggan,

2. Tim pengembang bertemu dengan stakeholder untuk mendefinisikan sasaran keseluruhan PL, mengidentifikasi spesifikasi kebutuhan yang diketahui, dan menggambarkan definisi lebih jauh pada iterasi selanjutnya,

3. Pembuatan prototipe direncanakan dengan cepat, dan pemodelan dilakukan,

4. Prototipe diserahkan kepada stakeholder untuk dievaluasi, dan memberikan umpan balik yang digunakan untuk persyaratan lebih lanjut,

5. Iterasi akan terjadi saat prototipe diperbaiki,

 Tujuan Pengembangan Model Prototype: 

a. Membuat antarmuka pengguna yang dapat diterima,

b. Membuat sistem yang dapat berfungsi, meskipun terbatas, tetapi tersedia dengan cepat untuk menunjukkan kelayakan dan kegunaan dari aplikasi,

c. Dapat digunakan untuk melatih pengguna sebelum sistem yang lengkap dikirim ke pelanggan,

d. Untuk menjelaskan bahwa beberapa teknologi baru akan menyediakan fasilitas yang dibutuhkan,

Manfaat Model Prototype 

Model prototype dikembangkan dan didemonstrasikan pada awal proses pembangunan PL, sehingga dapat bermanfaat untuk: 

a. Menghindari kesalahpahaman antara pengembang PL dan pengguna 

b. Beberapa fasilitas yang hilang mungkin dapat terungkap 

c. Fasilitas yang sulit digunakan/membingungkan dapat diidentifikasi dan disempurnakan 

d. Pengembang PL mungkin menemukan persyaratan yang tidak lengkap atau tidak konsisten.

Masalah pada Model Prototype 

1. Stakeholder hanya melihat tampilan PL yang akan dipakai tanpa mempedulikan bagaimana kerja sistem, dan pemeliharaan jangka panjang. 

2. Perubahan yang dibuat selama pengembangan PL mungkin akan mengubah struktur arsitektur. Oleh karena itu mungkin sulit dan mahal untuk pemeliharaannya. 

3. Karakteristik sistem yang penting seperti kinerja, keamanan dan keandalan, mungkin akan diabaikan selama pengembangan PL. 

4. Selama tahap pengembangan, prototype akan diubah untuk memenuhi kebutuhan pengguna. kemungkinan perubahan yang dibuat akan tidak terkontrol dan tidak didokumentasikan dengan baik.

3) MODEL SPIRAL

 Model Spiral merupakan suatu model proses PL evolusioner yang menggabungkan pendekatan prototyping yang bersifat iteratif dengan aspek yang terkontrol dan sistematis pada model waterfall. Model pengembangan spiral adalah model proses PL yang dikendalikan risiko yang digunakan untuk memandu para stakeholder untuk secara bersamaan merekayasa sistem yang bernuansa PL.

 Model spiral menggunakan prototipe sebagai mekanisme pengurangan risiko dan menggunakan pendekatan langkah demi langkah (waterfall) yang sistematis tetapi menggabungkannya ke dalam kerangka iteratif yang lebih realistis mencerminkan dunia nyata. Model spiral adalah pendekatan realistis untuk pengembangan sistem berskala besar.

 

Penjelasan gambar: 

a. Proses evolusioner ini dimulai dari titik tengah, ke bagian luar spiral searah jarum jam. 

b. Risiko PL akan dipertimbangkan saat masing-masing gerakan dibuat dan titik pengukuran dicatat setiap saat langkah-langkah evolusioner dilewati. 

c. Lintasan pertama di sekitar spiral dapat menghasilkan spesifikasi produk, putaran berikutnya di sekitar spiral mungkin digunakan untuk mengembangkan suatu prototipe dan pada lintasan berikutnya secara progresif bergerak ke versi PL yang semakin canggih. 

d. Setiap melewati lintasan menghasilkan penyesuaian pada perencanaan proyek. 

e. Biaya dan jadwal disesuaikan berdasarkan umpan balik yang berasal dari pelanggan setelah pengiriman produk. 

f. Selain itu, dilakukan penyesuaian jumlah iterasi yang direncanakan untuk menyelesaikan produk PL.

 Keuntungan Model Spriral 

a. Pendekatan yang dikendalikan risiko menghindari banyak kesulitan. 

b. Mengakomodasi persiapan untuk evolusioner siklus hidup, pertumbuhan, dan perubahan pada produk PL. 

c. Menyediakan mekanisme untuk tujuan kualitas dan PL gabungan ke pengembangan produk PL 

d. Mempunyai fokus untuk mengeliminasi kesalahan (error) 

e. Menyediakan pendekatan terpisah untuk pengembangan dan pemasangan PL 

f. Menyediakan keranga kerja aktif untuk pengembangan sistem hardware dan software yang terintegrasi.

 Kerugian Model Spriral 

a. Memerlukan penyesuaian dengan PL yang menitik beratkan pada kontrol dan titik permasalahan yang merupakan keunggulan model waterfall. 

b. Berdasarkan keahlian manajemen risiko yang memerlukan penaksiran risiko yang masuk akal, akan menimbulkan masalah yang lebih besar jika risiko mayor tidak ditemukan 

c. Memerlukan kebutuhan untuk penelitian lebih lanjut terhadap langkah-langkah spiral khususnya untuk area analisis risiko.

 

4) MODEL Rapid Application Development (RAD)  

     RAD adalah teknik berbasis tim yang mempercepat pengembangan SI dan menghasilkan fungsi-fungsi SI. Hal ini juga menggunakan pendekatan kelompok, produk akhir RAD adalah sistem informasi baru. RAD adalah metodologi yang lengkap, dengan 4 fase siklus hidup yang sejajar dengan fase SDLC tradisional. Penggunaan RAD untuk mengurangi biaya dan waktu pengembangan, dan meningkatkan probabilitas keberhasilan.

     RAD sangat bergantung pada prototipe dan keterlibatan pengguna. Berdasarkan input pengguna, prototipe dimodifikasi dan proses interaktif berlanjut sampai sistem benar-benar dikembangkan dan pengguna puas. Interaksi berkelanjutan antara fase desain dan konstruksi pengguna. Tim proyek menggunakan CASE tools untuk membangun prototipe dan membuat aliran dokumentasi yang berkelanjutan.

 Fase dan Aktivitas RAD

 

 1. REQUIREMENTS PLANNING 

• Fase ini menggabungkan elemen-elemen perencanaan sistem dan fase analisis SDLC. 

• Pengguna, manajer, dan anggota staf IT mendiskusikan dan menyetujui kebutuhan bisnis, ruang lingkup proyek, kendala, dan persyaratan sistem. 

• Fase ini berakhir ketika tim menyetujui masalahmasalah utama dan mendapatkan izin manajemen untuk melanjutkan.

 2. USER DESIGN 

• Selama fase ini, pengguna berinteraksi dengan sistem analis kemudian mengembangkan model dan prototipe yang mewakili semua input, proses, output. 

• Tim/subkelompok RAD biasanya menggunakan kombinasi teknik JAD (Joint Application Development) dan CASE tools untuk menerjemahkan kebutuhan pengguna ke dalam model. 

• Desain pengguna adalah kontinyu, proses interaktif memungkinkan pengguna untuk memahami, memodifikasi, dan akhirnya menyetujui model kerja sistem yang memenuhi kebutuhan mereka.

3. CONSTRUCTION 

• Fase konstruksi berfokus pada tugas pengembangan program dan aplikasi yang mirip dengan SDLC. 

• Pengguna terus berpartisipasi dan masih dapat menyarankan perubahan atau peningkatan saat tampilan atau laporan aktual dikembangkan.

4. CUTOVER 

• Merupakan fase peralihan, termasuk konversi data, pengujian, pergantian ke sistem baru, dan pelatihan pengguna. 

• Dibandingkan dengan metode tradisional, seluruh proses dikompresi. Akibatnya, sistem baru dibangun, dikirim, dan ditempatkan dalam operasi yang lebih cepat (agile). 

Tujuan RAD 

a. Mengurangi waktu dan biaya pengembangan dengan melibatkan pengguna dalam setiap fase pengembangan sistem. 

b. Membuat modifikasi yang diperlukan dengan cepat, seiring dengan perkembangan desain. 

c. Membatasi biaya perubahan yang biasanya terjadi dalam jadwal pengembangan yang berlarut-larut. 

d. Membutuhkan sistem informasi untuk mendukung fungsi bisnis baru, karena digerakkan oleh pengguna. 

e. Dengan input pengguna, membantu tim pengembangan merancang sistem yang membutuhkan antarmuka pengguna yang interaktif atau kompleks.

Keuntungan dan Kerugian RAD 

Keuntungan utama: sistem dapat dikembangkan lebih cepat dengan penghematan biaya yang signifikan 

Kerugian: Menekankan mekanisme sistem itu sendiri dan tidak menekankan kebutuhan strategis bisnis perusahaan, Baik untuk jangka pendek, Memungkinkan lebih sedikit waktu untuk mengembangkan kualitas, konsistensi, & standar desain, RAD dapat menjadi alternatif yang menarik, jika suatu organisasi memahami risiko yang mungkin terjadi  

5) MODEL SCRUM

 Scrum adalah sebuah proses yang agile untuk menangani produk yang kompleks. Scrum digunakan untuk memandu kegiatan pengembangan dalam suatu proses yang mencakup kerangka kerja seperti: kebutuhan, analisis, desain, evolusi, dan pengiriman. Metode ini menekankan penggunaan seperangkat pola proses PL yang telah terbukti efektif untuk proyek dengan jadwal yang ketat, perubahan kebutuhan, dan kekritisan bisnis.

 Tahapan kegiatan pengembangan Scrum 

1. Backlog 

• Daftar prioritas kebutuhan proyek/fitur yang menyediakan nilai bisnis bagi pelanggan. 

• Item dapat ditambahkan ke backlog kapan saja (diperkenalkan adanya perubahan). 

2. Sprints 

▪ Unit kerja diperlukan untuk mencapai kebutuhan yang didefinisikan dalam backlog yang harus sesuai dengan time box yang telah didefinisikan sebelumnya (biasanya 30 hari). 

▪ Time box adalah waktu yang telah dialokasikan untuk menyelesaikan beberapa tugas 

▪ Tidak diperkenankan adanya perubahan, sehingga anggota tim bekerja dalam lingkungan jangka pendek tetapi stabil.

3. Scrum Meetings 

Waktunya pendek (biasanya 15 menit) tiap pertemuan yang diadakan setiap hari. Pertemuan ini membantu tim untuk mengungkap potensi masalah sedini mungkin. 

4. Demo 

Memberikan peningkatan PL untuk pelanggan sehingga fungsionalitas yang telah diterapkan dapat didemonstrasikan dan dievaluasi oleh pelanggan. 

Penjelasan gambar 

a. Gagasan awal adalah bahwa seluruh tim harus diberdayakan untuk membuat keputusan sehingga istilah ‘Manajer Proyek', telah dengan sengaja dihindari. 

b. Scrum Master adalah seorang fasilitator yang mengatur 

• pertemuan harian 

• melacak backlog dari pekerjaan yang harus dilakukan 

• mencatat keputusan 

• mengukur kemajuan terhadap backlog 

• berkomunikasi dengan pelanggan dan manajemen di luar tim  

c. Seluruh tim menghadiri pertemuan harian, agar tetap fokus pada tugas masing-masing. 

d. Selama pertemuan, semua anggota tim berbagi informasi, melaporkan kemajuan mereka sejak pertemuan terakhir, menjelaskan masalah yang muncul, dan apa yang direncanakan untuk hari berikutnya. 

e. Ini berarti bahwa semua orang di tim tahu apa yang sedang terjadi, dan jika masalah muncul, dapat saling membanttu. 

f. Semua orang berpartisipasi dalam perencanaan jangka pendek ini.

Keuntungan Metode Scrum

a. Produk dipecah menjadi beberapa sub produk sehingga dapat dikelola dan dimengerti. 

b. Persyaratan yang tidak stabil tidak menghambat kemajuan. 

c. Seluruh tim memiliki visibilitas sehingga dapat meningkatkan komunikasi tim. 

d. Pelanggan melihat pengiriman tepat waktu dan mendapatkan umpan balik tentang bagaimana produk tersebut bekerja. 

e. Kepercayaan antara pelanggan dan pengembang akan terjalin dimana semua orang mengharapkan proyek untuk berhasil.

REKAYASA PERANGKAT LUNAK

 

Pertemuan 1 PERANGKAT LUNAK dan REKAYASA PERANGKAT LUNAK

PERANGKAT LUNAK:

Definisi Perangkat Lunak (PL) adalah Instruksi-instruksi program komputer yang ketika dijalankan menyediakan fitur-fitur, fungsi-fungsi dan kinerja yang dikehendaki, struktur data yang memungkinkan program-program memanipulasi informasi, dan Informasi deskriptif pada salinan tercetak dan bentukbentuk maya yang menggambarkan pengoperasian dan penggunaan program.

Perangkat Lunak dapat dikembangkan atau direkayasa, bukan diproduksi dalam konteks manufaktur, tidak mengalami kelelahan, dan dibuat berdasarkan spesifikasi yang diminta oleh penggun.

A. Kategori Perangkat Lunak ada 7 yaitu  PL Sistem (System Software), PL Aplikasi (Application Software), PL Rekayasa/Ilmiah (Engineering/Scientific Software), PL yang tertanam (Embedded Software), PL Lini Produk (Product-Line Software), PL Aplikasi Web (Web/Mobile Applications), dan PL Kecerdasan Buatan (Artificial Intelligence Software).

B. Jenis Perangkat Lunak Aplikasi:

 a) Stand-Alone Applications adalah contoh aplikasi seperti aplikasi office pada PC, program CAD, software manipulasi foto, dll 

b) Interactive Transaction-Based Aapplications adalah aplikasi yang mengeksekusi pada komputer remote dan yang diakses oleh pengguna dari PC mereka sendiri atau terminal

 c) Batch Processing Systems adalah sistem bisnis yang dirancang untuk memproses data input yang besar untuk membuat output yang sesuai. Contoh: sistem penagihan telepon, dan sistem pembayaran gaji.

 d) Embedded Control Systems adalah sistem kontrol PL yang mengontrol dan mengelola perangkat keras, atau sistem yang tertanam pada jenis sistem lain. Contoh: PL yang mengontrol pengereman anti-lock mobil, dan software dalam oven microwave untuk mengontrol proses memasak. 

e) Entertainment Systems adalah sistem yang terutama untuk penggunaan pribadi dan yang dimaksudkan untuk menghibur pengguna. 

f) Systems for Modelling and Simulation adalah sistem yang dikembangkan untuk model proses fisik atau situasi, dengan banyak objek yang saling berinteraksi 

g) Data Collection Systems adalah sistem yang mengumpulkan data dari lingkungan mereka menggunakan satu set sensor dan mengirim data ke sistem lain untuk diproses. 

h) Systems of Systems adalah sistem yang terdiri dari sejumlah sistem PL lain. 

 C. Perangkat Lunak Warisan

 • PL warisan harus diadaptasikan sedemikian rupa sehingga memenuhi kebutuhan dari lingkungan atau teknologi komputasi yang baru.

• PL warisan harus ditingkatkan kinerjanya supaya dapat menjalankan kebutuhan bisnis baru.

• PL warisan harus diperluas sedemikian rupa agar dapat saling mengoperasikan dengan sistem/PL/basisdata modern lainnya.

• PL harus dirancang ulang sehingga dapat hidup dalam lingkungan pengoperasian jaringan komputer.

 D. Kegagalan Perangkat Lunak 

Faktor-faktor penyebab kegagalan PL:

 • Meningkatnya tuntutan: RPL membangun sistem yang lebih besar, sistem yang lebih kompleks menyebabkan tuntutan berubah. Sistem harus dibangun dan disampaikan lebih cepat, lebih besar, dan lebih kompleks. Sistem harus memiliki kemampuan baru yang sebelumnya dianggap mustahil. 

• Harapan yang rendah: Hal ini relatif mudah untuk menulis program komputer tanpa menggunakan metode dan teknik RPL. Banyak Pengusaha yang tidak menggunakan metode RPL, akibatnya PL lebih mahal dan kurang dapat diandalkan. 

 Stakeholder dalam RPL: 

■ Users: adalah orang-orang yang akan menggunakan PL. 

■ Customer (client): adalah orang-orang yang membeli atau memesan PL. 

■ Software Developer: adalah orang-orang yang mengembangkan dan memelihara PL. 

■ Development Manager: adalah orang-orang yang menjalankan organisasi yang mengembangkan PL, dan biasanya memiliki latar belakang pendidikan dalam administrasi bisnis. 

=======================================================================

RPL adalah disiplin teknik yang berkaitan dengan semua aspek produksi PL dari tahap awal spesifikasi sistem sampai pemeliharaan. Aspek produksi RPL berkaitan dengan proses teknis dari pengembangan PL, manajemen proyek PL dan pengembangan alat-alat, metode, dan teori untuk mendukung produksi PL. RPL merupakan aplikasi dari suatu pendekatan yang semantik, disiplin, dan dapat diukur pada pengembangan, operasi, dan perawatan PL.

 =======================================================================

 PL dalam segala bentuk aplikasinya harus direkayasa, dengan alasan: 

• PL telah menyatu secara maya dengan setiap aspek dalam kehidupan 

• Kebutuhan IT yang sudah banyak dituntut oleh individu, bisnis dan pemerintah bertambah kompleks 

• Individu, bisnis, dan pemerintah mengandalkan PL untuk mengambil keputusan yang bersifat taktis dan strategis 

• Nilai aplikasi terus bertambah, kemungkinan jumlah pengguna dan usia PL akan bertambah

 ========================================================================

 PROSES PERANGKAT LUNAK

 • Suatu proses merupakan sekumpulan aktivitas, aksi, dan tugas yang dijalankan ketika suatu produk kerja harus dibuat. 

• Sebuah proses PL adalah urutan kegiatan yang mengarah ke produksi produk software. 

• Empat kegiatan proses PL adalah: Spesifikasi PL, Pengembangan PL, Software validasi, Software evolusi.

 • Suatu aktivitas berupaya mencapai tujuan umum dan diterapkan tanpa memperhatikan lingkungan aplikasi, tanpa memperhatikan ukuran proyek, tanpa memperhatikan kompleksitas dan usaha, dan tanpa memperhatikan kekakuan dari RPL saat diterapkan. 

• Suatu tugas konsentrasi pada tujuan yang kecil tetapi terdefinisi dengan baik. 

 • Kerangka kerja proses membangun dasar bagi proses RPL yang lengkap dengan cara mengidentifikasikan aktivitas kerangka kerja yang cocok untuk semua proses RPL. 

• Kerangka kerja proses mencakup sekumpulan akitivitas yang berperan sebagai penyangga dan cocok dengan keseluruhan proses PL. 

• Aktivitas kerangka kerja proses: Komunikasi, Perencanaan, Pemodelan, Konstruksi, Penyerahan PL ke pelanggan/user.

 • Aktivitas kerangka kerja proses RPL disempurnakan oleh aktivitas yang bertindak sebagai penyangga.

 • Kegiatan-kegiatan penyangga mencakup: Penelusuran dan kendali proyek PL, Manajemen risiko, Penjaminan kualilitas PL, Tinjauan teknis, Pengukuran, Manajemen konfigurasi PL, Manajemen penggunaan ulang, Persiapan produk kerja dan produksi

PRAKTEK RPL

 Langkah-langkah RPL: 

a. Memahami permasalahan 

• Siapa yang terkait dalam pemecahan masalah? 

• Apa saja yang tidak diketahui? 

• Data, fungsi, dan fitur yang dibutuhkan 

• Dapatkah masalah dikategorikan (dipecah menjadi masalah yang lebih kecil)? 

• Dapatkah masalah diwakili dengan grafis?• Dapatkah dibuat sebuah model analisis?

 b. Merancang solusi 

• Pernahkah ada masalah serupa sebelumnya dan telah didapatkan pemecahan masalahnya? 

• Dapatkah sub-masalah didefinisikan? 

• Dapatkah menyusun solusinya?

c. Menjalankan rancangan 

• Apakah solusi cocok dengan masalah? 

• Apakah kode program dapat dilacak secara langsung? 

• Apakah komponen dari solusi sudah tepat? 

d. Memeriksa hasil 

• Uji setiap komponen dari solusi dengan menggunakan strategi pengujian 

• Apakah solusi sesuai dengan data, fungsi dan fitur yang dibutuhkan? 

Prinsip-Prinsip Umum RPL:
Alasan keberadaan PL, Sederhana, Pertahankan visi, Apa yang dibuat, akan digunakan oleh konsumen/pengguna, Membuka diri terhadap masa depan, Merancang selangkah ke depan sehingga dapat digunakan kembali sampai Review.

Mitos Manajemen dalam PL: 

1) Kita sudah memiliki buku yang standar dan prosedur untuk membangun PL → Apakah buku tersebut mencerminkan praktek RPL modern, lengkap, dan dapat beradaptasi dengan keadaan yang dihadapi saat ini?.

2) Jika kita tertinggal dari jadwal yang telah ditetapkan, kita dapat menambah jumlah programmer dan akan memenuhi jadwal dengan cepat. → Menambah orang baru untuk proyek PL yang tertunda menyebabkan penyelesaian proyek PL tersebut mejadi semakin terlambat.

3) Jika memutuskan untuk menyewa orang ketiga untuk mengerjakan proyek PL, kita bisa sedikit lega karena PL dikerjakan oleh pihak ketiga. → Jika sebuah organisasi tidak dapat memahami cara mengelola dan mengendalikan proyek PL secara internal, maka organisasi tersebut akan bekerja lebih keras lagi ketika menyewa pihak ketiga.

 Mitos Pelanggan dalam PL:

1) Pernyataan tujuan umum sudah cukup untuk mulai menulis program, dan kita dapat membuat rinciannya nanti. → Pembuatan pernyataan kebutuhan yang komprehensif dan stabil tidak selalu dimungkinkan (tidak ambigu), tetapi perlu mengembangkan komunikasi yang efektif antara pengembang dan pelanggan.

2)  Kebutuhan PL terus menerus berubah, tetapi perubahan-perubahan dapat dengan mudah diakomodasi karena PL bersifat fleksibel. → Dampak perubahan beragam sesuai dengan waktu di mana perubahan diperkenalkan.

 Mitos Praktisi dalam PL:

1) Ketika kita menulis kode program dan menjalakannya, maka pekerjaan dianggap sudah selesai. → Semakin cepat kita mulai menulis ‘kode program’, semakin lama waktu yang dibutuhkan untuk menyelesaikannya.

2) Satu-satunya produk kerja untuk mencetak proyek PL yang berhasil adalah program yang sedang berjalan. → Sebuah produk kerja hanyalah sebagian kecil dari konfigurasi PL yang pada dasarnya mencakup banyak unsur RPL yang berhasil dan memberikan panduan bagi dukungan PL.

3)  RPL akan memaksa kita membuat dokumentasi yang berlebihan dan terkesan tidak penting, dan akan selalu menghambat kemajuan. → RPL merupakan kegiatan yang bertujuan untuk meningkatkan kualitas produk. Kualitas yang baik mengarah pada berkurangnya pekerjaan yang berulang-ulang sehingga pengiriman ke pelanggan akan lebih cepat.