Development Process with CMMI

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.

What qualifies as a Change Requirement (CR)?

• Adding a new feature that was not specified in the original documentation.
• Changing the design of a feature from A to B.
• Expanding existing options, e.g., from 3 choices to 4.
• All of the above must be referenced against the original documentation.

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.

Guidelines for Requirement Gathering

The requirement gathering stage is the most critical part of the entire process, as it determines the project’s overall direction and allows an early assessment of how the project will likely conclude. For example, if requirements are vague, conversational, and recorded without measurable criteria, it’s a strong indication that the project will not end successfully.

Characteristics of Well-Defined Requirements

• Clearly separated into key sections, such as:
  • User roles in the system
  • Permissions for each role in each area and data status
  • Action Actions that can be performed in each Role
• Field information on each topic
  • You can specify the type, category, and total number of fields and set an ID number for each field.
  • Define Master Data Fields and prepare an Admin page for management.
  • System reference fields and user reference fields are clearly separated.
• System Process Flow
  • สามารถแยกออกมาเป็นข้อ ๆ และมีเลข ID สำหรับเป็น Reference
  • Consideration of selection of data to be processed, such as selecting as a group or selecting each item individually.
• Displaying data in List format for each role
  • It is possible to clearly specify what conditions each role will be displayed under.
  • Clearly define the number of conditions to be considered.
• Clearly define the number of conditions to be considered.

Development Team

• Project Manager: Control the Scope of work plan to be within the scope that can be delivered according to the plan, present the project status to the meeting.
• Business Analysis: Design the system usage flow to be consistent with the user's needs and the goals of the system usage.
• System Analysis : Design and control Data Flow, Data Dic, ER Diagram, design of internal and external data connection system.
• Senior Programmer: Control the coding guidelines to meet standards.
• Programmer : Coding
• Tester: Design system testing before delivery.
• Admin: Manage project documents.