1. Software Engineering
Course Code: CS-1251
SE-Week-03
Instructor: Shimza Butt

2. The Software
Process
 Process defines a framework for a set
of key process areas that must be
established for effective delivery of
software engineering technology.
 A structured set of activities required
to develop a software system.

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

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

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

6. Software Process
Models

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

8. SDLC Model by
Summerville
 Requirements Definition
 System and Software Design
 Implementation and Unit testing
 Integration and System Testing
 Operation and maintenance

9. Types of SDLC
• Waterfall Model.
• V-Shaped Model.
• Evolutionary Prototyping Model.
• Spiral Method (SDM)
• Iterative and Incremental Method.
• Agile development.

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

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

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

14. The V-Model
A variation of waterfall model
depicts the relationship of
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.

15. Problems
Rarely linear
Iteration needed
Blocking state
Hard to state all requirements
explicitly
Code will not be released until
very late

17. 17

18. Incremental development

19. The Incremental Model
19

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

21. Incremental
development
benefits
• The amount of analysis and
documentation that has to be
redone is much less than is
required with the waterfall model.
The cost of
accommodating
changing customer
requirements is
reduced.
• Customers can comment on
demonstrations of the software
and see how much has been
implemented.
It is easier to get
customer feedback
on the development
work that has been
done.
• Customers are able to use and gain
value from the software earlier
than is possible with a waterfall
process.
More rapid delivery
and deployment of
useful software to
the customer is
possible.

22. Incremental
development
problems
• Managers need regular deliverables to
measure progress. If systems are developed
quickly, it is not cost-effective to produce
documents that reflect every version of the
system.
The process is not visible.
• 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.
System structure tends to degrade
as new increments are added.

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

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

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

26. RAD Model

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

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

29. Evolutionary Models: Prototyping
prototyping, analysis and design
Construction
of prototype
communication
Quick
plan
Modeling
Quick design
Construction
of prototype
Deployment
delivery &
feedback

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

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

32. Evolutionary Models: The Spiral

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

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

35. Integration
and
configuration
Based on software reuse where systems are
integrated from existing components or
application systems (sometimes called COTS -
Commercial-off-the-shelf) systems).
Reused elements may be configured to adapt
their behaviour and functionality to a user’s
requirements
Reuse is now the standard approach for
building many types of business system

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

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

38. Reuse-oriented software engineering

39. Key process
stages
Requirements specification
Software discovery and
evaluation
Requirements refinement
Application system configuration
Component adaptation and
integration

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

41. Still Other Process Models
Component based development—the process
to apply when reuse is a development
objective (COTS)
Unified Process—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.

42. Unified Modeling
 Class Diagram (View System Architecture)
 Use Case Diagram (View System Functionality)
 Sequence Diagram (View System Behavior)
 State Diagram (View System States)

43. The Unified Process (UP)
inception
elaboration