B21DC 4.

1: SOFTWARE ENGINEERING
THEORY
Total Teaching Hours: 45

No. of Hours per Week: 3

(3 credits)

Course Content

Sl. Unit/ Content Number Skills

No. chapter of hours Developed
title

1 Unit- I Introduction: Software Products and Software process, 10 Hrs Cognitive /

Process models: Waterfall model, Analytical /
Synthesis
Evolutionary Development, Bohemia‟s Spiral model,
Skills
RAD Model, Agile Model, Overview of risk
management, Process Visibility, Professional
responsibility. Computer based System Engineering:
Systems and their environment, System Procurement,
System Engineering Process, System architecture
modelling. Human Factors, System reliability
Engineering.

Requirements and Specification: The requirement

Engineering Process, The Software requirement
document, Validation of Evolution of requirements,
Viewpoint – oriented & method based analysis ,
system contexts , Social & organizational factors. Data
flow , Semantic, Objects, models , Requirement
Specification, Functional and Nonfunctional
requirement.

2 Unit- II Software Prototyping: Prototyping in software 12 Hrs Cognitive /

process, Prototyping techniques, User interface Synthesis
prototyping. Software Design: Design Process, Design Skills
Strategies, Design Quality , System Structuring control
models, Modular decomposition , Domain Specific
architecture.

Object Oriented & function oriented design: Objects,

object Classes and inheritance Object identification,
 An object oriented design example, Concurrent
Objects, Data flow design Structural decomposition,
Detailed Design, A Comparison of design Strategies.

User interface design: Design Principles, User System

interaction, Information Presentation, User Guidance,
Interface Evaluation.

3 Unit- III Software Reliability and reusability : Software 10 Hrs Cognitive /

reliability metrics , Software reliability Specification , Synthesis
Statistical testing ,Reliability Growth modeling, Fault Skills
avoidance & tolerance, Exception handling &
defensive programming , Software development with
reuse, Software‟ development for reuse , Generator
based reuse, Application System Portability.

4 Unit- IV Software Verification and Validation : The testing 13 Hrs Cognitive /

Process , Test Planning & Strategies, Black Box , Analytical /
Structural, interface testing , Program inspections , Synthesis
Mathematically based verification, Static analysis Skills
tools, Cleanroom software development. Management
Issues: Project management, Quality management,
Software cost estimation, Project Scheduling- work
tasks, timeline charts and CPM, PERT , Software
maintenance.

Books for Reference:

1. Ian Sommerville. (2010). Software Engineering. (9th Edition). Pearson Education

Ltd.
2. Roger S. Pressman. (2010). Software Engineering- A Practitioner’s approach. (7th
Edition). McGraw-Hill Publication.
3. Pankaj Jalote. (2013). An integrated approach to Software Engineering. (3rd
Edition). Narosa Publishing House.
Web Resources:

1. http://ww25.softwareengineering-9.com/

2. https://www.theforage.com/blog/careers/software-engineering-resources
What is a Software?
The software is basically a set of instructions or commands that tell a computer what to do.
In other words, the software is a computer program that provides a set of instructions to
execute a user’s commands and tell the computer what to do. For example like MS-
Word, MS-Excel, PowerPoint, etc.

Software Engineering is a subdomain of Engineering in which you learn to

develop, design, test, and maintain software using a systematic and structured
approach. Software is a collection of programs. And that programs are
developed by software engineers.

What are Software Processes?

Software processes in software engineering refer to the set of guidelines and
techniques used to develop and maintain software. Some examples of software
processes include:
Waterfall: a linear, sequential approach to software development, with distinct
phases such as requirements gathering, design, implementation, testing, and
maintenance.
Agile: a flexible, iterative approach to software development, with an emphasis
on rapid prototyping and continuous delivery.

A software product is software that has been developed and maintained to be

sold or distributed on a market.
Examples:- google Maps, Tally etc
Waterfall Model

The Waterfall Model is a classical software development methodology. It was first

