intoroduction to software Engineering

1. Chapter 4
Part-2
Software Processes

2. In Ch4 Lec 5 – Part 1 we discuss:
1- Generic software process model
a. waterfall model
b. evolutionary model
c. Formal systems
d. reuse- based component model
In Ch4 Lec 5 – Part 2 we discuss:
2- Iterative process model
a. Incremental development (delivery)
b. Spiral development
3- software process
4- CASE tools

3. Process iteration
• process iteration where earlier stages are
reworked in response to change request is always
part of the process for large systems
• The iteration process models that have been
designed to support process iteration??
– 1- Incremental development (delivery)
– 2- Spiral development

4. 1- Incremental delivery
• It is an in between approach which combines the
advantages of waterfall and evolutionary models.
• Rather than deliver the system as a single
delivery, the software specification, design and
implementation is broken down into increments
with each increment delivering part of the required
functionality.

5. Incremental delivery
• 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

6. Incremental development
Validate
increment
Develop system
increment
Design system
architecture
Integrate
increment
Validate
system
Define outline
requirements
Assign requirements
to increments
System incomplete
Final
system

7. Incremental delivery advantages
• Customer can gain value from the system 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
• it is useful when staffing is unavailable for a complete
implementation.

8. Advice: when you encounter a difficult deadline that
cannot be changed, the incremental model is a good
one to consider.
Increments should be relatively small and each
increment should deliver some system functionality.
So it is difficult to map the customer’s requirement
with the right size of the increment.
A recent evolution of this increment approach called
extreme programming (XP).

9. Extreme programming (XP)- a new
evolution of incremental approach.
• New approach based on the development and
delivery of very small increments of
functionality
• Relies on user involvement in the development
team (planning) and pair programming (Coding)

10. 2- Spiral development
• Process is represented as a spiral rather than as a
sequence of activities with backtracking from one
activity to another.
• Each loop in the spiral represents a phase in the
software process.
• The inner loop might be connected to feasibility, next
loop with requirements definitions and so on.
• Risks are explicitly assessed and resolved throughout
the process

11. Spiral model of the software
process
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integration
testAcceptance
testService Develop, verify
next-level product
Evaluate alternatives
identify, resolve risks
Determine objectives
alternatives and
constraints
Plan next phase
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW

12. Spiral model loop sectors
• Objective setting
– Specific objectives for the phase are identified
– constraints on the process and the product are
identified, also project risks are identified.
• Risk analysis (assessment) and reduction
– Risks are assessed and activities put in place to
reduce the key risks
– Example: if there is a risk that the requirements
are inappropriate, a prototype system may be
developed.

13. Spiral model loop sectors
• Development and validation (engineering)
– A development model for the system is chosen
which can be any of the generic models
– Example: if user interface risk are dominant
, an appropriate development model might
be evolutionary prototyping
• Planning
– The project is reviewed and the next phase of
the spiral is planned

14. Spiral model
• The main different between the Spiral model and other
Software process model:
is the explicit recognition of the risk (something that
can be go wrong)

15. Process activities
• 1- Software specification
• 2- Software design and implementation
• 3- Software validation
• 4- Software evolution

16. 1- Software specification (RE)
• It is the process of establishing what services are required
from the system and the constraints on the system’s
operation and development

17. 1- Software specification (RE)
• Software specification or Requirements Engineering process
phases:
– Feasibility study (is the proposed system cost-effective, is it
within the budget constraints)
– Requirements elicitation and analysis, this may involve
observation of existing system, task analysis, and may need
to development of system model an prototype.
– Requirements specification, translate info gathered to set of
requirements (document), it include:
User requirement and system requirements (more detail)
– Requirements validation, realism, consistency and
completeness.

18. The Requirements Engineering
process
Feasibility
study
Requirements
elicitation and
analysis
Requirements
specification
Requirements
validation
Feasibility
report
System
models
User and system
requirements
Requirements
document

19. 2- Software design and implementation
• The process of converting the system
specification into an executable system
• Software design, is a description of the structure
of the software, the data, the interfaces, and
algorithms.
• Implementation, translate this structure into an
executable program
• The activities of design and implementation are
closely related and may be inter-leaved

20. Design process activities (phases)
• Architectural design, the sub systems making the system and their
relationship are identified.
• Abstract specification, for each sub system, an abstract specification
of its services and constraints is produced.
• Interface design, for each sub system, its interfaces with others is
designed.
• Component design: services are allocated to the component and the
interfaces for this component is designed
• Data structure design: the data structure used in this system are
designed in detail.
• Algorithm design: the Algorithm used in this system are designed in
detail.

21. The software design process
Architectural
design
Abstract
specification
Interface
design
Component
design
Data
structure
design
Algorithm
design
System
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Requirements
specification
Design activities
Design products

