Question 1.

+ Project Characteristics
- Users
Lecturers and Staff: These users need to register and manage their bus routes.
Admin Staff: They synthesize schedules, schedule vehicles, and manage costs.
Admin Manager: They approve schedules and view cost summaries.
Academic Staff: They input and manage lecture schedules and their corresponding bus
requirements.
- Customer
FPT University's administrative department, which requires an efficient and secure system
for managing their shuttle bus system.
- Team
4-6 developers with extensive experience and skills.
Support from other departments (e.g., admin dept) as needed.
- Requirements Characteristics
Dynamic: The system is new, and requirements may change as development progresses.
Integration with Gmail for authentication.
High performance and security are critical.
User-friendly: The system should be intuitive to reduce the need for formal training.
- Time Constraints
First version deployment: 3 months.
Complete project completion: 6 months.
- Managers' Expectation
Deliver a robust, secure system without the need for extensive training.
The ability to adapt to changes during the development process.

+ Suggested Development Methodology: Agile

Given the characteristics identified above, an Agile development methodology would be best
suited for this project for several reasons:
- Flexibility for Changing Requirements:
Agile allows for iterative development, which can accommodate changes in requirements, a
crucial aspect since this is a new system and adjustments are anticipated.
User-Centric Focus: Agile involves regular user feedback and user stories, which aligns with
the need to create a user-friendly system that meets the specific needs of different user
groups at the university.
- Time Constraints:
The Agile methodology, with its iterative sprints, supports the rapid delivery of a functioning
version of the system within the three-month target for the first version.
Collaboration: Agile emphasizes close collaboration between developers and business
stakeholders, which is essential given that staff from different departments will support the IT
team.
- Regular Deliverables:
Agile's focus on delivering working software frequently aligns with the manager's
expectations for a high-quality and secure product within a restrictive timeline.
- Risk Management:
Frequent iterations and reviews help in early identification and resolution of issues, which is
vital for projects with tight deadlines and high expectations.
By using Agile, the development team can work in short sprints, which allows for constant
evaluation of project priorities and deliverables. It also encourages stakeholder involvement
throughout the project, ensuring that the final product aligns closely with the users' needs
and the university's goals.

Question 2.

To ensure a high-quality Shuttle Bus Management System (SBMS) for FPT University,
implementing a multi-level testing approach is crucial. I suggest list testing plan with the
types and stages of testing, along with the responsible parties for each:

- Unit Testing
Level: Low-level, focuses on individual components/functions.
Who: Developers.
When: Continuously during the development phase.
Purpose: To ensure that each piece of code works as intended in isolation.
- Integration Testing
Level: Mid-level, focuses on interactions between integrated units/modules.
Who: Developers or a specialized integration test team.
When: After unit testing, when modules are combined.
Purpose: To ensure that integrated components work together as expected.
- System Testing
Level: High-level, tests the complete and integrated software.
Who: A dedicated Quality Assurance (QA) team.
When: After integration testing, when the system is feature-complete.
Purpose: To validate the system against the full requirements.
- Acceptance Testing
Level: User-level, testing with real-world scenarios.
Who: End-users (lecturers, admin staff, academic staff) and/or business analysts.
When: After system testing and before the system goes live.
Purpose: To confirm the system meets the business needs and is ready for deployment.
- Performance Testing
Level: Focuses on non-functional aspects such as speed, scalability, and stability.
Who: Performance test engineers or QA team.
When: Late in the development process or after the system testing stage.
Purpose: To ensure the system meets performance benchmarks and can handle the
expected load.
- Security Testing
Level: Focuses on vulnerabilities, threats, and risks.
Who: Security specialists or a third-party security firm.
When: Can be conducted alongside system testing and acceptance testing.
Purpose: To ensure that user data is protected and the system is secure against potential
attacks.
- Regression Testing
Level: Ensures that new changes haven't adversely affected existing functionality.
Who: QA team.
When: After any change or addition to the system.
Purpose: To ensure that new code changes do not introduce new bugs into existing
functionality.
- User Acceptance Testing (UAT)
Level: Final verification before going live.
Who: Select group of end-users.
When: After all other tests have passed and before the final rollout.
Purpose: To confirm the system is ready for production and meets user expectations.

All these testing stages should be well-documented, and the outcomes should be tracked
meticulously. Automated testing can be used wherever applicable to speed up the process,
especially for regression testing. It is also important to plan for a feedback loop from the
users during UAT to make sure that any critical issues are addressed before the final launch.