introduced by Winston W. Royce in 1970. It is a linear and sequential approach to software
development that consists of several phases. It must be completed in a specific order. This
classical waterfall model is simple and idealistic. It was once very popular. Today, it is not
that popularly used. However, it is important because most other types of software
development life cycle models are a derivative of this.

Phases of Waterfall Model

The Waterfall Model has six phases which are:

1. Requirements: The first phase involves gathering requirements from stakeholders

and analyzing them to understand the scope and objectives of the project.

Requirement gathering and analysis: Firstly, all the requirements regarding the
software are gathered from the customer and then the gathered requirements are
analyzed. The goal of the analysis part is to remove incompleteness and
inconsistencies.
 Requirement specification: These analyzed requirements are documented in a
software requirement specification (SRS) document. SRS document serves as a
contract between the development team and customers. Any future dispute between
the customers and the developers can be settled by examining the SRS document.

2. Design: It is graphical representation of the requirements.This involves creating a

detailed design document that outlines the software architecture, user interface, and
system components.
It includes high-level and detailed design as well as the overall software architecture.
A Software Design Document is used to document all of this effort (SDD).

3. Development: The Development phase include implementation involves coding the

software based on the design specifications. This phase also includes unit testing to
ensure that each component of the software is working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that it meets
the requirements and is free from defects.
5. Deployment: Once the software has been tested and approved, it is deployed to the
production environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance, which
involves fixing any issues that arise after the software has been deployed and
ensuring that it continues to meet the requirements over time. The effort spent on
maintenance is 60% of the total effort spent to develop a full software.

Importance of Waterfall Model

Following are the importance of waterfall model:
1. Clarity and Simplicity: The linear form of the Waterfall Model offers a simple and
unambiguous foundation for project development.
2. Clearly Defined Phases: The Waterfall Model phases each have unique inputs and
outputs, guaranteeing a planned development with obvious checkpoints.
3. Documentation: A focus on thorough documentation helps with software
comprehension, maintenance, and future growth.
4. Stability in Requirements: Suitable for projects when the requirements are clear and
stable, reducing modifications as the project progresses.

Disadvantages of Waterfall Model

No Feedback Path
Limited Stakeholder Involvement
Difficult to accommodate Change Requests
 Spiral Model

What is Spiral Model in Software Engineering?

The Spiral Model is one of the most important Software Development Life Cycle
models. The Spiral Model is a combination of the waterfall model and the iterative model.
The Spiral Model was first proposed by Barry Boehm in the year 1986-88.

Each phase of the Spiral Model is divided into four quadrants as shown in the above
figure. The functions of these four quadrants are discussed below:

Objectives determination and identify alternative solutions: Requirements are

gathered from the customers and the objectives are identified, elaborated, and analyzed at the
start of every phase. Then alternative solutions possible for the phase are proposed in this
quadrant.
 Identify and resolve Risks: During the second quadrant, all the possible solutions
are evaluated to select the best possible solution. Then the risks associated with that solution
are identified and the risks are resolved using the best possible strategy. At the end of this
quadrant, the Prototype is built for the best possible solution.
Develop the next version of the Product: During the third quadrant, the identified
features are developed and verified through testing. At the end of the third quadrant, the next
version of the software is available.

Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate
the so-far developed version of the software. In the end, planning for the next phase is
started.
The Spiral model is called a Meta-Model because it subsumes all the other SDLC
models like waterfall, iterative and protype.

Advantages of the Spiral Model

Below are some advantages of the Spiral Model.
1. Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development
model to follow due to the risk analysis and risk handling at every phase.
2. Good for large projects: It is recommended to use the Spiral Model in
large and complex projects.
3. Flexibility in Requirements: Change requests in the Requirements at a
later phase can be incorporated accurately by using this model.
4. Customer Satisfaction: Customers can see the development of the
product at the early phase of the software development and thus, they
habituated with the system by using it before completion of the total
product.
5. Iterative and Incremental Approach: The Spiral Model provides an
iterative and incremental approach to software development, allowing for
flexibility and adaptability in response to changing requirements or
unexpected events.

