Of course!

Here are 10 more new and important questions, with concise answers
suitable for a 5-mark evaluation.

1. What are the key challenges faced in modern software

engineering? (5 Marks)

Answer:

Modern software engineering faces several significant challenges driven by

evolving technology and user expectations:

●​ Legacy System Challenge: Many organizations rely on older (legacy)

systems that are difficult and expensive to maintain and update. Integrating
these systems with modern technology without disrupting business
operations is a major hurdle.
●​ Heterogeneity Challenge: Modern software must often operate across a
wide range of devices, platforms, and networks (e.g., desktops, mobile,
cloud). Ensuring consistent performance, security, and user experience
across these heterogeneous environments is complex.
●​ Delivery and Time-to-Market Challenge: Businesses operate in a highly
competitive environment where speed is critical. There is immense
pressure to deliver high-quality software faster than ever before, leading to
the adoption of Agile and DevOps practices to shorten development
cycles.
●​ Trust and Security Challenge: As software becomes more integral to
society (e.g., in finance, healthcare), ensuring its security and
trustworthiness is paramount. Software must be resilient to cyber-attacks
and protect sensitive user data, which is a constantly evolving challenge.
●​ Scale and Complexity Challenge: Today's systems are often developed
at a massive scale (e.g., large-scale distributed systems, big data
applications). Managing the inherent complexity, ensuring scalability, and
maintaining performance are significant engineering challenges.
2. Differentiate between <<include>> and <<extend>> relationships
in a Use Case diagram with an example. (5 Marks)

Answer:

In UML Use Case diagrams, both <<include>> and <<extend>> are

relationships that show dependencies between use cases, but they serve
different purposes.

<<include>> Relationship:

●​ Purpose: It specifies that one use case (the base) must incorporate the
functionality of another use case (the inclusion). The included use case is
mandatory for the completion of the base use case.
●​ Analogy: Think of it as a function call. The base use case is "incomplete"
without the included one.
●​ Notation: A dashed arrow from the base use case to the included use
case, stereotyped as <<include>>.
●​ Example: For an online bank transaction, both Transfer Funds and
Pay Bill use cases would <<include>> a User Authentication
use case. You cannot perform either action without first authenticating.

(Diagram: A simple diagram showing Transfer Funds -> <<include>> ->

User Authentication would be effective.)

<<extend>> Relationship:

●​ Purpose: It specifies that one use case (the extending) provides optional
functionality that may be added to another use case (the extended) under
certain conditions.
●​ Analogy: Think of it as an optional feature or a conditional branch. The
base use case is complete on its own.
●​ Notation: A dashed arrow from the extending use case to the extended
use case, stereotyped as <<extend>>.
●​ Example: A Login use case could be <<extend>>ed by a Show
"Forgot Password" option use case. This option is only relevant if
the user fails to log in multiple times; the basic login functionality is
complete without it.
(Diagram: A diagram showing Show "Forgot Password" option ->
<<extend>> -> Login would be effective.)

3. Explain the purpose and main components of a Sequence Diagram.

(5 Marks)

Answer:

Purpose: A Sequence Diagram is a UML interaction diagram that models how

objects collaborate in a specific scenario. It emphasizes the time ordering of
messages exchanged between objects. It is excellent for visualizing the
step-by-step logic of a particular use case or operation, making it easy to
understand the dynamic behavior of a system.

Main Components:

1.​ Object/Lifeline: Represents an individual object participating in the

interaction. It is shown as a rectangle at the top with a dashed vertical line
(the lifeline) extending downwards.
○​ Notation: objectName:ClassName
2.​ Activation Bar (Execution Specification): A thin rectangle on a lifeline
that shows the period during which an object is performing an action, either
directly or by delegating to other objects.
3.​ Message: Represents the communication between objects. Messages are
shown as arrows between lifelines.
○​ Synchronous Message: A call where the sender waits for the
receiver to finish processing before continuing. (Notation: Solid line
with a filled arrowhead).
○​ Asynchronous Message: A call where the sender does not wait for
the receiver to finish. (Notation: Solid line with a open line
arrowhead).
○​ Reply/Return Message: A message showing the return of a value
from the receiver to the sender. (Notation: Dashed line with an open
line arrowhead).
 4.​ Self-Message: A message that an object sends to itself, indicating a call to
another of its own methods. (Notation: An arrow starting and ending on the
same lifeline).

4. What is Software Configuration Management (SCM)? Explain its

four main activities. (5 Marks)

Answer:

Software Configuration Management (SCM) is the process of identifying,

organizing, and controlling modifications to the software and related artifacts
being built by a development team. Its primary goal is to manage change and
maintain the integrity and traceability of the software product throughout its
lifecycle, thereby preventing confusion and errors.

The four main activities of SCM are:

1.​ Version Control: This is the process of managing changes to documents,

programs, and other collections of information. It allows developers to track
different versions of files and revert to previous versions if necessary.
Systems like Git are used for this.​

2.​ Change Control: This is a formal process for requesting, evaluating,

approving, and implementing changes to baselined configuration items. It
ensures that changes are made in a structured way and prevents
unauthorized or chaotic modifications. A Change Control Board (CCB)
often oversees this process.​

3.​ Configuration Auditing: This involves verifying that the software product
is built according to the requirements and configuration information defined
in the baseline. It ensures that what is documented is what has been built,
checking for completeness and correctness.​

4.​ Status Accounting (or Reporting): This is the activity of recording and
reporting the status of configuration items and any proposed changes. It
answers questions like, "What is the status of a specific change request?"
 or "What components were changed in a particular release?"​

5. Explain software quality metrics, giving one example each for a

process, product, and project metric. (5 Marks)

Answer:

Software quality metrics are quantitative measurements used to assess,

control, and improve the quality of the software product and the development
process. They provide insights into the health, efficiency, and effectiveness of a
project. They are categorized into three types:

1.​ Process Metrics: These metrics are used to measure the characteristics
of the software development process itself. The goal is to improve the
efficiency and effectiveness of the process over time.​

○​ Example: Defect Removal Efficiency (DRE). This metric measures

the effectiveness of the testing process. It is calculated as:
DRE=Defects found before release + Defects found after
releaseDefects found before release​A higher DRE indicates a more
effective quality assurance process.
2.​ Product Metrics: These metrics measure the characteristics of the
software product itself, such as its size, complexity, and quality attributes.​

○​ Example: Defect Density. This metric measures the number of

defects found in the software relative to its size. It is calculated as:
DefectDensity=Size of the software (e.g., in KLOC or Function
Points)Total number of defects​A lower defect density generally
indicates higher product quality.
3.​ Project Metrics: These metrics describe the characteristics and execution
of the project, such as cost, schedule, and team productivity. They are
used by project managers to monitor and control the project.​

○​ Example: Schedule Variance (SV). This metric measures whether

a project is ahead of or behind schedule. It is calculated as:
SV=Budgeted Cost of Work Performed (BCWP) - Budgeted Cost of
 Work Scheduled (BCWS) A positive SV means the project is ahead
of schedule.

6. Compare Agile Project Management with Traditional Project

Management on five key points. (5 Marks)

Answer:

Feature Agile Project Management Traditional Project

Management (e.g., Waterfall)

Requireme Requirements are expected to Requirements are defined

nts evolve and change is completely and frozen at the
welcomed. They are defined beginning of the project.
iteratively. Change is resisted.

Planning Planning is adaptive and Planning is predictive and

continuous. Detailed planning extensive. A detailed plan for
occurs for each short iteration the entire project is created
(sprint). upfront.

Delivery The product is delivered in The entire product is delivered

small, frequent, working in a single, large release at the
increments. Value is delivered end of the project lifecycle.
early and continuously.

Customer High level of continuous Customer involvement is high

Inv. collaboration and feedback at the start (requirements) and
from the customer throughout end (acceptance), but limited
the project. in between.

Team Teams are self-organizing and Teams are typically

Structure cross-functional, with a high hierarchical with specialized
degree of autonomy and roles and a
collaboration. command-and-control
management style.
Export to Sheets
7. What is Sprint Velocity in Scrum? How is it calculated and how is it
used for planning? (5 Marks)

Answer:

Sprint Velocity is a key metric in Scrum that measures the amount of work a
Development Team can complete in a single Sprint. It is a measure of the team's
rate of progress.

●​ How it is Calculated: Velocity is calculated at the end of a sprint by

summing the Story Points (or other estimation units) of all user stories
that were fully completed and met the Definition of Done. It is not based
on partially completed work. A team's average velocity is typically
calculated over the last 3-4 sprints to get a more stable and predictable
measure.​

1.​ Example: If a team completed stories worth 5, 8, and 3 story points

in a sprint, their velocity for that sprint is 16.
●​ How it is Used for Planning: Velocity is a crucial input for planning future
work:​

1.​ Sprint Planning: During Sprint Planning, the team uses its average
velocity as a guide to determine how much work they can
realistically pull from the Product Backlog into the next Sprint. This
helps prevent over-commitment and makes the Sprint Goal more
achievable.
2.​ Release Planning: The Product Owner can use the team's average
velocity to forecast how many sprints it will take to complete a set of
features in the Product Backlog.
■​ Formula: Number of Sprints = Total Story Points
for Release / Average Velocity This provides a
rough estimate for stakeholders about when a release might
be ready.

Important Note: Velocity is a measure of a team's capacity, not its productivity. It

