SUBJECT CODE

TYPE THE SUBJECT NAME HERE

UNIT NO 1

1. SOFTWARE PROCESS AND AGILE

DEVELOPMENT
1.3 PERSPECTIVE AND SPECIALIZED
III V PROCESS MODELS

CS8494
SOFTWARE ENGINEERING
 CS8494

SOFTWARE ENGINEERING

PROCESS MODELS

●PRESCRIPTIVE PROCESS MODELS

○ Waterfall model
○ Incremental Process model
Incremental model
RAD model
○ Evolutionary model
Prototyping
Spiral model
Concurrent model
● SPECIALIZED PROCESS MODELS
○ Component-Based Development
○ The Formal Methods Model
○ Aspect-Oriented Software Development
 CS8494

SOFTWARE ENGINEERING

PRESCRIPTIVE PROCESS MODEL

● Prescriptive process models are sometimes referred to as

“traditional” process models

● A prescriptive process model strives for structure and order in

software development. Activities and tasks occur sequentially
with defined guidelines for progress

● The prescriptive process approach in which order and project

consistency are dominant issues.

● It prescribes 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 process fl ow (also
called a work fl ow )—that is, the manner in which the process
elements are interrelated to one another.
 CS8494
SOFTWARE ENGINEERING

WATERFALL MODEL

●Classic life cycle or Linear sequential model

●The classic life cycle suggests a systematic, sequential approach to software
development
●It is the oldest paradigm for SE.
● This model is used for projects when requirements are well defined and
reasonably stable
 CS8494

SOFTWARE ENGINEERING

The waterfall model

 CS8494
SOFTWARE ENGINEERING

PHASES OF WATERFALL MODEL

The principal stages of the waterfall model directly reflect the fundamental
development activities:

1. Requirements analysis and definition The system’s services, constraints,

and goals are established by consultation with system users. They are then
defined in detail and serve as a system specification.

2. System and software design The systems design process allocates the
requirements to either hardware or software systems by establishing an overall
system architecture. Software design involves identifying and describing the
fundamental software system abstractions and their relationships.

3. Implementation and unit testing During this stage, the software design is
realized as a set of programs or program units. Unit testing involves verifying that
each unit meets its specification.
 CS8494
SOFTWARE ENGINEERING

PHASES OF WATERFALL MODEL

4. Integration and system testing The individual program units or programs are
integrated and tested as a complete system to ensure that the software
requirements have been met.

After testing, the software system is delivered to the customer.

5. Operation and maintenance Normally (although not necessarily), this is the

longest life cycle phase. The system is installed and put into practical use.

Maintenance involves correcting errors which were not discovered in earlier

stages of the life cycle, improving the implementation of system units and
enhancing the system’s services as new requirements are discovered.
 CS8494
SOFTWARE ENGINEERING

WATERFALL MODEL

● In principle, the result of each phase is one or more documents that are approved
(‘signed off’). The following phase should not start until the previous phase has
finished.
● In practice, these stages overlap and feed information to each other. During
design, problems with requirements are identified. During coding, design problems
are found and so on.
● The software process is not a simple linear model but involves feedback from one
phase to another.
● Documents produced in each phase may then have to be modified to reflect the
changes made.
● Because of the costs of producing and approving documents, iterations can be
costly and involve significant rework.
 CS8494

SOFTWARE ENGINEERING

ADVANTAGES OF WATERFALL MODEL

● This model is very simple and is easy to understand.

● Phases in this model are processed one at a time.
● Each stage in the model is clearly defined.
● This model has very clear and well understood milestones.
● Process, actions and results are very well documented.
● This model works well for smaller projects and projects where requirements are
well understood.
 CS8494

SOFTWARE ENGINEERING

DRAWBACKS

1. Real projects rarely follow the sequential fl ow 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.

2. It 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 not be
available until late in the project time span. A major blunder, if undetected until the
working program is reviewed, can be disastrous.

4. The linear nature of the classic life cycle leads to “blocking states” in which some
project team members must wait for other members of the team to complete
dependent tasks.
 CS8494

SOFTWARE ENGINEERING

V- MODEL (a variation of waterfall model)

❖ A variation in the representation of the waterfall model is called the V-model.

 CS8494

SOFTWARE ENGINEERING

V- MODEL

● The V-model depicts the relationship of quality assurance actions to the actions
associated with communication, modeling, and early construction activities

● As a software team moves down the left side of the V, basic problem requirements are
refined into progressively more detailed and 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 moves 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.
 CS8494

SOFTWARE ENGINEERING