Disadvantages of the Spiral Model

Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC
models.
2. Expensive: Spiral Model is not suitable for small projects as it is
expensive.
 3. Too much dependability on Risk Analysis: The successful completion
of the project is very much dependent on Risk Analysis. Without very
highly experienced experts, it is going to be a failure to develop a project
using this model.
4. Difficulty in time management: As the number of phases is unknown at
the start of the project, time estimation is very difficult.

Example :- windows operating system versions.

Agile Models – Software Engineering

To overcome these drawbacks of the Waterfall Model, in the mid-2000s

the Agile Software Development model was proposed by team of software
engineers.

Steps in the Agile Model

The agile model is a combination of iterative and incremental process models. The
steps involve in agile SDLC models are:
 Requirement gathering
  Design the Requirements
 Construction / Iteration
 Testing / Quality Assurance
 Deployment
 Feedback

Steps in the Agile Model

The agile model is a combination of iterative and incremental process models. The
steps involve in agile SDLC models are:

Requirement gathering
Design the Requirements
Construction / Iteration
Testing / Quality Assurance
Deployment
Feedback

1. Requirement Gathering:- In this step, the development team must gather the
requirements, by interaction with the customer. development team should plan the
time and effort needed to build the project. Based on this information you can
evaluate technical and economical feasibility.
2. Design the Requirements:- In this step, the development team will use user-flow-
diagram or high-level UML diagrams to show the working of the new features and
show how they will apply to the existing software. Wireframing and designing user
interfaces are done in this phase.
3. Construction / Iteration:- In this step, development team members start working on
their project, which aims to deploy a working product.
4. Testing / Quality Assurance:- Testing involves Unit Testing, Black and white box
testing .brief introduction of these three tests is as follows:
Unit Testing:- Unit testing is the process of checking small pieces of code to ensure
that the individual parts of a program work properly on their own. Unit testing is used
to test individual blocks (units) of code.
Black Box :- In Black-box testing, a tester doesn’t have any information about the
internal working of the software system. Black box testing is a high level of testing
that focuses on the behavior of the software. It involves testing from an external or
end-user perspective.
Programming knowledge is not needed to perform Black Box testing.
Performed by the end user, developer, and tester.
White Box:- White-box testing is a testing technique which checks the internal
functioning of the system. In this method, testing is based on coverage of code
statements, branches, paths or conditions. White-Box testing is considered as low-
level testing. It is also called glass box, transparent box, clear box or code base
testing.
Programming knowledge is required to perform White Box testing.
 Performed by the developer, and tester.

5. Deployment:- In this step, the development team will deploy the working project to
end users.
6. Feedback:- This is the last step of the Agile Model. In this, the team receives
feedback about the product and works on correcting bugs based on feedback provided
by the customer.

Principles of the Agile Model

 To establish close contact with the customer during development and to gain a clear
understanding of various requirements, each Agile project usually includes a
customer representative on the team. At the end of each iteration stakeholders and the
customer representative review, the progress made and re-evaluate the requirements.
 The agile model relies on working software deployment rather than comprehensive
documentation.
 Frequent delivery of incremental versions of the software to the customer
representative in intervals of a few weeks.
 Requirement change requests from the customer are encouraged and efficiently
incorporated.
 It emphasizes having efficient team members and enhancing communications among
them is given more importance. It is realized that improved communication among
the development team members can be achieved through face-to-face communication
rather than through the exchange of formal documents.
 It is recommended that the development team size should be kept small (5 to 9
people) to help the team members meaningfully engage in face-to-face
communication and have a collaborative work environment.
 The agile development process usually deploys Pair Programming. In Pair
programming, two programmers work together at one workstation. One does coding
while the other reviews the code as it is typed in. The two programmers switch their
roles every hour or so.
SDLC RAD Model Phases

 Business Modelling – During the Business Modelling

