Software Engineering Program Studi Teknik Informatika Fakultas Ilmu

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

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 2

What is Behind the Names? ? ? The IEEE Definition of 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) • Software engineering: • Software process • Technical Methods • Automated Tools Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 3

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

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 5

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

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

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

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

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 10

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 11

Controlling Human Nature • Documenting the way work is performed. Dokumentasi cara kerja dibentuk. • Provide guidance and quantifiable criteria where possible. Menyediakan kriteria petunjuk dan ukuran 2 yang dpt dihitung bila memungkinkan. • Record decisions and the data used to make them. Rekam keputusan 2 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 12

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

Key Process Areas (KPA) • CMM Level 2 • CMM Level 3 • 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 14

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

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

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 17

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

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 19

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

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 21

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

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

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 24

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

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

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

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 • 4 GT (fourth generation techniques) — automatic code generation. Rekayasa Perangkat Lunak/ AP/ 2005 Software Proses Page 28

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