Lecture
Topics are: -4
Process Models
The Unified Process
Process Models
(Prescriptive Models /
Prescriptive Process
What is it? Model)
Process models define a distinct set of activities, actions, tasks, milestones and
work products that are required to engineer high-quality software.
Who does it?
Software engineers and their managers adopt a process model to their needs and
then follow it.
Why is it important?
Because it provides stability, control and organization to an activity.
Prescriptive
Models
“There are many ways of going forward, but only one way of standing still”
Today more prescriptive software development models exist.
A software engineer have to choose one model for his work.
Each prescriptive model can accommodate generic process framework that
encompasses communication, planning, modeling, construction and
deployment.
Why the model is
called
prescriptive?
The model prescribes a set of process elements – software engineering actions,
tasks, work products, quality assurance, and change control mechanisms for
each project.
Each model prescribes a workflow.
Though generic process framework is the major idea behind, each model applies
a different style to those activities and defines a workflow.
Communication -> Planning -> Modeling -> Construction -> Deployment
The Waterfall
Model
Sometimes called the classic life cycle, suggests a systematic sequential approach
to software development that begins with customer requirements and progress
through Communication -> Planning -> Modeling -> Construction ->
Deployment.
It is a successful and oldest model for software engineering. However criticism
on this process model has caused even supporters to question its efficacy.
The Waterfall
Model
Although the original waterfall model proposed by Winston Royce made provision for
“feedback loops,” the vast majority of organizations that apply this process model treat
it as if it were strictly linear.
Problems in the
Waterfall Model
[Link] projects rarely follow the sequential flow that the model
proposes. Although the linear model can accommodate iteration, it does so
indirectly. As a result, changes can cause confusion as the project team
proceeds.
[Link] is often difficult for the customer to state all requirements explicitly.
The waterfall model requires this and has difficulty accommodating the
natural uncertainty that exists at the beginning of many projects.
3. The customer must have patience. A working version of the program(s)
will
A variation in the Waterfall
Model (V-Model)
A variation in the representation of the waterfall model is called
the V-model.
V-model depicts the relationship of quality assurance actions to the actions
associated with communication, modeling, and early construction activities.
A variation in the Waterfall
Model (V-Model)
As a software team moves down the left side of the V, basic problem
and
requirements are refined into progressively more detailed technical
representations of the problem and its solution.
Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests (quality assurance actions) that validate
each of the models created as the team moved down the left side.
In reality, there is no fundamental difference between the classic life cycle and
the V-model. The V-model provides a way of visualizing how verification and
validation actions are applied to earlier engineering work.
Incremental Process
Consider the followingModel
two connected scenarios:
1. There are many situations in which initial software requirements are
reasonably well defined, but the overall scope of the development effort
precludes (prevent from happening; make impossible) a purely linear process.
2. There may be a compelling need to provide a limited set of software
functionality to users quickly and then refine and expand on that functionality
in later software releases.
In such cases, you can choose a process model that is designed to produce the
software in increments.
Incremental Process
Model
Concepts behind
Incremental
• The incremental model combines elements of linear and parallel process flows.
Process Model
• The incremental model applies linear sequences in a staggered (walk or move
unsteadily) fashion as calendar time progresses.
• Each linear sequence produces deliverable “increments” of the software.
• For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document
production functions in the first increment; more sophisticated editing and
document production capabilities in the second increment; spelling and
grammar checking in the third increment; and advanced page layout capability
in the fourth increment.
Concepts behind
Incremental
Process
When an incremental model is used, Modelis often a core product.
the first increment
That is, basic requirements are addressed but many supplementary features
(some known, others unknown) remain undelivered.
The core product is used by the customer (or undergoes detailed evaluation). As
a result of use and/or evaluation, a plan is developed for the next increment.
The plan addresses the modification of the core product to better meet the
needs of the customer and the delivery of additional features and functionality.
Advantages of Incremental
Process Model
Useful when staffing is unavailable for a complete implementation by the
business deadline that has been established for the project. Early increments can
be implemented with fewer people.
If the core product is well received, then additional staff (if required) can be
added to implement the next increment.
In addition, increments can be planned to manage technical risks. For example, a
major system might require the availability of new hardware that is under
development and whose delivery date is uncertain. It might be possible to plan
early increments in a way that avoids the use of this hardware, thereby enabling
partial functionality to be delivered to end users without inordinate delay.
The RAD
Model
It is an incremental process model that emphasizes a short development cycle.
It is a high speed adoption of the waterfall model, in which rapid software
development is achieved by using a component based development.
If customer requirements are full understood and project scope is constrained,
the RAD process enables a development team to create a “fully functional
system” within a very short period of time. (Ex:- 60 to 90 days)
The RAD
Model
Like other process models, RAD model maps into process framework activities.
1. Communication & Planning: helps to understand business problem
and information characteristics that the software must accommodate.
2. Modeling: It encompasses three major phases:
1. Business modeling
2. Data modelling
3. Process modeling
[Link]: emphasizes the use of pre-developed software components
and automatic code generation.
4. Deployment: initiates subsequent iteration.
Five Drawbacks of RAD
Model
1. For large and scalable projects (continuous development) RAD model requires
more human resources to create more number of teams.
2. If developers and customers are not committed to the rapid-activities that are
necessary to complete the system within a short-time, the entire system will
fail.
3. If a system cannot be properly modularized, the RAD will be problematic.
4. RAD may not be suitable if technical risks are high.
5. If performance is an issue, and high performance can be achieved through
tuning the interfaces among components, the RAD is useless.
Evolutionary Process
Models
Evolutionary process models are iterative. They are highly useful to a software
engineer to develop more complex version soft wares.
Three types in evolutionary process model:
1. The prototyping model
2. The spiral model
3. The concurrent development model
The prototyping
model
Consider the following two different situations:
1. Often, a customer defines a set of general objectives, but does not identify a
detailed specifications like input, processing and output requirements. Its a
problem in customer side.
2. Next is, problems in developer side; a developer may unsure about the
efficiency of an algorithm; the adoptability of an operating system; problems
in human-computer interaction etc.
In these non-stabilized cases, the prototyping model may offer a best solution.
The prototyping
model
Problems in prototyping
1. Customer gets model
disappointed and lodge more complaints about the product
after seeing an initial version of working model, because they see a temporary
patch. The customer sees what appears to be a working version of the
software, unaware about the prototype. When a developer informed that the
product must be rebuilt so that high quality can be maintained, the customer
demands that “a few fixes” be applied to make the prototype a working
product.
2. The developer makes implementation compromises in order to get a working
prototype. An inappropriate program / inefficient algorithm / easy tool may
be used to demonstrate the capability of working model. Later, the developer
become comfortable with these choices and forget all the reasons why they
were inappropriate. The less-than-ideal choice has now become an integral
part of the system.
The Spiral
model
It’s a hybrid model that couples the iterative nature of prototyping model and
controlled and systematic aspect of waterfall model.
It provides potential for rapid development of more complex versions of
software. It is a part evolutionary model.
A spiral model is divided into a set of framework activities. Each framework
activity represents one segment of the spiral path.
The Spiral model
As this process begins, the software team performs activities that are implied by
a circuit around the spiral in a clockwise direction, beginning at the center.
Anchor path milestones – a combination of work products and conditions are
attained along the path of spiral.
The positives and
negatives of Spiral
model
Positives are: The spiral model is a realistic approach to the development of large-
complex systems.
It helps developer to understand and react to the risks at each evolutionary
levels.
It sees prototype as one of risk reducing mechanism, and it enables the
developer to use prototyping approach at every evolutionary levels.
Problems are: It is very difficult to convince a customer (particularly in contract
situations) that the model is controllable.
It demands risk assessment expertise and relies on this expertise on success. If a
major risk is uncovered, problems will occur.
The concurrent
development
model
Sometimes called concurrent engineering, can be represented schematically as a
series of framework activities, software engineering actions, tasks and their
associated states.
The model defines a series of events that will trigger transitions from state to
state for each of the software engineering activities, actions, or tasks.
The concurrent
development
model
Consider analysis activity – an action may goes on anyone of the given states.
Similarly other activities or tasks can be represented in an analogous (meaning:
comparable in certain respects) manner. For your consideration, a modeling
activity is given in next slide.
Importance of
concurrent
development
The concurrent model
development model is applicable to all types of software
development and provides an accurate picture of the current state of a project.
It defines a network activity, not like other software engineering actions.
Each activity, actions, tasks on the network exists simultaneously with other
activities, actions, tasks.
Specialized Process
Special process model
models take many features from one or more conventional
models. However these special models tend to be applied when a narrowly
defined software engineering approach is chosen.
Types in Specialized process models:
1. Component based development (Promotes reusable components)
2. The formal methods model (Mathematical formal methods are backbone here)
3. Aspect oriented software development (Uses crosscutting technology)
Component based
The component
development
based development model incorporates many of the
characteristics of the spiral model. It is evolutionary in nature, demanding an
iterative approach to the creation of software.
However, the model focuses on prepackaged software components. It promotes
software reusability.
Component based
development
Component based
development
Modeling and construction activities begin with the identification of candidate
components. Candidate components can be designed as either conventional
software modules or object oriented packages.
Component based development has the following steps:
1. Available component based products are researched and evaluated for
the application domain.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
Problems in Component
based
Component development
trustworthiness - how can a component with no available source
code be trusted?
Component certification - who will certify the quality of components?
Requirements trade-offs - how do we do trade-off analysis between the features
of one component and another?
The formal methods
The formal methods model
model encompasses a set of activities that leads to formal
mathematical specification of software. Formal methods enable a software
engineer to specify, develop and verify a computer system by applying rigorous
mathematical notation.
When mathematical methods are used during software development, they
provide a mechanism for eliminating many of the problems that are difficult to
overcome using other software engineering paradigms.
Formal methods provide a basis for software verification and therefore enable
software engineer to discover and correct errors that might otherwise go
undetected.
Problems in formal
methods model
The development of formal models is currently time-consuming and expensive.
Because few developers have the necessary background knowledge to apply
formal methods, extensive training is required to others.
It is difficult to use this model as a communication mechanism for technically
unsophisticated people.
Aspect oriented
Software
Development
Aspect Oriented Software Development (AOSD) often referred to as aspect-
oriented programming (AOP), a relatively new paradigm that provides process
and methodology for defining, specifying designing and constructing aspects.
It addresses limitations inherent in other approaches, including object-oriented
programming. AOSD aims to address crosscutting concerns by providing means
for systematic identification, separation, representation and composition.
This results in better support for modularization hence reducing development,
maintenance and evolution costs.
.
The Unified
What is it? Process
The Unified Process (UP) is an attempt to draw on the best features and
characteristics of conventional software process models, but characterize them in
a way that implements many of the best principles of agile software
development.
The Unified Process recognizes the importance of customer communication and
streamlined methods for describing the customer’s view of a system.
It helps the architect to focus on the right goals, such as understandability,
reliance to future changes, and reuse.
Agile Software
Development
What is agile software development?
“Agile Development” is an umbrella term for several iterative and incremental software
development methodologies. The most popular agile methodologies include Extreme
Programming (XP), Scrum, Crystal Clear, Dynamic Systems Development Method
(DSDM), and Feature-Driven Development (FDD).
Agile Manifesto:
We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Phases of the Unified
Process
Inception phase: encompasses both customer communication and planning
activities.
Elaboration phase: encompasses planning and modeling activities.
Construction phase: is identical to the construction activity.
Transition phase: encompasses latter stages of construction activity and first part
of the generic deployment activity.
Production phase: coincides with the deployment activity of the generic process.
Major Workflow
Produced for
Unified Process