1. Chapter 2
Software Processes

2. Topics covered Software processes and process models Generic models:
Waterfall
Incremental development
Reuse-oriented software engineering
Basic process activities:
Specification
Development
Validation
Evolution
(cont'd)

3. Topics covered (cont’d)
Coping with change
Software prototyping:
Uses of prototypes
Classifying prototypes
User Interface prototyping
Incremental delivery (cf. Incremental development)
Boehm’s spiral model
The Rational Unified Process (an example of a modern software development method)

4. The software process
[struhk-cherd] –adjective; having a clearly defined structure or organization.
A process is a structured set of activities required to develop a software system.
Many different software processes, but all involve:
Specification – defining what the system should do;
Design & implementation;
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing customer needs.
A process model is an abstract representation of a process. It presents a description of a process from some particular perspective
Models should be as simple as possible, but no
simpler. – A. Einstein

5. The software process
[struhk-cherd] –adjective; having a clearly defined structure or organization.
A process is a structured set of activities required to develop a software system.
Many different software processes, but all involve:
Specification – defining what the system should do;
Design & implementation;
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing customer needs.
A process model is an abstract representation of a process. It presents a description of a process from some particular perspective.
Models should be as simple as possible, but no
simpler. – A. Einstein

6. Plan-driven and agile processes
Plan-driven processes: all of the process activities are planned in advance and progress is measured against this plan.
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.

7. Generic software process models
The Waterfall Model – plan-driven model; separate and distinct phases of specification and development. not iterative
Incremental Development – specification, development, & validation are interleaved; may be plan-driven or agile.
Reuse-Based Development – e.g., component-based: the system is assembled from existing components; may be plan-driven or agile.
In practice, most large systems are developed using a process that incorporates elements from all of these models.
(And, at no additional cost: Boehm’s Spiral Model.)

8. Waterfall model (W. Royce)

9. Waterfall model phases
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
The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.
In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work.

10. Waterfall model problems
Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer requirements.
Thus, this model is only appropriate when the requirements are well-understood (to begin with).
Few business systems have stable requirements.
In general, the drawback of the waterfall model is the difficulty of accommodating change after the process is underway.

11. Incremental development

12. Incremental development benefits
Reduces cost of accommodating changing customer requirements - amount of analysis and documentation that has to be re-done is much less than is required with the waterfall model.
Easier to get customer feedback - customers can comment on demonstrations of the software and see how much has been implemented.
More rapid delivery & deployment of useful software to the customer is possible - customers are able to use and gain value from the software earlier than is possible with a waterfall process.

13. Incremental development problems
Lack of process visibility - lack of document deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.
System structure tends to degrade as new increments are added - unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.

14. Reuse-oriented software engineering
Based on systematic (as opposed to serendipitous) reuse - systems are integrated from existing components or COTS (Commercial-Off-The-Shelf) systems.
Process stages
Component analysis (What’s available?)
Requirements modification (Why?)
System design with reuse
Development and integration
“Reuse” is now the standard approach for building many types of business systems.
(cont'd)

15. Reuse-oriented software engineering
(what’s available?)
(cont'd)

16. Types of reusable software components
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.

17. Process activities
Actual software processes are interleaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system.
The four basic process activities of specification, development, validation, and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence; in incremental development they are interleaved.

18. Software specification / RE
The process of establishing what services are required and the constraints on the system’s operation and development.
Requirements Engineering (RE) process:
Feasibility (technical and otherwise) study
Requirements elicitation and analysis
Requirements specification (documentation)
Requirements validation
(cont'd)

19. The requirements engineering process (a waterfall perspective)

20. Software design and implementation
The process of producing an executable system based on the specification
Software design – design a software structure that realizes the specification.
Implementation – translate this structure into an executable program.
But remember: the activities of specification, design, and implementation are closely related and may be interleaved (as with incremental development).

21. Design activities
Architectural design: identify overall structure of system, principal components (sometimes called sub-systems or modules), their relationships, and how they are distributed.
Interface design: define the interfaces between system components.
Component design: design how each system component will operate.
Database design: design the system data structures and how these are to be represented in a database.

22. Software verification & validation
Verification and validation (V&V) determines whether or not a system (1) conforms to its specification and (2) meets the requirements of the customer.
Involves checking processes (e.g., inspections/reviews) and program (machine-based) testing.
Testing is the most commonly used V&V activity and involves executing program elements with test cases that are derived from analyzing specifications and/or program logic.

23. Testing stages Development or component testing System testing
Individual components are tested independently;
“Components” may be functions or objects or coherent groupings of these entities.
System testing
Testing of the system as a whole. Testing of emergent properties is particularly important.
Acceptance testing
Testing with customer data to check that the system meets the customer’s needs.

24. Software evolution (maintenance)
Software is inherently flexible and subject to change.
As requirements change through changing business circumstances, the software that supports the business must also evolve and change.
The distinction between development and evolution is increasingly irrelevant as fewer and fewer systems are completely new.
(cont'd)

25. Software evolution (maintenance)
e.g., change requests

26. Coping with change
Change is inevitable in all large software projects.
Business changes lead to new and changed system requirements.
New technologies open up new possibilities for improving implementations.
Changing platforms require application changes.
Change costs include both re-work (e.g., re- analyzing requirements) and the cost of implementing new functionality.

27. Reducing the costs of re-work
Change avoidance: includes process activities that can anticipate possible changes before significant re-work is required.
For example, a prototype system may be developed to stimulate user/stakeholder anticipation.
Change tolerance: process and/or product is designed so that changes can be accommodated at relatively low cost.
Proposed changes may be implemented in increments that have not yet been developed.
Information hiding techniques may be employed in product design.

28. Software prototyping

29. What is prototyping? An iterative process emphasizing:
Rapid development
Concreteness and evaluative use (a “real system” is developed and presented to real users for hands-on evaluation)
Consideration of alternatives
Feedback
Modification

30. General Prototyping process
What to include & what NOT to include.

31. Uses of prototypes
Principal use is to help customers and developers better understand system requirements.
Experimentation stimulates anticipation of how a system could be used.
Attempting to use functions together to accomplish some task can easily reveal requirements problems.
(cont’d)

32. Uses of prototypes (cont’d)
Other potential uses:
Evaluating proposed solutions for feasibility (Experimental Prototyping)
Develop and evaluate UI designs
“Back-to-back” testing
Training users before system delivery
Prototyping is most often undertaken as a risk reduction activity.

33. Classifying prototypes
By purpose:
Throw-away prototyping – to elicit and validate requirements
Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)

34. Throw-away prototyping
Elicit/validate REQMTS

35. Classifying prototypes
By purpose:
Throw-away prototyping – to elicit and validate requirements
Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)

36. Classifying prototypes
By purpose:
Throw-away prototyping – to elicit and validate requirements
Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)

37. points of comparable effort
Vertical prototype
high
F I d e l I t y
Horizontal prototype
points of comparable effort
low
few
many
Number of features

40. Classifying prototypes
By purpose:
Throw-away prototyping – to elicit and validate requirements
Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)

41. Quin Tech “Self-service check-in and baggage drop-off design”
“The design was tested through a full-scale mock-up.”

42. Electronic circuit on a bread-board (REUK.co.uk)
“There is no need to solder anything, and the components can be moved around and the circuit modified thousands of times without damaging parts.”

43. Classifying prototypes
By purpose:
Throw-away prototyping – to elicit and validate requirements
Experimental prototyping – to evaluate proposed solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)

