정보처리기사 실기 정리 - 1. 요구사항 확인

Chapter01 소프트웨어 개발 방법론 (중요도: ★★★)

◆ 소프트웨어 생명주기 (SDLC, Software Development Life Cycle)

:시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

◆ 소프트웨어 생명주기 모델 종류(폭프나반)

• 폭포수 모델: 가장 오래된 모델로, 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감
• 프로토타이핑 모델: 주요기능을 프로토타입으로 구현해, 고객의 피드백을 반영하여 S/W 만듦
• 나선형 모델: 위험을 최소화하기 위해 점진적으로 시스템 개발
  • 절차(계위개고): 계획 및 정의 -> 위험분석 -> 개발 -> 고객평가
• 반복적 모델: 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발

◆ 소프트웨어 개발 방법론

:소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과장을 형상화한 방법론

◆ 소프트웨어 개발 방법론 종류 - 구정/객컴/애제

• 구조적 방법론 (Structured Development):

  • 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방법론
  • 프로세스 중심의 하향식 방법론
  • 나씨-슈나이더만 차트: 논리의 기술에 중점을 둔 도형식 표현방법

• 정보공학 방법론(Information Engineering Development):

  • 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
  • James Martin 이 비즈니스 시스템 즉, 정보시스템 개발을 공학적으로 접근하기 위해 체계화시킨 개발 방법론

• 객체 지향 방법론(OOP, Object-Oriented Programming ):

  • '객체’라는 기본 단위 로 시스템을 분석 및 설계하는 방법론
  • 현실 세계의 개체(Entity)를 속성(Attribute)과 메서드(Method)가 결합된 형태의 객체(Object)로 표현하는 개념, 객체간의 메시지 통신을 통해 시스템을 구현하는 개발방법
  • 규모가 큰 대형프로젝트 적합
  • 재사용률 확장성 유지보수 향상
  • 사용자 타입 중심
  • 대화식 프로그램 개발 용이

• 컴포넌트 기반 방법론 (CBD, Component Based Development): 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론

• 애자일 방법론: 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적인 시스템 개발할 수 있는 신속 적응적 개량 개발 방법론

• 제품 계열 방법론: 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발하는 방법론, 임베디드 S/W작성에 유용

◆ 애자일(Agile) 방법론 유형

• XP(eXtreme Programming): 의사소통 개선과 즉각적 피드백으로 스프트웨어 품질을 높이기 위한 방법론

  • XP 5가지 가치 (용단의피존): 용기, 단순성, 의사소통, 피드백, 존중
  • XP12가지 기본원칙
    

• 스크럼(Scrum): 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

• 린(Lean): 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론

  • Lean 7가지 가치: 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

◆ 객체 지향 분석(OOA, Object Oriented Analysis)

: 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의

◆ 객체 지향 분석 방법론 종류

• 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,Function Point) 모형: 소프트웨어 기능을 증대시키는 요인별로 가중치를 부여하여 비용산정

◆ 비용 산정 자동화 추정 도구

• SLIM: Rayleigh-Norden곡선과 Putnam예측 모델을 기초로 하여 개발된 자동화 추정 도구
• ESTIMACS: 다양한 프로젝트와 개인별 요소를 수용하도록 FP모형을 기초로 하여 개발된 자동화 추정 도구

◆ 일정관리 모델

:프로젝트가 일정 기한 내에 완료될 수 있도록 관리하는 모델

• 주 공정법(CPM, Critical Path Method): 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법

  • 주 공정(Critical Path: 임계 경로): 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로

  

• PERT(Program Evaluation and Review Technique): 일의 순서를 계획적으로 정리하기 위한 수렴기법. 비관치, 중간치, 낙관치 이용
• 중요 연쇄 프로젝트 관리(CCPM, Critical Chain Project Management): 주 공정 연쇄법으로 원제약사항을 고려하여 일정을 작성하는 기법

Chapter02 현행 시스템 분석 (중요도: ★★★)

◆ 현행 시스템 파악:

