UNIT I

INTRODUCTION:
Problems in software development

Common Issues:-

● The final Software does not fulfill the needs of the customer.
● Hard to extend and improve: if you want to add functionality later is mission
impossible.
● Bad documentation.
● Bad quality: frequent errors, hard to use,
● More time and costs than expected

Conclusion
Programming is NOT enough!

Solution
Software Engineering
What is SOFTWARE ENGINEERING?

The study and application of methodologies to develop quality software that fulfill
customer needs.
The term software engineering is the product of two words, software, and engineering.

The software is a collection of integrated programs.

Software consists of carefully-organized instructions and code written by developers on

any of various particular 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.

DEFINITION:

“Software engineering is a systematic, disciplined and cost effective technique for

software development”

IEEE defines software engineering as: The application of a systematic, disciplined,

quantifiable approach to the development, operation and maintenance of software.

Stages for software development

Why is Software Engineering required?
Software Engineering is required due to the following reasons:

● To manage Large software

● For more Scalability

● Cost Management

● To manage the dynamic nature of software

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

● Huge Programming: It is simpler to manufacture a wall than to a house or

building, similarly, as the measure of programming becomes extensive
engineering has to step to give it a scientific process.

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

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

● 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.
 ● Quality Management: Better procedure of software development provides a
better and quality software product.

Objective

To produce software that is:

• On time: is delivered at the established date.

• Reliable: doesn´t crash.

• Complete: good documentation, fulfill customer needs.

Characteristics of a good software engineer

● Exposure to systematic methods, i.e., familiarity with software engineering
principles.
● Good technical knowledge of the project range (Domain knowledge).
● Good programming abilities.
● Good communication skills. These skills comprise of oral, written, and
interpersonal skills.
● High motivation.
● Sound knowledge of fundamentals of computer science.
● Intelligence.
● Ability to work in a team
Importance of Software Engineering

The importance of Software engineering is as follows:

1. Reduces complexity: Big software is always complicated and challenging to

progress. Software engineering has a great solution to reduce the complication
of any project. Software engineering divides big problems into various small
issues. And then start solving each small issue one by one. All these small
problems are solved independently to each other.

2. To minimize software cost: Software needs a lot of hardwork and software

engineers are highly paid experts. A lot of manpower is required to develop
software with a large number of codes. But in software engineering,
programmers project everything and decrease all those things that are not
needed. In turn, the cost for software productions becomes less as compared to
any software that does not use software engineering method.
3. To decrease time: Anything that is not made according to the project always
wastes time. And if you are making great software, then you may need to run
many codes to get the definitive running code. This is a very time-consuming
procedure, and if it is not well handled, then this can take a lot of time. So if you
are making your software according to the software engineering method, then it
will decrease a lot of time.

4. Handling big projects: Big projects are not done in a couple of days, and they
need lots of patience, planning, and management. And to invest six and seven
months in any company, it requires heaps of planning, direction, testing, and
maintenance. No one can say that he has given four months of a company to the
task, and the project is still in its first stage. Because the company has provided
many resources to the plan and it should be completed. So to handle a big
project without any problem, the company has to go for a software engineering
method.

5. Reliable software: Software should be secure, meaning if you have delivered the
software, then it should work for at least it's given time or subscription. And if any
bugs come in the software, the company is responsible for solving all these bugs.
Because in software engineering, testing and maintenance are given, so there is
no worry of its reliability.

6. Effectiveness: Effectiveness comes if anything has been made according to the

standards. Software standards are the big target of companies to make it more
effective. So Software becomes more effective in the act with the help of
software engineering.
Software Development Life Cycle (SDLC)
SDLC is a process that defines the various stages involved in the development of
software for delivering a high-quality product. SDLC stages cover the complete life cycle
of a software i.e. from inception to retirement of the product.
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.

In other words, 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.

THE NEED FOR A SOFTWARE LIFE CYCLE MODEL

● The development team must identify a suitable life cycle model for the particular
project and then adhere(support) to it.
● Without using a particular life cycle model the development of a software
product would not be in a systematic and disciplined manner.
● When a software product is being developed by a team there must be a clear
understanding among team members about when and what to do. Otherwise it
would lead to chaos and project failure.
● This problem can be illustrated by using an example. Suppose a software
development problem is divided into several parts and the parts are assigned to
the team members. From then on, suppose the team members are allowed the
freedom to develop the parts assigned to them in whatever way they like. It is
possible that one member might start writing the code for his part, another might
 decide to prepare the test documents first, and some other engineer might begin
with the design phase of the parts assigned to him. This would be one of the
perfect recipes for project failure.
● A software life cycle model defines entry and exit criteria for every phase.
● A phase can start only if its phase-entry criteria have been satisfied. So without a
software life cycle model the entry and exit criteria for a phase cannot be
recognized. Without software life cycle models it becomes difficult for software
project managers to monitor the progress of the project.
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(Small and medium size enterprise) 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.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.
 Software Requirements:

It is the description of features and functionalities of the targeted software. It is the

description of what the software should do.