INCREMENTAL PROCESS MODEL

• Incremental development is based on the idea of developing an initial

implementation, exposing this to user comment and evolving it through several
versions until an adequate system has been developed

• This model combines elements of both linear sequential model with the
iterative philosophy of prototyping

• The incremental model applies linear sequences in a staggered fashion as

calendar time progresses. Each linear sequence produces a deliverable
“increment” of the software
 CS8494

SOFTWARE ENGINEERING

INCREMENTAL PROCESS MODEL

 CS8494

SOFTWARE ENGINEERING

INCREMENTAL PROCESS MODEL

• When an incremental model is used, the first increment is often a core

product. 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 review). 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.
This process is repeated following the delivery of each increment, until the
complete product is produced.

• The incremental model focuses on the delivery of an operational product with

each increment. Early increments are stripped down versions of the final
product, but they do provide capability that serves the user and also provide a
platform for evaluation by the user.
 CS8494

SOFTWARE ENGINEERING

INCREMENTAL PROCESS MODEL

● Incremental development is particularly 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.
 CS8494

SOFTWARE ENGINEERING

INCREMENTAL PROCESS MODEL

For example,

word-processing software developed using the incremental paradigm might deliver

basic fi le 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.

It should be noted that the process flow for any increment can incorporate the
prototyping paradigm
 CS8494

SOFTWARE ENGINEERING

RAPID APPLICATION DEVELOPMENT MODEL(RAD)

• RAD is an incremental software development process model.
• It emphasizes short development cycle
• “high speed” adaptation of linear sequential model in which rapid
application is achieved by using component-based construction.
• If requirements are well understood and project scope is constrained, the
RAD process enables a development team to create a “fully functional
system” within very short time periods (e.g., 60 to 90 days)
• The phases are
❖ Business modeling
❖ Data modeling
❖ Process modeling
❖ Application generation
❖ Testing & turnover
 CS8494

SOFTWARE ENGINEERING

RAPID APPLICATION DEVELOPMENT MODEL(RAD)

 CS8494

SOFTWARE ENGINEERING

RAPID APPLICATION DEVELOPMENT MODEL(RAD)

1. Business modeling: The information flow among business

functions is modeled in a way that answers the following
questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who processes it?
2. Data modeling: The information flow defined as part of the
business modeling phase is refined into a set of data objects that
are needed to support the business. The characteristics (called
attributes) of each object are identified and the relationships
between these objects defined.
 CS8494

SOFTWARE ENGINEERING

RAPID APPLICATION DEVELOPMENT MODEL(RAD)

3. Process modeling: The data objects defined in the data modeling phase
are transformed to achieve the information flow necessary to implement a
business function. Processing descriptions are created for adding,
modifying, deleting, or retrieving a data object.

4. Application generation: RAD assumes the use of fourth generation

techniques. Rather than creating software using conventional third
generation programming languages the RAD process works to reuse
existing program components (when possible) or create reusable
components (when necessary). In all cases, automated tools are used to
facilitate construction of the software.

5. Testing and turnover:Since the RAD process emphasizes reuse, many

of the program components have already been tested. This reduces overall
testing time. However, new components must be tested and all interfaces
must be fully exercised.
 CS8494

SOFTWARE ENGINEERING

Advantages

• Use of reusable components helps to reduce the cycle time of the

project.
• Encourages user involvement
• Reduced cost.
• Flexible and adaptable to changes
 CS8494

SOFTWARE ENGINEERING

Disadvantages

• For large scalable projects, RAD requires sufficient human resources to

create the right number of RAD teams.

• If developers and customers are not committed to the rapid-fire activities, then

project will fail. If a system cannot properly be modularized, building the

components necessary for RAD will be problematic.
• The use of powerful and efficient tools requires highly skilled professionals.
• Customer involvement is required throughout the life cycle.
 CS8494

SOFTWARE ENGINEERING

EVOLUTIONARY PROCESS MODELS

Evolutionary process models produce an increasingly more complete

version of the software with each iteration.

Two types of evolutionary approaches are

o Prototyping

o Spiral models.
 CS8494

SOFTWARE ENGINEERING

PROTOTYPING

A prototype is an initial version of a software system that is used to

demonstrate concepts, try out design options, and find out more about
the problem and its possible solutions
A software prototype can be used in a software development process to
help anticipate changes that may be required:

1. In the requirements engineering process, a prototype can help

with the elicitation and validation of system requirements.

2. In the system design process, a prototype can be used to explore

particular software solutions and to support user interface design.
 CS8494

