1. Software Engineering Fall 2005
Lecture 2 Prescriptive Process Models Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman
Software Engineering
Fall 2005

2. Prescriptive Process Models
We called them ‘prescriptive’ because they prescribe a set of process elements- framework activities, software engineering actions, tasks, work products, quality assurance and change control mechanisms for each project.
Each process model also prescribes a workflow- that is, the manner in which the process elements are interrelated to one another.

3. Prescriptive Process Models
We called them ‘prescriptive’ because they prescribe a set of process elements - framework activities, software engineering actions, tasks, work products, quality assurance and change control mechanisms for each project.
Each process model also prescribes a workflow- that is, the manner in which the process elements are interrelated to one another.

4. Prescriptive Models
Prescriptive process models advocate an orderly approach to software engineering.
They brought order to software engineering work and provide reasonable guidance to software teams.
They have not provided a definitive answer to the problems of software development in an ever changing computing environment.

5. Prescriptive Models
Prescribe a distinct set of activities, actions, tasks, milestones, and work products required to engineer high quality software.
Adapted to meet the needs of software engineers and managers for a specific project.
Provide stability, control, and organization to a process that if not managed can easily get out of control.
Framework activities for a particular process model may be organized into a process flow that may be linear, incremental, or evolutionary.
The software engineer's work products (programs, documentation, data) are produced as a consequence of the activities defined by the software process.
The best indicators of how well a software process has worked are the quality, timeliness, and long-term viability of the resulting software product.

6. Software Processes
Every software engineering organization needs to describe a set of framework activities for the processes it adopts;
Each framework activity needs to be populated with software engineering actions;
Each engineering action needs to be defined in terms of a task set that defines the work and work products needed to meet the development goals;

7. Software Processes
The resulting process model should be adapted to accommodate the nature of the specific project, people doing the work, and the work environment;
Regardless of the process model selected, software engineers will chose a generic process framework that includes these activities:
- communication,
- planning,
- modeling,
- construction, and
- deployment.

8. Software Processes Each process model will prescribe:
- a set of process elements (framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms), and
- a workflow (the manner in which the process elements are interrelated).

9. Generic software process models
The Waterfall Model - separate and distinct phases of specification and development;
Incremental Models:
- Incremental Model
- Rapid Application and Development (RAD) Model
Evolutionary Process Models - specification, development and validation are interleaved:
Prototyping Model
Spiral Model
Concurrent Development
Software Process Models:
Waterfall Model (old fashioned but reasonable approach when requirements are well understood)
Incremental Models
- Incremental Model (delivers software in small but usable pieces, each piece builds on pieces already delivered)
- Rapid Application and Development (RAD) Model (makes heavy use of reusable software components with an extremely short development cycle)
Evolutionary Process Models
- Prototyping Model (good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product)
- Spiral Model (couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model)
- Concurrent Development Model (similar to spiral model often used in development of client/server applications)
There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design.

