Software engineering (by Arun and Shalini)

Unit-1
INTRODUCTION:

SOFTWARE-
Software is a set of instructions that are written in a programming language and
executed on a computer or other electronic device. It is a collection of programs,
data, and instructions that tell a computer or other electronic device what to do.

Software can be broadly categorized into two main types: system software and
application software.

1.​ System software: This type of software is responsible for managing and controlling
the hardware and other system resources of a computer or other electronic device.
Examples of system software include operating systems, device drivers, firmware,
and utility programs.
2.​ Application software: This type of software is designed to perform specific tasks or
functions for end-users. Examples of application software include word processors,
spreadsheet programs, web browsers, video editing software, and gaming
applications.

Goals:

1.​ Meeting user needs: The primary goal of software development is to create software
that meets the needs of the users.
2.​ Quality: Software should be reliable, efficient, maintainable, and scalable.
3.​ Timeliness: Software should be delivered on time, meeting the project's schedule.
4.​ Cost-effectiveness: Software development should be cost-effective and efficient.
5.​ Security: Software should be designed to be secure and protect sensitive data.

Principles:

1.​ Agile development: This methodology values iterative development, collaboration,

and flexibility to adapt to changing requirements.
2.​ Test-driven development: This approach involves writing tests before writing the
code to ensure the code meets the requirements.
3.​ Continuous integration and deployment: This principle involves regularly integrating
and deploying code changes to ensure they are functioning correctly and meet
requirements.
4.​ Separation of concerns: This principle involves dividing the software into distinct
components or modules to reduce complexity and improve maintainability.
5.​ Open source development: This approach values community collaboration,
transparency, and the sharing of knowledge and code.
Software crisis-Software crisis is a term used in the early days of computing
science for the difficulty of writing useful and efficient computer programs in the
required time. The software crisis was due to the rapid increases in computer power.
If we will use the same workforce, same methods, and same tools after the fast
increase in software demand, software complexity, and software challenges, then
there arise some problems like software budget problems, software efficiency
problems, software quality problems, software managing and delivering problem, etc.
This condition is called a software crisis.

Factors contributing to the software crisis.

●​ Poor project management.
●​ Lack of adequate training in software engineering.
●​ Less skilled project members.
●​ Low productivity improvements.

Solution of Software Crisis:

There is no single solution to the crisis. One possible solution to a software crisis
is Software Engineering because software engineering is a systematic, disciplined
approach. For preventing software crises, there are some guidelines:
●​ Reduction in software over budget.
●​ The quality of software must be high.
●​ Less time is needed for a software project.
●​ Experienced and skilled people working over the software project.
●​ Software must be delivered.
●​ Software must meet user requirements.

SOFTWARE PROCESS-A software process refers to a set of activities and

tasks that are involved in the creation of software. It involves a systematic approach
to software development that helps to ensure the quality and reliability of the
software produced. The software process includes various phases such as planning,
analysis, design, implementation, testing, deployment, and maintenance.

The software process is typically represented in the form of a software development

life cycle (SDLC), which is a framework that describes the stages involved in
developing software. The SDLC typically consists of the following phases:
1.​ Planning: In this phase, the requirements for the software are gathered, and a plan
is developed for how the software will be developed.
2.​ Analysis: In this phase, the requirements gathered in the planning phase are
analysed to determine the feasibility of the project.
3.​ Design: In this phase, the software is designed based on the requirements gathered
in the previous phases. This includes both high-level and low-level design.
4.​ Implementation: In this phase, the software is coded and developed based on the
design specifications.
5.​ Testing: In this phase, the software is tested to ensure that it meets the
requirements and specifications.
6.​ Deployment: In this phase, the software is deployed and made available to
end-users.
7.​ Maintenance: In this phase, the software is maintained and updated as necessary to
ensure that it remains functional and meets the changing needs of end-users.

EVOLUTION OF SOFTWARE ENGINEERING- Software Evolution is a

