24 February 2025 16:05

Introduction ot SE
Diff b/w Software and Programme
Characterstics of software
Bathtub curve
4p Management
SDLC

Software requirement- Known -unknown -undreamed

Document Manual
opearting Manual

Software Component - diagram program ,component

SRS document -IEEE 1993 format

organization, point - write name , if expalin then explain

S/w process Model-waterfall,prototype,Incrimental,Rad,Spiral

V-Model, Cmm Model

Software Engenieering tool -> 2-3 tool -> Comparison with 1 similar tool -> explain
why your is better - check report Assignemnt

DFD (practice level- 2 starting from level 0)

Notation in class use that only
circle
Singel dir arrow
Rectangle box
Stroring Noataion(2 line)
Use Case,ER, Class ,Activity diagram

Online System->Consider thing online

if not -> write 2 line then Draw

Software Project Planning

Activity Diagram
size of software
Resource Location

Cocomo Model 1-
Effect
Development time
Staff Size
productivity
Numericals(2)-> Slides me hai

organic,semi detached embedded

Risk Management
divide in two
further th then finalze

Software Design

Software Engenieering Page 1

Software Design
Framework Design -> Connectivity with Interface (diagram)
IEEE 1016 1998 (SW design)
IEEE 830 1993 SRS
top down ,bottom up and hybrid
coupling cohesion & types
Conceptual

Software Metrices
what is matrice
type,defination
important in SE
product,project process time interval measures

SRS SDD(format points)

ppt 1,2,3 -full

ppt 4- (1-8)
(41-52)
(180-193)

ppt-5 slides-31 (cohesion &coupling), slide(55-56)

ppt -6 (1-25)
metrics measurement
categories of metrics

Software Engenieering Page 2

24 February 2025 18:27

1. What is Software Engineering?

Software Engineering is the systematic and disciplined approach to designing, developing, testing, and maintaining
software. It ensures that software is:
• High-quality, reliable, and maintainable
• Developed using efficient techniques, tools, and methodologies
• Completed on time, within budget, and according to specifications
• Mainly applied to large software systems rather than standalone programs
It helps create structured software solutions that can evolve and scale efficiently while minimizing errors.

2. Key Principles of Software Engineering

Fundamental Principles:
• Modularity – Breaking software into smaller, independent components for better management and reusability.
• Abstraction – Hiding complex implementation details and exposing only necessary functionalities.
• Encapsulation – Grouping data and related functions within objects to protect internal states.
• Reusability – Creating components that can be reused in multiple projects to save time and resources.
• Maintainability – Ensuring software can be easily updated, fixed, and improved.
• Testing – Verifying that software functions correctly and meets requirements.
• Design Patterns – Standardized templates to solve recurring software design problems.
• Agile Methodologies – Iterative development processes that focus on flexibility, rapid delivery, and customer
satisfaction.
• Continuous Integration & Deployment (CI/CD) – Regularly integrating and deploying software updates to ensure
efficiency.
These principles guide the development process and improve software quality.

3. Main Attributes of Software Engineering

Software Engineering aims to create software with the following characteristics:
• Efficiency – Optimized use of system resources (CPU, memory, etc.).
• Reliability – Consistent performance without failure.
• Reusability – Components can be adapted for new applications.
• Maintainability – Easy to modify, enhance, or debug.
These attributes define the overall effectiveness of a software system.

4. Dual Role of Software

Software serves two main roles:
1. As a Product
○ Provides computational power across hardware networks.
○ Enables hardware functionality.
○ Acts as an information transformer (storing, modifying, and transmitting data).
2. As a Vehicle for Delivering a Product
○ Provides system functionality (e.g., payroll systems).
○ Controls other software (e.g., operating systems).
○ Helps build other software (e.g., development tools).
Software is both a product itself and a tool for creating new products.

5. Objectives of Software Engineering

Software engineering focuses on key objectives to improve development processes:
• Maintainability – Software should be adaptable to evolving requirements.
• Efficiency – Should utilize computing resources effectively.
• Correctness – Must fulfill all specifications outlined in the Software Requirements Specification (SRS) document.
• Reusability – Components should be designed for use in future projects.
• Testability – Must support verification and validation through testing.
• Reliability – Must function correctly over time with minimal failures.
• Portability – Should work across different hardware/software environments.
• Adaptability – Should be modifiable for varying system constraints.
• Interoperability – Should integrate with other systems and software.

6. Tasks of Software Engineers

Software engineers work on various tasks, including:

Software Engenieering Page 3

Software engineers work on various tasks, including:
• Requirement Analysis – Understanding client needs and defining system requirements.
• Design & Development – Writing structured, maintainable code.
• Testing & Debugging – Running tests to detect and fix errors.
• Code Review – Ensuring adherence to coding standards.
• Software Maintenance – Updating, fixing bugs, and adding new features.
• Documentation – Writing clear technical documents and API guides.

7. Advantages of Software Engineering

• Improved quality and reliability
• Increased productivity and maintainability
• Reduced development costs
• Better team collaboration and scalability
• Enhanced security and customer satisfaction

8. Disadvantages of Software Engineering

• High upfront costs (training, tools, processes)
• Limited flexibility due to structured methodologies
• Bureaucratic processes slowing development
• Complexity in managing large projects
• High learning curve for beginners
• Dependency on tools and frequent maintenance requirements

Software & Program

1. What is Software?
Software is a set of programs, procedures, data, or instructions designed to perform specific tasks and instruct a
computer on what to do. It acts as an interface between the user and hardware and ensures that the system functions
properly.
Key Characteristics of Software:
• Collection of programs & data – Works together to achieve a function.
• Performs specific tasks – Can be system-related (OS) or application-based (MS Word, Photoshop).
• Essential for computer operation – Without software, a computer is useless.
• Can be categorized into System Software, Application Software, and Programming Tools.

2. What is a Program?
A program is a set of ordered instructions designed to perform a specific function or task. Programs are executed by a
computer's CPU to produce the desired output.
Key Characteristics of a Program:
• A single unit of execution – Focuses on one particular task.
• Written in a programming language – Such as C, Java, or Python.
• Executed using a compiler/interpreter – Converts code into machine language.
• Forms the building block of software – Multiple programs together create software.

Software Engenieering Page 4

Software Characteristics

• Functionality: It refers to the degree of performance of the software against its intended purpose.

