Chapter01 소프트웨어 개발 방법론 (중요도: ★★★)
◆ 소프트웨어 생명주기 (SDLC): 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
[##_Image|kage@cbpMlq/btrBjIcuzAs/7GxVYJxtvizY3xdYSJXPr0/img.png|CDM|1.3|{"originWidth":683,"originHeight":153,"style":"alignCenter","caption":"(요분설개테유)"}_##]
◆ 소프트웨어 생명주기 모델 종류(폭프나반)
- 폭포수 모델(Waterfall Model): 가장 오래된 모델로, 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감
- 프로토타이핑 모델(Prototype Model, 원형 모형) : 주요기능을 프로토타입으로 구현해, 고객의 피드백을 반영하여 S/W 만듦,견본품(시제품)을 만들어 최종 형태를 예상함
- 나선형 모델(Spiral Model, 점진적 모형): 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형,위험을 최소화하기 위해 점진적으로 시스템 개발,(계위게고)계획 및 정의 / 위험 분석 / 개발 / 고객 평가
- 반복적 모델(Iteration Model): 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발
[##_Image|kage@urn9L/btrBnLMlNxL/uM3Lk6sU9gtuzbdKnjiW80/img.png|CDM|1.3|{"originWidth":900,"originHeight":139,"style":"alignCenter"}_##][##_Image|kage@8euaT/btrBmv4jdDR/l8GyvoUhfnsLN136myON5K/img.png|CDM|1.3|{"originWidth":688,"originHeight":547,"style":"alignCenter","width":353,"height":281}_##][##_Image|kage@bE85Zo/btrBjY6IHFq/nYDcUgLGcfgTdCkPWLYVy1/img.png|CDM|1.3|{"originWidth":900,"originHeight":300,"style":"alignCenter","caption":"나선형 모형"}_##][##_Image|kage@y4S0Z/btrBnLZTxiN/Z9xkeMTycAo9xpHaon1SpK/img.png|CDM|1.3|{"originWidth":758,"originHeight":304,"style":"alignCenter"}_##]
◆ 소프트웨어 개발 방법론: 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과장을 형상화한 방법론
◆ 소프트웨어 개발 방법론 종류(구정객컴 애제)
- 구조적 방법론(Structured Development): 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 방법론
- 나씨-슈나이더만 차트: 논리의 기술에 중점을 둔 도형식 표현방법
- 정보공학 방법론(Information Engineering Development): 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
- 객체 지향 방법론(Object-Oriented Development): ‘객체’라는 기본 단위로 시스템을 분석 및 설계하는 방법론
- 컴포넌트 기반 방법론 (CBD): 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
- 애자일 방법론(Agile Development): 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적인 시스템 개발할 수 있는 신속 적응적 개량 개발 방법론
- 제품 계열 방법론(Product Line Development): 특정 제품에 적용하고 싶은 공통괸 기능을 정의해 개발하는 방법론, 임베디드 S/W작성에 유용
◆ 애자일(Agile) 방법론 유형
[##_Image|kage@bYdIs6/btrBi7cxvS1/L7cDebHmde2vmaRu5KeeYk/img.png|CDM|1.3|{"originWidth":540,"originHeight":459,"style":"alignCenter"}_##]
XP(eXtreme Programming): 의사소통 개선과 즉각적 피드백으로 스프트웨어 품질을 높이기 위한 방법론
- XP 5가지 가치: 용기, 단순성, 의사소통, 피드백, 존중
- 스크럼(Scrum): 매일 정해진 시간, 장소에서 짤은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
- 린(Lean): 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 욧를 제거하여 품질을 향상시킨 방법론
- Lean 7가지 가치: 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화
◆ 객체 지향 분석(OOA): 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의
◆ 객체 지향 분석 방법론 종류
- OOSE(Object Oriented Software Engineering): 유스케이스를 모든 모델의 근간으로 활용되는 방법론, 야콥슨 만듦
- OMT(Object Modeling Technology): 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링, 럼바우 만듦
- 분석 절차: 객체 모델링 → 동적 모델링 → 기능 모델링
- 객체 모델링: 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링, 객체 다이어그램 활용
- 동적 모델링: 시간의 흐름에 따라 객체들의 동적인 행위를 표현하는 모델링, 상태 다이어그램 활용
- 기능 모델링: 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링, 자료 흐름도(DFD) 활용
◆ 비용산정 모형 분류
- 하향식 산정방법: 경험이 많은 전무가에게 비용산정 의뢰 또는 전무가와 조정자를 통해 비용산정
- 전문가 판단
- 델파이 기법: 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법
- 상향식 산정방법: 세부적인 요구사항과기능에 따라 필요한 비용 산정
- 코드 라인 수(LoC: Lines of Code): 원시 코드 라인수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구해 비용산정
- Man Month: 한 사람이 1개워 동안 할 수 있는 일의 양을 기준으로 비용산정
- COCOMO 모형: 보헴이 제안한 모형으로 프로그램의 규모에 따라 비용산정
- 조직형(Organic Mode): 5만(50KDSI)라인 이하
- 반 분리형(Semi-Detached Mode): 30만(300KDSI)라인 이하
- 임베디드형(Embedded Mode): 30만(300KDSI)라인 이상
- 푸트남(Putnam) 모형: 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
- 기능점수(FP) 모형: 소프트웨어 기능을 증대시키는 요인별로 가중치를 부여하여 비용산정
◆ 비용 산정 자동화 추정 도구
- SLIM: Rayleigh-Norden곡선과 Putnam예측 모델을 기초로 하여 개발된 자동화 추정 도구
- ESTIMACS: 다양한 프로젝트와 개인별 요소를 수용하도록 FP모형을 기초로 하여 개발된 자동화 추정 도구
◆ 일정관리 모델: 프로젝트가 일정 기한 내에 완료될 수 있도록 관리하는 모델
- 주 공정법(CPM): 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
- 주 공정(Critical Path: 임계 경로): 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로
- PERT: 일의 순서를 계획적으로 정리하기 위한 수렴기법. 비관치, 중간치, 낙관치 이용
- 중요 연쇄 프로젝트 관리(CCPM): 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법
Chapter02 현행 시스템 분석 (중요도: ★★★)
◆ 현행 시스템 파악: 현행시스템의 어떤 기술 요소 사용을 하는지 파악하는 활동
◆ 현행 시스템 파악 절차
- 구성/기능/인터페이스 파악 → 아키텍처 및 소프트웨어 구성 파악 → 하드웨어 및 네트워크 구성 파악
◆ 소프트웨어 아키텍처: 여러 가지 소프트웨어 구성요소과 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체
◆ 소프트웨어 아키텍처 4+1 뷰(유논프구배): 고객의 요규사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법
- 유스케이스 뷰(Usecase View): 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰
- 논리 뷰(Logical View): 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
- 프로세스 뷰(Process View): 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
- 구현 뷰(Implementation View): 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰, 컴포넌트 구조와 의존성을 보여주고 부가적인 정보 정의
- 배포 뷰(Deployment View): 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰
◆ 소프트웨어 아키텍처 패턴 유형
- 계층화 패턴(Layered Pattern): 시스템을 계층으로 구분하여 구성하는 패턴
- 클라이언트-서버 패턴(Client-Server Pattern): 하나의 서버와 다수의 클라이언트로 구성된 패턴
- 파이프-필터 패턴(Pipe-Filter Pattern): 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴, 재사용성이 좋고 추가가 쉬워 확장에 용이
- 브로커 패턴(Broker Pattern): 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌들 원격 서비스 실행을 통해 상호작용이 가능
- 모델-뷰-컨트롤러 패턴(MVC, Model-View-Controller Patter): 대형 애플리케이션을 3개의 서브 시스템으로 구조화한 패턴, 컴포넌트로 분리되어있어 서로 영향을 받지 않고 개발 작업 수행 가능
- 모델(Model): 핵심 기능과 데이터 보관
- 뷰(View): 사용자에게 정보 표시
- 컨트롤러(Controller): 사용자로부터 요청을 입력받아 처리
◆ 소프트웨어 아키텍처 비용 평가 모델 종류(SACAA)
- SAAM: 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능 비용평가 모델
- ATAM: 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상층관계까지 평가하는 모델
- CBAM: ATAM 바탕의 시스템으로 경제적 의사결정에 대한 요구를 충족하여 평가 모델
- ADR: 소프트웨어 아키텍처 구성요소 간 응집도 평가 모델
- ARID: 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하여 비용 평가 모델
◆ 디자인 패턴: 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
디자인 패턴 구성요소- 패턴 이름 / 문제 / 솔루션 / 사례 / 결과 / 샘플 코드(패문솔 사결샘)
◆ 디자인 패턴 유형
- 목적
- 생성: 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성방식을 구조화, 캡슐화를 수행하는 패턴
- 구조: 클래스나 객체의 조합을 다루는 패턴
- 행위: 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴
- 범위
- 클래스: 상속 관계를 다루는 패턴, 컴파일 타임에 정적으로 결정
- 객체: 객체 간 고나련서응ㄹ 다루는 패턴, 런타임에 동적으로 결정
◆ 디자인 패턴 종류(생구행)
- 생성패턴: Builder, Prototype, Factory Method, Abstract Factory, Singleton
- 구조패턴: Bridge, Decorator, Facade, Flyweight, Proxy, Composite, Adapter
- 행위패턴: Mediator, Interpreter, Iterator, Template Method, Observer, State, Visitor, COmmand, Strategy, Memento, Chain of Responsibility
생성 패턴(Creational Patterns)
객체 생성에 관련된 패턴입니다. 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공합니다.
생빌 프로 팩앱싱-생성(빌더 / 프로토타입 / 팩토리 메서드 / 앱스트랙 팩토리 / 싱글톤)
1. 싱글톤 패턴(Singleton) : 클래스의 인스턴스가 하나임을 보장하고 접근할 수 있는 전역적인 접근점을 제공하는 패턴으로, 디자인 패턴의 가장 많이 알려진 패턴입니다.
2. 추상팩토리 패턴(Abstract Factory) : 구체적인 클래스를 지정하지 않고 관련성이 있거나, 독립적인 객체들을 생성하기 위한 인터페이스를 제공하는 패턴입니다.
3. 빌더 패턴(Builder) : 복학 객체의 생성과정과 표현과정을 분리시켜 동일한 생성과정에서 다양한 표현을 생성할 수 있는 패턴입니다.
4. 팩토리 메서드 패턴(Factory Method) : 객체를 생성하는 인터페이스를 정의하지만, 인스턴스를 만드는 클래스는 서브클래스에서 결정하도록 하는 패턴입니다. 팩토리 메서드에서는 인스턴스를 만드는 것을 서브 클래스에서 하게 됩니다.
5. 원형 패턴(Prototype) : 생성할 객체의 종류를 명시하는 데 원형이 되는 예시물을 이용하고 새로운 객체를 이 원형들을 복사함으로써 생성하는 패턴입니다.
구조 패턴(Structural Patterns)
클래스나 객체를 조합해 더 큰 구조를 만드는 패턴입니다. 예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 서로 다른 객체들을 묶어 새로운 기능을 제공하는 패턴입니다.
구 브데 퍼플 프록 컴 어-구조(브리지 / 데코레이터 / 퍼사이드 / 플라이 웨이트 / 프록시 / 컴포지트 / 어댑 터)
1. 적응자 패턴(Adapter or Wrapper) : 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해주는 패턴입니다.
2. 브리지 패턴(Bridge) : 구현부에 추상층을 분리하여 각자 독립적으로 변형할 수 있도록 하는 패턴입니다. - 컴포지트 패턴(Composite) : 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴으로, 사용자가 단일 / 복합객체 모두 동일하게 다루도록 하는 패턴입니다.
3. 데코레이터 패턴(Decorator) : 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능확장이 필요할 때 서브클래스 대신 쓸 수 있는 대안이 될 수 있습니다.
4. 퍼사드 패턴(Facade) : 서브시스템에 있는 인터페이스 집합에 통합된 하나의 인터페이스를 제공합니다. 서브시스템을 좀 더 쉽게 사용하기 위해 고수준의 인터페이스를 정의합니다.
5. 프록시 패턴(Proxy) : 어떤 다른 객체로 접근하는 것을 통제하기 위해 그 객체의 매니저 또는 자리 채움자를 제공하는 패턴입니다.
행위 패턴(Behavioral Patterns)
객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴입니다. 한 객체가 혼자 수행할 수 없는 작업을 여러개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는것에 중점을 두는 방식입니다.
행 미인이 템옵 스테 비커 스트 메체-행위(미디에이터 / 인터프리터 / 이터레이터 / 템플릿 메서드/ 옵져버 / 스테이트/ 비지터 / 커맨드 / 스트레티지 / 메멘토 / 체인 오브 리스판서빌리티)
1. 옵저버 패턴(Observer) : 객체들 사이에 1 : N 의 의존관계를 정의하여 어떤 객체의 상태가 변할 때, 의존관계에 있는 모든 객체들이 통지받고 자동으로 갱신될 수 있게 만드는 패턴입니다.
2. 상태 패턴(State) : 객체의 내부 상태가 변경될 때 행동을 변경하도록 허락합니다. 객체는 자신의 클래스가 변경되는 것처럼 보이게 됩니다.
3. 스트레이트지 패턴(Strategy) : 동일 계열의 알고리즘들을 정의하고, 각각 캡슐화하며 이들을 상호교환 가능하도록 만드는 것입니다. 알고리즘을 사용하는 사용자로부터 독립적으로 알고리즘이 변경될 수 있도록 하는 패턴입니다.
4. 템플릿 패턴(Template) : 객체의 연산에서 알고리즘의 뼈대만 정의하고, 나머지는 서브클래스에서 이루어지게 하는 패턴입니다. 템플릿패턴은 알고리즘의 구조는 변경하지 않고 알고리즘의 각 단계를 서브클래스에서 재정의하게 됩니다.
5. 비지터 패턴(Visitor) : 객체구조를 이루는 원소에 대해 수행할 연산을 표현합니다. 방문자는 연산에 적용할 원소의 클래스를 변경하지 않고 새로운 연산을 재정의 할 수 있습니다.
6. 역할 사슬 패턴(Chain of Responsibility) : 요청을 처리하는 기회를 하나 이상의 객체에 부여하여 요청을 보내는 쪽과 받는 쪽의 결합을 피하는 패턴입니다. 요청을 받는 객체를 연쇄적으로 묶고 객체를 처리할 수 있을 때까지 요청을 전달합니다.
7. 커맨드 패턴(Command) : 요청을 객체로 캡슐화하여 서로 다른 사용자의 매개변수화, 요청 저장 또는 로깅, 연산의 취소를 지원하게 만드는 패턴입니다.
8. 인터프리터 패턴(Interpreter) : 주어진 언어에 대해서 문법을 위한 표현수단을 정의하고, 해당 언어로 된 문장을 해석하는 해석기를 사용하는 패턴입니다.
9. 이터레이터 패턴(Iterator) : 내부 표현부를 노출하지 않고 어떤 객체 집합의 원소들을 순차적으로 접근할 수 있는 방법을 제공하는 패턴입니다.
10. 미디에이터 패턴(Mediator) : 한 집합에 속해있는 객체들의 상호 작용을 캡슐화하는 객체를 정의하는 패턴입니다. 중재자는 객체들이 직접 서로 참조하지 않도록함으로써 객체들간의 느슨한 연결을 촉진시키며 객체들의 상호작용을 독립적으로 다양화 시킬 수 있도록 해줍니다.
◆ 운영체제 (Operating SYstem): 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램
- 운영체제 종류
- PC: 윈도즈, 유닉스, 리눅스
- 모바일: 안드로이드, iOS
◆ OSI 계층: 네트워크 통신에서 충돌 문제를 완화하기 위해 국제 표준화 기구(ISO)에서 제시한 모델
(아파서 티내다, 피나다.) OSI 7계층 Application(7) / Presentation(6) / Session(5) / Transport(4) / Network(3) / Data Link(2) / Physical(1)
- 응용 계층(Application Layer): 사용자와 네트워크 간 응용서비스 연결, 데이터 생성
- 표현 계층(Presentation Layer): 데이터 형식 설정과 부호교환, 암/복호화
- 세션 계층(Session Layer): 연결 접속 및 동기 제어
- 전송 계층(Transport Layer): 신뢰성 있는 통신 보장. 데이터 분할과 재조립, 흐름제어, 혼잡제어 등 담당,
- 네트워크 계층(Network Layer): 단말 간 데이터 전송을 위한 최적화된 경로 제공
- 데이터 링크 계층(Data Link Layer): 인접 시스템 간 데이터 전송, 전송오류 제어
- 물리 계층(Physical Layer): 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환
◆ DBMS(Database Management System): 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램
(가성호기구) DBMS 현행 시스템 분석 시 고려 사항 - 가용성 / 성능 / 상호 호환성 / 기술 지원 / 구축 비용
◆ 미들웨어(Middleware): 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어. 대표적인 미들웨어: WAS
- 웹 애플리케이션 서버(WAS: Web Application Server): 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버
Chapter03 요구사항 확인 (중요도: ★★★)
◆ 요구공학(Requirements Engineering): 사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 호가인 및 검증하는 구조화된 활동
◆ 요구사항의 분류
- 기능적 요구사항: 시스템이 제공하는 기능, 서비스에 대한 요구사항
- 특정 입력/상황에 대해 시스템이 어떻게 반응/동작 해야 하는지에 대한 기술
- 특성: 기능성, 완전성, 일관성
- 비기능적 요구사항: 시스템 구축에 대한 제약사항에 관한 요구사항
- 품질 속성에 관련하여 시스템이 갖춰야할 사항에 관한 기술, 시스템이 준수해야 할 제한 조건에 관한 기술
- 특성: 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항
- (명완검 일수 추개) 요구사항 명세 원리 및 검증 항목-명확성 / 완전성 / 검증 가능성 / 일관성 / 수정 용이성 / 추적 가능성 / 개발 후 이 용성
◆ 요구공학 프로세스: 도출 → 분석 → 명세 → 확인 및 검증(도분명확)
[##_Image|kage@Cgwd5/btrBkDPxUch/UEJBCH1GzD4fUJwJkCUqR0/img.png|CDM|1.3|{"originWidth":583,"originHeight":261,"style":"alignCenter"}_##]
요구사항 관리 단계(CMM Level 2 프로세스 영역) (협기변확)
| 순서 | 절차 | 기법/산출물 |
| 1 | 요구사항 협상 | 우선순위 설정, 시물레이션 |
| 2 | 요구사항 기준선 설정 | 공식 회의, 형상 관리 |
| 3 | 요구사항 변경관리 | 형상통제 위원회, 영향도 분석 |
| 4 | 요구사항 확인 및 검증 | 확인 및 검증 |
요구사항 개발 단계(CMM Level 3 프로세스 영역) (도분명확)
| 순서 | 절차 | 내용 |
| 1 | 요구사항 도출 | 문제 이해, 정보 식별, 수집 방법 결정 |
| 2 | 요구사항 분석 | 요구사항 분석 활동 |
| 3 | 요구사항 명세 | 문서 작성 단계 |
| 4 | 요구사항 확인 및 검증 | 확인(Validation), 검증(Verfication) 단계 |
◆ 요구사항 도출 단계 주요 기법
- 인터뷰, 브레인스토밍, 델파이기법, 롤 플레잉, 워크숍, 설문조사
- 델파이기법: 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법
◆ 요구사항 확인 및 검증 단계의 주요 기법
- 요구사항 검토: 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토
- 정형 기술 검토 활용(동워인)
- 동료 검토(Peer Review): 2~3명 리뷰 진행, 요구사항 명세서를 설명하고 이해관계자들이 들으면서 결함을 발견하는 형태로 진행
- 워크 스루(Walk Through): 검토 자료를 회의 전에 배포하여 짧은 시간동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화
- 인스펙션(Inspection): 소프트웨어 요구, 설계 원시 코드 등의 저작자 외의 다른 전무가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토방법
- (관기 인워감) 상세 정형 기술 검토 기법 - 관리 리뷰 / 기술 리뷰 / 인스펙션 / 워크 스루 / 감사
- 프로토타이핑 활용: 프로토파입(견본품)을 통해 효과적으로 요구 분석을 수행하면서 명세스를 산출하는 작업
- 모델 검증: 분석단계에서 개발된 모델의 품질 검증 필요
- 테스트 케이스 및 테스트를 통한 확인: 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 수립하고 테스트 케이스 작성
- CASE 도구 활용 검증: 자동화된 일관성 분석을 제공하는 CASE도구 활용
- 베이스라인을 통한 검증: 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검증 수행
- 요구사항 추적표(RTM)를 통한 검증: 요구사항 정의서를 기준으로 개발 단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인이 가능한 문서
Chapter04 분석 모델 확인하기 (중요도: ☆)
◆ 분석 모델 검증 방법: 유스케이스 모델 검증, 개념수준의 분석 클래스 검증, 분석 클래스 검증