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. 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.

4. 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.

5. 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.

6. 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.

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

8. 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.

9. 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.

10. 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.

11. 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

12. 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

13. The process of prototype development
Chapter 2 Software Processes

14. 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

15. 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.

16. 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.

17. 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).

18. 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

19. Incremental development
Chapter 2 Software Processes

20. 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.

21. 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.

22. 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.

23. Spiral Model of The Software Process18

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. Reuse-oriented software engineering
Chapter 2 Software Processes

30. 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.

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

32. 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.

33. Requirements Engineering Process27

34. 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.

35. 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.

36. General Model of The Design Process30

37. 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).

38. 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’.

39. Testing Stages 33

40. 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.

41. 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.

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

43. 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.

44. Software Evolution 37

45. 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.

46. 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.

47. Phases in the Rational Unified Process40

48. 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.

49.  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.

50.  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.

51.  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.

52. CASE (Computer-Aided Software Engineering)45
 CASE tools are software systems which are designed to support routine activities in the software process such as editing design diagrams, checking diagram consistency and keeping track of program tests which have been run.
 Software process activities such as:
 Requirement analysis.
 System Modeling.
 Debugging and Testing.

53. CASE Cont. 46
 All Software engineering method now come with associated CAES such as:
 Editors for the notations used in method.
 Analysis modules which check the system model according to the method rules.
 Report generators to help create system documentation.
 Code Generator
That automatically generate source code from the system model.

54. Classification of CASE Tools47
 CASE tools can be classified into:
 Upper-CASE:
Tools to support the early process activities of requirements and design.
 Lower-CASE:
Tools to support later activities such as programming, debugging and testing.

55. 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.

56. 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

57. Thank you End of Chapter 2