Advance Software

Engineering
 Today’s Lecture: Agenda

• Course Outline
• Deliverables
• Lesson 1
 Course Outline
• Text Book:
Software Engineering by Ian Sommerville
Software Engineering: A practitioner’s Approach by Roger S.
Pressman, Seventh Edition.
• References:
• Software Requirements Using The Unified Process: A Practical
Approach, Daniel R. Windle and L. Rene Abreo, Prentice Hall, 2002
• Mastering the Requirements Process, Suzanne Robertson & James
Robertson, Addison-Wesley, 2006.
• Managing Software Requirements: A Use Case Approach, Dean
Leffingwell and Don Widrig , 2nd Edition, Addison Wesley, 2003
• Recent research papers
• Case studies
Course Outline
• Basic
• Introduction to Software Engineering
• Software life cycle model.
• SRS Document
• Functional and non-functional requirements
• Software Design
Course Outline
• Advance
• Module/Functional Design
• Cohesion/Coupling
• Coding
• Debugging
• Integration
• White/Black Box Testing
• Software Maintenance
Course Outline
• Advance
• UML
• Formal Methods
• Software Reuse
• Software System Re-engineering
• Software Reverse Engineering
• Goal-based Software Engg.
This is a programming extensive course.

Please go through the object-oriented programming.

Programming questions will be part of both mid terms, final and project.
Scope and necessity of software engineering
• Software engineering is an engineering approach for
software development.

• We can alternatively view it as a systematic collection of

past experience. The experience is arranged in the form
of methodologies and guidelines.

• A small program can be written without using software

engineering principles. But if one wants to develop a
large software product, then software engineering
principles are MUST to achieve a good quality software
cost effectively.
 Scope and necessity of software engineering
• Without using software engineering principles it would be difficult
to develop large programs.

• A program of size 1,000 lines of code has some complexity. But a

program with 10,000 LOC is not just 10 times more difficult to
develop, but may as well turn out to be 100 times more difficult
unless software engineering principles are used.

• In such situations software engineering techniques come to rescue.

• Software engineering helps to reduce the programming complexity.

• Software engineering principles use two important techniques to

reduce problem complexity.

• Abstraction and Decomposition

Abstraction
• The principle of abstraction implies that a problem can
be simplified by omitting irrelevant details.
• In other words, the main purpose of abstraction is to
consider only those aspects of the problem that are
relevant for certain purpose and suppress other aspects
that are not relevant for the given purpose.
• Once the simpler problem is solved, then the omitted
details can be taken into consideration to solve the next
lower level abstraction, and so on.
• Abstraction is a powerful way of reducing the complexity
of the problem.
Abstraction
Decomposition
• In this technique, a complex problem is
divided into several smaller problems and
then the smaller problems are solved one
by one.
Decomposition
Decomposition
• However, in this technique any random decomposition of a
problem into smaller parts will not help.
• The problem has to be decomposed such that each
component of the decomposed problem can be solved
independently and then the solution of the different
components can be combined to get the full solution.
• A good decomposition of a problem should minimize
interactions among various components.
• If the different subcomponents are interrelated, then the
different components cannot be solved separately and the
desired reduction in complexity will not be realized.
Software Life Cycle Model
• A software life cycle model (also called process model) is
a descriptive and diagrammatic representation of the
software life cycle.
• A life cycle model represents all the activities required to
make a software product.
• It also captures the order in which these activities are to
be undertaken.
• In other words, a life cycle model maps the different
activities performed on a software product from its start
to retirement.
The need for a software life cycle model

• Without using of a particular life cycle model the development

of a software product would not be in a systematic and
disciplined manner.
• When a software product is being developed by a team there
must be a clear understanding among team members about
when and what to do. Otherwise it would lead to chaos and
project failure.
models have been proposed so far. Each of
Different software life cycle models
advantages as well as some disadvantages. A
and commonly used life cycle models are as

rfall Model
rfall model
Model or Evolutionary Model
Classical Waterfall Model
• The classical waterfall model is intuitively the most obvious
way to develop software.
• Thus, this model can be considered to be a theoretical way of
developing software.
• But all other life cycle models are essentially derived from the
classical waterfall model. So, in order to be able to appreciate
other life cycle models it is necessary to learn the classical
waterfall model.
Classical Waterfall Model
• Classical waterfall model divides the life cycle into the
following phases.
• Feasibility Study
• Requirements Analysis and Specification
• Design
• Coding and Unit Testing
• Integration and System Testing
• Maintenance
Activities undertaken during feasibility study

• The main aim of feasibility study is to determine whether it would

be financially and technically feasible to develop the product.
• At first project managers or team leaders try to have a rough
understanding of what is required to be done by visiting the client
side.
• Then they examine each of the solutions in terms of what kind of
resources required, what would be the cost of development and
what would be the development time for each solution.
• Based on this analysis they pick the best solution and determine
whether the solution is feasible financially and technically.
Activities undertaken during requirements
analysis & specification

• The aim of the requirements analysis and specification phase

is to understand the exact requirements of the customer and
to document them properly. This phase consists of two distinct
activities, namely
• Specification, and
• Analysis
Requirements Specifications
• Get user requirements form the client.
• The goal is to collect all relevant information from the
customer regarding the product to be developed.
Requirements Analysis
• The aim of requirements analysis is to discover problems
with the system requirements.

24
Requirements Analysis Stages

• Necessity checking
• Consistency checking
• Completeness checking

