MEHRAN UNIVERSITY OF ENGINEERING &

TECHNOLOGY JAMSHORO
DEPARTMENT OF COMPUTER SYSTEMS ENGINEERING

Software Engineering

Problem Based Learning Assignment

SUBMITTED BY : Noor Fatima(21CS079)

SUBMITTED TO : Ma’am Areej Jawed

October 2024
Problem Scenario:

You are part of a software development team for a startup that aims to build a mobile application
called FitnessTracker. The application will help users track their daily physical activities, set
fitness goals, and monitor their progress over time. The startup wants the app to have features
like step counting, GPS tracking for runs or walks, daily workout logs, and personalized fitness
recommendations.

The project must be completed in six months, and the client has a limited budget. Your team has
four developers, one project manager, and a UX/UI designer.

However, after the first two months of development, the client requests major changes, including
new features like integration with wearable devices, social sharing options, and a calorie tracker.
This significantly impacts the timeline and budget.

Question:

1. As a software engineer, what strategies or models would you recommend the team use to
manage these changes effectively? Consider aspects like:
o Software development methodology (e.g., Agile, Waterfall, etc.)
o Risk management
o Requirement analysis and prioritization
o Communication with stakeholders

To manage the changes requested by the client while adhering to Agile methodology and
integrating DSDM and CBSE (Component-based Software Engineering) approaches, the
following strategies and models should be implemented:

Software Development Methodology (Agile + DSDM + CBSE

Integration)
Agile methodologies, particularly DSDM (Dynamic Systems Development Method), are
well-suited for handling changing requirements. Since the project is already following
Agile principles with DSDM, you can leverage the flexibility and incremental delivery of
this framework to handle the changes.

• DSDM’s Fixed Time, Flexible Scope Approach: DSDM ensures that the project stays
within the six-month timeline by prioritizing critical features first. DSDM’s "80/20 rule"
(Pareto Principle) enables the delivery of 80% of essential functionality within the fixed
time frame, with less critical features handled later or discarded as necessary.

• CBSE (Component-Based Software Engineering) complements DSDM by focusing

on integrating pre-existing components instead of building everything from scratch. For
new features like wearable device integration or social sharing, the team can identify and
 reuse existing components, speeding up development and aligning with DSDM’s fixed-
time, variable-scope philosophy.

Risk Management
Effective Risk Mitigation and Risk Monitoring are crucial to managing the expanded
scope:

• Turnover Risk: As changes in scope might affect team dynamics, proactively address
any issues with staff through regular meetings, ensuring workload is balanced and roles
are clear. Use peer reviews and documentation to minimize risks associated with losing
key team members.

• Risk Monitoring: Conduct regular risk assessments to evaluate the probability and
impact of risks associated with new features like wearable integration. Continuously
monitor and assess risks at every review and adjust the plan accordingly to mitigate any
potential issues.

Requirement Analysis and Prioritization

DSDM’s incremental and iterative nature supports handling new requirements through
careful analysis and prioritization:

• Prioritize Using the 80/20 Rule: Focus on delivering the most critical 80% of
functionality, such as step counting, GPS tracking, and daily logs, within the remaining
timeline. Use this to de-prioritize less critical features, such as calorie tracking and social
sharing, unless these are considered high value by the client

• Enhanced Project Planning Tasks: Embed project planning tasks to manage

requirement changes:
o Define the new project scope, ensuring clear boundaries for what can be
delivered in the remaining time.
o Analyze the feasibility of new requests and provide multiple estimates for effort,
time, and cost.
• Collaborative Decision-Making: Involve the client in the process of prioritizing which
new features are most critical, ensuring that the highest business-value features are
developed first.

Communication with Stakeholders

DSDM emphasizes continuous and clear communication with stakeholders:

• Timeboxing: Regular timebox reviews should be held to discuss progress and the status
of any new features. In these reviews, communicate with the client about how new
requests are being handled, ensuring alignment.
• Early Client Involvement: Engage the client early in the process to discuss how new
requirements may impact the timeline and budget. Collaboratively decide on priorities
and adjust the timeboxes accordingly.

• Transparency: Provide working increments of the application during timebox reviews,

demonstrating progress on key features and gathering feedback on newly added features
such as GPS tracking or wearable device integration.
By leveraging DSDM’s principles, along with CBSE to reuse components, and
maintaining continuous communication with stakeholders, the team can handle scope
changes effectively within the fixed timeline.
2. How would you ensure that the quality of the software is maintained despite these
changes? Consider practices like code reviews, testing strategies, and continuous
integration.

To ensure that the quality of the software is maintained despite the changes, we would
use a combination of established practices such as code reviews, thorough testing, and
continuous integration. These practices align with the DSDM framework and will help
us manage the added complexity of the new features.

Consistent Code Reviews