should not be used to compare different teams.
8. What is a Minimum Viable Product (MVP)? Explain its purpose in
Agile development. (5 Marks)

Answer:

A Minimum Viable Product (MVP) is a version of a new product that includes

just enough core features to be released to the market and be useful for a subset
of initial users (early adopters). It is not a low-quality or incomplete product;
rather, it is the smallest version that can deliver value and serve as a foundation
for learning.

Purpose of an MVP in Agile Development:

The primary purpose of an MVP is to facilitate validated learning with the least
amount of effort. Instead of building a full-featured product based on
assumptions, an MVP allows a team to test their core business hypothesis
quickly.

1.​ Test Product Hypotheses: It helps answer the most critical question:
"Should this product be built at all?" By getting a real product into the
hands of real users, the team can gather data on whether there is a market
need for their solution.​

2.​ Gather User Feedback Early: An MVP is a powerful tool for collecting
feedback from early adopters. This feedback is invaluable for guiding
future development, ensuring the team builds features that users actually
want and need.​

3.​ Reduce Wasted Effort and Resources: By focusing only on essential

features, the team avoids spending significant time and money building a
complex product that nobody might use. It minimizes risk and maximises
the return on investment.​

4.​ Faster Time-to-Market: Releasing an MVP allows the business to enter

the market much faster than if they waited to build a "perfect" product. This
can provide a crucial competitive advantage and start generating revenue
sooner.​
In essence, the MVP cycle is Build -> Measure -> Learn. The team builds the
smallest possible useful product, measures how users interact with it, and learns
from that data to decide what to build next.

9. Explain the concepts of swimlanes and their use in project

management tools like Kanban or in Activity diagrams. (5 Marks)

Answer:

Swimlanes are horizontal or vertical partitions used in process flow diagrams to

visually group related tasks, activities, or responsibilities. They help clarify who
does what in a process, bringing structure and clarity to complex workflows. The
name comes from the analogy of lanes in a swimming pool.

Use in Kanban Boards: In Kanban, swimlanes are horizontal rows that span
across the columns of the board. They are used to categorize work items based
on specific criteria, helping teams manage their workflow more effectively.
Common uses include:

●​ By Team or Person: Assigning a lane to each team member or sub-team

to show individual responsibilities.
●​ By Class of Service: Creating lanes for different levels of priority or
urgency (e.g., Expedite, Standard, Fixed Date). This helps the team
prioritize which work to pull next.
●​ By Project or Feature: If a team is working on multiple projects, each
project can have its own swimlane.
●​ By Type of Work: Separating different kinds of tasks, such as New
Features, Bugs, and Technical Debt.

Use in UML Activity Diagrams: In Activity diagrams, swimlanes are called

Partitions. They are used to group actions based on the responsible party (e.g.,
an actor, a department, a system component).

●​ Purpose: They clearly show which actor or organizational unit is

responsible for performing each activity in a workflow. This is especially
useful for modeling business processes that cross departmental
boundaries.
 ●​ Example: In a business process for "Order Fulfillment," swimlanes could
be used for Sales Dept., Warehouse, and Shipping Dept., with
each activity placed in the lane of the department responsible for executing
it. This makes it easy to see the handoffs between different departments.

10. What is a "project repository" and why is it crucial for team

collaboration in software development? (5 Marks)

Answer:

A project repository is a central storage location where all the artifacts related
to a software project are stored and managed. While it most commonly refers to
the source code repository managed by a version control system like Git, it can
also include documentation, design models, test cases, build scripts, and other
project-related files.

Importance for Team Collaboration:

A project repository is crucial for effective team collaboration for several key
reasons:

1.​ Single Source of Truth: It provides a single, universally accessible

location for all project files. This ensures that every team member is
working with the most up-to-date and consistent version of the code and
documents, eliminating confusion and conflicts.​

2.​ Enables Parallel Development: With version control features like

branching, multiple developers can work on different features or bug fixes
simultaneously without interfering with each other's work. They can work in
isolated branches and merge their changes back into the main codebase
in a controlled manner.​

3.​ Maintains a Complete History: The repository keeps a detailed history of

every change made, including who made it, when, and why. This is
invaluable for debugging (e.g., finding when a bug was introduced),
auditing, and understanding the evolution of the project.​
4.​ Facilitates Code Reviews: Platforms that host repositories (like GitHub or
GitLab) have built-in features like Pull Requests. These tools facilitate a
collaborative code review process, where team members can discuss
changes and improve code quality before the code is integrated.​

5.​ Automation and Integration: Repositories are the foundation for

Continuous Integration/Continuous Deployment (CI/CD) pipelines.
Automated systems can monitor the repository and trigger builds, tests,
and deployments whenever new code is committed, streamlining the entire
development workflow.