LIFECYCLE · 03 / 06
분석·설계
요구사항을 식별·분석·명세하고 아키텍처를 설계한다. 실패의 50%가 여기 요구사항에서 갈린다.
요구사항 식별
요구의 원천 데이터를 폭넓게 끌어내는 첫 단계. 정제는 다음 단계의 몫.
요구사항은 출처와 함께 기록해야 누락·중복·상충을 역추적할 수 있다. 식별 단계에서는 거르기보다 폭넓게 끌어내고, 정제는 분석 단계의 몫으로 분리하는 것이 원칙이다.
분석·설계 · 요구사항검증(Validation)
"제대로 된 것을 만들고 있는가"를 고객이 확인하는 활동. 요구사항의 1.0 확정.
Validation은 고객이 확인하는 ‘제대로 된 것인가’, Verification은 엔지니어가 검토하는 ‘제대로 만들었는가’이다. 명세 0.9는 고객 확인을 거쳐야 1.0이 되며, 이 구분이 검수 분쟁을 예방한다.
분석·설계 · 관리변경관리
실현 가능한 계획 안에서 변경을 통제하는 PM의 핵심 역량. CCB가 의사결정.
변경관리는 변화를 막는 일이 아니라 실현 가능한 계획 안에서 통제하는 일이다. 수용 여부는 CCB 절차로 기록하고, 감당 범위를 넘는 요건은 운영 단계 개발로 이관한다.
분석·설계 · 관리Risk(위험)
아직 발생하지 않았으나 프로젝트 성공에 영향을 줄 수 있는 잠재적 위험.
Risk는 아직 오지 않은 예견, Issue는 이미 발생한 문제다. 이미 발생한 것부터 처리해야 하므로 우선순위에서는 Issue가 앞선다. 둘을 같은 무게로 다루면 대응이 무너진다.
분석·설계 · 요구사항요구사항 분석
수집한 요구의 누락·중복·상충을 정리하고 실현가능성을 가린다.
요구사항 분석의 핵심은 요구를 더 모으는 것이 아니라 모인 요구의 충돌과 실현 불가능을 이해관계자 앞에서 먼저 드러내는 데 있다. 상충과 비기능 조건을 분석 단계에서 표면화하지 못한 요구는 반드시 개발 후반의 재작업으로 되돌아오며, 그때의 비용은 분석 단계에서 조정했을 때와 비교할 수 없이 커진다.
분석·설계 · 요구사항확인(Verification)
"제대로 만들고 있는가"를 엔지니어가 설계 명세로 검토하는 것.
확인은 "명세대로 만들고 있는가"를 엔지니어가 설계 문서로 대조하는 활동이고, 검증은 "옳은 것을 만들고 있는가"를 사용자 요구로 따지는 활동이다. 명세대로 정확히 구현해 확인을 통과해도 명세 자체가 요구와 어긋나면 검증에서 실패하므로, 두 활동을 구분하지 못하면 명세 결함과 구현 결함의 책임 소재가 흐려진다.
분석·설계 · 요구사항요구사항 명세서
요구를 추적 가능하게 기록한 문서. 요구 ID·유형·출처·우선순위·이력이 필수.
요구사항 명세서의 품질은 문장을 얼마나 많이 적었느냐가 아니라, 각 요구가 ID·유형·출처·우선순위·이력을 갖춰 추적 가능하고 검증 가능한 항목으로 적혔느냐에 달려 있다. 측정 불가능한 모호한 문장과 추적 속성 없는 요구 목록은 검증 단계에서 합격 판정을 흐리고 변경의 파급 범위를 가늠하지 못하게 만든다.
분석·설계 · 요구사항비기능 요구사항
기능 외의 품질 요구 · 성능·보안·사용성·신뢰성·유지보수성·이식성.
비기능 요구사항의 성패는 정량화 여부에서 갈린다. 빠르게·안전하게 같은 형용사를 응답 시간·가용성 비율·동시 처리량처럼 측정 가능한 지표로 못 박아야 검수의 기준이 되고, 정량화되지 않은 항목은 인수 단계에서 반드시 분쟁으로 돌아온다.
분석·설계 · 요구사항FURPS
비기능 점검 약어 · Functional·Usability·Reliability·Performance·Supportability(+).
FURPS는 요구사항을 다섯 관점으로 펼쳐 누락을 막는 출발선일 뿐, 목표값을 대신 정해 주지 않는다. 약어로 항목을 끌어낸 다음에는 반드시 각 항목을 측정 가능한 지표로 환산하고 상충을 조정해야, 점검표가 검증 가능한 명세로 바뀐다.
분석·설계 · 요구사항Trade-Off
하나를 높이면 다른 하나가 낮아지는 상충. 성능과 보안이 대표.
트레이드오프에서 진짜 위험은 상충 자체가 아니라, 그것을 인식하지 못한 채 현장에서 임의로 절충되는 것이다. 무엇을 우선하고 무엇을 양보했는지 비즈니스 우선순위에 근거해 결정하고 그 기준을 기록해 두어야, 이후 변경관리에서 결정을 흔들어도 되는지 판단할 근거가 남는다.
분석·설계 · 관리Issue(이슈)
이미 발생한 문제. 예견인 Risk보다 시급하게 다뤄야 한다.
위험은 미래의 가능성이고 이슈는 이미 닥친 현실이므로, 둘을 한 대장에 섞어 관리하면 정작 급한 사안이 뒤로 밀린다. 발생한 이슈에는 반드시 담당자와 마감일을 붙이고, 범위·일정에 영향을 주는 해결은 임의로 봉합하지 말고 변경관리 절차로 합의한 뒤 반영하는 것이 정석이다.
분석·설계 · 모델링UseCase 모델
개발 범위를 다이어그램으로 표현한 모델. 요구사항 정의서와 짝을 이룬다.
유스케이스 모델은 그림 자체가 목적이 아니라, 시스템 경계 밖과 안을 갈라 개발 범위를 발주사와 합의하는 계약적 도구다. 다이어그램에 없는 기능은 이번 범위가 아니라는 합의를 만들고, 세부 흐름은 요구사항 명세서에 위임해 추적성을 맞춰야 분석 산출물로서 제 역할을 한다.
분석·설계 · 요구사항Baseline
합의로 고정된 기준선. 수행사 기준선은 고객 확인 전에는 무효.
기준선은 수행사가 작성했다고 성립하는 것이 아니라, 고객의 확인과 합의를 거쳐야 비로소 효력을 갖는다. 확인 전의 기준선은 내부 참고치일 뿐이며, 변경이 필요하면 임의 수정이 아니라 영향도 분석과 승인을 거친 통제된 절차로만 새 기준선을 세워야 검증과 검수의 기준이 흔들리지 않는다.
분석·설계 · 모델링OO 모델링
현실의 사물·개념을 객체로 인식해 시스템을 분석·설계하는 방법론.
객체 분해의 성패는 클래스를 몇 개로 쪼갰느냐가 아니라, 변경 요청이 들어왔을 때 영향 범위가 한 객체 안에서 끝나느냐로 판가름난다. 도메인 용어와 객체 이름을 일치시켜 두면 현업·분석가·개발자가 같은 언어로 모델을 검증하게 되어, 설계 오류가 코드로 굳기 전에 드러난다.
분석·설계 · 표준SWEBOK
소프트웨어 공학의 경험 지식 체계. 요구사항·테스트의 기준 근거.
SWEBOK은 절차서가 아니라 무엇을 빠짐없이 다루어야 하는지 알려 주는 분야의 지도다. 통독 대상이 아니라 요구사항·테스트가 합의 근거를 거슬러 올라가는지 점검하는 기준의 출처로 쓸 때 가장 유용하다. 관리 체계인 PMBOK과 짝을 이뤄야 관리와 공학이 한 프로젝트 위에서 맞물린다.
분석·설계 · 표준ISO/IEC 25010
소프트웨어 품질 모델 표준. 비기능 요구의 누락을 막는 체크리스트.
ISO/IEC 25010은 모든 특성을 채우는 양식이 아니라, 비기능 요구가 빠지지 않았는지 묻게 하는 점검표다. 각 특성에 측정 가능한 목표를 붙여 인수 기준으로 바꿔 둘 때 운영 단계의 품질 분쟁이 줄어든다. 시스템 성격에 따라 결정적 특성을 가려 역량을 집중하는 안목이 핵심이다.
분석·설계 · 비교Risk vs Issue
아직 오지 않은 예견(Risk)과 이미 발생한 문제(Issue). 현장 우선순위는 Issue가 앞선다.
Risk는 발생 확률과 영향으로 다루고 Issue는 이미 발생했으니 복구 속도와 영향 최소화로 다룬다. 현장 자원은 늘 부족해 Issue가 먼저지만, Risk가 Issue로 전환되는 순간을 누가 책임지고 변경관리로 넘기느냐가 분쟁의 갈림길이다.
분석·설계 · 비교Validation vs Verification
고객이 확인하는 Validation, 엔지니어가 검토하는 Verification. 검수 분쟁의 핵심 구분.
Verification은 명세대로 만들었는지를 엔지니어가 검토하고, Validation은 실제 요구를 충족하는지를 고객이 확인한다. 검수 분쟁의 대부분은 이 둘의 혼동에서 비롯되므로, 요구사항마다 측정 가능한 수용 기준을 명세서에 미리 박아 두는 것이 가장 확실한 예방책이다.
분석·설계 · 비교Needs vs Requirements
잠재 요구(Needs)와 확정 요구(Requirements). 추가 요구는 대개 비기능에서 드러난다.
이해관계자의 말은 Needs일 뿐 Requirements가 아니다. 그 말 뒤의 의도를 검증 가능한 조건으로 다듬는 것이 분석의 본질이며, 명세에서 빠지기 쉬운 성능·보안·가용성 같은 비기능 Needs를 초기에 수치로 합의해 두는 것이 검수 분쟁을 막는 가장 확실한 장치다.
분석·설계 · 비교기능 vs 비기능
동작을 정의하는 기능과 품질을 정의하는 비기능. 검수 분쟁은 대개 비기능에서 난다.
기능은 되느냐 안 되느냐로 판정되지만 비기능은 측정 기준이 없으면 영원히 합의되지 않는다. 빠르게·안전하게 같은 막연한 표현을 응답 시간·동시 처리량·복구 시간 같은 수치로 못 박아 두는 것이, 검수 막바지에 쏟아지는 추가 요구와 분쟁을 막는 가장 확실한 방법이다.
분석·설계 · 모델링UML
객체지향 분석·설계를 표준 다이어그램으로 표현하는 통합 모델링 언어.
UML은 모든 다이어그램을 다 그릴 때가 아니라 핵심 협력 구조와 위험한 흐름만 골라 그릴 때 가장 유용하다. 완벽한 모델링에 일정을 쓰기보다, 유스케이스·클래스·시퀀스의 추적 관계를 유지해 변경의 파급 범위를 읽어내는 기준선으로 삼는 편이 현장에서 더 큰 가치를 낸다.
분석·설계 · 모델링클래스 다이어그램
클래스의 속성·행위·관계를 표현하는 정적 구조 다이어그램.
클래스 다이어그램은 관계선이 한 클래스에 몰리는지, 다중도가 명확한지를 보는 결합도·응집도 진단 도구로 쓸 때 가치가 가장 크다. 시퀀스 다이어그램의 메시지와 클래스의 행위가 일대일로 대응되는지 교차 점검하면 설계의 빈틈을 코드 작성 전에 잡아낼 수 있다.
분석·설계 · 모델링시퀀스 다이어그램
객체 간 메시지 흐름을 시간순으로 표현하는 동적 다이어그램.
시퀀스 다이어그램은 메시지 왕복이 길어지거나 한 객체로 호출이 몰리는 지점을 통해 병목과 책임 편중을 코드 작성 전에 드러낸다. 모든 유스케이스를 다 그리기보다 협력 구조가 복잡하고 위험이 큰 핵심 흐름만 선별해 그리고, 그 메시지를 클래스 행위와 대조하는 활용이 현장에서 가장 효율적이다.
분석·설계 · 모델링상태 다이어그램
객체의 상태 변화와 전이 조건을 표현하는 행위 다이어그램.
상태 다이어그램의 진짜 가치는 그림 자체가 아니라 빠진 경우의 수를 강제로 드러낸다는 데 있다. 전이마다 가드 조건을 명시하고 처리되지 않은 사건이 없는지 끝까지 확인하면, 운영 중에 터지는 예외 상태의 상당수를 설계 단계에서 미리 막을 수 있다.
분석·설계 · 모델링활동 다이어그램
업무·처리 흐름을 절차적으로 표현하는 행위 다이어그램.
활동 다이어그램의 실무 가치는 업무가 주체에서 주체로 넘어가는 인계 지점을 드러낸다는 데 있다. 스윔레인으로 책임을 갈라 두면 지연과 누락이 잦은 경계가 눈에 보이고, 정상 흐름뿐 아니라 예외 경로까지 함께 그려야 설계 단계에서 오류 처리 누락을 미리 막을 수 있다.
분석·설계 · 모델링개체관계도
데이터의 개체·속성·관계를 표현하는 데이터 모델링 다이어그램.
개체관계도의 품질은 개체와 속성을 제대로 구분했는지, 그리고 관계의 카디널리티를 모호함 없이 명시했는지에서 갈린다. 정규화는 무결성을 위한 기본이되 성능이 걸린 영역에서는 역정규화를 의식적으로 선택해야 하며, 모델을 코드 변경과 함께 계속 갱신해야 비로소 살아 있는 설계 자산이 된다.
분석·설계 · 모델링데이터 모델링
업무 데이터를 개념·논리·물리 모델로 구조화하는 활동.
데이터 모델은 화면이나 기능보다 먼저 확정되어야 하며, 한번 운영 데이터가 쌓인 뒤에는 구조를 바꾸는 비용이 급격히 커진다. 정규화 수준을 높이는 것 자체가 목적이 아니라, 무결성과 조회 성능 사이에서 업무 특성에 맞는 절충점을 잡아내는 판단이 모델링의 실력이다.
분석·설계 · 모델링정규화
데이터 중복과 이상현상을 제거해 무결성을 높이는 설계 기법.
정규화의 목표는 정규형 단계를 높이는 것 자체가 아니라 갱신 이상현상을 없애 한 값을 한 곳에서만 관리하는 데 있다. 실무에서는 조회 성능을 위해 반정규화로 일부 중복을 허용하되, 어디서 왜 허용했는지를 명시해 갱신 일관성을 코드가 책임지도록 설계하는 것이 정석이다.
분석·설계 · 요구사항프로토타이핑
시제품으로 요구를 조기 검증해 불확실성을 줄이는 기법.
프로토타입의 가치는 잘못된 가정을 코드에 박히기 전에 드러내 검증을 앞당기는 데 있으므로, 만들기 전에 무엇을 확인할 가설인지를 먼저 정해야 한다. 검증용으로 급조한 시제품을 품질 검토 없이 운영 시스템으로 승격시키지 않도록, 버릴 것인지 키울 것인지를 처음부터 합의해 두는 것이 기술 부채를 막는 핵심이다.
분석·설계 · 요구사항CRUD
데이터의 생성·조회·수정·삭제. 기능 정의와 권한 설계의 기본 축.
CRUD 점검에서 가장 자주 빠지는 칸은 삭제다. 삭제를 물리 삭제로 둘지 상태값 변경의 논리 삭제로 둘지를 설계 초기에 결정해 두지 않으면, 운영 단계에서 감사·복구·정합성 요구가 한꺼번에 터지며 뒤늦게 구조를 뜯어고치게 된다.
분석·설계 · 표준BABOK
비즈니스 분석 직무의 표준 지식 체계. 현업·업무 분석의 BOK.
BABOK은 처음부터 끝까지 따르는 매뉴얼이 아니라 요구사항의 빈틈을 비추는 점검 틀로 쓸 때 가장 값지다. 비즈니스 요구·이해관계자 요구·솔루션 요구를 층위로 분리하는 습관만 몸에 익혀도, 경영진의 목적과 실무자의 기능 요청이 뒤섞여 명세가 흔들리는 사고를 크게 줄일 수 있다.
분석·설계 · 표준SFIA
IT 직무 역량과 책임 수준을 정의·측정하는 글로벌 역량 체계.
SFIA는 등급표로 줄을 세우는 도구가 아니라 같은 일을 어느 책임 수준에서 감당하느냐를 분별하는 데 진짜 쓸모가 있다. 인력 산정 때 사람을 동일한 맨먼스 단위로 뭉뚱그리지 말고 책임 수준별로 나누어 추정하면, 핵심 과업에 적정 역량을 배치하는 판단과 단가 근거가 함께 또렷해진다.
분석·설계 · 표준CMMI
조직의 프로세스 성숙도를 5단계로 평가·개선하는 모델.
CMMI 등급은 수주 자격으로는 유효하지만, 등급을 목표로 삼는 순간 평가용 문서만 늘고 일하는 방식은 그대로인 경우가 많다. 절차의 존재가 아니라 그 절차가 재작업과 납기에 실제로 영향을 주는지를 기준으로 도입 성과를 점검해야 한다.
분석·설계 · 표준TOGAF
전사 아키텍처를 수립·관리하는 대표 아키텍처 프레임워크.
TOGAF의 산출물은 그 자체가 목적이 아니라 의사결정의 근거일 때만 가치가 있다. 현행·목표 상태의 차이 분석 없이 목표 모습만 그린 아키텍처는 화려해도 이행 단계에서 무력해지므로, 재단을 통해 실제로 참조되는 최소한의 산출물에 집중하는 편이 낫다.