UNIT-1

1.Build a detailed explanation of the Waterfall Model and its key phases in
software development.

Waterfall Model
Phases of SDLC Waterfall Model – Design
The Waterfall Model is a linear and sequential approach to software development that consists of several phases
that must be completed in a specific order.
The Waterfall Model has six phases which are:
1. Requirements: The first phase involves gathering requirements from stakeholders and analysing them
to understand the scope and objectives of the project.
2. Design: Once the requirements are understood, the design phase begins. This involves creating a
detailed design document that outlines the software architecture, user interface, and system components.

3. Development: The Development phase include implementation involves coding the software based on the
design specifications. This phase also includes unit testing to ensure that each component of the software is
working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that it meets the requirements
and is free from defects.
5. Deployment: Once the software has been tested and approved, it is deployed to the
production environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance, which involves fixing any issues
that arise after the software has been deployed and ensuring that it continues to meet the requirements over
time.
The classical waterfall model divides the life cycle into a set of phases. This model considers that one phase can
be started after the completion of the previous phase. That is the output of one phase will be the input to the next
phase. Thus the development process can be considered as a sequential flow in the waterfall. Here the phases do
not overlap with each other. The different sequential phases of the classical waterfall model are shown in the
below figure.

1
The waterfall model is a software development model used in the context of large, complex projects, typically in
the field of information technology. It is characterized by a structured, sequential approach to project
management and software development.
Let us now learn about each of these phases in detail which include further phases.

1. Feasibility Study
The main goal of this phase is to determine whether it would be financially and technically feasible to develop the
software. The feasibility study involves understanding the problem and then determining the various possible
strategies to solve the problem. These different identified solutions are analyzed based on their benefits and
drawbacks. The best solution is chosen and all the other phases are carried out as per this solution strategy.
2. Requirements Analysis and Specification
The requirement analysis and specification phase aims to understand the exact requirements of the customer and
document them properly. This phase consists of two different activities.

Requirement gathering and analysis: Firstly all the requirements regarding the software are gathered from the
customer and then the gathered requirements are analyzed. The goal of the analysis part is to remove
incompleteness (an incomplete requirement is one in which some parts of the actual requirements have been
omitted) and inconsistencies (an inconsistent requirement is one in which some part of the requirement
contradicts some other part).
Requirement specification: These analyzed requirements are documented in a software requirement specification
(SRS) document. SRS document serves as a contract between the development team and customers. Any future
dispute between the customers and the developers can be settled by examining the SRS document.
2
 3. Design
The goal of this phase is to convert the requirements acquired in the SRS into a format that can be coded in a
programming language. It includes high-level and detailed design as well as the overall software architecture. A
Software Design Document is used to document all of this effort (SDD).

4. Coding and Unit Testing

In the coding phase software design is translated into source code using any suitable programming language.
Thus each designed module is coded. The unit testing phase aims to check whether each module is working
properly or not.

5. Integration and System testing

Integration of different modules is undertaken soon after they have been coded and unit tested. Integration of
various modules is carried out incrementally over several steps. During each integration step, previously planned
modules are added to the partially integrated system and the resultant system is tested. Finally, after all the
modules have been successfully integrated and tested, the full working system is obtained and system testing is
carried out on this. System testing consists of three different kinds of testing activities as described below.
Alpha testing: Alpha testing is the system testing performed by the development team.
Beta testing: Beta testing is the system testing performed by a friendly set of customers.
Acceptance testing: After the software has been delivered, the customer performs acceptance testing to
determine whether to accept the delivered software or reject it.

6. Maintenance
Maintenance is the most important phase of a software life cycle. The effort spent on maintenance is 60% of the
total effort spent to develop a full software. There are three types of maintenance.
Corrective Maintenance: This type of maintenance is carried out to correct errors that were not discovered
during the product development phase.
Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the system
based on the customer’s request.
Adaptive Maintenance: Adaptive maintenance is usually required for porting the software to work in a new
environment such as working on a new computer platform or with a new operating system.

2. Identify the key benefits of using Incremental Process Models in large-scale software
development projects.

Incremental Process Models

What is the Incremental Process Model?

3
First, a simple working system implementing only a few basic features is built and then that is delivered to the
customer. Then thereafter many successive iterations/ versions are implemented and delivered to the customer
until the desired system is released.

A, B, and C are modules of Software Products that are incrementally developed and delivered.
Phases of incremental model
Requirements of Software are first broken down into several modules that can be incrementally constructed and
delivered.

Phases of incremental model

1. Requirement analysis: In Requirement Analysis At any time, the plan is made just for the next increment
and not for any kind of long-term plan. Therefore, it is easier to modify the version as per the needs of the
customer.
2. Design & Development: At any time, the plan is made just for the next increment and not for any kind of
long-term plan. Therefore, it is easier to modify the version as per the needs of the customer. The
Development Team first undertakes to develop core features (these do not need services from other features)
of the system. Once the core features are fully developed, then these are refined to increase levels of
capabilities by adding new functions in Successive versions. Each incremental version is usually developed
using an iterative waterfall model of development.
3. Deployment and Testing: After Requirements gathering and specification, requirements are then split into
several different versions starting with version 1, in each successive increment, the next version is
constructed and then deployed at the customer site. in development and Testing the product is checked and
tested for the actual process of the model.
4. Implementation: In implementation After the last version (version n), it is now deployed at the client site.
Requirement Process Model
4
 Requirement Process Model

