Phân tích hệ thống trong CNTT

From Systems analysis wiki
Jump to navigation Jump to search

Phân tích hệ thống trong IT (Systems Analysis and Design) — phương pháp tiếp cận để thiết kế và phát triển hệ thống thông tin từ ý tưởng đến vận hành, bao gồm xác định nhu cầu, hình thức hóa yêu cầu, mô hình hóa lĩnh vực nghiệp vụ và các quy trình, cũng như đánh giá các phương án và rủi ro. Nói cách khác, phân tích hệ thống trong IT là giai đoạn phát triển mà các chuyên gia nghiên cứu bài toán, xác định hệ thống phải làm gì và xây dựng các giải pháp để tạo ra nó.

Phân tích hệ thống cổ điển bao quát phạm vi ứng dụng rộng, không chỉ phát triển phần mềm mà còn các thay đổi tổ chức, chiến lược và các khía cạnh khác.[1] [2]

Đối tượng và nhiệm vụ của phân tích hệ thống trong IT

Đối tượng của phân tích hệ thống trong IT là hệ thống thông tin (sản phẩm và/hoặc dịch vụ phần mềm) trong toàn bộ vòng đời — từ ý tưởng và luận chứng đến triển khai và vận hành.

Nhiệm vụ của phân tích hệ thống — chuyển đổi nhu cầu kinh doanh thành tập hợp yêu cầu và quyết định kiến trúc được thống nhất và có thể kiểm chứng: xác định và ghi lại mục tiêu và ràng buộc của các bên liên quan, hình thức hóa yêu cầu, mô hình hóa lĩnh vực nghiệp vụ và quy trình, đánh giá tính khả thi và rủi ro của các phương án, và luận chứng kiến trúc đã chọn. Kết quả là tạo ra các tài liệu được thống nhất và thiết lập các liên kết có thể theo dõi giữa yêu cầu, quyết định thiết kế và kiểm thử. Điều này đảm bảo tính quản lý và kiểm soát quá trình phát triển.

Các nhiệm vụ của phân tích hệ thống bao gồm:

  • Xác định nhu cầu và mục tiêu của các bên liên quan. Nhà phân tích thu thập và làm rõ kỳ vọng của khách hàng, người dùng và các bên có liên quan khác; sử dụng phỏng vấn, khảo sát, quan sát và phân tích các quy trình hiện tại. Kết quả là hình thành đặc tả yêu cầu ban đầu với sự phân chia thành yêu cầu chức năng («hệ thống phải làm gì») và phi chức năng (độ tin cậy, hiệu năng, bảo mật, v.v.).[1][2]
  • Hình thức hóa và ghi lại yêu cầu. Các yêu cầu được chuyển đổi thành yêu cầu có thể kiểm chứng. Một yêu cầu được trình bày tốt phải rõ ràng và không mơ hồ, đầy đủ, nhất quán, có thể kiểm chứng và có thể truy vết đến các mục tiêu cấp cao hơn; tập hợp yêu cầu phải được thống nhất và toàn vẹn.[3][4] Trong thực tế, các tài liệu được chuẩn hóa được sử dụng: SRS (Software Requirements Specification) theo ISO/IEC/IEEE 29148, cũng như trong một số ngành, URS (User Requirements Specification) và các đặc tả chức năng.[5][6][7]
  • Phân tích và mô hình hóa hệ thống. Để hiểu cách hệ thống sẽ hoạt động và tương tác với thế giới bên ngoài, các mô hình được xây dựng: biểu đồ Use Case cho các kịch bản sử dụng, DFD cho luồng dữ liệu và quy trình nghiệp vụ, biểu đồ lớp/thành phần, v.v. Các mô hình là cơ sở để so sánh các giải pháp và kiến trúc thay thế.[8][9][10]
  • Đánh giá tính khả thi và lựa chọn giải pháp. Thực hiện feasibility study (tính khả thi kỹ thuật, tổ chức, kinh tế, lịch trình) và so sánh các phương án kiến trúc (trade-off). Để đánh giá chất lượng kiến trúc theo các thuộc tính (ví dụ: hiệu năng, khả năng mở rộng, khả năng sửa đổi), các phương pháp như ATAM (Architecture Tradeoff Analysis Method) được áp dụng.[11][12] Việc lựa chọn giữa, ví dụ, kiến trúc nguyên khối và kiến trúc vi dịch vụ [3] dựa trên các đánh đổi rõ ràng (độ phức tạp vận hành so với khả năng mở rộng độc lập và tốc độ cung cấp) theo các hướng dẫn của ngành.[13][14]
  • Chuẩn bị các tài liệu dự án. Sau khi phân tích, các tài liệu sau được hình thành:
    • đặc tả yêu cầu đã được phê duyệt (với chỉ định mức độ quan trọng của chúng),
    • mô hình khái niệm của hệ thống (biểu đồ/mô tả),
    • các quyết định kiến trúc và thiết kế (sơ đồ dữ liệu, giao diện của các hệ thống bên ngoài),
    • kế hoạch triển khai (các giai đoạn/mô-đun).
    • Việc đảm bảo khả năng truy vết (bidirectional traceability) của các yêu cầu đến các yếu tố thiết kế và kiểm thử là điều cốt lõi.[15][4]

Sự thành công của một dự án IT phụ thuộc đáng kể vào mức độ trưởng thành của các thực hành làm việc với yêu cầu và kiến trúc. Nghiên cứu do McKinsey và Oxford thực hiện cho thấy các dự án IT lớn thường vượt ngân sách và tiến độ. Nghiên cứu này cũng nhấn mạnh tầm quan trọng của việc quản lý chiến lược đúng đắn, tương tác với các bên liên quan và thu thập yêu cầu một cách chuyên nghiệp. Tất cả những điều này có thể ảnh hưởng lớn đến sự thành công hay thất bại của dự án.[16]

Các phương pháp và phương pháp luận trong phân tích hệ thống IT

