Commit 6d462b

2026-04-02 10:14:20 Melisha Dsouza: Naming Convention Standard
/dev/null .. CMMI/Standard/Naming Convention Standard.md
@@ 0,0 1,252 @@
+ # **Naming Convention Standard**
+
+ _(Approval of the Naming Convention Standard indicates an understanding of the purpose and content described in this document. By signing this document, each individual acknowledges and agrees to follow the defined naming conventions, document classification structure, versioning guidelines, process area codes, and file management practices. This ensures consistency, traceability, and effective document management across all projects and organizational processes within the Quality Management System (QMS).)_
+
+ **Document Revision History**
+
+ | Ver No | Date | Change Information | Author | Approver |
+ |-------|-------------|--------------------|------------------|--------------|
+ | V1.0 | 16 Mar 2026 | Initial Draft | Melisha Dsouza | Pooja Thorat |
+
+ ### **1. Introduction**
+ Effective document management is essential for maintaining consistency, traceability, and organization within project and process documentation. A standardized naming convention helps ensure that all documents and files created across projects and process areas are easily identifiable, searchable, and properly version-controlled.
+
+ This document defines the standard naming conventions for files and artifacts within the Quality Management System (QMS). It provides guidelines for naming documents, spreadsheets, images, videos, diagrams, and other project-related files. By following these conventions, teams can maintain uniformity in documentation practices and support efficient document management across the organization.
+
+ ### **2. Purpose**
+ The purpose of this document is to define a standard naming convention for all documents, files, and artifacts created within the Enovate IT Quality Management System (QMS).
+
+ **This ensures:**
+ - Consistent document naming
+ - Easy document identification
+ - Proper version control
+ - Efficient document organization across projects
+
+ ### **3. Scope**
+ This naming convention applies to all documentation and files created within organizational processes and project environments, including:
+ - Word documents
+ - Spreadsheets
+ - Presentations
+ - Images
+ - Videos
+ - Drawings and diagrams
+ - PDF documents
+ - Text files
+ - Source code files
+ - Archive files
+ All project teams and stakeholders must comply with this naming standard.
+
+ ### **4. Standard Document Naming Structure**
+ In this document, “Documents” refers to formal, text-based files such as Microsoft Word documents (.doc or .docx) used to create requirements, design specifications, procedures, plans, and reports within projects and organizational processes.
+
+ **Examples include:**
+ - Software Requirement Specification (SRS)
+ - High Level Design (HLD)
+ - Low Level Design (LLD)
+ - Project Plans
+ - Procedures
+ - Reports
+ These documents are typically editable files that undergo review, approval, and version control.
+
+ #### **4.1. Documents with Version**
+ This format is used for formal and controlled documents that require version tracking and updates.
+
+ **Format:**
+
+ `EnovateIT_QMS_[ProcessArea]_[DocTypeNumber]_[ProjectName]_[DocName]_V[Version]`
+ Example: `EnovateIT_QMS_TS_DS01_Acanis_HLD_V1.0`
+
+ **These documents usually go through:**
+ - Review and approval processes
+ - Version updates
+ - Document control procedures
+
+ For documents that are organizational standards, policies, procedures, or process assets and are not associated with a specific project, the ProjectName field should be replaced with “Organization”. This indicates that the document applies across the entire organization rather than to a specific project.
+
+ **Example:**
+
+ `EnovateIT_QMS_PCM_P01_Organization_NamingConventionStandard_V1.0`
+
+ #### **4.2. Documents without Version**
+ This format is used for supporting Word documents that do not require formal version control.
+
+ **These may include:**
+ - Code review documents
+ - Supporting checklists
+ - Flow descriptions
+ - Reference notes
+ - Internal review documents
+ **Format:** `EnovateIT_QMS_[ProcessArea]_[ProjectName]_[DocName]_[DDMMYYYY]`
+
+ **Example**: `EnovateIT_QMS_PQA_Acanis_CodeReview_16032026`
+
+ _Note: For these documents, DocTypeNumber is not included because they are typically supporting or reference artifacts that do not require strict version tracking or formal document control._
+
+ ### **5. Naming Convention for Release and Test Plans**
+ Format: `EnovateIT_QMS_[ProjectName]_[PlanName]_V[Version]`
+
+ **Examples:**
+ - EnovateIT_QMS_Acanis_ReleasePlan_V1.0
+ - EnovateIT_QMS_Acanis_TestPlan_V1.0
+
+ ### **6. Naming Convention for Spreadsheets**
+ **Spreadsheets**
+
+ `EnovateIT_QMS_[ProcessArea]_[DocTypeNumber]_[ProjectName]_[DocName]_V[Version]`
+
+ **Example**: `EnovateIT_QMS_PQA_L01_Acanis_DefectLog_V1.0`
+
+ **Traceability Matrix**
+
+ **Format 1**: `TraceabilityMatrix_Client_[ProjectName]_Release_V[Version]`
+
+ **Example:** `TraceabilityMatrix_Client_Acanis_Release_V1.0`
+
+ **Format 2 (Internal QMS format):**
+ `EnovateIT_QMS_[ProcessArea]_RTM_[ProjectName]_V[Version]`
+
+ **Example**: `EnovateIT_QMS_VV_RTM_Acanis_V1.0`
+
+ ### **7. Naming Convention for Other File Types**
+ **Images** `EnovateIT_QMS_(ProcessArea)_(ProjectName)_(ImageName)`
+
+ **Videos** `EnovateIT_QMS_(ProcessArea)_(ProjectName)_(VideoName)`
+
+ **Drawings / Diagrams** `EnovateIT_QMS_(ProcessArea)_(ProjectName)_(DrawingName)`
+
+ **Example**: `EnovateIT_QMS_TS_Acanis_SystemArchitecture`
+
+ ### **8. Sprint Naming Convention**
+ **Format**: `[ProjectKey]_Sprint_[Number]`
+
+ **Example**: `ACM_Sprint_01`
+
+ ### **9. Document Type Codes**
+
+ | Document Type | Code |
+ |------------------|------|
+ | Procedure | P |
+ | Checklist | C |
+ | Log | L |
+ | Form | F |
+ | Plan | PL |
+ | Template | T |
+ | Item List | I |
+ | Report | R |
+ | Drawing | D |
+ | Design Document | DS |
+ | Specification | S |
+
+
+ ### **10. DocTypeNumber**
+ DocTypeNumber represents a combination of the Document Type Code and a unique sequential number assigned to a specific document type.
+
+ **Format**: `DocTypeNumber = Document Type Code + Serial Number`
+ - **PL**- Document Type = **Plan**
+ - **01**- Serial number of that document type
+
+ The number is assigned sequentially for documents under the same Document Type within a process area.
+
+ **Example in file name:**
+ - `EnovateIT_QMS_PQA_PL01_Acanis_TestPlan_V1.0`
+ - `EnovateIT_QMS_PQA_PL02_Acanis_ReleasePlan_V1.0`
+
+ ### **11. Document Categories**
+
+ | Category | Description |
+ |----------|-------------|
+ | Word Documents | Text-based documents used for requirements, design, and reports |
+ | Spreadsheets | Used for logs, matrices, and data tracking |
+ | Presentations | Slide-based documents used for meetings and project presentations |
+ | Images | Graphic files such as screenshots and diagrams |
+ | Videos | Demonstration or training recordings |
+ | Drawings / Diagrams | System architecture and workflow diagrams |
+ | PDF Documents | Finalized documents shared in non-editable format |
+ | Text Files | Plain text files used for notes or configurations |
+ | Source Code Files | Programming files used in application development |
+ | Archive Files | Compressed files used for storing multiple documents |
+
+ ### **12. General File Restrictions**
+ To ensure cross-platform compatibility and script-friendliness, all files must adhere to these syntax rules:
+ - **No Spaces:** Use underscores `(_)` instead of spaces.
+ - **Case Sensitivity:** Use PascalCase for descriptive names (e.g., `UserManual`, `not usermanual`).
+ - **Special Characters:** Do NOT use any of the following: `! @ # $ % ^ &( ) + = { } [ ] | \ : ; " ' < > ? / ,`
+ - **Date Format:** When a date is required in a filename (e.g., for Meeting Minutes), use the ISO 8601 format: `YYYYMMDD.`
+
+ ### **13. Email Subject Line Standard**
+ For traceability in communication, all project-related emails should follow this format: `[ProjectID] [ProcessArea] - [Subject Brief]`
+
+ **Example**: `[ACM] [RDM] - Review of Requirement Specs V0.1`
+
+ ### **14. Versioning Guidelines**
+ To maintain a clear distinction between "Work in Progress" and "Approved" documents, the following sub-versioning rules apply:
+
+ **Version format:** `V[Major].[Minor]`
+
+ | Ver | Status | Description |
+ |-------|-----------------|-------------|
+ | V0.x | Draft | Initial creation and internal team reviews (e.g., V0.1, V0.2) |
+ | V1.0 | Approved | First formal release after stakeholder sign-off |
+ | V1.x | Minor Update | Editorial changes, typo fixes, or small formatting updates |
+ | V2.0 | Major Revision | Significant change in scope, process, or project requirements |
+
+ ### **15. Compliance**
+ All project teams must follow this naming convention to maintain consistency, traceability, and organized documentation across the organization.
+
+ The Process Quality Assurance (PQA) team may review documents periodically to ensure compliance with this standard.
+
+ ### **16. Definitions**
+
+ | Term | Definition |
+ |--------------------|------------|
+ | QMS | Quality Management System used to manage organizational processes and documentation |
+ | Process Area | Functional area responsible for specific organizational processes |
+ | Document Type Code | Short identifier used to classify the type of document |
+ | Version | Numeric identifier used to track document revisions |
+ | Artifact | Any document, file, or output generated during project execution |
+
+ ### **17. Process Area Codes**
+
+ | Process Area | Code |
+ |---------------------------------------|------|
+ | Requirement Development Management | RDM |
+ | Estimating | EST |
+ | Planning | PLAN |
+ | Monitoring and Control | MC |
+ | Managing Performance and Measurement | MPM |
+ | Peer Review | PR |
+ | Process Management | PCM |
+ | Product Integration | PI |
+ | Technical Solution | TS |
+ | Process Quality Assurance | PQA |
+ | Configuration Management | CM |
+ | Verification and Validation | VV |
+ | Risk and Opportunity Management | ROM |
+ | Process Asset Development | PAD |
+ | Organizational Training | OT |
+ | Decision Analysis and Resolution | DAR |
+ | Governance | GOV |
+ | Implementation Infrastructure | II |
+ | Causal Analysis and Resolution | CAR |
+ | Supplier Agreement Management | SAM |
+
+ ### **18. Document Control**
+ All documents following this naming convention must be:
+ - Stored in the approved project repository
+ - Maintained with version control
+ - Reviewed periodically by the QA or process team
+ - Updated whenever significant changes occur
+
+ ### **19. Abbreviations**
+
+ | Abbreviation | Full Form |
+ |--------------|-----------|
+ | QMS | Quality Management System |
+ | SRS | Software Requirement Specification |
+ | HLD | High-Level Design |
+ | LLD | Low-Level Design |
+ | RTM | Requirements Traceability Matrix |
+ | PQA | Process Quality Assurance |
+ | SDLC | Software Development Life Cycle |
+
+ [The document can be accessed and downloaded from the following link](https://docs.google.com/document/d/1-W37LGdJ9Km6REh6BwGCtksbtQB17bsj1hS8rpqRvJE/edit)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9