Types of Incremental Model

1. Staged Delivery Model
2. Parallel Development Model
1. Staged Delivery Model
Construction of only one part of the project at a time.

Staged Delivery Model

2. Parallel Development Model

Different subsystems are developed at the same time. It can decrease the calendar time needed for the
development, i.e. TTM (Time to Market) if enough resources are available.

5
 Parallel Development Model

Advantages of the Incremental Process Model

1. Prepares the software fast.
2. Clients have a clear idea of the project.
3. Changes are easy to implement.
4. Provides risk handling support, because of its iterations.
5. Adjusting the criteria and scope is flexible and less costly.
6. Comparing this model to others, it is less expensive.
7. The identification of errors is simple.

Disadvantages of the Incremental Process Model

1. A good team and proper planned execution are required.
2. Because of its continuous iterations the cost increases.
3. Issues may arise from the system design if all needs are not gathered upfront throughout the program
lifecycle.
4. Every iteration step is distinct and does not flow into the next.
5. It takes a lot of time and effort to fix an issue in one unit if it needs to be corrected in all the units.

3. Identify the types of Evolutionary Process Models

Evolutionary Process Models
The evolutionary model is based on the concept of making an initial product and then evolving the
software product over time with iterative and incremental approaches with proper feedback. In this type of model,
the product will go through several iterations and come up when the final product is built through multiple
iterations. The development is carried out simultaneously with the feedback during the development. This model
has a number of advantages such as customer involvement, taking feedback from the customer during
development, and building the exact product that the user wants. Because of the multiple iterations, the chances
of errors get reduced and the reliability and efficiency will increase.
6
Types of Evolutionary Process Models

1. Iterative Model
2. Incremental Model
3. Spiral Model

7
 Iterative Model
In the iterative model first, we take the initial requirements then we enhance the product over multiple iterations until
the final product gets ready. In every iteration, some design modifications were made and some changes in
functional requirements is added. The main idea behind this approach is to build the final product through multiple
iterations that result in the final product being almost the same as the user wants with fewer errors and the
performance, and quality would be high.

Incremental Model

In the incremental model, we first build the project with basic features and then evolve the project in every iteration, it
is mainly used for large projects. The first step is to gather the requirements and then perform analysis, design,
code, and test and this process goes the same over and over again until our final project is ready.

Spiral Model
The spiral model is a combination of waterfall and iterative models and in this, we focused on risk handling along
with developing the project with the incremental and iterative approach, producing the output quickly as well as it
is good for big projects. The software is created through multiple iterations using a spiral approach. Later on, after
successive development the final product will develop, and the customer interaction is there so the chances of error
get reduced.

8
5. Build a detailed outline of the Spiral Model, explaining how its iterative
approach supports risk analysis and project management.
Spiral Model
What is the Spiral Model?
The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a systematic and
iterative approach to software development. In its diagrammatic representation, looks like a spiral with many
loops. The exact number of loops of the spiral is unknown and can vary from project to project. Each loop of the
spiral is called a phase of the software development process.
Some Key Points regarding the phase of a Spiral Model:
1. The exact number of phases needed to develop the product can be varied by the project manager depending
upon the project risks.
2. As the project manager dynamically determines the number of phases, the project manager has an important
role in developing a product using the spiral model.
3. It is based on the idea of a spiral, with each iteration of the spiral representing a complete software
development cycle, from requirements gathering and analysis to design, implementation, testing, and
maintenance.

What Are the Phases of the Spiral Model?

The Spiral Model is a risk-driven model, meaning that the focus is on managing risk through multiple iterations
of the software development process. It consists of the following phases:
1. Objectives Defined: In first phase of the spiral model we clarify what the project aims to achieve, including
functional and non-functional requirements.
2. Risk Analysis: In the risk analysis phase, the risks associated with the project are identified and evaluated.
3. Engineering: In the engineering phase, the software is developed based on the requirements gathered in the
previous iteration.
4. Evaluation: In the evaluation phase, the software is evaluated to determine if it meets the customer’s
requirements and if it is of high quality.
5. Planning: The next iteration of the spiral begins with a new planning phase, based on the results of the
evaluation.

9
The Spiral Model is often used for complex and large software development projects, as it allows for a more
flexible and adaptable approach to software development. It is also well-suited to projects with significant
uncertainty or high levels of risk.
The Radius of the spiral at any point represents the expenses (cost) of the project so far, and the angular dimension
represents the progress made so far in the current phase.

10
 Spiral Model

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

1. Objectives determination and identify alternative solutions: Requirements are gathered from the
customers and the objectives are identified, elaborated, and analyzed at the start of every phase. Then
alternative solutions possible for the phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select
the best possible solution. Then the risks associated with that solution are identified and the risks are
resolved using the best possible strategy. At the end of this quadrant, the Prototype is built for the best
possible solution.
3. Develop the next version of the Product: During the third quadrant, the identified features are developed
and verified through testing. At the end of the third quadrant, the next version of the software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so-far developed
version of the software. In the end, planning for the next phase is started.

Risk Handling in Spiral Model

A risk is any adverse situation that might affect the successful completion of a software project. The most
important feature of the spiral model is handling these unknown risks after the project has started. Such risk
resolutions are easier done by developing a prototype.
1. The spiral model supports coping with risks by providing the scope to build a prototype at every phase of
software development.