• Reliability: A set of attributes that bears on the capability of software to maintain its level of
performance under the given condition for a stated period of time.

• Efficiency: It refers to the ability of the software to use system resources in the most effective and
efficient manner. The software should make effective use of storage space and executive command as
per desired timing requirements.

• Usability: It refers to the extent to which the software can be used with ease. the amount of effort or
time required to learn how to use the software.

• Maintainability: It refers to the ease with which the modifications can be made in a software system to
extend its functionality, improve its performance, or correct errors.

• Portability: A set of attributes that bears on the ability of software to be transferred from one
environment to another, without or minimum changes.

Apart from above mention qualities of software, there are various characteristics of software in
software engineering:

• Software is developed, not manufactured – While both software and hardware require good design for high quality,
hardware manufacturing can introduce quality issues, unlike software development.
• Software doesn’t wear out – Unlike hardware, software does not degrade over time due to environmental factors.
However, it can become outdated or inefficient.
• No spare parts in software – Software failures indicate design flaws rather than physical wear. Maintenance involves
fixing errors and improving design rather than replacing components.
• Software continues to be custom-built – While software reuse is increasing, components still need to be planned and
developed for reuse, unlike in hardware where component reuse is standard.

Software Bathtub Curve

Introduction
• The Bathtub Curve is a graphical representation of the failure rate of assets over time.
• It is used in run-to-failure maintenance strategies to predict failures and identify root causes.
• Named "bathtub curve" because its shape resembles a bathtub.

Sections of the Bathtub Curve

1. Infant Mortality Section (Early Failure Period)
○ High initial failure rate, which decreases over time.
○ Causes: Manufacturing defects, installation issues, design flaws, material defects, improper startup

Software Engenieering Page 5

 ○ Causes: Manufacturing defects, installation issues, design flaws, material defects, improper startup
procedures.
2. Normal Life Section (Steady-State Operation)
○ Failure rate is low and constant.
○ Causes: Overloading, hidden defects, personnel mistakes, random failures.
○ Assets can remain unchecked for some time as failures occur infrequently.
3. Wear-Out Section (Aging Period)
○ Failure rate increases over time.
○ Causes: Fatigue, wear, gradual deterioration, corrosion.
○ Represents the end of an asset's lifecycle.

Why Software Systems Follow a Bathtub Curve

• Latent Defects: Software is deployed with unresolved bugs.
• Failure Definition Variability: What is considered a failure depends on system specifications.
• Non-Random Failures: Failures appear random but are triggered by specific conditions.
• Operational Profile Changes: The probability of failures depends on how frequently certain functions are used.
Software Operational Lifecycle
1. Initial Phase:
○ High failure rate due to undetected bugs.
○ Software vendors release patches to fix defects.
2. Operational Lifetime:
○ Stable phase with minor and occasional failures.
○ Software is used as per specifications.
3. Terminal Phase:
○ Frequent failures due to cumulative changes, increased complexity.
○ Reactive fixes lead to further instability.
○ Proactive Replacement Phase is required before failure becomes unmanageable.
Factors Leading to Software Failure
• Changing Operational Profile: New usage patterns expose latent bugs.
• Changing Requirements: Business needs evolve over time.
• Technology Stack Evolution: Software must adapt to new platforms.

The Management Spectrum | 4 P’s in Software

• People
The most important component of a product and its successful implementation is human resources. In building a proper

Software Engenieering Page 6

•
The most important component of a product and its successful implementation is human resources. In building a proper
product, a well-managed team with clear-cut roles defined for each person/team will lead to the success of the product. We
need to have a good team in order to save our time, cost, and effort. Some assigned roles in software project planning
are project manager, team leaders, stakeholders, analysts, and other IT professionals. Managing people successfully is a
tricky process which a good project manager can do.

• Product
As the name inferred, this is the deliverable or the result of the project. The project manager should clearly define the product
scope to ensure a successful result, control the team members, as well technical hurdles that he or she may encounter during
the building of a product. The product can consist of both tangible or intangible such as shifting the company to a new place or
getting a new software in a company.

• Process
In every planning, a clearly defined process is the key to the success of any product. It regulates how the team will go about its
development in the respective time period. The Process has several steps involved like, documentation phase, implementation
phase, deployment phase, and interaction phase.

• Project
The last and final P in software project planning is Project. It can also be considered as a blueprint of process. In this phase, the
project manager plays a critical role. They are responsible to guide the team members to achieve the project’s target and
objectives, helping & assisting them with issues, checking on cost and budget, and making sure that the project stays on track
with the given deadlines.

Software Engenieering Page 7

SDLC
24 February 2025 19:16

Software Development Life Cycle (SDLC)

Definition of SDLC
• SDLC is a structured approach used for designing, developing, and testing software.
• Ensures software is high-quality, maintainable, and meets user requirements.
• Defines step-by-step procedures to develop software efficiently.
• Helps deliver software at a low cost and within a specific time frame.

Purpose of SDLC
• Helps in developing, maintaining, replacing, and enhancing software.
• Improves software quality and ensures a systematic development process.
• Ensures that the final product meets customer expectations while staying within the budget.
• Provides a structured workflow for software engineers and developers.

Stage 1: Planning and Requirement Analysis

Planning is a crucial step in software development, as it lays the foundation for the entire project. In this
phase, developers conduct requirement analysis based on customer inputs, sales department insights, and
market surveys. The gathered information helps in defining the basic structure of the project. Proper
planning ensures the quality and feasibility of the software before development begins.

Stage 2: Defining Requirements

Once the requirements are gathered, they need to be clearly defined and documented. This is done using a
Software Requirement Specification (SRS) document, which includes all functional and non-functional
requirements of the project. The SRS is reviewed and approved by stakeholders, market analysts, and
customers to ensure that all project expectations are well-defined before moving forward.

Software Engenieering Page 8

Stage 3: Designing Architecture
With the requirements outlined in the SRS, software designers create multiple architectural designs for the
system. These designs are documented in the Design Document Specification (DDS) and evaluated by
stakeholders. The most practical, scalable, and efficient design is chosen for development. A well-structured
design ensures the software’s robustness, maintainability, and overall performance.

Stage 4: Developing Product

