Introduction to SEngineering

• Software engineering is all about designing, developing, and maintaining software systems.
• It involves practices to create efficient and reliable software.
• Software engineers use various programming languages, tools, and techniques to build
software applications that meet specific requirements.
• They work on different stages of the software development life cycle, including requirements
gathering, design, coding, testing, and deployment.
• It's a fascinating field that combines creativity and problem-solving skills.

Importance of SEngineering
It is incredibly important because it helps to ensure the development of high-quality, reliable, and
efficient software systems. Few key reasons why software engineering is important:

• Quality Assurance: Software engineering practices, such as requirements gathering, design,

and testing, help ensure that software systems meet the desired quality standards and
function as intended. This reduces the likelihood of bugs, errors, and system failures.
• Efficiency and Scalability: Software engineering principles enable the creation of efficient and
scalable software systems that can handle increasing user demands and evolving business
needs. This allows for smooth operation and growth of the software over time.
• Cost-Effectiveness: By following software engineering best practices, organizations can
minimize the risk of project delays, cost overruns, and rework. This leads to more cost-
effective software development and maintenance processes.
• User Satisfaction: Software engineering focuses on understanding user requirements and
designing software systems that meet those needs. This ensures that users have a positive
experience with the software, leading to higher user satisfaction and engagement.
• Safety and Security: Software engineering emphasizes the implementation of robust security
measures to protect sensitive data and prevent unauthorized access. It also ensures that
software systems are reliable and safe to use, especially in critical domains such as
healthcare and transportation.

Overall, software engineering plays a crucial role in the successful development, deployment, and
maintenance of software systems, benefiting both businesses and end-users.
Software applications
Software applications are the end products that are developed to fulfill specific user needs or
requirements. These applications can vary widely in their functionalities and purposes. Some
common types of software applications in software engineering include:

• Desktop Applications: These are software applications that are installed and run on personal
computers or laptops. Examples: word processors, spreadsheets, and graphic design
software.
• Web Applications: These are applications that are accessed through web browsers and run
on web servers. Examples: online shopping platforms, social media sites, and web-based
email clients.
• Mobile Applications: These are applications specifically designed to run on mobile devices
such as smartphones and tablets. Examples: gaming apps, fitness trackers, and navigation
apps.
• Enterprise Applications: These are large-scale software applications designed to meet the
needs of businesses or organizations. Examples: customer relationship management (CRM)
systems, enterprise resource planning (ERP) software, and supply chain management
systems.
• Embedded Systems: These are software applications that are embedded within hardware
devices and perform specific functions. Examples: software in cars, medical devices, and
home appliances.

Software crisis
It refers to a situation where there are significant challenges or issues in the development or
maintenance of software systems. It can occur due to various reasons, such as:

• Project Delays: When software projects take longer than expected to complete, causing
delays in delivery and increased costs.
• Cost Overruns: When the actual cost of developing software exceeds the estimated budget,
leading to financial difficulties.
• Quality Issues: When software systems have bugs, errors, or lack reliability, causing user
dissatisfaction and potential business risks.
• Scope Creep: When the requirements of a software project keep expanding or changing,
making it difficult to meet deadlines and deliver a satisfactory product.
• Lack of Communication: When there is a lack of effective communication between
stakeholders, resulting in misunderstandings, misaligned expectations, and project failures.

These crises highlight the need for proper project management, software engineering practices, and
collaboration among team members to address and mitigate these challenges.
Software Processes
In software engineering, the "4 P's" are often referred to as People, Product, Process, and Project.
These four elements play a crucial role in the success of software development projects.

1. People: This refers to the individuals involved in the software development process, such as
developers, designers, testers, project managers, and stakeholders. People are the driving
force behind the project, and effective collaboration and communication among team
members are essential for successful software development.

2. Product: The product is the software system or application being developed. It includes
features, functionality, user interface, performance, and quality. The focus is on delivering a
high-quality software solution that meets the needs and expectations of the end-users.

3. Process: The process encompasses the methodologies, activities, and best practices followed
during software development. It includes stages like requirements gathering, design, coding,
testing, deployment, and maintenance. Following a well-defined and structured process
ensures efficient and effective software development.

4. Project: The project aspect involves planning, organizing, and managing resources to deliver
the software successfully. It includes tasks like project management, planning, scheduling,
resource allocation, risk management, and stakeholder communication. Managing the
project effectively ensures that it is completed within the defined scope, timeline, and
budget.

Considering the 4 Ps in software engineering helps organizations ensure successful software

development projects that meet user needs, are delivered on time, and maintain high quality.
SDLC
Stands for Software Development Life Cycle. It is a systematic approach or process followed to
develop software applications. The SDLC consists of several phases that guide the software
development process from start to finish. Phases in the SDLC:

• Requirements Gathering: Gathering and documenting the software requirements from

stakeholders and users.
• System Design: Creating a high-level design and architecture for the software system.
• Coding: Writing the actual code for the software based on the design specifications.

• Testing: Conducting various tests to ensure that the software meets the requirements and
functions correctly.
• Deployment: Releasing the software for use by end-users.
• Maintenance: Providing ongoing support, updates, and bug fixes for the software.

The SDLC helps ensure a structured and organized approach to software development, improving the
quality and reliability of the final product. Each phase in the SDLC has specific objectives and
deliverables that contribute to the overall success of the software project.
Waterfall Model
The waterfall model is a sequential software development process where each phase is completed
before moving on to the next. It follows a linear and rigid approach, with the following phases:

1. Requirements Gathering: Gathering and documenting the software requirements from

stakeholders and users.
2. System Design: Creating a detailed design and architecture for the software based on the
requirements.
3. Implementation: Developing the software by coding and integrating the different
components.
4. Testing: Conducting various tests to ensure that the software meets the requirements and
functions correctly.
5. Deployment: Releasing the software for use by end-users.
6. Maintenance: Providing ongoing support, updates, and bug fixes for the software.

The waterfall model is a traditional approach that works well for projects with well-defined and
stable requirements. However, it lacks flexibility and can lead to issues if requirements change during
the development process.

Waterfall Methodology can be used when:

• Requirements are not changing frequently
• Application is not complicated and big
• Project is short
• Requirement is clear
• Environment is stable
• Technology and tools used are not dynamic and is stable
• Resources are available and trained
Prototype Model
• It is an iterative approach that focuses on building a working prototype of the software early
in the development process.
• It’s modified until the client is not satisfied, only then we move to the next phase.
• This allows stakeholders to provide feedback and make necessary changes before moving
forward.
• The prototype model offers several advantages, such as enhanced stakeholder involvement,
early detection of issues, and improved communication.
• By creating prototypes, developers can gather valuable user feedback and refine the
software incrementally.
• This model is particularly useful when requirements are not well-defined or when there is a
need for continuous collaboration and flexibility.
• However, it's important to note that the prototype model may require additional time and
effort for prototyping and may not be suitable for projects with strict budget or time
constraints.
Advantages of Prototype Model:

• This model is flexible in design. It is easy to detect errors.

• We can find missing functionality easily.
• There is scope of refinement, it means new requirements can be easily accommodated.
• It can be reused by the developer for more complicated projects in the future.
• It ensures a greater level of customer satisfaction and comfort.
• It is ideal for online system.
• It helps developers and users both understand the system better.
• Integration requirements are very well understood and deployment channels are decided at
a very early stage.
• It can actively involve users in the development phase.

Disadvantages of using Prototype Model:

• This model is costly.

• It has poor documentation because of continuously changing customer requirements.
• There may be too much variation in requirements.
• Customers sometimes demand the actual product to be delivered soon after seeing an early
prototype.
• There may be sub-optimal solutions because of developers in a hurry to build prototypes.
• Customers may not be satisfied or interested in the product after seeing the initial prototype.
• There is certainty in determining the number of iterations.
• There may be incomplete or inadequate problem analysis.
• There may increase the complexity of the system.
Spiral Model in SEngineering
• The Spiral Model is a software development process that combines elements of both
waterfall and iterative(prototype) models. It involves a series of iterations where each
iteration is a mini-project, with its own planning, design, development, and testing phases.
• This model allows for flexibility and risk management throughout the software development
lifecycle.
• Works in a loop manner.
• Developed by Barry Boehm in 1986.
• Also known as meta model as it contains all the life cycle models.
• Purpose is to reduce the risk in the project.
• One business analyst is required to reduce the risk with the help of developer and client then
only we can say how much cost it will take to develop the software.
• Mainly suited for large and complex model.
• It is called spiral model as the same activities are repeated for all the loops(spirals)
• Each loop or spiral represents software development process.

Advantages of Spiral model:

• Risks are analysed at early stages of development.

• Used in large and complex models.
• Best technology.
• Feedback can be used at each step.

Disadvantages of spiral model:

• Cost is high as system analyst is required to analyse the risk.

• Not suitable for small projects.
• Each loop or spiral contains four quadrants so it takes more time to complete.
Quality Function Deployment (QFD)
is a structured approach to defining customer needs or requirements and translating them into
specific plans to produce products to meet those needs. The “voice of the customer” is the term to
describe these stated and unstated customer needs or requirements.
QFD is divided into 4 major phases: Product Planning, Product Development, Process Planning, and
Production Planning.

