UNIT 1

Software Engineering is an engineering branch related to the evolution of software product using well
defined scientific principles, techniques, and procedures. The result of software engineering is an
effective and reliable software product.

Evolution of software engineering:

Following steps are involved in the evolution:

1. Software Engineering as an art

2. Software Engineering transition from art to craft
3. Software Engineering transition from craft to engineering discipline

Software Engineering as an Art means, this can be only learned by specific people and other people are
not allowed to work on them.

Software Engineering transition from art to craft when the area of people who know software
designing and coding will increase.

Software Engineering transition from craft to engineering discipline when everyone can learn software
engineering and coding irrespective of what they are doing as a degree course.

Components of a software:
1. Program
2. Documentation
3. Operating Procedures
Software characteristics:

1. Functionality- Refers to its ability to perform and function according to the design specifications.

2. Usability- Characterised by its ease of use. In other words, learning how to use the software should
require less effort or time.

3. Efficiency- Refers to the software’s ability to utilize human and system resources as much as
possible.

4. Reliability- Refers to software’s ability to operate without failure over a specified period of time
under certain conditions. It determines the ability of software to maintain its level of perform under
specified conditions.

5. Maintainability- Refers to how easily you can repair, improve and comprehend software code.

6. Portability- Ability to use a software in different environments.

Traditional/Conventional vs Software Engineering:

Software Development Life Cycle(SDLC):

1. PLANNING- Requirement analysis is done to plan the basic approach and to conduct product
feasibility study in the economical, operational and technical areas.

2. DEFINING- Clearly define and document the product requirements and get them approved from
the customer or the market analysts. This is done through an SRS(Software Requirement Specification)
document.

3. DESIGNING- Come out with the best architecture for the product to be developed based on the
requirements specified in SRS. Usually more than one design approach for the product architecture is
proposed and documented. A design approach clearly defines all the architectural modules of the
product.

4. BUILDING/CODING- Actual development of the software.

5. TESTING- Refers to the testing only stage of the product where products are reported, tracked,
fixed, and retested.

6. DEPLOYMENT- Released in the market.

Waterfall Model:

• First model to be introduced.

• Also referred to as linear-sequential life cycle model.
• Each phase must be completed before the next phase can begin.
• There is no overlapping in the phases.
• Typically, the outcome of one phase acts as the input for the next phase.
ADVANTAGES-

1. Simple and easy to understand.

2. Easy to manage.
3. Phases are processed and completed one at a time.
4. Works well for smaller projects.
DISADVANTAGES-

1. No working software produced until late during life cycle.

2. High amount of risk and uncertainty.
3. Not a good model for complex projects.

Prototype Model:

• Before carrying out the development of actual software, a working prototype of the system
should be built.
• A prototype is a small implementation of the system.
• Used when the customers do not know the exact project requirements beforehand.
• The prototype is refined until the customer us satisfied.

ADVANTAGES-

1. Reduces the risk of incorrect user requirements

2. Good where requirements are changing.
3. Support early product marketing.
4. Reduce maintenance cost.
DISADVANTAGES-

1. An unstable prototype often becomes the final product.

2. Requires extensive customer collaboration.

Spiral Model:

• One of the most important SDLC models.

• Provides support for Risk Handling.
• The exact loops of the spiral depends on the project.
• Each loop of the spiral is called a Phase of the software development process.
• The radius of the spiral at any point represents the cost of the project so far.
• Angular dimension represents the progress so far.
ADVANTAGES-

1. Risk Handling
2. Good for large projects.
3. Flexibility
4. Customer satisfaction.

DISADVANTAGES-

1.Complex
2. Expensive
3. Too much dependent on risk analysis.
4. No time management.

Iterative Model:

• It starts with a simple implementation of a small set of the software requirements and
iteratively enhances the evolving versions until the complete system is implemented and ready
to be deployed.
• It does not attempt to start with a full specification of requirements.
• Development begins by specifying and implementing just part of the software, which is then
reviewed to identify further requirements.
• The process is then repeated.
• At each iteration, design modifications are made, and new functional capabilities are added.

ADVANTAGES-

1. Testing and debugging during smaller iterations are easy.

2. A parallel development can be planned.
3. Easily acceptable to eve-changing needs of the project.
4. Risks are identified and resolved.

DISADVANTAGES-

1. Not suitable for smaller projects.