TYPES OF SOFTWARE REQUIREMENTS:

● System requirements (Functional and non-functional requirements)

● User requirements
● System requirements
● Interface specification
● Documentation of the software requirements

Functional and non-functional requirements/System Requirement

System requirements are a complete description of the software system’s functions,

services, and operational constraints. The system requirements document (sometimes
called a functional specification) should define precisely what is to be implemented. It
may be part of the agreement between the system buyer and the software developers.

Software system requirements are often classified as functional requirements or

nonfunctional requirements:

1. Functional requirements

These are statements of

1. services the system should provide,

2. how the system should react to particular inputs,
3. and how the system should behave in particular situations.

In some cases, the functional requirements may also explicitly state what the
system should not do.
 Functional system requirements vary from general specifications covering what
the system should do in order to very particular requirements reflecting local
ways of working or the organization's existing systems.

For example, here are examples of functional requirements:

1) Authentication and authorization of the user whenever he/she logs into the
system.

2) System should raise a query when a hazardous(critical) issue is highlighted.

3) A Verification email and OTP is sent to the user whenever he/she registers for
the first time on some software system or during an ecommerce transaction an
SMS is sent for the amount deduction.

● The functional requirements specification of a system must be both complete

and consistent. Completeness means that all services required by the user must
be defined. Consistency means that requirements should not have conflicting
definitions.
● In practice, for large, complex systems, it is practically impossible to achieve
requirements consistency and completeness. One reason for this is that it is
simple to make mistakes and omissions when writing specifications for complex
systems.
● Another reason is that there are many stakeholders in a large system. A
stakeholder is an individual or a role that is affected by the system in some way.
Stakeholders have different— and frequently inconsistent—needs. These
inconsistencies may not be evident(clear) when the requirements are first
specified, so conflicting requirements are included in the specification
● For example, here are examples of functional requirements for the MHC-PMS
(Mental Health Care-Patient Management System)system, used to maintain
information about patients receiving treatment for mental health problems:
 1. A user shall be able to search the appointments lists for all clinics.

2. The system shall generate each day, for each clinic, a list of patients who are
expected to attend appointments that day.

3. Each staff member using the system shall be uniquely identified by his or her
eight-digit employee number.

● These functional user requirements define specific facilities to be provided by

the system.
● Imprecision(Not clear) in the requirements specification is the cause of many
software engineering problems.
● It is natural for a system developer to interpret(explain) an ambiguous
requirement in a way that simplifies its implementation.However, this is not
what the customer wants. New requirements have to be established and
changes made to the system. This delays system delivery and increases costs.
● For example, the first example requirement for the MHC-PMS states that a user
shall be able to search the appointments lists for all clinics. The rationale for
this requirement is that patients with mental health problems are sometimes
confused. They may have an appointment at one clinic but actually go to a
different clinic. If they have an appointment, they will be recorded as having
attended, irrespective of the clinic.
● The medical staff member specifying this may expect ‘search’ to mean that,
given a patient name, the system looks for that name in all appointments at all
clinics. However, this is not explicit in the requirement. System developers may
interpret the requirement in a different way and may implement a search so that
the user has to choose a clinic then carry out the search. This obviously will
involve more user input and so take longer.
2. Non-functional requirements

● These are constraints/restrictions on the services or functions offered by

the system.
● They include timing constraints, constraints on the development process,
and constraints imposed by standards.
● Non-functional requirements, as the name suggests, are requirements that
are not directly concerned with the specific services delivered by the
system to its users. They may relate to emergent system properties such
as reliability, response time, and store occupancy.
● Alternatively, they may define constraints on the system implementation
such as the capabilities of I/O devices or the data representations used in
interfaces with other systems.
● Non-functional requirements, such as performance, security, or
availability, usually specify or constrain characteristics of the system as a
whole.
● Non-functional requirements are often more critical than individual
functional requirements.
● System users can usually find ways to work around a system function that
doesn’t really meet their needs. However, failing to meet a non-functional
requirement can mean that the whole system is unusable.

For example

● If an aircraft system does not meet its reliability requirements, it will not
be certified as safe for operation;
● If an embedded control system fails to meet its performance
requirements, the control functions will not operate correctly.
Above figure is a classification of non-functional requirements. You can see from
this diagram that the non-functional requirements may come from required
characteristics of the software (product requirements), the organization
developing the software (organizational requirements), or from external sources:

1. Product requirements These requirements specify or constrain the behavior of

the software. Examples include performance requirements on how fast the
system must execute and how much memory it requires, reliability requirements
that set out the acceptable failure rate, security requirements, and usability
requirements.

2. Organizational requirements These requirements are broad system

requirements derived from policies and procedures in the customer’s and
developer’s organization. Examples include operational process requirements
that define how the system will be used, development process requirements that
specify the programming language, the development environment or process
standards to be used, and environmental requirements that specify the operating
environment of the system.

3. External requirements This broad heading covers all requirements that are
derived from factors external to the system and its development process. These
may include regulatory requirements that set out what must be done for the
system to be approved for use by a regulator, such as a central bank; legislative
requirements that must be followed to ensure that the system operates within
the law; and ethical requirements that ensure that the system will be acceptable
to its users and the general public.

