Materi 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: 

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

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

- Kebutuhan penemuan 

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.

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

- Kebutuhan Prioritas dan Negosiasi

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

3. Elaborasi (Elaboration) 

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

4. Negosiasi 

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

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

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

7. Manajemen Kebutuhan (Requirement Management) 

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

Materi Perangkat Lunak Pertemuan 2

 

Model Proses Pengembangan Perangkat Lunak

 Model Proses Pengembangan Perangkat Lunak

    Dalam era digital saat ini perangkat lunak (software) sudah banyak sekali mengalami perkembangan sehingga menghasilkan berbagai macam model atau jenis dari perangkat lunak tersebut, diantaranya yaitu:

1. Model Waterfall

    Model waterfall atau disebut juga "classic life cycle" merupakan pengembangan perangkat lunak yang menekankan fase-fase yang berurutan dan sistematis. Pengembangan perangkat lunak, model ini cenderung menjadi salah satu pendekatan yang kurang iteratif dan fleksibel.

    Dalam model ini terdapat beberapa tahapan dalam prosesnya :

a. Requirements Analysis and Definition, merupakan tahap analisa kebutuhan sistem.

b. System and Software Design, merupakan tahap mengalokasikan kebutuhan hardware dan software.

c. Implementation and Unit Testing, merupakan tahap perangkat lunak direalisasikan sebagai satu set program atau unit program (coding) dan kemudian dilakukan pengujian (testing).

d. Integration and System Testing, merupakan tahap dimana program  diintegrasikan dan diuji sebagai sistem yang lengkap sesuai kebutuhan dan persyaratan dalam perangkat lunak.

e. Operation and Maintenance, merupakan tahap perawatan yang melibatkan koreksi kesalahan yang tidak ditemukan pada tahap sebelumnya.

2. Model Prototype

    Model prototype merupakan pengembangan perangkat lunak yang kompleks dan juga iteratif. Model ini dikerjakan secara bersama-sama (pengembang) dan  hanya mendefinisikan perangkat lunak secara objektif  tanpa merinci kebutuhan input, pemrosesan dan outputnya. Adapun tahapan dalam model ini :

a. Tahap analisa kebutuhan, dengan dilakukannya komunikasi antara tim pengembang PL dengan pelanggan.

b. Tahap Quick design, membangun rancangan umum sesuai dengan yang diketahui dari tahap analisa.

c. Tahap pembuatan prototipe.

d. Tahap evaluasi, prototipe diserahkan kepada stakeholder untuk dievaluasi.

e. Tahap iterasi, tahap ini akan terjadi saat prototipe diperbaiki.

3. Model Spiral

    Model spiral merupakan model perangkat lunak yang menggabungkan sifat iteratif pada model prototype dengan aspek berurutasn dan sistematis pada model waterfall. Model ini sangat berguna untuk melakukan pembangunan proyek-proyek besar dan prosesnya dilakukan dengan memperhatikan resiko proyek sehingga pada akhirnya akan menghasilkan model proses yang tepat sesuai kebutuhan pengguna. Adapun tahapan dalam model ini :

a. Tahap Liason, tahap komunikasi antara pihak pengembang dengan pelanggan (user)

b. Tahap planning, tahap perencanaan yang meliputi sumber-sumber informasi, batas waktu dan informasi-informasi yang dapat menjelaskan proyek.

c. Tahap analisis resiko, tahap untuk mengidentifikasi resiko dan menghasilkan solusi alternatif untuk mengurangi resiko tersebut.

d. Tahap rekayasa (engineering), tahap pembuatan prototype

e. Tahap konstruksi dan pelepasan (release), tahap pembangunan perangkat lunak untuk diuji.

f. Tahap evaluasi, tahap dimana pelanggan/pemakai (user) memberi tanggapan terhadap perangkat lunak.

4. Model Rapid Application Development (RAD)

    Model RAD merupakan model  perangkat lunak yang tergolong dalam teknik incremental (bertingkat) dan menekankan pada siklus pembangunan pendek, singkat, dan cepat. RAD juga menggunakan metode iteratif (berulang) dan mengadopsi model waterfall sehingga pembangunan dalam waktu yang singkat dapat dicapai. Adapaun tahapan dalam model ini :

a. Requirements Planning, tahap mengidentifikasikan tujuan-tujuan aplikasi atau sistem dan syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut.

b. User design, tahap pengguna berinteraksi dengan sistem analis kemudian mengembangkan model dan prototipe 

c. Construction, tahap pengembangan program dan aplikasi yang mirip dengan SDLC dan pengguna terus berpartisipasi dan masih dapat menyarankan perubahan atau peningkatan.

