1. Software Engineering C h a p t e r 2 Software Process Dr. Doaa Sami
Modified from Sommerville’s originals

2. Objectives  To introduce software process models2
 To introduce software process models
 Waterfall, iterative and spiral model.
 To describe process activities
 To explain the Rational Unified Process
 An example of a modern software process.

3. Video Tutorials
Software Engineering Process Models Reasons for Agile Processes Spiral Model

4. SOFTWARE-DEVELOPMENT LIFE-CYCLE
The software-development life-cycle is used to facilitate the development of a large software product in a systematic, well-defined, and cost- effective way

5. MAINTENANCE Maintenance is an important part of the SDLC
Maintenance may consume more time than the time consumed in the development
The cost of maintenance varies from 50% to 80% of the total development cost

6. TYPES OF MAINTENANCE 1. Corrective Maintenance:
Corrective maintenance means repairing processing failures or making changes because of previously uncorrected problems
2. Adaptive Maintenance:
Adaptive maintenance means changing the program function. This is done to adapt to the external environment change

7. TYPES OF MAINTENANCE 3. Perfective Maintenance:
Perfective maintenance means enhancing the performance or modifying the programs to respond to the user’s additional or changing needs

8. TYPES OF MAINTENANCE 4. Preventive Maintenance:
Preventive maintenance is the process by which we prevent our system from being obsolete
It involves the concept of re-engineering and reverse engineering in which an old system with an old technology is re-engineered using new technology

9. Ad Hoc Software Development3 3
 Developing software without planning for each
phase, and without specifying tasks, deliverables, or
time constraints.
 Relies entirely on the skills and experience of the
individuals performing the work.
 The software process may change as work progresses.

10. Overcome Problems of Ad Hoc Development4
 Problems (include But not limited to):
 Difficult to distinguish between tasks  important tasks may
be ignored.
 Inconsistent schedules, budgets, functionality, and product
quality.
 Delayed problem discovery  more costly to fix.
Solution? Software Process Model
“ an abstract representation of a process. It presents a description of a
process from some particular perspective.”
 Software Process Models provide guidelines to organize how software process activities should be performed and in what order.

11. Plan-driven and Agile Processes5
 Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.
 In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.
 In practice, most practical processes include elements of both plan-driven and agile approaches.
 There are no right or wrong software processes.

12. Software Process Models6
 Waterfall Model
 Separate and distinct phases of specification and development.
 Iterative Model
 Specification, development and validation are interleaved.
 Reuse-oriented Software Engineering
 The system is assembled from existing components.
 Which software process model is best?
 Depends on the project circumstances and requirements
 In practice, most large systems are developed using a process
that incorporates elements from all of these models.

13. Waterfall Model Phases7
Requirements
definitions
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance

14. Waterfall Model  There are separate phases in the waterfall model:8
 There are separate phases in the waterfall model:
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
 Waterfall Model Description
 Sequential (linear) design process
 Flow steadily downwards
 One phase has to be completed before moving onto the next
phase.

15. Waterfall Model Advantages9
 It has a clear structure which makes it easy to use.
 It is appropriate when the requirements are well-
understood and changes will be fairly limited during
the design process.
 It is mostly used for large systems engineering
projects where a system is developed at several sites.

16. Waterfall Model Disadvantages10
 The main drawback of the waterfall model is the
difficulty of accommodating change after the process
is underway
 No prototypes are used. It is difficult for customers
to described all requirements explicitly.
 Requires customer patience because a working
version of the program doesn't occur until the final
phase.
 Few business systems have stable requirements.

17. Software prototyping
A prototype is an initial version of a system used to demonstrate concepts and try out design options.
A prototype can be used in:
The requirements engineering process to help with requirements elicitation and validation;
In design processes to explore options and develop a UI design;
In the testing process to run back-to-back tests.
Chapter 2 Software Processes

18. Benefits of prototyping
Improved system usability.
A closer match to users’ real needs.
Improved design quality.
Improved maintainability.
Reduced development effort.
Chapter 2 Software Processes

19. The process of prototype development
Chapter 2 Software Processes

20. Prototype development
May be based on rapid prototyping languages or tools
May involve leaving out functionality
Prototype should focus on areas of the product that are not well-understood;
Error checking and recovery may not be included in the prototype;
Focus on functional rather than non-functional requirements such as reliability and security
Chapter 2 Software Processes