11
 2. The Prototyping Model also supports risk handling, but the risks must be identified completely before the
start of the development work of the project.
3. But in real life, project risk may occur after the development work starts, in that case, we cannot use the
Prototyping Model.
4. In each phase of the Spiral Model, the features of the product dated and analyzed, and the risks at that point
in time are identified and are resolved through prototyping.
5. Thus, this model is much more flexible compared to other SDLC models.

6. Develop a plan for implementing Agile practices in a team transitioning from a

traditional software development model.

Introduction to Agile Process

Agile Model
The meaning of Agile is swift or versatile."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
12
 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.

UNIT-2
1. Develop a comprehensive approach to gathering and analyzing requirements during the Requirements
Engineering process.
Requirements Engineering
What is Requirements Engineering?
A systematic and strict approach to the definition, creation, and verification of requirements for a software system
is known as requirements engineering. To guarantee the effective creation of a software product, the requirements
engineering process entails several tasks that help in understanding, recording, and managing the demands of
stakeholders.

13
 Requirements Engineering Process

Requirements Engineering Process

1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management

1. Feasibility Study
The feasibility study mainly concentrates on below five mentioned areas below. Among these Economic Feasibility
Study is the most important part of the feasibility analysis and the Legal Feasibility Study is less considered
feasibility analysis.

1. Technical Feasibility: In Technical Feasibility current resources both hardware software along required
technology are analyzed/assessed to develop the project. This technical feasibility study reports whether
there are correct required resources and technologies that will be used for project development. Along with
this, the feasibility study also analyzes the technical skills and capabilities of the technical team, whether
existing technology can be used or not, whether maintenance and up-gradation are easy or not for the chosen
technology, etc.
2. Operational Feasibility: In Operational Feasibility degree of providing service to requirements is analyzed
along with how easy the product will be to operate and maintain after deployment. Along with this other
operational scopes are determining the usability of the product, Determining suggested solution by the
software development team is acceptable or not, etc.
3. Economic Feasibility: In the Economic Feasibility study cost and benefit of the project are analyzed. This
means under this feasibility study a detailed analysis is carried out will be cost of the project for

14
 development which includes all required costs for final development hardware and software resources
required, design and development costs operational costs, and so on. After that, it is analyzed whether the
project will be beneficial in terms of finance for the organization or not.
4. Legal Feasibility: In legal feasibility, the project is ensured to comply with all relevant laws, regulations,
and standards. It identifies any legal constraints that could impact the project and reviews existing contracts
and agreements to assess their effect on the project’s execution. Additionally, legal feasibility considers
issues related to intellectual property, such as patents and copyrights, to safeguard the project’s innovation
and originality.
5. Schedule Feasibility: In schedule feasibility, the project timeline is evaluated to determine if it is realistic
and achievable. Significant milestones are identified, and deadlines are established to track progress
effectively. Resource availability is assessed to ensure that the necessary resources are accessible to meet the
project schedule. Furthermore, any time constraints that might affect project delivery are considered to
ensure timely completion. This focus on schedule feasibility is crucial for the successful planning and
execution of a project.

2. Requirements Elicitation
It is related to the various ways used to gain knowledge about the project domain and requirements. The various
sources of domain knowledge include customers, business manuals, the existing software of the same type,
standards, and other stakeholders of the project. The techniques used for requirements elicitation include
interviews, brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are
discussed here. Elicitation does not produce formal models of the requirements understood. Instead, it widens the
domain knowledge of the analyst and thus helps in providing input to the next stage.
Requirements elicitation is the process of gathering information about the needs and expectations of stakeholders for a
software system. This is the first step in the requirements engineering process and it is critical to the success of the
software development project. The goal of this step is to understand the problem that the software system is
intended to solve and the needs and expectations of the stakeholders who will use the system.
Several techniques can be used to elicit requirements, including:
 Interviews: These are one-on-one conversations with stakeholders to gather information about their needs
and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather information about their
needs and expectations.

15
  Focus Groups: These are small groups of stakeholders who are brought together to discuss their needs and
expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work environment to gather
information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software system, which can be used
to gather feedback from stakeholders and to validate requirements.
It’s important to document, organize, and prioritize the requirements obtained from all these techniques to ensure that
they are complete, consistent, and accurate.

3. Requirements Specification
This activity is used to produce formal software requirement models. All the requirements including the functional as
well as the non-functional requirements and the constraints are specified by these models in totality. During
specification, more knowledge about the problem may be required which can again trigger the elicitation process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition
diagrams(FDDs), data dictionaries, etc.
Requirements specification is the process of documenting the requirements identified in the analysis step in a clear,
consistent, and unambiguous manner. This step also involves prioritizing and grouping the requirements into
manageable chunks.
The goal of this step is to create a clear and comprehensive document that describes the requirements for the software
system. This document should be understandable by both the development team and the stakeholders.

Several types of requirements are commonly specified in this step, including

1. Functional Requirements: These describe what the software system should do. They specify the
functionality that the system must provide, such as input validation, data storage, and user interface.
2. Non-Functional Requirements: These describe how well the software system should do it. They specify
the quality attributes of the system, such as performance, reliability, usability, and security.
3. Constraints: These describe any limitations or restrictions that must be considered when developing the
software system.
4. Acceptance Criteria: These describe the conditions that must be met for the software system to be
considered complete and ready for release.

