1. Software Engineering
The Software Process

2. Why Software Engineering?
Can you approach building software as building a bridge? Why? Why not?
How is software engineering like other engineering disciplines?

3. Software Process
A structured set of activities required to develop a software system.
Fundamental Assumption:
Good processes lead to good software
Good processes reduce risk

4. What can go wrong in a software project? How can the risk be reduced?
Risk Management
What can go wrong in a software project?
How can the risk be reduced?

5. The software process
Many different software processes but all involve:
Specification: defining what the system should do;
Design and implementation: defining the organization of the system and implementing it
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing customer needs.

7. Software Process Models
A software process model is an abstract representation of a process.
The waterfall model
Separate and distinct phases of specification and development (product focused)
Evolutionary development
Specification, development and validation are interleaved e.g. XP (Beck), increment driven
Component-based software engineering
The system is assembled from existing components.
Spiral (Boehm)
driven by risk analysis and mitigation

8. Background on software process models
1950 ：Code-and-fix model
1956 ： Stagewise model (Bengington )
1970 ： Waterfall model (Royce)
1971 ： Incremental model(Mills)
1977 ： Prototyping model(Bally and others)
1988 ： Spiral model(Boehm)

9. Use of the Models in Practice

10. The Waterfall Model Requirements Definition System and Software design
Programming
and Unit Testing
Integration and
System Testing
Operation and
Maintenance

11. Waterfall Model material adapted from Steve Easterbrook
requirements
design
code
integrate
test
perceived
need
View of development:
A process of stepwise refinement
High-level management view
Problems:
Static view of requirements (ignores volatility)
Lack of user involvement once spec is written
Unrealistic separation of spec from design
Doesn’t accommodate prototyping, reuse

12. The Waterfall Model Requirements Definition System and Software design
Programming
and Unit Testing
Integration and
System Testing
Operation and
Maintenance

13. [1] Requirements Analysis and Definition
The system's services, constraints and goals are established by consultation with system users. They are then defined in a manner that is understandable by both users and development staff.
This phase can be divided into:
 Feasibility study (often carried out separately)
 Requirements analysis
 Requirements definition
 Requirements specification

14. Terminology
A requirement is a technical objective which is imposed upon the software, i.e., anything that might affect the kind of software that is produced
A requirement may be imposed by
the customer
the developer
the operating environment
The requirement must be documented
Requirements fall into two broad categories
functional
non-functional

15. Functional Requirements
Functional requirements are concerned with what the software must do
capabilities, services, or operations
Functional requirements are not concerned with how the software does things, i.e., they must be free of design considerations

16. Non-Functional Requirements
Non-functional requirements place restrictions on the range of acceptable solutions
Non-functional requirements cover a broad range of issues
interface constraints
performance constraints
operating constraints
life-cycle constraints
economic constraints
political constraints
manufacturing

17. Case Study
We participated in a group project where we designed and developed a cell phone game suitable for a cell phone using the programming language Java 2 Micro Edition.
We designed everything from the beginning with no game requirements given to us.
The process consists of defining system requirements, building the system, and testing the system. The goal of the project was to have a working game. We were restricted by time since this was a summer program

18. Define System Requirements
The system is designed to make the primary persona happy but the other personas should not be unhappy
Define user scenarios
User scenarios describe how someone will interact with the system.
This includes actual scenarios that could happen to a person while playing through the game.

19. Define System Requirements
Describe the user interface
Describe main interface that the user will interact with.
This includes screen interactions and all options the user will have.
Detailed requirements
Includes all functional, nonfunctional, and constraint requirements that the system must satisfy

20. The Waterfall Model Requirements Definition System and Software design
Programming
and Unit Testing
Integration and
System Testing
Operation and
Maintenance

21. [2] System and Software Design
System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture
Software design: Represent the software system functions in a form that can be transformed into one or more executable programs
 Unified Modeling Language (UML)

22. Case Study
We participated in a group project where we designed and developed a cell phone game suitable for a cell phone using the programming language Java 2 Micro Edition.
We designed everything from the beginning with no game requirements given to us.
The process consists of defining system requirements, building the system, and testing the system. The goal of the project was to have a working game. We were restricted by time since this was a summer program

23. Build System Define the system classes
Classes are derived from the nouns in the user scenarios.
Every system activity or primitive function should reside in a class
Define system sequence diagrams
Sequence diagrams show how the classes work together to execute each use-case function

24. Build System