term which refers to the process of developing software initially, then timely updating
it for various reasons. The cost and impact of these changes are accessed to see
how much system is affected by the change and how much it might cost to
implement the change. If the proposed changes are accepted, a new release of the
software system is planned. During release planning, all the proposed changes (fault
repair, adaptation, and new functionality) are considered. A design is then made on
which changes to implement in the next version of the system.
The necessity of Software evolution:
a) Change in requirement with time: With the passes of time, the organization’s
needs and modus Operandi of working could substantially be changed so in this
frequently changing time the tools (software) that they are using need to change for
maximizing the performance.
b) Environment change: As the working environment changes the things(tools) that
enable us to work in that environment also changes proportionally same happens in
the software world as the working environment changes then, the organizations need
reintroduction of old software with updated features and functionality to adapt the
new environment.
c) Errors and bugs: As the age of the deployed software within an organization
increases their preciseness or impeccability decrease and the efficiency to bear the
increasing complexity workload also continually degrades. So, in that case, it
becomes necessary to avoid use of obsolete and aged software. All such obsolete
Softwares need to undergo the evolution process in order to become robust as per
the workload complexity of the current environment.
d) Security risks: Using outdated software within an organization may lead you to at
the verge of various software-based cyberattacks and could expose your confidential
data illegally associated with the software that is in use. So, it becomes necessary to
avoid such security breaches through regular assessment of the security
patches/modules are used within the software. If the software isn’t robust enough to
bear the current occurring Cyber-attacks so it must be changed (updated).
e) For having new functionality and features: In order to increase the
performance and fast data processing and other functionalities, an organization need
to continuously evolute the software throughout its life cycle so that stakeholders &
clients of the product could work efficiently.
 Laws used for Software Evolution:
1.​ Law of continuing change: ​
This law states that any software system that represents some real-world reality
undergoes continuous change or become progressively less useful in that
environment.
2.​ Law of increasing complexity: ​
As an evolving program changes, its structure becomes more complex unless
effective efforts are made to avoid this phenomenon.
3.​ Law of conservation of organization stability: ​
Over the lifetime of a program, the rate of development of that program is
approximately constant and independent of the resource devoted to system
development.
4.​ Law of conservation of familiarity: ​
This law states that during the active lifetime of the program, changes made in
the successive release are almost constant.

Here are some of the key milestones and changes in the evolution of software
engineering:

1.​ Early development (1940s-1950s): The earliest software was developed for specific
applications, such as scientific calculations and military uses.
2.​ Structured programming (1960s-1970s): Structured programming emerged as a way
to make software development more organized and efficient.
3.​ Object-oriented programming (1980s-1990s): Object-oriented programming
introduced the concept of objects and classes.
4.​ Agile development (2000s-present): Agile development methodologies, such as
Scrum and Extreme Programming, emerged as a way to make software
development more flexible.
5.​ DevOps (2010s-present): DevOps emerged as a way to improve collaboration
between development and operations teams.
6.​ Cloud computing (2010s-present): Cloud computing has transformed the way
software is deployed and maintained, with many applications now hosted in the
cloud and accessed via the internet.
7.​ Artificial intelligence and machine learning (2010s-present)
Software characteristics: Characteristics of Software are classified into six
major components:

●​ Functionality: It refers to the suitability, accuracy, interoperability,

compliance, security of software which is measured as degree of performance
of the software against its intended purpose.

●​ Reliability: Refers to the recoverability, fault tolerance, maturity of software,

which is basically a capability of the software that provide
required functionality under the given situations.

●​ Efficiency: It is the ability of the software to use resources of system in the

most effective and efficient manner. Software must make effective use of
system storage and execute command as per required timing.

●​ Usability: It is the extent to which the software can be utilized with ease and
the amount of effort or time required to learn how to use the software.
 ●​ Maintainability: It is the ease with which the modifications can be made in a
software to extend or enhance its functionality, improve its performance, or
resolve bugs.

●​ Portability: It is the ease with which software developers can relaunch

software from one platform to another, without (or with minimum) changes. In
simple terms, software must be made in way that it should be platform
independent.

Software metrics- Software metrics are quantitative measures used to evaluate

and improve the quality of software during the development process. These metrics
help software developers and project managers to monitor and assess software
quality, identify areas for improvement, and make data-driven decisions.

Classification of Software Metrics:

There are 3 types of software metrics:

1.​ Product Metrics: Product metrics are used to evaluate the state of the product,
tracing risks and undercover prospective problem areas. The ability of the team
to control quality is evaluated.
2.​ Process Metrics: Process metrics pay particular attention to enhancing the
long-term process of the team or organization.
3.​ Project Metrics: The project matrix describes the project characteristic and
execution process.

Advantages of Software Metrics:

1.​ Reduction in cost or budget.

2.​ It helps to identify the particular area for improvising.
 3.​ It helps to increase the product quality.
4.​ Managing the workloads and teams.
5.​ Reduction in overall time to produce the product,
6.​ It helps to determine the complexity of the code and to test the code with
resources.
7.​ It helps in providing effective planning, controlling and managing of the entire
product.

Disadvantages of Software Metrics:

1.​ It is expensive and difficult to implement the metrics in some cases.

2.​ Performance of the entire team or an individual from the team can’t be
determined. Only the performance of the product is determined.
3.​ Sometimes the quality of the product is not met with the expectation.
4.​ It leads to measure the unwanted data which is wastage of time.
5.​ Measuring the incorrect data leads to make wrong decision making.

