Materi Kuliah SE 2 Pengertian software Kriteria software

Presentasi berjudul: "Materi Kuliah SE 2 Pengertian software Kriteria software"— Transcript presentasi:

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

2 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

3 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

4 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

5 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

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

7 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

8 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

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

10 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

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

12 Proses Rekayasa Persyaratan

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

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

15 Proses Perancangan Software

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

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

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

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

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

21 Proses Ujicoba Penerimaan Unit Sistem

22 Fase Ujicoba

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

24 System evolution

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

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

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

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

29 Model Waterfall

30 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

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

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

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

34 Model I: Alternative Waterfall

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

36 Model II: Evolutionary/Iterative

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

38 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

39 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

40 Spiral model of the software process

41 Model Evolutinary (Spiral)

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

43 Model Spiral

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

45 Model Incremental

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

47 Model Component-based

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

49 Teknologi Penunjang Component-based
Plugin OOP

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

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

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

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

54 Model RAD

55 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

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

57 Model Prototype

58 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

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

60 Komparasi Metodologi

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

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

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

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

65 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