LECTURE PLAN FOR THE ACADEMIC YEAR 2022-23

BRANCH: Computer Engineering YEAR/ Semester: II year III Semester

SUBJECT: Software Engineering TEACH METHODOLOGY: Lecture
UNIT: 1 TOTAL LECTURES:
FACULTY NAME: Shipra Khandelwal, Assistant Prof. Department of CSE
Introduction:

1. Software Engineering

The term software engineering is the product of two words, software, and engineering.
The software is a collection of integrated programs.

Theory

Software subsists of carefully organized instructions and code written by developers on any of
various computer languages.

Computer programs and related documentation such as requirements, design models and user
manuals.

Engineering is the application of scientific and practical knowledge to invent, design, build,
maintain, and improve frameworks, processes, etc.

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.

Why is Software Engineering required?

Software Engineering is required due to the following reasons:

o To manage Large software

o For more Scalability
o Cost Management
o To manage the dynamic nature of software
o For better quality Management

Need of Software Engineering

The necessity of software engineering appears because of a higher rate of progress in user
requirements and the environment on which the program is working.
 o Huge Programming: It is simpler to manufacture a wall than to a house or building,
similarly, as the measure of programming become extensive engineering has to step to
give it a scientific process.
o Adaptability: If the software procedure were not based on scientific and engineering
ideas, it would be simpler to re-create new software than to scale an existing one.
o Cost: As the hardware industry has demonstrated its skills and huge manufacturing has
let down the cost of computer and electronic hardware. But the cost of programming
remains high if the proper process is not adapted.
o Dynamic Nature: The continually growing and adapting nature of programming hugely
depends upon the environment in which the client works. If the quality of the software is
continually changing, new upgrades need to be done in the existing one.
o Quality Management: Better procedure of software development provides a better and
quality software product.

Characteristics of a good software engineer

The features that good software engineers should possess are as follows:

o Exposure to systematic methods, i.e., familiarity with software engineering principles.

o Good technical knowledge of the project range (Domain knowledge).
o Good programming abilities.
o Good communication skills. These skills comprise of oral, written, and interpersonal
skills.
o High motivation.
o Sound knowledge of fundamentals of computer science.
o Intelligence.
o Ability to work in a team
o Discipline

Example-

University Question-

1. Describe Software Engineering with its need?

2. Explain Characteristics of good Software Engineering.

Reference-
2. Software Development Life Cycle (SDLC)

Introduction

A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle. A life cycle model represents all the methods required
to make a software product transit through its life cycle stages. It also captures the structure in
which these methods are to be undertaken.

Theory

A life cycle model maps the various activities performed on a software product from its
inception to retirement. Different life cycle models may plan the necessary development
activities to phases in different ways. Thus, no element which life cycle model is followed, the
essential activities are contained in all life cycle models though the action may be carried out in
distinct orders in different life cycle models. During any life cycle stage, more than one activity
may also be carried out.

SDLC Cycle

The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.

The senior members of the team perform it with inputs from all the stakeholders and domain
experts or SMEs in the industry.

Planning for the quality assurance requirements and identifications of the risks associated with
the projects is also done at this stage.

Business analyst and Project organizer set up a meeting with the client to gather all the data like
what the customer wants to build, who will be the end user, what is the objective of the product.
Before creating a product, a core understanding or knowledge of the product is very necessary.

For Example, A client wants to have an application which concerns money transactions. In this
method, the requirement has to be precise like what kind of operations will be done, how it will
be done, in which currency it will be done, etc.

Once the required function is done, an analysis is complete with auditing the feasibility of the
growth of a product. In case of any ambiguity, a signal is set up for further discussion.

Once the requirement is understood, the SRS (Software Requirement Specification) document is
created. The developers should thoroughly follow this document and also should be reviewed by
the customer for future reference.

Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent and document the
software requirements and get them accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document which

contains all the product requirements to be constructed and developed during the project life
cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis, and design of
the software project. This phase is the product of the last two, like inputs from the customer and
requirement gathering.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built. The
implementation of design begins concerning writing code. Developers have to follow the coding
guidelines described by their management and programming tools like compilers, interpreters,
debuggers, etc. are used to develop and implement the code.
Stage5: Testing

After the code is generated, it is tested against the requirements to make sure that the products
are solving the needs addressed and gathered during the requirements stage.During this stage,
unit testing, integration testing, system testing, acceptance testing are done.