SOFTWARE LIFECYCLE MODEL- provide a structured approach to software

development that can help ensure that software projects are completed on time,
within budget, and to the required quality standards. The choice of the most
appropriate model will depend on the specific requirements of the software project,
the level of risk involved, and the available resources.

WATERFALL MODEL- the Waterfall Model was the first Process Model to be
introduced. It is also referred to as a linear-sequential life cycle model. The
Waterfall model is the earliest SDLC approach that was used for software
development.
The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process begins only
if the previous phase is complete. In this waterfall model, the phases do not overlap.
Waterfall Model - Design In "The Waterfall" approach, the whole process of
software development is divided into separate phases. In this Waterfall model,
typically, the outcome of one phase acts as the input for the next phase sequentially.

1.​ Requirements gathering and analysis: In this phase, the requirements for the
software project are defined and documented.
2.​ Design: In this phase, the system architecture and the software design are
developed based on the requirements.
3.​ Implementation: In this phase, the software is developed based on the design
specifications.
4.​ Testing: In this phase, the software is tested to ensure that it meets the
requirements and is free from bugs and errors.
5.​ Deployment: In this phase, the software is released and deployed to the users.
6.​ Maintenance: In this phase, the software is maintained and updated as needed.
Advantages of the waterfall model:

1.​ Clear and well-defined development process: The waterfall model provides a
clear and well-defined development process, making it easy for developers to
understand what needs to be done at each stage.
2.​ Easy to manage: The linear nature of the waterfall model makes it easy to manage
and track progress. Project managers can easily determine which stage of
development is complete and which stage is next.
3.​ Easy to estimate project timelines: Because the requirements and scope of the
project are well-defined at the beginning of the development process, it is easy to
estimate project timelines and costs.
4.​ Good documentation: The waterfall model requires documentation at each stage of
the development process, which can be useful for future reference and maintenance.

Disadvantages of the waterfall model:

1.​ Not flexible: The waterfall model is not well-suited for projects with changing or
unclear requirements. Once a stage is complete, it is difficult to go back and make
changes.
2.​ High risk: The waterfall model is a high-risk approach, as any issues or problems
that arise in the later stages of development may require significant changes to
previous stages, which can be costly and time-consuming.
3.​ Long development time: The waterfall model can be a slow and time-consuming
process, as each stage must be completed before moving on to the next.
4.​ Customer involvement is limited: The customer's involvement in the development
process is limited, as the requirements are defined at the beginning of the process
and changes are difficult to accommodate. This can lead to a product that does not
fully meet the customer's needs
APPLICATIONS-
Some Circumstances where the use of the Waterfall model is most suited are:
o​ When the requirements are constant and not changed regularly.
o​ A project is short
o​ The situation is calm
o​ Where the tools and technology used is consistent and is not changing
o​ When resources are well prepared and are available to use.

ADVANCE WATER FALLMODEL-

 o​ The Advanced Waterfall Model is an extension of the Waterfall model that
includes more feedback loops and allows for more flexibility in the
development process. This means that feedback is gathered throughout the
development process and used to make improvements to the software. This
makes the Advanced Waterfall Model more suitable for projects with changing
requirements or where there is a need for continuous improvement.

o​ Another difference between the Waterfall model and the Advanced Waterfall
Model is that the Advanced Waterfall Model includes additional stages, such
as the feedback and maintenance stages, that are not present in the
traditional Waterfall model.

SPIRAL MODEL- the Spiral Model is a software development model that

combines elements of both iterative and waterfall development models. It was
proposed by Barry Boehm in 1986 and is widely used in software development
projects, particularly in large-scale, complex projects.

The Spiral Model involves a series of iterations that follow a spiral pattern, with each
iteration consisting of four stages:

1.​ Planning: The project's goals and objectives are defined in the planning stage. Risks
are identified, and the project is evaluated in terms of cost, schedule, and feasibility.
2.​ Risk analysis: In this stage, potential risks are identified, and strategies are
developed to mitigate or manage them.
3.​ Engineering: This stage involves the actual development and testing of the
software. It includes requirements gathering, design, coding, testing, and integration.
4.​ Evaluation: At the end of each iteration, the software is evaluated to ensure that it
meets the project's goals and objectives.

Advantages of the Spiral Model:

1.​ Risk management: The Spiral Model emphasizes risk management, which helps to
identify and mitigate risks early in the project, reducing the likelihood of delays or
failures.
2.​ Flexibility: The Spiral Model is more flexible than the Waterfall Model, allowing for
changes and adjustments to be made throughout the development process.
3.​ Incremental development: The Spiral Model supports incremental development,
allowing for the delivery of working software at the end of each iteration.
4.​ Early feedback: The Spiral Model provides opportunities for early feedback from
stakeholders, enabling adjustments to be made before the software is complete.

