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
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.
• In those circumstances, the plan-
driven nature of the waterfall
model helps coordinate the
work.
 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