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

Programming Techniques

Lecture 2 Prescriptive Process Models

Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman

Software Engineering

Fall 2005


Prescriptive Process Models


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.


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.


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.


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;


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.


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


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


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)


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.


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


Waterfall Model

Communication Planning

ModelingConstruction

Deployment analysis design code

test

project initiation requirement gathering estimating

scheduling tracking

delivery support feedback


Waterfall Model Phases

• Requirements analysis and definition

• System and software design

• Implementation and unit testing

• Integration and system testing

• Operation and maintenance


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.


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


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’


The Incremental Model

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t ru c t i o n

De p l o y m e n t

d e l i v e ry f e e d b a c k

analys is

des ign code

t es t

increment # 1

increment # 2

delivery of 1st increment

delivery of 2nd increment

delivery of nth increment

increment # n

project calendar time

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g


De p l o y m e n t

d e l i v e ry

f e e d b a c k

analys is

des ign code

t es t

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g


De p l o y m e n t

d e l i v e ry

f e e d b a c k

analys is

des igncode t es t


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


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.


RAD Model

• ‘High-speed’ adaptation of the waterfall model.

• Makes heavy use of reusable software components with an extremely short development cycle (e.g. 60-90 days).

• Applications which can be modularised into major function to be completed in less than 3 months.


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.


The RAD Model

Communication

Planning

Modelingbusiness modeling data modeling process modeling

Constructioncomponent reuse automatic code generation testing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data modeling process modeling

Constructioncomponent reuse automatic code

generation testing

Modelingbusiness modeling data modeling process modeling

Const ruct ioncomponent reuse automatic code generation testing

Team # 2

Team # n

integration delivery feedback


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


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


Evolutionary Process Models

• Prototyping

• Spiral

• Concurrent Development


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



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



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





• 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



• 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


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


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.



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.



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



communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis



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



• 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’



• 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


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


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.


Evolutionary Models: Concurrent

Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling activity

represents the stateof a software engineeringactivity or task


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.


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.



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



• Component-Based Development

• Formal Methods Model

• Aspect-Oriented Programming


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.


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.


Component-Based Development

• 70% reduction in development cycle time

• 84% reduction in project cost

• Productivity increase


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.


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.


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


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)


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


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?


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.


Unified Process Phases

• Inception

• Elaboration

• Construction

• Transition

• Production


Unified Process Phases

software increment

Release

Inception

Elaboration

construction

transition

production


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


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.


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.


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.


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.


UP Phases

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support


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.


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.


UP Work Products

Inception phase

Elaboration phase

Construction phase

Transition phase

Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n

Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Descript ion. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals descript ion of current increment

Delivered software increment Beta test reports General user feedback


UP Good Practice

• Develop software iteratively

• Manage requirements

• Use component-based architectures

• Visually model software

• Verify software quality

• Control changes to software


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


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


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)


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 .


2005F

Instructor

John D Lin - [email protected]

Lectures

Tues & Thurs 10:00-11:30 RM. 100, Lower Block

Documents

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