To make the requirements specification clear, the requirements should be written in a natural language and use simple
terms, avoiding technical jargon, and using a consistent format throughout the document. It is also important to
use diagrams, models, and other visual aids to help communicate the requirements effectively.
Once the requirements are specified, they must be reviewed and validated by the stakeholders and development team
to ensure that they are complete, consistent, and accurate.

4. Requirements Verification and Validation

Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to
customer requirements. If requirements are not validated, errors in the requirement definitions would propagate
to the successive stages resulting in a lot of modification and rework. The main steps for this process include:
1. The requirements should be consistent with all the other requirements i.e. no two requirements should
conflict with each other.
2. The requirements should be complete in every sense.
3. The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
16
Requirements verification and validation (V&V) is the process of checking that the requirements for a software
system are complete, consistent, and accurate and that they meet the needs and expectations of the stakeholders.
The goal of V&V is to ensure that the software system being developed meets the requirements and that it is
developed on time, within budget, and to the required quality.
1. Verification is checking that the requirements are complete, consistent, and accurate. It involves reviewing
the requirements to ensure that they are clear, testable, and free of errors and inconsistencies. This can
include reviewing the requirements document, models, and diagrams, and holding meetings and
walkthroughs with stakeholders.
2. Validation is the process of checking that the requirements meet the needs and expectations of the
stakeholders. It involves testing the requirements to ensure that they are valid and that the software system
being developed will meet the needs of the stakeholders. This can include testing the software system
through simulation, testing with prototypes, and testing with the final version of the software.
3. Verification and Validation is an iterative process that occurs throughout the software development life
cycle. It is important to involve stakeholders and the development team in the V&V process to ensure that
the requirements are thoroughly reviewed and tested.
It’s important to note that V&V is not a one-time process, but it should be integrated and continue throughout the
software development process and even in the maintenance stage.

5. Requirements Management
Requirement management is the process of analyzing, documenting, tracking, prioritizing, and agreeing on the
requirement and controlling the communication with relevant stakeholders. This stage takes care of the changing
nature of requirements. It should be ensured that the SRS is as modifiable as possible to incorporate changes in
requirements specified by the end users at later stages too. Modifying the software as per requirements in a
systematic and controlled manner is an extremely important part of the requirements engineering process.
Requirements management is the process of managing the requirements throughout the software development life
cycle, including tracking and controlling changes, and ensuring that the requirements are still valid and relevant.
The goal of requirements management is to ensure that the software system being developed meets the needs and
expectations of the stakeholders and that it is developed on time, within budget, and to the required quality.

Several key activities are involved in requirements management, including:

1. Tracking and controlling changes: This involves monitoring and controlling changes to the requirements
throughout the development process, including identifying the source of the change, assessing the impact of
the change, and approving or rejecting the change.
2. Version control: This involves keeping track of different versions of the requirements document and other
related artifacts.
3. Traceability: This involves linking the requirements to other elements of the development process, such as
design, testing, and validation.
4. Communication: This involves ensuring that the requirements are communicated effectively to all
stakeholders and that any changes or issues are addressed promptly.
5. Monitoring and reporting: This involves monitoring the progress of the development process and reporting
on the status of the requirements.

Requirements management is a critical step in the software development life cycle as it helps to ensure that the
software system being developed meets the needs and expectations of stakeholders and that it is developed on
time, within budget, and to the required quality. It also helps to prevent scope creep and to ensure that the
requirements are aligned with the project goals.

17
2. Build a step-by-step guide for effectively eliciting requirements from stakeholders
during the early stages of a software project.
Eliciting Requirements
What is Requirement Elicitation?
The process of investigating and learning about a system’s requirements from users, clients, and other stakeholders
is known as requirements elicitation. Requirements elicitation in software engineering is perhaps the most
difficult, most error-prone, and most communication-intensive software development.
1. Requirement Elicitation can be successful only through an effective customer-developer partnership. It is
needed to know what the users require.
2. Requirements elicitation involves the identification, collection, analysis, and refinement of the requirements
for a software system.
3. Requirement Elicitation is a critical part of the software development life cycle and is typically performed at
the beginning of the project.
4. Requirements elicitation involves stakeholders from different areas of the organization, including business
owners, end-users, and technical experts.
5. The output of the requirements elicitation process is a set of clear, concise, and well-defined requirements
that serve as the basis for the design and development of the software system.
6. Requirements elicitation is difficult because just questioning users and customers about system needs may
not collect all relevant requirements, particularly for safety and dependability.
7. Interviews, surveys, user observation, workshops, brainstorming, use cases, role-playing, and prototyping
are all methods for eliciting requirements.

Importance of Requirements Elicitation

1. Compliance with Business Objectives: The process of elicitation guarantees that the software development
endeavors are in harmony with the wider company aims and objectives. Comprehending the business context
facilitates the development of a solution that adds value for the company.
2. User Satisfaction: It is easier to create software that fulfills end users’ needs and expectations when they are
involved in the requirements elicitation process. Higher user pleasure and acceptance of the finished product
are the results of this.
3. Time and Money Savings: Having precise and well-defined specifications aids in preventing
miscommunication and rework during the development phase. As a result, there will be cost savings and the
project will be completed on time.
4. Compliance and Regulation Requirements: Requirements elicitation is crucial for projects in regulated
industries to guarantee that the software conforms with applicable laws and norms. In industries like
healthcare, finance, and aerospace, this is crucial.
5. Traceability and Documentation: Throughout the software development process, traceability is based on
well-documented requirements. Traceability helps with testing, validation, and maintenance by ensuring that
every part of the software can be linked to a particular requirement.

