Software Engineering
Course Code: CS-1251
SE-Week-03
Instructor: Shimza Butt
Process defines a framework for a set
of key process areas that must be
established for effective delivery of
The Software software engineering technology.
A structured set of activities required
Process to develop a software system.
Software process descriptions
When we describe and discuss processes, we usually talk about
the activities in these processes such as specifying a data
model, designing a user interface, etc. and the ordering of
these activities.
Process descriptions may also include:
Products, which are the outcomes of a process activity;
Roles, which reflect the responsibilities of the people
involved in the process;
Pre- and post-conditions, which are statements that are
true before and after a process activity has been enacted or
a product produced.
Plan-driven and agile processes
Plan-driven processes are processes where all of the
process activities are planned in advance and progress is
measured against this plan.
In 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.
Software process activities
Many different software processes but all involve:
Software specification, where customers and engineers define the software
that is to be produced and the constraints on its operation.
Software development, where the software is designed and programmed.
Software validation, where the software is checked to ensure that it is what
the customer requires.
Software evolution, where the software is modified to reflect changing
customer and market requirements.
Software Process
Models
Software process models
A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective.
The waterfall model
Plan-driven model. Separate and distinct phases of specification and development.
Incremental development
Specification, development and validation are interleaved. May be plan-driven or
agile.
Integration and configuration
The system is assembled from existing configurable 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.
SDLC Model by
Summerville
Requirements Definition
System and Software Design
Implementation and Unit testing
Integration and System Testing
Operation and maintenance
Types of SDLC
• Waterfall Model.
• V-Shaped Model.
• Evolutionary Prototyping Model.
• Spiral Method (SDM)
• Iterative and Incremental Method.
• Agile development.
The Waterfall Model
It is the oldest paradigm for SE. When requirements are well
defined and reasonably stable, it leads to a top-down fashion.
The classic life cycle suggests a systematic, sequential approach
to software development.
Waterfall model phases
There are separate identified 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 main drawback of the waterfall model is the difficulty of
accommodating change after the process is underway. In principle, a phase
has to be complete before moving onto the next phase.
Waterfall model problems
Inflexible partitioning of the The waterfall model is mostly used
project into distinct stages makes for large systems engineering
it difficult to respond to changing projects where a system is
customer requirements. developed at several sites.
• Therefore, this model is only • In those circumstances, the plan-
appropriate when the driven nature of the waterfall
requirements are well- model helps coordinate the
understood and changes will be work.
fairly limited during the design
process.
• Few business systems have
stable requirements.
A variation of waterfall model
depicts the relationship of
The V-Model quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activities.
Team first moves down the left
side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.
Problems
Rarely linear
Iteration needed
Blocking state
Hard to state all requirements
explicitly
Code will not be released until
very late
17
Incremental development
The Incremental Model
19
The Incremental Model
When initial requirements are reasonably well defined, but the
overall scope of the development effort prevents a purely linear
process. A convincing need to expand a limited set of new functions
to a later system release.
It combines elements of water fall model in an iterative way. Each
linear sequence produces deliverable increments of the software.
The first increment is often a CORE PRODUCT with many additional
features. Users use it and evaluate it with more modifications to
better meet the needs.
The cost of • The amount of analysis and
accommodating
documentation that has to be
changing customer
requirements is redone is much less than is
reduced. required with the waterfall model.
Incremental It is easier to get
customer feedback • Customers can comment on
development on the
development work
that has been
demonstrations of the software and
see how much has been
implemented.
benefits done.
More rapid delivery • Customers are able to use and gain
and deployment of
value from the software earlier
useful software to
the customer is than is possible with a waterfall
possible. process.
The process is not visible.
• Managers need regular deliverables to
measure progress. If systems are developed
quickly, it is not cost-effective to produce
Incremental documents that reflect every version of the
system.
development System structure tends to degrade
as new increments are added.
problems • 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.
Pros and cons
Generates working software quickly and early during the
software life cycle.
More flexible – less costly to change scope and requirements
Easier to test and debug during a smaller iteration.
Easier to manage risk because risky pieces are identified and
handled during its iteration.
Each iteration is an easily managed milestone
Each phase of an iteration is rigid and do not overlap each other
Problems may arise pertaining to system architecture because
not all requirements are gathered up front for the entire
software life cycle.
RAD Model
Rapid application development (RAD) is an incremental software
development process model
It emphasizes an extremely short development cycle
The RAD model is a “high-speed” adaptation of the linear sequential
model in which rapid development 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(60-90 days)
Pros and cons
Increases reusability of components
Progress can be measured.
Encourages customer feedback
Quick initial reviews occur
Reduced development time
Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.
It is suitable for systems that are component based and scalable.
Requires highly skilled developers/designers.
Requires user involvement throughout the life cycle.
RAD Model
Evolutionary Models
Software system evolves over time as requirements often change as
development proceeds. Thus, a straight line to a complete end product is not
possible. However, a limited version must be delivered to meet competitive
pressure.
Usually a set of core product or system requirements is well understood, but
the details and extension have yet to be defined.
You need a process model that has been explicitly designed to accommodate
a product that evolved over time.
It is iterative that enables you to develop increasingly more complete version
of the software.
Two types are introduced, namely Prototyping and Spiral models.
Evolutionary Models: Prototyping
When to use: Customer defines a set of GENERAL OBJECTIVES but does not
identify detailed requirements for functions and features. Or Developer may be
unsure of the efficiency of an algorithm, the form that human computer
interaction should take.
What step: Begins with communication by meeting with stakeholders to define the
objective, identify whatever requirements are known, outline areas where further
definition is mandatory. A quick plan for prototyping and modeling (quick design)
occur. Quick design focuses on a representation of those aspects the software that
will be visible to end users. ( interface and output). Design leads to the
construction of a prototype which will be deployed and evaluated. Stakeholder’s
comments will be used to refine requirements.
Both stakeholders and software engineers like the prototyping paradigm. Users get
a feel for the actual system, and developers get to build something immediately.
However, engineers may make compromises in order to get a prototype working
quickly. The less-than-ideal choice may be adopted forever after you get used to
it.
Evolutionary Models: Prototyping
prototyping, analysis and design
Quick
plan
communication
Modeling
Quick design
Deployment Construction
delivery & of prototype
feedback Construction
of prototype
Pros and cons
Model allows a high user interface of the customer.
It provide actual look and feel of system being developed for
customer review and feedback about the system functionality.
Errors and issues can be detected very easily.
Risk of insufficient requirement analysis owing to too much
dependency on prototype.
Users may get confused in the prototypes and actual systems.
Developers may try to reuse the existing prototypes to build the
actual system, even when it’s not technically feasible.
Less-than-ideal choice has now become an integral part of the
system
Evolutionary Models: The Spiral
Spiral model is one of the most important Software
Development Life Cycle models, which provides support
for Risk Handling. In its diagrammatic representation, it looks
like a spiral with many loops. The exact number of loops of the
spiral is unknown and can vary from project to project. Each
loop of the spiral is called a Phase of the software
development process. The exact number of phases needed to
develop the product can be varied by the project manager
depending upon the project risks. As the project manager
dynamically determines the number of phases, so the project
manager has an important role to develop a product using
spiral model.
Evolutionary Models: The Spiral
Pros and cons
Highly flexible model
Risk handling
Fast and cost-effective development
Well-suited for large scale projects and mission-critical developments
Works well for complex projects
Monitoring is easy and effective
The end product can be highly customized
Can be expensive to implement – especially if spirals continue infinitely
The risk analysis aspect of the project may require specialist expertise
Not an ideal fit for smaller or low-risk projects
Success may depend greatly on the risk analysis
Documentation can be heavy, due to the number of intermediate stages
End of project may be difficult to define beforehand
Three Concerns on
Evolutionary Processes
First concern is that prototyping poses a problem to project planning
because of the uncertain number of cycles required to construct the
product.
Second, it does not establish the maximum speed of the evolution. If
the evolution occur too fast, without a period of relaxation, it is
certain that the process will fall into confusion. On the other hand if
the speed is too slow then productivity could be affected.
Third, software processes should be focused on flexibility and
extensibility rather than on high quality. We should prioritize the
speed of the development over zero defects. Extending the
development in order to reach high quality could result in a late
delivery of the product when the opportunity has disappeared.
Based on software reuse where systems are
integrated from existing components or
application systems (sometimes called COTS -
Commercial-off-the-shelf) systems).
Integration Reused elements may be configured to adapt
and their behaviour and functionality to a user’s
requirements
configuration
Reuse is now the standard approach for
building many types of business system
Reuse-Oriented Model
The reuse-oriented model, also called reuse-oriented development (ROD)
Method of software development in which a program is refined by producing
a sequence of prototypes called models
Each model is automatically derived from the preceding one according to a
sequence of defined rules.
Types of reusable software
Stand-alone application systems (sometimes called COTS) that are configured
for use in a particular environment.
Collections of objects that are developed as a package to be integrated with
a component framework such as .NET or J2EE.
Web services that are developed according to service standards and which are
available for remote invocation.
Reuse-oriented software engineering
Requirements specification
Software discovery and
evaluation
Key process Requirements refinement
stages
Application system configuration
Component adaptation and
integration
Advantages and disadvantages
Reduced costs and risks as less software is developed from scratch
Faster delivery and deployment of system
But requirements compromises are inevitable so system may not meet real
needs of users
Loss of control over evolution of reused system elements
Still Other Process Models
Component based development—the process
to apply when reuse is a development
objective (COTS)
UnifiedProcess—a “use-case driven,
architecture-centric, iterative and
incremental” software process closely
aligned with the Unified Modeling Language
(UML) to model and develop object-oriented
system iteratively and incrementally.
Class Diagram (View System Architecture)
Use Case Diagram (View System Functionality)
Sequence Diagram (View System Behavior)
State Diagram (View System States)
Unified Modeling
The Unified Process (UP)
elaboration
inception