phase, the primary task is to determine the information
flow among various business functions by answering
fundamental questions related to the source of data that
drives the business process, where the generated data
comes from, its destination, the individuals involved in
the processing of this data, and other pertinent details.
This step is crucial to establish a clear understanding of
the business operations and the interdependence of its
functions.
 Data Modeling is a phase where data collected from
business modeling is transformed into a set of data
objects, or entities, that are essential to support business
activities. During this phase, the attributes of each entity
are identified, and the relationship between these data
objects is defined. This process helps to ensure that the
data can be effectively utilized by the software
application being developed.
 Process Modeling involves transforming the
information objects defined in the data modeling phase
to facilitate the required data flow for executing a
 business function. To enable the addition, modification,
deletion, or retrieval of a data object, processing
descriptions are generated.
 Application Generation In the application generation
phase, developers employ automated tools to streamline
the software construction process. These tools may
leverage fourth generation language (4GL) techniques to
improve efficiency and productivity.
 Testing & Turnover – The testing and turnover phase
involves the evaluation of programming components,
many of which have already undergone testing due to
the emphasis on reuse in rapid application development
(RAD). As a result, the overall testing time is reduced.
However, any new components must be thoroughly
tested, and all interfaces must be fully exercised to
ensure optimal performance.

Disadvantages:-
Initial investment cost for more teams.

What is Risk Management?

Risk Management is a systematic process of recognizing, evaluating, and handling
threats or risks that have an effect on the finances, capital, and overall operations of an
organization.

Strategies to manage the risk

1.Reactive
2.Proactive

Reactive risk management

Focuses on hazards after they arise .No preventive measure ,OLD /Tractional
method .
Proactive Risk Management
Identifies and mitigates problems before they arise. Follows the logic of Prevention is
better than cure. Long-term outlook.

Risk Categorization

Risks can be categorized broadly into project risks, technical risks, business risks,
known risks, undreamt risks, predictable and unpredictable risks.
 Project risks: No proper scheduling, Time line is not followed, that costs will
increase.
  Technical risks: They threaten the quality of the software to be produced.
 Business risks: Business risk can be further categorized into the following:
o Market risk – building an excellent product or system that no one really
wants.
o Strategic risk – building a product that no longer fits into the overall business
strategy for the company.
o Sales risk – building a product that the sales force doesn’t understand how to
sell.
o Management risk – change in people.
o Budget risk – low budget and overturn.

Process visibility: - the ability to see all the aspects of the process.
Importance
1.Improve the customer’s service
2.Optimize the resources
3.Better decision making

Professional responsibility of Software engineers.

 Create high quality and reliable software

 Contribute to the society
 Respect privacy
 Continue to learn new technologies
 Communicate effectively with stake holders
 Follow the code of ethics designed by IEEE and ACM
 Yield an exclusive Intellectual Property Rights to safeguard software product's
unique and original aspects, including its source code, algorithms, user
interfaces, concepts and ideas.

System: “A system is an orderly grouping of independent components linked together

according to a plan to achieve a specific objective or goal”.
Environment:- Surroundings of the system.

SYSTEM BASIC COMPONENTS

I. Educational system Students, teachers, books, computers.
II. Computer system Monitor, CPU, keyboard.

Computer based system :-

 All the characteristics of the system are determined by the system elements, their
properties and relationships. The system elements are 1. Input 2. Processor 3. Output These
elements are common to all systems. These are the elements by which all systems are
described. They are set in a fixed position which helps the system analyst to design & work
with system more easily.
1. Input: It is defined as energizing or start up component on which system operates.
It may be raw material, data, physical source, knowledge or any energy to decide the nature
of output.
2. Processor: It is defined as the activity that makes possible the transformation of
input to output. When data is processed through computer it is processed through logical
steps. However these steps are required to be instructed in series to the computer.
3. Output: It is end result of the operation. In other words it is the purpose or the main
objective for which the system is designed. Though output is largely dependent on input, its
nature or format may vary vastly from the input. For example: If data keyed is in numerical
form it may display output which is in form of graph or pictorial form.

