Materi perkulaiahan matakuliah Rekayasa Perangkat Lunak. Dalam materi ini berisi: -Aktivitas Fundamental -Models

1. Marwondo
Fakultas Teknologi Informasi
Universitas Informatika dan Bisnis Indonesia
Fund.
Activity

2. Fundamental Activities
 Although there are many different software processes,
there are fundamental activities which are common to all
software processes.
 Generic activities in all software processes are:
 Specification - what the system should do and its
development constraints
 Design and Implementation - production of the software
system
 Validation - checking that the software is what the customer
wants
 Evolution - changing the software in response to changing
demands.
Soft.
Specification

3. Software specification
 Dimaksudkan untuk menetapkan layanan apa saja yang
diperlukan dari sistem dan kendala pada operasi dan
pengembangan system
 Often called requirements engineering
 Four main phase:
 Feasibility study
 Detailed estimation is made in this phase
 Requirements elicitation and analysis
 Help analyst to understand the system to be specified
 Requirements specification
 Translating analysis result into requirements
 Requirements validation
 Check requirements
Soft.
Specification
Figure

4. Soft. Design
& Implement

5. Software Design &
Implementation
 The process of converting system specification into an
executable system.
 May also involve refinement of software specification
 Iterative design is the best that designer can do!!
Specific
design
process

6. Specific design process
 Architectural design
 Abstract specification
 Interface design
 Component design
 Data structure design
 Algorithm design
Soft. Design
& Implement

8. Software Validation
 Include verification and validation
 Intended to show that a system conforms to its
specification and that the system meets the
expectations of the customer buying system

9. Testing Process
 Unit testing
 Module testing
 Sub-system testing
 System testing
 Acceptance testing

11. Software Evolution
 Changes on software can be made at any time during or
after the system development.
 Demarcation between software development and software
evolution
 Rather than separate the processes, it is better to think
that the software engineering is a evolutionary process
 Software engineering is a evolutionary process means
software is continually changed over its lifetime in
response to changing requirements and customer needs.

13. What is a software process
model?
 A simplified representation of a software process,
presented from a specific perspective.
 Examples of process perspectives are
 Workflow perspective - sequence of activities;
 Data-flow perspective - information flow;
 Role/action perspective - who does what.
 Generic process models
 Waterfall;
 Iterative development;
 Component-based software engineering.

14. Software process models
 The waterfall model
 Plan-driven model. Separate and distinct phases of
specification and development.
 Incremental development
 Specification, development and validation are interleaved.
May be plan-driven or agile.
 Reuse-oriented software engineering
 The system is assembled from existing components. May
be plan-driven or agile.
 In practice, most large systems are developed using a
process that incorporates elements from all of these
models.
14
Chapter 2 Software Processes

15. The waterfall model
15
Chapter 2 Software Processes

16. 16
Waterfall Model
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback

17. 17
Waterfall Model with Feedback
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback

18. Waterfall model phases
 There are separate identified phases in the waterfall
model:
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
 The main drawback of the waterfall model is the
difficulty of accommodating change after the process is
underway. In principle, a phase has to be complete
before moving onto the next phase.
18
Chapter 2 Software Processes

19. Waterfall model problems
 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.
 The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
 In those circumstances, the plan-driven nature of the
waterfall model helps coordinate the work.
19
Chapter 2 Software Processes

20. Incremental development
20
Chapter 2 Software Processes

21. 21
Waterfall Model with Feedback
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback

22. 22
Incremental Model
(Diagram)
Communication
Planning
Modeling
Construction
Deployment
Communication
Planning
Modeling
Construction
Deployment
Communication
Planning
Modeling
Construction
Deployment
Increment #1
Increment #2
Increment #3

23. 23
Incremental Model
(Description)
 Used when requirements are well understood
 Multiple independent deliveries are identified
 Work flow is in a linear (i.e., sequential) fashion within an
increment and is staggered between increments
 Iterative in nature; focuses on an operational product with each
increment
 Provides a needed set of functionality sooner while delivering
optional components later
 Useful also when staffing is too short for a full-scale development

24. 24
Prototyping Model
(Diagram)
Communication
Quick
Planning
Modeling
Quick Design
Construction
Of Prototype
Deployment,
Delivery,
and Feedback
Start

25. 25
Prototyping Model
(Description)
 Follows an evolutionary and iterative approach
 Used when requirements are not well understood
 Serves as a mechanism for identifying software requirements
 Focuses on those aspects of the software that are visible to the
customer/user
 Feedback is used to refine the prototype

26. 26
Prototyping Model
(Potential Problems)
 The customer sees a "working version" of the software, wants to
stop all development and then buy the prototype after a "few fixes"
are made
 Developers often make implementation compromises to get the
software running quickly (e.g., language choice, user interface,
operating system choice, inefficient algorithms)
 Lesson learned
 Define the rules up front on the final disposition of the prototype
before it is built
 In most circumstances, plan to discard the prototype and engineer the
actual production software with a goal toward quality

27. 27
Spiral Model
(Diagram)
Start
Start
Communication
Planning
Modeling
Construction
Deployment

28. 28
Spiral Model
(Description)
 Invented by Dr. Barry Boehm in 1988 while working at TRW
 Follows an evolutionary approach
 Used when requirements are not well understood and risks are high
 Inner spirals focus on identifying software requirements and project
risks; may also incorporate prototyping
 Outer spirals take on a classical waterfall approach after requirements
have been defined, but permit iterative growth of the software
 Operates as a risk-driven model…a go/no-go decision occurs after each
complete spiral in order to react to risk determinations
 Requires considerable expertise in risk assessment
 Serves as a realistic model for large-scale software development

29. Incremental development
benefits
 The cost of accommodating changing customer
requirements is reduced.
 The amount of analysis and documentation that has to be
redone is much less than is required with the waterfall
model.
 It is easier to get customer feedback on the
development work that has been done.
 Customers can comment on demonstrations of the
software and see how much has been implemented.
 More rapid delivery and deployment of useful software
to the customer is possible.
 Customers are able to use and gain value from the
software earlier than is possible with a waterfall process.
29
Chapter 2 Software Processes

30. 30
General Weaknesses of Evolutionary
Process Models
1) Prototyping poses a problem to project planning because of the
uncertain number of iterations required to construct the product
2) Evolutionary software processes do not establish the maximum
speed of the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
3) Software processes should focus first on flexibility and
extensibility, and second on high quality
• We should prioritize the speed of the development over zero
defects
• Extending the development in order to reach higher quality could
result in late delivery

31. Incremental development
problems
 The process is not visible.
 Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to
produce documents that reflect every version of the
system.
 System structure tends to degrade as new increments
are added.
 Unless time and money is spent on refactoring to improve
the software, regular change tends to corrupt its
structure. Incorporating further software changes becomes
increasingly difficult and costly.
31
Chapter 2 Software Processes

32. Reuse-oriented software
engineering
 Based on systematic reuse where systems are integrated
from existing components or COTS (Commercial-off-the-
shelf) systems.
 Process stages
 Component analysis;
 Requirements modification;
 System design with reuse;
 Development and integration.
 Reuse is now the standard approach for building many
types of business system
 Reuse covered in more depth in Chapter 16.
32
Chapter 2 Software Processes

33. Reuse-oriented software
engineering
33
Chapter 2 Software Processes

34. See Next Week