Câu 1: Lựa chọn mô hình phát triển (2đ)
Template cho Agile (Scrum):
Recommendation to use Agile:
I suggest using the Agile method for these reasons:
a) Requirements:
• Flexibility: Requirements not clearly defined, might change during
development
• Adaptability: Need to adjust based on user feedback and market trends
• Thoroughness: Many requirements need early validation
b) Development Team:
• Team Structure: 4-6 experienced developers, perfect for Scrum
• Strong Collaboration: Good communication within team
• Role Expertise: Clear roles (PO, Scrum Master, Developers)
• Adaptability: Can quickly adjust to changes
• Time Constraints: Fits well with sprint cycles
Conclusion:
Scrum is best due to team structure, need for iteration, and ability to
handle changing requirements.
Template cho Waterfall:
Recommendation to use Waterfall:
I recommend the Waterfall method for these reasons:
a) Requirements:
• Clear and Stable: Requirements well-defined from start
• Structured Approach: Step-by-step process needed
• Detailed Planning: Complex requirements need thorough documentation
b) Development Team:
• Team Structure: Works well in structured environment
• Specific Roles: Clear separation of responsibilities
• Documentation Focus: Strong documentation practices
• Predictability: Well-defined timeline and milestones
Conclusion:
Waterfall is best due to clear requirements, structured roles, and need
for documentation.
Câu 2: Testing Levels & Responsibilities (1đ)
Template trả lời mẫu (Nhớ paraphrase lại nhé và học thuộc hoặc học
hiểu tùy vào bạn)
Based on the project requirements, the following testing levels are
proposed:
1. Unit Testing
Tester: Developers
Focus:
- Testing individual software components
- Verifying correct functionality of each component
- Code coverage and basic functionality checks
2. Integration Testing
Tester: Developers or dedicated integration testing team
Focus:
- Component interactions and compatibility
- Interface testing between modules
- Data flow verification
3. System Testing
Tester: Dedicated testing team
Focus:
- End-to-end system functionality
- Requirements verification
- Complete system behavior testing
4. User Acceptance Testing (UAT)
Tester: End users
Focus:
- Real-world usage scenarios
- Business requirement validation
- User workflow verification
5. Regression Testing
Tester: Dedicated testing team/Automated tools
Focus:
- Impact of changes on existing features
- System stability after updates
- Automated test suites execution
6. Performance & Load Testing
Tester: Specialized testing engineers
Focus:
- System performance under load
- Stress testing and reliability
- Peak usage simulation
1. Phân công testing đúng người
o Unit testing → Developers
o Integration → Dev team/Testing team
o System → Dedicated testers
o UAT → End users
2. Thứ tự testing
o Start with Unit Testing
o Move to Integration
o Complete System Testing
o Finish with UAT
3. Focus areas
o Component functionality
o Integration points
o System requirements
o User acceptance
Câu 3: Functional & Non-functional Requirements (2đ)
Đáp án:
Câu 4: User Stories dựa trên Requirements (1.5đ)
Câu 5: Quality Metrics (1.0đ) - Câu này khuyến khích bỏ
vì khó làm và cũng là lần đầu ra thi
Template trả lời chuẩn
To measure code and design quality in this project, I propose these
metrics:
1. LCOM (Lack of Cohesion of Methods) - Measuring Cohesion
• Description: Measures how well methods of a class are related to
each other
• Formula: LCOM = (Number of method pairs not sharing attributes -
Number of method pairs sharing attributes) / 2
• Good Value: < 0.5 (Lower is better)
• Application in Project: Use to identify classes that may need to be
split into smaller, more focused classes
2. CBO (Coupling Between Objects) - Measuring Coupling
• Description: Counts number of other classes a class is coupled to
• Formula: Count unique class dependencies (method calls, attributes,
parameters, etc.)
• Good Value: < 14 classes
• Application in Project: Monitor dependencies between components to
maintain loose coupling
3. Cyclomatic Complexity
• Description: Measures complexity of code by counting decision points
• Formula: E - N + 2P (E=edges, N=nodes, P=connected components)
• Good Value: < 10 per method
• Application in Project: Identify complex methods needing refactoring
4. Code Coverage
• Description: Percentage of code executed by tests
• Formula: (Lines executed / Total lines) * 100
• Good Value: > 80% coverage
• Application in Project: Ensure comprehensive test coverage of
critical features
5. DIT (Depth of Inheritance Tree)
• Description: Measures inheritance levels in class hierarchy
• Formula: Count levels from class to root of inheritance tree
• Good Value: < 6 levels
• Application in Project: Keep inheritance hierarchies manageable and
avoid deep nesting
Câu 6: Story Mapping (2.5đ)
Ví dụ Story Map cho "Train Schedule Management"
A. Activities and User tasks
1. Create Train Schedule
1.1 Input Basic Schedule Information
1.2 Set Route Details
1.3 Assign Resources
1.4 Validate Schedule
2. Update Train Schedule
2.1 Modify Existing Schedule
2.2 Handle Schedule Conflicts
2.3 Notify Affected Parties
2.4 Update Related Systems
B. Releases
Release 1 (Core Functionality)
1.1.1 As a scheduler, I want to input train departure times
1.1.2 As a scheduler, I want to input train arrival times
1.2.1 As a scheduler, I want to define train stops
2.1.1 As a scheduler, I want to modify schedule times
2.1.2 As a scheduler, I want to update route information
Release 2 (Advanced Features)
1.3.1 As a scheduler, I want to assign train staff
1.4.1 As a scheduler, I want to check schedule conflicts
2.2.1 As a scheduler, I want to resolve timing conflicts
2.3.1 As a scheduler, I want to send update notifications