In this phase, actual coding and software development take place based on the selected design. Developers
follow industry standards and organizational protocols while using programming languages such as C/C++,
Python, and Java. Programming tools like compilers, interpreters, and debuggers assist in writing and
refining the code. This stage is critical as it transforms theoretical plans into a functional software product.

Stage 5: Product Testing and Integration

Once the software is developed, rigorous testing is conducted to ensure its smooth functionality. Testing is
performed at every stage of the SDLC, but this phase involves tracking and fixing all potential defects. The
software is evaluated against the requirements specified in the SRS, and any identified bugs are resolved
before deployment. Proper documentation is also prepared, providing instructions on software usage,
maintenance, and troubleshooting. Additionally, training programs are conducted to help users and
employees understand the system effectively.

Software Engenieering Page 9

Stage 6: Deployment and Maintenance of Products
After thorough testing, the final software product is deployed in a real-world environment. Initially, it is
released in phases to observe its performance in an industrial setting. If the product functions smoothly, it is
made available for broader use. Customer feedback is collected, and necessary modifications are
implemented to enhance usability. Post-deployment maintenance ensures continuous monitoring, bug fixes,
and updates to keep the software relevant and efficient in the long run.

Types of Software Requirements: Known, Unknown, and Undreamed

1. Known Requirements
These are the requirements that are explicitly stated, well-defined, and documented. They are usually
gathered from customers, stakeholders, or market research. Known requirements are categorized into
functional (specific features or functionalities) and non-functional (performance, security, usability,
etc.) requirements. Since they are clearly understood, they form the foundation of the Software
Requirement Specification (SRS).

2. Unknown Requirements
These are the requirements that are not immediately apparent at the beginning of the project but
emerge during development or testing. Unknown requirements arise due to evolving customer needs,
unforeseen technical challenges, or gaps in initial analysis. Agile and iterative development
methodologies help in handling such requirements by allowing flexibility in incorporating changes.

3. Undreamed Requirements

Software Engenieering Page 10

3. Undreamed Requirements
These requirements refer to aspects that neither the customer nor the developers initially considered or
imagined. They often arise due to innovations, technological advancements, or changing market trends.
Sometimes, users may not even realize they need a particular feature until they see its potential in
action. Companies that anticipate undreamed requirements can innovate and create groundbreaking
solutions that exceed customer expectations.

Software Engenieering Page 11

24 February 2025 21:53

Documentation manuals in Software Engineering

Classification of Documentation Manual :

1. Analytics/ Specification Manual :
This manual is prepared during the analysis phase of the software development. In this manual, all
the information that specifies the requirements of the software are described. Information in this
manual are presented in the following :
• Formal specification –
In this, all the requirements of the software are describe in detail.
• Context diagram –
This diagram describes the context of the Software.
• Data flow diagram –
Data flow diagram is a visual representation of the flow of information within the software.

2. Design Manual :
In this manual, all the information regarding the design of the software and how a software should
look. This manual is consist of the following :
• Flow charts –
It is a visual representation for representing the working procedure of the software.
• Entity relationship diagrams –
This is a type of flowchart that illustrates how “entities” such as people, objects, etc.

3. Implementation Manual :
This manual is prepared during the development phase of the software development. In this manual,
all the information regarding the program code, algorithms and data structures that are used in the
software. This manual is consist of the following :
• Source code listing –
It describes the code that is developed for that software.
Cross reference listing –
Software Engenieering Page 12
• Cross reference listing –
It describes the reference of the code module.

4. Testing Manual :
This manual is prepared in the testing phase of the Software. The tester is used to checks the
software for the best and worst cases of functioning and the result are stored. This manual is consist
of the following :
• Test data –
These are the data which are used as input for processing the task in the software.
• Test results –
These data are the Output that is produced by the software for the provided Test Data.

The operating procedures is a set of step-by-step instructions compiled by an organization to

help workers carry out complex routine operations. It consists of all the information that is
required for operating the Software. The operating procedures are equally important as the
program code of the software.

1. User Manuals :
This manuals is used to describe how to operate the particular software.
The User Manual consist of the following –
• System overview –
It describe the overview of the entire software. It is used to defines what are the purpose of the
software.
• Beginner’s guide tutorials –
This guide consist of step by step procedure for operating the software. A beginner can know how to
use software and the working of it. Overall, it helps in getting to know the software.
• Reference guide –
This guide is a help book for the users. Users can look forward for further reference in the Reference
guide.
2. Operational Manual :
This manual describes all the requirements and supports of the hardware and software that are
required for software running.

Software Engenieering Page 13

 required for software running.
The Operational Manual consist of the following –
• Installation guide –
This guide consist of all information regarding the installation of the software.
• System administration guide –
This guide consist of all information regarding the Administration settings and the permissions that
are required for the Software.

Components of Software(Main)
There are three main components of the software:
1. Program: A computer program is a list of instructions that tell a computer what to do.
2. Documentation: Source information about the product contained in design documents, detailed code
comments, etc.
3. Operating Procedures: Set of step-by-step instructions compiled by an organization to help workers
carry out complex routine operations.

Other Software Components

Other Software Components are:

4. Code: the instructions that a computer executes in order to perform a specific task or set of tasks.
5. Data: the information that the software uses or manipulates.
6. User interface: the means by which the user interacts with the software, such as buttons, menus, and
text fields.
7. Libraries: pre-written code that can be reused by the software to perform common tasks.
8. Documentation: information that explains how to use and maintain the software, such as user
manuals and technical guides.
9. Test cases: a set of inputs, execution conditions, and expected outputs that are used to test the
software for correctness and reliability.
10. Configuration files: files that contain settings and parameters that are used to configure the software
to run in a specific environment.
11. Build and deployment scripts: scripts or tools that are used to build, package, and deploy the
software to different environments.
12. Metadata: information about the software, such as version numbers, authors, and copyright
information.

Software Engenieering Page 14

 Software Process Models
24 February 2025 22:21

1. Waterfall Model
This model is easy to understand and reinforces the notion of “define before design” and “design before code”
Waterfall model is a famous and good version of SDLC(System Development Life Cycle) for software engineering. The waterfall
model is a linear and sequential model, which means that a development phase cannot begin until the previous phase is completed. We cannot
overlap phases in waterfall model.

Problems of waterfall model

• It is difficult to define all requirements at the beginning of a project

• This model is not suitable for accommodating any change
• A working version of the system is not seen until late in the project’s life
• It does not scale up well to large projects.
• Real projects are rarely sequential