10. Specialized Process Models
Component-Based Development - the process to apply when reuse is a development objective;
Formal Methods Model - emphasizes the mathematical specification of requirements;
Aspect-Oriented Programming (AOSD) - provides a process and methodological approach for defining, specifying, designing, and constructing aspects;
Unified Process - a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)
Specialized Process Models
- Component-Based Development (spiral model variation in which applications are built from prepackaged software components called classes)
- Formal Methods Model (rigorous mathematical notation used to specify, design, and verify computer-based systems)
- Aspect-Oriented Programming (provides a process for defining, specifying, designing, and constructing software aspects like user interfaces, security, and memory management that impact many parts of the system being developed)
- Unified Process (Use-case driven, architecture centric, iterative, and incremental software process
Attempts to draw on best features of traditional software process models and implements many features of agile software development

11. Waterfall Model Classic Life Cycle
Suggest a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction and deployment, culminating in on-going support of the completed software.

12. Waterfall Model When to choose it?
When requirements are well understood.
When work flows from communication through deployment in a reasonably linear fashion.
In situations when well-defined adaptations or enhancements to an existing system must be made
E.g., an adaptation to accounting software that has been mandated because of changes to government regulations.

13. Waterfall Model

14. Waterfall Model Phases
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance

15. Waterfall Model Problems
Difficulty of accommodating change after the process is underway
Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

16. Incremental Model When to choose it?
Requirements reasonably well-defined
Overall scope of the development effort precludes a purely linear effort.
Limited set of software functionality needed quickly

17. Incremental Model
Delivers software in small but usable pieces, each piece builds on pieces already delivered
Combines elements of the waterfall model applied in an iterative fashion.
Applies linear sequences in a staggered fashion as calendar time progresses – producing deliverable ‘increments’

18. The Incremental Model

19. Incremental Model
Useful when staffing is unavailable for a complete implementation by the business deadline.
Early increments can be implemented with fewer people. Additional staff (if required) cab be added for the next increment.
Increments can be planned to manage technical risks (e.g. new hardware required – not yet available).

20. The RAD Model When to choose it?
If a business application can be modularised in a way that enables each major function to be completed in less than three months, it is a candidate for RAD.
Each major function can be addressed by a separate RAD team and then integrated to form a whole.

21. RAD Model ‘High-speed’ adaptation of the waterfall model.
Makes heavy use of reusable software components with an extremely short development cycle (e.g days).
Applications which can be modularised into major function to be completed in less than 3 months.

22. RAD Model Generic framework activities:
Communication – to understand the business problem and the information characteristics that the software must accommodate.
Planning is essential – enables multiple software teams to work in parallel.
Modelling: business, data and process modeling – establishes design representation which is a base for construction activity.
Construction – emphasises the use of pre-existing software components.
Deployment – establishes a basis for subsequent iterations.

23. The RAD Model

24. RAD Drawbacks
For large, but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams.
If a system can not be properly modularised, building the components necessary for RAD will be problematic.
If high performance is an issue, and performance is to be achieved through the interfaces to system components.
May not be appropriate when technical risks are high (e.g. when a new application makes heavy use of new technology).

25. Evolutionary Process Models
Software evolves over a period of time
In some situations, a set of core product or system requirements is well understood, but the details of product or system extensions have yet to be defined.
Evolutionary process models are designed to accommodate a product that evolves over time
Iterative – help to develop increasingly more complete versions of the software

26. Evolutionary Process Models
Prototyping
Spiral
Concurrent Development

27. Evolutionary Models: Prototyping
When to choose it?
A customer defines a set of general objectives for software, but does not identify detailed input, processing or output requirements.
The developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the HCI

28. Evolutionary Models: Prototyping
Can be used as a standalone process model
More commonly used as a technique that can be implemented within the context of any one of the prescriptive process models
Good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product.

29. Evolutionary Models: Prototyping
When to choose it?
General objectives of software defined but not detailed input, processing or output requirements
The developer unsure of the efficiency of an algorithm, the adaptability of an operating system, or the HCI

30. Evolutionary Models: Prototyping

31. Evolutionary Models: Prototyping
Gather requirements
Developer & customer define overall objectives, identify areas needing more investigation – risky requirements
Quick design focusing on what will be visible to user – input & output formats
Use existing program fragments, program generators to throw together working version
Prototype evaluated and requirements refined

32. Evolutionary Models: Prototyping
Process iterated until customer & developer satisfied
Then throw away prototype and rebuild system to high quality
Alternatively, can have evolutionary prototyping – start with well understood requirements

33. Prototyping Drawbacks
Customer may want to hang onto first version, may want a few fixes rather than rebuild
First version will have compromises.
Developer may make implementation compromises to get prototype working quickly. Later on developer may become comfortable with compromises and forget why they are inappropriate

34. Evolutionary Models: The Spiral
Couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model.
Software is developed in a series of evolutionary releases.
Early iterations - the release might be a paper model prototype
Later iterations – more complete versions of the engineered system are produced.
Risk–driven process model that is used to guide multi-stakeholder concurrent engineering of software intensive systems.

35. Evolutionary Models: The Spiral
Main features:
Cyclic Approach – incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk.
Anchor Point Milestones – for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.

36. Evolutionary Models: The Spiral
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.
Allows for the fact that some software evolves.
On each iteration, plans, costs, risks and schedules updated and project manager get more accurate estimate of number of required iterations.

37. Evolutionary Models: The Spiral

38. Evolutionary Models: The Spiral
Each of the framework activities represents one segment of the spiral path
The software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center
Anchor point milestones – a combination of work products and conditions that are attained along the path of spiral – are noted for each evolutionary pass.
As workflow moves outward along the spiral, the software moves closer to completion.

39. Evolutionary Models: The Spiral
Can be adapted to apply throughout the life of the computer software.
The first circuit around spiral might represent a ‘concept development project’.
If the concept is to be developed into an actual product, the process proceeds outward on the spiral and a ‘new product development project’ commences.
Later, a circuit around the spiral might be used to represent a ‘product enhancement project’

40. Evolutionary Models: The Spiral
It is a realistic approach to the development of large scale systems and software.
As software evolves as the process progresses, the developer and customer better understand and react to each evolutionary level.
It uses prototyping as a risk reduction mechanism

41. The Spiral Model Drawbacks
It may be difficult to convince customer that the evolutionary approach is controllable
It demands considerable risk assessment expertise and relies on this expertise for success

42. Evolutionary Models :Concurrent
Also called – concurrent engineering
Similar to spiral model
Often used in development of client/server applications
Can be represented as a series of framework activities, software engineering tasks and their associated states.

43. Evolutionary Models: Concurrent

44. Evolutionary Models :Concurrent
All framework activities exist concurrently but reside in different states.
For example, early in project the communication activity has completed its first iteration and exists in the awaiting changes state.
The modeling activity, which existed in the none state while initial communication was completed, now makes transition into the under development state.
If customer indicates that changes in requirements must be made, the modeling activity moves from the under development state into the awaiting changes state.
Events generated at one point in the process network trigger transitions among the states.

45. Evolutionary Processes - Weaknesses
Prototyping poses a problem to project planning because of the uncertain number of cycles required to construct the product.
They do not establish the maximum speed of the evolution: too fast – chaos; too slow – productivity affected.
Extending the development in order to reach high quality could result in late delivery, when the opportunity niche has disappeared.

46. Specialized Process Models
Tend to be applied when a narrowly defined software engineering approach is chosen
Collection of techniques or a methodology for accomplishing a specific software development goal.

47. Specialized Process Models
Component-Based Development
Formal Methods Model
Aspect-Oriented Programming

48. Component-Based Development (CBD)
Object-based technologies provide the technical framework for component-based software (CBD) engineering.
The CBD model incorporates many of the iterative characteristics of the spiral model.
The main difference is that in CBD the emphasis is on composing solutions from prepackaged software components or classes.
CBD emphasizes software reusability.
The unified software development process is an example of CBD that has been proposed for industrial use. The unified modeling language (UML) is used to define the components and interfaces used in the unified software development process.

49. CBD Steps
Available component-based products are researched and evaluated for the application domain in question.
Component integration issues are considered.
A software architecture is designed to accommodate the components.
Components are integrated into the architecture.
Comprehensive testing is conducted to ensure proper functionality.

50. Component-Based Development
70% reduction in development cycle time
84% reduction in project cost
Productivity increase

51. Formal Methods Model
Formal methods in software development require the use of rigorous mathematical notation to specify, design, and verify computer-based systems.
Mathematical proof is used to verify the correctness of a system (not empirical testing).
Cleanroom software engineering is an example of this approach. It emphasizes error detection before testing
While formal methods have the potential to produce defect-free software, the development of formal models is both time-consuming and expensive.

52. Aspect-Oriented Software Development
Provides a process for defining, specifying, designing, and constructing software aspects like user interfaces, security, and memory management that impact many parts of the system being developed.

53. Unified Process (UP)
Also called Rational Unified Process (RUP), after the Rational Corporation, a primary contributor to the development and refinement of the process and a builder of complete environments (tools and technology) that support the process.
A framework for object-oriented software engineering using UML

54. Unified Process
Use-case driven, architecture centric, iterative, and incremental software process
Attempts to draw on best features of traditional software process models and implements many features of agile software development
Recognises the importance of customer communication and streamlined methods for describing the customer’s view of a system (i.e. the use-case)

55. Use-Cases
Each use-case tells stylized story about how end-users interact with the system under a specific set of circumstances
A collection of user scenarios that describe the thread of usage of a system
A use-case depicts the software or system from the end user’s point of view
Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way

56. Use-Case Scenarios Each scenario answers the following questions:
Who is the primary actor, the secondary actor (s)?
What are the actor’s goals?
What preconditions should exist before the story begins?
What main tasks or functions are performed by the actor?
What extensions might be considered as the story is described?
What variations in the actor’s interaction are possible?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?

57. Use-case Drawbacks Lack of formality in use-case descriptions
Not all systems have explicitly defined actors
Use-cases are not inherently object-oriented
Developers have a tendency to functionally decompose use-cases.

58. Unified Process Phases
Inception
Elaboration
Construction
Transition
Production

59. Unified Process Phases

60. UP Phases - Inception
The emergence of a good idea: specifying the end-product vision and its business case
A plan for the iterative, incremental nature of the ensuing project is developed
Fundamental business requirements are described through a set of preliminary use-cases that describe what features and functions are desired by each major class of users
Use-cases help to identify the scope of the project and provide a basis for project planning

61. UP Phases - Elaboration
Planning the necessary activities and required resources
Specifying the features and designing the architecture.
Identifies significant risks
Refines and expands the preliminary use-cases that were developed as part of the inception phase.
Expands the architectural representation to include five different views of the software: the use-case, the analysis, the design, the implementation and the deployment model.
Creates an ‘executable architectural baseline’ – a ‘first cut’ executable system.

62. UP Phases - Construction
Building the product and evolving the vision, the architecture, and the plans until the product--the completed vision--is ready for transfer to its users' community.
Main iterative spiral is placed here.
As components are being implemented, unit tests are designed and executed for each.
Use-cases are used to derive a suite of acceptance tests that are executed prior to the initiation of the next UP phase.

63. UP Phases - Transition
Making the transition from the product to its user's community, which includes: manufacturing, delivering, training, supporting, maintaining the product until the users are satisfied.

64. UP Phases - Production
Coincides with the deployment activity of the generic process.
The on-going use of the software is monitored, support for the infrastructure is provided and defect reports and requests for changes are submitted and evaluated.

65. UP Phases

66. UP Phases The process can be described along two axis:
The horizontal axis represents time and shows the dynamic aspect of the software development process as it is enacted, and it is expressed in terms of cycles, phases, iterations, and milestones.
The vertical axis represents the static aspect of the development process: how it is described in terms of activities, artefacts, workers and workflow.
Unified Process takes risk analysis as a central concept. Uses iteration as a means of controlling risk. Iteration management requires refinement, course planning early with fine grain planning through the iterations, not all upfront planning, issues of iteration size and completeness.

67. UP Phases
At the same time the construction, transition and production phases are being conducted, work may have already begun on the next software increment.
Phases occur with staggered concurrency.

68. UP Work Products Unified Process Work Products: 1) Inception phase
Vision document
Initial use-case model
Initial project glossary
Initial business case
Initial risk assessment
Project plan (phases and iterations)
Business model
Prototypes
2) Elaboration phase
Use-case model
Functional and non-functional requirements
Analysis model
Software architecture description
Executable architectural prototype
Preliminary design model
Revise risk list
Project plan (iteration plan, workflow, milestones)
Preliminary user manual
3) Construction phase
Design model
Software components
Integrated software increment
Test plan
Test cases
Support documentation (user, installation, increment)
4) Transition phase
Delivered software increment
Beta test reports
User feedback