44. The Turing Test (Alan Turing, 1950)

45. The Wizard of Oz exposed…
“The truth is the Wizard was an illusion created by a man hidden behind a curtain.”

46. Prototyping versus simulation
What’s the difference between prototyping and simulation?

47. Throw-away prototype delivery?
Developers may be “pressurized” to deliver a throw-away prototype as the final system.
This is problematic...
It may be impossible to meet non-functional requirements.
The prototype is almost certainly undocumented.
The system may be poorly structured and therefore difficult to maintain.
Normal organizational quality standards may not have been applied.

48. “Pressurizing” the Developer
No, no, no! I won’t deliver the prototype to you!
User Mgmt
Developer
Air Tank
“Pressurizing” the Developer

49. Implementation techniques
Various techniques may be used to implement prototypes:
Dynamic, high-level languages
Database programming (RAD)
Component and application assembly
These are not mutually exclusive – they are often used together.
Visual programming is also an inherent part of most prototype development systems.

50. User interface prototyping
It is usually impossible to pre-specify the look and feel of a user interface in an effective way. Prototyping is essential.
And UI development consumes an increasing part of overall system development costs.
(cont’d)

51. User interface prototyping (cont’d)
Aim is to allow users to gain direct experience with the interface.
Without this, it is almost impossible to judge usability.
Often a two-stage process:
paper prototypes are developed initially,
followed by a series of increasingly sophisticated automated prototypes.

52. Paper prototyping
Step through scenarios using sketches of the interface.
Use storyboards/scenarios to present a series of interactions with the system.
Paper prototyping is a cost-effective way of obtaining user reactions to an interface design proposal.

53. Incremental delivery