Stage6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is deployed.Then based on
the assessment, the software may be released as it is or with suggested enhancement in the object
segment.After the software is deployed, then its maintenance begins.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real issues come up and
requirements to be solved from time to time.This procedure where the care is taken for the
developed product is known as maintenance.

Different types of models in SDLC-

Waterfall model

Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing, integration
and system testing, and operation and maintenance. The steps always follow in this order and do
not overlap. The developer must complete every phase before the next phase begins. This model
is named "Waterfall Model", because its diagrammatic representation resembles a cascade of
waterfalls.

1. Requirements analysis and specification phase:

The aim of this phase is to understand the exact requirements of the customer and to
document them properly. Both the customer and the software developer work together so
as to document all the functions, performance, and interfacing requirement of the
software. It describes the "what" of the system to be produced and not "how."In this
phase, a large document called Software Requirement Specification (SRS)document is
created which contained a detailed description of what the system will do in the common
language.
2. Design Phase: This phase aims to transform the requirements gathered in the SRS into a
suitable form which permits further coding in a programming language. It defines the overall
software architecture together with high level and detailed design. All this work is documented
as a Software Design Document (SDD).

3. Implementation and unit testing: During this phase, design is implemented. If the SDD is
complete, the implementation or coding phase proceeds smoothly, because all the information
needed by software developers is contained in the SDD.During testing, the code is thoroughly
examined and modified. Small modules are tested in isolation initially. After that these modules
are tested by writing some overhead code to check the interaction between these modules and the
flow of intermediate output.

4. Integration and System Testing: This phase is highly crucial as the quality of the end
product is determined by the effectiveness of the testing carried out. The better output will lead
to satisfied customers, lower maintenance costs, and accurate results. Unit testing determines the
efficiency of individual modules. However, in this phase, the modules are tested for their
interactions with each other and with the system.

5. Operation and maintenance phase: Maintenance is the task performed by every user once
the software has been delivered to the customer, installed, and operational.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited are:

o When the requirements are constant and not changed regularly.

o A project is short
o The situation is calm
o Where the tools and technology used is consistent and is not changing
o When resources are well prepared and are available to use.
Advantages of Waterfall model

o This model is simple to implement also the number of resources that are required for it is
minimal.
o The requirements are simple and explicitly declared; they remain unchanged during the
entire project development.
o The start and end points for each phase is fixed, which makes it easy to cover progress.
o The release date for the complete product, as well as its final cost, can be determined
before development.
o It gives easy to control and clarity for the customer due to a strict reporting system.

Disadvantages of Waterfall model

o In this model, the risk factor is higher, so this model is not suitable for more significant
and complex projects.
o This model cannot accept the changes in requirements during development.
o It becomes tough to go back to the phase. For example, if the application has now shifted
to the coding phase, and there is a change in requirement, It becomes tough to go back
and change it.
o Since the testing done at a later stage, it does not allow identifying the challenges and
risks in the earlier phase, so the risk reduction strategy is difficult to prepare.

RAD (Rapid Application Development) Model

RAD is a linear sequential software development process model that emphasizes a concise
development cycle using an element based construction approach. If the requirements are well
understood and described, and the project scope is a constraint, the RAD process enables a
development team to create a fully functional system within a concise time period.

RAD (Rapid Application Development) is a concept that products can be developed faster and of
higher quality through:

o Gathering requirements using workshops or focus groups

o Prototyping and early, reiterative user testing of designs
o The re-use of software components
o A rigidly paced schedule that refers design improvements to the next product version

o Less formality in reviews and other team communication

The various phases of RAD are as follows:

1.Business Modelling: The information flow among business functions is defined by answering
questions like what data drives the business process, what data is generated, who generates it,
where does the information go, who process it and so on.

2. Data Modelling: The data collected from business modeling is refined into a set of data
objects (entities) that are needed to support the business. The attributes (character of each entity)
are identified, and the relation between these data objects (entities) is defined.

3. Process Modelling: The information object defined in the data modeling phase are
transformed to achieve the data flow necessary to implement a business function. Processing
descriptions are created for adding, modifying, deleting, or retrieving a data object.

4. Application Generation: Automated tools are used to facilitate construction of the software;
even they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have already been tested since
RAD emphasis reuse. This reduces the overall testing time. But the new part must be tested, and
all interfaces must be fully exercised.

When to use RAD Model?