Incremental Process Models

Incremental process models are useful in scenarios where the requirements are well-defined, and there is clarity regarding the final
product’s functionality. Instead of developing the entire system at once, the product is built and delivered in smaller increments or
cycles, with each increment adding new functionality.

After every cycle, a usable version of the product is provided to the customer, allowing for early feedback and iterative
improvements. This model is particularly beneficial when there is a need to quickly deliver a system with limited functionality and
then enhance it over time. It is commonly used in projects requiring flexibility, adaptability, and faster deployment.

Iterative Enhancement Model

• The Iterative Enhancement Model follows a structured development approach similar to the Waterfall Model but with
greater flexibility. Instead of completing all phases in a single pass, this model allows multiple iterations where a usable
product is delivered at the end of each cycle. Each iteration refines and extends the software, ensuring that new
functionalities are added while existing features are improved. This approach is particularly useful in scenarios where
requirements evolve over time, as it allows for continuous feedback and improvements.

• Key Points:
• Customers and developers specify as many requirements as possible and document them in the Software Requirement
Specification (SRS).
• Requirements are prioritized to focus on critical functionalities first.
• Development follows multiple cycles of design, implementation, and testing based on the defined priorities.
• A usable product is released at the end of each cycle, providing additional functionality with every iteration.
• Customer feedback is incorporated into subsequent iterations, making the product more refined over time.

Software Engenieering Page 15

 • Customer feedback is incorporated into subsequent iterations, making the product more refined over time.
• Helps in projects where requirements are uncertain or expected to change over time.

Rapid Application Development (RAD) Model

The Rapid Application Development (RAD) Model is a software development methodology that emphasizes quick
development and iteration. It is similar to the Incremental or Waterfall Model but is particularly suited for small projects.
If the project is large, it is divided into smaller, manageable components that are developed and completed one by one.
This approach speeds up the overall development process and ensures that the project is completed within the given time
frame. All requirements are gathered before development begins, and the use of pre-built components helps in faster
execution with minimal errors. The main goal of the RAD model is to reuse code, tools, components, and processes to
accelerate software development.

Key Points:

• Best suited for small projects; large projects are divided into smaller sub-projects.
• Ensures faster project completion within the given timeline.
• Requires reusable components to minimize development time.
• Not effective without user participation, as user feedback plays a crucial role.
• Requires highly skilled and specialized developers, who may not always be readily available.

Evolutionary Process Model

The Evolutionary Process Model is similar to the Iterative Enhancement Model as it follows a cyclical approach, incorporating the
same phases as the Waterfall Model. However, unlike the Iterative Enhancement Model, it does not require a usable product at
the end of each cycle. Instead, in evolutionary development, requirements are implemented by category rather than by priority.

Key Points:
• Best suited for projects involving new or evolving technology that is not well understood.
• Useful for complex projects where all functionality must be delivered at once.
• Handles unstable or unclear requirements, making it flexible for evolving user needs.
• Requirements are implemented in categories, ensuring structured and systematic development.

Software Engenieering Page 16

Prototype Model
The Prototype Model is a software development approach where a preliminary version (prototype) of the application is built before
the final system. This helps in understanding requirements better and refining the system based on user feedback. It was introduced
to overcome the shortcomings of the Waterfall Model, especially when requirements are unclear.

Key Features:
• The prototype is not the final product and is usually discarded after gathering insights.
• Helps in understanding and refining requirements before full-scale development.
• Though it may involve extra cost, it can reduce overall expenses compared to the Waterfall Model by preventing major
redesigns later.
• The prototype model can be used alone or combined with other models for better efficiency.

Spiral Model
The Spiral Model is a software development process that combines elements of both the Iterative and Waterfall models. It is
primarily used for large and complex projects where requirements may change frequently. The model is called "spiral" because its
structure resembles a spiral, with multiple loops representing different phases of development. The number of loops is not fixed and
depends on the size and complexity of the project.

Key Features:
• Unlike other models, the Spiral Model explicitly considers project risks, making it suitable for uncertain and high-risk projects.
• Barry Boehm introduced this model in 1986 to incorporate risk management into the software development process.
• The radial dimension represents cumulative costs, while the angular dimension indicates progress in completing each phase.
• Each loop of the spiral is a phase, divided into four key activities:
1. Planning – Identifying objectives, alternatives, and constraints.
2. Risk Analysis – Evaluating potential risks and finding ways to mitigate them.
3. Development – Designing, coding, and testing the product.
4. Assessment – Reviewing progress and gathering customer feedback.

Advantages:
• Allows flexibility and accommodates changes throughout development.
• Integrates risk management, reducing project failures.
• Can adapt to different software life cycle models as needed.

Challenges:
• Lacks explicit guidelines for defining objectives and alternatives.
• Requires expertise in risk analysis, which may not always be available.
• Provides more flexibility than necessary for some projects, making it less efficient in simpler cases.

Software Engenieering Page 17

V-Model (Verification and Validation Model)
The V-Model is a Software Development Life Cycle (SDLC) model that emphasizes a structured and disciplined approach to
software development. It is known as the Verification and Validation Model because each development phase has a corresponding
testing phase, ensuring early defect detection and efficient quality assurance.

Key Characteristics of V-Model:

• Sequential Execution: Each phase starts only after the previous phase is completed.
• Parallel Testing: Testing activities are performed alongside development activities.
• V-Shaped Structure: The left side represents development phases, the right side represents testing phases, and both are
connected by the coding phase.
• Disciplined and Structured: Ensures that verification (checking correctness) and validation (checking if the software meets
requirements) happen simultaneously.

V-Design Structure:
• Left Side (Development Activities) – Represents the software design and coding process.
• Right Side (Testing Activities) – Represents the corresponding testing phases for each development phase.
• Coding Phase (Bottom of the V) – Acts as the bridge connecting development and testing.
This model is widely used in projects where requirements are well-defined, as it ensures high-quality software by integrating
early testing and validation into the development process.

Capability Maturity Model (CMM) – Software Engineering

The Capability Maturity Model (CMM) is a framework for improving software development processes. It helps organizations
assess their current practices and identify areas for enhancement. CMM consists of five maturity levels: Initial, Repeatable,
Defined, Managed, and Optimizing, guiding organizations toward higher efficiency and quality.