Requirements Elicitation Methods

There are several requirements elicitation methods. A few of them are listed below:

18
 Requirement Elicitation Techniques

1. Interviews
The objective of conducting an interview is to understand the customer’s expectations of the software.
It is impossible to interview every stakeholder hence representatives from groups are selected based on their
expertise and credibility. Interviews may be open-ended or structured.
1. In open-ended interviews, there is no pre-set agenda. Context-free questions may be asked to understand the
problem.
2. In a structured interview, an agenda of fairly open questions is prepared. Sometimes a proper questionnaire
is designed for the interview.

2. Brainstorming Sessions
 Brainstorming Sessions is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share views
 A highly trained facilitator is required to handle group bias and conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and their priority if possible.

19
 3. Facilitated Application Specification Technique
Its objective is to bridge the expectation gap – the difference between what the developers think they are supposed
to build and what customers think they are going to get. A team-oriented approach is developed for
requirements gathering. Each attendee is asked to make a list of objects that are:
1. Part of the environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated, the team is
divided into smaller sub-teams to develop mini-specifications and finally, a draft of specifications is written down
using all the inputs from the meeting.

4. Quality Function Deployment

In this technique customer satisfaction is of prime concern, hence it emphasizes the requirements that are valuable
to the customer.
3 types of requirements are identified:
 Normal requirements: In this the objective and goals of the proposed software are discussed with the
customer. For example – normal requirements for a result management system may be entry of marks,
calculation of results, etc.
 Expected requirements: These requirements are so obvious that the customer need not explicitly state
them. Example – protection from unauthorized access.
 Exciting requirements: It includes features that are beyond customer’s expectations and prove to be very
satisfying when present. For example – when unauthorized access is detected, it should back up and shut
down all processes.

5. Use Case Approach

Use Case technique combines text and pictures to provide a better understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional view of the system.
The components of the use case design include three major things – Actor, use cases, and use case diagram.
1. Actor: It is the external agent that lies outside the system but interacts with it in some way. An actor may be
a person, machine, etc. It is represented as a stick figure. Actors can be primary actors or secondary actors.
 Primary actors: It requires assistance from the system to achieve a goal.
 Secondary actor: It is an actor from which the system needs assistance.
2. Use cases: They describe the sequence of interactions between actors and the system. They capture
who(actors) do what(interaction) with the system. A complete set of use cases specifies all possible ways to
use the system.
3. Use case diagram: A use case diagram graphically represents what happens when an actor interacts with a
system. It captures the functional aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.
The success of an elicitation technique used depends on the maturity of the analyst, developers, users, and the customer
involved.

. Build a framework for software project estimation, incorporating both quantitative

and qualitative methods to improve accuracy.
1. What is software project estimation?

Long story short, software development estimation is a crucial process that revolves around predicting the project’s
20
 time and effort, cost, and scope; all this information is necessary for the planning stage and to ensure the project’s
success. Additionally, it also takes into consideration, in terms of custom software development, the experience of
the company you’re working with, their tech stack, and their own process they need to follow to finish the project
(also known as the software development life cycle).

Even though an estimation is not the final software cost but just a ballpark range of the project – it’s essential to be as
accurate as possible. To be transparent and fair, an estimate should take into consideration the following points but
doesn’t have to be limited to them:

 Tasks – the details of what needs to be done

 Resources – what human resources are available
 Rate – cost to time ratio, the payment currency, and discounts
 Duration – how long will the project take to complete
 Third-party services – what additional services are necessary for completing the project

2. Why is software project estimation important?

The estimation accuracy is crucial because the client needs to feel confident that they can fund the project before
committing to it. Also, there are many side effects of poor project estimates, like:

 Going over budget

 Cutting corners to avoid going over an unrealistic budget
 Running out of funds
 The developing team has low morale due to unrealistic expectations

… and those are just some examples. But you get the idea – the more accurate the software project estimations, the
better the chances of successfully finishing the project. So, as a recommendation, the error margin should be
anywhere in the range of 5 to 10 percent.

We’ve seen the effects of poor project estimates, but what about the benefits of estimation?

 They are usually a pre-requisite, so they must be done anyway

 They provide a common language and a bridge between the team and the organization the project is for.
 Estimates provide alignment across the project team, providing transparency and validating or
questioning assumptions.

So what do you need to estimate a software project? Here is a list of inputs that you will need to be able to create a
meaningful result:

1. Scope of work

a. User requirements – this is needed to understand the system’s complexity.

b. Non-functional requirements – an app that must remain available at all times will be built differently than
an app that will only be used during office hours.
c. External factors – summarized as PESTLE (Political, Economic, Social, Technological,
Legal, Environmental).

21
 2. Project risks

A risk is something that has the potential to happen and, if it materializes, will cause a measurable impact on the
project. Each risk can be prevented, reduced, accepted, or transferred.

3. Tech stack

a. Is there a requirement to write something of a legacy nature?

b. Are any items from the tech stack going to end of life during the project?
c. Is the tech stack aligned with the present competencies in the organization?

3. What are the types of estimation?

No matter the type of development estimation, there are a couple of questions that any software project manager
should ask that aim at the most critical six constraints before starting the software project estimation process, such
as:

 Scope of the project – How much work is to be estimated?

 Estimation technique – How to estimate the project?
 Schedule – How much time will it take to finish the project?
 Resources – Who will be working on the project?
 Cost – What is the required budget?
 Risks – What blocking points might appear?

