Lab 08

Name: Muhammad Hassan Irshad

Roll no: 22-CS-26
Subject: Software Engineering
Date: 16-Dec- 24
Question No 01 What is SCRUM in Software Engineering ?
Scrum is an Agile framework used for developing, delivering, and sustaining complex products. It is especially popular in
software development for its focus on iterative progress, flexibility, and team collaboration. Scrum emphasizes adaptive
planning, evolutionary development, early delivery, and continuous improvement, which helps teams deliver products
incrementally and adapt quickly to changing requirements.
Here's a detailed breakdown of Scrum in software engineering:
1. Core Concepts of Scrum
 Iterative Development: Scrum divides work into small, manageable cycles called "sprints," which are
typically two to four weeks long. At the end of each sprint, a potentially shippable product increment is
delivered, reviewed, and refined.
 Empirical Process Control: Scrum is based on transparency, inspection, and adaptation:
o Transparency: All aspects of the process are visible to those responsible for the outcome.
o Inspection: Scrum teams regularly inspect their work and processes to detect variances.
o Adaptation: Based on the results of inspections, adjustments are made to optimize the outcome.
2. Scrum Team Roles
Scrum teams are cross-functional and usually consist of three key roles:
 Product Owner:
o Responsible for maximizing the value of the product and managing the Product Backlog, which
is a prioritized list of features, enhancements, and fixes.
o Defines and prioritizes the work that the team should focus on, based on customer needs and
business goals.
o Acts as the primary link between the team and the stakeholders.
 Scrum Master:
o Acts as a facilitator and coach, ensuring that the Scrum framework is followed and helping to
remove any impediments that may block the team's progress.
o Supports the Product Owner, helps the team stay focused, and ensures that the Scrum process
runs smoothly.
o Fosters a collaborative, supportive environment and addresses team conflicts if they arise.
 Development Team:
o Consists of professionals who work together to deliver the product increment each sprint. This
includes developers, testers, designers, and anyone else necessary to build the product.
o The team is self-organizing, meaning they decide internally how best to accomplish the work.
o Typically, Scrum teams are small (about 3-9 people) to maintain effective communication and
agility.
3. Scrum Artifacts
Artifacts in Scrum provide transparency and key information that helps the team and stakeholders stay aligned
and understand what work needs to be done, what has been completed, and what the team is currently working
on.
o A prioritized list of all the work items or requirements for the project, managed by the Product
Owner.
o Contains user stories, bug fixes, enhancements, and tasks needed to deliver the product.
o Continuously refined and adjusted as new information becomes available.
  Sprint Backlog:
o A subset of the Product Backlog that the team selects for completion in the upcoming sprint.
o It includes the tasks and subtasks necessary to complete the items selected, with each team
member working on specific items.
o Owned and managed by the Development Team, with items typically broken down into
actionable tasks.
 Increment:
o A working version of the product that incorporates all completed Product Backlog items from the
current and previous sprints.
o Each increment must be a potentially shippable product that meets the "Definition of Done,"
ensuring consistent quality.
4. Scrum Events
Scrum uses five key events to create regular opportunities for the team to inspect and adapt its processes and
work.
 Sprint:
o The core work cycle in Scrum, usually lasting two to four weeks. Each sprint begins with
planning and ends with a review and retrospective.
o During the sprint, no changes are made that would endanger the Sprint Goal, which is the main
objective the team commits to achieving.
 Sprint Planning:
o A meeting at the beginning of each sprint where the Product Owner and Development Team
discuss the Product Backlog items that should be included in the Sprint Backlog.
o The team selects work based on its capacity and collaborates to define a clear Sprint Goal.
 Daily Scrum (Stand-up):
o A short, time-boxed daily meeting (typically 15 minutes) where the team shares progress, plans
for the day, and discusses any impediments.
o The goal is to synchronize activities and ensure the team is aligned on achieving the Sprint Goal.
 Sprint Review:
o Held at the end of each sprint, this is a meeting where the team demonstrates the increment (the
completed work) to stakeholders and gathers feedback.
o The Product Owner assesses whether to release the increment or make further adjustments based
on feedback.
 Sprint Retrospective:
o A team-only meeting held after the Sprint Review where team members reflect on what went
well, what didn’t, and what could be improved.
o Actionable items are identified to improve processes or teamwork, which the team will
implement in future sprints.
5. Scrum Artifacts Transparency
Scrum requires that all artifacts be transparent so that everyone has a clear understanding of their state and
value. This transparency enables better inspection and adaptation.
 Definition of Done (DoD):
o A shared understanding within the team of what makes a product increment "done" or complete.
It ensures all team members deliver consistent quality and that the increment meets specific
standards.
o This may include coding standards, testing requirements, documentation needs, or any other
quality metrics.
6. Scrum Workflow and Lifecycle
Scrum is structured but flexible, emphasizing iterative progress and continuous improvement. The general
workflow of a Scrum lifecycle includes:
1. Product Backlog Creation: Initial requirements and feature lists are gathered in the Product Backlog.
2. Sprint Planning: The team selects a portion of the backlog to complete in the sprint.
 3. Execution: The Development Team works on the Sprint Backlog items, attending Daily Stand-ups and
