MetodeRekayasa Perangkat Lunak

System Development Life Cycle (SDLC)

The waterfall model

PrototypePrototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau komponen-komponen perangkat lunak akan bekerja dalam lingkungannya sebelum tahapan konstruksi aktual dilakukan (Howard, 1997).

Prototyping model

Antonius Wahyu Sudrajat, S. Kom., M.T.I.wayoe@stmik-mdp.net, wahyue79@gmail.com Rekayasa Perangkat Lunak

Masalah Perangkat LunakProses Perangkat Lunak

Perangkat lunak (software) komputer adalah suatu perangkat yang berisi serangkaian instruksi, program, prosedur, pengendali, pendukung, dan aktifitas-aktifitas pengolahan perintah pada sistem komputer. Jadi software merupakan komponen abstrak dari susunan sistem komputer. Tanpa software, komputer adalah rongsokan elektronik, jadi komputer adalah susunan atas hardware dan software yang saling bekerjasama. Hardware komputer akan hidup dan memiliki fungsi jika digunakan bersama-sama dengan software-nya. Secara umum fungsi dari software komputer yang utama adalah :Melakukan aktifitas bersama-sama dengan hardwareMenyediakan segala sumber daya yang bisa digunakan pada sebuah komputerBertindak sebagai perantara antara pengguna (user) dengan perangkat keras (hardware) untuk melakukan aktifitas dengan perintah yang harus dilakukan dalam software komputer.

Perangkat lunak (software)

Struktur Software Komputer Mengelola dan mendukung operasi sistem komputer dan jaringanSoftware SuitesWeb BrowserElectronic MailPengolah KataLembar KerjaDatabase ManagersPresentasi GrafisPersonal Information ManagerGroupWare

- Bisnis Akuntansi, pengolah transaksi, Perencanaan sumber daya perusahaan, perdagangan elektronik, dll- Ilmu pengetahuan dan teknikPendidikan, Entertainment, dll

Sistem OperasiProgram pengelola jaringanDBMS (database management system)Sistem UtilitasMonitoring Unjuk kerja SistemMonitoring Keamanan

Bahasa Program Translator (compiler)Pemrograman Editor dan ToolsPaket CASE (Computer Aided Software Engineering)

PERKEMBANGAN REKAYASA PERANGKAT LUNAK (RPL)1970anPerangkat pengembang perangkat lunak Perangkat minicomputer komersial1980anPerangkat Komputer Personal (PC) komersial Peningkatan permintaan perangkat lunak1990anPemrograman berorientasi obyek (OOP) Agile Process dan Extreme Programming Peningkatan drastis kapasitas memori Peningkatan penggunaan internet2000anPlatform interpreter modern (Java, .Net, PHP, dll)Outsourcing

Permasalahan Perangkat Lunak

Problem dalam Pembuatan SoftwareTidak memiliki waktu yang cukup dalam mengumpulkan data pada proses pembuatan perangkat lunak.Ketidakpuasan user pada S/W yang dibuatKualitas S/W terkadang meragukan.Sulit dalam memaintenance S/W sekarang

Problem SolvingCOMPUTER SCIENCECUSTOMERSOFTWAREENGINEERING

TeoriFungsi ComputerProblem

Tools dan Teknik utkMenyelesaikan Problem

Ongoing Problems (Masalah yang terus menerus ada)Kemajuan perangkat keras melebihi kemampuan membuat software Kemampuan membangun program baru tidak dapat memenuhi permintaan program-program baru, begitu juga kecepatan membangun program tidak dapat mnegikuti kebutuhan bisnis dan pasarPenyebaran penggunaan computer telah membuat kebergantungan masyarakat thdp komputerTantangan untuk membangun software dengan reliability & quality yang tinggiKemampuan men-support dan meningkatkan program terancam oleh design yang buruk dan keterbatasan sumberdaya

*

Persyaratan Perangkat LunakPerangkat lunak harus memberikan bantuan dalam merepresentasikan dan mengakses file-file eksternal yang dibuat dengan alat bantu lain.Persyaratan Fungsional dan Non-FungsionalPersyaratan UserPersyaratan SistemDokumentasi Persyaratan Perangkat Lunak

Persyaratan Fungsional dan Non-FungsionalPersyaratan Fungsional: Pernyataan layanan tentang bagaimana sistem harus bereaksi terhadap input, sistem harus berlaku pada situasi-situasi tertentu. Secara khusus menyatakan apa yang tidak boleh dilakukan sistem.Persyaratan Non Fungsional: Pernyataan tentang batasan layanan dan fungsi yang diberikan sistem.Persyaratan Domain: Persyaratan yang datang dari domain aplikasi sistem dan merefleksikan karakteristik domain tersebut

