Systems analysis in IT — IT 분야 시스템 분석

From Systems analysis Wiki
Jump to navigation Jump to search

IT에서의 시스템 분석 (Systems Analysis and Design) — 구상에서 운영에 이르기까지 정보 시스템의 설계 및 개발에 대한 접근 방식으로, 요구사항 식별, 요구사항 공식화, 주제 영역 및 프로세스 모델링, 대안 및 위험 평가를 포함한다. 다시 말해, IT에서의 시스템 분석이란 개발 단계 중 전문가들이 문제를 연구하고, 시스템이 무엇을 해야 하는지를 결정하며, 시스템 구축을 위한 솔루션을 개발하는 단계이다.

고전적 시스템 분석은 소프트웨어 개발뿐만 아니라 조직 변화, 전략 및 기타 측면을 포함하는 광범위한 응용 분야를 다룬다.[1] [2]

IT 분야 시스템 분석의 대상과 과제

IT 분야 시스템 분석의 대상은 구상과 타당성 검토부터 구현 및 운영에 이르기까지 전체 생명주기에 걸친 정보 시스템(소프트웨어 제품 및/또는 서비스)이다.

시스템 분석의 과제는 비즈니스 요구를 일관되고 검증 가능한 요구사항 및 아키텍처 결정의 집합으로 변환하는 것이다: 이해관계자의 목표와 제약을 식별하고 문서화하며, 요구사항을 공식화하고, 주제 영역과 프로세스를 모델링하며, 대안의 실현 가능성과 위험을 평가하고, 선택된 아키텍처를 정당화한다. 그 결과로 합의된 문서가 생성되고 요구사항, 설계 결정, 테스트 간에 추적 가능한 연결이 수립된다. 이를 통해 개발 프로세스의 관리 가능성과 통제력이 확보된다.

시스템 분석의 과제에는 다음이 포함된다:

  • 이해관계자의 요구와 목표 식별. 분석가는 고객, 사용자 및 기타 이해 당사자의 기대를 수집하고 명확히 한다. 인터뷰, 설문, 관찰, 현행 프로세스 분석 등의 방법이 사용된다. 결과물로는 기능적 요구사항(「시스템이 무엇을 해야 하는가」)과 비기능적 요구사항(신뢰성, 성능, 보안 등)으로 구분된 초기 요구사항 명세가 생성된다.[1][2]
  • 요구사항의 공식화 및 문서화. 요청은 검증 가능한 요구사항으로 변환된다. 잘 작성된 요구사항은 명확하고 모호하지 않아야 하며, 완전하고, 일관성 있고, 검증 가능하며, 상위 목표까지 추적 가능해야 한다. 요구사항 집합은 합의되고 완결성 있어야 한다.[3][4] 실무에서는 ISO/IEC/IEEE 29148에 따른 SRS (Software Requirements Specification), 그리고 일부 산업 분야에서는 URS (User Requirements Specification)와 기능 명세서 등 표준화된 문서가 사용된다.[5][6][7]
  • 시스템 분석 및 모델링. 시스템이 어떻게 작동하고 외부 세계와 상호작용하는지를 이해하기 위해 모델이 구축된다: 사용 시나리오를 위한 유스케이스(Use Case) 다이어그램, 데이터 흐름 및 비즈니스 프로세스를 위한 DFD, 클래스/컴포넌트 다이어그램 등. 모델은 대안적 솔루션과 아키텍처를 비교하는 기초로 활용된다.[8][9][10]
  • 실현 가능성 평가 및 솔루션 선택. feasibility study(기술적, 조직적, 경제적, 일정적 실현 가능성)와 아키텍처 대안 간의 비교(trade-off)가 수행된다. 품질 속성(예: 성능, 확장성, 수정 가능성)에 따른 아키텍처 평가에는 ATAM (Architecture Tradeoff Analysis Method)과 같은 방법이 적용된다.[11][12] 예를 들어 모놀리식과 마이크로서비스 아키텍처 간의 선택[3]은 산업 가이드의 권고에 따라 명시적 트레이드오프(운영 복잡성 대 독립적 확장성 및 출시 속도)를 기반으로 한다.[13][14]
  • 설계 산출물 준비. 분석 결과 다음과 같은 산출물이 작성된다:
    • 승인된 요구사항 명세(중요도 포함),
    • 시스템의 개념적 모델(다이어그램/설명),
    • 아키텍처 및 설계 결정(데이터 스키마, 외부 시스템 인터페이스),
    • 구현 계획(단계/모듈).
    • 요구사항에서 설계 요소와 테스트까지의 추적 가능성(bidirectional traceability)을 확보하는 것이 매우 중요하다.[15][4]

IT 프로젝트의 성공은 요구사항 및 아키텍처에 대한 성숙한 실무에 크게 의존한다. McKinsey와 Oxford가 수행한 연구에 따르면 대형 IT 프로젝트는 종종 예산과 일정을 초과한다. 이 연구는 또한 전략을 올바르게 관리하고, 이해관계자와 상호작용하며, 요구사항을 효과적으로 수집하는 것이 얼마나 중요한지를 강조하였다. 이 모든 것이 프로젝트의 성공 또는 실패에 큰 영향을 미칠 수 있다.[16]

IT 시스템 분석의 접근 방식과 방법론

