Software Engineering (EIT-252)

Syllabus
Unit-I: Introduction
Introduction to Software Engineering, Software Components,
Software Characteristics, Software Crisis, Software
Engineering Processes, Similarity and Differences from
Conventional Engineering Processes, Software Development
Life Cycle (SDLC) Models: Water Fall Model, Prototype
Model, Spiral Model, Evolutionary Development Models,
Iterative Enhancement Models, Selection of Software
Development Models.
Unit-II: Software Requirement Specifications (SRS)
Requirement Engineering Process: Elicitation, Analysis,
Documentation, Review and Management of User Needs,
Feasibility Study, Information Modeling, Data Flow Diagrams,
Entity Relationship Diagrams, Decision Tables, SRS Document,
IEEE Standards for SRS.
Unit-III: Software Design
Basic Concept of Software Design, Architectural Design, Low
Level Design: Modularization, Design Structure Charts, Pseudo
Codes, Flow Charts, Coupling and Cohesion Measures, Design
Strategies: Function Oriented Design, Object Oriented Design,
Top-Down and Bottom-Up Design. Software Measurement and
Metrics: Various Size Oriented Measures: Halestead’s Software
Science, Function Point (FP) Based Measures, Cyclomatic
Complexity Measures: Control Flow Graphs.
Unit-IV: Software Testing
Software Testing Objectives, Unit Testing, Integration Testing,
Acceptance Testing, Regression Testing, Testing for
Functionality and Testing for Performance, Top-Down and
Bottom-Up Testing Strategies: Test Drivers and Test Stubs,
Structural Testing (White Box Testing), Functional Testing
(Black Box Testing), Test Data Suit Preparation, Alpha and Beta
Testing of Products. Static Testing Strategies: Formal Technical
Reviews (Peer Reviews), Walk Through, Code Inspection,
Compliance with Design and Coding Standards.
Unit-V: Software Maintenance and Software Project Management
Software as an Evolutionary Entity, Need for Maintenance, Categories
of Maintenance: Preventive, Corrective, Adaptive and Perfective
Maintenance, Cost of Maintenance, Software Re-Engineering,
Reverse Engineering, Software Configuration Management Activities,
Change Control Process, Software Version Control, Defect Detection
and Removal: Defect Amplification Model, An Overview of CASE
Tools.
Text and Reference Books:
1. R. S. Pressman, Software Engineering: A Practitioners Approach,
McGraw Hill Publication.
2. K. K. Aggarwal and Yogesh Singh, Software Engineering, New Age
International Publishers.
3. Rajib Mall, Fundamentals of Software Engineering, PHI Publication.
4. Carlo Ghezzi, M. Jarayeri, D. Manodrioli, Fundamentals of Software
Engineering, PHI Publication.
5. Ian Sommerville, Software Engineering, Addison Wesley.
6. Pankaj Jalote, Software Engineering, Narosa Publication
7. Pfleeger, Software Engineering, Macmillan Publication.
8. A. Leon and M. Leon, Fundamentals of Software Engineering, Vikas
Publication.
 Lab Work
Lab exercises or a Mini Project (as per list
given below) to be carried out using
languages like C++, Java, C# and tools like
Visio, ARGOUML, Rational Rose etc. Design
and Implementation of an Object based
application using any one of the above
languages/tools is desirable.
• Hotel Automation System
• Book Shop Automation Software
• Word processing Software
 Lab Work
• Software Component Cataloguing
Software
• Payroll System
• Banking System
• Purchase Order System
• Library Management System
• Railway Reservation System
• Bill Tracking System
• University Admission System
• Estate Management System.
 Course Outcomes (COs)
• Understand and explain various concepts of
software engineering and software life cycle
development models. (Understand)
• Prepare SRS and Compute cost and effort
required to complete a given project, using various
estimation techniques and models. (Apply)
• Understand various concepts of Software design
and Construct Data Flow Diagrams, Data
Dictionaries and UML diagrams for a given
software requirement specification. (Understand,
Apply)
 Course Outcomes (COs)