SOFTWARE ENGINEERING

PROTOTYPING
 CS8494

SOFTWARE ENGINEERING

PROTOTYPING

● The prototyping paradigm begins with communication. You meet with other
stakeholders to define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further defi nition is mandatory.

● A prototyping iteration is planned quickly, and modeling (in the form of a “quick
design”) occurs.

● A quick design focuses on a representation of those aspects of the software that

will be visible to end users (e.g., human interface layout or output display
formats).
 CS8494

SOFTWARE ENGINEERING

PROTOTYPING

● The quick design leads to the construction of a prototype.

● The prototype is deployed and evaluated by stakeholders, who provide feedback

that is used to further refine requirements.

● Iteration occurs as the prototype is tuned to satisfy the needs of various

stakeholders, while at the same time enabling you to better understand what
needs to be done.

● Ideally, the prototype serves as a mechanism for identifying software

requirements. If a working prototype is to be built, you can make use of existing
program fragments or apply tools that enable working programs to be generated
quickly.
 CS8494

SOFTWARE ENGINEERING

PROTOTYPING

● The same prototype cannot meet all objectives.

● If the objectives are left unstated, management or end-users may

misunderstand the function of the prototype. Consequently, they may not get
the benefits that they expected from the prototype development.

● Although problems can occur, prototyping can be an effective paradigm for

software engineering. The key is to define the rules of the game at the
beginning; that is, all stakeholders should agree that the prototype is built to
serve as a mechanism for defi ning requirements.

● It is then discarded (at least in part), and the actual software is engineered
with an eye toward quality.
 CS8494

SOFTWARE ENGINEERING

SPIRAL MODEL

• It couples the iterative nature of prototyping with the controlled and

systematic aspects of the linear sequential model.

• Software is developed in a series of incremental releases

• It is divided into a number of framework activities,also called task regions.

● Customer Communication
● Planing
● Risk analysis
● Engineering
● Construction and release
● Customer evaluation
 CS8494

SOFTWARE ENGINEERING

SPIRAL MODEL
 CS8494

SOFTWARE ENGINEERING

SPIRAL MODEL

• The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop
a prototype and then progressively more sophisticated versions of the
software.
• Each pass through the planning region results in adjustments to the project
plan.
• Cost and schedule are adjusted based on feedback derived from the
customer after delivery.
• In addition, the project manager adjusts the planned number of iterations
required to complete the software.
 CS8494

SOFTWARE ENGINEERING

SPIRAL MODEL

● The spiral model is a realistic approach to the development of large-scale

systems and software. Because software evolves as the process progresses,
the developer and customer better understand and react to risks at each
evolutionary level.

● It maintains the systematic stepwise approach suggested by the classic life

cycle but incorporates it into an iterative framework that more realistically refl
ects the real world.

● The spiral model demands a direct consideration of technical risks at all

stages of the project and, if properly applied, should reduce risks before they
become problematic.
 CS8494

SOFTWARE ENGINEERING

CONCURRENT DEVELOPMENT MODEL

● The concurrent process model can be represented schematically as a

series of major technical activities, tasks, and their associated states.
● Allow a software team to represent iterative and concurrent elements of
any of the process models.
● For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the following actions:
prototyping, analysis and design.
 CS8494

SOFTWARE ENGINEERING

CONCURRENT DEVELOPMENT MODEL

 CS8494

SOFTWARE ENGINEERING

CONCURRENT DEVELOPMENT MODEL

● For example, communication activity has completed its first

iteration and in the awaiting changes state. The modeling
activity was in inactive state, now makes a transition into the
under development state. If customer indicates changes in
requirements, the modeling activity moves from the under
development state into the awaiting changes state.

● Concurrent modeling is applicable to all types of software

development
 CS8494

SOFTWARE ENGINEERING

CONCURRENT DEVELOPMENT MODEL

● This provides an accurate picture of the current state of a project.

● Rather than confining software engineering activities, actions

and tasks to a sequence of events, it defines a process
network.

● Each activity, action or task on the network exists

simultaneously with other activities, actions or tasks.

● Events generated at one-point trigger transitions among the states.

 CS8494

SOFTWARE ENGINEERING

SPECIALISED PROCESS MODELS

These models tend to be applied when a specialized or narrowly

defined software engineering approach is chosen.

● Component based development – the process to apply when

reuse is a development objective ( like spiral model)
● Formal methods—emphasizes the mathematical specification
of requirements ( easy to discover and eliminate ambiguity,
incompleteness and inconsistency)
● Aspect Oriented software development (AOSD)— provides a
process and methodological approach for defining, specifying,
designing, and constructing aspects
 CS8494