d. Cutover, tahap  peralihan termasuk konversi data, pengujian, pergantian ke sistem baru, dan pelatihan pengguna.

5. Model Scrum

    Model scrum merupakan model perangkat lunak yang menggunakan prinsip-prinsip pendekatan AGILE (prinsip-prinsip yang sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun), yang bertumpu pada kekuatan kolaborasi tim, incremental product dan proses iterasi untuk mewujudkan hasil akhir. Adapun tahapan dalam model ini :

a. Backlog, tahap dimana daftar prioritas kebutuhan proyek/fitur dan item yang menyediakan nilai bisnis bagi pelanggan dapat ditambahkan.

b. Sprints, tahap dimana unit kerja diperlukan untuk mencapai kebutuhan yang didefinisikan dalam backlog yang harus sesuai dengan time box (waktu yang telah dialokasikan untuk menyelesaikan beberapa tugas) yang telah didefinisikan (biasanya 30 hari)

c. Scrum Meetings, tahap diadakannya pertemuan untuk membantu tim mengungkap potensi masalah sedini mungkin.

d. Demo, tahap memberikan peningkatan perangkat lunak untuk pelanggan sehingga fungsionalitas yang telah diterapkan dapat didemonstrasikan dan dievaluasi oleh pelanggan.

Materi Perangkat Lunak pertemuan 1

Perangkat Lunak & Rekayasa Perangkat Lunak

1. PERANGKAT LUNAK

Definisi Perangkat Lunak:

instruksi program komputer yang ketika dijalankan menyediakan fitur, fungsi dan kinerja yang dikehendaki, memungkinkan program memanipulasi informasi / data.

2. KARAKTERISTIK

A. Karakteristik Perangkat Lunak :

Perangkat lunak dikembangkan atau direkayasa, bukan diproduksi dalam konteks manufaktur dan dibuat berdasarkan spesifikasi yang diminta oleh pengguna / tujuan perangkat lunak dibuat.

B. Kategori Perangkat Lunak :

•             System Software

•       Application Software

•            Engineering/Scientific Software

•            Embedded Software

•            Product-Line Software

•            Web/Mobile Applications

•             Artificial Intelligence Software

C. Jenis Perangkat Lunak Aplikasi :

>Stand-Alone Applications 

Contoh aplikasi seperti aplikasi Microsoft Office pada PC, program CAD, software

manipulasi foto(Photosop, dsb), dll.

>Interactive Transaction-Based Aapplications 

Aplikasi yang mengeksekusi pada komputer remote dan yang diakses oleh pengguna dari

PC mereka sendiri atau terminal.

>Batch Processing Systems 

Sistem bisnis yang dirancang untuk memproses data input yang besar untuk membuat

output yang sesuai. Contoh: sistem penagihan telepon, dan sistem pembayaran gaji.

>Embedded Control Systems 

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.

>Entertainment Systems 

Sistem yang terutama untuk penggunaan pribadi dan yang dimaksudkan untuk menghibur pengguna.

>Systems for Modelling and Simulation 

Sistem yang dikembangkan untuk model proses fisik atau situasi, dengan banyak objek yang saling

berinteraksi.

>Data Collection Systems 

Sistem yang mengumpulkan data dari lingkungan mereka menggunakan satu set sensor dan

mengirim data ke sistem lain untuk diproses.

>Systems of Systems 

Sistem yang terdiri dari sejumlah sistem PL lain. 

D. Perangkat Lunak Warisan

•         Perangkat lunak warisan harus diadaptasikan sedemikian rupa sehingga memenuhi kebutuhan dari

lingkungan atau teknologi komputasi yang baru.

•         harus ditingkatkan kinerjanya supaya dapat menjalankan kebutuhan bisnis baru.

•         harus diperluas sedemikian rupa agar dapat saling mengoperasikan dengan sistem/PL/basisdata

modern lainnya.

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

E. Kegagalan Perangkat Lunak

Faktor - faktor kegagalan perangkat lunak :

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

F. 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 perangkat lunak, dan biasanya memiliki latar belakang pendidikan dalam

administrasi bisnis. 

3. REKAYASA PERANGKAT LUNAK

Definisi Rekayasa Perangkat Lunak :

Teknik yang berkaitan dengan semua aspek produksi Perangkat Lunak dari tahap awal spesifikasi sistem sampai pemeliharaan. Aspek produksi berkaitan dengan proses teknis dari pengembangan PL, manajemen proyek PL dan pengembangan alat-alat, metode, dan teori untuk mendukung produksi Perangkat Lunak.

Alasan Perangkat Lunak di Rekayasa :