Question 3.

+ Functional Requirements

1. Bus Route Registration: The system must allow lecturers and staff to register for bus
routes, providing options for dates, times, and preferred pickup and drop-off points.

2. Bus Route Management: There should be functionality for lecturers and staff to change
their registered bus routes, with the system handling conflicts or scheduling issues that may
arise from such changes.

3. Scheduling and Synthesis: The system should enable admin staff to synthesize weekly
bus schedules of staff and lecturers, schedule the appropriate vehicles for these routes, and
ensure that the schedule optimizes vehicle usage to reduce costs.

4. Cost Management: The application must provide a feature for recording and summarizing
the costs associated with each bus trip, allowing the administrative staff to keep track of
expenses and manage the budget effectively.

+ Non-Functional Requirements

1. Performance: The system must handle multiple concurrent users efficiently, with minimal
latency, ensuring that users can register and manage bus routes in real-time without
significant system delays.

2. Security: Given that users will log in with their FU's email accounts, the system must
employ robust security measures to protect sensitive data and user privacy, following best
practices for authentication, data encryption, and secure data storage and transmission.
Question 4.

Use Cases:

Register Bus Routes: Lecturers/Staff can register for bus routes.

Manage Bus Routes: Lecturers/Staff can change their registered bus routes.
Synthesize Schedules: Admin Staff can synthesize and manage weekly bus schedules.
Record and Summarize Costs: Admin Staff can record the costs for bus trips and provide
summaries.

Question 5.

Test Case 1: Register Bus Routes

Target: Verify that Lecturers/Staff can successfully register for bus routes.

Procedure:
1. Log in to the SBMS as a Lecturer/Staff member.
2. Navigate to the "Register Bus Routes" section.
3. Fill in the required fields for bus route registration (date, time, pickup point, drop-off point).
4. Submit the registration form.

Expected:
- The system should confirm the registration.
- The registered bus route should now appear in the member's schedule.
- The system should not allow conflicting registrations for the same member.

Post-Conditions:
- The member should receive an email confirmation with the details of their registered route.

Test Case 2: Manage Bus Routes

Target: Test the ability for Lecturers/Staff to change their registered bus routes.

Procedure:
1. Log in to the SBMS as a Lecturer/Staff member.
2. Navigate to the "Manage Bus Routes" section.
3. Select an existing bus route registration.
4. Make changes to the bus route details (change time or destination).
5. Save the changes.

Expected:
- The system should display a success message indicating the route has been updated.
- The updated route details should reflect correctly in the member's schedule.
- Any scheduling conflicts as a result of the change should trigger a warning message.

Post-Conditions:
- The system should send an updated email confirmation with the new route details.

Test Case 3: Synthesize Schedules

Target: Ensure that Admin Staff can synthesize weekly bus schedules.

Procedure:
1. Log in to the SBMS as an Admin Staff.
2. Navigate to the "Synthesize Schedules" section.
3. Select the option to generate a new weekly schedule.
4. Review the automatically generated schedule for conflicts or inefficiencies.

Expected:
- The system should create a weekly schedule that optimizes vehicle usage.
- The schedule should be free of any conflicts between bus times and availability.

Post-Conditions:
- The schedule should be available for review and adjustments by the admin before final
publication.

Test Case 4: Record and Summarize Costs

Target: Validate that Admin Staff can record and summarize costs for bus trips.

Procedure:
1. Log in to the SBMS as an Admin Staff.
2. Navigate to the "Cost Management" section.
3. Enter the costs associated with a specific bus trip.
4. Save the cost information.
5. Generate a cost summary report.

Expected:
- The system should accurately record the entered cost details.
- The generated cost summary report should reflect all the recorded costs correctly.

Post-Conditions:
- The cost summary report should be downloadable and printable for record-keeping.

Each of these test cases should be executed in a controlled environment, ensuring that other
factors do not influence the outcome. Any discrepancies from the expected results should be
logged as defects for the development team to address.

Question 6.

- As a lecturer or staff member at FPT University,I want to be able to easily register

for bus routes through the Shuttle Bus Management System, So that I can plan
my commute to and from the university with convenience and ensure that my
travel needs are scheduled and confirmed in advance.

- As an admin staff member at FPT University,I want to have the capability to

synthesize and manage weekly bus schedules for all registered lecturers and
staff, So that I can ensure an optimized and conflict-free transportation plan
that makes efficient use of the available buses and aligns with the staff's
scheduling needs.

Question 7.
Story Map for "Register Bus Route"