1. The Software Process (2)
Software Engineering
The Software Process (2)

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

3. Incremental development

4. Evolutionary Process Model

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

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

7. Details of the Spiral

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

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

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

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

12. Prototyping Model material adapted from Steve Easterbrook
Prototyping is used for:
Understanding the requirements for the user interface
Examining feasibility of a proposed design approach
Exploring system performance issues
Problems
Users treat the prototype as the solution
A prototype is only a partial specification

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

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

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

17. Agile Model (XP) material adapted from Steve Easterbrook

19. Agile Software Development
Agile software development is a group of software development methods type of iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
It is used for time critical applications

20. Agile Software Development
Agile Methods break the product into small incremental builds. Each iteration typically lasts from about one to three weeks
Every iteration involves cross functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing, and acceptance testing.
At the end of the iteration a working product is displayed to the customer and important stakeholders.

21. Agile Software Development
It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.

23. What is Agility? Effective response to change
Effective communication among all stakeholders
Drawing the customer onto the team; eliminate the “us and them” attitude
Organizing a team so that it is in control of the work performed
Rapid, incremental delivery of software

24. The Agile Principles
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.

25. The Agile Principles
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

26. The Agile Principles
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

27. Agile Process Models Extreme Programming (XP)
Adaptive Software Development (ASD)
Dynamic Systems Development Method (DSDM)
Scrum
Crystal
Feature Driven Development (FDD)
Agile Modeling (AM)

28. Extreme programming
Perhaps the best-known and most widely used agile method.
Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.
New versions may be built several times per day;
Increments are delivered to customers every 2 weeks;
All tests must be run for every build and the build is only accepted if tests run successfully.

29. Extreme Programming (XP)
XP uses an object-oriented approach as its preferred development paradigm
Defines four (4) framework activities
Planning
Design
Coding
Testing

31. Extreme Programming (XP) - 2
spike solutions prototypes
simple design CRC cards
user stories values acceptance test criteria iteration plan
design
planning
coding
refactoring
test
pair programming
Release
unit test continuous integration
software increment project velocity computed
acceptance testing

32. XP - Planning
Begins with the creation of a set of stories (also called user stories)
Each story is placed on an index card
The customer assigns a value (i.e. a priority) to the story
Agile team assesses each story and assigns a cost
Stories are grouped to for a deliverable increment
A commitment is made on delivery date
After the first increment “project velocity” is used to help define subsequent delivery dates for other increments

33. Testing in XP
Testing is central to XP and XP has developed an approach where the program is tested after every change has been made.
XP testing features:
Test-first development.
Incremental test development from scenarios.
User involvement in test development and validation.
Automated test harnesses are used to run all component tests each time that a new release is built.

34. XP - Testing
Unit tests should be implemented using a framework to make testing automated. This encourages a regression testing strategy.
Integration and validation testing can occur on a daily basis
Acceptance tests, also called customer tests, are specified by the customer and executed to assess customer visible functionality
Acceptance tests are derived from user stories

35. Reuse-oriented software engineering
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.
Reuse is now the standard approach for building many types of business system

36. Types of software component
Web services that are developed according to service standards and which are available for remote invocation.
Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.
Stand-alone software systems (COTS) that are configured for use in a particular environment.

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

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

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

40. ATM system