Key Principles of CMM:

• People’s capability is a competitive advantage in software development.
• Skills and capabilities should align with business objectives.
• Organizations must invest in improving employees' skills and capabilities.
• Management is responsible for fostering talent development.
• Improvement should follow a structured process with best practices.
• Continuous enhancement is necessary to keep up with emerging technologies.

Software Engenieering Page 18

Software Engenieering Page 19
Software Engenieering Page 20
24 February 2025 23:10

Software Engineering Tools Based on SDLC Phases

In software development, tools play a crucial role in streamlining processes at different Software
Development Life Cycle (SDLC) phases. Below are three essential tools categorized by SDLC phases:

1. Docker (Deployment & Maintenance Phase)

○ Purpose: Docker simplifies application deployment by containerizing software, ensuring
consistency across different environments.
○ Features: Lightweight containers, scalability, cross-platform compatibility, and automation.
○ Benefits: Eliminates environment-related issues, speeds up deployment, and integrates well with
CI/CD pipelines.
2. JIRA (Planning & Requirement Analysis Phase)
○ Purpose: A project management tool used for tracking requirements, tasks, and issues in
software projects.
○ Features: Agile boards, sprint planning, backlog management, and reporting.
○ Benefits: Enhances collaboration, tracks project progress, and provides clear workflows.
3. Selenium (Testing Phase)
○ Purpose: An automation testing tool used to validate web applications.
○ Features: Supports multiple programming languages, cross-browser testing, and integration with
CI/CD tools.
○ Benefits: Reduces manual testing effort, increases accuracy, and speeds up the testing process.

Software Engenieering Page 21

Final Verdict: Why Docker Stands Out
Docker is superior in software deployment because it ensures consistency across development, testing,
and production environments. Unlike Jenkins (which automates pipelines), Selenium (which tests
applications), and JIRA (which manages projects), Docker directly impacts the reliability and scalability
of software applications.

If an organization needs a stable, portable, and scalable deployment process, Docker is the best choice
among these tools.

Software Engenieering Page 22

Why Docker is Better?

• Easier to Set Up & Use → Docker is lightweight and simple, making it ideal for developers who need
quick deployment. Kubernetes, while powerful, has a steep learning curve.
• Better for Small Applications → If you're working on a single-host application, Docker is sufficient
without the complexity of Kubernetes.
• Lower Resource Consumption → Docker runs efficiently on minimal system resources, whereas
Kubernetes requires a more powerful infrastructure.

Software Engenieering Page 23

 24 February 2025 23:14

Project Plan
Once a project is found to be possible, computer code project managers undertake project design. Project
designing is undertaken and completed even before any development activity starts. Project designing consists
of subsequent essential activities: Estimating the subsequent attributes of the project:
• Project size: What’s going to be the downside quality in terms of the trouble and time needed to develop the
product?
• Cost: What proportion is it reaching to value to develop the project?
• Duration: How long is it to reach design plate amended development?
• Effort: What proportion of effort would be required?

The effectiveness of the following design activities relies on the accuracy of those estimations.
• planning force and alternative resources
• workers organization and staffing plans
• Risk identification, analysis, and abatement designing
• Miscellaneous arrangements like quality assurance plans, configuration, management arrangements, etc.

The diagram represents key aspects of software project estimation and scheduling. Here’s an explanation of each
component:
1. Size Estimation
○ It involves estimating the size of the software project, typically measured in terms of Lines of Code (LOC),
Function Points (FP), or Use Case Points (UCP).
○ The size estimation helps determine the effort required for development, influencing cost, resources, and time
estimation.
○ Accurate size estimation is essential for reliable project planning and scheduling.

2. Cost Estimation
○ This process involves predicting the total cost required for software development, considering factors like labor,
hardware, software tools, and operational expenses.
○ Cost estimation methods include COCOMO, expert judgment, and analogy-based estimation.
○ It helps in budgeting and financial planning, ensuring resource allocation aligns with project constraints.

3. Development Time
○ This refers to the total time required to complete the software project, including phases like requirement
analysis, design, coding, testing, and deployment.
○ Development time is influenced by project size, complexity, team expertise, and resource availability.
○ A well-estimated development time ensures timely delivery and efficient project execution.

4. Resources Requirements
○ This includes identifying the human, technical, and infrastructure resources needed for the project.
○ Resources include developers, testers, designers, project managers, software tools, and hardware.
○ Proper resource estimation ensures the project runs smoothly without delays due to shortages.

5. Project Scheduling
○ Project scheduling involves planning the sequence and timeline of tasks to complete the project efficiently.
○ It includes setting milestones, deadlines, task dependencies, and resource allocations.

Software Engenieering Page 24

 ○ It includes setting milestones, deadlines, task dependencies, and resource allocations.
○ Techniques like PERT (Program Evaluation and Review Technique) and Gantt charts are commonly used for
scheduling.

Relationships in the Diagram

• Size estimation impacts both cost estimation and development time, as larger projects require more resources and
time.
• Cost estimation and size estimation together determine resource requirements, ensuring adequate staffing and tools.
• Development time directly influences project scheduling, ensuring tasks are completed within the deadline.
This structured estimation process helps in efficient project planning, execution, and management, reducing risks and
uncertainties.

Software Engenieering Page 25

 24 February 2025 23:17

What is Risk Management?

A risk is a probable problem; it might happen, or it might not. There are main two characteristics of risk.
• Uncertainty: the risk may or may not happen which means there are no 100% risks.
• Loss: If the risk occurs in reality, undesirable results or losses will occur.

Software Risk Management

Software developers tend to be optimistic, assuming everything will go as planned. However, software
projects are often full of uncertainties and unexpected surprises, which are rarely good news. Risk
management is essential to identify, address, and eliminate potential problems before they become crises.
What is Risk?
• "Tomorrow’s problems are today’s risks."
• A risk is a potential problem that may cause loss or threaten the success of a project but has not yet
occurred.
• Risk Management is the process of identifying, assessing, and mitigating these risks before they impact
the project.

Types of Software Risks

1. Dependencies on External Factors

These risks arise when a project's success relies on external agencies, teams, or resources that may not
always be available.
• Dependency on third-party vendors or agencies
• Shortage of skilled personnel
• Inter-group dependencies (coordination issues between different teams)
• Delays in customer-furnished items or information
• Issues with subcontractor relationships