25
Necessity Checking
• The need for the requirement is analyzed.
• In some cases, requirements may be proposed which
don’t contribute to the business goals of the organization
or to the specific problem to be addressed by the system
• Sometimes the customers want to include every thing in the software
product which they do not need
• Analyze in context of budget, schedule, technology and conformance to
objectives of client

26
Consistency and Completeness Checking

• The requirements are cross-checked for consistency and

completeness.
• Consistency means that no requirements should be
contradictory
• Completeness means that no services or constraints which are
needed have been missed out and no vagueness.

27
Activities undertaken during design

• The goal of the design phase is to transform the requirements

specified in the SRS document into a structure that is suitable
for implementation in some programming language.
• In technical terms, during the design phase the software
architecture is derived from the SRS document.
Activities undertaken during coding and unit
testing:
• The purpose of the coding and unit testing phase
(sometimes called the implementation phase) of
software development is to translate the software design
into source code.
• Each component of the design is implemented as a
program module. The end-product of this phase is a set
of program modules that have been individually tested.
• During this phase, each module is unit tested to
determine the correct working of all the individual
modules. It involves testing each module in isolation as
this is the most efficient way to debug the errors
identified at this stage.
 Activities undertaken during integration and
system testing:
• Integration of different modules is undertaken once they have been
coded and unit tested.
• During the integration and system testing phase, the modules are
integrated in a planned manner. The different modules making up a
software product are almost never integrated in one shot.
• Integration is normally carried out incrementally over a number of
steps. During each integration step, the partially integrated system is
tested and a set of previously planned modules are added to it.
• Finally, when all the modules have been successfully integrated and
tested, system testing is carried out.
Activities undertaken during integration and
system testing:
• System testing usually consists of three different kinds of testing
activities:
• α – testing: It is the system testing performed by the development team.
• β – testing: It is the system testing performed by a friendly set of customers.
• acceptance testing: It is the system testing performed by the client himself
after the product delivery to determine whether to accept or reject the
delivered product.
Activities undertaken during maintenance

• Maintenance of a typical software product requires much

more than the effort necessary to develop the product itself.
• Many studies carried out in the past confirm this and indicate
that the relative effort of development of a typical software
product to its maintenance effort is roughly in the 40:60 ratio.
Activities undertaken during maintenance

• Maintenance involves performing following kinds of

activities:
• Correcting errors that were not discovered during the product
development phase. This is called corrective maintenance.
• Improving the implementation of the system, and enhancing the
functionalities of the system according to the customer’s
requirements. This is called perfective maintenance.
• Porting the software to work in a new environment. For example,
porting may be required to get the software to work on a new
computer platform or with a new operating system. This is called
adaptive maintenance.
Shortcomings of the classical waterfall model

• The classical waterfall model is an idealistic one since it assumes

that no development error is ever committed by the engineers
during any of the life cycle phases.
• However, in practical development environments, the engineers do
commit a large number of errors in almost every phase of the life
cycle.
• The source of the defects can be many: oversight, wrong
assumptions, use of inappropriate technology, communication gap
among the project engineers, etc.
• Once a defect is detected, the engineers need to go back to the
phase where the defect had occurred and redo some of the work.
Prototype
• A prototype is a toy implementation of the system.
• A prototype usually exhibits limited functional
capabilities, low reliability, and inefficient performance
compared to the actual software.
• A prototype is usually built using several shortcuts. The
shortcuts might involve using inefficient, inaccurate, or
dummy functions.
• A prototype usually turns out to be a very crude version
of the actual system.
When to use prototype model

• A prototype of the actual product is preferred in situations such as:

• user requirements are not complete
• technical issues are not clear
• Example 1: User requirements are not complete : In any application software like
billing in a retail shop, accounting in a firm, etc the users of the software are not clear
about the different functionalities required. Once they are provided with the
prototype implementation, they can try to use it and find out the missing
functionalities.

• Example 2: Technical issues are not clear Suppose a project involves writing a
compiler and the development team has never written a compiler. In such a case, the
team can consider a simple language, try to build a compiler in order to check the
issues that arise in the process and resolve them. After successfully building a small
compiler (prototype), they would extend it to one that supports a complete language.
Spiral model
• The diagrammatic representation of this model appears
like a spiral with many loops.
• The exact number of loops in the spiral is not fixed.
• Each loop of the spiral represents a phase of the
software process. For example, the innermost loop might
be concerned with feasibility study. The next loop with
requirements specification, the next one with design,
and so on.
• Each phase in this model is split into four sectors (or
quadrants). The following activities are carried out during
each phase of a spiral model.
Spiral model
Spiral model

• First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of
the phase.

• Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk
that the requirements are inappropriate, a prototype system may
be developed.
Spiral model

• Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving
the identified risks.
• -Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and plan the
next iteration around the spiral.
• Progressively more complete version of the software gets built
with each iteration around the spiral.
Spiral model
Spiral Model

• The spiral model is called a meta model since it

encompasses all other life cycle models.
• Risk handling is inherently built into this model. The
spiral model is suitable for development of technically
challenging software products that are prone to several
kinds of risks.
• However, this model is much more complex than the
other models – this is probably a factor deterring its use
in ordinary projects.
Summary
• What is Software Engineering
• Abstraction
• Decomposition
• Software Life Cycle Model
• Waterfall
• Prototype
• Spiral
Next Time
• Requirement Specifications and Analysis
• Functional Requirement
• Non-Functional Requirements