Estimating software projects should have three major parts at the center: effort, cost, and resource predictions. There
is more than one estimation technique. However, during the early stages of a project life cycle, when the product
requirements are still fuzzy, and there isn’t much data to base the project estimation on, an initial estimate is
made, all known as a “ballpark estimate.” Let’s see what types of estimation techniques you can use:

1. Parametric estimation

This type of estimation uses independent measurable variables from the actual project work. For instance, the effort
needed to build a work packet will be calculated using the variable representing the lines of code in the project.
The parametric model gives more accuracy to the estimation since it uses more of a statistical or mathematical
approach.

 Step 1 – establish the factors of development (business or functional requirements, non-functional

requirements, project complexity, tech stack, etc.)
 Step 2 – obtain information about the required work to complete one unit from similar projects
completed in the past.
 Step 3 – the cost is predicted by using an empirical relationship between the factors from step 1 and
the total units from the project.

2. Topdown estimation
22
This method is more beneficial for initial estimations. The project’s scope is reviewed at a high level and divided into
features or estimated deliverables. However, this doesn’t include breaking down the project scope into smaller
pieces of work.

Mainly used for projects in the initial stages, where there isn’t much information available. Less time-consuming than
the bottom-up method, but it provides high-level estimations.

3. Bottomup estimation

This estimation model is useful when the requirements are known at a discrete level, where the smaller work pieces
are aggregated into the whole project. As the name implies, this is the reverse method of topdown estimation.

The scope of the project needs to be described at a low level with all the details, and those components of work are
estimated. The work breakdown structure can be used to present the detailed project scope.

The bottomup estimation is usually precise; however, it might not provide a buffer in case of scope changes.
Therefore, it is recommended to use this type of estimation technique for more mature projects; it’s more time-
consuming but provides a more precise estimation.

4. Threepoint estimating

This one uses a mathematical approach, the result being a weighted average or an optimistic, most likely, and
pessimistic estimation of the work package. This is also known as Program Evaluation and Review Technique, or
PERT.

Three ranges of estimates from three different data points are provided. Those three data points are “best scenario,”
“worst scenario,” and “most likely scenario.” The pessimistic estimation considers negative risks that
can happen, while the optimistic analysis includes positive risks. The final result is the weighted average of the
estimates.

5. Planning poker

Mostly used in agile software development, the planning poker estimation approach is used to estimate project
backlog. The name comes from the fact that the team uses cards while estimating.

Team members estimate all items in the backlog using cards; after the product owner describes the items, each team
member thinks about the estimation and prepares the card. Simultaneously, everyone shows their cards, and the
session ends when the team reaches a consensus.

Agile estimations are also used to estimate story points, even for virtual teams. This estimation technique’s apparent
benefit is that all team members think about the estimation simultaneously. This way, nobody is being influenced.

6. Expert judgment

As the name suggests, this method involves experts in the project estimation process since they have experience

23
 with similar projects and can provide more accurate cost estimates. Additionally, experts will be integrating risk
into their calculations.

4. What are the four basic steps in software project estimation?

Generally, there are four basic steps in software project estimation:

1. Estimating the project size

This will usually end up either in Lines of Code (LOC) or Function Points (FP). The sources of information for this
step should start with formal descriptions of the requirements. This step can be completed either by analogy or by
counting product features and using an algorithmic approach to convert the count into an estimate of size.

2. Estimating the effort in person-months or person-hours

You can convert the software project size estimation to the total project effort only if you have a
defined software development life cycle and a development process that you must follow. This effort estimation
requires you to identify and predict all the necessary activities to build the product. You can do this either by
using historical data or with an algorithmic approach, such as the COCOMO model or the Putnam Methodology.

3. Estimate the schedule in calendar months

This can be determined by using the effort estimate. It involves predicting the number of people working on the project,
what they will work on, when they will start working on it, and when they will finish. Again, like before, historical
data help lay this information out in a calendar format.

4. Estimate the project cost

There are a lot of factors that can influence the cost estimate. For example, to determine the labor cost, the easiest
method is multiplying the project’s effort estimate in hours by a general labor rate. However, you can get a more
accurate estimate by using specific labor rates for each staff position in your team.

4. Develop a decision-making framework for evaluating whether to make or buy a software solution,
considering factors like cost, time, and expertise.

The Make/Buy Decision

Introduction

Are you outsourcing enough? This was one of the main questions asked by management consultants during the
outsourcing boom. Outsourcing was viewed as one of the best ways of getting things done for a fraction of the
original cost.

24
Outsourcing is closely related to make or buy decision. The corporations made decisions on what to make internally
and what to buy from outside in order to maximize the profit margins.

As a result of this, the organizational functions were divided into segments and some of those functions were
outsourced to expert companies, who can do the same job for much less cost.

Make or buy decision is always a valid concept in business. No organization should attempt to make something by their
own, when they stand the opportunity to buy the same for much less price.

This is why most of the electronic items manufactured and software systems developed in the Asia, on behalf of the
organizations in the USA and Europe.

25
 Four Numbers You Should Know

When you are supposed to make a make-or-buy decision, there are four numbers you need to be aware of. Your
decision will be based on the values of these four numbers. Let's have a look at the numbers now. They are
quite self-explanatory.

 The volume
 The fixed cost of making
 Per-unit direct cost when making
 Per-unit cost when buying