22. Programming and debugging
( Implementation)
• Translating a design into a program and removing errors
from that program
• Programming is a personal activity - there is no generic
programming process
• Programmers carry out some program testing to discover
faults in the program and remove these faults in the
debugging process
• The debugging process are consisted of locate errors, design
error repair, repair errors, and re-test program.

23. The debugging process
Locate
error
Design
error repair
Repair
error
Re-test
program

24. 3- Software validation
• Verification and validation (V & V) is intended to
show that a system conforms to its specification
and meets the requirements of the system’s
customer
• 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

25. The stages of testing process
Sub-system
testing
Module
testing
Unit
testing
System
testing
Acceptance
testing
Component
testing
Integration testing User
testing

26. Testing Process stages
• Unit(Component) testing, individual components
are tested to insure that it is work correctly
• Module testing, related collections of dependent
components are tested
• Sub-system testing, modules are integrated into
sub-systems and tested. The focus here should be
on interface testing

27. Testing Process stages, cont…
• System testing, testing of the system as a whole.
integrate the component then make testing * to find the
errors result from integration and interface problems for
this component. This test is used * to validate the system
to meet the functional and non-functional requirement
and * to check the emergent properties.
• Acceptance testing, testing with customer data to
check that it is acceptable. System is tested using a
real data supplied by the user. This test reveals
requirement problems and if the system performance is
not acceptable.

28. 4- Software evolution
• 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 split between development and
evolution (maintenance) .
• Software maintenance cost is several times the
development cost.

29. System evolution
Assess existing
systems
Define system
requirements
Propose system
changes
Modify
systems
New
system
Existing
systems

30. Computer-aided software engineering (CASE)
• CASE is software to support requirement, design, software
development and evolution processes.
• Activity automation- can be used by CASE:
– Graphical editors used for system model development
– Data dictionary that holds information about entities and
relations of design. Used to understand design.
– Graphical User Interface builder used for user interface
construction
– Debuggers to support program fault finding
– Automated translators to generate new versions of a
program from old one. (ex COBOL)

31. CASE technology
• Case technology has led to significant improvements in the
software process and saving in the cost of software
process.
• CASE is available for most routine activities of software
process.
• The improvement from the use of CASE are limited by two
factors:
– Software engineering requires creative thought-
(Artificial intelligent technology ) - this is not easily
automatable.
– Software engineering is a team activity and, for large
projects, much time is spent in team interactions. CASE
technology does not really support these

32. CASE Tool classification
Classification helps us understand the different types of
CASE tools and their support for process activities:
• Functional perspective, tools are classified according to
their specific function
• Process perspective, tools are classified according to
process activities that are supported
• Integration perspective, tools are classified according to
how they are organised into integrated units that provide
support for process activity.

33. Functional tool classification
Tool type Examples
Planning tools PERT tools, estimation tools,
spreadsheets
Editing tools Text editors, diagram editors, word
processors
Change management tools Requirements traceability tools, change
control systems
Configuration management tools Version management systems, system
building tools
Prototyping tools Very high-level languages,
user interface generators
Method-support tools Design editors, data dictionaries, code
generators
Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static
analysers, dynamic analysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-
structuring systems

34. Activity-based classification
Reengineering tools
Testing tools
Debugging tools
Program analysis tools
Language-processing
tools
Method support tools
Prototyping tools
Configuration
management tools
Change management tools
Documentation tools
Editing tools
Planning tools
Specification Design Implementation Verification
and
Validation

35. CASE Classification Categories:
• Tools: support individual process activity such as design
consistency checking, text editing.
• Workbenches: support a set of related process phases and
activities such as specification or design.
Normally include a number of integrated tools.
• Environments: support all or most part of an entire
software process activities. Normally include several
integrated workbenches

36. Tools, workbenches, environments
Single-method
workbenches
General-purpose
workbenches
Multi-method
workbenches
Language-specific
workbenches
Programming Testing
Analysis and
design
Integrated
environments
Process-centred
environments
File
comparators
CompilersEditors
EnvironmentsWorkbenchesTools
CASE
technology

37. Key points
• Software processes are the activities involved in producing
and evolving a software system. They are represented in a
software process model
• General activities are specification, design,
implementation, validation and evolution
• Generic process models describe the organization of
software processes such as waterfall, evolutionary and
reuse-component.
• Iterative process models describe the software process as
a cycle of activities. Such as incremental delivery and
spiral model.
The main advantage of iteration process model is to avoid
the commitment to specification and design.

38. Key points
• Requirements engineering is the process of developing a
software specification
• Design and implementation processes transform the
specification to an executable program
• Validation involves checking that the system meets to its
specification and user needs
• Evolution is concerned with modifying the system after it is
in use
• CASE technology supports software process activities