25. [3] Programming and Unit Testing
The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified.)
Individual components are tested against specifications.

26. All coding takes place here.
Build System
Implement the system
The class skeletons are coded based on the code generated from the class diagrams.
All coding takes place here.

27. The Waterfall Model Requirements Definition System and Software design
Programming
and Unit Testing
Integration and
System Testing
Operation and
Maintenance

28. [4] Integration and System Testing
The individual program units are:
 integrated and tested as a complete system
 tested against the requirements as specified
 delivered to the client

29. The Waterfall Model Requirements Definition System and Software design
Programming
and Unit Testing
Integration and
System Testing
Operation and
Maintenance

30. [5] Operation and Maintenance
 Operation: The system is put into practical use.
Maintenance: Errors and problems are identified and fixed.
 Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment.
 Phase out: The system is withdrawn from service.

31. Discussion of the Waterfall Model
Advantages:
 Process visibility
 Dependence on individuals
 Quality control
 Cost control

32. The Classical Software Lifecycle
The classical software lifecycle models the software development as a step-by-step “waterfall” between the various development phases.
Requirements
Collection
Analysis
Design
Implementation
Testing
Maintenance
The waterfall model is unrealistic for many reasons:
requirements must be frozen too early in the life-cycle
requirements are validated too late

33. Problems with the Waterfall Lifecycle
“Real projects rarely follow the sequential flow that the model proposes. Iteration always occurs and creates problems in the application of the paradigm”
“It is often difficult for the customer to state all requirements explicitly. The classic life cycle requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects.”
Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised.
NB: Early prototyping helps to alleviate the 2nd and 3d problems.

34. Cons Not a good model for complex and object-oriented projects.
High amounts of risk and uncertainty.
Not suitable for the projects where requirements are at a moderate to high risk of changing. So risk and uncertainty is high with this process model.

35. Problem Case Study
Publisher of books want to develop a product that will carry out all the accounting functions of the company and provide online information to the head office staff regarding orders and inventory
Terminals are required for 15 accounting clerks, 32 order clerks, and 15 managers need access to the data. The publisher will pay and wants the complete product in 4 weeks
What do you tell him?

36. Case Study: Sensor Display
Consider a small system that displays the status of several sensors (e.g., pressure, temperature, rate of change, etc.) on a limited-size screen
What are some of its functional requirements?
What are some of its non-functional requirements?
Examine the issue of system boundaries.
- two pressure sensors
- two temperature sensors
- one six character display
Investigate the requirements/design separation.
- display layout
- how often do we read the sensors
- how do we debounce values
Contrast several levels of abstraction for the requirements.
- display all important parameters in a meaningful way
» min/max pressure and temperature over the last minute
» average the readings for each sensor pair (before or after computing the min/max?))
» discard unreasonable readings (what criterion?)
» compute rate of change (over what interval?)
- display all parameters in order for 2 seconds each using specific formats
Investigate the issue of models and analysis
- new requirement: display out of range values
» instantaneous (corrected) average
- error conditions need to be handled differently
» new mode of operation (attention) is needed to show the error condition
» there may be more than one (table of priorities)
» the condition may go away (hold it anyway)
» how can one see lower priority error conditions or current status (add reset button—interface change)
- investigate mode transitions (normal and attention)
» being in attention mode does not mean that an error condition is present
Examine the potential implications of a variety of possible constraints.
Size, cost, power, environmental conditions.
Political considerations (e.g., export restrictions).
Human factors (e.g., blind employees).
Sensor capabilities (e.g., reading frequency, accuracy, reliability).

37. Iterative Development
In practice, development is always iterative, and all activities progress in parallel.
Requirements
Testing based on requirements
Collection
Testing
Maintenance through iteration
Analysis
Testing throughout implementation
Validation through prototyping
If the waterfall model is pure fiction, why is it still the dominant software process?
Implementation
Design
Design through refactoring

38. Iterative Refinement Requirements Evaluation Implementation
(prototype)
Design

39. Phased Models material adapted from Steve Easterbrook
design
code
test
integrate
O&M
reqts
Requirements
version 1
version 2
version 3
Release 1
release 2
release 3
release 4
lessons learnt
Incremental development
(each release adds more functionality)
Evolutionary development
(each version incorporates new requirements)

40. Incremental Development
Plan to incrementally develop (i.e., prototype) the system.
If possible, always have a running version of the system, even if most functionality is yet to be implemented.
Integrate new functionality as soon as possible.
Validate incremental versions against user requirements.