Phân tích hệ thống trong IT dựa trên các nguyên tắc tư duy hệ thống và các phương pháp được điều chỉnh cho phát triển phần mềm. Trong thực tế, các phương pháp tiếp cận «cứng» và «mềm», các phương pháp luận có cấu trúc, các ký hiệu hướng đối tượng, cũng như các ngôn ngữ mô hình hóa quy trình và yêu cầu được kết hợp với nhau.

  • Phương pháp cứng và mềm. Trong các dự án IT, phương pháp tiếp cận cứng (hard systems) giả định các mục tiêu và yêu cầu có thể được hình thức hóa trước, phân rã và thiết kế «từ trên xuống». Phương pháp mềm (soft systems) được áp dụng khi mục tiêu không rõ ràng và có nhiều quan điểm khác nhau: sử dụng các yếu tố của Soft Systems Methodology (SSM) (ví dụ: rich picture, định nghĩa gốc, CATWOE) để thống nhất hiểu biết về vấn đề và các thay đổi mong muốn; sau đó kết quả được chuyển đổi thành các yêu cầu hình thức.[17][18]
  • Phương pháp luận SSM (Soft Systems Methodology). Ban đầu được phát triển bởi Peter Checkland cho các thay đổi tổ chức, SSM hữu ích ở các giai đoạn tiền dự án IT: từ nghiên cứu tình huống có vấn đề và hình thành định nghĩa gốc (bao gồm thông qua CATWOE) đến so sánh các mô hình khái niệm với thực tế và đạt được sự thỏa thuận giữa các bên liên quan.[19][20]
  • Phương pháp luận có cấu trúc: SADT/IDEF0. SADT mô hình hóa hệ thống như một hệ phân cấp các chức năng; ký hiệu chuẩn IDEF0 (IEEE 1320.1) ghi lại các chức năng và giao diện I-C-O-M của chúng (Inputs, Controls, Outputs, Mechanisms). Phương pháp này thuận tiện cho việc phân rã chức năng và thống nhất ranh giới hệ thống độc lập với các thuật toán.[21][22]
  • Phân tích hướng đối tượng: UML và SysML (MBSE). UML đã trở thành ngôn ngữ cơ bản cho yêu cầu và thiết kế (biểu đồ Use Case, lớp, trình tự, v.v.) và tạo thuận lợi cho việc xác nhận kịch bản với người dùng; SysML mở rộng UML cho kỹ thuật hệ thống (biểu đồ yêu cầu, biểu đồ tham số) và dựa trên phương pháp MBSE, trong đó mô hình là tài liệu trung tâm xuyên suốt các giai đoạn từ yêu cầu đến kiểm thử.[23][24][25]
  • Mô hình hóa quy trình nghiệp vụ: BPMN. Tiêu chuẩn BPMN được sử dụng để mô tả đồ họa các quy trình (pool, luồng công việc, sự kiện, cổng), bao gồm so sánh as-is/to-be trong các đặc tả yêu cầu và tích hợp.[26][27]
  • Mối liên hệ với kỹ thuật yêu cầu. Quy trình bao gồm các bước elicitation–analysis–specification–validation–change management; các tiêu chí «yêu cầu tốt» và cấu trúc SRS được quy định bởi ISO/IEC/IEEE 29148. Để ưu tiên hóa, các kỹ thuật MoSCoW (Must/Should/Could/Won't) và các phương pháp lựa chọn đa tiêu chí, ví dụ AHP được áp dụng. Trong các quy trình linh hoạt, hoạt động phân tích hệ thống được phản ánh trong backlog refinement và khả năng truy vết yêu cầu.[28][29][30][31]
  • Mối liên hệ với kỹ thuật hệ thống. Đối với các hệ thống phức tạp (không gian mạng-vật lý), mô hình V được áp dụng: ở nhánh «trái» — phân tích hệ thống và kiến trúc, ở nhánh «phải» — tích hợp, xác minh và xác nhận với liên kết đến các tài liệu của nhánh trái. Các phương pháp đánh giá kiến trúc theo các thuộc tính chất lượng bao gồm ATAM (phân tích trade-off).[32][33]

Phân tích hệ thống trong IT kết hợp các phương pháp đã được kiểm chứng — từ các kỹ thuật mềm để thống nhất tầm nhìn đến các ký hiệu hình thức và tiêu chuẩn. Việc lựa chọn công cụ được xác định bởi mức độ rõ ràng của nhiệm vụ: khi có nhiều sự không chắc chắn — vai trò của SSM và hỗ trợ nhóm được tăng cường, khi ranh giới rõ ràng — các mô hình hình thức (UML/SysML, IDEF0, BPMN) và các quy định được áp dụng.

Mối liên hệ với kiến trúc IT và kiến trúc doanh nghiệp

Phân tích hệ thống trong các dự án IT gắn bó chặt chẽ với thiết kế kiến trúc. Vai trò của nhà phân tích và kiến trúc sư giao nhau: nhà phân tích hình thành yêu cầu và mô hình logic, kiến trúc sư xác định cấu trúc mục tiêu của giải pháp và các đánh đổi kỹ thuật; công việc được thực hiện cùng nhau.

  • Kiến trúc hệ thống IT. Theo nghĩa hẹp, kiến trúc phần mềm là tổ chức các thành phần, mối quan hệ của chúng và các nguyên tắc hướng dẫn thiết kế giải pháp. Nhà phân tích cần tính đến các phong cách kiến trúc (phân lớp, client–server, vi dịch vụ, hướng sự kiện, v.v.), vì các yêu cầu phi chức năng (độ tin cậy, khả năng mở rộng, khả năng sửa đổi) thường xác định các quyết định kiến trúc và các đánh đổi của chúng.[34][35] Ở giai đoạn phân tích đầu, tầm nhìn kiến trúc (high-level vision) được hình thành và phác thảo giải pháp được xây dựng để kiểm tra tính khả thi của các yêu cầu (độ dài của các vòng lặp và mức độ chi tiết phụ thuộc vào phương pháp luận).[36]
  • Các mẫu và giải pháp sơ bộ. Để đáp ứng các yêu cầu phi chức năng, các mẫu kiến trúc (architectural patterns) được áp dụng. Ví dụ, để tương tác không đồng bộ và kết nối lỏng — publish–subscribe qua message broker trong kiến trúc hướng sự kiện.[37]
  • TOGAF (The Open Group Architecture Framework). Một trong những framework kiến trúc doanh nghiệp phổ biến nhất; bao gồm phương pháp ADM (Architecture Development Method) và các tài liệu quản lý kiến trúc (kho lưu trữ, danh mục/ma trận, nguyên tắc). Trong TOGAF, quản lý yêu cầu là quy trình xuyên suốt, được tích hợp vào tất cả các giai đoạn ADM.[36] Để hỗ trợ yêu cầu và khả năng truy vết, các danh mục và ma trận được sử dụng (ví dụ: yêu cầu ↔ dịch vụ, chức năng ↔ thành phần), đồng thời phân biệt Architecture Building Blocks và Solution Building Blocks.[38][39] Các nguyên tắc và tiêu chuẩn doanh nghiệp được ghi lại trong các danh mục tương ứng và đóng vai trò là yêu cầu phi chức năng bên ngoài cho các nhóm dự án.[40] Sự tuân thủ của các giải pháp với kiến trúc mục tiêu được xác nhận bởi thủ tục kiểm tra tuân thủ kiến trúc (Architecture Compliance Review).[41] Phương pháp tiếp cận TOGAF giả định Architecture Vision sơ bộ và chi tiết hóa tiếp theo (dữ liệu/ứng dụng/công nghệ) với kế hoạch di chuyển và quản lý thay đổi yêu cầu.[42][43]
  • Zachman Framework. Một bản thể học về các tài liệu kiến trúc doanh nghiệp sớm và có ảnh hưởng, được trình bày dưới dạng ma trận 6×6 (góc nhìn × các khía cạnh «cái gì/như thế nào/ở đâu/ai/khi nào/tại sao»). Hàng «người thiết kế» tương ứng với phân tích hệ thống và thiết kế; các cột xác định tính đầy đủ trong việc xem xét dữ liệu, chức năng/quy trình, vai trò, vị trí và động lực. Framework này đóng vai trò phân loại (chứ không phải phương pháp luận) và giúp đảm bảo tính đầy đủ của mô tả giải pháp trong cảnh quan doanh nghiệp.[44]
  • Mối liên hệ với Kiến trúc Doanh nghiệp (Enterprise Architecture, EA). Nhà phân tích hệ thống làm việc trong bối cảnh EA: các yêu cầu mới được truy vết đến các khả năng kinh doanh và mô hình vận hành; các tiêu chuẩn và ràng buộc nguyên tắc của doanh nghiệp được áp dụng (bảo mật, tính tương thích, v.v.).[45][36] Ở giai đoạn khởi động, Architecture Vision được hình thành (mục tiêu/ràng buộc, các yêu cầu tổng quát), sau đó nhà phân tích chi tiết hóa, duy trì khả năng truy vết đến tầm nhìn và tiêu chuẩn doanh nghiệp; việc không tuân thủ tiêu chuẩn được phát hiện tại các buổi đánh giá kiến trúc và có thể dẫn đến việc chỉnh sửa giải pháp.[36][46]

Tóm lại: phân tích hệ thống và thiết kế kiến trúc tạo thành cặp «yêu cầu → quyết định kiến trúc → đánh đổi theo các thuộc tính chất lượng». Việc lựa chọn phương pháp (phong cách/mẫu, tài liệu TOGAF, phân loại Zachman) được xác định bởi tính chất của dự án và khuôn khổ kiến trúc doanh nghiệp.

Quy trình và thực hành

Phân tích hệ thống được tích hợp vào toàn bộ vòng đời phát triển và vận hành phần mềm, kết nối mục tiêu kinh doanh, kiến trúc và việc cung cấp sản phẩm. Bao gồm nghiên cứu tiền dự án, lựa chọn phương pháp tiếp cận, hình thành các tài liệu có thể kiểm chứng và các yêu cầu về độ tin cậy, hiệu năng, bảo mật và bảo trì. Trong mô hình thác nước, phân tích được thực hiện trước thiết kế và triển khai, trong các phương pháp linh hoạt — liên tục qua các vòng lặp, và trong DevOps — với trọng tâm là các mục tiêu vận hành. Bất kể phương pháp tiếp cận nào, phân tích đảm bảo khả năng truy vết, quản lý thay đổi và rủi ro, ghi lại các đánh đổi kiến trúc và tuân thủ các ràng buộc quy định, làm cho việc phát triển có thể dự đoán và quản lý được.

  • SDLC cổ điển (Waterfall). Giai đoạn System Analysis & Requirements Definition đứng trước thiết kế và triển khai; các yêu cầu được cố định trong SRS chi tiết như cơ sở lập kế hoạch và hợp đồng. Hiệu quả trong các lĩnh vực ổn định và được quy định; rủi ro «đóng băng» yêu cầu được giảm thiểu bởi SRR/đánh giá và quản lý thay đổi thông qua CCB.[47][48][49]
  • Phương pháp luận linh hoạt (Agile). Phân tích là liên tục: thay vì SRS cuối cùng, product backlog được duy trì với các user story và tiêu chí chấp nhận, được tinh chỉnh trong backlog refinement; áp dụng BDD (Given–When–Then); rủi ro mất tính toàn vẹn kiến trúc được bù đắp bởi việc xây dựng kiến trúc sớm và khả năng truy vết minh bạch của yêu cầu ↔ triển khai/kiểm thử.[50][51][52]
  • DevOps và SRE. Các bản phát hành thường xuyên đòi hỏi các yêu cầu vận hành «mặc định»: tự động hóa, khả năng quan sát, khôi phục. Các yêu cầu phi chức năng được hình thành dưới dạng SLO/SLI, quản lý error budget; các tác vụ về log/metric/trace/alert được thêm vào backlog; cho việc phát hành không có downtime — các mẫu blue/green và các mẫu khác.[53][54][55]
  • Quản lý yêu cầu và rủi ro. Các yêu cầu trong ALM có trạng thái và liên kết với tác vụ/phiên bản/lỗi; bắt buộc phải có version control, change impact analysis và tái ưu tiên hóa thường xuyên.[56][57]
  • Đảm bảo chất lượng (QA). Chất lượng được đặt nền tảng ở giai đoạn yêu cầu: đánh giá, «Three Amigos», kế hoạch Acceptance Test Plan, kiểm thử tự động cho tiêu chí chấp nhận (BDD/ATDD).[58][59]
  • Khả năng quan sát và độ tin cậy. Các yêu cầu bao gồm SLA/SLO, MTTR và MTBF với các mục tiêu có thể đo lường và phương pháp kiểm soát; các tham số đến từ kinh doanh/vận hành và được đưa vào kiến trúc và kiểm thử độ tin cậy.[60][61]

Chỉ số và chất lượng tài liệu

Các tiêu chí được chấp nhận rộng rãi được áp dụng để đánh giá công việc của nhà phân tích hệ thống và chất lượng kết quả của anh ta. Yêu cầu và mô hình chất lượng — là nền tảng của dự án thành công, vì vậy chúng được quản lý trong toàn bộ vòng đời (elicitation → specification → verification/validation → change management). Các thuộc tính chất lượng cơ bản của yêu cầu được quy định trong các tiêu chuẩn ISO/IEC/IEEE 29148 và (lịch sử) IEEE 830.[3][62][1]

  • Tính đúng đắn (Correctness) — yêu cầu phản ánh nhu cầu thực sự và được thống nhất với các chuyên gia trong lĩnh vực nghiệp vụ; được xác nhận bởi việc xác nhận (review/inspection, nguyên mẫu, kịch bản).[1][4]
  • Tính đầy đủ (Completeness) — các khía cạnh và điều kiện quan trọng đã được tính đến.
    • Tính đầy đủ của từng yêu cầu riêng lẻ: các chi tiết cần thiết được chỉ định (ví dụ: «chỉ báo chuyển sang trạng thái đỏ khi có lỗi», không chỉ «trở thành màu đỏ»).
    • Tính đầy đủ của đặc tả: các kịch bản/vai trò được bao phủ, NFR được xác định; đạt được bằng danh sách kiểm tra và khả năng truy vết đến mục tiêu kinh doanh; kiểm toán độc lập về tính đầy đủ (QA/review) rất hữu ích.[3][63]
  • Tính rõ ràng (Unambiguity) — các công thức được diễn giải theo một cách duy nhất; bảng thuật ngữ, các mẫu dạng «hệ thống phải làm A, khi B, nếu C», ví dụ giúp ích; các biểu đồ đi kèm với chú giải. Kiểm tra — nguyên tắc «bốn mắt».[3][1]
  • Tính nhất quán (Consistency) — các yêu cầu không mâu thuẫn với nhau và với các ràng buộc bên ngoài; áp dụng cấu trúc hóa, bảng tổng hợp thuộc tính, đánh giá nhóm; đối chiếu các quy định/tiêu chuẩn.[3][63]
  • Khả năng xác minh/kiểm thử (Verifiability) — việc đạt được được xác nhận bởi kiểm thử/trình diễn/phân tích; các công thức không thể kiểm chứng được thay thế bằng các tiêu chí có thể đo lường; đối với NFR, các chỉ số và tiêu chí chấp nhận được xác định trước.[3][63]
  • Khả năng thay đổi và truy vết (Modifiability & Traceability) — ID duy nhất, cấu trúc logic («một ý tưởng — một đoạn»), không có trùng lặp; các liên kết «yêu cầu ↔ nguồn/đích/thiết kế/kiểm thử» được duy trì, ma trận khả năng truy vết (RTM) được quản lý.[64][3]
  • Phân hạng và ưu tiên hóa — chất lượng của tập hợp yêu cầu; sử dụng kỹ thuật MoSCoW và MCDM (ví dụ: AHP); ưu tiên hóa cùng với kinh doanh ảnh hưởng đến lập kế hoạch và rủi ro.[65][66]

Chỉ số chất lượng yêu cầu (ví dụ):[63][1]

  • mật độ lỗi yêu cầu (số nhận xét trên 100 yêu cầu);
  • số lần thay đổi sau khi cố định cơ sở;
  • các chỉ số coverage: tỷ lệ yêu cầu có kiểm thử; tỷ lệ yêu cầu có thể truy vết đến mục tiêu kinh doanh;
  • độ ổn định yêu cầu (tỷ lệ yêu cầu được thêm/xóa so với tổng số trong một khoảng thời gian);
  • kích thước/độ phức tạp của đặc tả (số yêu cầu trung bình trong một use case, độ sâu phân rã);
  • sự hài lòng của các bên liên quan (khảo sát).

Trong các quy trình trưởng thành (ví dụ: CMMI cấp độ 3+), các quy định về chất lượng yêu cầu được áp dụng: kiểm tra hình thức, kiểm toán tuân thủ mẫu, thu thập/phân tích chỉ số.[67] Trong các lĩnh vực quan trọng (hàng không, vũ trụ, v.v.), các phương pháp hình thức được áp dụng để tăng độ tin cậy.[68]

Các lỗi điển hình

Trong các dự án IT, thường gặp các lỗi phân tích hệ thống: yêu cầu không đầy đủ và không rõ ràng, mâu thuẫn, ranh giới mơ hồ, bỏ qua các khía cạnh phi chức năng, tích hợp bị bỏ sót và bảo mật muộn. Điều này dẫn đến việc làm lại, chậm trễ, tăng chi phí và lỗi.

Các vấn đề điển hình, hậu quả và cách phòng ngừa.

  • Yêu cầu không đầy đủ và bị bỏ sót. Các vai trò có quyền đặc biệt, các trường hợp biên và NFR bị bỏ qua. Hậu quả: làm lại kiến trúc và trì hoãn ra mắt. Cách phòng tránh: danh sách kiểm tra, động não «điều gì sẽ xảy ra nếu…», tham gia sớm của người kiểm thử, khả năng truy vết đến mục tiêu kinh doanh.[1][69]
  • Công thức không rõ ràng, mơ hồ. Hậu quả: nhà phát triển thực hiện «không đúng», khách hàng không hài lòng. Cách phòng tránh: tiêu chí có thể đo lường, bảng thuật ngữ, mẫu «A, khi B, nếu C», peer‑review.[3][69]
  • Yêu cầu mâu thuẫn. Hậu quả: chậm trễ trong việc làm rõ, làm lại khi tích hợp. Cách phòng tránh: cấu trúc hóa, đối chiếu quy tắc kinh doanh/quy định, các phiên giải quyết xung đột, kiểm tra tính nhất quán khi đánh giá.[3][1]
  • Hội chứng «mạ vàng» (gold‑plating). Hậu quả: tăng phạm vi, phức tạp hóa, các điểm lỗi mới. Cách phòng tránh: gắn từng yêu cầu với mục tiêu/chỉ số; trong Agile — không đưa những thứ không cần thiết vào backlog; cố định scope; xem YAGNI.
  • Chi tiết hóa quá mức ở nơi không cần thiết. Cách phòng tránh: tách biệt cái gì/tại sao (yêu cầu) khỏi làm thế nào (thiết kế/triển khai); áp dụng design‑free requirements ở những nơi phù hợp.[3]
  • Vi phạm khả năng quản lý yêu cầu. Hậu quả: lộn xộn về phiên bản, thực hiện «không đúng». Cách phòng tránh: nguồn thông tin duy nhất trong ALM, lịch sử và trạng thái, RTM và change impact analysis; quản lý thay đổi thông qua CCB.[64][1]
  • Thiếu sự tham gia của người dùng. Cách phòng tránh: phỏng vấn, quan sát, nguyên mẫu, trình diễn thường xuyên; xác nhận rõ ràng với các bên liên quan.[3][1]
  • «Tê liệt phân tích» quá lâu. Cách phòng tránh: vùng đủ dùng, tính lặp và timeboxing; khởi động MVP/các phần tăng dần và điều chỉnh dựa trên phản hồi.[1]
  • Bỏ qua các yêu cầu phi chức năng. Cách phòng tránh: phân tách NFR (ví dụ: FURPS+), đặt tiêu chí có thể đo lường, đưa chúng vào kế hoạch kiểm thử và các quyết định kiến trúc.[1][3]
  • Lỗi giao tiếp và «yếu tố con người». Cách giải quyết: phát triển kỹ năng phỏng vấn và hỗ trợ nhóm, duy trì tính trung lập, ghi lại các quyết định và nguồn yêu cầu (khả năng truy vết đến mục tiêu).[1]

Hầu hết các vấn đề đều quy về chất lượng công thức, tính đầy đủ và khả năng quản lý yêu cầu; việc áp dụng các tiêu chuẩn ISO/IEC/IEEE 29148 và các thực hành SWEBOK (khả năng xác nhận, khả năng truy vết, tính lặp) giảm đáng kể rủi ro trễ tiến độ và làm lại.[3][1]

Hạn chế

Mặc dù hiệu quả trong việc giảm sự không chắc chắn, phân tích hệ thống có những hạn chế của mình:

  • Thực tế thay đổi và phức tạp. Không thể tính đến tất cả các yếu tố, đặc biệt trong các dự án dài hạn. Một số yêu cầu chắc chắn sẽ xuất hiện sau khi hệ thống được ra mắt. Điều quan trọng là cố gắng giảm thiểu sự bất ngờ, nhưng cần phải sẵn sàng cho những thay đổi.
  • Yêu cầu phụ thuộc vào con người. Ưu tiên của doanh nghiệp, luật pháp và thị trường có thể thay đổi. Phân tích hệ thống ghi lại trạng thái hiện tại và không thể dự đoán tất cả các thay đổi bên ngoài. Để thích nghi, cần thường xuyên cập nhật yêu cầu và làm việc theo hướng lặp.
  • Người dùng không phải lúc nào cũng biết mình muốn gì cho đến khi nhìn thấy. Đây là hạn chế đã biết. Nguyên mẫu hóa và các phương pháp luận linh hoạt như Agile giúp vượt qua vấn đề này. Phân tích trên giấy có những giới hạn của nó, và để có được dữ liệu chính xác, cần có phản hồi từ các triển khai.
  • Cân bằng giữa thời gian và chất lượng. Phân tích quá chi tiết có thể trở nên lỗi thời. Trong các lĩnh vực đổi mới, tốt hơn là nhanh chóng tạo ra sản phẩm khả thi tối thiểu (MVP) và nhận dữ liệu thực tế. Phân tích hệ thống hiệu quả trong các lĩnh vực ổn định, nhưng trong các dự án nghiên cứu (R&D) vai trò của nó bị hạn chế.
  • Yếu tố con người. Ngay cả những phương pháp luận tốt nhất cũng không bù đắp được sự thiếu năng lực của nhà phân tích hay sự vắng mặt của khách hàng. Điều quan trọng là tất cả các bên tham gia vào quy trình đều phải được tham gia và có động lực.

Ảnh hưởng của các công nghệ hiện đại đến phân tích hệ thống trong IT

Phân tích hệ thống trong IT liên tục phát triển dưới tác động của các đổi mới công nghệ. Nhà phân tích thế kỷ XXI làm việc trong điều kiện tăng trưởng bùng nổ của dữ liệu, triển khai AI khắp nơi, chu kỳ phát triển nhanh và chú ý ngày càng tăng đến bảo mật. Thực hành phân tích hệ thống thành công đòi hỏi nắm vững kiến thức mới (Data Science, an ninh mạng, công nghệ đám mây) và linh hoạt trong việc áp dụng các phương pháp.

  • Dữ liệu và AI/ML: những gì được thêm vào phân tích. Đối với các hệ thống có AI, ngay từ đầu đã cố định các mục tiêu và bối cảnh ứng dụng, các yêu cầu đối với nguồn và chất lượng dữ liệu, cũng như các chỉ số tin cậy vào quyết định của mô hình (độ tin cậy, bảo mật, khả năng giải thích, quyền riêng tư, công bằng). Các kiểm tra TEVV (testing, evaluation, verification, validation), giám sát trong vận hành và việc tắt/loại bỏ mô hình an toàn được lên kế hoạch. Các bước này tương ứng với các chức năng GOVERN–MAP–MEASURE–MANAGE từ khung quản lý rủi ro AI của NIST; chúng được phản ánh trong SRS, kiến trúc và kế hoạch xác minh/vận hành.[70]
  • DevSecOps: bảo mật «từ bên trái» và theo mặc định. Tích hợp bảo mật vào từng giai đoạn CI/CD trở thành tiêu chuẩn: kiểm tra tự động (SAST/DAST), quét phụ thuộc và container, chính sách triển khai, khả năng quan sát cơ bản. Các registry tài liệu đáng tin cậy và các image «đã được gia cố» được chuẩn hóa được sử dụng; các nguyên tắc zero trust được áp dụng. Trong phân tích hệ thống, các điểm kiểm soát pipeline (điều kiện để vượt qua các giai đoạn), mối liên kết giữa yêu cầu và các kiểm soát bảo mật và các quy tắc chuyển tiếp giữa các môi trường (dev/test/stage/prod) được mô tả trước.[71]
  • Những gì thay đổi trong tài liệu (tài liệu dự án). Phần nào xuất hiện hoặc được làm rõ trong các tài liệu chính khi có Big Data và AI/ML và khi làm việc theo DevSecOps:
    • SRS / Đặc tả yêu cầu: mục tiêu và bối cảnh ứng dụng AI; các yêu cầu về dữ liệu (nguồn gốc, chất lượng, ràng buộc đạo đức và pháp lý); chỉ số mô hình (độ chính xác, độ tin cậy, thời gian phản hồi); kế hoạch TEVV (testing, evaluation, verification, validation); các yêu cầu về tính minh bạch/khả năng giải thích và quyền riêng tư; tiêu chí để tắt/loại bỏ mô hình khỏi vận hành.[70]
    • Kiến trúc và quyết định (Architecture, ADR): kết quả mô hình hóa mối đe dọa; các biện pháp «bảo mật theo mặc định» (mã hóa, kiểm soát truy cập, quản lý bí mật, nguyên tắc quyền tối thiểu); các ràng buộc về việc sử dụng dữ liệu/mô hình; các bản ghi ADR với đánh giá rủi ro và đánh đổi.[71][70]
    • Kế hoạch xác minh và xác nhận (V&V / TEVV): các kịch bản kiểm thử mô hình và dữ liệu; ngưỡng chấp nhận cho các chỉ số chất lượng; giám sát độ trôi dữ liệu/mô hình; các quy trình đánh giá lại định kỳ và xác nhận lại.[70]
    • Chính sách CI/CD và «cổng» pipeline: kiểm tra tự động SAST/DAST, SCA (phụ thuộc), quét container; ký và lưu trữ tài liệu trong các registry đáng tin cậy; các quy tắc chuyển tiếp giữa các môi trường (dev/test/stage/prod) và điều kiện chặn build khi kiểm tra thất bại; các yêu cầu về khả năng quan sát theo mặc định.[71]
    • Kế hoạch quản lý dữ liệu và mô hình: danh mục nguồn và lineage; tiêu chí chất lượng và sẵn có của dữ liệu; các phiên bản dataset/mô hình; lịch (tái) huấn luyện và kiểm soát bias; chính sách truy cập và lưu trữ; kế hoạch hủy kích hoạt mô hình an toàn và xóa dữ liệu nếu cần.[70]
    • Vận hành và khả năng quan sát (Ops/Runbook): chỉ số tin cậy AI và SLO; kiểm toán và ghi nhật ký; cảnh báo về suy giảm/bất thường; kế hoạch ứng phó sự cố; fallback/kill‑switch cho các thành phần AI; các yêu cầu về báo cáo và phân tích sau sự cố.[70][71]
    • Khả năng truy vết (end‑to‑end): các liên kết rõ ràng «yêu cầu ↔ kiểm soát/kiểm tra trong pipeline» và «yêu cầu ↔ kiểm thử/giám sát trong vận hành», để có thể kiểm chứng được bảo mật và chất lượng trong toàn bộ vòng đời.[71][70]
  • Vai trò của nhà phân tích hệ thống.
    • quản lý bối cảnh và rủi ro AI (các tác nhân, kịch bản ứng dụng, giả định và ràng buộc dữ liệu);
    • đảm bảo khả năng truy vết «yêu cầu ↔ kiểm soát bảo mật trong pipeline»;
    • hình thành các yêu cầu phi chức năng có thể kiểm chứng (bảo mật, minh bạch, khả năng quan sát) trong toàn bộ vòng đời hệ thống.[70][71]

Sự khác biệt so với phân tích hệ thống cổ điển

Thuật ngữ «phân tích hệ thống» về mặt lịch sử rộng hơn phát triển phần mềm. Phân tích hệ thống cổ điển — phương pháp tiếp cận để giải quyết các vấn đề liên ngành phức tạp (xã hội, kinh tế, quản lý), dựa trên tư duy hệ thống và các phương pháp định lượng, thường để hỗ trợ các quyết định quản lý. Trong IT, phân tích hệ thống được hiểu là một ngành ứng dụng trong lĩnh vực kỹ thuật phần mềm, tập trung vào việc tạo ra các hệ thống thông tin.

Dưới đây — các điểm khác biệt chính.

  • Mục tiêu và đối tượng phân tích. Phân tích cổ điển giải quyết các vấn đề kém cấu trúc, «mờ» và cải thiện các hệ thống kinh tế-xã hội hiện có (mạng giao thông đô thị, chiến lược công ty, chính sách môi trường). Đối tượng — hệ thống thực tế; nhiệm vụ — giúp người ra quyết định chọn hướng hành động. Đối với phân tích hệ thống trong IT, mục tiêu là thiết kế và tạo ra hệ thống thông tin mới hoặc sản phẩm phần mềm đáp ứng các yêu cầu. Đối tượng — hệ thống đang được thiết kế; trọng tâm — hành vi và đặc điểm mà người dùng cần.
  • Cơ sở phương pháp luận. Các trường phái cổ điển dựa trên tư duy hệ thống và thường dựa vào toán học. Phương pháp cứng (hard systems) — hình thức hóa vấn đề, tiêu chí định lượng, tối ưu hóa (như trong operations research). Các phương pháp luận mềm (soft systems) thừa nhận tính đa dạng của quan điểm; ví dụ — Soft Systems Methodology (SSM), nơi thông qua thảo luận và các mô hình khái niệm, các thay đổi mong muốn được thống nhất. Trong IT, nền tảng là các ngành kỹ thuật: kỹ thuật yêu cầu, thiết kế phần mềm, các framework kiến trúc. Các quy trình được chuẩn hóa (ISO/IEC/IEEE 15288, 12207, 29148), các ký hiệu UML/SysML và các thực hành quản lý thay đổi được áp dụng.
  • Vai trò và tài liệu. Trong phân tích cổ điển, vai trò «nhà phân tích hệ thống» thường không chính thức; kết quả — báo cáo phân tích, khuyến nghị, mô hình toán học, kịch bản «điều gì sẽ xảy ra nếu». Trong IT, vai trò của nhà phân tích (hoặc nhà phân tích kinh doanh) được chính thức hóa; các đặc tả yêu cầu, mô hình hệ thống (UML, ER), đặc tả giao diện, user story và backlog được xuất bản — các tài liệu được sử dụng trực tiếp bởi nhà phát triển và người kiểm thử.
  • Vòng đời và quy trình. Phân tích cổ điển không có mẫu duy nhất: các bước phụ thuộc vào vấn đề (trong SSM — từ nghiên cứu tình huống đến thực hiện thay đổi). Trong IT, các chu kỳ SDLC tiêu chuẩn được chấp nhận: trong mô hình thác nước, có một giai đoạn phân tích yêu cầu riêng biệt; trong các phương pháp lặp và linh hoạt, phân tích là hoạt động liên tục của mỗi sprint. Các thực hành hiện đại (DevOps, CI/CD) mở rộng phạm vi phân tích sang vận hành: các yêu cầu về bảo trì, khả năng quan sát và khả năng cập nhật được tính đến. Nói cách khác, phân tích hệ thống trong IT được tích hợp vào vòng đời phát triển, trong khi phân tích cổ điển thường được thực hiện như một hoạt động dự án/tư vấn.

Nhà phân tích hệ thống

Nhà phân tích hệ thống trong IT — chuyên gia chịu trách nhiệm về tư duy hệ thống trong việc thiết kế và phát triển hệ thống thông tin: hình thành và xác nhận yêu cầu, mô hình hóa (UML/BPMN), phối hợp các quyết định kiến trúc và đảm bảo tích hợp. Vai trò và yêu cầu trình độ tại Liên bang Nga được quy định trong tiêu chuẩn nghề nghiệp và FGOS.

Mục tiêu chính của loại hoạt động nghề nghiệp: Đảm bảo sự phù hợp của dịch vụ IT, hệ thống tự động hóa, hệ thống thông tin tự động hóa, hệ thống quản lý tự động hóa, sản phẩm phần mềm, thông tin hoặc công cụ (sau đây - Hệ thống) với môi trường, yêu cầu và ràng buộc ban đầu, mục tiêu tự động hóa và hoạt động được tự động hóa bằng cách phát triển và chuyển giao các quyết định dự án chất lượng và liên kết với nhau cho các bên liên quan khi khởi động và phối hợp công việc của từng người thực hiện trong toàn bộ vòng đời Hệ thống (Tiêu chuẩn nghề nghiệp «Nhà phân tích hệ thống» (lệnh của Bộ Lao động Liên bang Nga ngày 27.04.2023 № 367н).[72]

Bảng thuật ngữ các khái niệm chính

Khái niệm cơ bản và các bên tham gia

  • Phân tích hệ thống trong IT — ngành học, đối tượng của nó là hệ thống thông tin trong toàn bộ vòng đời, từ ý tưởng đến vận hành.
  • Các bên liên quan (Stakeholders) — cá nhân hoặc nhóm quan tâm đến dự án hoặc bị ảnh hưởng bởi nó (khách hàng, người dùng, quản lý).
  • Tài liệu dự án — tài liệu và kết quả được tạo ra trong quá trình dự án, chẳng hạn như đặc tả, mô hình, kế hoạch và quyết định.

Yêu cầu: các loại và tài liệu

  • Yêu cầu chức năng — mô tả hệ thống phải làm gì; các chức năng và hành vi của nó.
  • Yêu cầu phi chức năng — mô tả các thuộc tính chất lượng của hệ thống (độ tin cậy, hiệu năng, bảo mật, khả năng sử dụng, khả năng mở rộng, v.v.).
  • Đặc tả yêu cầu (ban đầu) — tài liệu chứa tập hợp yêu cầu ban đầu được thu thập ở các giai đoạn đầu của dự án.
  • SRS (Software Requirements Specification) — tài liệu được chuẩn hóa mô tả chi tiết các yêu cầu phần mềm theo các tiêu chuẩn quốc tế (ví dụ: ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — tài liệu mô tả các yêu cầu của người dùng đối với hệ thống từ góc độ quy trình kinh doanh và kỳ vọng của người dùng cuối.
  • Yêu cầu có ý nghĩa kiến trúc (ASR) — các yêu cầu ảnh hưởng đáng kể đến các quyết định và đánh đổi kiến trúc.
  • Yêu cầu liên chức năng (CFR) — đồng nghĩa của yêu cầu phi chức năng, nhấn mạnh tính chất xuyên suốt của chúng.
  • Tiêu chí chấp nhận (Acceptance Criteria) — các điều kiện có thể kiểm chứng, khi được đáp ứng, công việc về yêu cầu được coi là đã chấp nhận.
  • Definition of Ready (DoR) — thỏa thuận về sự sẵn sàng của một mục backlog để phát triển (rõ ràng, ước tính, tiêu chí).
  • Definition of Done (DoD) — thỏa thuận về «sự hoàn thành» của công việc (mã, kiểm thử, tài liệu, triển khai).
  • Ràng buộc (Constraint) — điều kiện cứng, giới hạn các giải pháp (thời hạn, nền tảng, tiêu chuẩn, giấy phép).
  • Giả định (Assumption) — giả thiết được chấp nhận mà không có bằng chứng, đòi hỏi xác nhận sau này.
  • Chất lượng yêu cầu — các thuộc tính theo ISO 29148: tính rõ ràng, tính đầy đủ, tính nhất quán, khả năng kiểm chứng, tính nguyên tử.

Hình thức hóa, khả năng truy vết và ưu tiên hóa yêu cầu

  • Hình thức hóa yêu cầu — quá trình chuyển đổi các yêu cầu không chính thức thành các yêu cầu rõ ràng, có thể kiểm chứng và không mơ hồ.
  • Khả năng truy vết yêu cầu — khả năng theo dõi vòng đời của yêu cầu từ nguồn của nó đến triển khai, kiểm thử và phân phối.
  • Bidirectional traceability (khả năng truy vết hai chiều) — khả năng theo dõi các liên kết giữa yêu cầu, các yếu tố thiết kế và các kịch bản kiểm thử theo cả hai chiều thuận và nghịch.
  • MoSCoW — kỹ thuật ưu tiên hóa yêu cầu, phân loại chúng thành Must-have (phải có), Should-have (nên có), Could-have (có thể có) và Won't-have (sẽ không có).
  • BDD (Behavior-Driven Development) — phương pháp luận phát triển trong đó các kiểm thử được viết bằng ngôn ngữ tự nhiên, tập trung vào hành vi của hệ thống từ góc độ người dùng (định dạng Given–When–Then).

Ký hiệu và mô hình hóa

  • UML (Unified Modeling Language) — ngôn ngữ mô hình hóa đồ họa được chuẩn hóa để đặc tả, trực quan hóa, xây dựng và tài liệu hóa các thành phần của hệ thống phần mềm.
  • SysML (Systems Modeling Language) — mở rộng UML cho kỹ thuật hệ thống, hỗ trợ mô hình hóa các khía cạnh khác nhau của các hệ thống phức tạp, bao gồm yêu cầu, hành vi, cấu trúc và tham số.
  • BPMN (Business Process Model and Notation) — tiêu chuẩn ký hiệu đồ họa để mô tả quy trình nghiệp vụ, cho phép trực quan hóa luồng công việc, sự kiện, cổng và pool.
  • MBSE (Model-Based Systems Engineering) — phương pháp tiếp cận kỹ thuật hệ thống, nơi mô hình là tài liệu trung tâm ở tất cả các giai đoạn vòng đời hệ thống, từ yêu cầu đến kiểm thử.
  • ArchiMate — ký hiệu kiến trúc doanh nghiệp (kinh doanh, ứng dụng, công nghệ) và các mối quan hệ của chúng.
  • DMN (Decision Model and Notation) — mô hình hóa các quyết định kinh doanh và bảng quy tắc.
  • DFD (Data Flow Diagram) — biểu đồ luồng dữ liệu (bối cảnh, các cấp độ phân rã).
  • ERD (Entity-Relationship Diagram) — mô hình lĩnh vực nghiệp vụ với các thực thể, mối quan hệ và thuộc tính.
  • Ma trận CRUD — sự tương ứng của các thao tác Create/Read/Update/Delete với các thực thể và vai trò/chức năng.

Phong cách kiến trúc và đánh giá giải pháp

  • Kiến trúc nguyên khối — phương pháp tiếp cận kiến trúc trong đó toàn bộ hệ thống được phát triển như một mô-đun duy nhất, không thể phân chia.
  • Kiến trúc vi dịch vụ — phương pháp tiếp cận kiến trúc trong đó hệ thống được xây dựng như một tập hợp các dịch vụ nhỏ, có thể triển khai và mở rộng độc lập.
  • Trade-off (đánh đổi) — lựa chọn giữa các đặc điểm hoặc giải pháp loại trừ lẫn nhau hoặc mâu thuẫn, nơi việc cải thiện một đặc điểm xảy ra với chi phí là sự suy giảm của đặc điểm kia.
  • ATAM (Architecture Tradeoff Analysis Method) — phương pháp đánh giá kiến trúc phần mềm, được sử dụng để phân tích các đánh đổi giữa các thuộc tính chất lượng (ví dụ: hiệu năng, khả năng mở rộng).

Kiến trúc doanh nghiệp và các framework

  • TOGAF (The Open Group Architecture Framework) — một trong những framework kiến trúc doanh nghiệp phổ biến nhất, bao gồm phương pháp ADM (Architecture Development Method) để phát triển và quản lý kiến trúc.
  • Zachman Framework — bản thể học về các tài liệu kiến trúc doanh nghiệp, được trình bày dưới dạng ma trận 6×6, phân loại các khía cạnh kiến trúc khác nhau từ các góc nhìn khác nhau.

Phương pháp tiếp cận phân tích và quy trình phát triển

  • Phương pháp cứng (Hard Systems) — phương pháp luận phân tích hệ thống, giả định các mục tiêu và yêu cầu có thể được hình thức hóa trước, phân rã và thiết kế «từ trên xuống», hiệu quả cho các nhiệm vụ được xác định rõ ràng.
  • Phương pháp mềm (Soft Systems) — phương pháp luận phân tích hệ thống, được áp dụng khi mục tiêu không rõ ràng và có nhiều quan điểm của các bên liên quan, nhằm mục đích thống nhất hiểu biết về vấn đề và các thay đổi mong muốn.
  • SSM (Soft Systems Methodology) — phương pháp luận tiếp cận hệ thống mềm cụ thể, được phát triển bởi Peter Checkland, sử dụng các công cụ như rich picture, định nghĩa gốc và CATWOE.
  • Waterfall (mô hình thác nước) — phương pháp luận phát triển phần mềm cổ điển, nơi các giai đoạn (phân tích, thiết kế, triển khai, kiểm thử, triển khai) được thực hiện tuần tự, với việc hoàn thành đầy đủ giai đoạn trước trước khi bắt đầu giai đoạn tiếp theo.
  • Agile — nhóm các phương pháp luận phát triển phần mềm linh hoạt, tập trung vào phát triển lặp, thích nghi với thay đổi, tương tác với khách hàng và cung cấp giá trị liên tục.

Phương pháp lựa chọn và các lỗi điển hình

  • AHP (Analytic Hierarchy Process) — phương pháp lựa chọn đa tiêu chí, cho phép cấu trúc hóa các vấn đề phức tạp và đánh giá các phương án dựa trên hệ thống phân cấp tiêu chí.
  • Gold-plating (hội chứng «mạ vàng») — lỗi trong phân tích hệ thống, bao gồm việc thêm chức năng không được yêu cầu bởi các bên liên quan, dẫn đến tăng phạm vi và độ phức tạp của dự án.

Liên kết

  • ISO/IEC/IEEE 15288:2023 — System life cycle processes
  • ISO/IEC/IEEE 12207:2017 — Software life cycle processes
  • ISO/IEC/IEEE 29148:2018 — Requirements engineering
  • ISO/IEC/IEEE 42010:2022 — Architecture description
  • ISO/IEC 25010:2023 — Product quality model (SQuaRE)
  • ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288
  • ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation)
  • ISO/IEC/IEEE 42020:2019 — Architecture processes
  • ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts
  • IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation
  • UML 2.5.1 — OMG Specification
  • BPMN 2.0.2 — OMG Specification
  • SysML v1.7 — OMG Specification
  • TOGAF Standard, 10th Edition — The Open Group
  • ArchiMate 3.2 — The Open Group
  • SEI ATAM — Architecture Tradeoff Analysis Method
  • NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF)
  • SWEBOK Guide v4.0a — IEEE Computer Society (PDF)
  • Guide to the Systems Engineering Body of Knowledge (SEBoK)
  • BABOK Guide v3 — IIBA
  • Google SRE Books — Official site
  • Microsoft Azure Well-Architected Framework — Official docs
  • Phân tích hệ thống bằng ngôn ngữ đơn giản. YouTube
  • Phân tích hệ thống trong IT bằng ngôn ngữ đơn giản. YouTube

Tài liệu tham khảo

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, xuất bản lần thứ 5.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Phiên bản miễn phí chính thức.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Tải xuống miễn phí chính thức (theo giấy phép).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, xuất bản lần thứ 4.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, xuất bản lần thứ 3.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, xuất bản lần thứ 2.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, xuất bản lần thứ 5.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, xuất bản lần thứ 3.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, xuất bản lần thứ 4.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, xuất bản lần thứ 11.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, xuất bản lần thứ 8.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, xuất bản lần thứ 7.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, xuất bản lần thứ 3.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, xuất bản lần thứ 2.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, xuất bản lần thứ 4.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, xuất bản lần thứ 4.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, xuất bản lần thứ 2.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Ghi chú

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (обзор). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).
Retrieved from "https://systems-analysis.ru/int/index.php?title=Phân_tích_hệ_thống_trong_CNTT&oldid=23909"