FAST or the Facilitated Application Specification Technique is a team-oriented approach that is

practiced during the early stages of analysis and specification to facilitate proper discussions.

Or

FAST, which stands for Facilitated Application Specification Technique, is a team-oriented approach
used during the early stages of analysis and specification. It helps facilitate productive
discussions by providing a structured framework for gathering requirements and defining
system specifications. This technique encourages active participation from team members,
promotes clarity, and ensures that all perspectives are considered. By using FAST, teams can
effectively collaborate and create a shared understanding of the project's goals and
requirements.

Data Flow Diagrams

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a
system. A neat and clear DFD can depict the right amount of the system requirement graphically. It
can be manual, automated, or a combination of both.

It shows how data enters and leaves the system, what changes the information, and where data is
stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be used
as a communication tool between a system analyst and any person who plays a part in the order
that acts as a starting point for redesigning a system. The DFD is also called as a data flow graph or
bubble chart.
Or

DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a process is
represented by DFD. It also gives insight into the inputs and outputs of each entity and the
process itself.

The following observations about DFDs are essential:

• All names should be unique. This makes it easier to refer to elements in the DFD.
• Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order of
events; arrows in DFD represents flowing data. A DFD does not involve any order of events.
• Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a DFD,
suppress that urge! A diamond-shaped box is used in flow charts to represents decision
points with multiple exists paths of which the only one is taken. This implies an ordering of
events, which makes no sense in a DFD.
• Do not become bogged down with details. Defer error conditions and error handling until
the end of the analysis.
 • Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.
• Data Flow: A curved line shows the flow of data into or out of a process or data store.
• Data Store: A set of parallel lines shows a place for the collection of data items. A data store
indicates that the data is stored which can be used at a later stage or by the other processes
in a different order. The data store can have an element or group of elements.
• Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or
sink of system outputs.

Use Case
Data Dictionary in software engineering
In software engineering, a data dictionary is a set of information about the system and its
components, such as databases, programs, file, and tables. It documents the structure and attributes
of each item in the system for better understanding and management.

It describes the meanings and purposes of data elements within the context of a project, and
provides guidance on interpretation, accepted meanings and representation. A Data Dictionary also
provides metadata about data elements.

There are two types of data dictionaries: active and passive.

A data dictionary may also be referred to as a “system catalogue.”

SRS Document
• SRS is a document that outlines the requirements for a software system.
• It describes the functional and non-functional requirements of the system.
• The SRS document helps stakeholders understand what the software should do and how it
should behave.
• It includes sections like introduction, system overview, functional requirements, non-
functional requirements, and more.
• The SRS document serves as a foundation for software development, testing, and validation.
• It helps ensure that the software meets the needs and expectations of the users and
stakeholders.

Characteristics of SRS:

• Complete: The SRS document should capture all the necessary requirements for the software
system.
• Clear and Concise: The document should be written in a clear and concise manner, avoiding
ambiguity and confusion.
• Consistent: The requirements should be consistent throughout the document, without any
contradictions or conflicts.
• Verifiable: The requirements should be verifiable, meaning they can be tested or validated to
ensure they are met.
• Traceable: Each requirement should be uniquely identified and linked to its source, such as
user needs or system constraints.
• Modifiable: The SRS document should be easily updated and modified as requirements
change over time.
• Realistic: The requirements should be feasible and achievable within the given constraints of
the project.
• Unambiguous: The document should use clear and precise language to avoid any
misunderstandings or misinterpretations.
• Prioritized: The requirements should be organized and prioritized based on their importance
and impact on the system.
• Understandable: The SRS document should be easily understandable by all stakeholders,
including developers, testers, and users.
Organization of an SRS document:

o Introduction: Provides an overview of the document, including its purpose, scope,

and intended audience.
o System Overview: Describes the system at a high level, including its context,
objectives, and key features.
o Functional Requirements: Details the specific functionalities and behaviors the
system should exhibit.
o Non-functional Requirements: Outlines the system's performance, usability, security,
and other non-functional aspects.
o User Interface: Describes the visual and interactive elements of the system's user
interface.
o System Constraints: Specifies any limitations or restrictions that impact the system's
design or implementation.
o Assumptions and Dependencies: Lists any assumptions made during the
requirements gathering process and external dependencies.
o Glossary: Provides definitions of technical terms and acronyms used throughout the
document.
o References: Includes any external documents or resources referenced in the SRS.

The IEEE standard for the SRS Document is IEEE Std 830-1998. It provides guidelines and
recommendations for creating a comprehensive and well-structured SRS document. However, it's
worth noting that standards may be revised or updated over time, so it's essential to refer to the
most recent version for the latest guidelines.