Examples of non-functional requirements in the MHC-PMS

User Requirements:

● specifies what the user expects the software to be able to do.

● The user requirements for a system should describe the functional and
non-functional requirements so that they are easily understood by system
users without thorough technical knowledge. They should only specify the
external behavioral patterns of the system and should avoid, as far as
possible, system design characteristics.
● Consequently, if you are writing user requirements, you must not use the
software jargon, structured notations, or formal notations, or explain the
requirement by describing the system implementation.

List of problems that occur when requirements are written in natural language.

1. Lack of clarity -> It is sometimes difficult to use language in an accurate and

unambiguous manner without making the document wordy and hard to read.

2. Requirements confusion -> Functional requirements, non-functional

requirements, system objectives and design information might not be clearly
distinguished.

3. Requirements amalgamation -> Several different requirements can be

expressed together as a single requirement.

User requirements that include too much data limit the freedom of the system
developer to provide innovative solutions to user problems and are difficult to
understand. The user requirement should simply focus on the key and all the
essential amenities to be provided.
 To minimize misunderstandings when writing user requirements, following steps
need to be taken:
● Invent a standard format and ensure that all requirement definitions follow that
format.
● Standardizing the format makes exceptions less likely and the necessary
conditions easier to check.
● You may also include information on who proposed the requirement (the
requirement source) so that you will know whom to consult if the requirement
must be changed.
● Use language steadily.
● You should always distinguish between compulsory and desirable requirements.
Mandatory requirements are requirements that the system must support and are
typically written using 'shall'. Appropriate requirements are not essential and are
written using 'should'.
● Use text highlighting (bold, italic or colour) to pick out crucial parts of the
requirement.

Avoid, as far as possible, the use of computer terminology.

System Requirements

System requirements are expanded versions of the user needs that are used by
software engineers as the starting point for the system design. They add details
and explain how the user requirements should be offered by the system.

They may be used as part of the contract for the application of the system and
should therefore be a complete and consistent specification of the whole system
Ideally, the system requirements should simply explain the external behavior of
the system and its operational constraints. They should not be worried about
how the system should be constructed or implemented. However, at the level of
detail necessary to completely specify a complex software system, it is
impossible, in practice, to exclude all information about the project.

Natural language is often used to write system specifications for the

specifications as well as user requirements. However, because system
requirements are more detailed than user requirements, natural language
specifications may be confusing and hard to understand:

Natural language understanding depends on the specification readers and

writers that uses the same words for the same notion. This leads to
misunderstandings because of an ambiguity of natural language.

A natural linguistic requirements specification is over flexible. You could tell you
the same thing in completely different ways. It is up to the reader to find out
when requirements are the same and when they are distinct. There is no easy
way to modularise natural-language requirements. It may be difficult to find all
the related terms and conditions set forth. To discover the consequence of a
transformation, you may need to look at every requirement rather than at simply a
group of connected requirements.
 Structured language Specification:
● Structured natural language is a way of writing system specifications for
where the freedom of the requirements writer is limited, and all the
demands are written in a standard way.
● The advantage of this approach is that it maintains most of the fluency
and understandability of natural language but ensures that some degree
of uniformity remains imposed on the specification.
● Structured language notations restrict the terminology that can be used
and use templates to specify system requirements. They can incorporate
control constructs derived from programming languages and graphical
emphasizing to partition the specification.
When a standard form can be used to specify the functional requirements, the
following data should be included:

1. Description of the feature or entity being specified

2. Explanation of its inputs as well as where these come from

3. Description of its outputs and somewhere these go to

4. Suggestion of which other entities is used (the requires part)

5. Explanation of the action to be carried out

6. If a functional approach is used, a pre-condition setting out what should be

true before the function is called and a post-condition if you specify what is true
after the function is called

7. Description of the side effects (if any) of the operation

Graphical models are most useful when you need to show how state changes
using sequence diagram there are three basic subsequence used:

1. Validate card the user s card is authenticated by checking the card number
and user’s PIN.

2. Handle request the user's request is handled through the system. For a
withdrawal, the database must be queried to check the user's balance and to
debit the sum withdrawn. Notice the exception here if the requestor does not
have enough cash in their account.

3. Complete transaction the users card will be returned and, when it is removed,
the cash and receipt are delivered.
Interface Specification:
1. Procedural interfaces where existing systems or subsystems provide a range
of services that are accessed by calling interface procedures. These interfaces
are sometimes called Application Programming Interfaces.

2. Data structures that are passed from a particular sub-system to another.

Graphical information from the models are the best entries for this type of
description. If necessary, system descriptions in Java or python may be
automatically generated from these descriptions.
 3. Representations of data that have been established for an already existing
sub-system. These interfaces are most common in the integrated, real-time system.
Some programming languages like Ada support this level of specification. However, the
best way to explain these is probably to use a diagram of the structure along with
annotations explaining the function of every group of bits.

The Software Requirements Document