Regular code reviews prevent bugs from slipping into the codebase, ensure consistency
in code quality, and make sure the entire team is aware of changes being made, which is
essential for maintaining the stability of the software.

• Peer Programing Reviews: As part of the development process, every change

introduced—especially new features like wearable device integration or social sharing—
should go through peer reviews. This will ensure that the new code is clean, follows best
practices, and doesn’t introduce any bugs into the system.

• Component-Based Code Reviews: Since we are using component-based software

engineering (CBSE), reviews will focus on the integration of pre-built components. This
helps in identifying issues early and ensuring that reused components fit well into the
system.

Testing Strategy
Testing will be an ongoing part of the development process to ensure that every part of
the system works as expected, both individually and as a whole. Thorough testing
minimizes the risk of bugs reaching the final product.

• Unit Testing: This will test individual components (like the step counter or GPS tracker)
to ensure that they function correctly in isolation. For new features like wearable device
integration, unit testing will verify that the components work as intended without
breaking existing functionality.
• Integration Testing: As we integrate new features with the core system, integration
testing will be essential to check if the components interact correctly with each other. For
example, after adding wearable device integration, we will test how it interacts with the
GPS tracking and workout logging features.
• System Testing: Once all components are integrated, system testing will ensure that the
entire app functions smoothly as a whole. This will check if both old and new features
are aligned and working together as expected.
• Regression Testing: Every time new features are added, regression testing will be
performed to make sure that the existing features (step counting, GPS tracking) are not
 negatively impacted. This is important to avoid breaking previously working parts of the
system.
• Non-Functional Testing: We will also focus on performance testing to ensure that new
features, like wearable device integration, do not slow down the app. Usability testing
will check the user experience to ensure it remains intuitive despite the new features.

Continuous Integration
Continuous integration allows us to integrate and test changes frequently, ensuring the
software remains stable throughout development.

• Frequent Builds and Testing: Every time a developer adds new code, such as the new
features, it will be automatically integrated into the main project and tested. This ensures
that any issues are caught immediately and can be fixed early on.
• Automated Testing in CI: Automated unit and integration tests will be run as part of the
CI process. This helps in quickly identifying if any new changes, like wearable device
integration or social sharing, cause problems elsewhere in the system.

Early and Ongoing Testing

As noted, starting testing early in the development process is critical. Testing as we build
allows us to detect defects at the earliest stage, where fixing them is less costly and time-
consuming. Regular testing aligns with the DSDM approach of delivering incrementally,
ensuring that each iteration of the app is stable and functional before moving forward.
3. Discuss how you would handle the balance between delivering a product on time and
incorporating the client’s new requirements. What trade-offs might be necessary, and
how would you justify them to the client?

To manage the balance between delivering the product on time while incorporating the
client's new requirements, the approach will be aligned with DSDM's fixed time,
variable functionality principle and the Pareto Principle. Here’s how the balance will
be handled:

Fixed Time, Flexible Scope (Pareto Principle)

DSDM ensures that the time and resources remain fixed, meaning the product must be
delivered within the original six-month timeline. To accommodate the client's new
feature requests, such as wearable device integration and social sharing, we will apply the
Pareto Principle, focus on delivering the most valuable 80% of the product’s functionality
within 20% of the time. The remaining 20% of less critical features will be handled either
after the core product is delivered or as future enhancements.

Trade-off: Some non-essential features (e.g., advanced social sharing options or calorie
tracking) may need to be postponed or simplified to ensure timely delivery.

Justification to the Client: I would explain that the core functionality—step counting,
GPS tracking, and workout logs—must be delivered first to meet the user needs and
business goals within the agreed timeline. Less critical features can be added later,
allowing the app to be launched on time while keeping future updates in mind.

Timeboxing and Incremental Delivery

Timeboxing, a core practice in DSDM, will allow us to deliver features in fixed periods
(timeboxes). Each timebox will focus on a set of prioritized features, with the highest-
value functionality being developed and tested first.

Trade-off: The less essential features may be delayed if they don’t fit into the scheduled
timeboxes. The key is ensuring that the core product is functional and stable by the
deadline.

Justification to the Client: By using timeboxing, I would reassure the client that we can
incrementally deliver a working product that meets their business goals. New features
can still be added later without impacting the initial release. This method allows for
feedback at regular intervals, providing the client with visibility into the development
process and helping them feel in control of priorities.

Reuse of Pre-existing Components (CBSE)

Component-Based Software Engineering (CBSE) will play a crucial role in integrating
the new features, such as wearable device integration or social sharing. By reusing pre-
existing components, we reduce the time needed for development.

Trade-off: While CBSE can accelerate development, some requested features might still
need to be scaled down in complexity to fit within the timeline.

Justification to the Client: I would explain that by leveraging reusable components, we

can implement certain features faster without impacting the delivery timeline. However,
I’d also emphasize that some features may need to be simplified or added incrementally
to avoid delays in launching the core app.