Disadvantages of the Spiral Model:

1.​ Complexity: The Spiral Model can be more complex than other development
models, requiring more resources and expertise.
2.​ Cost: The Spiral Model can be more expensive than other development models,
particularly if multiple iterations are required.
3.​ Time-consuming: The Spiral Model can be time-consuming, with each iteration
requiring significant planning and analysis.
4.​ Not suitable for small projects: The Spiral Model is not suitable for small projects

or projects with limited resources.

INCREMENTAL MODEL- the Incremental Model is a software development

model that involves breaking a large project into smaller, more manageable parts.
Each part is developed and delivered in increments, with each increment adding
additional functionality to the software until the project is complete.

The Incremental Model involves the following stages:

1.​ Requirements gathering: The project requirements are identified, and the software
functionality is broken down into smaller parts.
2.​ Design: Each increment is designed, with the overall architecture of the software
taken into consideration.
3.​ Implementation: Each increment is developed and tested, with the focus on
delivering working software at the end of each increment.
4.​ Testing: The software is tested after each increment, with the focus on ensuring that
the software is functioning as intended.
5.​ Deployment: The software is deployed after all increments have been completed
and tested.

Advantages of the Incremental Model:

1.​ Early feedback: The Incremental Model provides opportunities for early feedback
from stakeholders, enabling adjustments to be made before the software is
complete.
2.​ Reduced risk: The Incremental Model reduces risk by delivering working software at
the end of each increment, allowing for early identification and mitigation of issues.
3.​ Flexibility: The Incremental Model is flexible, allowing for changes and adjustments
to be made throughout the development process.
4.​ Faster time to market: The Incremental Model enables faster time to market by
delivering working software at the end of each increment.

Disadvantages of the Incremental Model:

1.​ Complexity: The Incremental Model can be more complex than other development
models, requiring more resources and expertise.
2.​ Coordination: The Incremental Model requires careful coordination and planning to
ensure that each increment is developed and delivered on time and within budget.
3.​ Dependencies: The Incremental Model can create dependencies between
increments, which can make it difficult to make changes or adjustments later in the
development process.
4.​ Testing: Testing each increment can be time-consuming and may require significant
resources.

Evolutionary model is a combination of Iterative and Incremental model of

software development life cycle. Delivering your system in a big bang release,
delivering it in incremental process over time is the action done in this model. Some
initial requirements and architecture envisioning need to be done. It is better for
software products that have their feature sets redefined during development because
of user feedback and other factors. The Evolutionary development model divides the
development cycle into smaller, incremental waterfall models in which users are able
to get access to the product at the end of each cycle. Feedback is provided by the
users on the product for the planning stage of the next cycle and the development
team responds, often by changing the product, plan or process. Therefore, the
software product evolves with time. All the models have the disadvantage that the
duration of time from start of the project to the delivery time of a solution is very high.
Evolutionary model solves this problem in a different approach. ​

​
Evolutionary model suggests breaking down of work into smaller chunks, prioritizing
them and then delivering those chunks to the customer one by one. The number of
chunks is huge and is the number of deliveries made to the customer. The main
advantage is that the customer’s confidence increases as he constantly gets
quantifiable goods or services from the beginning of the project to verify and validate
his requirements. The model allows for changing requirements as well as all work in
broken down into maintainable work chunks. Application of Evolutionary Model:
1.​ It is used in large projects where you can easily find modules for incremental
implementation. Evolutionary model is commonly used when the customer wants
to start using the core features instead of waiting for the full software.
 2.​ Evolutionary model is also used in object oriented software development because
the system can be easily portioned into units in terms of objects.
Necessary conditions for implementing this model:-
●​ Customer needs are clear and been explained in deep to the developer team.
●​ There might be small changes required in separate parts but not a major change.
●​ As it requires time, so there must be some time left for the market constraints.
●​ Risk is high and continuous targets to achieve and report to customer repeatedly.
●​ It is used when working on a technology is new and requires time to learn.
Advantages:
●​ In evolutionary model, a user gets a chance to experiment partially developed
system.
●​ It reduces the error because the core modules get tested thoroughly.
Disadvantages:
●​ Sometimes it is hard to divide the problem into several versions that would be
acceptable to the customer which can be incrementally implemented and
delivered.

UNIFIED PROCESS- the Unified Process (UP) is a software development

framework that is based on the Object-Oriented Analysis and Design (OOAD)
methodology. The UP is an iterative and incremental process that focuses on
delivering working software early in the development process. The UP is also known
as the Unified Software Development Process (USDP).