2. Requirement Issues
Unclear, evolving, or incorrect requirements can lead to misaligned expectations and dissatisfied customers.
• Uncertain or changing requirements
• Delivering the wrong product (either incorrect functionality or poorly implemented features)
• Lack of clear product vision
• No agreement on product requirements
• Failure to prioritize requirements
• New market demands with uncertain needs
• Inadequate impact analysis of requirement changes

3. Management Issues
Poor project management leads to delays, confusion, and inefficiencies.
• Inadequate planning and unrealistic schedules
• Lack of visibility into actual project status
• Unclear project ownership and decision-making responsibilities
• Conflicts among team members
• Unrealistic expectations from management or stakeholders
• Poor communication across teams and stakeholders

4. Lack of Knowledge & Technical Challenges

Teams lacking the right skills, experience, or tools may struggle to deliver high-quality software.
• Inadequate training for team members
Software Engenieering Page 26
 • Inadequate training for team members
• Poor understanding of software methods, tools, and techniques
• Lack of experience in the application domain
• Adoption of new or unfamiliar technologies
• Neglected or poorly documented processes

5. Other Risk Categories

Additional risks that can significantly impact the project:
• Unavailability of adequate testing facilities
• High turnover of essential personnel
• Unachievable performance requirements
• Unproven or unreliable technical approaches

Risk Management Activities

1. Risk Assessment
Risk assessment involves identifying, analyzing, and prioritizing risks that may impact the project. It helps in
understanding potential threats, their consequences, and possible mitigation strategies. By assessing risks
early, project teams can proactively plan for challenges rather than reacting to crises.

• Risk Identification – Recognizing potential risks that might affect the project, such as technical failures,
resource shortages, or changing requirements. A thorough assessment of internal and external factors is
conducted. This ensures all possible risks are documented and categorized.

• Risk Analysis – Evaluating risks based on their probability and severity to determine their impact on
project success. This involves assessing both qualitative and quantitative aspects of each risk. The
analysis helps in making informed decisions about risk handling strategies.

• Risk Prioritization – Ranking risks based on their likelihood and impact, ensuring that the most critical
ones are addressed first. Risks with higher impact and probability receive immediate attention. This
helps allocate resources efficiently to minimize potential damages.

2. Risk Control
Risk control focuses on managing and mitigating risks to reduce their negative effects. It involves planning,
monitoring, and taking corrective actions to ensure project stability. Effective risk control prevents
disruptions and ensures smooth project execution.

• Risk Management Planning – Developing strategies to handle risks, including avoidance, mitigation,
transfer, or acceptance of risks. Contingency plans are created for high-priority risks. The objective is to
prepare for uncertainties and minimize negative consequences.

• Risk Monitoring – Continuously tracking identified risks, assessing their status, and detecting new risks
that may arise. Regular updates ensure risks are being managed effectively. Any changes in risk factors
are addressed promptly to avoid surprises.

•
Software Engenieering Page 27
• Risk Resolution – Implementing actions to eliminate, minimize, or control risks, ensuring they do not
disrupt project objectives. Risk resolution strategies may include reassigning resources or modifying
project scope. The goal is to achieve project stability despite uncertainties.

Software Engenieering Page 28

25 February 2025 12:31

Software Measurement & Metrics

1. Importance of Measurement in Software Engineering

• Measurement is a fundamental aspect of any engineering discipline, including software engineering.
• It helps improve the software development process, estimate costs, ensure quality control, and support
decision-making.
• By applying software metrics, engineers can quantify different aspects of software development to predict,
control, and enhance its effectiveness.

2. Key Concepts in Software Metrics

• Measure: A quantitative value representing a specific attribute of a product or process (e.g., number of
errors).
• Measurement: The process of determining a measure to analyze software characteristics.
• Metric: A measure that quantifies an attribute of a system, component, or process (e.g., defects per
person-hour).
• Indicator: A combination of one or more metrics that provide insights into software processes, projects, or
products.

3. Types of Software Metrics

• Direct Metrics: Attributes that can be measured directly, such as lines of code (LOC), execution speed, and
defect count.
• Indirect Metrics: Attributes that cannot be measured directly, such as maintainability, usability, and
complexity.

4. Faults and Defects in Software Development

• Errors: Mistakes found by developers during the software development process.
• Defects: Issues detected by customers or users after the software has been released.
• Categorization: Errors should be classified based on their origin, type, and impact to facilitate better risk
management and quality assurance.

5. Applications of Software Metrics

• Quality Assessment: Evaluating software quality to ensure reliability, efficiency, and performance.
• Productivity Measurement: Assessing the efficiency of development teams and individual contributors.
• Process Improvement: Identifying inefficiencies and improving software development methodologies.
• Project Estimation: Helping in cost, time, and resource estimation for future projects.
• Decision-Making Support: Justifying investments in new tools, training, and process enhancements.
• Defect and Error Rate Analysis: Forecasting potential issues and reducing future maintenance costs.

6. Measuring Defect and Error Rates

• Errors and defects are measured at various levels, including individual components, modules, and the
overall system.
• The categorization of errors helps in analyzing their impact and planning corrective actions accordingly.
• Tracking defect rates assists in predicting maintenance needs and improving long-term software quality.

7. Expert Definitions of Software Measurement

• Pressman: Measurement provides a quantitative indication of an attribute related to a product or process,
helping to evaluate its effectiveness.
• Fenton: Measurement is the process of assigning numbers or symbols to real-world attributes in a way that
describes them using well-defined rules.

8. Areas of Application of Software Metrics

• Cost and Size Estimation: Used to predict development costs and required resources.
• Quality and Reliability Prediction: Helps in forecasting software performance and detecting potential
failures.
• Design Validation: Ensures that software design meets defined standards and requirements.

Software Engenieering Page 29

 • Design Validation: Ensures that software design meets defined standards and requirements.
• Process Monitoring and Control: Enables tracking of project progress and detecting deviations early.

Categories of Software Metrics

1. Product Metrics
• These describe the characteristics of a software product, including its size, complexity, performance,
efficiency, reliability, and portability.
• Product metrics provide insights into the quality and maintainability of the software product at any stage
of development.