collaborating as needed.
4. Sprint Review and Demonstration: The increment is demonstrated to the Product Owner and
stakeholders for feedback.
5. Sprint Retrospective: The team reflects on process improvements.
6. Iteration: After retrospective, the team moves into the next sprint.
7. Advantages of Scrum
 Increased Flexibility and Adaptability: Since Scrum is iterative, it allows for flexibility in changing
requirements and adapting to customer feedback.
 Higher Quality Deliverables: Continuous testing and feedback cycles result in higher-quality software,
as issues are caught early and frequently.
 Greater Team Collaboration and Ownership: The Development Team has more control over how
they work, fostering greater team ownership and accountability.
 Faster Delivery of Features: With short, time-boxed sprints, Scrum enables frequent delivery of
working features to stakeholders.
8. Challenges of Scrum
 Requirement of Skilled Teams: Scrum requires a team skilled in Agile practices and self-organization,
which can be challenging for teams transitioning from traditional models.
 Potential for Scope Creep: If the Product Backlog is not well managed, it can lead to scope creep, with
new requirements frequently added, making it difficult to complete work in a sprint.
 High Commitment Requirement: Scrum demands commitment and active participation from both
team members and stakeholders, which can be hard to maintain consistently.
 Focus on Collaboration Over Documentation: While collaboration is emphasized, if documentation is
neglected, it can be problematic for knowledge transfer, especially if team members change frequently.
Question No 02: Describe ERD in detail?
An Entity-Relationship Diagram (ERD) is a visual representation of the data and relationships within a system,
often used in database design. In software engineering, ERDs play a key role in modeling the structure and
organization of data and defining how different entities relate to each other. ERDs are particularly important in
the planning and design phases of database systems and can simplify communication between developers,
stakeholders, and database architects.
Here’s a detailed overview of ERDs in software engineering:
1. Purpose of an ERD
 Data Modeling: ERDs visually represent the data model of a system, making it easier to understand the
structure, key entities, attributes, and relationships within a database.
 Database Design: ERDs serve as blueprints for constructing a database. They help database designers
decide how to organize data effectively, avoiding redundancy and improving efficiency.
 Communication Tool: ERDs act as a bridge between business stakeholders and technical teams,
enabling clear communication of database requirements and structure.
2. Components of an ERD
ERDs are composed of three main elements: entities, attributes, and relationships.
 Entities:
o An entity is a distinct object or concept in the database that has a real-world meaning. It can be
something tangible, like Customer, Product, or Employee, or an abstract concept like Order or Invoice.
o Each entity is represented as a rectangle in the ERD and has a unique name.
o In a database, entities typically map to tables, with each instance of an entity corresponding to a
row in the table.
 Attributes:
o Attributes are the data elements that describe properties of an entity. For example, a Customer
entity might have attributes like CustomerID, Name, Email, and Phone.
o Attributes are represented as ovals connected to their respective entities.
o Primary keys and foreign keys are key types of attributes.
 Relationships:
 o Relationships define how two or more entities are connected. For example, an Order entity might
be related to a Customer entity, meaning that a customer places an order.
o Relationships are typically represented as diamonds or lines connecting entities. They have
labels describing the type of relationship, such as "has," "contains," or "belongs to."
3. Types of ERD Notations
There are several notations used in ERDs to represent entities, attributes, and relationships, including:
 Chen Notation:
o In this traditional notation, entities are rectangles, relationships are diamonds, and attributes are
ovals.
o Chen notation is highly descriptive and is useful for communicating conceptual models.
 Crow’s Foot Notation:
o This is one of the most common notations, especially for relational database design. It uses lines
and symbols to indicate relationships.
o Crow’s Foot notation is preferred for its simplicity and clarity, especially in representing
cardinality.
 UML Notation:
o The Unified Modeling Language (UML) notation is often used in object-oriented database
designs.
o It represents entities as classes and relationships as associations.
Creating an ERD typically involves several steps:
1. Identify Entities: Determine the main objects or concepts involved in the system, such as Customer,
Order, and Product.
2. Define Relationships: Define how these entities interact or relate to each other (e.g., "Customer places
Order").
3. Assign Attributes: Identify the relevant properties for each entity, and assign primary and foreign keys.
4. Determine Cardinality and Modality: Define the cardinality (1:1, 1
,M
) and modality (mandatory or optional) of each relationship.
5. Refine and Review: Iterate on the diagram, adding or modifying details based on additional
requirements or feedback.
6. ERD Example
Here’s a simplified example of an ERD for an e-commerce system:
 Entities:
o Customer with attributes CustomerID, Name, and Email.
o Order with attributes OrderID, OrderDate, and TotalAmount.
o Product with attributes ProductID, ProductName, and Price.
o OrderDetail with attributes OrderDetailID, Quantity, and Subtotal.
 Relationships:
o Customer and Order have a 1
relationship, meaning each customer can place multiple orders, but each order is associated with
only one customer.
o Order and Product have an M
relationship, as each order can contain multiple products, and each product can be in multiple
orders. This is usually resolved through a junction table (like OrderDetail), which includes OrderID
and ProductID as foreign keys.
 Improved Communication: ERDs make complex database structures more understandable for non-
technical stakeholders.
 Efficient Database Design: ERDs provide a clear structure, helping avoid redundancy and ensuring
data integrity.
 Error Detection: ERDs can help detect inconsistencies, missing relationships, and other design flaws
early in the database design process.