Without a map (or well, Google Maps!), it can get tough traveling to a new city or
country. You wouldn’t know what transport to take or which direction to travel in, making
it almost impossible to reach your destination.

Similarly, in software development, you are highly unlikely to create the right product
without proper documentation of software requirements.

Documentation ensures that the software development team or other stakeholders are
on the same page regarding what needs to be built and are fully aware of the goal,
scope, functional requirements, challenges, and budget regarding the software.
However, as much as creating software is exciting, documenting its requirements can
be boring and tiresome.

These documents are often long, text-heavy, and full of technical jargon, making them
very difficult to understand. This makes them highly vulnerable to misinterpretations
and can thus, lead to disastrous results.

To avoid costly design mistakes, product managers and software developers often use
pre-made templates that keep the documentation process to the point and easy to
understand.
What is a Software Requirements Document? – Definition

A software requirements document (also known as software requirements

specifications) is a document that describes the intended use-case, features, and
challenges of a software application.

These documents are created before the project has started development in order to
get every stakeholder on the same page regarding the software’s functionality.

Software requirements are written up by the tech team depending on the project they
are working on. As non-technical colleagues, clients, and partners get involved it’s
important to ensure that everyone is on the same page and agree with the scope,
budget, and goal of the project.

Why is a Software Requirements Document Important?

Software requirement documents provide an important map of the product being built,
the features that will be included, and much more.

This roadmap helps to keep the technical and non-technical team on the same
wavelength as to what the expectations are. It helps to ensure that the product is built
meeting the needs whether it’s for internal purposes, for users or clients.

What You Should Include in Your Software Requirements Document?

A typical software requirements document should involve the following details:

Software Requirements Document

1. Introduction

1.1 Purpose: Set the expectations for the outcome of the product.

1.2 Intended Audience: Who is the software for? Who is the end-user? Will the software
be used internally at a company or externally?

1.3 Intended Use: What is the software for? What problem is it solving?
1.4 Scope: Explain the scope of the software. What are the main goals and objectives?
How do they relate to the company’s goals?

1.5 Definitions and Acronyms: Provide an overview of any definitions the reader should
understand before reading on.

2. Overall Description: Describe what you are building and for who.

2.1 User Needs: Explain the user needs for this software.

2.2 Assumptions and Dependencies: What assumptions are you making that could
cause an error in your approach? Is the project reliant on any other factors that could
affect the development of the software?

3. System Features and Requirements

3.1 Functional Requirements: Take time to define the functional requirements that are
essential for the software to build.

3.2 External Interface Requirements: Are there any UX and UI requirements that you
must keep in mind as you build?

3.3 System Features: What features are required for the software to even work.

3.4 Nonfunctional Requirements: Are there any non-functional requirements that you
need to address (i.e. budget, team, etc.)

OR

-> (THIS IS REFERENCE BOOK CONTENT, YOU CAN WRITE ANY WHICH YOU WISH)

How can a client and provider reach a shared understanding of the concept of the
product? It is not easy when they speak several languages. A customer defines a
product at a high-level concept level, focusing on the external system behaviour: what it
will be doing and how end-users will work with it. Meanwhile, developers think of the
product in terms of its own internal characteristics. That is why a Business Analyst
steps in to convert a customer’s needs into requirements, and further turn them into
tasks for developers. This is initially done by writing software requirements
specifications.
 ● Poorly specified requirements lead to some functionality not being included in
the application. Every assumption should be clearly communicated rather than
just implied.
● For eg: NASA’s Mars Climate Orbiter mission failed due to conflicting units of
measure. Nobody specified beforehand that the mindset control system and
navigation software must both use the same metric or imperial units.
● For some, it went without saying, everyone else did not find it as obvious. This is
a widespread problem that keeps happening even to the best specialists if not
prevented.

Inaccurate requirements gathering is one of the top causes for project failure

The manufacture of the requirements stage of a software development process is

Software Requirements Specifications (SRS) (also called a requirements document).
This report lays a foundation for software development activities and is constructing
when whole requirements are elicited and analyzed.
SRS is a formal report, which serves as a representation of software that enables the
customers to review whether it (SRS) is in accordance with their requirements. Also, it
includes user requirements for a system in addition to the detailed requirements of the
system requirements
The SRS is a specification for a particular software product, program, or a set of
applications which perform functions in a specific environment. It serves several
purposes depending on who is writing it. First, the 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 expectations of the users. The
second case, SRS, is written for different purposes and serves as a contract detail
between customer and developer. SRS is at the bottom of the software requirements
pyramid, which goes like this:
Top tier – the high-level business requirements (BRs) dictating the aim behind the
product,
Middle tier – user requirements (URs) that picture an end-user and their needs, and
Bottom tier – SRSs that specify the product’s features are available in tech terms.

Solid arrows show how requirement types (ovals) are sorted into the documents
(rectangles). While dotted arrows show which requirement type is the origin of or
influences another on
SRS Software and Template

An SRS template provides a handy reminder of what kinds of knowledge to explore.

