Materi Kuliah SE 2 Pengertian software Kriteria software Aktivitas proses software SDLC standard Waterfall Iterative Component based RUP RAD Tugas mandiri

Definisi SE Disiplin ilmu yang membahas secara detail bagaimana cara pembuatan suatu software dilihat dari berbagai aspek Spesifikasi → Pemeliharaan Cakupan SE: Proses teknis pengembangan software Manajemen proyek software Penggunaan alat bantu Metode dan teori yg mendukung produksi software

Pengertian Software Software ≠ Program komputer Software tidak hanya sekedar program, tetapi harus mencakup juga File-file konfigurasi data terkait supaya program bisa berjalan sebagai sebuah aplikasi sebagaimana yang diharapkan Dokumentasi yang menjelaskan cara penggunaan sistem Situs web sebagai sumber informasi tentang produk software terbaru

Kriteria software yang baik Maintainability (dapat dipelihara) Software bisa menangani perubahan spek kebutuhan Dependability (dapat diandalkan) Aman, selamat, tidak menyebabkan keruksakan fisik Efficiency (Efisien) Software mampu mengoptimalkan resource Acceptability (Kemampupakaian) Software bisa diterima user sebagaimana rancangan. Mudah dimengerti, digunakan and compatible dengan sistem yang lain

Produk Software Generik (terbuka utk siapapun) ≈ DBMS, Word Processor, Sistem Operasi, Adobe Photoshop, CorelDraw, MsProject, dll Spek hanya dikontrol oleh sendiri oleh Vendor Software Pesanan (disesuaikan dgn kebutuhan pelanggan tertentu saja) Berdasarkan kontrak kerja, tender, dll Spek dikontrol oleh pelanggan tertentu

Software Process Serangkaian kegiatan dan hasil-hasilnya yang diperlukan untuk menghasilkan aplikasi tertentu. Spesifikasi Perancangan & Implementasi Validasi Evolusi

Spesifikasi Untuk menetapkan layanan/fungsi apa yang dituntut dari sistem, dan mendefinisikan batasan operasinya. Istilah lainnya “Rekayasa Persyaratan” Tahapan Rekayasa Persyaratan Studi kelayakan Elisitasi dan analisis persyaratan Spesifikasi persyaratan Validasi persyaratan

Spesifikasi Software Studi kelayakan Memperkirakan apakah user yang diidentifikasi puas menggunakan software dan teknologi hardware saat ini Memutuskan apakah sistem yang diusulkan efektif dalam hal biaya dari sudut pandang bisnis Memutuskan apakah sistem dapat dikembangkan dengan anggaran yang tersedia #Studi ini harus bersifat murah dan cepat

Spesifikasi Software Elisitasi dan analisis persyaratan Penurunan persyaratan sistem melalui observasi sistem yang ada, diskusi dengan user yang akan memakai dan yang mengadakan, analisis pekerjaan,. Melibatkan pengembangan satu atau lebih model dan prototipe sistem. Hasil fase ini akan membantu analis memahami sistem yang akan dispesifikasi.

Spesifikasi Software Spesifikasi persyaratan Menerjemahkan informasi hasil kegiatan analisis menjadi dokumen yang mendefinisikan serangkaian persyaratan Persyaratan user merupakan abstraksi dari persyaratan sistem untuk pelanggan dan end user sistem Deskripsi rinci tentang fungsionalitas yang akan diberikan

Spesifikasi Software Validasi persyaratan Memeriksa apakah persyaratan dapat direalisasiskan, konsisten, dan lengkap. Pada proses ini, kesalahan pada dokumen persyaratan pada akhirnya dapat ditemukan. Kesalahan ini akan dimodifikasi untuk menyelesaikan masalah.

Proses Rekayasa Persyaratan

Perancangan & Implementasi Proses pengubahan spesifikasi sistem menjadi sistem aplikasi yang bisa dijalankan. Mencakup: Perancangan Design a software structure that realises the specification; Pemrograman/coding Translate this structure into an executable program; #The activities of design and implementation are closely related and may be inter-leaved.

Kegiatan Proses Perancangan Perancangan arsitektural Spesifikasi abstrak Perancangan interface Perancangan komponen Perancangan struktur data Perancangan algoritma

Proses Perancangan Software

Metode Perancangan Systematic approaches to developing a software design. The design is usually documented as a set of graphical models. Possible models Object model; Sequence model; State transition model; Structural model; Data-flow model.

Implementasi Pemrograman Mengubah hasil perancangan menjadi program komputer yang bisa dijalankan. Programming is a personal activity - there is no generic programming process. Programmer melakukan pengujian terhadap programnya masing-masing, dan melakukan debug yaitu proses mencari lokasi error program dan menghilangkannya.

Proses Debug Mencari lokasi error Merancang perbaikan error Memperbaiki error Uji ulang program

