1.

User Story/Case Study Based on Risk Management

Title: Implementing Risk Management in Software Development at ABC Corp
Background: ABC Corp, a mid-sized software development firm, experienced several project failures
due to unanticipated risks. This resulted in cost overruns, delays, and client dissatisfaction. To address
these issues, ABC Corp decided to implement a structured risk management process.
Challenges:
 High incidence of project failures
 Unpredictable cost and schedule deviations
 Poor visibility into potential project risks
Solution:
1. Risk Identification: The team conducted brainstorming sessions, expert interviews, and
historical data analysis to identify potential risks in their projects.
2. Risk Assessment: Each identified risk was assessed for its probability of occurrence and
potential impact using a risk matrix.
3. Risk Mitigation: Strategies such as avoidance, reduction, sharing, and acceptance were
developed to address each identified risk.
4. Risk Monitoring and Control: A risk management software tool was implemented to
continuously monitor and control risks throughout the project lifecycle.
5. Training: Project team members were trained on risk management techniques and the use of
the risk management tool.
Results:
 Reduction in project failure rates by 40%
 Improved adherence to project budgets and timelines
 Enhanced risk visibility and proactive management

2. Agile Manifesto / SDLC (Software Development Life Cycle)

Agile Manifesto:
 Individuals and Interactions over processes and tools
 Working Software over comprehensive documentation
 Customer Collaboration over contract negotiation
 Responding to Change over following a plan
Principles of Agile:
1. Customer satisfaction through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently, with a preference for shorter timescales.
4. Business people and developers must work together daily.
5. Build projects around motivated individuals and trust them to get the job done.
6. Face-to-face conversation is the most efficient and effective method of conveying information.
7. Working software is the primary measure of progress.
8. Maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design.
10.Simplicity is essential.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.Regular reflection on how to become more effective, then tune and adjust behavior accordingly.
SDLC Phases:
1
 1. Requirement Analysis: Gathering functional and non-functional requirements from
stakeholders to understand what the software should do.
2. Design: Creating architecture and design documents to plan how the software will be built.
3. Implementation: Writing and compiling code to build the software.
4. Testing: Verifying and validating that the software functions as expected and meets the
requirements.
5. Deployment: Releasing the software to production and making it available to users.
6. Maintenance: Providing ongoing support, fixing bugs, and making updates to improve or
adapt the software.

3. COCOMO Model (Constructive Cost Model)

Introduction: COCOMO is a procedural software cost estimation model developed by Barry Boehm.
It helps predict the effort, development time, and staffing required for software projects. COCOMO
has three models based on the nature and size of the project: Basic, Intermediate, and Advanced.
Modes in COCOMO:
1. Organic Mode: Small projects with small teams and experienced personnel. Flexible
requirements.
2. Semi-Detached Mode: Medium-sized projects with mixed experience levels. Somewhat
flexible requirements.
3. Embedded Mode: Large, complex projects with stringent requirements.
COCOMO Formulas:
 Effort (E): Effort in person-months (PM)
b
E=a × ( KLOC )
 Development Time (D): Time to develop the software in months
d
D=c × ( E )
 Staff Size (SS): Average staff size required
E
SS=
D
Values for Constants (a, b, c, d):
 Organic Mode: a=2.4 , b=1.05 , c=2.5 , d=0.38
 Semi-Detached Mode: a=3.0,b = 1.12,c = 2.5,d = 0.35
 Embedded Mode: a = 3.6, b=1.20,c = 2.5,d = 0.32
Example Calculation for a 200 KLOC Project in Semi-Detached Mode:
1. Effort (E):
1.12
E=3.0 × ( 200 ) ≈1008 Person-Months (PM)
2. Development Time (D):
0.35
D=2.5× ( 1008 ) ≈ 25.87 Months
3. Staff Size (SS):
1008
personsSS= ≈ 38.96 ≈ 39 persons
25.87

2
4. Short Notes:
 Agile Tools: Tools like JIRA, Trello, and Asana are used for task and sprint management in
Agile projects. These tools help track progress, manage tasks, and facilitate collaboration.
 Quality Matrix: A quality matrix is a tool used to measure and assess the quality of software.
It includes various metrics such as defect density, test coverage, and code churn to evaluate
different aspects of software quality.
 GitHub: GitHub is a web-based platform for version control and collaborative software