2. More resources may be required.
3. Requirement changes can cause over budget.
 UNIT 2

SOFTWARE REQUIREMENT SPECIFICATION:

1. This report lays a foundation for software engineering activities and is constructed when
entire requirements are elicited and analysed.

2. SRS is a formal report, which acts as a representation of software that enables the customer
to review whether it is according to their requirements.

3. It also comprises user requirements for a system as well as detailed specifications of the
system requirements.

CHARACTERISTICS/FEATURES OF GOOD SRS-

1. Correctness: Accurate description of the requirements.

2. Completeness: SRS is complete if it includes all essential requirements, whether relating to

functionality, performance, design, constraints, attributes.

3. Consistency: SRS is consistent if no individual elements are in conflict.

4. Unambiguous: SRS is unambiguous when every fixed requirement has only one unique
interpretation.

5. Ranking: SRS is ranked for importance and stability.

6. Modifiability: Capable of quickly obtaining changes to the system.

FEASIBILITY STUDY:

1. A study to evaluate feasibility of proposed project or system.

2. It is a measure of the software product in terms of how much beneficial product
development will be for the organization in a practical point of view.
3. To analyse whether the software will be right in terms of development, implantation,
contribution etc.
4. It is done to determine software’s technical and commercial viability before its development.

TYPES OF FEASIBILITY STUDY-

1. TECHNICAL FEASIBILITY: Both the current resources, hardware, and software, along
with required technology are analysed to develop a project. This study gives report whether
there exists correct required resources and technologies which will be used for project
development.

2. OPERATIONAL FEASIBILITY: Degree of providing service to requirements is analysed

along with how much easy product will be to operate and maintain after deployment.
 3. ECONOMIC FEASIBILITY: Cost and benefit of the project is analysed. What will be
cost of the project for development which includes all required cost for final development like
hardware and software resource, design etc.

4. LEGAL FEASIBILITY: Project is analysed in legality point of view.

5. SCHEDULE FEASIBILITY: Mainly timelines/deadlines are analysed for proposed

project.

CONTENTS IN A FEASIBILITY STUDY-

1. Project description: gather necessary background data

2. Market analysis: spend time exploring target audience and how they are likely to reach to
you
3. Technical specification: length of time required, machines that will be used
4. Risk analysis: analysing and understanding the weakness and risks associated with the
project
5. Describe the possible solutions: perform alternative analysis
6. Evaluation criteria: investigate solutions and match them with the selection criteria
7. Propose with the feasible solution: determine the economical and technically feasible
solution
8. Conclusion: summarize the aim of the project

PURPOSE- A feasibility study is designed to help decision-makers determine whether a

proposed project or investment is likely to be successful. It identifies both the known costs and
the expected benefits.

REQUIREMENTS ELICITATION:

1. Perhaps the most difficult, most error-prone and most communication intensive software
development.
2. Can be successful only through an effective customer-developer partnership.

REQUIREMENTS ELICITATION METHODS/TECHNIQUES-

1. INTERVIEWS: To understand customer’s expectations from the software. Representatives

from groups are selected based on their expertise and credibility. Interviews may be open ended
or structured.

2. BRAINSTORMING SESSIONS: It is a group technique. It is intended to generate lots of

new ideas hence providing a platform to share views. A highly trained facilitator handles group
conflicts. Every idea is documented so that everyone can see it.

3. FACILITATED APPLICATION SPECIFICATION TECHNIQUE (FAST):

Objective is to bridge the expectation gap—difference between what the developers think they
are supposed to build and what customers think they are going to get.
 4. QUALITY FUNCTION DEPLOYMENT: In this technique, customer satisfaction is of
prime concern, hence it emphasizes on the requirements which are valuable to the customer.
Three types of requirements are identified- Normal, expected, exciting.

5. USE CASE APPROACH: Combines text and pictures to provide a better understanding of
the requirements. The use case describes the ‘what’ of a system and not ‘how’.

VERIFICATION VS. VALIDATION

SEI-CMM

• Stands for Software Engineering Institute Capability Maturity Model.

• The SEI-CMM is a procedure used to develop and refine an organization’s software
development process.
• This model defines a five-level evolutionary stage of increasingly organized and consistently
more mature processes.
• It is used a benchmark to measure the maturity of an organization’s software process.

METHODS OF SEI-CMM