Now, there are two formulas that use the above numbers. They are 'Cost to Buy' and 'Cost to Make'. The higher
value loses and the decision maker can go ahead with the less costly solution.

Cost to Buy (CTB) = Volume x Per-unit cost when buying

Cost to Make (CTM) = Fixed costs + (Per-unit direct cost x volume)

Reasons for Making

There are number of reasons a company would consider when it comes to making in-house. Following are a few:

 Cost concerns
 Desire to expand the manufacturing focus
 Need of direct control over the product
 Intellectual property concerns
 Quality control concerns
 Supplier unreliability
 Lack of competent suppliers
 Volume too small to get a supplier attracted
 Reduction of logistic costs (shipping etc.)
 To maintain a backup source
 Political and environment reasons
 Organizational pride

Reasons for Buying

Following are some of the reasons companies may consider when it comes to buying from a supplier:

 Lack of technical experience

 Supplier's expertise on the technical areas and the domain
 Cost considerations
 Need of small volume
 Insufficient capacity to produce in-house
 Brand preferences
 Strategic partnerships

26
 The Process

The make or buy decision can be in many scales. If the decision is small in nature and has less impact on the business,
then even one person can make the decision. The person can consider the pros and cons between making and
buying and finally arrive at a decision.

When it comes to larger and high impact decisions, usually organizations follow a standard method to arrive at a
decision. This method can be divided into four main stages as below.

1. Preparation
 Team creation and appointment of the team leader
 Identifying the product requirements and analysis
 Team briefing and aspect/area destitution

2. Data Collection
 Collecting information on various aspects of make-or-buy decision
 Workshops on weightings, ratings, and cost for both make-or-buy

3. Data Analysis
 Analysis of data gathered

4. Feedback
 Feedback on the decision made

By following the above structured process, the organization can make an informed decision on make-or-buy. Although
this is a standard process for making the make-or-buy decision, the organizations can have their own varieties.

27
 Conclusion

Make-or-buy decision is one of the key techniques for management practice. Due to the global outsourcing, make-
or-buy decision making has become popular and frequent.

Since the manufacturing and services industries have been diversified across the globe, there are a number of
suppliers offering products and services for a fraction of the original price. This has enhanced the global product
and service markets by giving the consumer the eventual advantage.

If you make a make-or-buy decision that can create a high impact, always use a process for doing that. When such
a process is followed, the activities are transparent and the decisions are made for the best interest of the company.

UNIT-3
1. Analyze the core design concepts in software engineering and explain
how they contribute to creating a scalable and maintainable system.
3.1 The Design Concepts

Software Design is the process of transforming user requirements into a suitable form, which helps the
programmer in software coding and implementation. During the software design phase, the design document is
produced, based on the customer requirements as documented in the SRS document. Hence, this phase aims to
transform the SRS document into a design document.
The following items are designed and documented during the design phase:
1. Different modules are required.
2. Control relationships among modules.
3. Interface among different modules.
4. Data structure among the different modules.
5. Algorithms are required to be implemented among the individual modules.

Objectives of Software Design

1. Correctness: A good design should be correct i.e., it should correctly implement all the functionalities of
the system.
2. Efficiency: A good software design should address the resources, time, and cost optimization issues.
3. Flexibility: A good software design should have the ability to adapt and accommodate changes easily. It
includes designing the software in a way, that allows for modifications, enhancements, and scalability
without requiring significant rework or causing major disruptions to the existing functionality.
4. Understandability: A good design should be easily understandable, it should be modular, and all the
modules are arranged in layers.
5. Completeness: The design should have all the components like data structures, modules, external interfaces,
etc.
6. Maintainability: A good software design aims to create a system that is easy to understand, modify, and
maintain over time. This involves using modular and well-structured design principles e.g.,(employing

28
 appropriate naming conventions and providing clear documentation). Maintainability in Software and design also
enables developers to fix bugs, enhance features, and adapt the software to changing requirements without
excessive effort or introducing new issues.

Software Design Concepts

Concepts are defined as a principal idea or invention that comes into our mind or in thought to understand something.
The software design concept simply means the idea or principle behind the design. It describes how you plan to
solve the problem of designing software, and the logic, or thinking behind how you will design software. It allows
the software engineer to create the model of the system software or product that is to be developed or built. The
software design concept provides a supporting and essential structure or model for developing the right software.
There are many concepts of software design and some of them are given below:

Software Design Concepts

Points to be Considered While Designing Software

1. Abstraction (Hide Irrelevant data): Abstraction simply means to hide the details to reduce complexity and
increase efficiency or quality. Different levels of Abstraction are necessary and must be applied at each stage
of the design process so that any error that is present can be removed to increase the efficiency of the
software solution and to refine the software solution. The solution should be described in broad ways that
cover a wide range of different things at a higher level of abstraction and a more detailed description of a
solution of software should be given at the lower level of abstraction.
2. Modularity (subdivide the system): Modularity simply means dividing the system or project into smaller
parts to reduce the complexity of the system or project. In the same way, modularity in design means
subdividing a system into smaller parts so that these parts can be created independently and then use these
parts in different systems to perform different functions. It is necessary to divide the software into
components known as modules because nowadays, there are different software available like Monolithic
software that is hard to grasp for software engineers. So, modularity in design has now become a trend and is
also important. If the system contains fewer components then it would mean the system is complex which
requires a lot of effort (cost) but if we can divide the system into components then the cost would be small.