development using Git. It allows developers to manage code repositories, track changes, and
collaborate with others.
 Scrum Master: The Scrum Master is a role in Agile Scrum methodology responsible for
facilitating the Scrum process, removing impediments, and ensuring that the team adheres to
Agile principles and practices.
 MVP (Minimum Viable Product): An MVP is a version of a product with just enough
features to satisfy early users and provide feedback for future development. It helps validate
product ideas and guide further development.
 SCM (Software Configuration Management): SCM involves managing changes to software
artifacts such as source code, documentation, and configuration files. It ensures that changes
are tracked, versioned, and maintained to preserve the integrity and traceability of the software.
5. UML Diagrams:
 Class Diagram: A Class Diagram depicts the structure of a system by showing its classes,
attributes, methods, and relationships among objects. It helps in visualizing the system's static
structure.
 Use Case Diagram: A Use Case Diagram illustrates the interactions between users (actors) and
the system. It shows the use cases (functionalities) that the system provides and how users
interact with them.
 Activity Diagram: An Activity Diagram represents the workflow of activities in a system. It
shows the sequence of actions or steps and the flow of control from one activity to another.
 Sequence Diagram: A Sequence Diagram depicts the sequence of interactions between objects
in a system over time. It shows how objects interact with each other and the order of messages
exchanged.
 Package Diagram: A Package Diagram organizes elements of a system into packages. It
provides a higher-level view of the system by grouping related elements together.
6. SRS (Software Requirements Specification):
Example: Online Exam Form:
 Functional Requirements:
o User registration and login
o Course selection
o Display of exam questions
o Submission of exam answers
o Result generation and display
 Non-Functional Requirements:
o Performance: The system should handle multiple concurrent users.
o Security: User data should be encrypted and securely stored.
o Usability: The system should have an intuitive and user-friendly interface.

3
4
7. Risk Management, Product Backlog, Sprint Backlog:
 Risk Management: Risk Management involves identifying, assessing, and controlling risks
that could impact a project. It includes risk identification, risk assessment (probability and
impact), risk mitigation strategies, and risk monitoring.
 Product Backlog: The Product Backlog is a prioritized list of work items or features that need
to be developed for the product. It is managed by the Product Owner and serves as the source of
requirements for the development team.
 Sprint Backlog: The Sprint Backlog is a subset of the Product Backlog items selected for a
specific sprint. It includes the tasks and plan for delivering the selected items within the sprint.
8. Story Point Techniques:
 Planning Poker: A consensus-based estimation technique where team members use cards to
estimate the effort required for a user story.
 T-Shirt Sizing: A relative estimation technique where user stories are categorized into sizes
(XS, S, M, L, XL) based on their complexity and effort.
 Dot Voting: A technique where team members use dots to vote on the effort required for user
stories, helping to reach a consensus
9. SPM Life Cycle (Software Project Management):
 Initiation:
o Define the project scope, objectives, and stakeholders.
o Conduct feasibility studies and create a project charter.
 Planning:
o Develop a detailed project plan that includes timelines, resources, risk management
strategies, and communication plans.
o Define project deliverables and milestones.
 Execution:
o Carry out the project plan by executing the defined tasks.
o Coordinate team efforts, manage resources, and ensure project activities are on track.
 Monitoring and Controlling:
o Track project performance using KPIs (Key Performance Indicators).
o Implement change control processes to manage deviations from the plan.
o Regularly review progress and make adjustments as necessary.
 Closing:
o Finalize all project activities and ensure all project deliverables are completed.
o Conduct a project review to identify lessons learned and best practices for future
projects.
o Release project resources and formally close the project.

5
10. Spiral Model:
The Spiral Model is a risk-driven software development process model that combines elements of
both iterative and waterfall models. It allows for iterative development and refinement of a system
through continuous risk assessment and mitigation.
Phases:
1. Planning:
o Identify objectives, alternatives, and constraints for the iteration.
o Determine the project's overall goals and the specific goals for the current iteration.
2. Risk Analysis:
o Identify and analyze potential risks.
o Develop risk mitigation strategies.
3. Engineering:
o Develop and test the system incrementally.
o Implement the solutions for identified risks and refine system functionality.
4. Evaluation:
o Evaluate the developed system against project objectives.
o Review and assess progress, and plan for the next iteration.
The spiral model emphasizes continuous risk assessment, allowing teams to address risks early and
iteratively refine the system.
11. Functional vs. Non-Functional Requirements:
 Functional Requirements:
o Define what the system should do.
o Describe specific behaviors, functionalities, or operations of the system.
o Example: The system shall allow users to log in using their email and password.
 Non-Functional Requirements:
o Define how the system performs its functions.
o Describe the quality attributes, performance, usability, and constraints of the system.
o Example: The system shall handle up to 10,000 concurrent users with a response time of
less than 2 seconds.
12. Challenges in Project Management:
1. Scope Creep:
o Uncontrolled changes or continuous growth in a project's scope.
o Leads to project delays, cost overruns, and resource allocation issues.
2. Budget Overruns:
o Exceeding the allocated budget for a project.
o Caused by poor cost estimation, unexpected expenses, or scope changes.
3. Time Management:
o Difficulty in meeting project deadlines.
o Often due to unrealistic timelines, poor scheduling, or resource constraints.
4. Risk Management:
o Identifying, assessing, and mitigating project risks.
o Failure to manage risks can lead to project failures or significant setbacks.
5. Communication Issues:
o Ineffective communication among stakeholders, team members, and clients.

6
 o Leads to misunderstandings, misaligned expectations, and delays
1. Prototyping Model Reduced Risk of Failure: Issues are identified and
Prototyping Model: The Prototyping Model is an resolved early in the development process.
iterative, trial-and-error approach used in software Limitations:
development where a prototype (an early Time-Consuming: Iterative refinement can be time-
approximation of the final product) is built, tested, consuming.
and then reworked until an acceptable prototype is Scope Creep: Continuous changes and
achieved. This model is especially useful when improvements may lead to scope creep.
requirements are not well understood at the Higher Costs: The repeated design, development,
beginning. and testing cycles can increase costs.
Key Phases: 2. Spiral Model
Requirement Gathering and Analysis: Spiral Model: The Spiral Model is a risk-driven
Initial requirements are gathered from stakeholders. software development model that combines
These requirements are often incomplete or iterative development with systematic risk
unclear. management. It emphasizes the need to go through
Quick Design: multiple iterations (or spirals) of development, with
A preliminary design is created, focusing on user each spiral addressing a different aspect of the
interface and input/output formats. product and managing associated risks.
The goal is to develop a quick and simple version Key Phases:
of the system. Planning:
Building the Prototype: Initial planning phase involves identifying
The initial prototype is built based on the quick objectives, constraints, and alternatives.
design. Establishes the foundation for subsequent spirals.
This prototype is not complete or fully functional Risk Analysis:
but includes key elements to provide a feel for the Each spiral involves a thorough risk analysis.
system. Potential risks are identified, assessed, and
User Evaluation: mitigated through prototypes, simulations, and
Users interact with the prototype to provide other means.
feedback. Engineering:
Their feedback focuses on usability, functionality, Development and testing of the product take place
and design. during this phase.
Refining the Prototype: Includes coding, unit testing, integration testing,
Based on user feedback, the prototype is refined. and system testing.
This cycle of user feedback and refinement Evaluation:
continues until the prototype meets the users' needs The product is evaluated by stakeholders.
and expectations. Feedback is collected to refine and improve the
Developing the Final Product: system in the next spiral.
The final system is developed based on the refined Advantages:
prototype. Risk Management: Continuous risk assessment
Rigorous testing and validation are performed and mitigation reduce the likelihood of project
before deployment. failure.
Advantages: Flexibility: Accommodates changes and
Better User Involvement: Users are actively improvements at each iteration.
involved, leading to a product that better meets Incremental Development: Allows for incremental
their needs. releases and early delivery of working software.
Improved Requirement Clarity: Ambiguous or Limitations:
unclear requirements are discovered and clarified
through the prototype.
7
Complexity: Can be complex to manage, especially Expertise Required: Effective risk management
for large projects. requires skilled and experienced personnel.
High Costs: The iterative nature and thorough risk
analysis can lead to higher costs.
3. IEEE SRS Format
IEEE SRS Format: The IEEE Software Requirements Specification (SRS) format is a standardized
structure for documenting software requirements, ensuring clarity, completeness, and consistency. It is
widely used to facilitate communication among stakeholders and provide a clear understanding of the
software to be developed.
Key Sections:
Introduction:
Purpose: Defines the purpose of the SRS document.
Scope: Describes the scope of the software, including objectives and goals.
Definitions, Acronyms, and Abbreviations: Lists and explains the terms and acronyms used in the
document.
References: Lists reference materials and documents used in preparing the SRS.
Overview: Provides an overview of the document structure and contents.
Overall Description:
Product Perspective: Provides context and background of the product.
Product Functions: Summarizes the major functionalities of the software.
User Characteristics: Identifies the characteristics of the intended users.
Constraints: Lists constraints such as regulatory requirements, hardware limitations, and others.
Assumptions and Dependencies: States assumptions made during the requirement gathering process
and dependencies on other projects or systems.
Specific Requirements:
Functional Requirements: Detailed descriptions of the specific functionalities the software must
provide.
External Interface Requirements: Describes how the software will interact with other systems,
hardware, and users.
System Features: Lists and describes each feature of the system, including inputs, outputs, and
processing.
Non-Functional Requirements: Defines system attributes such as performance, security, reliability,
and usability.
Appendices:
Glossary: Defines key terms used in the SRS.
References: Provides additional references and resources.
Index: An alphabetical index for easy reference to key terms and sections.
Advantages:
Clarity and Consistency: Provides a clear and consistent structure for documenting requirements.
Facilitates Communication: Ensures all stakeholders have a common understanding of the software
requirements.
Comprehensive Documentation: Covers all aspects of the software, including functional and non-
functional requirements.
8
Limitations:
Time-Consuming: Creating a detailed SRS can be time-consuming.
Requires Expertise: Requires a thorough understanding of both the domain and the software
development process.
1) Interaction
Interaction: In software engineering, an interaction refers to the communication and data exchange between
different objects, components, or systems within a software application. Interaction modeling helps visualize how
various parts of the system collaborate to perform specific functions and achieve overall system behavior.
Types of Interaction Diagrams:
Sequence Diagram:
Definition: A sequence diagram shows the sequence of messages exchanged between objects to carry out a
particular function or process.
Components:
Actors: Represent external entities interacting with the system.
Objects: Represent instances of classes or components.
Lifelines: Vertical dashed lines that represent the existence of an object over time.
Messages: Horizontal arrows indicating communication between objects.
Communication Diagram:
Definition: A communication diagram (formerly known as a collaboration diagram) emphasizes the structural
organization of objects that send and receive messages.
Components:
Actors: External entities interacting with the system.
Objects: Instances of classes or components.
Links: Lines connecting objects to indicate relationships.
Messages: Labeled arrows indicating the flow of communication.
Uses of Interaction Diagrams:
Behavior Modeling: Capture how objects interact to fulfill a use case or business process.
Sequence and Timing: Understand the order and timing of message exchanges.
Debugging and Maintenance: Visualize interactions for identifying bugs and optimizing processes.
Design and Documentation: Document the dynamic behavior of the system for better design and communication
among stakeholders.
2) SwimLanes
SwimLanes: SwimLanes are a feature in activity diagrams used to organize and visualize the activities performed
by different actors, departments, or system components. Each SwimLane represents a participant in the process,
clearly showing responsibilities and the flow of control between different actors.
Key Components:
SwimLanes: Horizontal or vertical partitions in an activity diagram, each representing a specific actor or
department.
Activities: Actions or steps performed by the actors.
Transitions: Arrows indicating the flow of control from one activity to another.
Start/End Points: Indicate the beginning and end of the process.
Uses of SwimLanes:
Clarify Responsibilities: Show which actor or department is responsible for each activity.
Improve Process Understanding: Visualize the entire process, making it easier to understand.
Identify Inefficiencies: Highlight bottlenecks and areas for improvement in the process.

