PMDEXIT 프로젝트 용어사전

STANDARD · IEEE

IEEE

Institute of Electrical and Electronics Engineers

세계 최대 기술 전문 단체. 통합/분리 발주, 요구사항·검수 기준의 표준 근거를 제공한다.

분석·설계 · 요구사항

검증(Validation)

Validation

"제대로 된 것을 만들고 있는가"를 고객이 확인하는 활동. 요구사항의 1.0 확정.

Validation은 고객이 확인하는 ‘제대로 된 것인가’, Verification은 엔지니어가 검토하는 ‘제대로 만들었는가’이다. 명세 0.9는 고객 확인을 거쳐야 1.0이 되며, 이 구분이 검수 분쟁을 예방한다.

분석·설계 · 요구사항

확인(Verification)

Verification

"제대로 만들고 있는가"를 엔지니어가 설계 명세로 검토하는 것.

확인은 "명세대로 만들고 있는가"를 엔지니어가 설계 문서로 대조하는 활동이고, 검증은 "옳은 것을 만들고 있는가"를 사용자 요구로 따지는 활동이다. 명세대로 정확히 구현해 확인을 통과해도 명세 자체가 요구와 어긋나면 검증에서 실패하므로, 두 활동을 구분하지 못하면 명세 결함과 구현 결함의 책임 소재가 흐려진다.

분석·설계 · 요구사항

요구사항 명세서

Requirement Specification (SRS) · SRS

요구를 추적 가능하게 기록한 문서. 요구 ID·유형·출처·우선순위·이력이 필수.

요구사항 명세서의 품질은 문장을 얼마나 많이 적었느냐가 아니라, 각 요구가 ID·유형·출처·우선순위·이력을 갖춰 추적 가능하고 검증 가능한 항목으로 적혔느냐에 달려 있다. 측정 불가능한 모호한 문장과 추적 속성 없는 요구 목록은 검증 단계에서 합격 판정을 흐리고 변경의 파급 범위를 가늠하지 못하게 만든다.

분석·설계 · 모델링

UseCase 모델

Use Case Model

개발 범위를 다이어그램으로 표현한 모델. 요구사항 정의서와 짝을 이룬다.

유스케이스 모델은 그림 자체가 목적이 아니라, 시스템 경계 밖과 안을 갈라 개발 범위를 발주사와 합의하는 계약적 도구다. 다이어그램에 없는 기능은 이번 범위가 아니라는 합의를 만들고, 세부 흐름은 요구사항 명세서에 위임해 추적성을 맞춰야 분석 산출물로서 제 역할을 한다.

분석·설계 · 비교

Validation vs Verification

Validation vs Verification

고객이 확인하는 Validation, 엔지니어가 검토하는 Verification. 검수 분쟁의 핵심 구분.

Verification은 명세대로 만들었는지를 엔지니어가 검토하고, Validation은 실제 요구를 충족하는지를 고객이 확인한다. 검수 분쟁의 대부분은 이 둘의 혼동에서 비롯되므로, 요구사항마다 측정 가능한 수용 기준을 명세서에 미리 박아 두는 것이 가장 확실한 예방책이다.

분석·설계 · 모델링

UML

Unified Modeling Language · UML

객체지향 분석·설계를 표준 다이어그램으로 표현하는 통합 모델링 언어.

UML은 모든 다이어그램을 다 그릴 때가 아니라 핵심 협력 구조와 위험한 흐름만 골라 그릴 때 가장 유용하다. 완벽한 모델링에 일정을 쓰기보다, 유스케이스·클래스·시퀀스의 추적 관계를 유지해 변경의 파급 범위를 읽어내는 기준선으로 삼는 편이 현장에서 더 큰 가치를 낸다.

분석·설계 · 모델링

클래스 다이어그램

Class Diagram

클래스의 속성·행위·관계를 표현하는 정적 구조 다이어그램.

클래스 다이어그램은 관계선이 한 클래스에 몰리는지, 다중도가 명확한지를 보는 결합도·응집도 진단 도구로 쓸 때 가치가 가장 크다. 시퀀스 다이어그램의 메시지와 클래스의 행위가 일대일로 대응되는지 교차 점검하면 설계의 빈틈을 코드 작성 전에 잡아낼 수 있다.

분석·설계 · 모델링

시퀀스 다이어그램

Sequence Diagram

객체 간 메시지 흐름을 시간순으로 표현하는 동적 다이어그램.

시퀀스 다이어그램은 메시지 왕복이 길어지거나 한 객체로 호출이 몰리는 지점을 통해 병목과 책임 편중을 코드 작성 전에 드러낸다. 모든 유스케이스를 다 그리기보다 협력 구조가 복잡하고 위험이 큰 핵심 흐름만 선별해 그리고, 그 메시지를 클래스 행위와 대조하는 활용이 현장에서 가장 효율적이다.

분석·설계 · 모델링

상태 다이어그램

State Diagram

객체의 상태 변화와 전이 조건을 표현하는 행위 다이어그램.

상태 다이어그램의 진짜 가치는 그림 자체가 아니라 빠진 경우의 수를 강제로 드러낸다는 데 있다. 전이마다 가드 조건을 명시하고 처리되지 않은 사건이 없는지 끝까지 확인하면, 운영 중에 터지는 예외 상태의 상당수를 설계 단계에서 미리 막을 수 있다.

분석·설계 · 모델링

활동 다이어그램

Activity Diagram

업무·처리 흐름을 절차적으로 표현하는 행위 다이어그램.

활동 다이어그램의 실무 가치는 업무가 주체에서 주체로 넘어가는 인계 지점을 드러낸다는 데 있다. 스윔레인으로 책임을 갈라 두면 지연과 누락이 잦은 경계가 눈에 보이고, 정상 흐름뿐 아니라 예외 경로까지 함께 그려야 설계 단계에서 오류 처리 누락을 미리 막을 수 있다.

테스트 · 품질

인수 테스트

Acceptance Test

고객 기준으로 합격 여부를 판정하는 최종 테스트. 검수의 근거.

인수 테스트의 승부는 수행 단계가 아니라 합격 기준을 글로 못 박는 요구사항 단계에서 갈린다. 기준이 모호하면 검수 회의는 결함 판정이 아니라 범위 논쟁으로 변질되며, 초과 요건은 잔여 결함과 분리해 운영 단계 개선 개발로 이관하는 것이 정석이다.