Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 1 Software Engineering Program Studi Teknik Informatika Fakultas Ilmu Komputer Universitas Dian Nuswantoro

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 2 Software Process References - Software Engineering: A Practitioners Approach. R.S. Pressman and Associates The Rational Planning of (Software) Projects Mark C. Paulk, Software Engineering Institute Created based on the original Pressman slides modified by Romana Spasojevic and Giancarlo Succi

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 3 What is Behind the Names??? Software engineering: Software process Technical Methods Automated Tools The IEEE Definition of Software Engineering: Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1)

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 4 A Layered Technology Software Engineering

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 5 What Does Software Engineering Do??? Definition Development Maintenance Project Tracking / Control Formal Technical Reviews SW Quality Assurance SW Configuration Management Documenting Reusability Management Measurement Risk Management

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 6 Definition (What???) System or information engineering Software project planning Requirements analysis

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 7 Development (How???) Software design Code Generation Software Testing

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 8 Maintenance (Change) Correction Adaptation Enhancement Prevention

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 9 A Common Process Framework

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 10 What Causes SW Projects to Fail? Unrealistic plans, based on optimistic estimates Ineffective tracking of performance Volatile requirements Risks

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 11 But, Why do We Let it Happen? People tend to be risk averse when there is potential of loss ( orang cenderung untuk menentang resiko ketika ada potensi kerugian) People are unduly optimistic in their plans and forecasts. ( orang cenderung terlalu optimis dalam perencaan dan peramalan) People prefer to use intuitive judgment rather than quantitative models ( orang lebih sering menggunakan intuisi dibandingkan dengan model kualitatif)

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 12 Controlling Human Nature Documenting the way work is performed. Dokumentasi cara kerja dibentuk. Provide guidance and quantifiable criteria where possible. Menyediakan kriteria petunjuk dan ukuran2 yang dpt dihitung bila memungkinkan. Record decisions and the data used to make them. Rekam keputusan2 dan gunakan data untuk membuat keputusan tersebut. Analyze the results and improve the process where possible. Analisis hasil dan tingkatkan proses bila memungkinkan Learn - individually and organizationally.

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 13 Capability Maturity Model (CMM) Level 1: Initial Level 2: Repeatable Level 3: Defined Level 4: Managed Level 5: Optimizing

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 14 Key Process Areas (KPA) CMM Level 2 CMM Level3 CMM Level 4 CMM level 5 SW configuration management SW quality assurance SW subcontract management SW project tracking SW project planning Requirements management Peer reviews Inter-group coordination SW production engineering Integrated software management Training Organization process definition Organization process focus Software quality management Quantitative process management Process change management Technology change management Defect prevention

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 15 Process as Problem Solving

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 16 The Linear Model

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 17 Linear Models - Problems Change handling during the process. Penanganan perubahan selama proses. Requires that all requirements are stated clearly at the beginning of the process. Membutuhkan bahwa semua kebutuhan dinyatakan jelas pada awal proses. Working version is delivered at the end of the process cycle; mistakes at earlier stages may be disastrous. Versi kerja dikirim pada saat akhir proses; kesalahan di awal kondisi mungkin berbahaya. “Blocking States”

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 18 Iterative Models - Prototyping

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 19 Prototyping - The Problems There is a “working version” of software before the requirements for the overall quality and maintainability are satisfied. Ada sebuah versi kerjaan perangkat lunak sebelum kebutuhan untuk semua mutu dan perawatan dicukupi. Implementation compromises, made to create a quick “working version” often become a part of the final version. Implementasi berkompromi, dibuat untuk menciptakan sebuah versi kerja cepat sering menjadi bagian dari akhir

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 20 Iterative Models - RAD

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 21 RAD - The Problems For large, but scalable projects, requires significant human resources. Membutuhkan sumber daya manusia yang tepat. Requires customers and developers willing to work in a rapid development environment. Membutuhkan pelanggan dan pengembang yang berkeinginan untuk bekerja dalam lingkungan pengembang yang cepat. If the requirements can not be modularized, this approach may not be suitable. Jika kebutuhan tidak dapat dimodulisasikan, pendekatan ini tidak nyaman. If fine-tuning is needed, this approach may not be suitable. Jika penyetelan yang baik diperlukan, pendekatan ini mungkin tidak cocok.

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 22 Evolutionary Models - The Incremental Model

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 23 Evolutionary Models - Spiral Model

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 24 Spiral Model - The Lifecycle of SW Product Concept Development Projects New Product Development Projects Product Enhancement (peningkatan) Projects Product Maintenance Projects

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 25 Spiral Model - Characteristics Advantages application in large systems and software used well as a risk reduction mechanism Disadvantages controllability (demands high risk assessment and expertise) has not been applied as much (little history)

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 26 Component Assembly Model extract components if available build components if available construct n th iteration of the system identify candidate components look up components in library put new components in library

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 27 Concurrent Model none Under development Baselined Done Under revision Awaiting changes Analysis activity Represent the state of a software engineering activity or task

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 28 Still Other Process Models Formal methods—the process to apply when a mathematical specification is to be developed. Proses untuk menjalankan sebuah spesifikasi matematika dikembangkan. Cleanroom software engineering— emphasizes error detection before testing. Pendeteksian kesalahan sebelum pengujian 4GT (fourth generation techniques) — automatic code generation.

Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 29 Product and Process - Keep Thinking!