현행시스템의 어떤 기술 요소 사용을 하는지 파악하는 활동

◆ 현행 시스템 파악 절차

• 구성/기능/인터페이스 파악 → 아키텍처 및 소프트웨어 구성 파악 → 하드웨어 및 네트워크 구성 파악

◆ 소프트웨어 아키텍처:

여러 가지 소프트웨어 구성요소과 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체

◆ 소프트웨어 아키텍처 4+1 뷰 (유논프구배)

: 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

• 유스케이스 뷰: 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰, 사용자 설계자 개발자 테스트 관점
• 논리 뷰: 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰, 설계자 개발자 관점
• 프로세스 뷰: 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰, 개발자 시스템 통합자 관점
• 구현 뷰: 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰, 컴포넌트 구조와 의존성을 보여주고 부가적인 정보 정의
• 배포 뷰: 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

◆ 소프트웨어 아키텍처 패턴 유형

• 계층화 패턴(Layered Pattern): 시스템을 계층으로 구분하여 구성하는 패턴

  

• 클라이언트-서버 패턴(Client-Server Pattern): 하나의 서버와 다수의 클라이언트로 구성된 패턴

  

• 파이프-필터 패턴(Pipe-Filter Pattern): 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴, 재사용성이 좋고 추가가 쉬워 확장에 용이 (대표:UNIX의 쉘)
  

• 브로커 패턴(Broker Pattern): 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌트들 원격 서비스 실행을 통해 상호작용이 가능

• 모델-뷰-컨트롤러 패턴(MVC, Model-View-Controller Patter): 대형 애플리케이션을 3개의 서브 시스템으로 구조화한 패턴, 컴포넌트로 분리되어있어 서로 영향을 받지 않고 개발 작업 수행 가능

  • 모델(Model): 핵심 기능과 데이터 보관
  • 뷰(View): 사용자에게 정보 표시
  • 컨트롤러(Controller): 사용자로부터 요청을 입력받아 처리

◆ 소프트웨어 아키텍처 비용 평가 모델 종류(SACAA)

• SAAM(SoftWare Architecture Analyses Method): 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능 비용평가 모델
• ATAM(Architecture Trade-off Analysis Method): 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델
• CBAM(Cost Benefit Analysis Method): ATAM 바탕의 시스템으로 경제적 의사결정에 대한 요구를 충족하여 평가 모델
• ADR(Active Design Review): 소프트웨어 아키텍처 구성요소 간 응집도, 평가 모델
• ARID(Active Reviews for Intermediate Designs): 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하여 비용 평가 모델

◆ 디자인 패턴:

소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

◆ 디자인 패턴 유형

• 목적(생구행)

  • 생성: 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성방식을 구조화, 캡슐화를 수행하는 패턴
  • 구조: 클래스나 객체의 조합을 다루는 패턴
  • 행위: 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

• 범위(클객)

  • 클래스: 상속 관계를 다루는 패턴, 컴파일 타임에 정적으로 결정
  • 객체: 객체 간 관련성을 다루는 패턴, 런타임에 동적으로 결정

◆ 목적에 따른 디자인 패턴 종류

디자인 패턴의 종류

[생성] - 생빌 프로 팩앱싱

• 생성 패턴은 객체의 생성과 관련된 패턴
• 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 최소화 할 수 있도록 유연성 제공

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: (객체가 특정 상태로 다시 되돌아올 수 있도록 내부 상태를 실체화)

클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용, Undo 기능을 개발할 때 사용(객체를 이전 상태로 복구시켜야 하는 경우 '작업취소(Undo)' 요청)

Chain of Responsibility: (요청을 받는 객체를 연쇄적으로 묶어 요청을 처리하는 객체를 만날때 까지 객체 Chain을 따라 요청을 전달 )

정적으로 어떤 기능에 대한 처리의 연결이 하드코딩 되어 있을 때 기능 처리의 연결 변경이 불가능한데 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결(한 요청을 2개 이상의 객체에서 처리)

◆ 운영체제 (Operating System)

:컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램