Subsystem: A complex system is difficult to implement when consider as a whole.

However, if we divide it into smaller functional units which are of manageable sizes then
every small function unit becomes a subsystem. In the formation of subsystem, the
components performing same or similar functions are grouped.

For example: In a business organization system, marketing, production, sales can be

considered as subsystems.

TYPES OF THE SYSTEM

Conceptual & Physical system

1. Conceptual (abstract) system is an orderly arrangement of independent ideas.
For example: Economic theory, Theory of relativity.
2. Physical system: These are the concrete operational systems made up of people
, material, machines energy & other physical things.
For example: Management information system.
Physical systems being operational systems can display activities or behavior.
While conceptual system as it works on different ideas or concepts it displays
theoretical structures.

Open & Closed systems

Open system: Open system is that system which interacts with its environment.
For example: Any business organization system exchanges its material,
manpower, money & information with its environment.
Closed system: Closed system is that system which does not interact with its
environment. It has only controlled & well-defined input & output.
 For example: Television is itself is closed system which controls its sharpness,
brightness automatically with sensors.

Deterministic & probabilistic system:

1. Deterministic system: It is a system which operates in predictable
manner. Stepwise execution is always possible & output is sure.
For example: computer system.

2. Probabilistic system: It is a system which operates in unpredictable manner &

degree of error is always possible. Also, output is not sure.
Weather forecasting

System procurement is the strategic process of acquiring goods and services needed
to support the development and operation of software systems. This process can be broken
down into four main steps: identify requirements, identify suppliers, evaluate proposals, and
select a supplier.

System Engineering
A System Engineer oversees the entire lifecycle of a complex system, from its initial
conception to its final deployment.
 Designing and developing system architectures
Focus on the overall IT infrastructure, including hardware, software, and networks.
Testing of the entire system, including hardware, software, and other components.

Software Engineering
A Software Engineer specializes in designing, developing, testing, and maintaining
software applications. They use their programming skills to create software solutions that
solve problems and meet the needs of users. Software engineers are responsible for writing
and debugging code, designing software architectures, testing software for functionality and
performance, and collaborating with other team members.
primarily deal with the software development lifecycle and software testing and
quality assurance.

What is the Systems Engineering process?

Systems Engineering is an interdisciplinary approach and guidelines that was
designed to create efficient and successful systems.

System Architecture Modeling

System modelling is the important element of the system engineering focused on
designing of the system.
They are classified in to 3 types

1.Data architecture
 2.Application architecture
3.Technology architecture

Data architecture
It provides a frame work for the information needs and set of attributes define some
aspects , quality and characteristic etc.

Application architecture
It provides the relationship among the objects for example
2 objects we will take customer and product these objects will connect like
Customer purchases product

Technology architecture
This will provide the foundation of data and application architecture includes
computers, operating systems, networks etc..

Nowadays the designing is managed mostly by UML and SFD .

Depict the Class diagram given in the class

Requirement Engineering
Requirement engineering is the process of collecting, validating and managing the
requirements essential for the development of the software, specified by the clients or the
end-users. This task is performed at the initial stages of software development.
The requirement engineering process involves a team of software developers or
engineers, business analysts, customers and end-users. Requirement engineering provides the
basic idea to the software developer of what the client or the end-user wants the software to
do.The phases of requirement engineering is classified as follows

1.The inception phase, the business requirements are identified where first the
business need is identified, the scope of the software in the market is analysed, a rough
feasibility analysis is done and the functioning of the software is discussed. Though all these
requirements are subject to change they are enough to start a conversation between business
analysts or customers or stakeholders and the software developers.
2. Requirement Elicitation
If the inception report is positive to undertake the project the next step is to gather the
requirement from the clients. This phase is the requirement elicitation phase where the
system analyst or the software developers communicate with the clients or the end-users of
the system to elicit more information.
There are many things that the software analyst come across while eliciting the
requirements such as:

