Scribd
Upload
23 views3 pages

Q1, Q2 Swe201c

The document recommends using an Agile development methodology, specifically Scrum, for developing the Shuttle Bus Management System due to the project's rapid timeline, iterative delivery expectations, and evolving requirements. Scrum is considered a good fit as it emphasizes daily communication, encourages flexibility to changes, and allows dividing work into manageable sprints to meet the three month deadline.

Uploaded by

huyleo2004
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
23 views3 pages

Q1, Q2 Swe201c

The document recommends using an Agile development methodology, specifically Scrum, for developing the Shuttle Bus Management System due to the project's rapid timeline, iterative delivery expectations, and evolving requirements. Scrum is considered a good fit as it emphasizes daily communication, encourages flexibility to changes, and allows dividing work into manageable sprints to meet the three month deadline.

Uploaded by

huyleo2004
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Q1 :

For the development of the Shuttle Bus Management System, given the rapid timeline and
expectation or iterative and incrementar denvery, the Agile software development methodology,
particularly the Scrum framework, is recommended.

Project Characteristics:

The project requires a quick turnaround with the first functional iteration to be delivered within three
months, demanding a highly adaptive and iterative approach.

The involvement of multiple departments indicates the necessity for cross-functional collaboration and
constant communication.

As SBMS is a new venture for FU, there's a likelihood of evolving requirements which necessitates a
flexible approach to accommodate potential changes without significant delays.

User, Customer, and Team Dynamics:

The system will serve a diverse group of users, including lecturers, administrative staff, and managers,
each with unique requirements that must be clearly understood and quickly addressed.

The development team is comprised of 4-6 experienced IT personnel alongside contributors from other
departments, implying a need for a method that supports team dynamics and leverages various skill
sets.

Requirements Characteristics:

SBMS requirements may not be fully defined upfront and are subject to change, thus a methodology
that em

The system requires high quality and security standards, which Agile can assure through continuous
testing and integration.

Time Constraints and Management Expectation:

A tight deadline necessitates a development model that allows for concurrent phases of planning,
development, testing, and revisions. Management expects quick and tangible results, which Agile's
sprint cycles can deliver, providing frequent progress updates and product increments.

Development Model Choice:

Scrum fits the identified factors well as it:


Encourages regular reflection on how to become more effective, allowing the team to adjust behaviors
accordingly.

Utilizes time-boxed sprints to divide the work into manageable chunks, which aligns with the three-
month release target.

Emphasizes daily communication and collaboration through rituals like Daily

Stand-Ups and Sprint Reviews, ensuring the team stays aligned and bottlenecks are addressed promptly.

Considering these points, Scrum's iterative development cycles, emphasis on user feedback, and ability
to accommodate changing requirements will likely lead to the successful delivery of SBMS within the
specified timeframe and to the satisfaction of all stakeholders.

Q2.

Suggested Testing Types and Levels for SBMS

Unit Testing

Executors: Developers

Timing: Post-development of individual functions

Objective: Verify the correctness of each unit of code in isolation

Integration Testing

Executors: Development Team or Integration Testers

Timing: Post-completion of module development

Objective: Ensure that integrated modules operate cohesively

System Testing

Executors: Quality Assurance Team

Timing: After integration and before UAT

Objective: Confirm that the system as a whole meets specified requirements

User Acceptance Testing (UAT)

Executors: End Users/Stakeholders

Timing: Before final deployment

Objective: Validate the system against user requirements and expectations

You might also like