9
1. Slack Time
Slack Time: Slack time, also known as float, is the amount of time that a task in a project schedule can be delayed
without causing a delay to subsequent tasks or the project's overall completion date. It is a crucial aspect of project
management as it helps identify the flexibility within the project schedule and allows project managers to manage
resources effectively.
Calculation:
Total Slack: The difference between the latest start time and the earliest start time, or the latest finish time and the
earliest finish time.
Free Slack: The amount of time a task can be delayed without affecting the early start of any subsequent tasks.
Importance:
Helps identify critical and non-critical tasks.
Allows for better resource allocation.
Provides a buffer for unforeseen delays.
2. Earliest Start Time and Late Start Time
Earliest Start Time (EST): The earliest time a task can begin without any delay, considering the project's timeline
and dependency constraints. It is determined by the earliest time that all preceding tasks are completed.
Late Start Time (LST): The latest time a task can start without delaying the project's overall completion. It is
calculated by working backward from the project's end date and considering the dependencies.
Importance:
Helps in planning and scheduling tasks.
Identifies tasks that have flexibility in their start times.
Aids in optimizing the project schedule.
3. Latest Finish and Earliest Finish Time
Latest Finish Time (LFT): The latest time a task can be completed without delaying the overall project
completion. It is determined by working backward from the project's final deadline, considering the dependencies.
Earliest Finish Time (EFT): The earliest time a task can be completed, considering its earliest start time and
duration. It is calculated by adding the task's duration to its earliest start time.
Importance:
Helps in identifying the critical path of the project.
Allows project managers to ensure tasks are completed on time.
Provides a clear timeline for task completion.
4. Software Quality
Software Quality: Software quality refers to the degree to which a software product meets the specified
requirements and satisfies the needs of its users. High-quality software is essential for user satisfaction, reducing
maintenance costs, and improving overall performance.
Attributes of Software Quality:
Functionality: The ability of the software to provide the required functions and features.
Reliability: The consistency of the software in performing its functions without failures.
Usability: The ease with which users can interact with the software.
Efficiency: The software's performance in terms of resource usage and response time.
Maintainability: The ease with which the software can be modified to correct defects or implement changes.
Portability: The ability of the software to be used in different environments.
5. Process and Activity
Process: A process is a set of interrelated or interacting activities that transform inputs into outputs. In software
engineering, a process defines the sequence of steps to develop and maintain software.
Activity: An activity is a specific task or set of tasks that are part of a process. Activities are the building blocks of
a process, each contributing to the overall goal.
Importance:
Processes: Provide a structured approach to software development.
Activities: Ensure that each step of the process is executed correctly and efficiently.
10
 6. Software Size Estimation Techniques