Every software development organization would adopt one or more standard SRS
templates for their projects. There are various templates available depending on the
design class. Here is an example of an SRS template that works well for many types of
projects.

Structure with explanation of SRS:

 SOFTWARE PROCESS

Software is the set of instructions in the form of programs to govern the computer
system and to process the hardware components. To produce a software product the
set of activities is used. This set is called a software process.
Software Development : In this process, designing, programming, documenting,
testing, and bug fixing is done.
Components of Software :
There are three components of the software: These are : Program, Documentation, and
Operating Procedures.
1. Program –
A computer program is a list of instructions that tell a computer what to do.

2. Documentation –
Source information about the product contained in design documents,
detailed code comments, etc.

3. Operating Procedures –
Set of step-by-step instructions compiled by an organization to help workers
carry out complex routine operations.

There are four basic key process activities:

1. Software Specifications –
In this process, detailed description of a software system to be developed
with its functional and non-functional requirements.

2. Software Development –
In this process, designing, programming, documenting, testing, and bug fixing
is done.

3. Software Validation –
In this process, evaluation software product is done to ensure that the
software meets the business requirements as well as the end users needs.
 4. Software Evolution –
It is a process of developing software initially, then timely updating it for
various reasons.

Software Crisis :
1. Size and Cost –
Day to day growing complexity and expectation out of software. Software are
more expensive and more complex.

2. Quality –
Software products must have good quality.

3. Delayed Delivery –
Software takes longer than the estimated time to develop, which in turn leads
to cost shooting up.

Software Development Process Model:

Waterfall model

What is a Waterfall model?

The Waterfall model is the oldest model used by the IT industry to develop software.

There are various models and processes which are used by different companies, but the
waterfall model is the oldest, safest, and easy model in the IT industry.

It is the easiest model for building software that represents real life.
 1. Requirements

Consider if there is a client and he wants to develop software, then the client reaches
out to the company. Suppose he reaches out to the service-based company and asks
the company to build the software for me.

What does the company do?

Company will collect all the requirements, the knowledge that the customer has or the
client want to have on his software, the company will collect all the information from the
client and prepare the documentation. Once this activity is performed, then the design
phase gets started.

2. Design

In this phase, we prepare the high-level and low-level designs. Before developing the
software, the design of the software is required. Suppose the customer wants
e-commerce website similar to the Amazon, then UI(User Interface) of the website will
be made by the designer and dataflows are also designed in this phase that how data
will flow. Once this phase is completed, the development phase will get started.

3. Development

In the Development phase, the software development team starts coding and
developing the software. This is the longest phase of the waterfall model as developers
need more time to build the software. Once the development of the software is
completed, then the project is handed over to the testers.

4. Testing

The testing team will test the software, and if any bug is found, then they inform the
developers about the issue they found and make sure that the bug is fixed. They ensure
that the end-to-end software is completed.

5. Deployment

Once the project is tested, the project is deployed so that it becomes live to the real-time
users.

6. Maintenance

Finally, the project is deployed and available to the clients. Clients want the maintenance
period for one or two years because if any bug is found or want a slightly enhanced
feature in the project, so they need some team to handle such stuff. Due to this reason,
they go for the maintenance period
Example of Waterfall model

Suppose the client wants an app like a WhatsApp, so he reaches to the company where
both the company and the client had a discussion for 2 months. The company made the
documentation of all the requirements in 2 months.

Now, the development team starts developing the software and suppose it took around
10 months to develop the software. It means that 12 months have been used, i.e., 2
months in the requirement phase and 10 months in a development phase, but still the
client does not have the idea about the internal phases.

Once the development is completed, testing is done, and it will take around 2 months
for software quality testing. Once the testing is done, it goes to the integration and
launch so that WhatsApp will become live. However, when it reaches the client, the
client says that it has taken more than a year and the software that I received was not
what I expected.

This happened because the client had only verbal communication with the software
team. If the client wants some changes in the software, then the whole process will be
executed again.
Advantages of Waterfall model

● This model is simple to implement and the number of resources that are required
for it is minimal.

● The requirements are simple and explicitly declared; they remain unchanged
during the entire project development.

● The start and end points for each phase are fixed, which makes it easy to cover
progress.

● The release date for the complete product, as well as its final cost, can be
determined before development.

● It gives easy control and clarity for the customer due to a strict reporting system.

Disadvantages of Waterfall model

● In this model, the risk factor is higher, so this model is not suitable for more
significant and complex projects.

● This model cannot accept the changes in requirements during development.

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

● Since the testing is 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

Prototyping Model has following six SDLC phases as follow:

Step 1: Requirements gathering and analysis

A prototyping model starts with requirement analysis. In this phase, the requirements of
the system are defined in detail. During the process, the users of the system are
interviewed to know what is their expectation from the system.

Step 2: Quick design

The second phase is a preliminary design or a quick design. In this stage, a simple
design of the system is created. However, it is not a complete design. It gives a brief
idea of the system to the user. The quick design helps in developing the prototype.
Step 3: Build a Prototype
In this phase, an actual prototype is designed based on the information gathered from
quick design. It is a small working model of the required system.