41. Incremental development

46. Incremental delivery
Rather than deliver the system as a single delivery, the 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.
It is easier to get customer feedback on the development work that has been done.

47. Incremental development advantages
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.
The cost of accommodating changing customer requirements is reduced.

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

49. Evolutionary Process Model

51. Evolutionary New versions implement new and evolving requirements
Design
Coding
Test
Deployment
Requirements
Version 2
Design
Coding
Test
Deployment
Requirements
Version 3
Feedback
Design
Coding
Test
Deployment
Requirements
New versions implement new and evolving requirements
(Some call it iterative)

52. Evolutionary development
Problems
Lack of process visibility;
Systems are often poorly structured;
Special skills (e.g. in languages for rapid prototyping) may be required.
Applicability
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.

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

54. Spiral Model material adapted from Steve Easterbrook
Determine goals,
alternatives,
constraints
Evaluate
alternatives
and risks
Plan
Develop
and
test
budget1
budget2
budget3
budget4
prototype1
prototype2
prototype3
prototype4
alternatives4
alternatives3
Altern-
atives2
constraints4
constraints3
Constr-
aints2
risk analysis4
risk analysis3
risk
analysis2
analysis1
concept of
operation
software
requirements
validated
design
validated,
verified design
detailed
code
unit
system
acceptance
requirements,
lifecycle plan
development plan
integration and test plan
implementation plan

55. Details of the Spiral

56. Boehm’s Spiral Lifecycle
Planning =
determination
Risk Analysis =
Analysis of
of objectives, alternatives
alternatives and identification/
and constraints
resolution of risks
Risk =
something that
will delay project or
initial requirements
increase its cost
go, no-go decision
completion
first prototype
alpha demo
Customer Evaluation =
Engineering =
Assessment of the
Development of the
results of engineering
evolving system
next level product

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

58. The spiral model The Risk Management Plan
Identify the project’s top 10 risk items.
Present a plan for resolving each risk item.
Update list of top risk items, plan, and results monthly.
Highlight risk-item status in monthly project reviews.
Compare with previous month’s rankings, status.
Initiate appropriate corrective actions.

59. Spiral Model Advantages
Focuses attention on reuse options.
Focuses attention on early error elimination.
Puts quality objectives up front.
Integrates development and maintenance.
Provides a framework for hardware/software development.

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

61. V Model material adapted from Steve Easterbrook
system
requirements
software
preliminary
design
detailed
code and
debug
unit
test
component
integration
acceptance
“analyze and design”
“test
and integrate”
time
Level of abstraction

62. V Model V- model means Verification and Validation model.
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes.
Each phase must be completed before the next phase begins.  
Testing of the product is planned in parallel with a corresponding phase of development.

64. V Model
Requirements begin the life cycle model just like the waterfall model.
But, in this model before development is started, a system test plan is created. 
The test plan focuses on meeting the functionality specified in the requirements gathering.

65. Build and Fix Model Advantage Disadvantage
Appropriate for small programs written by one person
Disadvantage
Understandability and maintainability decrease rapidly with increasing program size
Totally unsatisfactory
Need a life-cycle model
“Game plan”
Phases
Milestones

66. Case Study Test System
The final phase in the process was to test the system.
We ran visual acceptance tests by running the program and playing through the game.
This proved helpful in ensuring that the game is error free, not necessarily that the system is error free.

67. Children hospital Case study
Care for children in the Alexandria city and some Arab countries
The average length of stay of inpatients is 3.6 days
All patients are accompanied by a parent for the entire duration of their stay at hospital

68. Case Study
We participated in a group project where we designed and developed a cell phone game suitable for a cell phone using the programming language Java 2 Micro Edition.
We designed everything from the beginning with no game requirements given to us.
The process consists of defining system requirements, building the system, and testing the system. The goal of the project was to have a working game. We were restricted by time since this was a summer program

69. Bank example Requirements
Open an account for a customer (savings or chequing)
Deposit ƒ
Withdraw ƒ
Display details of an account ƒ
Change LOC ƒ
Produce monthly statements ƒ
Print a list of customers
Ambiguities
What is the difference between savings and chequing?

71. Design of Bank – Identify Classes
TELLER ƒ
CUSTOMER ƒ
SAVINGS_ACCOUNT ƒ
CHEQUING_ACCOUNT ƒ
MAIN_MENU ƒ
BALANCE_INQUIRY ƒ
INTEREST_RATE