• Understand various testing techniques and use
these concepts to design optimal test cases.
(Understand, Apply, Analyze)
• Understand software configuration management,
version control, reverse engineering, defect
tracking etc. (Understand)
• Build a project report as a team which contains
the requirement specification, plan, schedule and
design documents based on the knowledge of
software development lifecycle. (Apply)
Software Products
 Software Engineering
➢ A strategy for producing high quality
software, which satisfies customer
requirements and is within budget and
schedule.
➢ Software engineering encompasses a
process, management techniques,
technical methods, and the use of
tools.
 Software Engineering
• Deals with the management techniques
required to

Plan Organize

Control Monitor
 Software does not Wear Out
• Software does not wear out rather it
becomes more reliable with time until it
finally retires.
• But, ultimately it becomes obsolete due to
change in environment for which it was
developed.
• Software may finally retire due to
environment changes, new requirements,
and new expectations etc.
 Software is not Manufactured
• Life of a software is from the concept exploration to
the retirement.
• It involves one time development and continuous
maintenance efforts to keep it operational.
• Making multiple copies of software does not involve
any additional cost.
• In H/W products every product costs us due to raw
material and other processing expenses.
• Catalogue of hardware components used during
manufacturing of hardware systems.
• There is no assembly line in software
development. Hence it is not manufactured.
 Reusability of Components
• For manufacturing H/W systems we may not require to
manufacture any components rather they need to be
collected off the self and properly assembled.
• We may have standard quality guidelines and
effective processes to produce a good quality
product.
• But, in software every product is new and requires
start from the scratch. No reusability.
• However, concept of reusability is now introduced
through component oriented design concept.
• In h/w reusability of components is a natural part of
engineering process but in s/w it is just a humble
beginning.
 Software is Flexible
• Everyone considers software as flexible and
assumes that it can be developed for
everything.
• Software being flexible, every change can be
accommodated at any stage of development of
software.
• This myth of implementing almost “everything”
has made the software development difficult to
plan, monitor and control and leads to “software
crisis”.
 Software Crisis
• Project running over budget.
• Project running over time.
• Poor quality of the developed software.
• Insufficient software productivity.
• Software does not meet requirements.
• Software failed or could not be delivered to
the customer.
• Software is unmanageable and code is
difficult to maintain.
 Software Crisis
(Need of Software Engineering)
• A survey conducted by IBM in 2000 reports that
– 31% of the projects get cancelled before
completion.
– 53% of the projects exceed to the budget
schedule even up to 189%.
– 94% of the projects have many restarts.
• Software failures receive a lot more publicity than
software engineering success stories.
 Software Crisis
• Software cost has not dropped as rapidly as the
hardware cost.
• Developers in H/W industry have significantly
affected cost, quality, productivity and reliability of
hardware.
• In S/w industry, there is no single development
either in technology or in mgmt. technique that by
itself promises even one order of magnitude
improvement in the productivity, cost and reliability.
• Use of CASE tools was thought to be a
development giving boost to above factors but the
results are highly un satisfactory.
 Software Process
• Software process is basically the way in which
software is developed.
• To survive in the competitive s/w business
requires more than hiring smart &
knowledgeable developers and latest tools.
• Additionally, effective development process is
also required to substantially improve the quality,
productivity and maintenance efforts.
• It is very difficult to improve the software process
due to certain reasons.
 Not Enough Time
• Unrealistic schedules leave insufficient time to
do the essential project management work.
• No software groups are sitting around with plenty
of time to explore what is wrong with the
current development process.
• Customers and managers demand for high
productivity and quality in minimum time.
• There is almost always shortage of time and
pressure on the developers. As a consequence
the first release may be in time but they may have
to ship the next release immediately after fixing
the bugs recently discovered.
 Lack of Knowledge