Persyaratan Non FungsionalPersyaratan Produk: persyaratan yang diambil dari spesifikasi produk, seperti persyaratan hardware untuk mendukung kinerja.Persyaratan Organisasi: persyaratan yang berasal dari kebijakan dan prosedur pada organisasi.Persyaratan Eksternal: Persyaratan yang berasal dari faktor eksternal terhadap sistem dan proses pengembangannya.

Ukuran Persyaratan Non FungsionalKecepatan dalam: Transaksi yang diproses/detik, waktu tanggal user/event atau waktu refresh layarUkuran dalam: KB atau jumlah Chip RAMKemudahan penggunaan dalam: waktu pelatihan atau jumlah frame helpKehandalan dalam: waktu rata-rata kegagalan, probabilitas ketidaksediaan, kecepatan terjadinya kegagalan, atau ketersediaanKetahanan dalam: waktu start ulang setelah kegagalan, prosentase event yang gagal, atau probabilitas korupsi dataPortabilitas dalam: prosentase pernyataan tergantung target, atau jumlah sistem target

*

Persyaratan UserMendeskripsikan persyaratan fungsional dan non-fungsional sehingga dapat dipahami oleh user yang tidak memiliki pengetahuan teknik.Persyaratan user harus ditulis memakai bahasa natural, formal dan diagram intuitif yang sederhana. Persyaratan user tidak boleh didefinisikan memakai model implementasi.Masalah yang sering muncul:Tidak Adanya KejelasanKesimpang-siuran PersyaratanPenggabungan Persyaratan

Persyaratan SistemPersyaratan sistem ini lebih rinci dari persyaratan user, dan berfungsi sebagai dasar kontrak untuk implementasi sistem.Persyaratan sistem ini digunakan sebagai titik awal perancangan sistem.Bahasa natural banyak digunakan dalam mendefinisikan persyaratan sistem

Pentingnya Evolusi Perangkat LunakPerusahaan akan memberikan investasi yang besar pada sistem perangkat lunak mereka karena merupakan aset bisnis yang vital.Untuk mempertahankan nilai aset tersebut untuk bisnis, sistem perangkat lunak harus diubah dan diperbaharui.Mayoritas anggaran perangkat lunak dalam perusahaan besar dikhususkan untuk memperbarui perangkat lunak yang telah ada daripada mengembangkan perangkat lunak baru.

Alasan Perangkat Lunak BerevolusiKebutuhan cenderung berevolusi ketika sistem sedang dikembangkan karena lingkungannya berubah. Oleh karena itu, sistem yang dikirim tidak akan memenuhi harapan pengguna.Sistem terkait erat dengan lingkungannya. Bila sistem dipasang di suatu lingkungan, sistem itu mengubah lingkungan nya sehingga perubahan juga terjadi pada kebutuhan sistem.

Pendorong Perangkat Lunak BerevolusiFaktor EksternalLingkungan Sistem, meliputi:Inovasi KompetitorAncaman KeamananMeningkatnya BandwithMobilitasLegislasi (pengaruh dari pemerintah)Perubahan Ekspektasi Pengguna, meliputi:FungsionalitasUsabilityKeandalanWaktu Respon

Faktor InternalKebutuhan Sistem yang Berubah-UbahPeraturan dan Prosedur PerusahaanProses BisnisPergantian Sasaran PenggunaKondisi OperasionalPerbaikan bugPerangkat Keras BaruPengingkatan Fitur UmumWaktu HidupDegradasi PerformaTeknologi KunoKompleksitas Berkembang di Luar Perkiraan

MITOS PERANGKAT LUNAKMitos dalam perangkat lunak berbeda dengan mitos-2 kuno. Mitos dalam PL memiliki sejumlah atribut yang membuat mereka tersembu-nyi dan berbahaya. Ada beberapa mitos dalam PL yang masih tetap dipercaya.

.Mitos ManajemenMitos : Kita sudah memiliki buku-2 yang memenuhi SOP untuk buat PL. Apa ini

tidak membantu staf saya ? Kenyataan : Apakah buku-2 tsb mencerminkan perangkat lunak modern?

2. Mitos : Staf saya memiliki alat pengembang PL terkini. OSI saya membeli komputer terbaru untuk mereka Kenyataan : Hardware tidak membantu, krn yang penting adalah CASE untuk mencapai kualitas dan produktivitas

MITOS PERANGKAT LUNAK2. Mitos Pelanggan Mitos : Kebutuhan proyek berubah-rubah terus dan pasti nantinya dapat mengakomodir perubahan, karena PL bersifat fleksibel kan ? Kenyataan : Perubahan-2 tsb akan berdampak ke bagian lain (lihat gambar 1.5)