Step 4: Initial user evaluation

In this stage, the proposed system is presented to the client for an initial evaluation. It
helps to find out the strength and weakness of the working model. Comments and
suggestions are collected from the customer and provided to the developer.

Step 5: Refining prototype

If the user is not happy with the current prototype, you need to refine the prototype
according to the user’s feedback and suggestions.
This phase will not be over until all the requirements specified by the user are met.
Once the user is satisfied with the developed prototype, a final system is developed
based on the approved final prototype.

Step 6: Implement Product and Maintain

Once the final system is developed based on the final prototype, it is thoroughly tested
and deployed to production. The system undergoes routine maintenance for minimizing
downtime and preventing large-scale failures.

Types of Prototyping Models

Four types of Prototyping models are:

1. Rapid Throwaway prototypes
2. Evolutionary prototype
3. Incremental prototype
4. Extreme prototype
Rapid Throwaway Prototype

● Rapid throwaway is based on the preliminary requirement.

● It is quickly developed to show how the requirement will look visually.
● The customer’s feedback helps make changes to the requirement, and the
prototype is again created until the requirement is baselined.
● In this method, a developed prototype will be discarded and will not be a part
of the ultimately accepted prototype.
● This technique is useful for exploring ideas and getting instant feedback for
customer requirements.

Evolutionary Prototyping

● Here, the prototype developed is incrementally refined based on customer’s

feedback until it is finally accepted.
● It helps you to save time as well as effort. That’s because developing a
prototype from scratch for every interaction of the process can sometimes
be very frustrating.
 ● This model is helpful for a project which uses a new technology that is not well
understood.
● It is also used for a complex project where every functionality must be
checked once. It is helpful when the requirement is not stable or not understood
clearly at the initial stage.

Incremental Prototyping

● In incremental Prototyping, the final product is decimated into different small

prototypes and developed individually.
● Eventually, the different prototypes are merged into a single product. This
method is helpful to reduce the feedback time between the user and the
application development team.

Extreme Prototyping:
Extreme prototyping method is mostly used for web development. It consists of three
sequential phases.
1. Basic prototype with all the existing pages is present in the HTML format.
2. You can simulate a data process using a prototype services layer.
3. The services are implemented and integrated into the final prototype.

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Support early product marketing
4. Reduce Maintenance cost.
5. 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

○ Costs customer money

○ Needs committed customer

 ○ Difficult to finish if customer withdraw

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

ITERATIVE DEVELOPMENT

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 accessing earlier phases, in which the variations are made
respectively.

The final output of the project was 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 programmes 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 behaviour and validity of the developed product. And if there are any error
found then the process starts again from the designing phase.

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(Pros) of Iterative Model:

1. Testing and debugging during smaller iterations is easy.

2. A Parallel development can be planned.

 3. It is easily acceptable to the 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(Cons) 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.

Rational Unified Process (RUP)

● Rational Unified Process (RUP) is an agile software development methodology.

● RUP splits the project life cycle into five phases.
● During each of the phases, all six core development disciplines take place:
business modelling, requirements, analysis and design, implementation, testing,
and deployment.
● However, certain processes are more important and take up more time during
every stage.
● For example, business modelling mostly takes place during the early phases,
inception and elaboration. Each of five phases has the main objective, which has
to be completed before the project can progress to the next phase.
● The main goal of RUP is to create high quality software with a predictable
budget and time frame.
● Each of the life cycle phases can be repeated, if needed, until the main
objectives are met. Once the transition stage is completed successfully, the
project is finished.
1. Inception –
○ Communication and planning are the main ones.
○ Identifies the scope of the project using a use-case model allowing
managers to estimate costs and time required.
○ Customers’ requirements are identified and then it becomes easy to
make a plan for the project.
○ The project plan, Project goal, risks, use-case model, and Project
description, are made.
○ The project is checked against the milestone criteria and if it couldn’t pass
these criteria then the project can be either canceled or redesigned.

2. Elaboration –
○ Planning and modeling are the main ones.
○ A detailed evaluation and development plan is carried out and
diminishes the risks.
○ Revise or redefine the use-case model (approx. 80%), business case, and
risks.
 ○ Again, checked against milestone criteria and if it couldn’t pass these
criteria then again the project can be canceled or redesigned.
○ Executable architecture baseline.

3. Construction –
○ The project is developed and completed.
○ System or source code is created and then testing is done.
○ Coding takes place.

4. Transition –
○ The final project is released to the public.
○ Transit the project from development into production.
○ Update project documentation.
○ Beta testing is conducted.
○ Defects are removed from the project based on feedback from the public.

5. Production –
○ The final phase of the model.
○ The project is maintained and updated accordingly.

Advantages:
1. It provides good documentation, it completes the process in itself.
2. It provides risk-management support.
3. It reuses the components, and hence total time duration is less.
4. Good online support is available in the form of tutorials and training.