• Software developers are not familiar with the
industry best practices.
• Software developers do not devote time in
studying literature on best known ways of
software development.
• They just learn Java, VB, or ORACLE but don’t
look for anything on process, testing, or quality.
• Process improvement frameworks like CMM, ISO
9001 are not in realistic use.
 Wrong Motivation
• Process improvement initiatives are launched
with wrong reasons like contractor demand, or
directions of the senior manger.
• Basic motivation should be to remove present
difficulties with the process.
• Most of the people should be motivated by the
prospect of meeting their commitments,
improving customer satisfaction, and
delivering excellent product.
• Reasons for implementation of an
improvement framework should be clearly
explained to the developers.
 Insufficient Commitment
• Many times the process improvement initiatives fail due
to insufficient commitment.
• It starts with the process assessment but fails to follow
through with the actual changes.
• Management sets no expectations, devote insufficient
resources, write no improvement plans, develop no
roadmap and pilot no new processes.
• Process improvements will not be visible immediately
rather may have a drop in productivity due to efforts for
the current demand being siphoned of for the better
future.
• At this stage, companies should not give up, but should
take motivation from the success stories of good
companies.
 Software Myths
• Generally divided in three groups: Management
myths, Customers myths and Practitioners
myths.
• Getting behind the schedule can be make up by
introducing more persons: Sometimes, it may
further delay because of time required for training
the new comers, cross talks etc. - M
• A general statement of objective is sufficient for
software development, the details can be easily
incorporated later: Incorporation of details is
difficult and costly. - C
• Software being flexible can be easily modified:
Cost of change is very high. -M
 Software Myths
• Quality can be assessed only after getting the running
program: Quality assurance is an umbrella activity which
begins since inception and covers all phases of
development. FTR’s during all phases are conducted to
improve quality. - P
• Once the software has been written and get to work our
job is over: Sooner you begin to write the code the longer
it will take you to get done. - P
• Working program is the only deliverable: Documentation
including user and operation manuals are also to be
delivered. - P
• Software Engineering makes the things complex and may
slow down the process: Principles and practices of SE
improve the process and quality of the software. - P
Productivity and People
Early Error Detection
Saves Money
 Software Applications
• System Software: Software used to improve efficiency of other
s/w or h/w. e.g. Compilers, Editors, Device Drivers, OS.
• Real Time Software: Used to monitor, control and analyze the
real world events as they occur.
• Embedded Software: Placed in a ROM controls various
functions of a system.
• Business Software: Used to process business applications.
e.g. Payroll, Employee Management System, Library
Management System, Security System.
• AI Software: Used to solve non algorithmic problems. e.g.
Expert System, Game playing.
• Engineering and Scientific Software: Huge computing
required for data processing. CAD/CAM Packages, SPSS,
MATLAB
• Web Based Software: Web application s/w like HTML, CGI,
Java, Perl, DHTML
Software Applications
 Software Engineering Phases
• Definition Phase
– Focuses on What (information engineering,
software project planning, requirements
analysis).
• Development Phase
– Focuses on How (software design, code
generation, software testing).
• Support Phase
– Focuses on Changes (corrective maintenance,
adaptive maintenance, perfective
maintenance, preventive maintenance).
Software Life Cycle Phases
1. Requirements, analysis, and design phase.
2. System design phase.
3. Program design phase.
4. Program implementation phase.
5. Unit testing phase.
6. Integration testing phase.
7. System testing phase.
8. System delivery.
9. Maintenance.
 S.E. Management Spectrum
4 P’s
• People
• Product
• Process
• Project
 Project Effort Distribution
Generally accepted guidelines are:
02-03 % planning
10-25 % requirements analysis
20-25 % design
15-20 % coding
30-40 % testing and debugging
40-20-40 Rule
 5W2H Principle
• Why is the system being developed (Scope) ?
• What will be done (SRS) ?
• When it will be done (Schedule) ?
• Who is responsible for a function (Resource)?
• Where are they organizationally located
(Organization) ?
• How will the job be done technically and
managerially (Process) ?
• How much of each resource is needed
(Estimation) ?
 Linear Sequential Model