Software Size Estimation Techniques: These techniques are used to estimate the size and complexity of a
software project, which is crucial for planning, scheduling, and resource allocation. Accurate size estimation helps
in predicting project costs and timelines.
Common Techniques:
Lines of Code (LOC): Counting the number of lines in the source code.
Advantages: Simple and straightforward.
Limitations: Language-dependent, not indicative of complexity.
Function Points (FP): Measuring functionality provided to the user based on inputs, outputs, user interactions,
files, and interfaces.
Advantages: Language-independent, considers user perspective.
Limitations: Requires detailed requirements.
Use Case Points (UCP): Estimating size based on use cases in the system.
Advantages: Incorporates user interactions.
Limitations: Requires well-defined use cases.
7. Domain Values in FPA
Domain Values in FPA (Function Point Analysis): Function Point Analysis (FPA) is a technique used to
measure the functional size of a software application. It evaluates the functionality provided to the user, measured
in function points (FP).
Key Components: Importance:
Inputs: Data entering the system. Provides a standardized method for measuring
Outputs: Data leaving the system. software size.
User Interactions: User interface elements. Helps in comparing and estimating different software
Files: Internal and external files used by the system. projects.
Interfaces: Connections to other systems. Facilitates better planning and resource allocation.

6. Product Backlog Report

Product Backlog Report: A product backlog report provides an overview of all the user stories, features,
enhancements, and bug fixes that need to be addressed for the product. It is maintained by the product owner and
prioritized based on business value, customer needs, and project goals.
Components:
User Stories: Descriptions of features from the user's perspective.
Prioritization: Each item is prioritized to ensure the most valuable features are developed first.
Estimates: Effort estimates for each user story.
Purpose:
 Planning: Helps the team understand the remaining work and plan for upcoming sprints.
 Communication: Provides visibility into the project’s progress and priorities for stakeholders.
 Prioritization: Ensures that the team focuses on delivering the most valuable features first.

