Certification Maturity Model
29.4.1. Maturity Model Overview
The TQS Maturity Model is a proprietary maturity framework inspired by the five-level maturity concept of CMMI (Capability Maturity Model Integration), redesigned to suit TIENIPIA's technical environment.
While CMMI focuses on measuring organizational process maturity, the TQS Maturity Model measures a project's technical implementation quality maturity. Based on the actual implementation levels of code conventions, testing, security, and build automation, it diagnoses the project's current position and provides specific direction for advancing to the next level.
The five-level structure of the TQS Maturity Model is as follows.
| Level | Name | TQS Certification Grade | Key Characteristics |
|---|---|---|---|
| Level 1 | Initial | Uncertified | No standards applied, individual coding styles |
| Level 2 | Managed | Uncertified (Preparation stage) | Basic conventions applied, formatter setup complete |
| Level 3 | Defined | Standard Certification | TQS mandatory items 100% satisfied |
| Level 4 | Quantitative | Advanced Certification | Metrics monitoring, recommended items 80% or above |
| Level 5 | Optimized | Premier Certification | Recommended items 100%, continuous improvement process |
Each level includes the requirements of the previous level. In other words, to qualify for Level 3, the requirements of Levels 1 and 2 must also be fully met. Skipping levels is not permitted.
The maturity model is directly linked to TQS certification. Only projects that have reached Level 3 or above may apply for TQS certification, and Levels 4 and 5 correspond to Advanced Certification and Premier Certification, respectively.
29.4.2. Level Definitions
29.4.2.1. Level 1: Initial
Level 1 is the state where no technical standards are applied. Coding style, tool selection, and project structure are determined according to individual developers' experience and preferences.
| Domain | Level 1 Status |
|---|---|
| Code Style | Formatter not applied, differing coding styles per individual |
| Project Structure | Non-standard directory structure, inconsistent package organization |
| Testing | Tests not written or very low coverage (below 30%) |
| Configuration Management | Branch strategy undefined, no commit message rules |
| CI/CD | Pipeline not configured or manual deployment |
| Security | No systematic security criteria, inadequate secret management |
| Documentation | API documentation not written, absence of project description documents |
Projects at Level 1 accumulate technical debt rapidly and are vulnerable to personnel changes or requirements changes. Most new projects start at Level 1 unless standards are intentionally applied.
29.4.2.2. Level 2: Managed
Level 2 is the state where basic coding conventions and tool configuration are complete. This is the stage where the first step toward standardization has been taken, and preparation for TQS certification begins.
| Domain | Level 2 Status |
|---|---|
| Code Style | Formatter setup complete (Google Java Format, Prettier) |
| Project Structure | Basic layered structure applied (Controller-Service-Repository) |
| Testing | Tests exist for key features (coverage 30-60%) |
| Configuration Management | Branch strategy adopted, basic commit rules applied |
| CI/CD | Basic pipeline configured (build + test) |
| Security | Basic input validation applied, .gitignore configured |
| Documentation | Basic project description document exists |
Level 2 falls short of TQS certification criteria but has the foundation for standardization in place. At this stage, progressively satisfying the TQS standard's mandatory items enables transition to Level 3.
29.4.2.3. Level 3: Defined
Level 3 is the state where 100% of TQS standard mandatory items are satisfied, corresponding to TQS Standard Certification.
| Domain | Level 3 Status |
|---|---|
| Code Style | Formatter + linter automatically applied, style verification in CI |
| Project Structure | 100% compliance with TQS standard project structure |
| Testing | Line coverage 80% or above, branch coverage 70% or above |
| Configuration Management | GitHub Flow, Conventional Commits, minimum 1 PR reviewer |
| CI/CD | Lint + test + build pipeline fully established |
| Security | TLS 1.2 or above, BCrypt hashing, Bean Validation, RBAC |
| Documentation | Automated API documentation (SpringDoc), standard error responses |
Level 3 is the minimum threshold for TQS certification. Since 100% fulfillment of mandatory items is required, failure to satisfy even a single mandatory item means the project is not recognized as Level 3. Projects that reach Level 3 may apply for TQS Standard Certification.
29.4.2.4. Level 4: Quantitative
Level 4 is the state where, in addition to mandatory item fulfillment, 80% or more of recommended items are satisfied and quality metrics are quantitatively monitored. This corresponds to TQS Advanced Certification.
| Domain | Level 4 Status |
|---|---|
| Code Style | Level 3 met + code complexity/duplication monitoring |
| Project Structure | Level 3 met + 80% or more of recommended configuration items applied |
| Testing | Line coverage 85% or above, integration tests included |
| Configuration Management | Level 3 met + strict Semantic Versioning applied |
| CI/CD | Level 3 met + security scan stage included |
| Security | Level 3 met + OWASP Dependency-Check applied |
| Documentation | Level 3 met + architecture documentation, operations guide written |
| Monitoring | Coverage, build success rate, defect density measured regularly |
The core of Level 4 is quantitative management. Quality metrics are measured numerically, trends are analyzed, and achievement rates against targets are managed. This is the stage where quality management is based on data rather than intuition.
29.4.2.5. Level 5: Optimized
Level 5 is the state where both mandatory and recommended items are 100% satisfied and a continuous improvement process is in operation. This corresponds to TQS Premier Certification.
| Domain | Level 5 Status |
|---|---|
| Code Style | Level 4 met + team-led convention improvement activities |
| Project Structure | All mandatory/recommended items 100% satisfied |
| Testing | Line coverage 90% or above, E2E tests included |
| Configuration Management | Level 4 met + release automation |
| CI/CD | Level 4 met + zero-downtime deployment, canary deployment |
| Security | Level 4 met + periodic security audits, penetration testing |
| Documentation | Level 4 met + Architecture Decision Records (ADR) |
| Improvement Activities | Regular retrospectives, KPI-based improvement goal setting and achievement |
The core of Level 5 is continuous improvement. Rather than being satisfied with the current level, improvement opportunities are explored based on data, and new technologies and methodologies are actively adopted. Level 5 projects are registered as internal technical best practices and serve as benchmarks for other projects.
29.4.3. Self-Assessment Guide
Diagnostic criteria are provided for each level so that project teams can self-assess their current maturity level.
29.4.3.1. Diagnostic Criteria Table
For each item in the following tables, determine "Satisfied" or "Not Satisfied." All items for a given level must be satisfied to be recognized at that level.
Level 1 to Level 2 Transition Diagnosis
| No. | Diagnostic Item | Satisfaction Criteria |
|---|---|---|
| 1 | Is a formatter configuration file included in the project? | .editorconfig or formatter configuration file exists |
| 2 | Is a basic layered structure applied? | Controller-Service-Repository separation |
| 3 | Does test code exist? | At least 1 test class exists |
| 4 | Is a branch strategy defined? | main/feature branch distinction in use |
| 5 | Is a CI pipeline configured? | Build automation configured |
| 6 | Is the .gitignore file properly configured? | Build artifacts, IDE configuration files excluded |
Level 2 to Level 3 Transition Diagnosis
| No. | Diagnostic Item | Satisfaction Criteria |
|---|---|---|
| 1 | Are all TQS mandatory checklist items passed? | 100% fulfillment of applicable category mandatory items |
| 2 | Are formatters/linters automatically verified in CI? | Lint stage included in CI pipeline |
| 3 | Is the test coverage threshold met? | Line 80%, branch 70% or above |
| 4 | Are Conventional Commits applied? | Commit message format compliance |
| 5 | Is a PR review process in operation? | Minimum 1-person review before merge |
| 6 | Are basic security items applied? | TLS, BCrypt, Bean Validation, RBAC |
| 7 | Is API documentation automatically generated? | SpringDoc/Swagger UI configuration complete |
Level 3 to Level 4 Transition Diagnosis
| No. | Diagnostic Item | Satisfaction Criteria |
|---|---|---|
| 1 | Is the recommended item fulfillment rate 80% or above? | Recommended checklist 80% or above |
| 2 | Are code quality metrics measured regularly? | Measured at least once per month |
| 3 | Is the test coverage 85% or above? | Line coverage 85% or above |
| 4 | Is security scanning integrated into CI? | OWASP Dependency-Check or equivalent tool |
| 5 | Are quality metric trends being tracked? | Dashboard or report exists |
Level 4 to Level 5 Transition Diagnosis
| No. | Diagnostic Item | Satisfaction Criteria |
|---|---|---|
| 1 | Are all recommended items 100% satisfied? | Recommended checklist 100% |
| 2 | Is a continuous improvement process in operation? | Regular retrospectives, improvement goal setting |
| 3 | Is the test coverage 90% or above? | Line coverage 90% or above |
| 4 | Are E2E tests included? | E2E test automation |
| 5 | Is zero-downtime deployment implemented? | No service interruption during deployment |
| 6 | Is there a history of KPI-based improvement activities? | Minimum 2 improvement case studies |
29.4.3.2. Current Level Determination Method
The method for determining the current maturity level is as follows.
- Start from Level 1 and diagnose sequentially toward higher levels.
- If all diagnostic items for a given level are "Satisfied," proceed to the next level.
- If even one item is "Not Satisfied," the previous level is the current level.
- For example, if there are unsatisfied items in the Level 2 to Level 3 diagnosis, the current level is Level 2.
Self-assessment must be performed before applying for a TQS certification audit. Projects with self-assessment results below Level 3 are not eligible to apply for certification audit.
29.4.4. Level Transition Roadmap
Key activities for advancing from the current level to the next level are defined. Each transition includes estimated timeframes and high-priority activities.
29.4.4.1. From Level 1 to Level 2
Estimated timeframe: 2-4 weeks
| Priority | Key Activity | Details |
|---|---|---|
| 1 | Formatter Setup | Configure and apply Google Java Format (backend), Prettier (frontend) |
| 2 | Project Structure Reorganization | Reorganize packages into standard layered structure (Controller-Service-Repository) |
| 3 | CI Pipeline Configuration | Build basic pipeline with build + test automation |
| 4 | Branch Strategy Adoption | Apply GitHub Flow, begin main/feature branch operation |
| 5 | Basic Test Writing | Write unit tests for core business logic |
| 6 | .gitignore Setup | Apply standard .gitignore file |
The transition from Level 1 to Level 2 is the most fundamental but forms the foundation for all subsequent levels. Starting with formatter setup is recommended. Formatter application alone significantly improves code consistency.
29.4.4.2. From Level 2 to Level 3
Estimated timeframe: 4-8 weeks
| Priority | Key Activity | Details |
|---|---|---|
| 1 | TQS Checklist Self-Assessment | Inspect all mandatory items and compile a list of unmet items |
| 2 | Test Coverage Achievement | Write tests to achieve line 80%, branch 70% |
| 3 | CI Pipeline Enhancement | Add lint verification stage, generate coverage reports |
| 4 | Basic Security Item Application | Configure TLS, BCrypt, Bean Validation, Spring Security |
| 5 | Configuration Management Rules Application | Conventional Commits, PR templates, review process |
| 6 | API Documentation Automation | Configure SpringDoc (Swagger UI) |
| 7 | Remaining Item Remediation | Satisfy remaining mandatory items identified during self-assessment |
The transition from Level 2 to Level 3 requires the most effort. Since achieving test coverage takes the most time, starting as early as possible is recommended.
29.4.4.3. From Level 3 to Level 4
Estimated timeframe: 4-6 weeks
| Priority | Key Activity | Details |
|---|---|---|
| 1 | Recommended Item Inspection | Inspect recommended checklist and prioritize achievable items |
| 2 | Quality Metrics Monitoring System Build | Automated measurement environment for coverage, build success rate, defect density |
| 3 | Security Scan CI Integration | Add OWASP Dependency-Check to CI pipeline |
| 4 | Test Coverage Enhancement | Achieve 85% or above, add integration tests |
| 5 | Operations Documentation | Architecture documentation, operations guide, incident response manual |
| 6 | Regular Measurement Process Establishment | Monthly quality metrics measurement and reporting system |
The transition from Level 3 to Level 4 represents a shift from "management" to "measurement." Building a system that quantitatively measures and tracks quality is the key focus.
29.4.4.4. From Level 4 to Level 5
Estimated timeframe: 6-12 weeks
| Priority | Key Activity | Details |
|---|---|---|
| 1 | Remaining Recommended Item Fulfillment | Achieve 100% of unmet recommended items |
| 2 | Continuous Improvement Process Establishment | Regular retrospectives, data-driven improvement goal setting |
| 3 | E2E Test Build | Automate E2E tests for key user scenarios |
| 4 | Zero-Downtime Deployment Implementation | Apply blue-green or canary deployment strategy |
| 5 | Security Hardening | Conduct periodic security audits, penetration testing |
| 6 | Technical Decision Records | Begin writing ADR (Architecture Decision Records) |
| 7 | Team Improvement Activities | Regularize technical debt resolution sprints and code quality improvement activities |
The transition from Level 4 to Level 5 is the most time-consuming interval. Level 5 goes beyond simply satisfying checklists and requires establishing a culture and process of continuous improvement. Projects that reach this level are recognized as best practice examples for technical standards within the organization.