or Waterfall Model
Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance
 Waterfall Model
• The software development activity is divided into
different phases.
• Each phase consists of a series of tasks and has
different objectives.
• Output of one phase becomes the input of the next
phase.
• It is mandatory for a phase to be completed before
the next phase starts. Thus, there is no overlapping
of the phase activities/tasks.
• Waterfall model is the pioneer of the SDLC
processes.
• It was the first model which was widely used in the
software industry.
 Advantages and Disadvantages
• Easy to understand and reinforces the notion of “define
before design” and “design before code”.
• Suitable for smaller projects. Does not scale up well for
very large projects due to high risk.
• Since the phases are rigid and precise, one phase is done
one at a time, it is easy to maintain.
• The entry and exit criteria are well defined, so it is easy
and systematic to proceed with quality.
• Requires defining all the requirements in the beginning
which is very difficult. Not suitable for accommodating any
changes at later stages.
• Working version of the system is available very late.
• Suitable for situations where the requirements and their
implementations are fixed and well understood.
 Prototype Model
Concurrent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
 Prototyping Model
Requirements
Users get a feel of the
actual system and
Focuses only on visible developers get to build
aspects and not on
Quick design something immediately
quality /efficiency
parameters Refinement of
Requirements as
Implementation per suggestions
Ideally prototype serves as
a mechanism for identifying
requirements precisely
Customer Evaluation

Now engineer the product using usual

phases of software development
 PM Features
• Working prototype is developed as per the current
available requirements. Prototype is a toy
implementation of the system.
• It has limited functionality, low reliability, and poor
performance (stripped down version of the final
product).
• Refined versions of prototype are more and more
suitable.
• Final prototype approved by the customer can be
used to draw requirements for the ultimate product
development through WFM.
 Advantages and Disadvantages
• Reduce the risk of incorrect user requirements and
suitable where requirements are changing.
• Regular visible process aids management .
• Support early product marketing and Reduce
Maintenance cost.
• An unstable/badly implemented prototype often
becomes the final product.
• Require extensive customer collaboration which may
not be always available.
• Special tools & techniques are required to build a
prototype which are expensive. But still the overall cost
is relatively low because of the experience gained.
• It is a time-consuming process.
 Incremental/Iterative
Enhancement Model (IEM)

Define outline Assign requirements Design system

requirements to increments architecture

Develop system Validate Integrate Validate

increment increment increment system
Final
system
System incomplete
 Incremental/Iterative
Enhancement Model (IEM)
• Rather than delivering the system as a single
unit, the development and delivery is broken
down into increments.
• Each increment/version incorporates part of the
required functionality.
• User requirements are prioritised and the highest
priority requirements are included in early
increments.
• Once the development of an increment is started,
its requirements are “frozen” while requirements
for later increments can continue to evolve.
 IEM Advantages/Disadvantages
• Useful functionality is delivered with each
increment, so customers derive value early.
• Early increments act as a prototype to help elicit
requirements for later increments.
• There is Lower risk of overall project failure.
• The highest priority system services tend to
receive the most testing.
• Not suitable for the situation where requirements
may NOT be partitionable into stand-alone
increments.
 Evolutionary Development Model
• Evolutionary process model resembles the iterative
enhancement model.
• The same phases as defined in the waterfall model
occur here in a cyclical fashion.
• This model differs from the IEM in the sense that
this does not require a working/useful product at
the end of each cycle.
• In EDM, requirements are implemented by category
rather than by priority.
• For example, in a simple DB application, one cycle
might implement the GUI, another file manipulation,
another queries and yet another updates.
 Advantages/Disadvantages
• Use of EDM brings a significant reduction in risk for
software projects.
• EDM can reduce costs by providing a structured,
disciplined avenue for experimentation.
• EDM allows the marketing department access to early
deliveries, facilitating the development of documentation
and demonstration.
• Better fit the product to user needs and market
requirements.
• Manage project risk with the definition of early cycle
content.
• Uncover key issues early and focus attention
appropriately.
• Increase management visibility of project progress.
 Rapid Action Development Model