21. Iterative Model iteration where earlier stages are reworked is always11
 System requirements ALWAYS evolve. 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.
 Three (related) approaches
 Incremental delivery.
 Spiral development.
 Agile development.

22. Incremental Delivery Description12
 The Incremental Model = Linear Sequential Model
(waterfall) + the iterative philosophy.
 When an Incremental Model is used, the first increment is often the “core product”.
 The subsequent iterations are the supporting
functionalities or the add-on features that a
customer would like to see.
 The model is designed, implemented and tested as a
series of incremental builds until the product is
finished.

23. Incremental Delivery Description Cont.13
 Each increment cycle  delivers part of the
functionality.
 Provides a needed set of functionalities sooner
while delivering optional components later.
 User requirements have to be prioritized .
 Requirements with highest priority are included in early increments.
 Freezing requirements for each increment (no
changing in requirement once a specific increment
started).

24. Incremental Delivery 14
Define outline Assign Design system Develop system
requirements increment Architecture increment
System incomplete?
Validate Integrate Validate Deploy
increment increment system increment
System
complete?
Final
Increment 1: Analysis Design  Develop  Test  integrate  test (Delivery of
1st Increments). Normally ''Core Product“
Increment 2:Analysis Design  Develop  Test  integrate  test (Delivery of
2nd Increments)
Increment n: Analysis Design  Develop  Test  integrate  test (Delivery of nth Increments)
requirement to

25. Incremental development
Chapter 2 Software Processes

26. Incremental Delivery Advantages15
 Customer don’t need to wait until the entire system deliver.
 Give customer some opportunities to delay some decisions.
 Lower risk of overall project failure.
 The highest priority system services tend to receive the most testing.

27. Incremental Delivery Disadvantages16
 Most systems require a set of basic facilities that are used by different parts of the system. Difficult to identify common requirements between increments.
 Increments should be relatively small and still
deliver some functionality.
 Might be difficult to map customer requirements
into increments.
 High level requirements may not be sufficient to
define system architecture.

28. Spiral Model 17
 Process is represented as a spiral rather than as a sequence of activities.
 Using the Spiral Model, the software is developed in
a series of incremental releases.
 Unlike the incremental Model, where in the first product is a core product, in the Spiral Model the early iterations could result in a paper model or a prototype.
 Risks are explicitly assessed and resolved throughout the process.
 It is favored for large, expensive, and complicated models.

29. Spiral Model of The Software Process18

30. Spiral Model Sectors  Objective setting19
 Objective setting
 Specific objectives for the phase are identified.
 Risk assessment and reduction
 Risks are assessed and activities put in place to reduce the 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 the next phase of the spiral is
planned.

31. Spiral Model Advantages20
 Estimates of the budget and schedule become more
realistic as work progresses because of the
questions that have been raised.
 Easier to cope with the changes inherent to software development.
 Software engineers can start working on the project
earlier rather than wading through a lengthy early
design process.

32. Spiral Model Disadvantages21
 Estimating the budget and time are harder to be judged at the beginning of the project since the requirements evolve through the process.
 Requires considerable expertise in risk assessment.
 Requires more time, and is more expensive.

33. The concurrent engineering model
Software Engineering Software Processes
Software Engineering

34. The concurrent engineering model
It explicitly accounts for the divide and conquer principle.
Each team works on its own component, typically following a spiral or evolutionary approach.
There has to be some initial planning, and periodic integration.
Software Engineering Software Processes
Software Engineering

35. Risks 22  Risk driven process model  What is risk?  Example risks:
 Different risk patterns can lead to choosing different process
models
 What is risk?
 Situations or possible events that may cause a project to fail to
meet its goal.
 Example risks:
 Experienced staff leave the project.
 Hardware which is essential for the system will not be
delivered on schedule.

36. Reuse-oriented Software Development23
 It also called Component Based Software Engineering
(CBSE).
 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.
 This approach is becoming increasingly used as
component standards have emerged.

37. Reuse-oriented software engineering
Chapter 2 Software Processes

38. CBSE Advantages and Disadvantages24
 Advantages
 Reduce amount of software to be developed.
 Reduce costs and risks.
 Faster delivery.
 Disadvantages:
 Requirements compromises, system does not meet real needs of users.
 Control over system evolution is lost.