11
1. Swim Lane
Swim Lane: A swim lane is a visual element used in process flow diagrams or activity diagrams to distinguish
responsibilities and separate tasks based on who is responsible for them. Each swim lane represents a specific
actor, team, or department, helping to clarify roles and responsibilities within the process.
Uses:
 Clarification: Swim lanes make it clear which actor or team is responsible for each step in a process.
 Efficiency: By clearly defining responsibilities, swim lanes help identify bottlenecks and inefficiencies.
 Communication: They improve communication by providing a clear and visual representation of workflows
and processes.
Example in a Process Flow:
Imagine a software development process with three swim lanes: Development Team, QA Team, and Deployment
Team. Tasks such as coding, testing, and deployment are placed in the corresponding swim lanes, making it easy
to see who is responsible for what.
3. Sprint Backlog
Sprint Backlog: The sprint backlog is a list of tasks, user stories, and work items that the development team
commits to completing during a sprint. It is derived from the product backlog and represents a subset of the
product backlog items.
Components:
 User Stories: Detailed descriptions of the functionality to be developed.
 Tasks: Specific activities needed to complete the user stories.
 Estimates: Time or effort estimates for each task.
Creation:
The sprint backlog is created during the sprint planning meeting and includes all the tasks necessary to achieve the
sprint goal. It is a living document that can be updated as work progresses.
4. Version Control
Version Control: Version control is a system that records changes to a file or set of files over time so that specific
versions can be recalled later. It enables multiple developers to collaborate on a project, track changes, and manage
revisions.
Types of Version Control:
 Centralized Version Control Systems (CVCS): A single central repository that all developers commit to
(e.g., Subversion, CVS).
 Distributed Version Control Systems (DVCS): Every developer has a local copy of the entire repository
(e.g., Git, Mercurial).
Benefits:
 Collaboration: Allows multiple developers to work on the same project simultaneously without conflicts.
 Tracking: Maintains a history of changes, making it easy to track and revert changes if necessary.
 Branching: Supports branching and merging, allowing developers to work on new features or fixes in
isolation.
5. Agile Project Life Cycle
Agile Project Life Cycle: The Agile project life cycle consists of several iterative phases that focus on delivering
small, incremental improvements to the product. The typical phases include:
1. Initiation:
o Define the project goals, scope, and stakeholders.
o Develop a high-level project plan and initial product backlog.
2. Planning:
o Create a detailed plan for the first iteration (sprint).
o Prioritize user stories and tasks in the product backlog.
3. Execution:
o Conduct multiple sprints or iterations, each involving planning, development, testing, and review.
12
o Daily stand-up meetings to track progress and resolve issues.
4. Monitoring and Controlling:
o Track progress, manage changes, and ensure alignment with project goals.
o Use metrics like velocity and burndown charts to monitor performance.
5. Closing:
o Finalize the project, obtain stakeholder approval, and conduct a retrospective to identify lessons learned.
o Release the final product increment to the customer
5.)…..
1. Commit Command
Commit Command: The git commit command is a fundamental part of Git version control. It is used to save
changes to the local repository by capturing a snapshot of the current state of the project, including all staged
changes. Each commit creates a unique record of what was added, removed, or modified in the project since the
last commit.
Detailed Explanation:
 Staging Area: Before committing, changes must be added to the staging area (also called the index) using the
git add command. This allows you to selectively choose which changes to include in the next commit.
bash
git add <file1> <file2> # Stage specific files
git add . # Stage all changes in the current directory
 Commit Message: A commit message is mandatory and should be descriptive enough to explain the purpose
of the changes. Good commit messages help in understanding the project's history and make collaboration
easier.
bash
git commit -m "Fixed bug in user authentication logic"
 Amending Commits: If you need to modify the most recent commit, you can use the --amend flag. This is
useful for correcting mistakes or updating the commit message.
bash
git commit --amend -m "Updated commit message with more details"
 Commit History: Each commit is recorded in the repository's history with a unique SHA-1 hash. You can
view the commit history using the git log command.
bash
git log
 Example Workflow:
1. Make changes to files in your working directory.
2. Stage the changes using git add.
3. Commit the changes with a meaningful message using git commit.
Importance of Commits:
 Tracking Progress: Commits provide a detailed history of changes, making it easier to track progress and
understand what was done and why.
 Reverting Changes: If a mistake is made, commits allow you to revert to a previous state of the project.
 Collaboration: Commits make it possible for multiple developers to work on the same project without
overwriting each other's changes.

13