• This is an incremental process model developed by
IBM in 1980.
• In this model, user involvement is essential from
requirement phase to delivery of the product which
ensures users expectations and perspective in
requirements elicitation, analysis and design of the
product.
• The process starts with developing a rapid
prototype and giving it to the user for evaluation.
• The prototype is then refined on the basis of user
feedback and the process continues till the
requirements are finalized.
 Rapid Action Development Model
• It involves four phases namely Requirements
Planning, User Description, Construction, and Cut Over
with participation of the user throughout.
• Requirements are captured using any group
elicitation technique (FAST,QFD, Brainstorming).
• Joint Teams of developers and users prepare,
understand and review the requirements.
• Construction phase combines the detailed design,
coding and testing phases of WFM.
• Sophisticated automation tools like code generators,
screen generators etc. are used in the construction.
• In cut over phase, acceptance testing by the users,
installation of the system, and user training is done.
 Advantages/Disadvantages
• Due to fast delivery of the rapid prototype, quick initial
views of the product are possible.
• The development time is reduced due to the use of
powerful development tools.
• Continuous involvement of the customer increases the
product acceptability.
• Model is not suitable in situations where user
involvement is limited.
• Development time can not be reduced in an environment
where reusable components are not available.
• Highly specialised and skilled developers are needed
and such developers may not be available very easily.
• It may not be effective if system can not be properly
modularised.
 Spiral Model

Determination of Analyze alternatives and

objectives, alternatives attempt to identify &
and constraints resolve the risks

Evaluation by the
customer and feedback
Actual product
reporting development and testing
 Spiral Model
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analy sis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
 SM Features
• Spiral Model was proposed by Barry Boehm in
1986 by incorporating Project Risk factor in life
cycle model.
• Entire development space is supposed to be
divided into 4-6 regions.
• Radial dimension represents the cumulative cost
of development. Each path around the spiral is
indicative of the increased cost.
• Angular dimension represents the progress made
in completing each cycle.
• Each loop from x-axis clockwise through 360
degree represents one phase.
 SM Features
• One phase is usually split into four sectors of major
activities like Planning, Risk Analysis, Development,
and Assessment (Customer Evaluation)
• During first phase planning is done, risks are
analyzed, prototypes are built, and customer
evaluates the prototype. In subsequent phases more
refined prototypes are built.
• Good feature is that each phase is completed with a
review /evaluation by the concerned people.
• It includes quality objectives in the development by
eliminating error in the early phases through
evaluation process.
 Advantages/Disadvantages
• This model accommodates good features of other
life cycle models. It becomes equivalent to another
life cycle model in appropriate situations.
• The risk analysis and validation steps eliminate
errors in the early phases of development and thus
incorporate s/w quality objectives in development
process.
• Difficulties with the model include lack of explicit
process guidance in determining objectives,
constraints, alternatives, relying on risk
assessment expertise and providing more
flexibility.
Fourth Generation Language
Techniques
Specify some characteristic
of the s/w at high level, tool
automatically generates source
codes based on specifications.
 4 GT Include
• Non Procedural Languages
• Query Languages
• Report Generators
• Graphic Utilities
• Spread Sheets
• Code Generators
• Data Processors
 4 GT Model

Code Generator ?

Requirements Formal Formal Integration and

definition specification transformation system testing

Not realistic, unless “Formal specification” is

source code…
 Formal transformations

Formal transformations
T1 T2 T3 T4

Formal R1 Executable
R2 R3
specification program

P1 P2 P3 P4

Proofs of transformation correctness

 Advantages/Disadvantages
• Small software may be directly implemented
from the requirement specifications.
• Reduction in the development time.
• Increase in productivity.
• 4 GT is not easy to use.
• Codes generated are generally inefficient.
• Normally used for business information system
applications and for designing large projects.