39. Evolutionary development
Develop an initial implementation prototype
Client test drive …
feed back
Refine prototype
 2 types of Evolutionary development
Exploratory development Throw-away prototyping
Software Engineering Software Processes

40. Evolutionary development
Software Engineering Software Processes
Software Engineering

41. Evolutionary development
2 types of Evolutionary development
Exploratory development
Objective is to work with customers, explore their requirements and to evolve a final system from an initial outline specification.
Should start with well-understood requirements and add new features as proposed by the customer.
Throw-away prototyping
Objective is to understand the system requirements and outline abetter definition of requirements.
Should start with poorly understood requirements to clarify what is really needed.
Software Engineering Software Processes
Software Engineering

42. TIME BOXING PROCESS MODEL
To speed up development, parallelism between the different iterations can be employed
A new iteration commences before the system produced by the current iteration is released, and hence development of a new release happens in parallel with the development of the current release

43. TIME-BOXING PROCESS MODEL.

44. TIME-BOXING PROCESS MODEL
In the time boxing model, the basic unit of development is a time box, which is of fixed duration
Since the duration is fixed, a key factor in selecting the requirements to be built in a time box is what can be fit into the time box
This is in contrast to regular iterative approaches where the functionality is selected and then the time to deliver is determined

45. TIME-BOXING PROCESS MODEL
Each time box is divided into a sequence of stages
The model requires that the duration of each stage is approximately the same
Having time-boxed iterations with stages of equal duration and having dedicated teams renders itself to pipelining of different iterations

46. TIME-BOXING PROCESS MODEL
To illustrate the use of this model, consider a time box consisting of three stages: requirement specification, build, and deployment
The requirement stage is executed by its team of analysts and ends with a prioritized list of requirements to be built in this iteration along with a high-level design

47. TIME-BOXING PROCESS MODEL
The build team develops the code for implementing the requirements, and performs the testing
The tested code is then handed over to the deployment team, which performs pre-deployment tests, and then installs the system for use
These three stages can be done in approximately equal time in an iteration

48. TIME-BOXING PROCESS MODEL
Timeboxing is well suited for projects that require a large number of features to be developed in a short time around a stable architecture using stable technologies
These features should be such that there is some flexibility in grouping them for building a meaningful system in an iteration that provides value to the users

49. TIME-BOXING PROCESS MODEL
The main cost of this model is the increased complexity of project management (and managing the products being developed) as multiple developments are concurrently active
Also, the impact of unusual situations in an iteration can be quite disruptive

50. TIME-BOXING PROCESS MODEL
Tasks of Different Teams

51. V PROCESS MODEL .

52. V PROCESS MODEL The V model is a variant of the waterfall model
It represents a tacit recognition that there are testing activities occurring throughout the waterfall software life cycle model and not just during the software testing period

53. V PROCESS MODEL
For example, during requirements specification, the requirements are evaluated for testability and an STRS may be written
This document would describe the strategy necessary for testing the requirements

54. V PROCESS MODEL
Testing is a full life-cycle activity and that it is important to constantly consider the testability of any software requirement and to design to allow for such testability

55. Process Activities 25
 The four basic process activities are organized differently in different development processes:
 Software Specification.
 Software Development (design + implementation).
 Validation.
 Evolution.

56. Software Specification26
 The process of establishing what services required and constraints on the system’s operation and development.
 Requirements engineering process:
 Feasibility study  Cheap and quick.
 Requirements elicitation and analysis  This document is
derived by observation of existing one, task analysis, talk to customer.
 Requirements specification  Defining requirements in detail.
 Requirements validation  Checking the validity of the
requirements.

57. Requirements Engineering Process27

58. Software Design and Implementation28
 The process of converting system specification into an executable system.
 Software design
 Design a software structure that realises the specification;
 Implementation
 Translate this structure into an executable program;
 The activities of design and implementation are
closely related and may be inter-leaved.

59. Design Activities  Architectural design,  Interface design:29
 Architectural design,
 where you identify the overall structure of the system.
 Interface design:
 where you define the interfaces between system components.
 Component design:
 where you take each system component and design how it will
operate.
 Database design:
 where you design the system data structures and how these are
to be represented in a database.

60. General Model of The Design Process30

61. Programming and Debugging31
 Translating a design into a program and removing
errors from that program.
 Programmers carry out some program testing to