Disadvantages:
1. Team of expert professionals is required, as the process is complex.
2. Complex and not properly organized process.
3. More dependency on risk management.
4. Hard to integrate again and again.
RAD (Rapid Application Development) Model
● The RAD (Rapid Application Development) model is based on prototyping and
iterative development with no specific planning involved. The process of
writing the software itself involves the planning required for developing the
product.
● Rapid Application Development focuses on gathering customer requirements
through workshops or focus groups, early testing of the prototypes by the
customer using iterative concepts, reuse of the existing prototypes (components),
continuous integration and rapid delivery.

What is RAD?

● Rapid application development is a software development methodology that uses

minimal planning in favor of rapid prototyping. A prototype is a working model
that is functionally equivalent to a component of the product.
● In the RAD model, the functional modules are developed in parallel as
prototypes and are integrated to make the complete product for faster product
delivery. Since there is no detailed preplanning, it makes it easier to incorporate
the changes within the development process.
● RAD projects follow an iterative and incremental model and have small teams
comprising of developers, domain experts, customer representatives and
other IT resources working progressively on their component or prototype.
● The most important aspect for this model to be successful is to make sure that
the prototypes developed are reusable.
The various phases of RAD are as follows:
1.Business Modeling: 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 Modeling: 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 Modeling: The information objects 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 the RAD Model?

● When the system should need to create the project that modularizes in a short
span time (2-3 months).

● When the requirements are well-known.

● When the technical risk is limited.

● When there's a necessity to make a system, which is modularized in 2-3 months

of period.

● It should be used only if the budget allows the use of automatic code generating
tools.

Advantage of RAD Model

● This model is flexible for change.

● In this model, changes are adoptable.

● Each phase in RAD brings highest priority functionality to the customer.

● It reduced development time.

● It increases the reusability of features.

Disadvantage of RAD Model

● It required highly skilled designers.

● All applications are not compatible with RAD.

 ● For smaller projects, we cannot use the RAD model.

● On the high technical risk, it's not suitable.

● Required user involvement

TIME BOXING MODEL

● In time boxing model, development is done iteratively as in the iterative
enhancement model. However, in time boxing model, each iteration is done in a
timebox of fixed duration.
● The functionality to be developed is adjusted to fit the duration of the timebox.
Moreover, each timebox is divided into a sequence of fixed stages where each
stage performs a clearly defined task (analysis, implementation, and deploy) that
can be done independently.
● This model also requires that the time duration of each stage is approximately
equal so that the pipelining concept is employed to have the reduction in
development time and product releases.
● There is a dedicated team for each stage so that the work can be done in
pipelining. Thus, stages should be chosen in such a way that each stage perform
some logical unit of work that becomes the input for next stage.
● In addition to the advantages of iterative model, time boxing model has some
other advantages too. Various advantages and disadvantages associated with
timeboxing model are listed in Table.
 AGILE SOFTWARE DEVELOPMENT
AGILE METHODS

Agile is a software development methodology to build a software incrementally using

short iterations of 1 to 4 weeks so that the development process is aligned with the
changing business needs.
Instead of a single-pass development of 6 to 18 months where all the requirements
and risks are predicted upfront, Agile adopts a process of frequent feedback where a
workable product is delivered after 1 to 4-week iteration.

What is Agile Methodology?

Agile Methodology meaning a practice that promotes continuous iteration of

development and testing throughout the software development lifecycle of the project.
In the Agile model in software testing, both development and testing activities are
concurrent, unlike the Waterfall model.
Agile Principles

Plan-driven and agile development

Plan Driven Development (PDD):
A plan-driven approach to software engineering is based around separate development
stages with the outputs to be produced at each of these stages planned in advance.
Actually this action plan is based on the execution of an ordered set of task-specific
levels.
We can say it is an attitude to software engineering wherever it is planned to feature
how the development procedure will take place.
A plan-driven development project sets out a program for the project, including the
available resources, work breakdowns, work completion schedules etc.
● Organizing the team and roles of different members.
● Risk Analysis and Probabilities, Prospects, Strategies to Arise.
● Hardware as well as software resource requirements.
● Deciding Activities, Deliveries, and Milestones.
● Allotment of people and allocation of their time.
● Monitoring and Reporting systems.
Agile development

Let’s see a brief overview of how development occurs in Agile philosophy.

● In Agile development, Design and Implementation are considered to

be the central activities in the software process.
● Design and Implementation phase also incorporate other activities such
as requirements elicitation and testing into it.
● In an agile approach, iteration occurs across activities. Therefore,
the requirements and the design are developed together, rather
than separately.
● The allocation of requirements and the design planning and
development as executed in a series of increments. In contrast with the
conventional model, where requirements gathering needs to be
completed in order to proceed to the design and development phase, it
gives Agile development an extra level of flexibility.
● An agile process focuses more on code development rather than
documentation.

Example: Let’s go through an example to understand clearly how agile

actually works.