• Examples:
○ Complexity metrics: Measure the intricacy of software design.
○ Size metrics: Lines of Code (LOC), Function Points (FP), and documentation size.
○ Performance metrics: Execution speed, memory usage, response time.
○ Defect density: Number of defects per KLOC (thousand lines of code).

2. Process Metrics
• These measure the effectiveness and quality of the software development process and aim at process
improvement.
• Process metrics are collected over long periods and across multiple projects to establish long -term trends.

• Examples:
○ Development time: Total time required to build the software.
○ Defect removal efficiency (DRE): Ratio of defects removed before release to total defects found.
○ Effectiveness of defect removal during development: Percentage of errors detected at each
development phase.
○ Process maturity level: Follows models like CMMI (Capability Maturity Model Integration).

3. Project Metrics
• These describe project characteristics and execution to help in tracking progress and ensuring efficient
project management.
• Project metrics are used for cost estimation, risk management, schedule tracking, and productivity
assessment.

• Examples:
○ Number of developers: Total workforce allocated to the project.
○ Staffing pattern: Human resource distribution over the project lifecycle.
○ Cost and schedule tracking: Estimated vs. actual effort and timeline adherence.
○ Productivity assessment: Output produced per developer per unit time.

Importance of Process Metrics

• Process metrics allow organizations to measure and improve software development efficiency.
• They provide quantitative indicators for process maturity, defect trends, and areas requiring optimization.

• Measurement steps:
○ Identify specific attributes of the process.
○ Derive meaningful metrics from these attributes.
○ Use these metrics to provide indicators.
○ Formulate improvement strategies based on the indicators.

Strategic Process Improvement & Error Analysis

• Focuses on achieving consistent quality through structured process improvements.

• Statistical Software Process Improvement (SSPI):

○ All defects and errors are categorized by their origin.
○ Cost per defect correction is recorded.
○ Data is analyzed to identify high-cost error categories.

Software Engenieering Page 30

 ○ Data is analyzed to identify high-cost error categories.
○ Process modifications are suggested to minimize future defects.

• Defect Removal Efficiency (DRE):

○ Measures how effectively errors are detected and corrected before release.
○ Formula: DRE = E / (E + D), where:
▪ E = Errors found before release.
▪ D = Defects reported by users after release.
○ Ideal DRE is 1, meaning all errors are detected before delivery.

• Key Process Outcome Metrics:

○ Number of errors uncovered before release.
○ Number of defects reported by users post-release.
○ Productivity levels (work products completed per unit effort).
○ Total human effort required for software development.
○ Adherence to schedule and budget.

Project Metrics for Software Management

• Role of project metrics:

○ Help managers track project progress, detect risks, and optimize resource allocation.
○ Used in software estimation techniques for cost, effort, and schedule prediction.
○ Metrics from past projects guide future project planning.

• How project metrics help:

○ Minimize development time by identifying potential delays.
○ Continuously assess product quality and modify approaches to improve it.
○ Compare actual effort and schedule with estimated values to monitor deviations.
○ Ensure efficient workflow adaptation by making data-driven decisions.

Common Project Metrics

• Effort per software engineering task: Time required for each development task.
• Errors uncovered per review hour: Measures the efficiency of code review and testing.
• Scheduled vs. actual milestone dates: Tracks adherence to planned timelines.
• Number of changes and their characteristics: Assesses the stability of requirements.
• Distribution of effort across tasks: Analyzes workload distribution and bottlenecks.

Product Metrics for Software Quality

• Product metrics assess the quality, maintainability, and efficiency of the software system.
• They provide measurable indicators of software design, development, and operational performance.

• Examples of product metrics:

○ Software complexity: Cyclomatic complexity, Halstead metrics.
○ Code size: Lines of Code (LOC), Function Points (FP).
○ Reliability: Mean Time Between Failures (MTBF).
○ Efficiency: CPU and memory usage.

• Direct vs. Indirect Measures:

○ Direct Measures: Easily quantifiable, such as LOC, execution speed, memory size, and defect count.
○ Indirect Measures: More abstract qualities like maintainability, usability, and reliability.

Software Engenieering Page 31

25 February 2025 15:24

The Organic, Semidetached, and Embedded modes are categories defined in the COCOMO
(Constructive Cost Model) for software development projects. These modes classify projects based on
complexity, size, and development environment.'

1. Organic Mode
• Definition: Suitable for small, simple, and well-understood projects developed by a small, cohesive
team.
• Characteristics:
○ Small team with good communication and experience.
○ Less formal development process.
○ Few constraints on requirements and technology.
○ Examples: Small business applications, simple web applications, utility programs.
2. Semidetached Mode
• Definition: Applies to medium-sized projects with a mix of experienced and less-experienced
developers.
• Characteristics:
○ More complex than organic projects but not highly critical.
○ Requires moderate planning, documentation, and formalization.
○ A mix of rigid and flexible development processes.
○ Examples: Information systems, transaction processing systems, database-driven applications.
3. Embedded Mode
• Definition: Used for large, complex, and highly constrained projects with strict requirements.
• Characteristics:
○ Requires high reliability, security, and strict adherence to standards.
○ Extensive documentation, rigorous testing, and quality control.
○ Developed in constrained environments (hardware/software dependencies).
Software Engenieering Page 32
○ Developed in constrained environments (hardware/software dependencies).
○ Examples: Real-time systems, avionics software, military applications, automotive control
systems.

Software Engenieering Page 33

Software Engenieering Page 34
Software Engenieering Page 35
SRS document IEEE
25 February 2025 15:30

Software Engenieering Page 36

Software Design iEEE
25 February 2025 15:42

Software Engenieering Page 37

25 February 2025 15:42

Coupling refers to the degree of interdependence between software modules. High coupling means that modules are
closely connected and changes in one module may affect other modules. Low coupling means that modules are
independent, and changes in one module have little impact on other modules.

Cohesion refers to the degree to which elements within a module work together to fulfill a single, well-defined
purpose. High cohesion means that elements are closely related and focused on a single purpose, while low cohesion
means that elements are loosely related and serve multiple purposes.

Software Engenieering Page 38

Both coupling and cohesion are important factors in determining the maintainability, scalability, and reliability of a
software system. High coupling and low cohesion can make a system difficult to change and test, while low coupling
and high cohesion make a system easier to maintain and improve.
Basically, design is a two-part iterative process. The first part is Conceptual Design which tells the customer what the
system will do. Second is Technical Design which allows the system builders to understand the actual hardware and
software needed to solve a customer’s problem.