discover faults in the program and remove these
faults in the debugging process.
 Testing Differ Than Debugging?
 How!!
 Debugging (locating defects and correcting).
 Testing (establish existing of defects).

62. The debugging process Software Engineering Software Processes44
Software Engineering Software Processes
Software Engineering

63. Software Validation system testing.32
 Verification and Validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the customer.
 Involves checking and review processes and
system testing.
 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.
 Validation ensures that ‘you built the right thing’.
 Verification ensures that ‘you built it right’.

64. Defect Distribution in SW Life Cycle
Software Engineering Software Processes
Software Engineering
Software Processes

65. Testing Stages 33

66. Testing stages  Component (Unit) Testing  System Testing34
 Component (Unit) Testing
 Individual components are tested independently;
 Components may be functions or objects or coherent
groupings of these entities.
 System Testing
 System components are integrated to create a complete system.
 Testing of the system as a whole.

67. potential customer who report any problems to the developer.
Testing Stages Cont. 35
 Acceptance Testing
 Testing with customer data to check that the system meets the
customer’s needs.
 Alpha Testing: Continues till the system developer and the
client agree that the system is acceptable.
 Usually applicable for bespoke/Custom systems.
 Beta Testing: Involves delivering a system to a number of
potential customer who report any problems to the developer.
 Usually applicable for generic software.

68. Testing phases in a plan-driven software process
Chapter 2 Software Processes

69. Software Evolution  Software is inherently flexible and can change.36
 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 demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems
are completely new.

70. Software Evolution 37

71. The Rational Unified Process (RUP)38
 A modern process derived from the work on UML and associated Unified Software Development Process.
 UML: Unified Model Language: is an industry standard language allows us to clearly communicate requirements, architectures and designs.
 RUP is a phased model that identifies four discrete phase in a software process.

72. Different Perspectives of RUP39
 RUP normally described from 3 perspectives:
 Dynamic perspective:
Shows phases over time.
 Static perspective
Shows process activities.
 Practice perspective
Suggests good practices to be used.

73. Phases in the Rational Unified Process40

74. Inception Phase 41
 The goal of this phase is to:
 Establish the business case for the system by:
 Identify all external entities with which the system will interact (actors) and define the nature of this interaction.
 Assess the contribution that system makes to the business.
 If this contribution is minor, the project may be cancelled after this phase.

75.  On completion of this phase we should have:
Elaboration Phase 42
 The goals of this phase are to:
 Develop an understanding of the problem domain.
 Establish an architectural framework for the system.
 Develop the project plan and identify the key project risks.
 On completion of this phase we should have:
Requirement model for the system.
Development plan for the software.

76.  On completion of this phase we should have:
Construction Phase 43
 The goals of this phase are to:
 System design, programming and testing.
 Parts of the system are developed in parallel and integrating during this phase.
 On completion of this phase we should have:
Working software system.
Associated documentation.
The system is ready for delivery to the users.

77.  On completion of this phase we should have:
Transition Phase 44
 The final phase is concerned with moving the system from development community to user community and making it work in a real environment.
 This phase is ignored in most models, but it is expensive and sometimes problematic activity.
 On completion of this phase we should have:
Documented software system that is working correctly in its operational environment.

78. SOFTWARE STANDARDS
ISO  International Organization for Standardization
ACM  Association for Computing Machinery
IEEE  Institute of Electrical and Electronics Engineers
DOD  The U.S. Department of Defence

79. Summery a software system. Software process models are abstract48
 Software processes are the activities involved in producing
a software system. Software process models are abstract
representations of these processes.
 General process models describe the organization of
software processes. Examples of these general models
include the ‘waterfall’ model, iterative development, and
reuse-oriented development.
 Processes may be structured for iterative development and
delivery so that changes may be made without disrupting
the system as a whole
Requirements engineering is the process of developing a software specification.

80. Summary transforming a requirements specification into an
 Design and implementation processes are concerned with
transforming a requirements specification into an
executable software system.
 Software validation is the process of checking that the
system conforms to its specification and that it meets the
real needs of the users of the system.
 Software evolution takes place when you change existing
software systems to meet new requirements.
 RUP is a modern generic process model that involves four phases (inception, elaboration, construction and transition).
 CASE tools are software systems which are designed to support routine activities in the software process. 49

81. Thank you End of Chapter 2