A Software company named ABC wants to make a new web browser for the
latest release of its operating system. The deadline for the task is 10 months.
The company’s head assigned two teams named Team A and Team B for this
task. In order to motivate the teams, the company head says that the first team to
develop the browser would be given a salary hike and a one-week full-sponsored
travel plan. With the dreams of their wild travel fantasies, the two teams set out
on the journey of the web browser. Team A decided to play by the book and
decided to choose the Waterfall model for the development. Team B after a
heavy discussion decided to take a leap of faith and choose Agile as their
development model.

The Development plan of the Team A is as follows:

● Requirement analysis and Gathering – 1.5 Months

● Design of System – 2 Months
● Coding phase – 4 Months
● System Integration and Testing – 2 Months
● User Acceptance Testing – 5 Weeks

The Development plan for the Team B is as follows:

● Since this was an Agile, the project was broken up into several
iterations.
● The iterations are all of the same time duration.
● At the end of each iteration, a working product with a new feature has to
be delivered.
● Instead of Spending 1.5 months on requirements gathering, They will
decide the core features that are required in the product and decide
which of these features can be developed in the first iteration.
● Any remaining features that cannot be delivered in the first iteration will
be delivered in the next subsequent iteration, based on the priority
● At the end of the first iterations, the team will deliver working software
with the core basic features.
Both the team have put their best efforts to get the product to a complete stage.
But then out of blue due to the rapidly changing environment, the company’s
head came up with an entirely new set of features and wanted it to be
implemented as quickly as possible and wanted to push out a working model in 2
days.

Team A was now in a fix, they were still in their design phase and did not yet start
coding and they had no working model to display. And moreover, it was
practically impossible for them to implement new features since the waterfall
model there is not reverting back to the old phase once you proceed to the next
stage, which means they would have to start from square one again. That would
incur their heavy cost and a lot of overtime.

Team B was ahead of Team A in a lot of aspects, all thanks to Agile

Development. They also had the working product with most of the core
requirements since the first increment. And it was a piece of cake for them to add
the new requirements. All they had to do is schedule these requirements for the
next increment and then implement them.

AGILE DEVELOPMENT
"Agile process model" refers to a software development approach based on iterative
development. Agile methods break tasks into smaller iterations, or parts do not
directly involve long term planning.
The project scope and requirements are laid down at the beginning of the development
process. Plans regarding the number of iterations, the duration and the scope of each
iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller parts
helps to minimize the project risk and to reduce the overall project delivery time
requirements. Each iteration involves a team working through a full software
development life cycle including planning, requirements analysis, design, coding, and
testing before a working product is demonstrated to the client.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering

2. Design the requirements

3. Construction/ iteration

4. Testing/ Quality assurance

 5. Deployment

6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed to build the
project. Based on this information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the
high-level UML diagram to show the work of new features and show how it will apply to
your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work
environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.

Extreme Programming (XP)

Extreme Programming technique is very helpful when there are constantly changing
demands or requirements from the customers or when they are not sure about the
functionality of the system.
It advocates frequent “releases” of the product in short development cycles, which
inherently improves the productivity of the system and also introduces a checkpoint
where any customer requirements can be easily implemented.
The XP develops software keeping customer in the target.

Business requirements are gathered in terms of stories. All those stories are stored in a
place called the parking lot.
In this type of methodology, releases are based on the shorter cycles called Iterations
with span of 14 days time period.
Each iteration includes phases like coding, unit testing and system testing where at
each phase some minor or major functionality will be built in the application.

Why is it called “Extreme?”

Extreme Programming takes the effective principles and practices to extreme levels.

● Code reviews are effective as the code is reviewed all the time.

● Testing is effective as there is continuous regression and testing.

● Design is effective as everybody needs to do refactoring daily.

● Integration testing is important as integrate and test several times a day.

● Short iterations are effective as the planning game for release planning

and iteration planning.

Agile Project Management

Agile Project Management is one of the revolutionary methods introduced for the
practice of project management.

This is one of the latest project management strategies that is mainly applied to project
management practice in software development. Therefore, it is best to relate agile
project management to the software development process when understanding it.

From the inception of software development as a business, there have been a number
of processes following, such as the waterfall model.

With the advancement of software development, technologies and business

requirements, the traditional models are not robust enough to cater the demands.

Therefore, more flexible software development models were required in order to

address the agility of the requirements. As a result of this, the information technology
community developed agile software development models.

'Agile' is an umbrella term used for identifying various models used for agile
development, such as Scrum.

Since agile development model is different from conventional models, agile project
management is a specialized area in project management.
 The Agile Process
It is required for one to have a good understanding of the agile development process in
order to understand agile project management.

There are many differences in agile development model when compared to traditional
models:

● The agile model emphasizes on the fact that the entire team should be a tightly
integrated unit. This includes the developers, quality assurance, project management,
and the customer.
● Frequent communication is one of the key factors that makes this integration possible.
Therefore, daily meetings are held in order to determine the day's work and
dependencies.
● Deliveries are short-term. Usually a delivery cycle ranges from one week to four weeks.
These are commonly known as sprints.
● Agile project teams follow open communication techniques and tools which enable the
team members (including the customer) to express their views and feedback openly
and quickly. These comments are then taken into consideration when shaping the
requirements and implementation of the software.