29
 3. Architecture (design a structure of something): Architecture simply means a technique to design a
structure of something. Architecture in designing software is a concept that focuses on various elements and
the data of the structure. These components interact with each other and use the data of the structure in
architecture.
4. Refinement (removes impurities): Refinement simply means to refine something to remove any impurities
if present and increase the quality. The refinement concept of software design is a process of developing or
presenting the software or system in a detailed manner which means elaborating a system or software.
Refinement is very necessary to find out any error if present and then to reduce it.
5. Pattern (a Repeated form): A pattern simply means a repeated form or design in which the same shape is
repeated several times to form a pattern. The pattern in the design process means the repetition of a solution
to a common recurring problem within a certain context.
6. Information Hiding (Hide the Information): Information hiding simply means to hide the information so
that it cannot be accessed by an unwanted party. In software design, information hiding is achieved by
designing the modules in a manner that the information gathered or contained in one module is hidden and
can’t be accessed by any other modules.
7. Refactoring (Reconstruct something): Refactoring simply means reconstructing something in such a way
that it does not affect the behavior of any other features. Refactoring in software design means
reconstructing the design to reduce complexity and simplify it without impacting the behavior or its
functions. Fowler has defined refactoring as “the process of changing a software system in a way that it
won’t impact the behavior of the design and improves the internal structure”.

nference the key factors that contribute to an effective user interface design, and
explain how they enhance user experience and accessibility.

3.2 User Interface Design: Interface Analysis – Interface Design Steps

The user interface is the front-end application view to which the user interacts to use the software. The software
becomes more popular if its user interface is:
1. Attractive
2. Simple to use
3. Responsive in a short time
4. Clear to understand
5. Consistent on all interface screens

Types of User Interface

1. Command Line Interface: The Command Line Interface provides a command prompt, where the user types
the command and feeds it to the system. The user needs to remember the syntax of the command and its use.
2. Graphical User Interface: Graphical User Interface provides a simple interactive interface to interact with
the system. GUI can be a combination of both hardware and software. Using GUI, the user interprets the
software.

User Interface Design Process

The analysis and design process of a user interface is iterative and can be represented by a spiral model. The
analysis and design process of user interface consists of four framework activities.

30
 UI Design Stages

1. User, Task, Environmental Analysis, and Modeling

Initially, the focus is based on the profile of users who will interact with the system, i.e., understanding, skill and
knowledge, type of user, etc., based on the user’s profile users are made into categories. From each category
requirements are gathered. Based on the requirement’s developer understand how to develop the interface. Once
all the requirements are gathered a detailed analysis is conducted. In the analysis part, the tasks that the user
performs to establish the goals of the system are identified, described and elaborated. The analysis of the user
environment focuses on the physical work environment. Among the questions to be asked are:
1. Where will the interface be located physically?
2. Will the user be sitting, standing, or performing other tasks unrelated to the interface?
3. Does the interface hardware accommodate space, light, or noise constraints?
4. Are there special human factors considerations driven by environmental factors?

2. Interface Design
The goal of this phase is to define the set of interface objects and actions i.e., control mechanisms that enable the
user to perform desired tasks. Indicate how these control mechanisms affect the system. Specify the action
sequence of tasks and subtasks, also called a user scenario. Indicate the state of the system when the user performs
a particular task. Always follow the three golden rules stated by Theo Mandel. Design issues such as response
time, command and action structure, error handling, and help facilities are considered as the design model is
refined. This phase serves as the foundation for the implementation phase.

3. Interface Construction and Implementation

The implementation activity begins with the creation of a prototype (model) that enables usage scenarios to be
evaluated. As iterative design process continues a User Interface toolkit that allows the creation of windows,
menus, device interaction, error messages, commands, and many other elements of an interactive environment
can be used for completing the construction of an interface.

31
4. Interface Validation
This phase focuses on testing the interface. The interface should be in such a way that it should be able to perform
tasks correctly, and it should be able to handle a variety of tasks. It should achieve all the user’s requirements. It
should be easy to use and easy to learn. Users should accept the interface as a useful one in their work.

User Interface Design Golden Rules

The following are the golden rules stated by Theo Mandel that must be followed during the design of the
interface. Place the user in control:
1. Define the interaction modes in such a way that does not force the user into unnecessary or undesired
actions: The user should be able to easily enter and exit the mode with little or no effort.
2. Provide for flexible interaction: Different people will use different interaction mechanisms, some might
use keyboard commands, some might use mouse, some might use touch screen, etc., Hence all interaction
mechanisms should be provided.
3. Allow user interaction to be interruptible and undoable: When a user is doing a sequence of actions the
user must be able to interrupt the sequence to do some other work without losing the work that had been
done. The user should also be able to do undo operation.
4. Streamline interaction as skill level advances and allow the interaction to be customized: Advanced or
highly skilled user should be provided a chance to customize the interface as user wants which allows
different interaction mechanisms so that user doesn’t feel bored while using the same interaction
mechanism.
5. Hide technical internals from casual users: The user should not be aware of the internal technical details
of the system. He should interact with the interface just to do his work.
6. Design for direct interaction with objects that appear on-screen: The user should be able to use the
objects and manipulate the objects that are present on the screen to perform a necessary task. By this, the
user feels easy to control over the screen.

32