SOFTWARE ENGINEERING

Component-Based Development

● The component-based development model incorporates many

of the characteristics of the spiral model.
● It is evolutionary in nature, uses an iterative approach to the creation
of software.
● The component-based development model constructs
applications from prepackaged software components.
● Modeling and construction activities begin with the identification
of candidate components.
● These components can be designed as either conventional
software modules or object- oriented classes or packages of
classes.
 CS8494

SOFTWARE ENGINEERING

Component-Based Development

● The component-based development model incorporates the following steps

to develop the software:
1. Available component-based products are researched and evaluated
for the application domain in question.
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.

 CS8494

SOFTWARE ENGINEERING

Component-Based Development

● The component-based development model leads to software reuse, and

reusability provides software engineers with a number of measurable
benefits.
● This model helps to reduce the development cycle time as well as the project
cost
 CS8494

SOFTWARE ENGINEERING

Formal Methods Model

● Every software engineering methodology is based on a recommended
development process proceeding through several phases:
● Requirements, Specification, Design
● Coding, Unit Testing
● Integration and System Testing, Maintenance
● Formal methods can
■ Be a foundation for designing safety critical systems
■ Be a foundation for describing complex systems
■ Provide support for program development
● The formal methods model has a set of activities that leads to formal
mathematical specification of computer software.
● Formal methods help to specify, develop, and verify a computer-based system by
applying a mathematical notation
 CS8494

SOFTWARE ENGINEERING

Formal Methods Model

● Ambiguity, incompleteness, and inconsistency can be discovered and

corrected more easily
● When formal methods are used during design, they help in program
verification and therefore enable to discover and correct errors
● Thus the formal methods model provides defect-free software
Drawbacks:

➔ The development of formal models is quite time consuming and expensive

➔ Because few software developers have the necessary background to
apply formal methods, extensive training is required
➔ It is difficult to use the models as a communication mechanism for
technically unsophisticated customers
 CS8494

SOFTWARE ENGINEERING

Aspect-Oriented Software Development

● Aspect-oriented software development (AOSD) aims to address

crosscutting concerns by providing means for systematic identification,
separation, representation and composition.
● Crosscutting concerns are encapsulated in separate modules, known
as aspects, so that localization can be promoted.
● This results in better support for modularization hence reducing
development, maintenance and evolution costs.
 CS8494

SOFTWARE ENGINEERING

Aspect-Oriented Software Development

● Some Crosscutting concerns are high-level properties of a system

(e.g., security, fault tolerance). Other concerns affect functions (e.g.,
the application of business rules), while others are systemic (e.g., task
synchronization or memory management).

● Aspect-oriented software development (AOSD) is often referred as

aspect-oriented programming (AOP), provides a process and
methodological approach for defining, specifying, designing, and
constructing aspects.
 CS8494

SOFTWARE ENGINEERING

Aspect-Oriented Software Development

● An aspect-oriented process is likely to adopt both evolutionary and

concurrent process models
● The evolutionary model is appropriate as aspects are identified and then
constructed.
● The parallel nature of concurrent development is essential
because aspects are engineered independently of localized
software components.
 CS8494

SOFTWARE ENGINEERING

Aspect-Oriented Software Development

● Advantages:
○ Provides better modularization support of software designs,
reducing software design, development and maintenance
costs
○ Because concerns are encapsulated into different modules,
localization of crosscutting concerns is better promoted and
handled.
○ Promotes reusability of code
○ Smaller code size, due to tackling cross cutting concerns
 CS8494

SOFTWARE ENGINEERING

Aspect-oriented component engineering (AOCE)

● AOCE uses a concept of horizontal slices through vertically-decomposed
software components, called “aspects,” to characterize cross-cutting
functional and non-functional properties of components.
● Systemic aspects include user interfaces, collaborative work, distribution,
persistency, memory management, transaction processing, security, integrity
and so on.
● Components may provide aspect details relating to a particular aspect, such
as a viewing mechanism, extensible affordance and interface kind (user
interface aspects); event generation, transport and receiving (distribution
aspects); data store/retrieve and indexing (persistency aspects);
authentication, encoding and access rights (security aspects); transaction
atomicity, concurrency control and logging strategy (transaction aspects); and
so on.
 CS8494

SOFTWARE ENGINEERING

Video URL:

https://www.youtube.com/watch?time_continue=1190&v=i7f075xlCoc&fe
ature=emb_logo