1. Perangkat lunka telah menyatu secara maya dengan setiap aspek dalam kehidupan.

2. Kebutuhan IT yang sudah banyak dituntut oleh individu, bisnis dan pemerintah

bertambah kompleks.

3. Individu, bisnis, dan pemerintah mengandalkan PL untuk mengambil keputusan yang

bersifat taktis dan strategis.

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

bertambah.

Proses Perangkat Lunak

•        Sebuah proses Perangkat Lunak adalah urutan kegiatan yang mengarah ke produksi produk

software.

•        Empat kegiatan proses PL adalah:

a.       Spesifikasi PL

b.       Pengembangan PL

c.        Software validasi

d.       Software evolusi

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

a.       Komunikasi

b.       Perencanaan

c.        Pemodelan

d.       Konstruksi

e.       Penyerahan PL ke pelanggan/user

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

•         Kegiatan-kegiatan penyangga mencakup:

a.      Penelusuran dan kendali proyek PL

b.      Manajemen risiko

c.      Penjaminan kualilitas PL

d.      Tinjauan teknis

e.      Pengukuran

f.         Manajemen konfigurasi PL

g.      Manajemen penggunaan ulang

h.      Persiapan produk kerja dan produksi

4. PRAKTEK REKAYASA PERANGKAT LUNAK

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

a.       Alasan keberadaan PL

b.       Sederhana

c.        Pertahankan visi

d.       Apa yang dibuat, akan digunakan oleh konsumen/pengguna

e.       Membuka diri terhadap masa depan

f.          Merancang selangkah ke depan sehingga dapat digunakan kembali

g.       Review

5. MITOS-MITOS PERANGKAT LUNAK

A. Mitos Managemen

      Mitos 1        : Kita sudah memiliki buku yang standar dan prosedur untuk

                         membangun PL.

     Realita         : Apakah buku tersebut  mencerminkan praktek RPL modern, lengkap, dan

                         dapat beradaptasi dengan keadaan yang dihadapi saat ini?

     Mitos 2        : Jika kita tertinggal dari jadwal yang telah ditetapkan, kita dapat                                           menambah jumlah programmer dan akan memenuhi jadwal dengan cepat.

    Realita        : Menambah orang baru untuk proyek PL yang tertunda                                                          menyebabkan penyelesaian proyek PL tersebut mejadi semakin                                             terlambat.

B. Mitos Pelanggan

    Mitos 1        : Pernyataan tujuan umum sudah cukup untuk mulai menulis program, dan                               kita dapat membuat rinciannya nanti.

    Realita         : Pembuatan pernyataan kebutuhan yang komprehensif dan stabil tidak                                    selalu dimungkinkan (tidak ambigu), tetapi perlu mengembangkan                                        komunikasi yang efektif antara pengembang dan pelanggan.

    Mitos 2        : Kebutuhan PL terus menerus berubah, tetapi perubahan-perubahan dapat                               dengan mudah diakomodasi karena PL bersifat fleksibel.

    Realita         : Dampak perubahan beragam sesuai dengan waktu di mana perubahan                                    diperkenalkan.       

C. Mitos Praktisi

    Mitos 1        : Ketika kita menulis kode program dan menjalakannya, maka pekerjaan

                          dianggap sudah selesai.

    Realita         : Semakin cepat kita mulai menulis ‘kode program’, semakin lama waktu

                           yang dibutuhkan untuk menyelesaikannya.

    Mitos 2        : Satu-satunya produk kerja untuk mencetak proyek PL yang berhasil adalah                           program yang sedang berjalan.

    Realita         : Sebuah produk kerja hanyalah sebagian kecil dari konfigurasi PL yang

                           pada dasarnya mencakup banyak unsur RPL yang berhasil dan

                           memberikan panduan bagi dukungan PL.

REFERENSI

Bell, Douglas. 2005. Software Engineering for Students, 4^th.

London: Addison-Wesley.

Booch, Grady. James Rumbaugh. and Ivar Jacobson. 1999.

Unified Modeling Language User Guide. Canada: Addison

Wesley.

Fowler, Martin. 2004. UML Distilled: A Brief Guide to the

Standard Object Modeling Language, 3^rd. USA:

Addison-Wesley.

Lethbridge, Timothy C., Robert L. 2005. Object-Oriented Software Engineering, 2^nd.  London: McGraw-Hill

Pressman, Roger S. and Bruce R. Maxim. 2015.

Software Engineering: A Practitioner’s Approach, 8^th. New

York:McGraw-Hill.

Shelly, Gary B. and Rosenblatt, Harry J. 2012. Systems

Analysis and Design. 9^th. USA: Boston.