1. Capability Evaluation: Provides a way to assess the software process capability of an

organization. The results can be used to select a contractor.
2. Software Process Assessment: Used by an organization to improve its process capability.

LEVELS OF SEI-CMM

Level 1- Initial

• Ad hoc activities happen at this level.

• Very few or no processes are described and followed.
• Different engineers follow their different processes.
• Development becomes chaotic.
• Also called chaotic level.

Level 2- Repeatable

• The fundamental project management practices (like planning, tracking cost, scheduling etc)
are established.
• Size and cost estimation methods, like COCOMO are used.

Level 3- Defined

• The methods for project management and development activities are defined and
documented.
• Everybody understands their operations, roles, and responsibilities.
• The product and process qualities are not measured.
• ISO 9000 achieved at this level.

Level 4- Managed

• The focus is on software metrics.

• There are two types: Product and Process metrics

Level 5- Optimizing

• Process and product measurement data are collected and evaluated for continuous
improvement.
 UNIT 4

SOFTWARE TESTING

Software Testing is a process of identifying the correctness of the software by considering all its
attributes—reliability, scalability, portability, reusability, usability—and evaluating the execution of
software components for finding bugs or errors or defects.

It involves testing of all components under the required services to confirm that whether it is satisfying
the specified requirements or not. The process is also providing the client with information about the
quality of the software.

OBJECTIVES OF TESTING:

a. Finding defects which may be created by software developers.

b. Gain confidence in providing information of software quality.
c. To make sure that end result meets the business and user requirements.
d. Satisfies the Business Requirement Specification and System Requirement Specification.
e. To gain confidence of the customer.

TYPES OF SOFTWARE TESTING:

Manual Testing: The process of checking the functionality of an application as per the customer
needs without taking any help of automation tools.

White Box Testing: It is a type of testing which analyses internal structure, internal design, code, and
working of the software to verify output flow and improve design, usability and security. Developers do
white box testing.
Black Box Testing: Used to examine the functionality of the software instead of bothering about the
internal structure of the software.

Functional Testing: is performed to confirm that the functionality of an application or system is

behaving as expected. Done to verify all the functional requirements. Example: Unit Testing,
Regression Testing, Integration Testing, Black box testing, White box testing, Alpha and Beta Testing.
Non-functional Testing: Non-functional testing is a type of software testing to test non-functional
parameters such as reliability, load test, performance and accountability of the software. The
parameters of non-functional testing are never tested before the functional testing.

Unit Testing: Divide the software into separate units/modules/components and test each unit
separately, to evaluate the performance of each unit.

STEP 1: Create test cases

STEP 2: Review test cases
STEP 3: Define measures(parameters)
STEP 4: Execute test cases

Integration Testing: Two or more modules that have passed unit testing are integrated to test them
again as one unit, to verify whether these integrated units work as specified.

System Testing: Complete and integrated software is tested as a whole.

Acceptance Testing: Conducted to ensure whether the requirements of the users are fulfilled prior to
its delivery and the software is working in the user’s working environment. Types:

a. User Acceptance Testing

b. Business Acceptance Testing
c. Contract Acceptance Testing

Performance Testing: It determines how a system performs under a given workload. It is performed
to measure stability, speed, scalability, and responsiveness.

Load Testing: It measures system’s performance when the workload is increased.

Stress Testing: It measures system’s performance outside of normal conditions of the software
environment.

Spike Testing: When workload increases beyond normal conditions, spike testing is used.

Top-down Testing: Testing is conducted from main module to sub modules. In some conditions if
sub module is not developed, a temporary program called stub is used to stimulate the sub-module.
Bottom-up Testing: Testing is conducted from sub modules to main module. If the main module is
not developed, a temporary program called driver is used to stimulate main module.
 STUB- Stubs are developed by software developers to use them in place of modules, if the
respective modules aren’t developed, missing in developing stage, or are unavailable currently,
while Top-down testing of modules. A Stub simulates module which has all the capabilities of
the unavailable module. Stubs are used when the lower-level modules are needed but are
unavailable currently.

DRIVER- Drivers serve the same purpose as stubs, but drivers are used in Bottom-up
integration testing and are also more complex than stubs. Drivers are also used when some
modules are missing and unavailable at time of testing of a specific module because of some
unavoidable reasons, to act in absence of required module. Drivers are used when high-level
modules are missing

