Waterfall model

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.

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 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.

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.

Prototype Model

The prototype model requires that before carrying out the

development of actual software, a working prototype of the
system should be built.
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. Difficult to know how long the project will last.
3. Easy to fall back into the code and fix without proper
requirement analysis, design, customer evaluation, and
feedback.
4. Prototyping tools are expensive.
5. Special tools & techniques are required to build a prototype.
6. It is a time-consuming process.

Big Bang Model

In this model, developers do not follow any specific process.

Development begins with the necessary funds and efforts in the
form of inputs. And the result may or may not be as per the
customer's requirement, because in this model, even the
customer requirements are not defined.

This model is ideal for small projects like academic projects or

practical projects. One or two developers can work together on
this model.
Advantage (Pros) of Big Bang Model:
1. There is no planning required.
2. Simple Model.
3. Few resources required.
4. Easy to manage.
5. Flexible for developers.

Disadvantage(Cons) of Big Bang Model:

1. Not acceptable for a large project.

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.

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.
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(Pros) 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.

Disadvantage(Cons) of Iterative Model:

1. It is not suitable for smaller projects.

Spiral Model

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:

When to use Spiral Model?

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.
Software Requirement Specifications

Software Requirement Specification (SRS) Format as the

name suggests, is a complete specification and description of
requirements of the software that need to be fulfilled for the
successful development of the software system.

it comprises user requirements for a system as well as detailed

specifications of the system requirements. SRS could be written
by the client of a system. Second, the SRS could be written by a
developer of the system. The two methods create entirely various
situations and establish different purposes for the document
altogether. The first case, SRS, is used to define the needs and
expectation of the users. The second case, SRS, is written for
various purposes and serves as a contract document between
customer and developer.
Purpose and Structure of an SRS Document
Functional requirements

Interface requirements

Performance requirements

Design constraints

Non-functional attributes

A preliminary schedule and budget

Characteristics of good SRS
Properties of a good SRS document

The essential properties of a good SRS document are the

following:

1. Concise:

2. Structured:

3. Black-box view:

4. Conceptual integrity:

5. Verifiable:
Advantages of good SRS Document

 An SRS establishes the basis for agreement between the

customer and the supplier on what the software product
will perform.

 validation of the final product/software.

 produce high-quality product/software.

 reduces the development cost.

Problems without an SRS Document
 It would be difficult to develop the system according to
customer needs, without having an SRS document.

 Software developers will not know whether they are

developing the product according to the customer need.

 Software Engineers find it difficult to understand the

functionality of the software, during the maintenance
phase.

 User document writer will face many difficulties writing the

“users manual” without understanding the SRS
documents.

Requirement Engineering
 Requirements engineering (RE) refers to the process of
defining, documenting, and
maintaining requirements in the engineering design process.
 The process to gather the software requirements from
client, analyze and document them
is known as requirement engineering.
 Requirement engineering provides the appropriate
mechanism to understand what the
customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable
solution, specifying the solution clearly, validating the
specifications and managing the
requirements as they are transformed into a working system.
 Thus, requirement engineering is the disciplined application
of proven principles, methods,
tools, and notation to describe a proposed system's intended
behavior and its associated
constraints.
 The goal of requirement engineering is to develop and
maintain sophisticated and
descriptive ‘System Requirements Specification’ document.
Requirement Engineering Process
It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
Software Design Principles

Problem Partitioning
 Software Project Planning

Project planning is an organized and integrated management process that focuses

on the actions necessary for the project's practical completion.

project planning goals.:

1.It establishes the project management team's duties and

responsibilities.

2.It guarantees that the project management team adheres to

the company's goals.

3. It improved resource use

4.It establishes the project's limits.

Project Planning Process

 project's objectives
 Techniques
 Timeline
 resources.
 Dangers

Software Project Manager

Software manager is responsible for planning and scheduling project

development.
  ensure that it is completed to the required standard.
 monitor the progress to check that the event is on time and
within budget.
 incorporate the major issues like size & cost estimation
scheduling,

A software metric is a measure of software characteristics

which are measurable or countable.
Classification of Software Metrics

Software metrics can be classified into two types as

follows:

1. Product Metrics: These are the measures of various

characteristics of the software product. The two important
software characteristics are:
 1. Size and complexity of software.
2. Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

2. Process Metrics: These are the measures of various

characteristics of the software development process. For
example, the efficiency of fault detection. They are used to
measure the characteristics of methods, techniques, and tools
that are used for developing software.

Software Metrics

Measure of characteristics of software which are quantifiable and

countable.

1. Product Metrics:
 SIZE
 FEATURES
 COMPLEXITY
 PERFORMANCE
 LEVEL OF QUALITY
2. Process Metrics:
 SOFTWARE DEVELOPMENT
 SOFTWARE MAINTENANCE
3. Project Metrics:
 COST OF DEVELOPING SOFTWARE
  SCHEDULE THE SOFTWARE DEVELOPMENT
 ASSIGNING DUTIES

4. Process Metrics:

 SOFTWARE DEVELOPMENT
 SOFTWARE MANTENANCE
1. Process Metrics:
Project size estimation is a crucial
aspect of software engineering, as it
helps in planning and allocating
resources for the project. Here are some
of the popular project size estimation
techniques used in software
engineering:

1. Expert Judgment:
2.
3. Analogous Estimation
4.
5. Bottom-up Estimation:
6.
7. Three-point Estimation:
8.
9. Function Points:

Estimation of the size of the software is an

essential part of Software Project Management. It
helps the project manager to further predict the
effort and time which will be needed to build the
project. Various measures are used in project size
estimation. Some of these are:
 Lines of Code
 Number of entities in ER diagram
 Total number of processes in detailed data
flow diagram
 Function points

COCOMO MODEL:
Cocomo (Constructive Cost Model) is a model
based on LOC, i.e number of Lines of Code. It was
proposed by Barry Boehm in 1981 and is based on
the study of 63 projects, which makes it one of the
best-documented models.
outcome of the Cocomo are primarily Effort &
Schedule:
 Effort: Amount of labor that will be required
to complete a task. It is measured in person-
months units.
 Schedule: Simply means the amount of
time required for the completion of the job,
which is, of course, proportional to the effort
put in. It is measured in the units of time
such as weeks, and months.

Boehm’s definition of organic, semidetached, and

embedded systems:

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 also the team members have a nominal
experience regarding the problem.
2.

3. Semi-detached – A software project is said to

be a 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. The projects classified as Semi-
Detached are comparatively less familiar and
difficult to develop compared to the organic
ones and require more experience and better
guidance and creativity.
4.

5. Embedded – A software project requiring the

highest level of complexity, creativity, and
experience requirement fall under this
category.

Effort=a*(KLOC) b PM

Tdev=c*(efforts)d Mont
hs

Software
Projects a b c d
2. 1.0 2. 0.3
Organic
4 5 5 8

3. 1.1 2. 0.3
Semi-Detached
0 2 5 5

3. 1.2 2. 0.3
Embedded
6 0 5 2
Advantages of the COCOMO model:
provides a systematic way to estimate the cost
and effort of a software project.
Can be used to evaluate the feasibility of a
software project by estimating the cost and effort
required to complete it.

Disadvantages of the COCOMO model:

1.Does not provide a precise estimate of the
cost and effort of a software project, as it is
based on assumptions and averages.