3. Mitos para Praktisi Mitos : Satu-2 nya yang dapat disampaikan untuk sebuah proyek yang sukses adalah bahwa program itu bekerja Kenyataan : Program yang bekerja hanya salah satu bagian dalam PL, tapi masih ada hal seperti dokumen, data, dokumentasi

Sasaran Proyek dan 3 Kendala (Triple Constraint)Setiap Proyek memiliki tujuan khusus, didalam proses pencapaian tujuan tersebut ada 3 constraint yang harus dipenuhi, yang dikenal dengan Trade-off Triangle atau Triple Constraint :ANGGARANJADWALMUTU

Sasaran Proyek dan 3 Kendala (Triple Constraint)MUTUBIAYAWAKTUSesuai TargetSesuai AnggaranTidak harus dicairkan sekaligusOn Time Delivery per Modul / Process / Phase

Anggaran (Cost)Proyek harus diselesaikan dengan biaya yang tidak melebihi anggaran. Untuk proyek-proyek yang melibatkan dana dalam jumlah yang besar dan jadwal bertahun-tahun, anggaran bukan hanya ditentukan untuk total proyek atau per periode tertentu (misalnya per kwartal) yang jumlahnya disesuaikan dengan keperluan. Dengan demikian penyelesaian bagianbagian proyek pun harus memenuhi sasaran anggaran per periode.

Mutu (Quality)Produk atau hasil kegiatan proyek harus memenuhi spesifikasi dan kriteria yang dipersyaratkan. Sebagai contoh, bila hasil kegiatan proyek tersebut berupa instalasi pabrik, maka kriteria yang harus dipenuhi adalah pabrik harus mampu beroperasi secara memuaskan dalam kurun waktu yang telah ditentukan. Jadi, memenuhi persyaratan mutu berarti mampu memenuhi tugas yang dimaksudkan atau sering disebut sebagai fit for the intended use.

Waktu (Time)Proyek harus dikerjakan sesuai dengan kurun waktu dan tanggal akhir yang telah ditentukan. Bila hasil akhir adalah produk baru, maka penyerahannya tidak boleh melewati batas waktu yang telah ditentukan. Walaupun secara teoritis pelaksanaan proyek harus tepat waktu, namun sering terjadi pada waktu pelaksanaannya tidak berjalan sebagaimana yang diharapkan.(Soeharto,I. 1995)

Biaya Rekayasa Perangkat LunakUmumnya sekitar 60% untuk biaya pengembangan (development) dan 40% biaya pengujian (testing). Distribusi biaya yang tepat selama proses perangkat lunak bergantung pada proses yang digunakan dan jenis perangkat lunak yang dikembangkan.

Metode-metode RPLPendekatan-pendekatan terstruktur terhadap pengembangan perangkat lunak mencakup model, notasi, aturan, saran pengembangan sistem (rekomendasi), dan panduan proses.

Deskripsi model sistem Deskripsi model yang harus dikembangkan dan notasi yang digunakan untuk mendefinisikan model-model ini. Ex : model aliran data.Aturan Batasan yang berlaku bagi model sistem. Ex : Setiap entitas pada model sistem harus memiliki nama yang unik.Rekomendasi Saran dalam membentuk perancangan yang baik. Ex : Tidak ada objek yang memiliki lebih dari tujuh sub-objek yang berhubungan dengannya.Panduan Proses Aktifitas yang bisa diikuti untuk mengembangkan model sistem. Ex : Atribut objek harus didokumentasi sebelum mendefinisikan operasi yang berhubungan dengan objek.

CASE (Computer-Aided Software Engineering)Mencakup berbagai macam program yang digunakan untuk mendukung kegiatan PL seperti analisis persyaratan, pemodelan sistem, debugging, dan pengujian.

Tantangan Kunci yang dihadapi RPL ?Tantangan Warisan (Legacy) Tantangan memelihara dan meng-update PL sedemikian sehingga biaya yg berlebihan dapat dihindari dan layanan bisnis yg penting tetap dilakukan.Tantangan Heterogenitas Tantangan teknik pengembangan untuk membangun perangkat lunak yang dapat diandalkan dan cukup flexibel untuk menghadapi heterogenitas yang ada.Tantangan Pengiriman Tantangan mempersingkat waktu kirim sistem besar dan kompleks, tanpa mengurangi kualitas sistem.

DOKUMEN PERANGKAT LUNAKSoftware Project Management Plan (SPMP)Software Requirement Specification (SRS)Software Design Description (SDD)Software Test Plan (STP)Software Test Description (STD)Software Test Result (STR)Software VersionUser Guide / User Manual

*

*

*

*