54. (Compromise between Waterfall & Incremental Development)
Incremental delivery
Rather than deliver the system as a single unit, the development and delivery is broken down into increments, each of which incorporates part of the required functionality.
User requirements are prioritized and the highest priority requirements are included in early increments.
Once the development of an increment is started, its requirements are “frozen” while requirements for later increments can continue to evolve.
(Compromise between Waterfall & Incremental Development)
(cont’d)

55. Incremental delivery
(cont'd)

56. Incremental “development” versus incremental “delivery”
Develop the system in increments and make available for evaluation & feedback before proceeding to the development of the next increment;
Normal approach used in agile methods;
Evaluation undertaken by user/customer (or a proxy).
Incremental delivery
Deploy increments for actual work-place use by end-users;
Permits more realistic evaluation of practical usefulness;
Difficult to carry out for replacement systems as increments provide less functionality than the system being replaced.

57. Incremental delivery advantages
Useful functionality is delivered with each increment, so customers derive value early.
Early increments assist in eliciting requirements for later increments.
Lower risk of overall project failure.
The highest priority system services tend to receive the most testing. (They're subject to more “validation” steps.)
(cont'd)

58. Potential problem with incremental delivery
Requirements may NOT be partitionable into stand-alone increments. (e.g., a compiler)
Most systems require a set of basic facilities that are used by different parts of the system. But since requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments.
The essence of an iterative process is that the specification is developed in conjunction with the software. But this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract.

59. Spiral development model

60. Boehm’s spiral development model
Process is represented as a spiral rather than a sequence of activities.
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.
Explicitly incorporates risk assessment and resolution throughout the process.
(cont'd)

61. Boehm’s spiral development model

62. Spiral model quadrants
Objective Setting – specific objectives for the phase are identified. Project risks and alternative strategies 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.

63. Spiral model usage
The model has been very influential in helping people think about iteration in software processes and introducing the risk- driven approach to development.
In practice, however, the model is rarely used as published for practical software development.

64. RUP

65. The Rational Unified Process
A modern process model derived from the work on the UML and its associated process.
A hybrid process model that brings together aspects of the generic process models discussed previously…it represents a new generation of generic processes.
Normally described from 3 perspectives
A dynamic perspective that shows phases over time;
A static perspective that shows process activities;
A practice perspective that suggests good practices.

66. RUP phase model “in-phase iteration” “cross-phase iteration”
cf Waterfall Model: RUP phases are more closely related to business rather than technical concerns.

67. RUP phases Inception Elaboration Construction Transition
Establish the business case for the system.
Elaboration
Develop an understanding of the problem domain and the system architecture.
Construction
System design, programming and testing.
Transition
Deploy the system in its operating environment.

68. Static workflows (process activities) in RUP
Description
Business modelling
The business processes are modelled using business use cases.
Requirements
Actors who interact with the system are identified and use cases are developed to model the system requirements.
Analysis and design
A design model is created and documented using architectural models, component models, object models and sequence models.
Implementation
The components in the system are implemented and structured into implementation sub-systems. Automatic code generation from design models helps accelerate this process.

69. RUP good practices
Develop software iteratively: plan increments based on customer priorities and deliver highest priority increments first.
Manage requirements: explicitly document and keep track of changes.
Use component-based architectures: organize system architecture as a set of reusable components.
(cont'd)

70. RUP good practices (cont’d)
Visually model software: using graphical UML models to present static and dynamic views.
Verify software quality: ensure software meets organizational quality standards.
Control changes to software: using change management system and configuration management tools.

71. Key points
Software processes are the activities involved in producing and evolving a software system. They are represented abstractly by software process models.
Generic models are very general and represent different approaches to development. Examples are the waterfall model, incremental development, and reuse-oriented development.
(cont'd)

72. Key points (cont’d)
Requirements engineering is the process of establishing what services are required and the constraints on the system’s operation and development.
Design and implementation processes produce an executable system based on the specification.
V&V involves checking that the system meets its specification and satisfies user needs.
Evolution is concerned with modifying the system after it is placed in use. Software must evolve to remain useful.
(cont'd)

73. Key points (cont’d)
Processes should include activities to cope with change. This may involve a prototyping phase that helps avoid poor decisions on requirements and design.
Throw-away prototyping is used to explore requirements and design options.
Rapid development of prototypes is essential. This usually requires leaving out functionality or relaxing non-functional constraints.
(cont'd)

74. Key points (cont’d)
Prototyping is essential for parts of the system such as the user interface which cannot be effectively pre-specified.
Users must be involved in prototype evaluation.
The Rational Unified Process is a modern generic process model that is organized into phases (inception, elaboration, construction and transition) but separates activities (requirements, analysis and design, etc.) from these phases.

75. Chapter 2
Software Processes