Validasi Istilah lain Verification & validation (V & V) Menunjukkan bahwa sistem telah sesuai dengan spesifikasinya, dan memenuhi harapa pelanggannya. Involves checking and review processes and system testing. System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.

Proses Ujicoba Component or unit testing System testing Individual components are tested independently; Components may be functions or objects or coherent groupings of these entities. System testing Testing of the system as a whole. Testing of emergent properties is particularly important. Acceptance testing Testing with customer data to check that the system meets the customer’s needs.

Proses Ujicoba Penerimaan Unit Sistem

Fase Ujicoba

Evolusi Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.

System evolution

Pendukung Proses Software Computer-Aided Software Engineering (CASE) tool Pendukung kegiatan otomatisasi proses software dari mulai spesifikasi s/d pengujian, evolusi software. Otomatisasi kegiatan Graphical editors for system model development; Data dictionary to manage design entities; Graphical UI builder for user interface construction; Debuggers to support program fault finding; Automated translators to generate new versions of a program.

CASE technology Case technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted Software engineering requires creative thought - this is not readily automated; Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these.

Evolutionere (iterasi) Model Proses Software Waterfall (linear) Evolutionere (iterasi) Component-based

Model Proses Software Sequence Linear – pengembangan yang bersifat linear dari mulai spesifikasi s/d pemeliharaan. Evolutionere/Iterative – pendekatan pengulangan kegiatan spesifikasi, pengembangan, dan validasi. Sistem sejak awal dikembangkan dengan cepat berdasarkan spesifikasi abstrak, lalu disempurnakan secara bertahap berdasarkan masukan dari pelanggan/pengguna sampai sistem dapat memenuhi kebutuhan pelanggan/pengguna. Component-based – pengembangan dengan cara menggunakan komponen yang dapat dipakai ulang.

Model Waterfall

Analisis Waterfall Kelebihan Sudah terbukti handal dan paling lama digunakan Digunakan untuk rekayasa sistem software berukuran besar (TRON) dimana proyek dikerjakan di beberapa tempat berlainan, dan terbagi menjadi beberapa bagian sub-proyek. Cocok untuk pengembangan software yang bersifat generik Prosesnya sudah benar-benar jelas dan tidak berubah-ubah

Analisis Waterfall Sistematis, Titik transisi yang jelas pada setiap tahapan/proses akan memudahkan tim pengembang software dalam memonitor penjadwalan proyek, menetapkan tanggung jawab, dan akuntabilitas peran personal dalam proyek perangkat lunak.

Analisis Waterfallub The main drawback !!! Sulit/adanya kendala dalam mengakomodasi perubahan speksifikasi ketika proses sedang berlangsung Fase sebelumnya harus lengkap dan selesai sebelum memasuki tahap berikutnya.

Analisis Waterfall Few business systems have stable requirements. Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well- understood, and changes will be fairly limited during the design process. Few business systems have stable requirements.

Model I: Alternative Waterfall

Evolutionary Development Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer. Throw-away prototyping Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.

Model II: Evolutionary/Iterative

Analisis Model Evolutionary Keuntungan Spesifikasi dapat dikembangkan secara inkremental Sementara pengguna mendapat pemahaman yang lebih baik dari masalah mereka Sistem software dapat merefleksikannya Penerapan For small or medium-size interactive systems; For parts of large systems (e.g. the user interface); For short-lifetime systems.

Analisis Model Evolutionary Kelemahan Lack of process visibility; Proses tidak terlihat, memerlukan alat ukur kemajuan secara reguler Systems are often poorly structured; Perubahan yang sering meruksak struktur software, penyesuaian perubahan semakin sulit dan mahal Special skills (e.g. in languages for rapid prototyping) may be required. Memerlukan keahlian yang lebih mapan

Spiral Development Tidak merepresentasikan rangkaian kegiatan dengan penelusuran balik (backtracking). Berbentuk spiral, dimana software dikembangkan dengan prinsip incremental versions Setiap untai pada spiral menunjukkan fase proses perangkat lunak Tidak ada fase-fase yang tetap seperti spesifikasi atau perancangan. Mencakup model yang lain (prototipe, waterfall) Perbedaannya dengan model lainnya, model spiral mempertimbangkan resiko secara eksplisit

Spiral model of the software process

Model Evolutinary (Spiral)

Empat Sektor Pada Model Spiral Objective setting/Penentuan tujuan Mendefinisikan tujuan spesifik untuk setiap fase proyek Risk assessment &reduction/Penilaian & Pengurangan Resiko Identifikasi resiko proyek dan meminimalisir resiko. Example: jika ada resiko persyaratan yang tidak sesuai diperlukan prototipe Development & validation/Pengembangan & validasi Memilih model pengembangan yang cocok. Jika resiko interface dipilih model prototipe evolusioner. Jika resiko integrasi subsistem dipilih model waterfall Planning/Perencanaan The project is reviewed and the next phase of the spiral is planned.