The UP involves the following phases:

1.​ Inception: The project is initiated, and the requirements are identified. The feasibility
of the project is assessed, and a rough plan for the project is developed.
2.​ Elaboration: The requirements are refined, and a more detailed plan for the project
is developed. The architecture of the software is designed, and a prototype is
developed to demonstrate the key features of the software.
3.​ Construction: The software is developed through a series of iterations, with each
iteration building on the previous one. The focus is on developing and delivering
working software.
4.​ Transition: The software is deployed, and any issues are addressed. The focus is
on ensuring that the software meets the needs of the stakeholders.

The UP is based on a set of principles, including:

1.​ Use-case driven: The development process is driven by the needs of the
stakeholders, which are expressed in the form of use cases.
2.​ Architecture-centric: The architecture of the software is designed early in the
development process, and the development process is focused on implementing the
architecture.
3.​ Iterative and incremental: The software is developed through a series of iterations,
with each iteration building on the previous one.
4.​ Risk-focused: The development process is focused on identifying and mitigating
risks throughout the development process.
 Advantages of the Unified Process:

1.​ Flexibility: The UP is flexible and can be tailored to meet the needs of the project.
2.​ Risk management: The UP includes a focus on risk management, which can help
to reduce the risk of project failure.
3.​ Early delivery: The UP focuses on delivering working software early in the
development process, which can provide early value to the stakeholders.
4.​ Collaboration: The UP promotes collaboration between stakeholders, which can
lead to better communication and a better understanding of the project goals.

Disadvantages of the Unified Process:

1.​ Complexity: The UP can be more complex than other development frameworks,
requiring more resources and expertise.
2.​ Documentation: The UP requires a significant amount of documentation, which can
be time-consuming.
3.​ Cost: The UP can be more expensive than other development frameworks, due to
the resources required for documentation and the iterative development process.

SELECTION OF LIFE CYCLE MODEL

The selection of a life cycle model for a software development project depends on a
number of factors, including the project requirements, the size and complexity of the
project, the budget and resources available, the development team's experience,
and the customer's expectations.

Here are some general guidelines for selecting a life cycle model:

1.​ Waterfall model: The waterfall model is best suited for projects with well-defined and
stable requirements, where the final product is expected to be delivered in a single
release. This model is less suitable for complex projects where requirements are
likely to change during the development process.
2.​ Iterative models: Iterative models such as the Incremental model, the Evolutionary
model, or the Unified Process are best suited for projects where the requirements
are not fully understood or are likely to change during the development process.
These models allow for flexibility and can accommodate changes as they arise...
3.​ Spiral model: The Spiral model is best suited for large, complex, and mission-critical
projects where risk management is a top priority. This model allows for risk analysis
and mitigation throughout the development process.
4.​ Prototype model: The Prototype model is best suited for projects where the
requirements are not well understood or are likely to change frequently. This model
allows for rapid prototyping and feedback from the customer, enabling adjustments
to be made before the final product is delivered.
Software requirements
Software requirements refer to the description of what a software system should do
and how it should behave. Requirements help to define the scope of the software
project and provide a basis for the software design and development process.
 There are several types of software requirements, including:

1.​ Functional requirements: These describe the specific features and functions that
the software should perform.
2.​ Non-functional requirements: These describe the quality attributes of the software,
such as usability, performance, security, and reliability.
3.​ User requirements: These describe the needs and expectations of the end-users of
the software.
4.​ Business requirements: These describe the goals and objectives of the software
project and how it aligns with the overall business strategy.
5.​ System requirements: These describe the hardware and software environments in
which the software will run.
6.​ Design requirements: These describe the specific design constraints and
considerations that need to be taken into account during the development process.

The process of defining software requirements typically involves the following steps:

1.​ Requirements gathering: This involves gathering information about the user needs
and system requirements through interviews, surveys, and other techniques.
2.​ Requirements analysis: This involves analyzing the requirements to ensure that
they are complete, consistent, and feasible.
3.​ Requirements specification: This involves documenting the requirements in a clear
and concise manner, using a variety of techniques such as use cases, user stories,
and requirement documents.
4.​ Requirements validation: This involves reviewing and testing the requirements to
ensure that they are accurate, complete, and meet the needs of the users.

Analysis specification
Analysis specification is the process of creating a detailed description of the
functional and non-functional requirements for a software system. It involves
breaking down the requirements into smaller, more manageable components that
can be more easily understood and implemented by software developers.

The process of analysis specification typically involves the following steps:

1.​ Requirements gathering: This involves identifying the needs and goals of the
software system, and documenting them in a clear and concise manner.
2.​ Requirements analysis: This involves reviewing and refining the requirements to
ensure that they are complete, consistent, and feasible. During this step, the analyst
may use various techniques such as data flow diagrams, use cases, and business
process models to help define the requirements.
3.​ Requirements specification: This involves documenting the requirements in a
detailed and precise manner, using a variety of techniques such as functional and
non-functional specifications, data models, and user interface mockups.
4.​ Requirements validation: This involves reviewing and testing the requirements to
ensure that they are accurate, complete, and meet the needs of the users and
stakeholders.
 REQUIREMENT ENGINEERING
Requirement engineering is the process of eliciting, analyzing, documenting,
validating, and managing the requirements for a software system. It involves
identifying the needs and goals of the system, and defining the features and
functions that are required to meet those needs.

The process of requirement engineering typically involves the following steps:

1.​ Requirements elicitation: This involves identifying the stakeholders and

understanding their needs, goals, and expectations for the software system. This
step may involve conducting interviews, surveys, and workshops with the
stakeholders to gather their requirements.
2.​ Requirements analysis: This involves reviewing and refining the requirements to
ensure that they are complete, consistent, and feasible. During this step, the analyst
may use various techniques such as use cases, data flow diagrams, and business
process models to help define the requirements.
3.​ Requirements documentation: This involves documenting the requirements in a
clear and concise manner, using a variety of techniques such as use cases, user
stories, and requirement documents.
4.​ Requirements validation: This involves reviewing and testing the requirements to
ensure that they are accurate, complete, and meet the needs of the users and
stakeholders.
5.​ Requirements management: This involves tracking and maintaining the
requirements throughout the software development lifecycle, and ensuring that
changes to the requirements are properly managed and communicated to all
stakeholders.

DATA FLOW DIAGRAM

A data flow diagram (DFD) is a graphical representation of the flow of data through a
system. It is a visual tool that helps to describe the data inputs, outputs, and
processes of a system. DFDs are commonly used in software engineering and
business analysis to model the flow of data within an organization or system.

A data flow diagram consists of the following components:

1.​ Data sources: These are the sources of data that enter the system, such as
customers, suppliers, or other systems.
2.​ Data stores: These are the locations where data is stored within the system, such as
a database or file.
3.​ Processes: These are the activities that transform the data within the system, such
as calculations, validations, or updates.
4.​ Data flows: These are the arrows that represent the movement of data between the
various components of the system.
 There are four levels of data flow diagrams, each providing a greater level of
detail:

1.​ Level 0: This is the highest level of DFD, which shows the overall system and its
main processes.
2.​ Level 1: This level breaks down the processes into sub-processes and shows the
data flows between them.
3.​ Level 2: This level provides more detail on the sub-processes of level 1 and shows
the data flows within them.
4.​ Level 3: This is the most detailed level of DFD, which shows the specific data flows
and processes within a sub-process.

Data flow diagrams are an effective way to communicate the flow of data within a
system and to identify areas where improvements can be made. They help to
visualize the system and make it easier to understand, analyze, and communicate to
stakeholders.

DATA DICTIONARY- A data dictionary is a structured description of the data

elements, attributes, and relationships that are used within an information system or
database. It serves as a reference document for developers, users, and other
stakeholders who need to understand the structure and meaning of the data in the
system.

A data dictionary typically includes the following information:

1.​ Data element name: The name of the data element or attribute.
2.​ Data element description: A brief description of the data element or attribute,
including its purpose, meaning, and characteristics.
3.​ Data type: The type of data that the element represents, such as text, number, or
date.
4.​ Valid values: The range of values that are allowed for the data element.
5.​ Data source: The origin of the data element, such as a specific table or file.
6.​ Relationship to other data elements: Information on how the data element is
related to other elements in the system, such as through a foreign key relationship.
7.​ Constraints: Any rules or constraints that apply to the data element, such as
maximum length or required fields.
The Notations used within the data dictionary are given in the table below as follows:
 Notations Meaning

X = a+b X consists data elements a and b.

X = [a/b] X consists of either elements a or b.

X=aX X consists of optimal data elements a.

X = y[a] X consists of y or more events of data element a

X = [a] z X consists of z or less events of data element a

X = y [a] X consists of some events of data elements between y and

z z.

Features of Data Dictionary:

Here, we will discuss some features of the data dictionary as follows.

●​ It helps in designing test cases and designing the software.
●​ It is very important for creating an order list from a subset of the items list.
●​ It is very important for creating an order list from a complete items list.
●​ The data dictionary is also important to find the specific data item object from the
list.