69. UP Good Practice Develop software iteratively Manage requirements
Use component-based architectures
Visually model software
Verify software quality
Control changes to software

70. UP Work Products - Inception Phase
Vision document
Initial use-case model – the most important, from the software engineer’s point of view.
Initial project glossary
Initial business case
Initial risk assessment
Project plan (phases and iterations)
Business model
Prototypes

71. UP Work Products - Elaboration Phase
Use-case model
Functional and non-functional requirements
Analysis model
Software architecture description
Executable architectural prototype
Preliminary design model
Revise risk list
Project plan (iteration plan, workflow, milestones)
Preliminary user manual

72. UP Work Products - Construction Phase
Produces an implementation model that translates design classes into software components that will be built to realise the system.
Software components
Integrated software increment
Test plan and procedure
Test cases
Support documentation (user manuals, installation manuals, description of current increment)

73. Prescriptive software process models
Have been applied for many years in order to bring order and structure to software development.
Each suggest somewhat different process flow, but all perform the same set of generic framework activities: communication, planning, modeling, construction and deployment.
Brought order to software engineering work and provide reasonable guidance to software teams.
Yet, they have not provided a definitive answer to the problems of software development in an ever changing computing environment .

74. 2005F Instructor John D Lin - johndlin@hotlinemail.com Lectures
Tues & Thurs 10:00-11:30 RM. 100, Lower Block