o When the system should need to create the project that modularizes in a short span time
(2-3 months).
o When the requirements are well-known.
 o When the technical risk is limited.
o When there's a necessity to make a system, which modularized in 2-3 months of period.
o It should be used only if the budget allows the use of automatic code generating tools.

Advantage of RAD Model

o This model is flexible for change.

o In this model, changes are adoptable.
o Each phase in RAD brings highest priority functionality to the customer.
o It reduced development time.
o It increases the reusability of features.

Disadvantage of RAD Model

o It required highly skilled designers.

o All application is not compatible with RAD.
o For smaller projects, we cannot use the RAD model.
o On the high technical risk, it's not suitable.
o Required user involvement.

Spiral Model

The spiral model, initially proposed by Boehm, is an evolutionary software process model that
couples the iterative feature of prototyping with the controlled and systematic aspects of the
linear sequential model. It implements the potential for rapid development of new versions of the
software. Using the spiral model, the software is developed in a series of incremental releases.
During the early iterations, the additional release may be a paper model or prototype. During
later iterations, more and more complete versions of the engineered system are produced.

The Spiral Model is shown in fig:

 Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle,
the various alternatives that are possible for achieving the targets, and the constraints that exists.

Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located on
the risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve uncertainties
and risks. This process may include activities such as benchmarking, simulation, and
prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether
to continue with a further period of the spiral. If it is determined to keep, plans are drawn up for
the next step of the project.

The development phase depends on the remaining risks. For example, if performance or user-
interface risks are treated more essential than the program development risks, the next phase may
be an evolutionary development that includes developing a more detailed prototype for solving
the risks.

The risk-driven feature of the spiral model allows it to accommodate any mixture of a
specification-oriented, prototype-oriented, simulation-oriented, or another type of approach. An
essential element of the model is that each period of the spiral is completed by a review that
includes all the products developed during that cycle, including plans for the next cycle. The
spiral model works for development as well as enhancement projects.

When to use Spiral Model?

o When deliverance is required to be frequent.
o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages

o High amount of risk analysis

o Useful for large and mission-critical projects.

Disadvantages

o Can be a costly model to use.

o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

Incremental Model

Incremental Model is a process of software development where requirements divided into

multiple standalone modules of the software development cycle. In this model, each module goes
through the requirements, design, implementation and testing phases. Every subsequent release
of the module adds function to the previous release. The process continues until the complete
system achieved.

The various phases of incremental model are as follows:

1. Requirement analysis: In the first phase of the incremental model, the product analysis
expertise identifies the requirements. And the system functional requirements are understood by
the requirement analysis team. To develop the software under the incremental model, this phase
performs a crucial role.

2. Design & Development: In this phase of the Incremental model of SDLC, the design of the
system functionality and the development method are finished with success. When software
develops new practicality, the incremental model uses style and development phase.

3. Testing: In the incremental model, the testing phase checks the performance of each existing
function as well as additional functionality. In the testing phase, the various methods are used to
test the behavior of each task.

4. Implementation: Implementation phase enables the coding phase of the development system.
It involves the final coding that design in the designing and development phase and tests the
functionality in the testing phase. After completion of this phase, the number of the product
working is enhanced and upgraded up to the final system product

When we use the Incremental Model?

o When the requirements are superior.

o A project has a lengthy development schedule.
o When Software team are not very well skilled or trained.
o When the customer demands a quick release of the product.
o You can develop prioritized requirements first.

Advantage of Incremental Model

o Errors are easy to be recognized.

o Easier to test and debug
o More flexible.
o Simple to manage risk because it handled during its iteration.
o The Client gets important functionality early.

Disadvantage of Incremental Model

o Need for good planning

o Total Cost is high.
o Well defined module interfaces are needed.
Iterative Model

In this Model, you can start with some of the software specifications and develop the first
version of the software. After the first version if there is a need to change the software, then a
new version of the software is created with a new iteration. Every release of the Iterative Model
finishes in an exact and fixed period that is called iteration.The Iterative Model allows the
accessing earlier phases, in which the variations made respectively. The final output of the
project renewed at the end of the Software Development Life Cycle (SDLC) process.

The various phases of Iterative model are as follows:

1. Requirement gathering & analysis: In this phase, requirements are gathered from customers
and check by an analyst whether requirements will fulfil or not. Analyst checks that need will
achieve within budget or not. After all of this, the software team skips to the next phase.