ER DIAGRAM-
An entity-relationship diagram (ERD) is a type of data modelling technique used to
represent the entities, attributes, and relationships involved in a system or
organization. ER diagrams are often used in software engineering and database
design to help visualize and organize the data that will be stored in a database.
An ERD consists of several components, including:
1.​ Entities: These are the objects or concepts in the system that are relevant to
the data being modeled. For example, in a university system, entities might
include students, courses, professors, and departments.
2.​ Attributes: These are the characteristics or properties of the entities. For
example, attributes of a student might include name, student ID, major, and
GPA.
TYPES OF ATTRIBUTES:
 1.​ Key attribute: Key is an attribute or collection of attributes that uniquely
identifies an entity among the entity set. For example, the roll_number of a
student makes him identifiable among students.

There are mainly three types of keys:

1.​ Super key: A set of attributes that collectively identifies an entity in the entity
set.
2.​ Candidate key: A minimal super key is known as a candidate key. An entity
set may have more than one candidate key.
3.​ Primary key: A primary key is one of the candidate keys chosen by the
database designer to uniquely identify the entity set.

2. Composite attribute: An attribute that is a combination of other attributes is

called a composite attribute. For example, in student entity, the student address is a
composite attribute as an address is composed of other characteristics such as pin
code, state, country.

3. Single-valued attribute: Single-valued attribute contain a single value. For

example, Social_Security_Number.
4. Multi-valued Attribute: If an attribute can have more than one value, it is known
as a multi-valued attribute. Multi-valued attributes are depicted by the double ellipse.
For example, a person can have more than one phone number, email-address, etc.
5. Derived attribute: Derived attributes are the attribute that does not exist in the
physical database, but their values are derived from other attributes present in the
database. For example, age can be derived from date_of_birth. In the ER diagram,
Derived attributes are depicted by the dashed ellipse.
​

Relationships THIRD COMPONENT: These are the connections between

entities. For example, a student might enroll in one or more courses, and a course
might have one or more professors teaching it. There are three main types of
relationships that can exist between entities:
One-to-one (1:1): A relationship in which one entity is associated with only one
instance of another entity.
One-to-many (1: N): A relationship in which one entity is associated with multiple
instances of another entity.
Many-to-many (N: M): A relationship in which multiple instances of one entity are
associated with multiple instances of another entity.

DECISION TABLE-
A decision table is a tabular representation of the conditions and actions that make
up a decision-making process. It is a structured approach to solving complex
problems or making important decisions based on a set of rules or criteria.

In a decision table, the columns represent the conditions or inputs that are used to
make the decision, and the rows represent the possible combinations of these
conditions. The table also includes the actions or outputs that are taken based on the
combination of conditions.

Each cell in the table represents a specific combination of conditions and actions.
The conditions may be either true or false, and the actions may be either taken or
not taken based on the condition

1. Decision Table: Decision Table is just a tabular representation of all conditions

and actions. Decision Table are always used whenever the processing logic is very
complicated and involves multiple conditions. The main components used for the
formation of the Data Table are Conditions Stubs, Action Stubs, and rules.
Types of decision tables:
●​ Extended entry table
●​ Limited entry table
Benefits:
●​ Visualization of Cause and effect relationships in the table.
●​ Easy to understand
●​ In the case of a complex table, it can be readily broken down into simpler tables.
●​ Tables are formatted consistently.
●​ Suggestions of possible actions need to be taken from the summarized outcomes
of a situation.
●​ In these tables, semi-standardized languages might be used.
●​ Table users are not necessarily know how to use a computer.
Drawbacks:
●​ Decision tables are not well suited to large-scale applications. There is a
requirement of splitting huge tables into smaller ones to eliminate redundancy.
●​ The complete sequence of actions is not reflected in the decision tables.
●​ A partial solution is presented.
2. Decision Tree: A decision tree is a graph that always uses a branching method
in order to demonstrate all the possible outcomes of any decision. Decision Trees
are graphical and show a better representation of decision outcomes. It consists of
three nodes namely Decision Nodes, Chance Nodes, and Terminal Nodes.
Types of the decision tree:
●​ Categorical variable decision tree
●​ Continuous variable decision tree
Benefits:
●​ A decision tree is simple to comprehend and use.
●​ New scenarios are simple to add.
●​ Can be combined with other decision-making methods.
●​ Handling of both numerical and categorial variables
●​ The classification does not require many computations.
●​ Useful in analysing and solving various business problems.
Drawbacks:
●​ They are inherently unstable, which means that a slight change in the data can
have a result in a change in the structure of the optimal decision tree, and they
are frequently wrong.
●​ These are less suitable for estimation tasks where the outcome required is the
value of a continuous variable.
●​ The alternative options perform better with the same data. A random forest of
decision trees can be used as a replacement but it is not as straightforward to
comprehend as a single decision tree.
●​ Calculations can become quite complicated, especially when several values are
uncertain and/or multiple outcomes are related.