Types of Coupling
1. Data Coupling – Modules share data through parameters without additional control information, ensuring
independence. Example: Customer billing system.

2. Stamp Coupling – Entire data structures are passed instead of specific elements, leading to unnecessary data
transfer.

3. Control Coupling – Modules communicate using control information, affecting behavior. Example: A sort function
receiving a comparison function as input.

4. External Coupling – Modules depend on external systems, files, or hardware. Example: Protocols, external file
formats.

5. Common Coupling – Multiple modules share global data, making changes difficult to track and maintain.

6. Content Coupling – One module modifies another’s data or controls its flow, reducing modularity and increasing
dependency.

Types of Cohesion
1. Functional Cohesion – A module performs a single, well-defined task. Example: A function calculating square root.

2. Sequential Cohesion – Output from one task becomes input for another. Example: Processing and then storing
customer details.

3. Communicational Cohesion – Elements use the same input data or contribute to the same output. Example: Database
update and printing.

4. Procedural Cohesion – Elements execute in a specific sequence but have weak connections. Example: Calculating and
printing GPA.

5. Temporal Cohesion – Tasks grouped by execution timing rather than functionality. Example: System initialization
tasks.

6. Logical Cohesion – Tasks are logically related but not functionally. Example: Reading inputs from different sources
(disk, network).

7. Coincidental Cohesion – Randomly grouped, unrelated tasks, reducing maintainability. Example: Printing and
reversing a string in one function.

Conceptual design answers :

Software Engenieering Page 39

 Conceptual design answers :
• Where will the data come from ?
• What will happen to data in the system?
• How will the system look to users?
• What choices will be offered to users?
• What is the timings of events?
• How will the reports & screens look like?
Technical design describes :
• Hardware configuration
• Software needs
• Communication interfaces
• I/O of the system
• Software architecture
• Network architecture
• Any other thing that translates the requirements in to a solution to the customer’s problem.

Bottom-Up Design

These modules are collected together in the form of a “library”.

Bottom-Up Design Model:

In this design, individual parts of the system are specified in detail. The parts are linked to form larger components, which are
in turn linked until a complete system is formed. Object-oriented language such as C++ or java uses a bottom-up approach
where each object is identified first.
Advantage:
• Make decisions about reusable low-level utilities then decide how there will be put together to create high-level construct. ,

Software Engenieering Page 40

 Top-Down Design Model:
• In the top-down model, an overview of the system is formulated without going into detail for any part of it. Each part of it then
refined into more details, defining it in yet more details until the entire specification is detailed enough to validate the model.
if we glance at a haul as a full, it’s going to appear not possible as a result of it’s so complicated For example: Writing a
University system program, writing a word processor. Complicated issues may be resolved victimization high down style,
conjointly referred to as Stepwise refinement where,

• We break the problem into parts,

• Then break the parts into parts soon and now each of parts will be easy to do.

Software Engenieering Page 41

25 February 2025 16:40

Use Case, Sequence ,Classs

for more:- http://www.programsformca.com/2012/03/

Software Engenieering Page 42

Software Engenieering Page 43
Software Engenieering Page 44
Software Engenieering Page 45
Software Engenieering Page 46
Software Engenieering Page 47
ER
25 February 2025 16:43

E-R Diagram
ER-Diagram is a visual representation of data that describes how data is related to each
other.

Symbols and Notations

Software Engenieering Page 48

Components of E-R Diagram
The E-R diagram has three main components.
1) Entity
An Entity can be any object, place, person or class. In E-R Diagram, an entity is represented
using rectangles. Consider an example of an Organisation. Employee, Manager, Department,
Product and many more can be taken as entities from an Organisation.

Weak Entity
Weak entity is an entity that depends on another entity. Weak entity doen't have key
attribute of their own. Double rectangle represents weak entity.

2) Attribute
An Attribute describes a property or characterstic of an entity. For example, Name, Age,
Address etc can be attributes of a Student. An attribute is represented using eclipse.

Key Attribute
Key attribute represents the main characterstic of an Entity. It is used to represent Primary
key. Ellipse with underlying lines represent Key Attribute.

Software Engenieering Page 49

Composite Attribute
An attribute can also have their own attributes. These attributes are known
as Composite attribute.

3) Relationship
A Relationship describes relations between entities. Relationship is represented using
diamonds.

There are three types of relationship that exist between Entities.

• Binary Relationship
• Recursive Relationship
• Ternary Relationship

Binary Relationship
Binary Relationship means relation between two Entities. This is further divided into three
types.
1. One to One : This type of relationship is rarely seen in real world.

The above example describes that one student can enroll only for one course and a
course will also have only one Student. This is not what you will usually see in
relationship.
2. One to Many : It reflects business rule that one entity is associated with many number
of same entity. For example, Student enrolls for only one Course but a Course can
have many Students.

Software Engenieering Page 50

 The arrows in the diagram describes that one student can enroll for only one course.
3. Many to Many :

The above diagram represents that many students can enroll for more than one
courses.

Recursive Relationship
When an Entity is related with itself it is known as Recursive Relationship.

Ternary Relationship
Relationship of degree three is called Ternary relationship.
Generalization
Generalization is a bottom-up approach in which two lower level entities combine to form a
higher level entity. In generalization, the higher level entity can also combine with other
lower level entity to make further higher level entity.

Specialization
Specialization is opposite to Generalization. It is a top-down approach in which one higher
level entity can be broken down into two lower level entity. In specialization, some higher
level entities may not have lower-level entity sets at all.

Software Engenieering Page 51

Aggregration
Aggregration is a process when relation between two entity is treated as a single entity.
Here the relation between Center and Course, is acting as an Entity in relation with Visitor.

Participation Constraint
Participation Constraint is applied to the entity participating in the
relationship set.
1. Total Participation – Each entity in the entity set must participate in the
relationship. If each student must enroll in a course, the participation of
students will be total. Total participation is shown by a double line in the ER
diagram.
2. Partial Participation – The entity in the entity set may or may NOT
participate in the relationship. If some courses are not enrolled by any of
the students, the participation in the course will be partial.

Software Engenieering Page 52

Software Engenieering Page 53
for more ER:- https://www.camillevleonard.com/CS_5012_ER_Diagram.html

Software Engenieering Page 54