2. Design: In the design phase, team design the software by the different diagrams like Data
Flow diagram, activity diagram, class diagram, state transition diagram, etc.

3. Implementation: In the implementation, requirements are written in the coding language and
transformed into computer program which are called Software.

4. Testing: After completing the coding phase, software testing starts using different test
methods. There are many test methods, but the most common are white box, black box, and grey
box test methods.

5. Deployment: After completing all the phases, software is deployed to its work environment.
6. Review: In this phase, after the product deployment, review phase is performed to check the
behavior and validity of the developed product. And if there are any error found then the process
starts again from the requirement gathering.

7. Maintenance: In the maintenance phase, after deployment of the software in the working
environment there may be some bugs, some errors or new updates are required. Maintenance
involves debugging and new addition options.

When to use the Iterative Model?

1. When requirements are defined clearly and easy to understand.

2. When the software application is large.
3. When there is a requirement of changes in future.

Advantage of Iterative Model:

1. Testing and debugging during smaller iteration is easy.

2. A Parallel development can plan.
3. It is easily acceptable to ever-changing needs of the project.
4. Risks are identified and resolved during iteration.
5. Limited time spent on documentation and extra time on designing.

Disadvantage of Iterative Model:

1. It is not suitable for smaller projects.

2. More Resources may be required.
3. Design can be changed again and again because of imperfect requirements.
4. Requirement changes can cause over budget.
5. Project completion date not confirmed because of changing requirements.

Prototype Model

The prototype model requires that before carrying out the development of actual software, a
working prototype of the system should be built. A prototype is a toy implementation of the
system. A prototype usually turns out to be a very crude version of the actual system, possible
exhibiting limited functional capabilities, low reliability, and inefficient performance as
compared to actual software. In many instances, the client only has a general view of what is
expected from thesoftware product. In such a scenario where there is an absence of detailed
information regarding the input to the system, the processing needs, and the output requirement,
the prototyping model may be employed.
Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
 6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.

2. Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market
3. Difficult to know how long the project will last.
4. Easy to fall back into the code and fix without proper requirement analysis, design,
customer evaluation, and feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

Example

University Question-

1. Explain different phases of Software Development Life Cycle.

2. Describe models of SDLS-
o Waterfall Model
o Spiral Model
o RAD Model
o Prototype Model

Reference-
 3. Software Requirement Specification - [SRS]

Introduction
A software requirements specification (SRS) is a document that captures complete description
about how the system is expected to perform. It is usually signed off at the end of requirements
engineering phase.

Theory

Qualities of SRS:
Following are the characteristics of a good SRS document:
1. Correctness
User review is used to ensure the correctness of requirements stated in the SRS. SRS is said
to be correct if it covers all the requirements that are actually expected from the system.

2. Completeness
Completeness of SRS indicates every sense of completion including the numbering of all
the pages, resolving the determined parts to as much extent as possible as well as covering
all the functional and non-functional requirements properly.
3. Consistency
Requirements in SRS are said to be consistent if there are no conflicts between any set of
requirements. Examples of conflict include differences in terminologies used at separate
places, logical conflicts like time period of report generation, etc.

4. Unambiguousness
An SRS is said to be unambiguous if all the requirements stated have only 1 interpretation.
Some of the ways to prevent unambiguousness include the use of modelling techniques like
ER diagrams, proper reviews and buddy checks, etc.

5. Ranking for importance and stability

There should a criterion to classify the requirements as less or more important or more
specifically as desirable or essential. An identifier mark can be used with every
requirement to indicate its rank or stability.

6. Modifiability
SRS should be made as modifiable as possible and should be capable of easily accepting
changes to the system to some extent. Modifications should be properly indexed and cross-
referenced.
 7. Verifiability
An SRS is verifiable if there exists a specific technique to quantifiably measure the extent
to which every requirement is met by the system. For example, a requirement stating that
the system must be user-friendly is not verifiable and listing such requirements should be
avoided.

8. Traceability
One should be able to trace a requirement to a design component and then to a code
segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.

9. Design Independence
There should be an option to choose from multiple design alternatives for the final
system. More specifically, the SRS should not include any implementation details.

10. Testability
An SRS should be written in such a way that it is easy to generate test cases and test
plans from the document.

11. Understandable by the customer