Difference between Decision Table and Decision Tree:

S.
No. Decision Table Decision Tree

Decision Tables are a tabular Decision Trees are a graphical

representation of conditions and representation of every possible
1. actions. outcome of a decision.

We can derive a decision table We cannot derive a decision tree from

2. from the decision tree. the decision table.

It helps to take into account the

possible relevant outcomes of the
3. It helps to clarify the criteria. decision.

In Decision Tables, we can

include more than one ‘or’ In Decision Trees, we cannot include
4. condition. more than one ‘or’ condition.

It is used when there are small It is used when there are more number
5. number of properties. of properties.
S.
No. Decision Table Decision Tree

6. It is used for simple logic only. It can be used for complex logic as well.

It is constructed of rows and

7. tables. It is constructed of branches and nodes.

A decision tree’s objective is to provide

The goal of using a decision table an effective means to visualize and
is the generation of rules for understand a decision’s available
structuring logic on the basis of possibilities and range of possible
8. data entered in the table. outcomes.

STRUCTURED CHART- Structure Chart represent hierarchical structure of

modules. It breaks down the entire system into lowest functional modules, describe
functions and sub-functions of each module of a system to a greater detail. Structure
Chart partitions the system into black boxes (functionality of the system is known to
the users but inner details are unknown). Inputs are given to the black boxes and
appropriate outputs are generated.

Modules at top level called modules at low level. Components are read from top to
bottom and left to right. When a module calls another, it views the called module as
black box, passing required parameters and receiving results.

Symbols used in construction of structured chart

1.​ Module​
It represents the process or task of the system. It is of three types.
o​ Control Module​
A control module branches to more than one sub module.
o​ Sub Module​
Sub Module is a module which is the part (Child) of another module.
o​ Library Module​
Library Module are reusable and invokable from any module.
2.​ Conditional Call​
It represents that control module can select any of the sub module on the
basis of some condition.

3.​ Loop (Repetitive call of module)​

It represents the repetitive execution of module by the sub module.​
A curved arrow represents loop in the module.

All the sub modules cover by the loop repeat execution of module.

4.​ Data Flow​

It represents the flow of data between the modules. It is represented by
directed arrow with empty circle at the end.

5.​ Control Flow​

It represents the flow of control between the modules. It is represented by
directed arrow with filled circle at the end.
 6.​ Physical Storage​
Physical Storage is that where all the information are to be stored.

Example: Structure chart for an Email server

Types of Structure Chart:

1.​ Transform Centered Structured: ​

These type of structure chart are designed for the systems that receives an
input which is transformed by a sequence of operations being carried out by
one module.
2.​ Transaction Centered Structure: ​
These structure describes a system that processes a number of different
types of transaction.

REQUIREMENT DOCUMENTATION AND REQUIREMENT

VALIDATION
Requirement documentation and requirement validation are two key processes in
software engineering that are critical for ensuring that software development projects
are successful and meet the needs of stakeholders.
Requirement documentation involves the process of gathering and documenting the
requirements of a software project. This includes identifying the needs and goals of
stakeholders, defining the scope of the project, and documenting the specific
functional and non-functional requirements of the software. Requirement
documentation is typically done through the use of tools such as use cases, user
stories, and other documentation techniques.

Requirement validation, on the other hand, involves the process of ensuring that the
requirements are correct, complete, and consistent. This process involves reviewing
the requirements documentation to identify potential errors, ambiguities, or
contradictions, and ensuring that the requirements are feasible and achievable within
the constraints of the project.

There are several techniques used in requirement validation, such as walkthroughs,

peer reviews, and testing. These techniques help to identify any issues with the
requirements and ensure that they meet the needs of stakeholders.

VALIDATION VS VERIFICATION

Verification Validation

It includes checking documents, It includes testing and validating the

design, codes and programs. actual product.

Verification is the static testing. Validation is the dynamic testing.

It does not include the execution of the

code. It includes the execution of the code.

Methods used in verification are Methods used in validation are Black

reviews, walkthroughs, inspections and Box Testing, White Box Testing and
desk-checking. non-functional testing.

It checks whether the software meets

It checks whether the software the requirements and expectations of a
conforms to specifications or not. customer or not.

It can find the bugs in the early stage It can only find the bugs that could not
of the development. be found by the verification process.

The goal of verification is application

and software architecture and The goal of validation is an actual
specification. product.
 Verification Validation

Quality assurance team does Validation is executed on software code

verification. with the help of testing team.

It comes before validation. It comes after verification.

It consists of checking of
documents/files and is performed by It consists of execution of program and
human. is performed by computer.