Hello World!

1. Software Engineering
and Information System
Design
The Software Process

2. What is a Process?
• We can think of a series of activities as a process
• Any process has the following characteristics
– It prescribes all of the major activities
– It uses resources and produces intermediate and final
products
– It may include sub-processes and has entry and exit
criteria
– The activities are organized in a sequence
– Constraints or control may apply to activities
(budget control, availability of resources )

3. Software Processes
Coherent sets of activities for
– Specifying,
– Designing,
– Implementing and
– Testing software systems
When the process involves the building of some product,
we refer to the process as a life cycle
Software development process – software life cycle

4. The Software Process
• A structured set of activities required to
develop a software system
– Specification
– Design
– Validation
– Evolution
• Fundamental Assumptions:
– Good processes lead to good software
– Good processes reduce risk

5. Generic software process models
• The waterfall model
– Separate and distinct phases of specification and
development
• Evolutionary development
– Specification and development are interleaved
• Formal systems development
– A mathematical system model is formally transformed
to an implementation
• Reuse-based development
– The system is assembled from existing components

6. Software Process Models
• Waterfall model (Royce, 1970)
• Prototyping
– Throwaway
– Evolutionary
• Incremental development
– Iterative
– Spiral model (Boehm, 1988)

7. Some Realities of Software
Development
 1. Requirements always change because of:
changing customer desires and user needs
initial requirements analysis inadequate
understandings and insights gained through experience
changing technology
changing competitive situation
personnel turnover: engineering, management, marketing,
customer

8. Some Realities of Software
Development
 2. The design is never right the first time
design is a creative, problem solving process
 3. Frequent demonstrations of progress and early
warning of problems are desirable

9. Prototyping
Requirements
Implementatio
n
Design
Testing
Design
Implementation
Testing
Maintenance

10. Observations
• Used for requirements elicitation and
validation
• A “working” model (prototype) of the final
system is developed during requirements
 The system evolves by adding new features as they
are proposed by customer.
• Is an iterative process
• Prototype can be thrown away or evolved into
the final system (evolutionary prototyping)

11. Advantages of Prototype model:
• Users are actively involved in the development
• Since in this methodology a working model of the system is
provided, the users get a better understanding of the system
being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified as requirement
validation, quick implementation of incomplete, but functional
application

12. Disadvantages of Prototype model:
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the system as
scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as the
full system was designed
Incomplete or inadequate problem analysis.
 Lack of process visibility
 Systems are often poorly structured
 Special skills (e.g. in languages for rapid prototyping) may be
required

13. When to use Prototype model
• Prototype model should be used when the desired system needs to have a
lot of interaction with the end users.
• Typically, online systems, web interfaces have a very high amount of
interaction with end users, are best suited for Prototype model. It might
take a while for a system to be built that allows ease of use and needs
minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system
and provide a feedback which is incorporated in the prototype to result in
a useable system. They are excellent for designing good human computer
interface systems.
– For small or medium-size interactive systems
– For parts of large systems (e.g. the user interface)

15. Evolutionary development
• Exploratory development
- Objective is to work with customers and to evolve
a final system from an initial outline specification.
- The system evolves by adding new features as
they are proposed by customer.

16. Evolutionary development
• Rapid prototyping
– Objective is to understand the system
requirements.
• Develop “quick and dirty” system in short
time;
• Expose to user comment & feedback;
• Refine;
Repeat until adequate system
developed.
– Particularly suitable where:

17. Evolutionary development
Outline
Description
Concurrent
Activities
Requirements
Design
Implementation
Initial
Versio
n
Intermediate
Versions
Final
Version

18. Evolutionary development
Requirements
Design
Implementation
(prototype)
Evaluation

19. Process iteration
•Modern development processes take iteration as a fundamental
concept.
•System requirements ALWAYS evolve during the course of a
project; so process iteration where earlier stages are reworked is
always part of the process for large systems.
•Iteration can be applied to any of the generic process models.
•Two (related) approaches:
• Incremental development
• Spiral development

20. Incremental development
System is not a single delivery; the development and
delivery broken down into increments delivering part of
the required functionality.
User requirements are prioritized and the highest
priority requirements are included in early increments.
Once the development of an increment is started,
the requirements are frozen though requirements
for later increments can continue to evolve.

21. Incremental development
Valida te
incremen
t
Develop system
increment
Design system
architecture
Integrate
incremen
t
Valida te
system
Define outline
requirements
Assign requirements
to increments
System incomplete
Final
syste
m

22. The Incremental Model

23. Observations
• Development and delivery is broken down
into increments with each increment
delivering part of the required functionality.
• User requirements are prioritised and the
highest priority requirements are included
in early increments.
• Is an iterative process

24. Advantages of Incremental model:
• Customer value can be delivered with each increment so system functionality is
available earlier.
• Early increments act as a prototype to help elicit requirements for later
increments
• Lower risk of overall project failure
• The highest priority system services tend to receive the most testing
• Generates working software quickly and early during the software life
cycle.
• This model is more flexible – less costly to change scope and
requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified and handled

25. Disadvantages of Incremental model:
• Needs good planning and design.
• Needs a clear and complete definition of the whole system before it can
be broken down and built incrementally.
• Total cost is higher than waterfall.
• 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.

26. When to use the Incremental model
• This model can be used when the requirements of the
complete system are clearly defined and understood.
• Major requirements must be defined; however, some details
can evolve with time.
• There is a need to get a product to the market early.
• A new technology is being used
• Resources with needed skill set are not available
• There are some high risk features and goals.

27. Spiral Model
The spiral model is a risk-driven process model
generator for software projects. Based on the unique risk
patterns of a given project, the spiral model guides a team to
adopt elements of one or more process models, such as
incremental, waterfall, or evolutionary prototyping.
This model was first described by Barry Boehm in his
1986 paper "A Spiral Model of Software Development and
Enhancement".

28. Spiral development
Process is represented as a spiral rather than as a sequence of
activities with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design – loops in the
spiral are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the
process.

29. Spiral model of the software process
Risk
analysis
Risk
analysis
Risk
analysis
Ris k
Proto-
analysis
type 1
Prototype 3
Prototype 2
Opera-
tional
protoyp e
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements Prod uct
design Detailed
design
Code
Requirement
validation
Design
V&V
A
c
c
test
Service
Unit test
Integr ation
test
Develop,
verify next-level
product
Evaluate alternatives
identify, resolve risks
Determine objectives
alternatives and
constraints
Plan next phase
Integration
and test plan
Develop ment
plan
Requirements plan
Life-cycle plan
REVIEW

30. Spiral model sectors
 Objective setting
• Specific objectives for the phase are identified
 Risk assessment and reduction
• Risks are assessed and activities put in place to reduce key risks
 Development and validation
•A development model for the system is chosen which can be
any of the generic models
 Planning
• The project is reviewed and next phase of the spiral is

31. Observations
• Process is represented as a spiral rather than as a
sequence of activities with backtracking
• Each loop in the spiral represents a phase in the
process.
• No fixed phases such as specification or design -- loops in
the spiral are chosen depending on what is required
• Risks are explicitly assessed and resolved throughout the
process.
• Uses prototyping

32. Advantages of Spiral model
• High amount of risk analysis hence, avoidance
of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a
later date.
• Software is produced early in the software life
cycle.

33. Disadvantages of Spiral model
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the
risk analysis phase.
• Doesn’t work well for smaller projects.

34. When to use Spiral model
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential
changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)

35. Spiral model usage
Spiral model has been very influential in helping people
think about iteration in software processes and introducing
the risk-driven approach to development.
In practice, however, the model is rarely used as
published for practical software development.