Alpha Testing: Performed to identify bugs before releasing the product to real users or to the public.

Beta Testing: Performed by real users of the software application in a real environment.
FORMAL TECHNICAL REVIEW

Software quality control activity performed by software engineers.

 UNIT 5

SOFTWARE EVOLUTION

• In software engineering, software evolution is referred to as the process of developing,

maintaining, and updating the software or various reasons.
• Software changes are inevitable because there are many factors that change during the life cycle
of a piece of a software.
• Some of these factors include:

a. Requirement changes
b. Environment changes
c. Errors or security breaches
d. New equipment added or removed
e. Improvements to the system

• Software is considered a very critical asset, and management wants to ensure they employ a
team of software engineers who are devoted to ensuring that the software stays up to date with
ever evolving changes.

NEED FOR SOFTWARE MAINTENANCE

1. To correct errors
2. To improve the design
3. Implement enhancements
4. To interface with evolving systems
5. Retire software
6. User requirements are changing
7. Improve its response time

TYPES OF SOFTWARE MAINTENANCE

1. PREVENTIVE MAINTENANCE: This type of maintenance includes

modifications and updations to prevent future problems. Its goal is to attend problems,
which are not significant at this moment but may cause serious issues in future.
2. CORRECTIVE MAINTENANCE: This type of maintenance includes correcting
bugs observed while the system is in use, or to enhance the performance of the system.
3. PERFECTIVE MAINTENANCE: Maintenance to support the new features that
the users want or to change different types of functionalities of the system according to
the customer’s demands.
4. ADAPTIVE MAINTENANCE: Include modifications and updations when the
customers need the product to run on new platforms, or new operating systems.

SOFTWARE RE-ENGINEERING

Software Re-engineering is a process of software development which is done to improve the

maintainability of a software system. Re-engineering is the examination and alteration of a system to
reconstitute it in a new form. This process encompasses a combination of sub-processes like reverse
engineering, forward engineering, reconstructing etc.
OBJECTIVES

1. To describe a cost-effective option for system evolution.

2. To describe the activities involved in the software maintenance process.
3. To distinguish between software and data re-engineering and to explain the problems of
data re-engineering.

STEPS INVOLVED

1. Inventory analysis
2. Document reconstruction
3. Reverse engineering
4. Code reconstruction
5. Data reconstruction
6. Forward engineering

RE-ENGINEERING COST FACTORS

1. Quality of the software

2. Tool support available
3. Extent of the required data conversion
4. Availability of expert staff
SOFTWARE REVERSE ENGINEERING

Software Reverse engineering is the process of recovering the design, requirement specifications and
functions of a product from an analysis of its code.

GOALS

1. Cope with complexity

2. Recover lost information
3. Detect side effects
4. Produce higher abstraction
5. Facilitate reuse

STEPS

1. Collection of information
 2. Examining the information
3. Extracting the structure
4. Recording the functionality
5. Recording data flow
6. Recording control flow
7. Review extracted design
8. Generate documentation

CASE TOOLS

• CASE stands for Computer Aided Software Engineering.

• CASE tools are a set of software application programs, which are used to automate SDLC
activities.
• Used by software project managers, analysts, and engineers to develop software.

COMPONENTS OF CASE TOOLS

1. Central repository: stores all the information in a common, integrated, and consistent form.
2. Upper case tools: used in planning, analysis, and design stages of SDLC.
3. Lower case tools: used in implementation, testing and maintenance.
4. Integrated case tools: used in all stages of SDLC.

TYPES OF CASE TOOLS

1. DIAGRAM TOOLS- These tools are used to represent system components, data and
control flow among various software components and system structure in a graphical form.
For example: Flow chart maker tool.

2. PROCESS MODELLING TOOLS- A method to create software process model, which

is used to develop the software. It helps the managers to choose a process model or modify
it as per the requirements. For example: EPF Composer.
3. PROJECT MANAGEMENT TOOLS- These tools are used for project planning, cost
and effort estimation, project scheduling and resource planning. They help in storing and
sharing project information in real-time throughout the organization. For example: Creative
Pro Office.

4. DOCUMENTATION TOOLS- Documentation in a software starts prior to the software

process, goes throughout all phases of SDLC and after the completion of the software.
Documentation tools generate documents for technical users and end users. For example:
Doxygen.