Theend user maybe an expert in his/her specific domain but might not be an expert in
computer science. Hence, the use of formal notations and symbols should be avoided to
as much extent as possible. The language should be kept easy and clear.
12. Right level of abstraction
The SRS is written for the requirements phase, the details should be explained explicitly.
Whereas, for a feasibility study, fewer details can be used. Hence, the level of abstraction
varies according to the purpose of the SRS.

Example

University Question-
1. What is SRS Document ? Explain qualities of good SRS Document.

Reference

4. Formal Requirement Specification

Introduction
In computer science, formal specifications are mathematically based techniques whose purpose
are to help with the implementation of systems and software.
Theory
They are used to describe a system, to analyze its behavior, and to aid in its design by verifying
key properties of interest through rigorous and effective reasoning tools.These specifications
are formal in the sense that they have a syntax, their semantics fall within one domain, and they
are able to be used to infer useful information.
Given such a specification, it is possible to use formal verification techniques to demonstrate that
a system design is correct with respect to its specification. This allows incorrect system designs
to be revised before any major investments have been made into an actual implementation.
Another approach is to use probably correct refinement steps to transform a specification into a
design, which is ultimately transformed into an implementation that is correct by construction.
It is important to note that a formal specification is not an implementation, but rather it may be
used to develop an implementation. Formal specifications describe what a system should do,
not how the system should do it.
A good specification must have some of the following attributes: adequate, internally consistent,
unambiguous, complete, satisfied, and minimal.

A good specification will have:

 Constructability, manageability andevolvability.

 Usability
 Communicability
 Powerful and efficient analysis
One of the main reasons there is interest in formal specifications is that they will provide an
ability to perform proofs on software implementations.These proofs may be used to validate a
specification, verify correctness of design, or to prove that a program satisfies a specification.
Example-

University Question-

1. What is the use formal requirement specification?

Reference

5. Verification and Validation

 Introduction
The process of evaluating software to determine whether the products of a given development
phase satisfy the conditions imposed at the start of that phase.

Theory

Verification
Verification is a static practice of verifying documents, design, code and program. It includes all
the activities associated with producing high quality software: inspection, design analysis and
specification analysis. It is a relatively objective process.
Verification will help to determine whether the software is of high quality, but it will not ensure
that the system is useful. Verification is concerned with whether the system is well-engineered
and error-free.

Methods ofVerification : Static Testing

 Walkthrough
 Inspection
 Review

Validation
The process of evaluating software during or at the end of the development process to determine
whether it satisfies specified requirements.
Validation is the process of evaluating the final product to check whether the software meets the
customer expectations and requirements. It is a dynamic mechanism of validating and testing the
actual product.
Methods of Validation : Dynamic Testing
 Testing
 End Users

Difference between Verification and Validation

The distinction between the two terms is largely to do with the role of specifications.
Validation is the process of checking whether the specification captures the customer’s
needs. “Did I build what I said I would?”
Verification is the process of checking that the software meets the specification. “Did I build
what I need?”
 Verification Validation
1. Verification is a static 1. Validation is a dynamic
practice of verifying documents, mechanism of validating and
design, code and program. testing the actual product.
2. It does not involve executing 2. It always involves executing
the code. the code.
3. It is human based checking of 3. It is computer based
documents and files. execution of program.
4. Verification uses methods 4. Validation uses methods like
like inspections, reviews, black box (functional) testing,
walkthroughs, and Desk- gray box testing, and white box
checking etc. (structural) testing etc.
5. Validation is to check
5. Verification is to check
whether software meets the
whether the software conforms
customer expectations and
to specifications.
requirements.
6. It can catch errors that 6. It can catch errors that
validation cannot catch. It is low verification cannot catch. It is
level exercise. High Level Exercise.
7. Target is requirements
7. Target is actual product-a
specification, application and
unit, a module, a bent of
software architecture, high level,
integrated modules, and
complete design, and database
effective final product.
design etc.
8. Verification is done by QA
team to ensure that the software 8. Validation is carried out with
is as per the specifications in the the involvement of testing team.
SRS document.
9. It generally comes first-done 9. It generally follows
before validation. after verification.

Example

University Question-

1. Difference Between Validation and Verification.

 2. What is Static and Dynamic Testing?
REFERENCES

BOOK :
 “Software Engineering” by Ian Somerville
 “Software engineering” by Roger S. Pressman

INTERNET : https://www.tutorialspoint.com/

https://www.geeksforgeeks.org/

NAME OF FACULTY : RAMANDEEP KAUR

SIGNATURE : ___________________