The problem of scope:-

The boundary of the system is not defined properly
The problem of understanding:-
Poor understanding between the user and developer
The problem of volatile:-
The requirements keep changing over time

3. Requirement Specification
In terms of the software, the requirement specification can be a written document, a
mathematical model, graphical models, some usage scenarios, some sort of sample model,
some sort of code etc.

4. Negotiating Requirements
Now each client associated with the same project might have different versions of
requirements and they think that their aspect is more useful to develop software. Observing
the conflicting requirements, the software engineer has to reconcile and negotiate the facts
with the clients and end-users.
Negotiation is an iterative process where each client is asked to rank the requirement
in terms of priority. Parallelly the software engineer also assesses the cost associated with the
project, risk factors.
While addressing the conflicting requirements they may eliminate, add, combine or
modify the conflicting requirements so that each client sense some sort of satisfaction that
their requirements are essential for the development of the software.

5. Requirement Validation
Whatever is gathered, understood during the process of the requirement of
engineering must be validated to ensure that all the software requirements are specified. The
software developer or engineer must also ensure that the requirements are unambiguous,
correct, consistent, essential.
The requirement validation phase requires the presence of all like software
developers, clients, end-users and stakeholders. The specified requirements are checked
thoroughly for any missing, redundant, inconsistent information.

6. Requirement Management
Requirements of any software keep on changing and the business and technical
change throughout the life of the software. Requirement management is subject to keep track
of the requirements and the changes that occur during the development of the software.
 So, these are the steps or tasks that must be performed in the requirement engineering
process. The efficient requirement engineering promises that developed software satisfies
each requirement specified and up to the standards.

The software requirement document:-

The software requirements document (sometimes called the software requirements
specification or SRS) is an official statement of what the system developers should
implement. Requirements documents are essential when an outside contractor is
developing the software system.

Depict the picture given in the class.

The Figure shows requirements document has a diverse set of users, ranging from the
customer to management of the organization that is paying for the system to the engineers
responsible for developing the software.

A viewpoint is a way of organising the requirements for a software system, based on

some perspective such as an end-user perspective or a manager’s perspective

There are three generic types of viewpoint:

1. Interactor viewpoints that represent people or other systems that interact directly with
the system. In the bank ATM system, examples of interactor viewpoints are the
bank’s customers and the bank’s account database.
2. Indirect viewpoints that represent stakeholders who do not use the system themselves
but who influence the requirements in some way. In the bank ATM system, examples
of indirect viewpoints are the management of the bank and the bank security staff.
3. Domain viewpoints that represent domain characteristics and constraints that
influence the system requirements. In the bank ATM system, an example of a domain
viewpoint would be the standards that have been developed for inter-bank
communications.

Context model in requirement engineering:-

Context Model serve as a foundational tool, helping designers and stakeholders grasp the
scope and boundaries of a system under consideration. These diagrams provide a high-level
view, illustrating how the system interacts with external entities and the environment.
 Data Flow
These are arrows representing the flow of data or information between the system and
external entities. They illustrate the exchange of data between the system and its
environment.
1. Unidirectional Data Flow
Unidirectional data flow indicates that data moves in only one direction between two
components.
2.Bidirectional Data Flow
Bidirectional data flow indicates that data can move in both directions between two
components.

Object models
A model of a software system that is structured and organized as a set of object
classes and the relationships between these classes.
 Functional and Non-Functional Requirements: -

Requirements analysis is an essential process that enables the success of a system or

software project to be assessed. Requirements are generally split into two types: Functional
and Non-functional requirements.

Functional Non-functional
Describes what the system do How the system performs
Mandatory Not mandatory
Provide by user By developer
Test before non functional requirements After functional requirements
Verify the identity of the user Scalability and usability