Model Spiral

Makna Setiap Untaian Spiral Concept Development Project New Product Development Project Product Enhancenment Project Product Maintenance Project

Model Incremental

Model III: Component-based Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the- shelf) systems. This approach is becoming increasingly used as component standards have emerged. Process stages Component analysis; Requirements modification; System design with reuse; Development and integration.

Model Component-based

Model Component-based Software e-Learning Moodle, a-Tutor, Sakai Software e-Commerce Joomla

Teknologi Penunjang Component-based Plugin OOP

Model Rational Unified Process A modern process model derived from the work on the UML and associated process.

RUP phases Inception Elaboration Construction Transition Establish the business case for the system. Elaboration Develop an understanding of the problem domain and the system architecture. Construction System design, programming and testing. Transition Deploy the system in its operating environment.

RUP good practice Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software

Rapid Application Development/RAD Metodologi ini melakukan beberapa penyesuaian terhadap SDLC pada beberapa bagian sehingga lebih cepat untuk sampai ke tangan pengguna. metodologi ini biasanya mensyaratkan beberapa teknik dan alat2 khusus agar proses bisa cepat, misalnya melakukan sesi joint application development (JAD), penggunaan alat-alat computer aided software engineering (CASE Tools), kode generator dan lain-lain.

Model RAD

Model RAD Requires sufficient human resources to create the right number of RAD teams. Tidak semua tipe aplikasi bisa, harus yang tingkat modularisasinya tinggi Tidak cocok jika tingkat resiko teknisnya tinggi, terutama jika banyak menggunakan teknologi terbaru yang mungkin tidak cocok dengan program yang ada

Model Prototype Melakukan analisis, desain dan implementasi secara bersamaan, kemudian dilakukan secara berulang-ulang untuk mendapatkan review dari pengguna sampai semua kebutuhan tercapai.

Model Prototype

Problematika Prototype Developer sering melakukan kompromi agar prototype bisa cepat selesai. Bisa saja menggunakan algoritma yang kurang/tidak efisien, karena dikejar waktu harus cepat jadi. Menggunakan sistem operasi atau bahasa pemrograman yang kurang tepat

Throw-away Prototype Hampir sama dengan metodologi Prototyping, tetapi analisis dilakukan lebih mendalam lagi.

Komparasi Metodologi

Bagaimana Memilih Metodologi Kejelasan kebutuhan pengguna Jika pada suatu saat kita dihadapkan pada kondisi ketidakjelasan kebutuhan pengguna, maka metodologi RAD berbasis prototipe dan prototipe sekali pakai (throwaway prototyping) merupakan salah satu metodologi yang tepat untuk digunakan. Penguasaan teknologi Penguasaan teknologi merupakan satu bagian yang vital untuk dipertimbangkan dalam menentukan sebuah metodologi. Familiaritas terhadap teknologi dasar yang tidak memadai akan menimbulkan pembengkakan waktu dan biaya.

Bagaimana Memilih Metodologi   Tingkat kerumitan sistem yang akan dibangun Sistem yang kompleks membutuhkan analisis dan desain yang sangat hati-hati. Oleh karena itu methodologi agile dan prototyping dipandang kurang begitu baik diterapkan jika tingkat kerumitan sistem sangat tinggi.

Bagaimana Memilih Metodologi Tingkat kehandalan sistem Kehandalan sistem biasanya merupakan faktor penting dalam pengembangan sistem. Metodologi berbasis prototipe umumnya bukan pilihan yang baik karena mereka kurang berhati-hati tahap analisis dan desain. Waktu pelaksanaan pengembangan Metodologi berbasis RAD cocok untuk proyek-proyek dengan jadwal waktu singkat yang membutuhkan kecepatan deliverables. metodologi berbasis waterfall adalah pilihan terburuk ketika waktu adalah penting karena tidak memungkinkan untuk memudahkan perubahan jadwal.

Bagaimana Memilih Metodologi Visibilitas jadwal pelaksanaan Metodologi berbasis RAD banyak bergerak dari keputusan2 penting sehingga metodologi ini paling cocok diterapkan jika manager proyek mengenali dan memberikan perhatian lebih bagi tahapan yang mempunyai faktor resiko dan ekspetasi yang tinggi.

Tugas SE I Amatilah kegiatan di tempat anda masing-masing yang kira-kira business prosess apa yang potensial untuk dikomputerisasikan dalam bentuk aplikasi software. Metodologi apa yang tepat Buatlah paper sederhana & presentasikan Daftar isi paper: Abstrak Pendahuluan Tinjauan pustaka Objek penilitian & Pembahasan Kesimpulan