Khung kiến trúc quy trình vòng đời quốc tế
Sơ đồ khối luồng tổng thể 7 giai đoạn (ISO/IEC/IEEE 12207:2017 & SWEBOK v4.0)
Giai đoạn 1
Xác định & Phân tích Yêu cầu
Bước 1 – Bước 5
Điểm then chốt: Khai thác nhu cầu, phân tích tính khả thi, đặc tả SRS/IRD, thẩm định và chốt Requirements Baseline qua Hội đồng CCB.
Giai đoạn 2
Định nghĩa Kiến trúc & Thiết kế
Bước 6 – Bước 10
Điểm then chốt: Phân rã kiến trúc tĩnh/động, thiết kế API & DB, thiết kế module chi tiết, Threat Modeling và chốt Design Baseline (PDR/CDR).
Giai đoạn 3
Xây dựng & Tích hợp Phần mềm
Bước 11 – Bước 15
Điểm then chốt: Lập trình tuân thủ an toàn, Unit Testing & Code Review, tích hợp CI/CD tự động và đánh giá sẵn sàng thử nghiệm (TRR).
Giai đoạn 4
Kiểm thử và xác nhận
Bước 16 – Bước 20
Điểm then chốt: Lập kế hoạch kiểm thử, xác nhận phần mềm trung gian, kiểm thử hệ thống & an ninh, nghiệm thu UAT và phê duyệt QR.
Giai đoạn 5
Chuyển giao & Triển khai
Bước 21 – Bước 25
Điểm then chốt: Đóng gói bản phát hành, chuyển đổi dữ liệu Prod, Smoke Test kiểm tra tính toàn vẹn và ký Biên bản Nghiệm thu Bàn giao (AR).
Giai đoạn 6
Vận hành và khai thác
Bước 26 – Bước 30
Điểm then chốt: Giám sát tự động 24/7 (Telemetry/Logs), đảm bảo cam kết SLA/SLO, hỗ trợ Helpdesk L1–L3 và sao lưu bảo mật hệ thống.
Giai đoạn 7
Bảo trì, nâng cấp hoặc chấm dứt hoạt động
Bước 31 – Bước 35
Điểm then chốt: Tiếp nhận MR/PR, sửa lỗi hồi quy, phát hành Patch/Release qua CCB, lập kế hoạch lưu trữ an toàn và ngừng vận hành hệ thống.
Tài liệu tham khảo & Căn cứ quy chuẩn quốc tế
Căn cứ quy chuẩn
Hệ thống quy trình phát triển phần mềm toàn trình 7 giai đoạn được xây dựng và chuẩn hóa dựa trên các tài liệu quy chuẩn kỹ thuật và cẩm nang tri thức quốc tế:
Tiêu chuẩn quốc tế
ISO/IEC/IEEE 12207:2017 — Systems and software engineering — Software life cycle processes
Tiêu chuẩn quốc tế quy định khung quy trình vòng đời phần mềm toàn diện, xác định chi tiết các tiến trình kỹ thuật (Technical Processes), hoạt động thực hiện và sản phẩm bàn giao từ giai đoạn xác định nhu cầu, phân tích yêu cầu, kiến trúc, thiết kế, lập trình, tích hợp, kiểm thử (V&V), chuyển giao, đến vận hành và bảo trì/hủy bỏ hệ thống.
Khung tri thức ngành
SWEBOK v4.0 (IEEE Computer Society) — Guide to the Software Engineering Body of Knowledge
Cẩm nang tri thức cốt lõi về kỹ nghệ phần mềm do IEEE Computer Society ban hành, cung cấp các nguyên lý lý thuyết, thuật ngữ chuyên ngành chuẩn hóa và các phương pháp thực hành kỹ thuật tốt nhất (best practices) cho từng chuyên môn trong dự án phần mềm.
Tiêu chuẩn bổ trợ
NIST SP 800-218 (SSDF) & ISO/IEC/IEEE 29119
Khung phát triển phần mềm an toàn NIST SP 800-218 (Secure Software Development Framework) nhằm kiểm soát an toàn chuỗi cung ứng, bảo mật mã nguồn và quản lý lỗ hổng; kết hợp bộ tiêu chuẩn quốc tế ISO/IEC/IEEE 29119 về các quy trình, tài liệu và kỹ thuật kiểm thử phần mềm hoàn chỉnh.
Lọc theo vai trò:
Giai đoạn 1
Xác định và Phân tích Yêu cầu Phần mềm
Bảng phân nhiệm & các bước quy chuẩn Giai đoạn 1
Bước 1 – Bước 5
| Bước | Diễn giải, mục tiêu, kết quả đầu ra & rẽ nhánh | Phân cấp trách nhiệm (RACI) |
|---|---|---|
| 1 |
Bước 1: KHAI THÁC YÊU CẦU (REQUIREMENTS ELICITATION)Mục tiêu: Thu thập đầy đủ, chính xác nhu cầu, nguyện vọng, mục tiêu sứ mệnh và các ràng buộc từ tất cả các bên liên quan (Stakeholders) cũng như từ các tài liệu quy chuẩn và hệ thống liên quan.
Cách thức thực hiện: Nhận diện các nguồn yêu cầu (người dùng, hệ thống cũ, quy chuẩn an ninh/bảo mật, tiêu chuẩn ngành). Sử dụng các kỹ thuật như phỏng vấn sâu, hội thảo JRP/JAD, quan sát thực địa, khảo sát, xây dựng kịch bản Use Case / User Story và áp dụng Tư duy Thiết kế (Design Thinking) để khám phá cả các nhu cầu ẩn.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá tính đầy đủ của nguồn thông tin và mức độ bao phủ các nhóm bên liên quan. Nếu thông tin thu thập bị mâu thuẫn nặng, thiếu hụt thông tin từ các bên liên quan trọng yếu hoặc không rõ mục tiêu: Quay lại bước tái nhận diện nguồn yêu cầu và tổ chức lại các phiên làm việc JRP/JAD với Khách hàng/SMEs trước khi chuyển sang bước Phân tích.
|
[Chủ trì (A)] Product Owner (PO)[Thực hiện (R)] Business Analyst (BA)[Tham vấn (C)] Project Manager (PM), Software Architect (SA), UI/UX Designer (UI/UX), Technical Lead (Tech Lead), Quality Control / Tester (QC), Security Lead (Sec Lead)
|
| 2 |
Bước 2: PHÂN TÍCH YÊU CẦU (REQUIREMENTS ANALYSIS)Mục tiêu: Hiểu rõ ý nghĩa, mối quan hệ, tính khả thi và tác động của các yêu cầu thô; phân loại, mô hình hóa và đàm phán giải quyết các mâu thuẫn giữa các bên liên quan.
Cách thức thực hiện: Phân loại yêu cầu thành Chức năng, Phi chức năng / Chất lượng dịch vụ (QoS: hiệu năng, độ tin cậy), Ràng buộc Công nghệ, An toàn & Bảo mật. Xây dựng mô hình lô-gíc (UML/SysML, sơ đồ luồng dữ liệu, sơ đồ trạng thái). Phân tích tính khả thi kỹ thuật/chi phí và đàm phán giải quyết các yêu cầu xung đột.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác nhận tính khả thi kỹ thuật và sự thống nhất của các bên liên quan về phương án đánh đổi. • Nếu yêu cầu bất khả thi về kỹ thuật hoặc vượt quá ngân sách/thời gian: Chuyển đàm phán với Khách hàng để giảm phạm vi (Descope) hoặc tìm giải pháp thay thế. • Nếu phát hiện lỗ hổng tri thức do thiếu thông tin nghiệp vụ: Quay lại Bước 1 (Khai thác Yêu cầu) để phỏng vấn bổ sung.
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] Business Analyst (BA)[Tham vấn (C)] Product Owner (PO), Software Architect (SA), UI/UX Designer (UI/UX), Database Administrator (DBA), Technical Lead (Tech Lead), Quality Control / Tester (QC), Security Lead (Sec Lead)
|
| 3 |
Bước 3: ĐẶC TẢ YÊU CẦU (REQUIREMENTS SPECIFICATION)Mục tiêu: Chuẩn hóa toàn bộ yêu cầu đã phân tích thành tài liệu chính thức (SRS/StRS) theo tiêu chuẩn quy định, đảm bảo từng yêu cầu có tính không mơ hồ, kiểm thử được, nguyên tử và truy xuất được.
Cách thức thực hiện: Biên soạn tài liệu bằng Ngôn ngữ tự nhiên có cấu trúc, mô hình hóa hoặc kịch bản kiểm thử nghiệm thu (BDD/ATDD / Acceptance Criteria). Gán các thuộc tính phụ trợ cho từng yêu cầu (Mã định danh ID duy nhất, Mức độ ưu tiên, Lý do tồn tại/Rationale, Tiêu chí kiểm thử nghiệm thu) và lập Ma trận Truy xuất (Traceability Matrix).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá độ hoàn thiện và chất lượng văn bản đặc tả (kiểm tra các thuộc tính: Unambiguous, Testable, Atomic, Complete). • Nếu văn bản còn mơ hồ, thiếu tiêu chí kiểm thử hoặc không thể truy xuất: Yêu cầu BA chỉnh sửa, chuẩn hóa lại văn bản. • Nếu phát hiện mâu thuẫn logic mới phát sinh: Quay lại Bước 2 (Phân tích Yêu cầu) để tái phân tích.
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] Business Analyst (BA)[Tham vấn (C)] Product Owner (PO), Software Architect (SA), UI/UX Designer (UI/UX), Database Administrator (DBA), Technical Lead (Tech Lead), Software Quality Assurance (SQA), Quality Control / Tester (QC), Software Configuration Manager (SCM), Security Lead (Sec Lead)
|
| 4 |
Bước 4: THẨM ĐỊNH YÊU CẦU (REQUIREMENTS VALIDATION)Mục tiêu: Xác nhận và đạt được sự đồng thuận chính thức từ Khách hàng/Bên liên quan rằng bản đặc tả SRS thể hiện chính xác và đầy đủ nhu cầu thực tế trước khi phê duyệt.
Cách thức thực hiện: Tổ chức đợt rà soát chính thức (Software Requirements Review - SWRR / Formal Inspection) đa góc nhìn (Khách hàng, Lập trình viên, Kiểm thử viên). Sử dụng các bản mẫu UI/UX (Prototyping) hoặc mô phỏng (Simulation) để khách hàng trực tiếp kiểm tra và xác nhận.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Quyết định phê duyệt bản Đặc tả Yêu cầu Phần mềm (Đạt / Đạt có điều kiện / Không đạt). • Nếu sai lệch do hiểu lầm nghiệp vụ cốt lõi hoặc thiếu tính năng quan trọng: Quay lại Bước 1 & Bước 2 để khai thác lại và tái phân tích. • Nếu chỉ là lỗi diễn đạt hoặc mô tả chưa rõ ràng: Quay lại Bước 3 (Đặc tả) để cập nhật lại văn bản trước khi rà soát lại.
|
[Chủ trì (A)] Product Owner (PO)[Thực hiện (R)] Business Analyst (BA), Quality Control / Tester (QC)[Tham vấn (C)] Project Manager (PM), Software Architect (SA), UI/UX Designer (UI/UX), Database Administrator (DBA), Technical Lead (Tech Lead), Software Quality Assurance (SQA), Security Lead (Sec Lead)
|
| 5 |
Bước 5: QUẢN LÝ YÊU CẦU & THIẾT LẬP CƠ SỞ (REQUIREMENTS MANAGEMENT & BASELINING)Mục tiêu: Phê duyệt chính thức Tập yêu cầu cơ sở (Requirements Baseline), vận hành quy trình kiểm soát Yêu cầu Thay đổi (CR) và duy trì ma trận truy xuất xuyên suốt vòng đời phát triển.
Cách thức thực hiện: Trình bộ hồ sơ SRS/IRD đã thẩm định lên Hội đồng Kiểm soát Cấu hình (CCB) để chốt Baseline. Vận hành quy trình kiểm soát thay đổi (tiếp nhận CR, phân tích tác động về chi phí/lịch trình/kỹ thuật, CCB quyết định, cập nhật baseline và thông báo cho các bên).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: CCB quyết định phê duyệt đóng gói Baseline hoặc Phê duyệt / Bác bỏ một Yêu cầu Thay đổi (CR). Xử lý khi có Yêu cầu Thay đổi (CR) phát sinh sau Baseline: • Nếu CCB Từ chối (Reject): Giữ nguyên Baseline hiện tại, phản hồi lý do cho bên đề xuất. • Nếu CCB Chấp thuận (Approve): Kích hoạt luồng cập nhật bằng cách Quay lại Bước 2 (Phân tích Tác động) -> Bước 3 (Đặc tả lại) -> Bước 4 (Thẩm định lại phạm vi thay đổi) -> Cập nhật và phát hành phiên bản Baseline mới (v1.1, v2.0...). --- HẾT ---
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] Business Analyst (BA), Software Configuration Manager (SCM)[Tham vấn (C)] Product Owner (PO), Software Quality Assurance (SQA)
|
Sơ đồ luồng kỹ thuật Giai đoạn 1
Giai đoạn 2
Định nghĩa Kiến trúc và Thiết kế Phần mềm
Bảng phân nhiệm & các bước quy chuẩn Giai đoạn 2
Bước 6 – Bước 10
| Bước | Diễn giải, mục tiêu, kết quả đầu ra & rẽ nhánh | Phân cấp trách nhiệm (RACI) |
|---|---|---|
| 6 |
Bước 6: PHÂN RÃ & ĐỊNH NGHĨA KIẾN TRÚC PHẦN MỀM (SOFTWARE ARCHITECTURAL SYNTHESIS & DECOMPOSITION)Mục tiêu: Chuyển đổi các yêu cầu chức năng, phi chức năng và ràng buộc từ Đặc tả Yêu cầu (SRS) thành cấu trúc kiến trúc tổng thể (tĩnh và động), lựa chọn kiểu kiến trúc và phân rã hệ thống thành các mô-đun/thành phần cấp cao.
Cách thức thực hiện: Lựa chọn kiểu kiến trúc phù hợp (Architectural Styles/Patterns: Layered, Microservices, Event-Driven, Component-Based...). Phân rã cấu trúc tĩnh (Packages, Subsystems, Classes) và cấu trúc động (Tasks, Threads, Processes, Sequence Diagrams). Đánh giá sự đánh đổi giữa các chỉ số chất lượng (Hiệu năng vs. Bảo mật vs. Tính dễ bảo trì).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá tính đáp ứng của kiến trúc đối với các chỉ số chất lượng (QoS) và tính khả thi về mặt hạ tầng công nghệ. Nếu kiến trúc không đáp ứng được chỉ số hiệu năng hoặc độ tin cậy bắt buộc: Tiến hành thiết kế lại phương án kiến trúc mới (khái niệm lại architectural patterns). Nếu phát hiện yêu cầu SRS chưa rõ ràng hoặc không thể khả thi ở cấp kiến trúc: Quay lại Giai đoạn 1 (Bước 2: Phân tích / Bước 3: Đặc tả lại SRS) để điều chỉnh phạm vi.
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] Software Architect (SA)[Tham vấn (C)] UI/UX Designer (UI/UX), Database Administrator (DBA), Technical Lead (Tech Lead), Software Quality Assurance (SQA), DevOps Engineer (DevOps), Site Reliability Engineer (SRE), System Administrator (SysAdmin), Security Lead (Sec Lead)
|
| 7 |
Bước 7: THIẾT KẾ GIAO DIỆN VÀ MÔ HÌNH DỮ LIỆU (INTERFACE & DATA DESIGN)Mục tiêu: Định nghĩa chuẩn hóa toàn bộ các giao diện tương tác bên ngoài (External APIs/ICDs) và giao diện nội bộ giữa các thành phần phần mềm, cùng với thiết kế cấu trúc dữ liệu toàn cục/CSDL.
Cách thức thực hiện: Thiết kế giao diện ngoại vi (với phần cứng, hệ thống bên thứ ba, giao diện mạng) và giao diện nội bộ (bản tin, API endpoints, gRPC/REST protocols). Thiết kế mô hình dữ liệu (Conceptual/Logical/Physical Data Model), cấu trúc CSDL (Relational / NoSQL), chiến lược lưu trữ và bảo mật dữ liệu.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá độ tương thích giao diện, tính toàn vẹn dữ liệu và chuẩn an ninh truyền thông (TLS, OAuth2...). Nếu giao diện xung đột với hệ thống bên ngoài hoặc không đảm bảo băng thông/độ trễ: Yêu cầu thiết kế lại giao thức và định dạng dữ liệu (Payload format/protocol revision). Nếu cấu trúc CSDL không đảm bảo tính nhất quán (ACID) hoặc khả năng mở rộng: Yêu cầu tinh chỉnh lại sơ đồ ERD hoặc chiến lược phân tán CSDL.
|
[Chủ trì (A)] Product Owner (PO)[Thực hiện (R)] UI/UX Designer (UI/UX)[Tham vấn (C)] Project Manager (PM), Software Architect (SA), Technical Lead (Tech Lead), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev), Quality Control / Tester (QC)
|
| 8 |
Bước 8: THIẾT KẾ CHI TIẾT THÀNH PHẦN VÀ THUẬT TOÁN (DETAILED COMPONENT DESIGN)Mục tiêu: Phân rã các thành phần kiến trúc cấp cao thành các đơn vị phần mềm (Software Units) chi tiết có thể lập trình được, bao gồm cấu trúc thuật toán, xử lý ngoại lệ và quản lý tài nguyên.
Cách thức thực hiện: Chi tiết hóa thuật toán nội bộ của từng hàm/lớp/mô-đun (sử dụng Pseudo-code, Activity Diagrams, Statechart Diagrams). Thiết kế cơ chế xử lý lỗi/ngoại lệ (Exception handling), quản lý bộ nhớ, tiến trình song song (Concurrency) và thiết lập tiêu chuẩn mã hóa chi tiết (Coding Standards, SOLID).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá tính khả thi trong lập trình, mức độ hoàn thiện thuật toán và tính kiểm thử được của các đơn vị (Unit Testability). Nếu thuật toán quá phức tạp, nguy cơ gây nghẽn hiệu năng hoặc rò rỉ tài nguyên: Yêu cầu tối ưu hóa cấu trúc dữ liệu / thuật toán. Nếu phát hiện vi phạm nguyên tắc thiết kế SOLID hoặc coupling quá cao: Refactor lại thiết kế thành phần trước khi cho phép bắt đầu code.
|
[Chủ trì (A)] Software Architect (SA)[Thực hiện (R)] Database Administrator (DBA)[Tham vấn (C)] Technical Lead (Tech Lead), Back-End Developer (BE Dev), DevOps Engineer (DevOps), Site Reliability Engineer (SRE), Security Lead (Sec Lead)
|
| 9 |
Bước 9: RÀ SOÁT THIẾT KẾ, PHÂN TÍCH AN NINH VÀ MÔ HÌNH HÓA MỐI ĐE DỌA (DESIGN REVIEW & THREAT MODELING)Mục tiêu: Thẩm định độc lập toàn bộ bản thiết kế kiến trúc và thiết kế chi tiết nhằm phát hiện sớm các lỗi thiết kế, nguy cơ an ninh thông tin và đánh giá rủi ro kỹ thuật trước khi viết code.
Cách thức thực hiện: Thực hiện mô hình hóa mối đe dọa an ninh (Threat Modeling - ví dụ khung STRIDE/PASTA) để tìm lỗ hổng kiến trúc. Tổ chức các đợt rà soát thiết kế chính thức (Software Design Review / Architecture Review) với các chuyên gia độc lập, phân tích rủi ro kỹ thuật và đánh giá khả năng duy trì/tái sử dụng mã nguồn.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá phê duyệt hồ sơ Kiến trúc và Thiết kế chi tiết (Conditional Pass / Fail). Nếu phát hiện lỗ hổng an ninh kiến trúc nghiêm trọng hoặc vi phạm ràng buộc kỹ thuật cốt lõi: Hội đồng Kiến trúc bác bỏ phê duyệt; Quay lại Bước 1 hoặc Bước 2 của Giai đoạn này để thiết kế lại trước khi tổ chức rà soát lại.
|
[Chủ trì (A)] Software Architect (SA)[Thực hiện (R)] Technical Lead (Tech Lead), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev)[Tham vấn (C)] Database Administrator (DBA), Front-End Developer (FE Dev), Mobile Developer (Mobile Dev), Quality Control / Tester (QC), Automation Test Engineer (Auto Test), Security & Performance Tester (Sec/Perf Tester), Security Lead (Sec Lead)
|
| 10 |
Bước 10: LẬP KẾ HOẠCH TÍCH HỢP, V&V VÀ CHỐT CƠ SỞ THIẾT KẾ (DESIGN BASELINING & STRATEGY)Mục tiêu: Xây dựng chiến lược tích hợp phần mềm, kế hoạch xác minh & xác nhận (V&V), và phê duyệt chính thức Tập cơ sở thiết kế (Design Baseline - PDR/DDR) làm chuẩn cho Giai đoạn Xây dựng.
Cách thức thực hiện: Xây dựng Chiến lược Tích hợp Phần mềm (Top-down, Bottom-up, Continuous Integration). Soạn thảo Kế hoạch Xác minh & Xác nhận (SVerP, SValP). Trình toàn bộ Hồ sơ Thiết kế (SAD, SDD, ICD, Threat Model) lên Hội đồng Kiểm soát Cấu hình (CCB) hoặc Ban Đánh giá Thiết kế Sơ bộ/Chi tiết (PDR/DDR) để phê duyệt chốt Baseline.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Hội đồng Thẩm định cấp phép đóng gói Baseline Thiết kế tại cột mốc PDR/CDR. Nếu không đạt cột mốc PDR/CDR: Không cấp phép chuyển sang Giai đoạn 3 (Xây dựng). Quay lại các bước thiết kế trước đó để hoàn thiện hồ sơ. Khi có yêu cầu thay đổi thiết kế sau Baseline: Kích hoạt quy trình CCB để kiểm soát cập nhật phiên bản kiến trúc.
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] Software Architect (SA), Software Configuration Manager (SCM)[Tham vấn (C)] UI/UX Designer (UI/UX), Database Administrator (DBA), Technical Lead (Tech Lead), Software Quality Assurance (SQA), DevOps Engineer (DevOps), Security Lead (Sec Lead)
|
Sơ đồ luồng kỹ thuật Giai đoạn 2
Giai đoạn 3
Xây dựng / Lập trình và Tích hợp Phần mềm
Bảng phân nhiệm & các bước quy chuẩn Giai đoạn 3
Bước 11 – Bước 15
| Bước | Diễn giải, mục tiêu, kết quả đầu ra & rẽ nhánh | Phân cấp trách nhiệm (RACI) |
|---|---|---|
| 11 |
Bước 11: LẬP TRÌNH VÀ TUÂN THỦ TIÊU CHUẨN MÃ NGUỒN AN TOÀN (SECURE & STANDARDIZED CODING)Mục tiêu: Hiện thực hóa bản thiết kế chi tiết (SDD) thành các đơn vị mã nguồn (Software Units) chất lượng cao, tuân thủ nghiêm ngặt quy chuẩn mã hóa và tiêu chuẩn an toàn thông tin.
Cách thức thực hiện: Lập trình mã nguồn theo các tiêu chuẩn mã hóa quy định (Coding Standards), áp dụng các thực hành lập trình an toàn (Secure Coding Practices - kiểm soát đầu vào, mã hóa đầu ra, phòng chống OWASP Top 10), và tái sử dụng các thư viện mã nguồn mở/bên thứ ba đã qua kiểm duyệt an toàn (SBOM).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác nhận mã nguồn tuân thủ Coding Standards và Quy trình mã nguồn an toàn. Nếu mã nguồn vi phạm quy chuẩn mã hóa hoặc sử dụng các thư viện cấm/lỗ hổng bảo mật đã biết (CVE): Từ chối tích hợp, yêu cầu lập trình viên hiệu chỉnh và quét lại mã nguồn cho đến khi đạt chuẩn.
|
[Chủ trì (A)] Software Architect (SA)[Thực hiện (R)] Technical Lead (Tech Lead), DevOps Engineer (DevOps)[Tham vấn (C)] Database Administrator (DBA), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev), Software Quality Assurance (SQA), System Administrator (SysAdmin), Software Configuration Manager (SCM), Security Lead (Sec Lead)
|
| 12 |
Bước 12: KIỂM THỬ ĐƠN VỊ VÀ PHÂN TÍCH MÃ NGUỒN (UNIT TESTING & CODE ANALYSIS / REVIEW)Mục tiêu: Xác minh tính đúng đắn logic của từng đơn vị phần mềm độc lập, phát hiện sớm lỗi cú pháp, rò rỉ bộ nhớ và các lỗ hổng an ninh mã nguồn trước khi thực hiện tích hợp.
Cách thức thực hiện: Xây dựng và chạy các kịch bản kiểm thử đơn vị tự động (Automated Unit Tests) đạt tỷ lệ bao phủ mã (Code Coverage: Statement/Branch Coverage). Thực hiện rà soát mã đồng nghiệp (Peer Review) và quét mã tự động bằng công cụ phân tích tĩnh (SAST - Static Application Security Testing).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Tỷ lệ bao phủ kiểm thử đơn vị >= 80% (hoặc ngưỡng quy định) và không còn lỗi Severity High/Critical. • Nếu tỷ lệ bao phủ chưa đạt hoặc có unit test thất bại: Trả lại mã nguồn cho lập trình viên bổ sung test case và sửa lỗi. • Nếu phát hiện lỗi logic thiết kế cấp thấp: Quay lại Giai đoạn 2 (Bước 3: Thiết kế Chi tiết) để hiệu chỉnh thuật toán trước khi viết lại mã nguồn.
|
[Chủ trì (A)] Technical Lead (Tech Lead)[Thực hiện (R)] Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev)[Tham vấn (C)] Scrum Master (SM), Software Architect (SA), UI/UX Designer (UI/UX), Database Administrator (DBA), Software Configuration Manager (SCM)
|
| 13 |
Bước 13: TÍCH HỢP PHẦN MỀM VÀ TỰ ĐỘNG HÓA BUILD (SOFTWARE INTEGRATION & CONTINUOUS BUILD)Mục tiêu: Hợp nhất các đơn vị phần mềm đơn lẻ thành các cụm thành phần và bản đóng gói hệ thống hoàn chỉnh theo chiến lược tích hợp đã lập kế hoạch.
Cách thức thực hiện: Áp dụng quy trình Tích hợp Liên tục (CI - Continuous Integration). Thực hiện hợp nhất mã nguồn (Merge Code), xử lý xung đột (Merge Conflicts), biên dịch tự động (Automated Build) và tạo bản đóng gói thực thi (Executable Packages / Binary Artifacts / Docker Images).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Bản build tự động thành công và xác nhận tính toàn vẹn của tệp thực thi. Nếu biên dịch thất bại (Build Broken) hoặc xung đột phiên bản mã nguồn: Lập tức chặn tiến trình CI, thông báo cho lập trình viên vừa commit để sửa lỗi khẩn cấp trong vòng 30 phút hoặc revert commit về phiên bản ổn định gần nhất.
|
[Chủ trì (A)] Technical Lead (Tech Lead)[Thực hiện (R)] Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev)[Tham vấn (C)] Software Quality Assurance (SQA), Quality Control / Tester (QC), Automation Test Engineer (Auto Test), DevOps Engineer (DevOps)
|
| 14 |
Bước 14: KIỂM THỬ TÍCH HỢP PHẦN MỀM (SOFTWARE INTEGRATION TESTING)Mục tiêu: Xác minh khả năng tương tác, giao tiếp và truyền nhận dữ liệu chính xác giữa các đơn vị/thành phần phần mềm sau khi tích hợp.
Cách thức thực hiện: Lập kịch bản và thực thi kiểm thử giao diện nội bộ (Internal API Testing, Component Integration Testing). Thử nghiệm kiểm tra luồng dữ liệu liên mô-đun, quản lý tài nguyên đồng thời và các kịch bản ngoại lệ khi các mô-đun phối hợp hoạt động.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: 100% các ca kiểm thử tích hợp chính vượt qua thành công, không có lỗi giao dịch hợp nghiêm trọng. • Nếu phát hiện lỗi giao tiếp giữa các mô-đun: Phân loại lỗi thuộc về mô-đun nào để yêu cầu lập trình viên tương ứng sửa chữa (Quay lại Bước 1). • Nếu lỗi do hiểu sai đặc tả giao diện (API Spec mismatch): Quay lại Giai đoạn 2 (Bước 2: Thiết kế Giao diện & CSDL) để đồng bộ hóa lại định nghĩa API.
|
[Chủ trì (A)] Software Architect (SA)[Thực hiện (R)] Technical Lead (Tech Lead), Security Lead (Sec Lead)[Tham vấn (C)] Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev), Software Quality Assurance (SQA), Security & Performance Tester (Sec/Perf Tester), DevOps Engineer (DevOps)
|
| 15 |
Bước 15: ĐÁNH GIÁ SẴN SÀNG THỬ NGHIỆM VÀ CHỐT CƠ SỞ XÂY DỰNG (CONSTRUCTION BASELINING & TRR)Mục tiêu: Đánh giá toàn bộ kết quả xây dựng, kiểm thử đơn vị và tích hợp để chốt Tập cơ sở xây dựng (Construction Baseline) và xác nhận phần mềm đủ điều kiện chuyển sang Giai đoạn V&V (Kiểm thử Hệ thống).
Cách thức thực hiện: Kiểm tra tính hoàn thiện của mã nguồn, tài liệu hướng dẫn người dùng sơ bộ (Draft SUM) và bộ hồ sơ thiết kế cập nhật (As-built SDD). Tổ chức đợt Đánh giá Sẵn sàng Thử nghiệm (TRR - Test Readiness Review) hoặc Đánh giá Thiết kế Tối quan trọng (CDR - Critical Design Review) với các bên liên quan.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Quyết định cấp phép bàn giao gói phần mềm nội bộ (Internal Passed / Failed). Nếu còn lỗi tích hợp tồn đọng mức High/Critical hoặc chưa vượt qua bộ kiểm thử hồi quy: Từ chối bàn giao cho đội Kiểm thử độc lập (Giai đoạn 4); yêu cầu đội phát triển tiếp tục hoàn thiện và thực hiện lại Bước 4 (Kiểm thử Tích hợp).
|
[Chủ trì (A)] Technical Lead (Tech Lead)[Thực hiện (R)] DevOps Engineer (DevOps), Software Configuration Manager (SCM)[Tham vấn (C)] Software Architect (SA), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev), Automation Test Engineer (Auto Test), Site Reliability Engineer (SRE), System Administrator (SysAdmin), Security Lead (Sec Lead)
|
Sơ đồ luồng kỹ thuật Giai đoạn 3
Giai đoạn 4
Kiểm thử và xác nhận
Bảng phân nhiệm & các bước quy chuẩn Giai đoạn 4
Bước 16 – Bước 20
| Bước | Diễn giải, mục tiêu, kết quả đầu ra & rẽ nhánh | Phân cấp trách nhiệm (RACI) |
|---|---|---|
| 16 |
Bước 16: LẬP KẾ HOẠCH VÀ THIẾT KẾ KIỂM THỬ V&V (V&V PLANNING & TEST DESIGN)Mục tiêu: Xây dựng Kế hoạch V&V tổng thể (theo IEEE 1012 / ISO 12207), thiết kế bộ kịch bản kiểm thử (Test Cases/Scripts) đảm bảo bao phủ 100% các yêu cầu kỹ thuật (SRS), thiết kế kiến trúc (SDD) và các kịch bản sử dụng (Use Cases).
Cách thức thực hiện: Phân tích chi tiết tài liệu SRS, SDD, ICD để biên soạn Kế hoạch V&V (SVerP & SValP). Xây dựng bộ kịch bản kiểm thử chức năng, phi chức năng, giao diện và an ninh dựa trên ma trận truy xuất. Chuẩn bị dữ liệu kiểm thử (Test Data) và phối hợp dựng môi trường thử nghiệm độc lập (Staging/Test Environment).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá tính đầy đủ và độ bao phủ của bộ kịch bản kiểm thử so với yêu cầu SRS (Traceability Coverage Check). - Nếu kịch bản kiểm thử chưa bao phủ hết yêu cầu SRS hoặc phát hiện yêu cầu mơ hồ: Quay lại Giai đoạn 1 (Bước 3: Đặc tả SRS) hoặc bổ sung ngay kịch bản kiểm thử. - Nếu môi trường kiểm thử sai lệch so với môi trường sản xuất: Yêu cầu đội DevOps điều chỉnh cấu hình hạ tầng thử nghiệm.
|
[Chủ trì (A)] Technical Lead (Tech Lead)[Thực hiện (R)] Quality Control / Tester (QC), Automation Test Engineer (Auto Test)[Tham vấn (C)] Software Architect (SA), Database Administrator (DBA), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev), Software Quality Assurance (SQA), DevOps Engineer (DevOps)
|
| 17 |
Bước 17: THỰC THI XÁC MINH PHẦN MỀM (SOFTWARE VERIFICATION EXECUTION)Mục tiêu: Xác minh các sản phẩm kỹ thuật trung gian và mã nguồn tuân thủ đúng các đặc tả thiết kế, quy chuẩn chất lượng và ma trận truy xuất (Đúng quy trình / Doing the thing right).
Cách thức thực hiện: Thực hiện phân tích động (Dynamic Analysis), kiểm tra ma trận truy xuất hai chiều (Requirements-to-Code-to-Test Traceability), rà soát độc lập cấu trúc mã nguồn, đánh giá kết quả kiểm thử đơn vị/tích hợp, và thực hiện phân tích kiểm thử độ bền (Robustness/Stress Testing).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác nhận mức độ tuân thủ quy trình kỹ thuật và tính toàn vẹn của mã nguồn so với hồ sơ thiết kế. - Nếu phát hiện sai lệch nghiêm trọng giữa mã nguồn và thiết kế SDD/SRS: Quay lại Giai đoạn 3 (Sửa code) hoặc Giai đoạn 2 (Điều chỉnh thiết kế). - Nếu ma trận truy xuất bị đứt gãy: Yêu cầu cập nhật bổ sung mã truy xuất ID cho đến khi đạt khớp 100%.
|
[Chủ trì (A)] Software Quality Assurance (SQA)[Thực hiện (R)] Quality Control / Tester (QC)[Tham vấn (C)] Project Manager (PM), Product Owner (PO), Technical Lead (Tech Lead), Automation Test Engineer (Auto Test), Security & Performance Tester (Sec/Perf Tester), Security Lead (Sec Lead)
|
| 18 |
Bước 18: THỰC THI XÁC NHẬN HỆ THỐNG & AN NINH PHẦN MỀM (SYSTEM & SECURITY VALIDATION EXECUTION)Mục tiêu: Đánh giá toàn bộ hệ thống phần mềm trong môi trường thử nghiệm đại diện, đảm bảo thỏa mãn đầy đủ các yêu cầu chức năng, hiệu năng và an toàn bảo mật (Đúng sản phẩm / Doing the right thing).
Cách thức thực hiện: Thực hiện kiểm thử toàn bộ hệ thống (System Testing), kiểm thử hộp đen (Black-box testing), kiểm thử hiệu năng/chịu tải (Performance/Load/Stress Testing), kiểm thử khả năng phục hồi sau sự cố (Disaster Recovery), và thử nghiệm xâm nhập an ninh (Penetration Testing / DAST).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác nhận hệ thống không còn lỗi chức năng mức Tối quan trọng/Nghiêm trọng (Blocker/Critical Defect) và không còn lỗ hổng an ninh chưa khắc phục. - Nếu phát hiện lỗi hệ thống nghiêm trọng: Phát hành Báo cáo Sự cố (PR/NCR), Quay lại Giai đoạn 3 (Sửa code & Re-test). - Nếu phát hiện lỗ hổng an ninh mức High/Critical: Dừng luồng nghiệm thu, Quay lại Giai đoạn 2 & 3 để vá lỗ hổng kiến trúc/mã nguồn.
|
[Chủ trì (A)] Software Quality Assurance (SQA)[Thực hiện (R)] Quality Control / Tester (QC), Automation Test Engineer (Auto Test)[Tham vấn (C)] Product Owner (PO), UI/UX Designer (UI/UX), Technical Lead (Tech Lead), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev)
|
| 19 |
Bước 19: THỬ NGHIỆM NGHIỆM THU NGƯỜI DÙNG (USER ACCEPTANCE TESTING - UAT)Mục tiêu: Cho phép Khách hàng và Người dùng cuối trực tiếp đánh giá, thử nghiệm phần mềm trên môi trường UAT dựa trên các kịch bản sử dụng thực tế (Mission/Business Scenarios) để làm cơ sở chấp nhận sản phẩm.
Cách thức thực hiện: Thiết lập môi trường UAT độc lập với dữ liệu mẫu nghiệp vụ. Tổ chức cho đại diện Khách hàng và Người dùng cuối thực thi kịch bản nghiệm thu UAT, ghi nhận ý kiến phản hồi, đánh giá tính dễ sử dụng (Usability) và xác nhận sự phù hợp với quy trình nghiệp vụ.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Khách hàng ra quyết định chấp nhận nghiệm thu UAT (Đồng ý / Đồng ý có điều kiện / Từ chối Nghiệm thu). - Nếu thất bại UAT do lỗi chức năng sai so với SRS: Quay lại Giai đoạn 3 để sửa lỗi khẩn cấp. - Nếu thất bại UAT do phát sinh nhu cầu nghiệp vụ mới ngoài SRS: Khởi tạo Yêu cầu Thay đổi (Change Request - CR) thông qua CCB.
|
[Chủ trì (A)] Software Architect (SA)[Thực hiện (R)] Security & Performance Tester (Sec/Perf Tester)[Tham vấn (C)] Database Administrator (DBA), Technical Lead (Tech Lead), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev), Software Quality Assurance (SQA), Quality Control / Tester (QC), Automation Test Engineer (Auto Test), DevOps Engineer (DevOps), Site Reliability Engineer (SRE), System Administrator (SysAdmin)
|
| 20 |
Bước 20: ĐÁNH GIÁ NHẬN DẠNG CHẤT LƯỢNG VÀ CHỐT CƠ SỞ V&V (QUALIFICATION REVIEW & V&V BASELINING - QR)Mục tiêu: Tổng hợp toàn bộ hồ sơ V&V, kiểm tra việc đóng các báo cáo sự cố (PRs/NCRs), tổ chức đợt Đánh giá Nhận dạng Chất lượng (Qualification Review - QR) và chốt Tập cơ sở V&V làm căn cứ nghiệm thu bàn giao.
Cách thức thực hiện: Rà soát tổng thể báo cáo xác minh, báo cáo xác nhận, báo cáo an ninh và biên bản UAT. Tổ chức đợt đánh giá chính thức QR với sự tham gia của Khách hàng, Đội ngũ SQA, và các bên liên quan để phê duyệt trạng thái Qualified Software Product.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Phê duyệt phần mềm đạt trạng thái Qualified Software (Sẵn sàng chuyển sang Giai đoạn 5: Bàn giao & Vận hành). - Nếu còn các lỗi mở (Open Defects) chưa được giải quyết hoặc chưa được Khách hàng miễn trừ (Waiver): Bác bỏ việc cấp chứng nhận Qualification; Quay lại Giai đoạn 3 & 4 để giải quyết triệt để lỗi tồn đọng trước khi tổ chức QR lại.
|
[Chủ trì (A)] Security Lead (Sec Lead)[Thực hiện (R)] Security & Performance Tester (Sec/Perf Tester)[Tham vấn (C)] Project Manager (PM), Software Architect (SA), Database Administrator (DBA), Technical Lead (Tech Lead), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev), Software Quality Assurance (SQA), DevOps Engineer (DevOps), Site Reliability Engineer (SRE), System Administrator (SysAdmin)
|
Sơ đồ luồng kỹ thuật Giai đoạn 4
Giai đoạn 5
Chuyển giao và Triển khai Phần mềm
Bảng phân nhiệm & các bước quy chuẩn Giai đoạn 5
Bước 21 – Bước 25
| Bước | Diễn giải, mục tiêu, kết quả đầu ra & rẽ nhánh | Phân cấp trách nhiệm (RACI) |
|---|---|---|
| 21 |
Bước 21: LẬP KẾ HOẠCH CHUYỂN GIAO VÀ ĐÓNG GÓI BẢN PHÁT HÀNH (TRANSITION & RELEASE PLANNING)Mục tiêu: Xây dựng chiến lược và kế hoạch chi tiết để đưa phần mềm từ môi trường phát triển/thử nghiệm lên môi trường vận hành thực tế (Production), đảm bảo quá trình chuyển giao diễn ra an toàn, không làm gián đoạn các hoạt động vận hành hiện tại.
Cách thức thực hiện: Lập Kế hoạch Chuyển giao (Transition Plan), xác định điều kiện tiên quyết (Prerequisites), xây dựng phương án chuyển đổi dữ liệu (Data Migration Plan), kịch bản triển khai (Deployment Script/Playbook), kế hoạch đào tạo người dùng và phương án phục hồi về trạng thái cũ nếu gặp sự cố (Rollback Plan).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá sự sẵn sàng của hạ tầng sản xuất, tính khả thi của kịch bản Rollback và sự phê duyệt của Ban Quản lý Chuyển giao (Go/No-Go Decision). Nếu phương án Rollback chưa khả thi hoặc hạ tầng sản xuất chưa sẵn sàng: Hoãn thời điểm triển khai, yêu cầu bổ sung kịch bản thử nghiệm Rollback trên môi trường Staging trước khi cấp phép lại.
|
[Chủ trì (A)] Product Owner (PO)[Thực hiện (R)] Business Analyst (BA)[Tham vấn (C)] Project Manager (PM), UI/UX Designer (UI/UX), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev), Software Quality Assurance (SQA), Quality Control / Tester (QC)
|
| 22 |
Bước 22: CHUYỂN ĐỔI DỮ LIỆU VÀ TRIỂN KHAI SẢN XUẤT (DATA MIGRATION & PRODUCTION DEPLOYMENT)Mục tiêu: Thực hiện chuyển đổi dữ liệu từ hệ thống cũ (nếu có) và cài đặt bản phát hành phần mềm chính thức lên hạ tầng vận hành thực tế.
Cách thức thực hiện: Thực hiện trích xuất, chuyển đổi và tải dữ liệu (ETL/Data Migration) từ hệ thống cũ sang CSDL mới, kiểm tra tính toàn vẹn dữ liệu. Tiến hành triển khai bản đóng gói phần mềm (Release Package / Docker Images / Binaries) lên các máy chủ sản xuất, cấu hình biến môi trường, phân quyền truy cập và thực thi kiểm thử nhanh sau triển khai (Smoke Test / Sanity Test).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác nhận kết quả Smoke Test và tính toàn vẹn của dữ liệu sau chuyển đổi (Triển khai Thành công hay Thất bại). Nếu quá trình chuyển đổi dữ liệu bị sai lệch hoặc Smoke Test thất bại nghiêm trọng: Kích hoạt ngay kịch bản Rollback khôi phục hệ thống về trạng thái ban đầu, Quay lại Bước 1 để phân tích nguyên nhân và lập lại kịch bản triển khai.
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] Software Quality Assurance (SQA)[Tham vấn (C)] Product Owner (PO), Software Architect (SA), Technical Lead (Tech Lead), Quality Control / Tester (QC), Security & Performance Tester (Sec/Perf Tester), Software Configuration Manager (SCM), Security Lead (Sec Lead)
|
| 23 |
Bước 23: GIÁM SÁT VẬN HÀNH VÀ CẤU HÌNH HẠ TẦNG (OPERATIONS MONITORING & INFRASTRUCTURE MANAGEMENT)Mục tiêu: Duy trì sự ổn định, tính sẵn sàng cao (High Availability), an toàn thông tin và theo dõi hiệu năng của phần mềm trong quá trình khai thác thực tế.
Cách thức thực hiện: Thiết lập hệ thống giám sát tự động (Monitoring & Alerting tools - Prometheus/Grafana, APM), theo dõi các chỉ số vận hành (CPU, RAM, Disk, Latency, Error Rate, SLO/SLA), thực hiện sao lưu dữ liệu định kỳ (Data Backup) và áp dụng các chính sách vá lỗi an ninh hạ tầng (Infrastructure Patching).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác nhận các chỉ số hiệu năng và độ ổn định hệ thống đạt cam kết SLA/SLO. Nếu hệ thống vượt ngưỡng tài nguyên hoặc vi phạm SLA hiệu năng: Kích hoạt cơ chế tự động mở rộng (Auto-scaling) hoặc điều chỉnh cấu hình hạ tầng; nếu lỗi do rò rỉ tài nguyên từ phần mềm: Khởi tạo sự cố mức High chuyển sang Giai đoạn 6 (Bảo trì khẩn cấp).
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] DevOps Engineer (DevOps)[Tham vấn (C)] Product Owner (PO), Software Architect (SA), Database Administrator (DBA), Technical Lead (Tech Lead), Software Quality Assurance (SQA), Site Reliability Engineer (SRE), System Administrator (SysAdmin), IT Technical Support (IT Support), Software Configuration Manager (SCM), Security Lead (Sec Lead)
|
| 24 |
Bước 24: HỖ TRỢ NGƯỜI DÙNG VÀ QUẢN LÝ SỰ CỐ (USER SUPPORT & INCIDENT MANAGEMENT)Mục tiêu: Tiếp nhận, phân loại, hỗ trợ và giải quyết các yêu cầu, thắc mắc cũng như sự cố phát sinh từ người dùng trong quá trình vận hành sản phẩm.
Cách thức thực hiện: Vận hành Trung tâm hỗ trợ (Helpdesk / Service Desk), phân loại sự cố theo các mức độ ưu tiên (Severity 1 to 4). Đưa ra các giải pháp khắc phục tạm thời (Workarounds) để khôi phục dịch vụ nhanh nhất, đồng thời theo dõi và ghi nhận các Báo cáo Sự cố (Incident Reports / SPRs).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Phân loại sự cố là do lỗi phần mềm (Defect), lỗi vận hành (Ops Issue), hay Yêu cầu Thay đổi mới (Change Request). - Nếu sự cố là lỗi phần mềm chưa khắc phục được bằng workaround: Chuyển hồ sơ sự cố (SPR/NCR) sang Giai đoạn 6 (Bảo trì Phần mềm) để phân tích nguyên nhân gốc (Root Cause Analysis - RCA) và sửa mã nguồn. - Nếu sự cố là do người dùng chưa nắm quy trình: Bổ sung tài liệu FAQ và tổ chức đào tạo lại.
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] DevOps Engineer (DevOps), Software Configuration Manager (SCM)[Tham vấn (C)] Technical Lead (Tech Lead), Software Quality Assurance (SQA), Quality Control / Tester (QC), Security Lead (Sec Lead)
|
| 25 |
Bước 25: ĐÁNH GIÁ NGHIỆM THU VÀ CHỐT CƠ SỞ VẬN HÀNH (ACCEPTANCE REVIEW & OPERATIONS BASELINING - AR)Mục tiêu: Đánh giá chính thức kết quả vận hành thử nghiệm, xác nhận sự hoàn thành của quá trình bàn giao và chốt Tập cơ sở Vận hành (Operations Baseline) chính thức nghiệm thu hợp đồng/dự án.
Cách thức thực hiện: Rà soát tổng thể kết quả triển khai, báo cáo vận hành, nhật ký xử lý sự cố còn tồn đọng và biên bản nghiệm thu kỹ thuật. Tổ chức đợt Đánh giá Nghiệm thu chính thức (Acceptance Review - AR) với sự tham gia của Khách hàng, Nhà cung cấp và các đại diện vận hành.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Khách hàng ký Biên bản Nghiệm thu chính thức (AR Approved / Approved with Reservations / Rejected). - Nếu còn các sự cố mức Critical/High chưa đóng: Tạm hoãn nghiệm thu chính thức; yêu cầu nhà cung cấp khắc phục trong thời gian bảo hành/cam kết trước khi tổ chức AR lại. - Nếu đạt có điều kiện (Approved with Reservations): Lập danh mục công việc tồn đọng (Punch List) để đội Bảo trì theo dõi giải quyết trong Giai đoạn 6.
|
[Chủ trì (A)] Software Architect (SA)[Thực hiện (R)] Database Administrator (DBA)[Tham vấn (C)] Project Manager (PM), Product Owner (PO), Technical Lead (Tech Lead), Back-End Developer (BE Dev), Software Quality Assurance (SQA), Quality Control / Tester (QC), DevOps Engineer (DevOps), Site Reliability Engineer (SRE), System Administrator (SysAdmin), Security Lead (Sec Lead)
|
Sơ đồ luồng kỹ thuật Giai đoạn 5
Giai đoạn 6
Vận hành và khai thác
Bảng phân nhiệm & các bước quy chuẩn Giai đoạn 6
Bước 26 – Bước 30
| Bước | Diễn giải, mục tiêu, kết quả đầu ra & rẽ nhánh | Phân cấp trách nhiệm (RACI) |
|---|---|---|
| 26 |
Bước 26: LẬP KẾ HOẠCH VẬN HÀNH VÀ QUẢN LÝ DUNG LƯỢNG HẠ TẦNG (OPERATIONS PLANNING & CAPACITY MANAGEMENT)Mục tiêu: Lập kế hoạch vận hành chi tiết, thiết lập các mục tiêu cam kết chất lượng dịch vụ (SLA/SLO/SLI) và lập kế hoạch quản lý dung lượng/tài nguyên hạ tầng nhằm đảm bảo hệ thống phần mềm hoạt động liên tục, sẵn sàng cao và tối ưu chi phí.
Cách thức thực hiện: Xây dựng Kế hoạch Vận hành (Operations Plan), định nghĩa các ngưỡng cảnh báo (Alert Thresholds), thiết lập bộ chỉ số SLA/SLO/SLI (Availability, Latency, Throughput, Error Rate), và tính toán dự báo nhu cầu tăng trưởng tài nguyên hạ tầng (Capacity Planning & FinOps).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá phê duyệt bộ chỉ số SLA/SLO và tính khả thi của kế hoạch phân bổ tài nguyên. Nếu dự báo tài nguyên hạ tầng không đủ đáp ứng tăng trưởng hoặc nguy cơ vi phạm SLA: Đề xuất điều chỉnh ngân sách tài nguyên hạ tầng hoặc tái tối ưu hóa cấu hình hệ thống trước khi vận hành chính thức.
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] DevOps Engineer (DevOps), Site Reliability Engineer (SRE)[Tham vấn (C)] Product Owner (PO), Software Architect (SA), Database Administrator (DBA), Technical Lead (Tech Lead), Software Quality Assurance (SQA), Quality Control / Tester (QC), System Administrator (SysAdmin), Software Configuration Manager (SCM), Security Lead (Sec Lead)
|
| 27 |
Bước 27: GIÁM SÁT VẬN HÀNH LIÊN TỤC VÀ ĐO LƯỜNG CHỈ SỐ (CONTINUOUS OPERATIONS MONITORING & TELEMETRY)Mục tiêu: Theo dõi liên tục 24/7 tình trạng sức khỏe hệ thống, hiệu năng, an toàn thông tin và tính sẵn sàng của phần mềm trên môi trường sản xuất để chủ động phát hiện sớm bất thường.
Cách thức thực hiện: Triển khai các công cụ giám sát tập trung (Prometheus, Grafana, APM, ELK Stack), thực hiện tập hợp nhật ký (Log Aggregation), đo lường các chỉ số Golden Signals (Latency, Traffic, Errors, Saturation) và thiết lập cơ chế tự động gửi cảnh báo (Alerting Rules).
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá các chỉ số vận hành thực tế có nằm trong ngưỡng an toàn SLO/SLA đã cam kết hay không. Nếu phát sinh chỉ số vượt ngưỡng cảnh báo (Alert threshold breached) hoặc vi phạm SLA: Kích hoạt ngay quy trình Xử lý Sự cố (Bước 3) hoặc kích hoạt cơ chế tự động mở rộng hạ tầng (Auto-scaling).
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] Business Analyst (BA), IT Technical Support (IT Support)[Tham vấn (C)] Product Owner (PO), UI/UX Designer (UI/UX), Software Quality Assurance (SQA), Software Configuration Manager (SCM)
|
| 28 |
Bước 28: HỖ TRỢ KỸ THUẬT NGƯỜI DÙNG VÀ QUẢN LÝ SỰ CỐ VẬN HÀNH (HELPDESK SUPPORT & INCIDENT MANAGEMENT)Mục tiêu: Tiếp nhận, phân loại, phản hồi và giải quyết các sự cố gián đoạn dịch vụ từ phía người dùng hoặc từ hệ thống giám sát tự động nhằm nhanh chóng khôi phục dịch vụ về trạng thái bình thường.
Cách thức thực hiện: Vận hành kênh tiếp nhận sự cố (Helpdesk / Service Desk L1/L2/L3), phân loại mức độ nghiêm trọng (P1/Severity 1 đến P4), áp dụng các giải pháp khắc phục tạm thời (Workarounds) để giảm thời gian ngừng hoạt động (Downtime), và ghi nhận nhật ký xử lý ticket.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Phân loại nguyên nhân sự cố thuộc về lỗi vận hành hạ tầng (xử lý tại chỗ) hay do lỗi mã nguồn phần mềm / kiến trúc (cần sửa code). Nếu sự cố do lỗi phần mềm nghiêm trọng chưa thể khắc phục bằng workaround: Chuyển ngay Báo cáo Sự cố (SPR/NCR) sang Giai đoạn 7: Bảo trì, nâng cấp hoặc chấm dứt hoạt động để phát hành bản sửa lỗi khẩn cấp (Hotfix).
|
[Chủ trì (A)] Software Architect (SA)[Thực hiện (R)] DevOps Engineer (DevOps), Site Reliability Engineer (SRE)[Tham vấn (C)] Database Administrator (DBA), Technical Lead (Tech Lead), System Administrator (SysAdmin), Security Lead (Sec Lead)
|
| 29 |
Bước 29: SAO LƯU DỮ LIỆU VÀ BẢO MẬT HẠ TẦNG VẬN HÀNH (DATA BACKUP & OPERATIONAL SECURITY MANAGEMENT)Mục tiêu: Đảm bảo tính toàn vẹn, khả năng khôi phục dữ liệu an toàn và bảo mật hạ tầng phần mềm xuyên suốt quá trình khai thác vận hành thực tế.
Cách thức thực hiện: Thực hiện sao lưu CSDL và dữ liệu ứng dụng định kỳ (Full/Incremental Backups), diễn tập thử nghiệm khôi phục dữ liệu sau sự cố (Disaster Recovery Testing), áp dụng các bản vá an ninh hệ điều hành/hạ tầng (Infrastructure Security Patching) và rà soát quyền truy cập hệ thống.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá tính sẵn sàng của các bản sao lưu và mức độ đáp ứng chỉ số RPO/RTO (Recovery Point/Time Objective). Nếu đợt diễn tập khôi phục dữ liệu thất bại hoặc bản sao lưu bị hỏng: Yêu cầu hiệu chỉnh quy trình backup, tiến hành thử nghiệm khôi phục lại cho đến khi đáp ứng đúng tiêu chí RPO/RTO quy định.
|
[Chủ trì (A)] Site Reliability Engineer (SRE)[Thực hiện (R)] IT Technical Support (IT Support)[Tham vấn (C)] Project Manager (PM), Database Administrator (DBA), Technical Lead (Tech Lead), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev), DevOps Engineer (DevOps), System Administrator (SysAdmin), Security Lead (Sec Lead)
|
| 30 |
Bước 30: ĐÁNH GIÁ HIỆU QUẢ VẬN HÀNH ĐỊNH KỲ VÀ BÀN GIAO SANG BẢO TRÌ/HỦY BỎ (PERIODIC OPERATIONAL REVIEW & TRANSITION)Mục tiêu: Đánh giá định kỳ hiệu quả khai thác phần mềm, chi phí vận hành, mức độ hài lòng của người dùng và xác định thời điểm chuyển giao sang giai đoạn bảo trì lớn hoặc ngừng vận hành hệ thống.
Cách thức thực hiện: Tổ chức các đợt rà soát vận hành định kỳ (Periodic Operational Review), tổng hợp báo cáo SLA, chi phí hạ tầng (FinOps), đánh giá mức độ lạc hậu công nghệ và đề xuất kế hoạch nâng cấp hoặc ngừng vận hành.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác định quyết định chiến lược cho bước tiếp theo của phần mềm (Tiếp tục Vận hành bình thường / Chuyển sang Bảo trì lớn & Nâng cấp / Kích hoạt Quy trình Hủy bỏ & ngừng vận hành). Nếu phần mềm phát sinh quá nhiều lỗi hoặc công nghệ quá cũ gây tốn chi phí vận hành vượt ngưỡng: Kích hoạt Giai đoạn 7: Bảo trì, nâng cấp hoặc chấm dứt hoạt động.
|
[Chủ trì (A)] Site Reliability Engineer (SRE)[Thực hiện (R)] DevOps Engineer (DevOps), System Administrator (SysAdmin)[Tham vấn (C)] Project Manager (PM), Software Architect (SA), Database Administrator (DBA), Technical Lead (Tech Lead), Quality Control / Tester (QC), Software Configuration Manager (SCM), Security Lead (Sec Lead)
|
Sơ đồ luồng kỹ thuật Giai đoạn 6
Giai đoạn 7
Bảo trì, nâng cấp hoặc chấm dứt hoạt động
Bảng phân nhiệm & các bước quy chuẩn Giai đoạn 7
Bước 31 – Bước 35
| Bước | Diễn giải, mục tiêu, kết quả đầu ra & rẽ nhánh | Phân cấp trách nhiệm (RACI) |
|---|---|---|
| 31 |
Bước 31: TIẾP NHẬN, PHÂN LOẠI VÀ PHÂN TÍCH TÁC ĐỘNG YÊU CẦU THAY ĐỔI / LỖI (MODIFICATION REQUEST & IMPACT ANALYSIS)Mục tiêu: Ghi nhận toàn bộ Yêu cầu Thay đổi (Modification Requests - MRs) hoặc Báo cáo Sự cố (Problem Reports - PRs), phân loại bản chất bảo trì (Sửa lỗi, Thích ứng, Hoàn thiện, Phòng ngừa) và đánh giá chi tiết tác động về kỹ thuật, chi phí và rủi ro.
Cách thức thực hiện: Ghi nhận yêu cầu vào hệ thống quản lý (Jira/ServiceNow). Phân loại bảo trì theo 4 nhóm chuẩn ISO 14764 (Corrective, Adaptive, Perfective, Preventive). Phân tích chi tiết tác động của thay đổi đối với mã nguồn, CSDL, kiến trúc, tài liệu, chi phí và lịch trình dự án.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác định tính hợp lệ và mức độ ưu tiên của yêu cầu thay đổi. Nếu yêu cầu mơ hồ hoặc chưa đủ thông tin phân tích tác động, yêu cầu bên đề xuất bổ sung tài liệu. Nếu yêu cầu bất khả thi về mặt kỹ thuật hoặc chi phí quá lớn, trình Hội đồng Kiểm soát Cấu hình (CCB) ra quyết định bác bỏ (Reject).
|
[Chủ trì (A)] Site Reliability Engineer (SRE)[Thực hiện (R)] Database Administrator (DBA), System Administrator (SysAdmin)[Tham vấn (C)] Project Manager (PM), Software Architect (SA), Software Quality Assurance (SQA), DevOps Engineer (DevOps), Security Lead (Sec Lead)
|
| 32 |
Bước 32: THỰC THI SỬA ĐỔI MÃ NGUỒN, CẬP NHẬT THIẾT KẾ VÀ KIỂM THỬ HỒI QUY (MODIFICATION EXECUTION & REGRESSION TESTING)Mục tiêu: Tái áp dụng các hoạt động kỹ thuật (SRS, SDD, Coding) để sửa đổi phần mềm theo yêu cầu đã duyệt, đồng thời thực hiện kiểm thử hồi quy nhằm đảm bảo tính toàn vẹn và không làm phát sinh lỗi mới.
Cách thức thực hiện: Thực hiện cập nhật thiết kế chi tiết và mã nguồn theo quy chuẩn mã hóa an toàn. Viết bổ sung các kịch bản kiểm thử đơn vị/tích hợp mới. Thực hiện kiểm thử hồi quy tự động (Automated Regression Testing) trên toàn bộ hệ thống để xác minh các chức năng cũ không bị ảnh hưởng.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác nhận lỗi đã được khắc phục hoàn toàn và không gây lỗi hồi quy trên các phân hệ khác. Nếu kiểm thử hồi quy phát hiện lỗi mới (Regression Defect), bắt buộc trả mã nguồn lại cho nhóm lập trình viên sửa đổi và thực thi lại bộ kiểm thử hồi quy từ đầu.
|
[Chủ trì (A)] Product Owner (PO)[Thực hiện (R)] Business Analyst (BA)[Tham vấn (C)] Project Manager (PM), Software Architect (SA), Technical Lead (Tech Lead), Site Reliability Engineer (SRE), IT Technical Support (IT Support), Software Configuration Manager (SCM)
|
| 33 |
Bước 33: ĐÓNG GÓI BẢN CẬP NHẬT, KIỂM SOÁT CẤU HÌNH VÀ PHÁT HÀNH BẢN SỬA LỖI (PATCHING, RELEASE & MIGRATION MANAGEMENT)Mục tiêu: Đóng gói bản nâng cấp/bản vá lỗi (Patches / Upgraded Releases), cập nhật tài liệu hướng dẫn và thực hiện phát hành chuyển giao cho bộ phận vận hành theo quy trình kiểm soát cấu hình nghiêm ngặt.
Cách thức thực hiện: Đóng gói bản sửa lỗi/nâng cấp (Patch Packages / Hotfix Releases), cập nhật phiên bản ma trận truy xuất và tài liệu người dùng (SUM). Trình Hội đồng CCB phê duyệt phát hành và phối hợp với đội ngũ DevOps/Ops thực hiện cập nhật lên môi trường sản xuất theo kịch bản chuyển giao.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: CCB quyết định phê duyệt cấp phép phát hành bản nâng cấp/vá lỗi. Nếu bản vá không vượt qua đợt đánh giá cấu hình hoặc kịch bản triển khai lỗi, CCB từ chối phát hành; yêu cầu đóng gói và kiểm thử lại trước khi xin phê duyệt lại.
|
[Chủ trì (A)] Software Architect (SA)[Thực hiện (R)] Technical Lead (Tech Lead), Front-End Developer (FE Dev), Back-End Developer (BE Dev), Full-Stack Developer (FS Dev), Mobile Developer (Mobile Dev)[Tham vấn (C)] Project Manager (PM), Product Owner (PO), UI/UX Designer (UI/UX), Database Administrator (DBA), Software Quality Assurance (SQA), Quality Control / Tester (QC), Automation Test Engineer (Auto Test), DevOps Engineer (DevOps), Software Configuration Manager (SCM), Security Lead (Sec Lead)
|
| 34 |
Bước 34: LẬP KẾ HOẠCH NGỪNG VẬN HÀNH VÀ LƯU TRỮ DỮ LIỆU LỊCH SỬ (DISPOSAL PLANNING & DATA ARCHIVAL)Mục tiêu: Xây dựng chiến lộ trình ngừng vận hành hệ thống (Disposal Plan) khi phần mềm hết giá trị sử dụng hoặc được thay thế, đảm bảo an toàn dữ liệu lịch sử và tuân thủ các quy định pháp lý.
Cách thức thực hiện: Lập Kế hoạch Ngừng vận hành & Hủy bỏ (Disposal / Retirement Plan), xác định các tập dữ liệu cần lưu trữ dài hạn (Archival Data), lập kịch bản chuyển đổi người dùng sang hệ thống mới (nếu có), thông báo lộ trình ngừng phục vụ cho các bên liên quan và chuẩn bị hạ tầng lưu trữ bảo mật.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Đánh giá phê duyệt Kế hoạch Hủy bỏ và phương án lưu trữ dữ liệu đáp ứng luật định. Nếu phương án lưu trữ dữ liệu chưa đảm bảo tính bảo mật hoặc vi phạm quy định lưu trữ dữ liệu ngành, yêu cầu chỉnh sửa kế hoạch và bổ sung giải pháp mã hóa/lưu trữ an toàn.
|
[Chủ trì (A)] Project Manager (PM)[Thực hiện (R)] Database Administrator (DBA), Software Configuration Manager (SCM)[Tham vấn (C)] Product Owner (PO), Business Analyst (BA), Software Architect (SA), Technical Lead (Tech Lead), Software Quality Assurance (SQA), DevOps Engineer (DevOps), Site Reliability Engineer (SRE), System Administrator (SysAdmin), IT Technical Support (IT Support), Security Lead (Sec Lead)
|
| 35 |
Bước 35: THỰC THI NGỪNG VẬN HÀNH, THU HỒI TÀI NGUYÊN VÀ ĐÓNG VÒNG ĐỜI (SYSTEM RETIREMENT & LIFECYCLE CLOSEOUT)Mục tiêu: Thực hiện ngừng cung cấp dịch vụ, lưu trữ dữ liệu lịch sử, thu hồi tài nguyên hạ tầng, tiêu hủy các bản sao không cần thiết và chính thức đóng vòng đời phần mềm.
Cách thức thực hiện: Ngừng kết nối dịch vụ phần mềm, thực hiện trích xuất và đóng gói lưu trữ CSDL lịch sử vào hạ tầng an toàn. Thu hồi tài nguyên máy chủ/hạ tầng mạng (Decommissioning), hủy bỏ các quyền truy cập, thực hiện tiêu hủy an toàn dữ liệu nhạy cảm theo chuẩn (NIST 800-88) và lập biên bản đóng vòng đời sản phẩm.
Sản phẩm bàn giao quy chuẩn:
Đánh giá và xử lý: Xác nhận hoàn thành toàn bộ công tác thu hồi tài nguyên và đóng vòng đời hệ thống. Nếu phát hiện dữ liệu nhạy cảm chưa được lưu trữ đầy đủ hoặc chưa được hủy an toàn, dừng quy trình thu hồi cho đến khi công tác bảo mật và lưu trữ được hoàn tất 100%.
|
[Chủ trì (A)] Product Owner (PO)[Thực hiện (R)] Database Administrator (DBA), Site Reliability Engineer (SRE), System Administrator (SysAdmin), Software Configuration Manager (SCM), Security Lead (Sec Lead)[Tham vấn (C)] Project Manager (PM), Software Quality Assurance (SQA), DevOps Engineer (DevOps)
|
Sơ đồ luồng kỹ thuật Giai đoạn 7