운영체제 종류
PC: 윈도즈, 유닉스, 리눅스
모바일: 안드로이드, iOS

◆ OSI 계층(아파서 티네다 피나다)

: 네트워크 통신에서 충돌 문제를 완화하기 위해 국제 표준화 기구(ISO)에서 제시한 모델

• 응용 계층(Application Layer): 사용자와 네트워크 간 응용서비스 연결, 데이터 생성
• 표현 계층(Presentation Layer): 데이터 형식 설정과 부호교환, 암/복호화
• 세션 계층(Session Layer): 연결 접속 및 동기 제어
• 전송 계층(Transport Layer): 신뢰성 있는 통신 보장. 데이터 분할과 재조립, 흐름제어, 혼잡제어 등 담당,
• 네트워크 계층(Network Layer): 단말 간 데이터 전송을 위한 최적화된 경로 제공
• 데이터 링크 계층(Data Link Layer): 인접 시스템 간 데이터 전송, 전송오류 제어
• 물리 계층(Physical Layer): 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환

◆ DBMS(Database Management System)

: 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램

◆ 미들웨어(Middleware)

: 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어. 대표적인 미들웨어: WAS

• 웹 애플리케이션 서버(WAS: Web Application Server): 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버

Chapter03 요구사항 확인 (중요도: ★★★)

◆ 요구공학(Requirements Engineering)

:사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

◆ 요구사항의 분류

• 기능적 요구사항: 시스템이 제공하는 기능, 서비스에 대한 요구사항
  • 특정 입력/상황에 대해 시스템이 어떻게 반응/동작 해야 하는지에 대한 기술
  • 특성: 기능성, 완전성, 일관성
• 비기능적 요구사항: 시스템 구축에 대한 제약사항에 관한 요구사항
  • 품질 속성에 관련하여 시스템이 갖춰야할 사항에 관한 기술, 시스템이 준수해야 할 제한 조건에 관한 기술
  • 특성: 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항

◆ 요구공학 프로세스 (도분명확)

: 도출 → 분석 → 명세 → 확인 및 검증

◆ 요구사항 도출 단계 주요 기법

• 인터뷰: 이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보수집 방식
• 롤 플레잉 : 현실에 일어나는 장면을 설정하고, 여러사람이 각자 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법
• 설문조사 : 설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집하는 방법
• 워크숍: 단기간 집중적인 노력으로 다양하고 전문적인 정보를 획득하고 공유하는 방법
• 브레인스토밍: 말꺼내기 쉬운 분위기 말들어 회의 참석자들이 아이디어들을 비판 없이 수용할수 있도록 하는 회의
• 델파이기법: 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법

◆ 요구사항 확인 및 검증 단계의 주요 기법

• 요구사항 검토: 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토
• 정형 기술 검토 활용: 사용자의 요구표현할 때 수학적인 원리와 표기법을 기반으로 서술 하는 기법
  • 동료 검토: 2~3명 리뷰 진행, 요구사항 명세서를 설명하고 이해관계자들이 들으면서 결함을 발견하는 형태로 진행
  • 워크 스루: 검토 자료를 회의 전에 배포하여 짧은 시간동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화
  • 인스펙션: 소프트웨어 요구, 설계 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토방법
• 프로토타이핑 활용: 프로토파입(견본품)을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출하는 작업
  - 모델 검증: 분석단계에서 개발된 모델의 품질 검증 필요
• 테스트 케이스 및 테스트를 통한 확인: 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 수립하고 테스트 케이스 작성
• CASE 도구 활용 검증: 자동화된 일관성 분석을 제공하는 CASE도구 활용
• 베이스라인을 통한 검증: 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검증 수행
• 요구사항 추적표(RTM)를 통한 검증: 요구사항 정의서를 기준으로 개발 단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인이 가능한 문서

Chapter04 분석 모델 확인하기 (중요도: ☆)

◆ 분석 모델 검증 방법

: 유스케이스 모델 검증, 개념수준의 분석 클래스 검증, 분석 클래스 검증