The company follows an operational and project management process called CMMI (Capability Maturity Model Integration), which has been assessed and certified at Level 3, combined with the Agile Method as the company’s project management standard. CMMI covers the entire process, starting from project planning through to post-delivery system maintenance. Therefore, the CMMI Level 3 standard has a broader scope than a typical Software Development Life Cycle (SDLC), ensuring comprehensive coverage throughout the entire project lifecycle.
The project process under the CMMI framework is divided into the following stages:
1.System Proposal Process (Contract)
2.Planning Process
2.1 System Proposal Process (Contract)
2.2 Planning Process
3.Requirement Definition Process
3.1 System Requirement Specification (SRS)
3.2 System Design Specification (SDS)
4.System Development Process
4.1 Functional Development (Source Code and Application)
4.2 Functional Testing
4.3 Integration Testing (Testing the interaction between system components after integration)
5.System Testing and Deployment Process (Operational Test and Transition)
5.1 User Acceptance Test Planning (UAT Test Plan)
5.2 UAT Test Cases and Results (Assessment and summary of test results)
5.3 User Training
5.4 User Manual
5.5 Administration & Configuration Manual
6.System Maintenance Process (Operation Maintenance)
6.1 Maintenance Agreement
6.2 Maintenance Issues List
Change Requirement Management
In the application development process, one thing that is unavoidable is the Change Requirement (CR). Its causes and impacts can significantly affect the project, so the management process for handling changes must be clearly agreed upon.
Causes of Change Requirements:
- The person providing information is not fully knowledgeable about the subject.
- The system is newly designed and has never been implemented before.
- The supplier does not fully understand the customer’s business.
Impacts of Change Requirements:
- CR before Requirement Gathering
- Minimal impact since actual development has not started yet.
- Can still be considered part of the requirement process.
- CR during the Design Phase:
- Some impact, as parts of the system (e.g., frontend or layout design) may already be underway.
- Impact varies depending on the type of CR — e.g., adding field details or validation conditions has low impact.
- Adding a new feature must be checked against the requirement specification to ensure it’s not out of scope
- CR during Development
- Affects the project timeline as it may require revisiting the design phase.
- Must assess whether the CR conflicts with previously agreed requirements or significantly changes workflows — if so, the impact can be major.
- CR during UAT (User Acceptance Testing):
- CRs are likely at this stage because end users (different from the requirement team) are now involved, and many may be seeing the system for the first time
- There will definitely be an impact on both the project timeline and budget.
Managing Change Requirements (CR)
- Developers must first accept that CR is a natural part of the process and remain calm and patient.
- The user’s project manager should plan the budget in advance to accommodate potential changes.
- End users should be given the opportunity to review the design and participate in the design process early in the project.
- A project kick-off meeting should be held to present the initial project scope to the UAT team.