5. ANALYSIS TOOLS- These tools help to gather requirements, automatically check for any
inconsistency, inaccuracy in the diagrams, data redundancies or erroneous omissions. For
example: Accept 360.

6. DESIGN TOOLS- These tools help software developers to design the block structure of
the software, which may further be broken down in smaller modules using refinement
techniques. For example: Animated Software Design

7. CONFIGURATION MANAGEMENT TOOLS- An instance of software is released

under one version. Example: Fossil. Configuration management tools deal with:

a. Version and revision management

b. Baseline configuration management
c. Change control management

8. CHANGE CONTROL TOOLS- These tools are considered as a part of configuration

management tools. They deal with changes made to the software after its baseline is fixed or
when the software is first released. They automate change tracking, file management, code
management and more.

9. PROGRAMMING TOOLS- Consists of programming environments like IDE, in-built

modules library and simulation tools. For example: Eclipse

10. PROTOTYPING TOOLS- A simulated version of the intended software product. It

provides initial look and feel of the product. For example: Serena prototype composer.

11. WEB DEVELOPMENT TOOLS- These tools assist in designing web pages with all
allied elements like forms, texts, scripts etc. For example: Brackets.

12. QUALITY ASSURANCE TOOLS- Monitoring the engineering process and methods
adopted to develop the software product to ensure conformance of quality as per
organization standards.

13. MAINTENANCE TOOLS- Includes modifications in the software product after it is

delivered. For example: HP quality center.
COCOMO MODEL

• COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e., Lines of
Code.
• It is a model that estimates the effort and time taken to complete the model based on the size
of the source code.
• It is often used as a process of reliably predicting the various parameters associated with
making a project such as size, effort, cost, time and quality.
• The key parameters are Effort and Time.
• Effort is the amount of labour that will be required to complete a task. Measured in person-
month units.
• Time means the amount of time required to complete the job, which is proportional to the
effort out in.

CHARACTERISTIC OF DIFFERENT SYSTEM TYPES

1. ORGANIC- A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past, and the team
members have a nominal experience. Project size is typically in the range of 2-50 KLOC. Very
little innovation is involved. The deadline for organic type if not very tight.
2. SEMI-DETACHED- A software project is said to be Semi-detached type if the vital
characteristics such as team size, experience and knowledge of the various programming
environment lie in between that of organic and embedded. They are comparatively less familiar
and difficult to develop. Require more guidance and experience. Project size is typically in the
range 50-300 KLOC. Medium level of innovation is involved. The deadline is also medium.
3. EMBEDDED- A software project requiring the highest level of complexity, creativity and
experience requirement fall under this category. Requires a larger team size, developers need to
be sufficiently experienced and creative to develop such complex models. Project size is
typically over 300 KLOC. Significant innovation is involved. Deadlines are very tight.

TYPES OF COCOMO MODELS

1. Basic COCOMO model

2. Intermediate COCOMO model
3. Detailed COCOMO model

COMPONENTS CALCULATED IN COCOMO

Effort = a(KLOC)b
Time = c(Effort)d

NUMERICALS

1. A simple standalone software utility is developed in C programming by a team of

software experts for a computer running Linux and the overall size of the software is
estimated to be 20000 lines of code. Considering (a, b) = (2.4, 1.05) as multiplicative
and exponential factor for the basic COCOMO effort estimation equation and (c, d) =
(2.5, 0.38) as multiplicative and exponential factor for the basic COCOMO development
time estimation equation, approximately how long does the software project takes to
complete.

20000 LOC= 20 KLOC

Effort = a(KLOC)b = 2.4 * (20)1.05 = 55.756 person month

Time = c(Effort)d = 2.5 * (55.756)0.38 = 11.52 months

2. Suppose that a project was estimated to be 400 KLOC. Calculate effort and time for
each of the 3 modes of development (Organic, Semi-detached and Embedded)

FOR ORGANIC:

Effort = a(KLOC)b = 2.4 * (400)1.05 = 1295 person-month

Time = c(Effort)d = 2.5 * (1295)0.38 = 38 months

FOR SEMI-DETACHED:

Effort = 3.0 * (400)1.12 = 2462 person-month

Time = 2.5 * (2462)0.35 = 38.4 months

FOR EMBEDDED:

Effort = 3.6 * (400)1.20 = 4772 person-month

Time = 2.5 * (4772)0.32 = 38 months