IT에서의 시스템 분석은 시스템 사고의 원칙과 소프트웨어 개발에 맞게 적용된 방법론에 기반한다. 실무에서는 「딱딱한」 접근 방식과 「부드러운」 접근 방식, 구조적 방법론, 객체지향 표기법, 프로세스 및 요구사항 모델링 언어가 혼합되어 사용된다.

  • 딱딱한 접근 방식과 부드러운 접근 방식. IT 프로젝트에서 딱딱한 접근 방식(hard systems)은 사전에 공식화 가능한 목표와 요구사항, 분해 및 「하향식」 설계를 전제로 한다. 부드러운 접근 방식(soft systems)은 목표가 불명확하고 다양한 관점이 존재할 때 적용된다. Soft Systems Methodology(SSM)의 요소(예: rich picture, 근본 정의, CATWOE)를 활용하여 문제 이해와 원하는 변화에 대한 합의를 도출하며, 이후 결과를 공식적 요구사항으로 변환한다.[17][18]
  • SSM(Soft Systems Methodology) 방법론. 원래 피터 체클랜드가 조직 변화를 위해 개발한 SSM은 IT의 사전 프로젝트 단계에서 유용하다: 문제 상황 탐구와 근본 정의 수립(CATWOE 포함)부터 개념적 모델을 현실과 비교하고 이해관계자 간 조율(accommodation)을 달성하는 단계까지 활용된다.[19][20]
  • 구조화된 방법론: SADT/IDEF0. SADT는 시스템을 기능의 계층구조로 모델링하며, 표준 표기법인 IDEF0(IEEE 1320.1)는 기능과 해당 I-C-O-M 인터페이스(입력, 제어, 출력, 메커니즘)를 기록한다. 이 방법은 알고리즘과 무관하게 기능 분해와 시스템 경계 합의에 적합하다.[21][22]
  • 객체지향 분석: UML과 SysML(MBSE). UML은 요구사항 및 설계를 위한 기본 언어(유스케이스, 클래스, 시퀀스 다이어그램 등)가 되었으며 사용자와의 시나리오 검증을 용이하게 한다. SysML은 시스템 엔지니어링을 위해 UML을 확장한 것으로(요구사항 다이어그램, 파라메트릭 다이어그램) MBSE 접근 방식을 기반으로 하며, 여기서 모델은 요구사항부터 테스트까지 모든 단계를 관통하는 중심 산출물이다.[23][24][25]
  • 비즈니스 프로세스 모델링: BPMN. BPMN 표준은 프로세스를 그래픽으로 설명하는 데 사용된다(풀, 작업 흐름, 이벤트, 게이트웨이). 요구사항 명세와 통합 분야에서 as-is/to-be 비교를 포함한다.[26][27]
  • 요구사항 엔지니어링과의 연계. 프로세스에는 도출–분석–명세–검증–변경 관리 단계가 포함되며, 「좋은 요구사항」의 기준과 SRS 구조는 ISO/IEC/IEEE 29148에 규정되어 있다. 우선순위 지정에는 MoSCoW (Must/Should/Could/Won't) 기법과 AHP와 같은 다기준 선택 방법이 사용된다. 애자일 프로세스에서는 시스템 분석 활동이 backlog refinement와 요구사항 추적 가능성에 반영된다.[28][29][30][31]
  • 시스템 엔지니어링과의 연계. 복잡한(사이버물리) 시스템의 경우 V-모델이 적용된다: 「왼쪽」 가지에는 시스템 분석과 아키텍처가, 「오른쪽」 가지에는 왼쪽 가지의 산출물과 연계된 통합, 검증 및 유효성 확인이 위치한다. 품질 속성에 따른 아키텍처 평가 방법에는 ATAM(trade-off 분석)이 포함된다.[32][33]

IT에서의 시스템 분석은 비전 합의를 위한 부드러운 방법론부터 공식 표기법과 표준에 이르기까지 검증된 접근 방식을 결합한다. 도구의 선택은 작업의 불확실성 정도에 의해 결정된다: 불확실성이 높을수록 SSM과 퍼실리테이션의 역할이 강화되고, 경계가 명확할수록 공식 모델(UML/SysML, IDEF0, BPMN)과 규정이 활용된다.

IT 아키텍처 및 엔터프라이즈 아키텍처와의 연계

IT 프로젝트에서의 시스템 분석은 아키텍처 설계와 밀접하게 연관되어 있다. 분석가와 아키텍트의 역할은 겹친다: 분석가는 요구사항과 논리적 모델을 수립하고, 아키텍트는 솔루션의 목표 구조와 기술적 트레이드오프를 결정한다. 작업은 협력적으로 이루어진다.

  • IT 시스템 아키텍처. 좁은 의미에서 소프트웨어 아키텍처는 컴포넌트의 구성, 그 관계, 그리고 솔루션 설계 시 따르는 원칙이다. 분석가는 아키텍처 스타일(계층형, 클라이언트-서버, 마이크로서비스, 이벤트 기반 등)을 고려하는 것이 중요하다. 비기능적 요구사항(신뢰성, 확장성, 수정 가능성)이 종종 아키텍처 결정과 그 트레이드오프를 결정하기 때문이다.[34][35] 분석 초기 단계에서 아키텍처 비전(high-level vision)을 수립하고 요구사항의 실행 가능성을 검증하기 위한 솔루션의 초안 윤곽을 작성한다(반복 주기의 길이와 세부 수준은 방법론에 따라 달라진다).[36]
  • 패턴 및 사전 결정. 비기능적 요구사항을 충족시키기 위해 아키텍처 패턴(architectural patterns)이 적용된다. 예를 들어, 비동기 상호작용과 느슨한 결합을 위해서는 이벤트 기반 아키텍처에서 메시지 브로커를 통한 publish–subscribe 방식이 사용된다.[37]
  • TOGAF (The Open Group Architecture Framework). 가장 널리 사용되는 엔터프라이즈 아키텍처 프레임워크 중 하나로, ADM(Architecture Development Method) 방법과 아키텍처 관리 산출물(저장소, 카탈로그/매트릭스, 원칙)을 포함한다. TOGAF에서 요구사항 관리는 ADM의 모든 단계에 통합된 횡단 프로세스이다.[36] 요구사항과 추적 가능성 지원을 위해 카탈로그와 매트릭스(예: 요구사항 ↔ 서비스, 기능 ↔ 컴포넌트)가 사용되며, Architecture Building Blocks와 Solution Building Blocks가 구별된다.[38][39] 엔터프라이즈의 원칙과 표준은 해당 카탈로그에 기록되며, 프로젝트 팀에 대한 외부 비기능적 요구사항으로 기능한다.[40] 솔루션이 목표 아키텍처에 부합함은 아키텍처 컴플라이언스 검토(Architecture Compliance Review) 절차로 확인된다.[41] TOGAF 접근 방식은 사전 Architecture Vision 수립과 이후 상세화(데이터/애플리케이션/기술), 마이그레이션 계획 및 요구사항 변경 관리를 포함한다.[42][43]
  • Zachman Framework. 엔터프라이즈 아키텍처 산출물에 대한 초기의 영향력 있는 온톨로지로, 6×6 매트릭스(관점 × 「무엇/어떻게/어디서/누가/언제/왜」 측면)로 표현된다. 「설계자」 행은 시스템 분석 및 설계에 해당하며, 열은 데이터, 기능/프로세스, 역할, 위치 및 동기의 완전한 고려를 정의한다. 이 프레임워크는 방법론이 아닌 분류 체계 역할을 하며 엔터프라이즈 환경에서 솔루션 설명의 완전성을 보장하는 데 도움을 준다.[44]
  • 엔터프라이즈 아키텍처(Enterprise Architecture, EA)와의 연계. 시스템 분석가는 EA의 맥락에서 작업한다: 새로운 요구사항은 비즈니스 역량과 운영 모델로 추적되며, 엔터프라이즈의 표준 및 원칙적 제약(보안, 상호운용성 등)이 적용된다.[45][36] 착수 단계에서 Architecture Vision; (목표/제약, 상위 수준 요구사항)이 수립된 후 분석가는 비전과 기업 표준에 대한 추적 가능성을 유지하면서 상세화를 진행한다. 표준 미준수는 아키텍처 검토에서 발견되어 솔루션 재작업으로 이어질 수 있다.[36][46]

요약하면: 시스템 분석과 아키텍처 설계는 「요구사항 → 아키텍처 결정 → 품질 속성 트레이드오프」의 연계를 형성한다. 방법(스타일/패턴, TOGAF 산출물, Zachman 분류)의 선택은 프로젝트의 성격과 엔터프라이즈 아키텍처 프레임워크에 의해 결정된다.

프로세스와 실무

시스템 분석은 소프트웨어 개발 및 운영의 전체 생명주기에 통합되어 비즈니스 목표, 아키텍처, 납품을 연결한다. 사전 프로젝트 연구, 접근 방식 선택, 검증 가능한 산출물 형성, 신뢰성·성능·보안·유지보수에 대한 요구사항을 포함한다. 폭포수 모델에서는 설계 및 구현 이전에 분석이 수행되고, 애자일 방법에서는 반복을 통해 지속적으로, DevOps에서는 운영 목표에 중점을 두고 수행된다. 접근 방식과 무관하게, 분석은 추적 가능성, 변경 및 위험 관리, 아키텍처 트레이드오프 문서화, 규제 제약 준수를 보장하여 개발을 예측 가능하고 관리 가능하게 만든다.

  • 고전적 SDLC (Waterfall). System Analysis & Requirements Definition 단계는 설계 및 구현보다 선행된다. 요구사항은 계획 및 계약의 기초로서 상세한 SRS에 고정된다. 안정적이고 규제된 도메인에서 효과적이며, 요구사항 「동결」 위험은 SRR/검토 및 CCB를 통한 변경 관리로 완화된다.[47][48][49]
  • 애자일 방법론(Agile). 분석은 지속적이다: 최종 SRS 대신 backlog refinement에서 구체화되는 인수 기준이 있는 user story로 구성된 제품 백로그를 관리하며, BDD(Given–When–Then)를 적용한다. 일관된 아키텍처 손실 위험은 조기 아키텍처 검토와 요구사항 ↔ 구현/테스트 간 명확한 추적 가능성으로 보완된다.[50][51][52]
  • DevOps와 SRE. 빈번한 릴리스에는 「기본」 운영 요구사항이 필요하다: 자동화, 관찰 가능성, 롤백. 비기능적 요구사항은 SLO/SLI로 공식화되고, error budget이 관리된다. 백로그에는 로그/메트릭/트레이스/알럿 작업이 추가되며, 다운타임 없는 릴리스를 위해 blue/green 등의 패턴이 사용된다.[53][54][55]
  • 요구사항 및 위험 관리. ALM의 요구사항은 작업/릴리스/결함과의 연결 상태를 가지며, 버전 관리, 변경 영향 분석, 정기적인 우선순위 재조정이 필수적이다.[56][57]
  • 품질 보증(QA). 품질은 요구사항 단계에서 결정된다: 검토, 「Three Amigos」, Acceptance Test Plan 수립, BDD/ATDD 인수 기준 자동화 테스트.[58][59]
  • 관찰 가능성과 신뢰성. 요구사항에는 측정 가능한 목표와 통제 방법이 있는 SLA/SLO, MTTR 및 MTBF가 포함된다. 매개변수는 비즈니스/운영 측에서 제공받아 아키텍처와 신뢰성 테스트에 반영된다.[60][61]

메트릭과 산출물 품질

시스템 분석가의 작업과 결과물의 품질을 평가하기 위해 일반적으로 인정된 기준이 적용된다. 양질의 요구사항과 모델은 성공적인 프로젝트의 기반이므로 전체 생명주기(도출 → 명세 → 검증/유효성 확인 → 변경 관리)에 걸쳐 관리된다. 요구사항 품질의 기본 속성은 ISO/IEC/IEEE 29148(역사적으로는 IEEE 830) 표준에 규정되어 있다.[3][62][1]

  • 정확성(Correctness) — 요구사항이 실제 요구를 반영하고 도메인 전문가와 합의되어 있다. 검증(검토/검사, 프로토타입, 시나리오)으로 확인된다.[1][4]
  • 완전성(Completeness) — 주요 측면과 조건이 모두 고려된다.
    • 개별 요구사항의 완전성: 필요한 세부 정보가 명시된다(예: 단순히 「빨간색으로 변경」이 아닌 「장애 시 지시자가 빨간색 상태로 전환」).
    • 명세의 완전성: 시나리오/역할이 포함되고 NFR이 정의된다. 체크리스트와 비즈니스 목표에 대한 추적 가능성으로 달성되며, 독립적인 완전성 감사(QA/검토)가 유용하다.[3][63]
  • 명확성(Unambiguity) — 표현이 단일한 방식으로만 해석된다. 용어집, 「시스템은 B일 때, C인 경우 A를 해야 한다」형식의 템플릿, 예시가 도움이 된다. 다이어그램에는 범례가 포함된다. 검증 방법 — 「네 눈의 원칙」.[3][1]
  • 일관성(Consistency) — 요구사항이 서로 및 외부 제약과 모순되지 않는다. 구조화, 속성 요약 테이블, 팀 검토를 적용하고, 규제/표준을 대조 확인한다.[3][63]
  • 검증 가능성/테스트 가능성(Verifiability) — 달성 여부가 테스트/시연/분석으로 확인된다. 검증 불가능한 표현은 측정 가능한 기준으로 대체되며, NFR에는 메트릭을 설정하고 인수 기준을 사전에 고정한다.[3][63]
  • 수정 가능성 및 추적 가능성(Modifiability & Traceability) — 고유 ID, 논리적 구조(「하나의 생각 — 하나의 단락」), 중복 없음. 「요구사항 ↔ 출처/목표/설계/테스트」 간 연결이 유지되며, 추적 가능성 매트릭스(RTM)가 관리된다.[64][3]
  • 순위 및 우선순위 지정 — 요구사항 집합의 품질. MoSCoW 기법과 MCDM(예: AHP)이 사용되며, 비즈니스와 함께하는 우선순위 지정이 계획 및 위험에 영향을 준다.[65][66]

요구사항 품질 메트릭 (예시):[63][1]

  • 요구사항 결함 밀도(요구사항 100개당 지적 사항 수);
  • 기준선 고정 후 변경 횟수;
  • 커버리지 메트릭: 테스트가 있는 요구사항 비율; 비즈니스 목표로 추적 가능한 요구사항 비율;
  • 요구사항 안정성(특정 기간 동안 추가/삭제된 요구사항과 전체 요구사항의 비율);
  • 명세의 규모/복잡성(유스케이스당 평균 요구사항 수, 분해 깊이);
  • 이해관계자 만족도(설문).

성숙한 프로세스(예: CMMI 수준 3 이상)에서는 요구사항 품질에 관한 규정이 적용된다: 공식 검사, 템플릿 준수 감사, 메트릭 수집/분석.[67] 핵심 도메인(항공, 우주 등)에서는 신뢰성 향상을 위해 형식적 방법을 적용한다.[68]

일반적인 오류

IT 프로젝트에서는 시스템 분석 오류가 자주 발생한다: 불완전하고 모호한 요구사항, 모순, 불명확한 경계, 비기능적 측면의 무시, 누락된 통합, 뒤늦은 보안 고려. 이는 재작업, 지연, 비용 증가 및 결함으로 이어진다.

일반적인 문제, 그 결과 및 예방 방법.

  • 불완전성 및 누락된 요구사항. 특별한 권한을 가진 역할, 경계 케이스 및 NFR이 누락된다. 결과: 아키텍처 재작업 및 출시 지연. 예방 방법: 체크리스트, 「만약…이라면?」 브레인스토밍, 테스터의 조기 참여, 비즈니스 목표에 대한 추적 가능성.[1][69]
  • 불명확하고 모호한 표현. 결과: 개발자가 「엉뚱한 것」을 구현하고 고객이 불만족한다. 예방 방법: 측정 가능한 기준, 용어집, 「A, B일 때, C인 경우」 템플릿, 동료 검토.[3][69]
  • 모순된 요구사항. 결과: 명확화 지연, 통합 시 재작업. 예방 방법: 구조화, 비즈니스 규칙/규제 대조, 갈등 해결 세션, 검토 시 일관성 확인.[3][1]
  • 「금도금」 증후군(gold-plating). 결과: 범위 증가, 복잡성 증가, 새로운 장애 지점. 예방 방법: 각 요구사항을 목표/메트릭에 연결; Agile에서는 불필요한 것을 백로그에 포함하지 않음; 범위 고정; YAGNI 참조.
  • 불필요한 곳에서의 과도한 세부화. 예방 방법: 무엇/왜(요구사항)와 어떻게(설계/구현)를 분리; 적절한 경우 design-free requirements 적용.[3]
  • 요구사항 관리 가능성 위반. 결과: 버전 혼란, 「엉뚱한 것」 구현. 예방 방법: ALM의 단일 진실 공급원, 이력 관리 및 상태, RTM과 변경 영향 분석; CCB를 통한 변경 관리.[64][1]
  • 사용자 참여 부재. 예방 방법: 인터뷰, 관찰, 프로토타입, 정기적 시연; 이해관계자와의 명시적 검증.[3][1]
  • 지나치게 긴 「분석 마비」. 예방 방법: 충분성의 영역 설정, 반복성 및 timeboxing; MVP/증분 출시와 피드백에 따른 조정.[1]
  • 비기능적 요구사항 무시. 예방 방법: NFR 분리(예: FURPS+), 측정 가능한 기준 설정, 테스트 계획 및 아키텍처 결정에 포함.[1][3]
  • 커뮤니케이션 오류 및 「인적 요소」. 해결 방법: 인터뷰 및 퍼실리테이션 역량 개발, 중립성 유지, 결정 사항 및 요구사항 출처 기록(목표에 대한 추적 가능성).[1]

대부분의 문제는 표현의 품질, 완전성 및 요구사항 관리 가능성으로 귀결된다. ISO/IEC/IEEE 29148 표준과 SWEBOK 실무(검증 가능성, 추적 가능성, 반복성)의 적용은 일정 지연 및 재작업의 위험을 크게 줄인다.[3][1]

한계

불확실성 감소에 효과적임에도 불구하고, 시스템 분석에는 고유한 한계가 있다:

  • 현실은 변화하고 복잡하다. 특히 장기 프로젝트에서는 모든 요소를 고려하는 것이 불가능하다. 일부 요구사항은 시스템 출시 이후에 불가피하게 나타난다. 놀라움을 최소화하려는 노력이 중요하지만, 변화에 대비해야 한다.
  • 요구사항은 사람에 의존한다. 비즈니스 우선순위, 법률, 시장이 변할 수 있다. 시스템 분석은 현재 상태를 고정하며 모든 외부 변화를 예측할 수 없다. 적응하려면 요구사항을 정기적으로 업데이트하고 반복적으로 작업해야 한다.
  • 사용자는 보기 전까지 원하는 것을 모를 때가 있다. 이는 잘 알려진 한계이다. 프로토타이핑과 Agile 같은 애자일 방법론이 이 문제를 극복하는 데 도움이 된다. 종이 위의 분석은 한계가 있으며, 정확한 데이터를 얻으려면 구현으로부터의 피드백이 필요하다.
  • 시간과 품질 간의 균형. 지나치게 상세한 분석은 시대에 뒤떨어질 수 있다. 혁신적인 분야에서는 최소 기능 제품(MVP)을 빠르게 만들고 실제 데이터를 얻는 것이 낫다. 시스템 분석은 안정적인 분야에서 효과적이지만, R&D 프로젝트에서는 그 역할이 제한된다.
  • 인적 요소. 최고의 방법론도 분석가의 비전문성이나 고객의 부재를 보완할 수는 없다. 프로세스의 모든 참여자가 참여하고 동기부여되는 것이 중요하다.

IT 시스템 분석에 대한 현대 기술의 영향

IT에서의 시스템 분석은 기술 혁신의 영향으로 지속적으로 진화한다. 21세기의 분석가는 폭발적인 데이터 증가, 보편적인 AI 도입, 빠른 개발 주기, 보안에 대한 높은 관심 속에서 작업한다. 성공적인 시스템 분석 실무는 새로운 지식(Data Science, 사이버 보안, 클라우드 기술)의 습득과 방법 적용의 유연성을 요구한다.

  • 데이터와 AI/ML: 분석에 추가되는 사항. AI를 포함한 시스템의 경우 초기부터 적용 목표와 맥락, 데이터 소스 및 품질에 대한 요구사항, 모델 결정에 대한 신뢰 메트릭(신뢰성, 보안, 설명 가능성, 프라이버시, 공정성)을 확정한다. TEVV(testing, evaluation, verification, validation) 검사, 운영 중 모니터링, 안전한 모델 종료/폐기 계획이 수립된다. 이 단계들은 NIST AI 위험 관리 프레임워크의 GOVERN–MAP–MEASURE–MANAGE 기능에 해당하며, SRS, 아키텍처, 검증/운영 계획에 반영된다.[70]
  • DevSecOps: 「좌측」 및 기본 보안. CI/CD의 모든 단계에 보안을 내재화하는 것이 표준이 되고 있다: 자동화된 검사(SAST/DAST), 의존성 및 컨테이너 스캐닝, 배포 정책, 기본 관찰 가능성. 신뢰할 수 있는 아티팩트 레지스트리와 표준화된 「강화된」 이미지가 사용되며, 제로 트러스트 원칙이 적용된다. 시스템 분석에서는 사전에 파이프라인의 통제 지점(단계 통과 조건), 요구사항과 보안 통제의 연결, 환경 간 전환 규칙(dev/test/stage/prod)을 기술한다.[71]
  • 문서(산출물)의 변화. Big Data 및 AI/ML 존재 시와 DevSecOps 적용 시 핵심 문서에서 추가되거나 구체화되는 섹션:
    • SRS / 요구사항 명세: AI 적용 목표 및 맥락; 데이터 요구사항(출처, 품질, 윤리적 및 법적 제약); 모델 메트릭(정확도, 신뢰성, 응답 시간); TEVV 계획(testing, evaluation, verification, validation); 투명성/설명 가능성 및 프라이버시 요구사항; 모델 종료/폐기 기준.[70]
    • 아키텍처 및 결정(Architecture, ADR): 위협 모델링 결과; 「기본 보안」 조치(암호화, 접근 제어, 시크릿 관리, 최소 권한 원칙); 데이터/모델 사용 제약; 위험 및 트레이드오프 평가가 포함된 ADR 기록.[71][70]
    • 검증 및 유효성 확인 계획(V&V / TEVV): 모델 및 데이터 테스트 시나리오; 품질 메트릭 인수 임계값; 데이터/모델 드리프트 모니터링; 주기적 재평가 및 재검증 절차.[70]
    • CI/CD 정책 및 파이프라인 「게이트」: 자동화된 SAST/DAST, SCA(의존성), 컨테이너 스캐닝; 신뢰할 수 있는 레지스트리에서의 아티팩트 서명 및 저장; 환경 간 승격 규칙(dev/test/stage/prod)과 검사 실패 시 빌드 차단 조건; 기본 관찰 가능성 요구사항.[71]
    • 데이터 및 모델 관리 계획: 소스 카탈로그 및 lineage; 데이터 품질 및 가용성 기준; 데이터셋/모델 버전; (재)학습 일정 및 bias 통제; 접근 및 보존 정책; 필요한 경우 모델의 안전한 비활성화 및 데이터 삭제 계획.[70]
    • 운영 및 관찰 가능성(Ops/Runbook): AI 신뢰 메트릭 및 SLO; 감사 및 로깅; 성능 저하/이상 알럿; 인시던트 대응 계획; AI 컴포넌트를 위한 fallback/kill-switch; 보고 및 사후 인시던트 분석 요구사항.[70][71]
    • 추적 가능성 (end-to-end): 전체 생명주기에 걸쳐 보안과 품질을 증명 가능하게 검증할 수 있도록 「요구사항 ↔ 파이프라인의 통제/검사」와 「요구사항 ↔ 운영 중 테스트/모니터링」 간의 명시적 연결.[71][70]
  • 시스템 분석가의 역할.
    • AI의 맥락과 위험 관리(행위자, 적용 시나리오, 데이터 가정 및 제약);
    • 「요구사항 ↔ 파이프라인의 보안 통제」 추적 가능성 확보;
    • 시스템 전체 생명주기에 걸쳐 검증 가능한 비기능적 요구사항(보안, 투명성, 관찰 가능성) 수립.[70][71]

고전적 시스템 분석과의 차이점

「시스템 분석」이라는 용어는 역사적으로 소프트웨어 개발보다 광범위하다. 고전적 시스템 분석은 시스템 사고와 정량적 방법에 기반한 복잡한 학제간 문제(사회적, 경제적, 경영적) 해결 접근 방식으로, 주로 경영 의사결정 지원을 위해 사용된다. IT에서의 시스템 분석은 정보 시스템 구축에 초점을 맞춘 소프트웨어 공학 내의 응용 분야로 이해된다.

아래는 핵심 차이점이다.

  • 목표와 분석 대상. 고전적 분석은 잘 구조화되지 않은 「흐릿한」 문제를 해결하고 기존의 사회기술 시스템(도시 교통망, 기업 전략, 환경 정책)을 개선한다. 대상은 실제 시스템이며, 과제는 의사결정자가 행동 방침을 선택하도록 돕는 것이다. IT에서의 시스템 분석의 목표는 요구사항을 충족하는 새로운 정보 시스템이나 소프트웨어 제품을 설계하고 구축하는 것이다. 대상은 설계 중인 시스템이며, 초점은 사용자에게 필요한 동작과 특성이다.
  • 방법론적 기반. 고전적 학파는 시스템 사고와 종종 수학에 의존한다. 딱딱한 접근 방식(hard systems)은 문제 공식화, 정량적 기준, 최적화(operations research에서처럼)이다. 부드러운 방법론(soft systems)은 관점의 다양성을 인정한다. 예를 들어 Soft Systems Methodology(SSM)에서는 토론과 개념적 모델을 통해 원하는 변화에 합의한다. IT에서의 기반은 공학적 분야: 요구사항 엔지니어링, 소프트웨어 설계, 아키텍처 프레임워크이다. 표준화된 프로세스(ISO/IEC/IEEE 15288, 12207, 29148), UML/SysML 표기법, 변경 관리 실무가 적용된다.
  • 역할과 산출물. 고전적 분석에서 「시스템 분석가」의 역할은 종종 비공식적이며, 결과물은 분석 보고서, 권고사항, 수학적 모델, 「만약…이라면?」 시나리오이다. IT에서 분석가(또는 비즈니스 분석가)의 역할은 공식화되어 있으며, 개발자와 테스터가 직접 활용하는 요구사항 명세, 시스템 모델(UML, ER), 인터페이스 명세, user story 및 백로그가 산출된다.
  • 생명주기와 프로세스. 고전적 분석에는 단일한 템플릿이 없다: 단계는 문제에 따라 다르다(SSM에서는 상황 탐구에서 변화 구현까지). IT에서는 표준 SDLC 주기가 채택된다: 폭포수 모델에는 별도의 요구사항 분석 단계가 있으며, 반복적이고 애자일한 접근 방식에서는 분석이 각 스프린트의 상시 활동이다. 현대적 실무(DevOps, CI/CD)는 분석의 범위를 운영까지 확장한다: 유지보수성, 관찰 가능성, 업데이트 가능성에 대한 요구사항이 고려된다. 즉, IT에서의 시스템 분석은 개발 생명주기에 내재되어 있는 반면, 고전적 분석은 대개 프로젝트/컨설팅 활동으로 수행된다.

시스템 분석가

IT 시스템 분석가는 정보 시스템의 설계 및 개발에서 시스템 사고를 담당하는 전문가이다: 요구사항 수립 및 검증, 모델링(UML/BPMN), 아키텍처 결정 합의, 통합 보장. 러시아 연방에서 역할과 자격 요건은 직업 표준 및 연방 교육 표준에 명시되어 있다.

직업 활동의 주요 목적: 전체 생명주기에 걸쳐 개별 수행자의 작업 시작 및 조율을 통해 이해관계자에게 양질의 상호 연계된 설계 결정을 개발하고 전달함으로써 IT 서비스, 자동화 시스템, 자동화 정보 시스템, 자동화 관리 시스템, 소프트웨어·정보 제품 또는 수단(이하 - 시스템)이 환경, 초기 요구사항 및 제약, 자동화 목표와 자동화 활동에 부합하도록 보장하는 것 (직업 표준 「시스템 분석가」(러시아 연방 노동부 명령 2023년 4월 27일 제367н호).[72]

핵심 용어 용어집

기본 개념 및 참여자

  • IT에서의 시스템 분석 — 구상에서 운영에 이르기까지 전체 생명주기에 걸친 정보 시스템을 연구 대상으로 하는 분야.
  • 이해관계자 — 프로젝트에 이해관계가 있거나 영향을 받는 개인 또는 그룹(고객, 사용자, 관리자).
  • 프로젝트 산출물 — 명세, 모델, 계획, 결정 등 프로젝트 과정에서 생성되는 문서와 결과물.

요구사항: 유형 및 문서화

  • 기능적 요구사항 — 시스템이 무엇을 해야 하는지, 즉 기능과 동작을 기술한다.
  • 비기능적 요구사항 — 시스템의 품질 속성(신뢰성, 성능, 보안, 사용 편의성, 확장성 등)을 기술한다.
  • 요구사항 명세(초기) — 프로젝트 초기 단계에서 수집된 초기 요구사항 집합을 담은 문서.
  • SRS (Software Requirements Specification) — 국제 표준(예: ISO/IEC/IEEE 29148)에 따라 소프트웨어 요구사항을 상세히 기술하는 표준화된 문서.
  • URS (User Requirements Specification) — 비즈니스 프로세스 및 최종 사용자의 기대 관점에서 사용자의 시스템 요구사항을 기술하는 문서.
  • 아키텍처적으로 중요한 요구사항(ASR) — 아키텍처 결정과 트레이드오프에 실질적인 영향을 미치는 요구사항.
  • 교차 기능 요구사항(CFR) — 비기능적 요구사항의 동의어로, 그 횡단적 성격을 강조한다.
  • 인수 기준(Acceptance Criteria) — 요구사항에 대한 작업이 인수된 것으로 간주되는 검증 가능한 조건.
  • Definition of Ready (DoR) — 백로그 항목이 개발 준비가 되었다는 합의(명확성, 추정, 기준).
  • Definition of Done (DoD) — 작업 「완료」에 대한 합의(코드, 테스트, 문서, 배포).
  • 제약(Constraint) — 솔루션을 제한하는 엄격한 조건(기한, 플랫폼, 표준, 라이선스).
  • 가정(Assumption) — 증명 없이 수용되며 이후 검증이 필요한 전제.
  • 요구사항 품질 — ISO 29148에 따른 속성: 명확성, 완전성, 일관성, 검증 가능성, 원자성.

요구사항의 공식화, 추적 가능성 및 우선순위 지정

  • 요구사항 공식화 — 비공식적 요청을 명확하고 검증 가능하며 모호하지 않은 요구사항으로 변환하는 과정.
  • 요구사항 추적 가능성 — 요구사항의 출처에서 구현, 테스트, 배포에 이르기까지 생명주기를 추적하는 능력.
  • 양방향 추적 가능성(Bidirectional traceability) — 요구사항, 설계 요소, 테스트 시나리오 간의 연결을 순방향 및 역방향 모두로 추적하는 능력.
  • MoSCoW — 요구사항을 Must-have(필수), Should-have(필요), Could-have(있으면 좋음), Won't-have(불필요)로 분류하는 우선순위 지정 기법.
  • BDD (Behavior-Driven Development) — 사용자 관점에서 시스템의 동작에 초점을 맞춘 자연어(Given–When–Then 형식)로 테스트를 작성하는 개발 방법론.

표기법 및 모델링

  • UML (Unified Modeling Language) — 소프트웨어 시스템 컴포넌트의 명세, 시각화, 구성 및 문서화를 위한 표준화된 그래픽 모델링 언어.
  • SysML (Systems Modeling Language) — 요구사항, 동작, 구조, 파라미터 등 복잡한 시스템의 다양한 측면 모델링을 지원하는 시스템 엔지니어링을 위한 UML 확장.
  • BPMN (Business Process Model and Notation) — 작업 흐름, 이벤트, 게이트웨이, 풀을 시각화하는 비즈니스 프로세스 기술을 위한 그래픽 표기법 표준.
  • MBSE (Model-Based Systems Engineering) — 요구사항에서 테스트에 이르기까지 시스템 생명주기의 모든 단계에서 모델이 중심 산출물인 시스템 엔지니어링 접근 방식.
  • ArchiMate — 엔터프라이즈 아키텍처(비즈니스, 애플리케이션, 기술) 및 그 연결에 대한 표기법.
  • DMN (Decision Model and Notation) — 비즈니스 결정 및 규칙 테이블 모델링.
  • DFD (Data Flow Diagram) — 데이터 흐름 다이어그램(맥락, 분해 수준).
  • ERD (Entity-Relationship Diagram) — 엔티티, 관계, 속성을 포함한 도메인 모델.
  • CRUD 매트릭스 — Create/Read/Update/Delete 작업과 엔티티 및 역할/기능 간의 대응 관계.

아키텍처 스타일 및 솔루션 평가

  • 모놀리식 아키텍처 — 전체 시스템이 하나의 분리 불가능한 모듈로 개발되는 아키텍처 접근 방식.
  • 마이크로서비스 아키텍처 — 시스템이 독립적으로 배포 및 확장 가능한 소규모 서비스의 집합으로 구축되는 아키텍처 접근 방식.
  • 트레이드오프(Trade-off) — 상호 배타적이거나 상충하는 특성이나 결정 간의 선택으로, 하나의 특성 개선이 다른 특성의 저하를 가져온다.
  • ATAM (Architecture Tradeoff Analysis Method) — 품질 속성(예: 성능, 확장성) 간의 트레이드오프를 분석하는 데 사용되는 소프트웨어 아키텍처 평가 방법.

엔터프라이즈 아키텍처 및 프레임워크

  • TOGAF (The Open Group Architecture Framework) — 아키텍처 개발 및 관리를 위한 ADM(Architecture Development Method)을 포함하는 가장 널리 사용되는 엔터프라이즈 아키텍처 프레임워크 중 하나.
  • Zachman Framework — 다양한 관점에서 아키텍처의 여러 측면을 분류하는 6×6 매트릭스로 표현된 엔터프라이즈 아키텍처 산출물 온톨로지.

분석 및 개발 프로세스 접근 방식

  • 딱딱한 접근 방식(Hard Systems) — 사전에 공식화 가능한 목표와 요구사항, 분해 및 「하향식」 설계를 전제로 하는 시스템 분석 방법론. 명확히 정의된 문제에 효과적이다.
  • 부드러운 접근 방식(Soft Systems) — 목표가 불명확하고 이해관계자의 관점이 다양할 때 적용되는 시스템 분석 방법론. 문제 이해와 원하는 변화의 합의에 초점을 맞춘다.
  • SSM (Soft Systems Methodology) — rich picture, 근본 정의, CATWOE 등의 도구를 사용하는, 피터 체클랜드가 개발한 구체적인 소프트 시스템 접근 방법론.
  • 폭포수(Waterfall, 카스케이드 모델) — 단계(분석, 설계, 구현, 테스트, 도입)가 순차적으로, 이전 단계가 완전히 완료된 후 다음 단계가 시작되는 고전적 소프트웨어 개발 방법론.
  • Agile — 반복적 개발, 변화 적응, 고객과의 상호작용, 지속적인 가치 제공에 초점을 맞춘 소프트웨어 개발 애자일 방법론 그룹.

선택 방법 및 일반적인 오류

  • AHP (Analytic Hierarchy Process) — 기준의 계층 구조를 기반으로 복잡한 문제를 구조화하고 대안을 평가하는 다기준 선택 방법.
  • 금도금(Gold-plating) — 이해관계자가 요구하지 않는 기능을 추가하는 시스템 분석의 오류로, 프로젝트 범위와 복잡성의 증가로 이어진다.

링크

  • 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
  • 시스템 분석 쉽게 이해하기. YouTube
  • IT에서의 시스템 분석 쉽게 이해하기. YouTube

문헌

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 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. 공식 무료 버전.
  • 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. 공식 무료 다운로드(라이선스 기준).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4판.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3판.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2판.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (개정판).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5판.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 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, 4판.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11판.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8판.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7판.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3판.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2판.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 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, 4판.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (개정판).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2판.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

주석

  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.info/int/index.php?title=Systems_analysis_in_IT_—_IT_분야_시스템_분석&oldid=7614"