[정보처리기사 실기] 01. 요구사항 확인

소프트웨어 생명주기 모델(SDLC; Swoftware Development Life Cycle)

• 소프트웨어 생명주기 : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
• 단계 : 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수
• 종류 : 
  • 폭포수 모델(Waterfall Model, 고전적 생명주기 모델)
    • 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
    • 소프트웨어 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
    • 단계 : 타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수
  • 프로토타이핑 모델(Prototyping Model)
    • 고객이 요구한 주요 기능을 프로토타입으로 구현, 고객의 피드백을 반영하여 소프트웨어 개발
  • 나선형 모델(Spiral Model)
    • 보헴(Bohem)이 제안한 것으로 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
    • 단계(반복) : 계획 및 정의 → 위험 분석 → 개발 및 검증 → 고객 평가
  • 반복적 모델(Interation Model)
    • 구축 대상을 나누어 병렬적, 반복적으로 개발 후 통합하여 소프트웨어 개발

 

소프트웨어 개발 방법론(Software Development Methodology)

• 소프트웨어 개발 전 과정에서 지속적으로 적용할 수 있는 방법, 절차, 기법
• 소프트웨어 하나를 하나의 생명체로 간주하고 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론
• 종류 :
  • 구조적 방법론(Structured Development)
    • 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
    • 구조적 프로그래밍 표현을 위해 나씨-슈나이더만(Nassi-Shneiderman) 차트 사용
    • 프로세스 중심의 하향식 방법론
  • 정보공학 방법론(Information Engineering Development)
    • 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
    • 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론
  • 객체지향 방법론(Object-Orinted Development)
    • '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론
    • 객체, 클래스, 메시지 사용
  • 컴포넌트 기반 방법론(CBD; Component Based Development)
    • 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
    • 개발 기간 단축으로 인한 생산성 향상
    • 소프트웨어 재사용 및 새로운 기능 추가 용이(확장성)
  • 애자일 방법론(Agile Development)
    • 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 개량 개발 방법론
    • 개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아 유동적으로 개발
    • 유형 :
      • XP(eXtreme Programming)
        • 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
        • 5가지 가치 : 
          • 용기(Courage)
          • 단순성(Simplicity)
          • 의사소통(Communication)
          • 피드백(Feedback)
          • 존중(Respect)
        • 12가지 원리
          • 짝 프로그래밍(Pair Programming)
          • 공동 코드 소유(Collective Ownership)
          • 지속적인 통합(CI; Continuous Intergration)
          • 계획 세우기(Planning Process)
          • 작은 릴리즈(Small Release)
          • 메타포어(Metaphor)
          • 간단한 디자인(Simple Design)
          • 테스트 기반 개발(TDD; Test Driven Develop)
          • 리팩토링(Refactoring)
          • 40시간 작업(40-Hour Work)
          • 고객 상주(On Site Customer)
          • 코드 표준(Coding Standard)
      • 스크럼(Scrum)
        • 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
        • 백로그(Backlog) : 제품과 프로젝트에 대한 요구사항
        • 스프린트(Sprint) : 2 ~ 4주의 짧은 개발 기간의 반복적 수행으로 개발품질 향상
        • 스크럼 미팅(Scrum Meeting) :
          • 매일 15분 정도 미팅으로 To-Do List 계획 수립
          • 데일리 미팅(Daily Meeting)이라고도 함
        • 스크럼 마스터(Scrum Master) : 프로젝터 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
        • 스프린트 회고(Sprint Retrospective) : 
          • 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
          • 해당 스프린트가 끝난 시점이나 일정 주기로 시행
        • 번 다운 차트(Burn Down Chart) : 
          • 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
          • 백로그는 보통 수직축에 위치하며 시간을 수평축에 위치
      • 린(LEAN)
        • 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
        • JIT(Just In Time), 칸반(Kanban) 보드 사용
        • 7가지 원칙 : 낭비 제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

 

 

객체 지향 분석 방법론(OAA; Object Oriented Analysis)

• 객체 지향 분석 : 사용자의 요구사항을 분석하여 요구된 문제와 관련된 클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법
• 종류 : 
  • OOSE(Object Oriented Software Engineering) : 야콥슨(Jacobson)
    • 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용되는 방법론
    • 분석, 설계, 구현 단계로 구성되며 기능적 요구사항 중심의 시스템
  • OMT(Object Modeling Technology) : 럼바우(Rumbaugh)
    • 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론
    • 분석 절차 : 객체 모델링 → 동적 모델링 → 기능 모델링
      • 객체 모델링(Object Modeling)
        • 정보 모델링(Information Modeling)
        • 시스템에서 요구하는 객체를 갖고 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링
        • 객체 다이어그램을 활용하여 표현
      • 동적 모델링(Dynamic Modeling) 
        • 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현
        •  상태 다이어그램을 활용하여 표현
      • 기능 모델링(Functional Modeling) 
        • 프로세스의 자료 흐름을 중심으로 처리 과정을 표현하는 모델링
        • 자료 흐름도(DFD; Data Flow Diagram)를 활용하여 표현
  • OOD(Object Oriented Design) : 부치(Booch)
    • 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론
    • 분석과 설계의 분리가 불가능

 

 

비용 산정 모형

• 소프트웨어 규모 파악을 통한 투입자원, 소요 시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식
• 분류 : 
  • 하향식 산정 방법 : 전문가 판단, 델파이 기법
  • 상향식 상정 방법 :
    • 코드 라인 수(LoC; Lines of Code)
      
      • 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측지를 구하고 이를 이용하여 비용을 산정하는 방식
      • 측정이 쉽고 이해하기 쉬워 많이 사용
    • Man Month 
      • 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식
    • COCOMO(COnstructive COst MOdel)
      • 보헴(Bohem)이 제안한 모형으로, 프로그램 규모에 따라 비용을 산정하는 방식
      • 비용산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 산정
      • 유형은 규모에 따라 조직형, 반 분리형, 임베디드형으로 나뉜다.
      • 유형 : 
        • 조직형(Organic Mode)
          • 5만(50KDSI) 라인 이하
          • 기관 내부에서 개발된 중소규모의 소프트웨어
          • 일괄 자료 처리, 과학 기술 계산용, 비즈니스 자료 처리 개발에 적용 
        • 반 분리형(Semi-Detached Mode)
          • 30만(300KDSI) 라인 이하
          • 단순형과 임베디드의 중간형
          • 트랜잭션 처리 시스템, 데이터베이스 관리 시스템, 컴파일러, 인터프리터와 같은 유틸 개발에 적용
        • 임베디드형(Embedded Mode)
          • 30만(300KDSI) 라인 이상
          • 초대형 규모의 트랜잭션 처리 시스템
          • 운영체제, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적용
    • 푸트남(Putnam)
      • 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
      • 푸트남이 제안한 것으로 생명주기 예측 모형이라고 한다.
      • 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
    • 기능 점수(FP; Function Point)
      • 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식
      • 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여

 

 

일정 관리 모델

• 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델
• 종류 : 
  • 주 공정법(CPM; Critical Path Method)
    • 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 방법
    • 모든 자원 제약사항을 베재한 상태로 프로젝트의 시작과 끝을 나타내는 노드(Node)와 노드 간 연결을 통해 공정을 계산하기 위한 액티비티(Activity) 표기법
  • PERT(Program Evaluation and Review Technique) 
    • 일의 순서를 계획적으로 정리하기 위한 수렴 기법
    • 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 방법
  • 중요 연쇄 프로젝트 관리(CCPM; Critical Chain Project Management)
    • 주 공정 연쇄법으로 자원 제약 사향을 고려하여 일정을 작성하는 방법

 

 

현행 시스템  파악

• 현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지를 파악하는 활동
• 사용하고 있는 소프트웨어 및 하드웨어는 무엇인지, 네트워크의 구성은 어떻게 되어 있는지 파악하는 활동
• 절차 : 구성/기능/인터페이스 파악 → 아키텍처 및 소프트웨어 구성 파악 → 하드웨어 및 네트워크 구성 파악

 

 

소프트웨어 아키텍처(Software Architecture)

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

 

 

소프트웨어 아키텍처 프레임워크(Software Architecture Framework)

• 소프트웨어 집약적인 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준
• 구성요소 : 
  • 아키텍처 명세서(Architectural Description)
    • 아키텍처를 기록하기 위한 산출물
    • 이해관계자들의 시스템에 대한 관심을 관점에 맞추어 작성한 뷰로 표현
    • 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등
  • 이해관계자(Stakeholder)
    • 시스템 개발에 관련된 모든 사람과 조직
    • 고객, 최종 사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등
  • 관심사(Concerns)
    • 사용자 입장 : 기본적인 기능, 신뢰성, 보안, 사용성 등
    • 유지보수자 입장 : 유지보수의 용이성
    • 개발자 입장 : 적은 비용과 인력으로 개발
  • 관점(Viewpint)
    • 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식
    • 이해관계자들이 서로 다른 역할이나 책임으로 시스템이나 산출물들에 대해 보고 싶은 관점
  • 뷰(View)
    • 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현
    • 시스템에 대한 아키텍처 설명에는 하나 이상의 뷰로 구성
  • 근거(Rationale)
    • 아키텍처 결정 근거
    • 회의 결과, 보고 결과
  • 환경(Environment) : 시스템에 영향을 주는 요인으로 개발, 운영 등의 외부 요인 등으로 시스템에 영향을 주는 요인
  • 시스템(System) : 각 애플리케이션, 서브 시스템, 시스템의 집합, 제품군 등의 구현체

 

소프트웨어 아키텍처 4+1 뷰

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

 

 

소프트웨어 아키텍처 패턴(Software Architecture Pattern)

• 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식
• 주어진 상황에서의 소프트웨어 아키텍처에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션
• 유형 :
  • 계층화 패턴(Layered Pattern) 
    • 시스템을 계층(Layer)으로 구분하여 구성
    • 각 하위 모듈들은 특정한 수준의 추상화를 제공하고, 각 계층은 다음 상위 계층에 서비스를 제공
    • 계층화 패턴은 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어짐
  • 클라이언트-서버 패턴(Client-Server Pattern)
    • 하나의 서버와 다수의 클라이언트로 구성
    • 사용자가 클라이언트를 통해서 서버에 서비스를 요청하면 서버는 클라이언트에게 서비스를 제공
    • 서버는 클라이언트로부터 요청 대기
  • 파이프-필터 패턴(Pip-Filter Pattern)
    • 데이터 스크림을 생성하고 처리하는 시스템에서 사용 가능한 패턴
    • 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정 반복
    • 필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확장 용이
  • 브로커 패턴(Broker Pattern)
    • 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포넌트 들은 원격 서비스 실행을 통해 상호 작용이 가능
    • 브로커 컴포넌트는 컴포넌트 간의 통신을 조정하는 역할 수행
  • 모델-뷰-컨트롤러 패턴(MVC; Model View Controller Pattern)
    • 각 부분이 별도의 컴포넌트로 분리되어 있어서 서로 영향을 받지 않고 개발 작업 수행 가능
    • 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능하게 하고, 대화형 애플리케이션 구축에 적합
    • 구성 요소 :
      • 모델(Model) : 핵심 기능과 데이터 보관
      • 뷰(View) : 사용자에게 정보 표시(하나 이상의 뷰가 정의될 수 있음)
      • 컨트롤러(Controller) : 사용자로부터 요청을 입력받아 처리

 

 

소프트웨어 아키텍처 비용 평가 모델

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

 

 

디자인 패턴(Design Pattern)

• 소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
• 디자인 패턴을 참고하여 개발할 경우 개발의 효율성과 유지보수성, 운용성이 높아지며, 프로그램의 최적화에 도움이 된다.
• 구성요소 : 
  • 패턴의 이름 : 디자인 패턴을 부를 때 사용하는 이름과 디자인 패턴의 유형
  • 문제 및 배경 : 디자인 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미
  • 솔루션 : 디자인 패턴을 이루는 요소들, 관계, 협동 과정
  • 사례 : 디자인 패턴의 간단한 적용 사례
  • 결과 : 디자인 패턴을 사용하면 얻게 되는 이점이나 영향
  • 샘플 코드 : 디자인 패턴이 적용된 원시 코드
• 유형 : 
  • 목적에 따른 구분
    • 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 구행하는 패턴
    • 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
    • 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴
  • 범위에 따른 구분 
    • 클래스 : 클래스 간 관련성(상속 관계)을 다루는 패턴, 컴파일 타임에 정적으로 결정
    • 객체 : 객체 간 관련성을 다루는 패턴, 런타임에 동적으로 결정
• 종류 : 
  • 생성 패턴
    • 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 기능을 개발할 때 사용하는 패턴 
    • Chain of Responsibility
      • 정적으로 어떤 기능에 대한 처리의 연결이 하드코딩 되어 있을 때 기능 처리의 연결 변경이 불가능한데, 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 패턴

 

 

현행 시스템  파악

• 현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지를 파악하는 활동
• 사용하고 있는 소프트웨어 및 하드웨어는 무엇인지, 네트워크의 구성은 어떻게 되어 있는지 파악하는 활동
• 절차 : 구성/기능/인터페이스 파악 → 아키텍처 및 소프트웨어 구성 파악 → 하드웨어 및 네트워크 구성 파악

 

 

소프트웨어 아키텍처(Software Architecture)

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

 

 

소프트웨어 아키텍처 프레임워크(Software Architecture Framework)

• 소프트웨어 집약적인 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준
• 구성요소 : 
  • 아키텍처 명세서(Architectural Description)
    • 아키텍처를 기록하기 위한 산출물
    • 이해관계자들의 시스템에 대한 관심을 관점에 맞추어 작성한 뷰로 표현
    • 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등
  • 이해관계자(Stakeholder)
    • 시스템 개발에 관련된 모든 사람과 조직
    • 고객, 최종 사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등
  • 관심사(Concerns)
    • 사용자 입장 : 기본적인 기능, 신뢰성, 보안, 사용성 등
    • 유지보수자 입장 : 유지보수의 용이성
    • 개발자 입장 : 적은 비용과 인력으로 개발
  • 관점(Viewpint)
    • 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식
    • 이해관계자들이 서로 다른 역할이나 책임으로 시스템이나 산출물들에 대해 보고 싶은 관점
  • 뷰(View)
    • 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현
    • 시스템에 대한 아키텍처 설명에는 하나 이상의 뷰로 구성
  • 근거(Rationale)
    • 아키텍처 결정 근거
    • 회의 결과, 보고 결과
  • 환경(Environment) : 시스템에 영향을 주는 요인으로 개발, 운영 등의 외부 요인 등으로 시스템에 영향을 주는 요인
  • 시스템(System) : 각 애플리케이션, 서브 시스템, 시스템의 집합, 제품군 등의 구현체

 

소프트웨어 아키텍처 4+1 뷰

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

 

 

소프트웨어 아키텍처 패턴(Software Architecture Pattern)

• 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식
• 주어진 상황에서의 소프트웨어 아키텍처에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션
• 유형 :
  • 계층화 패턴(Layered Pattern) 
    • 시스템을 계층(Layer)으로 구분하여 구성
    • 각 하위 모듈들은 특정한 수준의 추상화를 제공하고, 각 계층은 다음 상위 계층에 서비스를 제공
    • 계층화 패턴은 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어짐
  • 클라이언트-서버 패턴(Client-Server Pattern)
    • 하나의 서버와 다수의 클라이언트로 구성
    • 사용자가 클라이언트를 통해서 서버에 서비스를 요청하면 서버는 클라이언트에게 서비스를 제공
    • 서버는 클라이언트로부터 요청 대기
  • 파이프-필터 패턴(Pip-Filter Pattern)
    • 데이터 스크림을 생성하고 처리하는 시스템에서 사용 가능한 패턴
    • 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정 반복
    • 필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확장 용이
  • 브로커 패턴(Broker Pattern)
    • 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포넌트 들은 원격 서비스 실행을 통해 상호 작용이 가능
    • 브로커 컴포넌트는 컴포넌트 간의 통신을 조정하는 역할 수행
  • 모델-뷰-컨트롤러 패턴(MVC; Model View Controller Pattern)
    • 각 부분이 별도의 컴포넌트로 분리되어 있어서 서로 영향을 받지 않고 개발 작업 수행 가능
    • 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능하게 하고, 대화형 애플리케이션 구축에 적합
    • 구성 요소 :
      • 모델(Model) : 핵심 기능과 데이터 보관
      • 뷰(View) : 사용자에게 정보 표시(하나 이상의 뷰가 정의될 수 있음)
      • 컨트롤러(Controller) : 사용자로부터 요청을 입력받아 처리

 

 

소프트웨어 아키텍처 비용 평가 모델

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

 

 

디자인 패턴(Design Pattern)

• 소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
• 디자인 패턴을 참고하여 개발할 경우 개발의 효율성과 유지보수성, 운용성이 높아지며, 프로그램의 최적화에 도움이 된다.
• 구성요소 : 
  • 패턴의 이름 : 디자인 패턴을 부를 때 사용하는 이름과 디자인 패턴의 유형
  • 문제 및 배경 : 디자인 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미
  • 솔루션 : 디자인 패턴을 이루는 요소들, 관계, 협동 과정
  • 사례 : 디자인 패턴의 간단한 적용 사례
  • 결과 : 디자인 패턴을 사용하면 얻게 되는 이점이나 영향
  • 샘플 코드 : 디자인 패턴이 적용된 원시 코드
• 유형 : 
  • 목적에 따른 구분
    • 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 구행하는 패턴
    • 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
    • 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴
  • 범위에 따른 구분 
    • 클래스 : 클래스 간 관련성(상속 관계)을 다루는 패턴, 컴파일 타임에 정적으로 결정
    • 객체 : 객체 간 관련성을 다루는 패턴, 런타임에 동적으로 결정
• 종류 : 
  • 생성 패턴
    • 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 기능을 개발할 때 사용하는 패턴 
    • Chain of Responsibility
      • 정적으로 어떤 기능에 대한 처리의 연결이 하드코딩 되어 있을 때 기능 처리의 연결 변경이 불가능한데, 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 패턴

 

 

분석 산출물의 종류

• 정보 시스템 구성 현황
• 정보 시스템 기능 구성도
• 인터페이스 구성도
• 인터페이스 현황
• 현행 시스템 아키텍처 구성도
• 소프트웨어 구성도
• 하드웨어 구성도
• 네트워크 구성도

 

 

운영체제(OS; Operating System)

• 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고, 컴퓨터 사용자와 컴퓨터 하드웨어 간 인터페이스를 담당하는 프로그램
• 사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원하는 소프트웨어
• 운영체제 현행 시스템 분석 시 고려 사항
  • 품질 측면 : 신뢰도, 성능
  • 지원 측면 : 기술 지원, 주변 기기, 구축 비용

 

 

OSI 7계층(Open Systems Interconnection 7 Layer)

1. 물리 계층(Physical Layer)
   • 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환
   • 프로토콜 : RS-232C
   • 전송 단위 : 비트(Bit)
2. 데이터 링크 계층(Data Link Layer)
   • 인접 시스템 간 데이터 전송, 전송 오류 제어
   • 동기화, 흐름 제어 등의 전송 기능 제공
   • 오류 검출 / 재전송 등의 기능 제공
   • 프로토콜 : 이더넷
   • 전송 단위 : 프레임(Frame)
3. 네트워크 계층(Network Layer)
   • 단말 간 데이터 전송을 위한 최적화된 경로 제공
   • 프로토콜 : IP, ICMP
   • 전송 단위 : 패킷(Packet)
4. 전송 계층(Transport Layer)
   • 신뢰성 있는 통신 보장
   • 데이터 분할과 재조립, 흐름 제어, 오류 제어, 혼잡제어 등을 담당
   • 프로토콜 : TCP, UDP
   • 전송 단위 : 세그먼트(Segment)
5. 세션 계층(Session Layer)
   • 연결 접속 및 동기 제어
   • 프로토콜 : SSH, TLS
   • 전송 단위 : 데이터(Data)
6. 표현 계층(Presentation Layer)
   • 데이터 형식 설정과 부호 교환, 암/복호화
   • 프로토콜 : JPEG, MPEG
   • 전송 단위 : 데이터(Data)
7. 응용 계층(Application Layer)
   • 사용자와 네트워크 간 응용 서비스 연결, 데이터 생성
   • 프로토콜 : HTTP, FTP
   • 전송 단위 : 데이터(Data)

 

 

데이터베이스 관리 시스템(DBMS; DataBase Management System)

• 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해주는 소프트웨어
• 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템
• 고려사항 : 
  • 성능 측면 : 가용성, 성능, 상호 호환성
  • 지원 측면 : 기술 지원, 구축 비용

 

미들웨어(Middleware)

• 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어
• 운영체제와 소프트웨어 애플리케이션 사이 위치

 

 

웹 애플리케이션 서버(WAS; Web Application Server)

• 서버 계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버
• 고려사항 : 가용성, 성능, 기술 지원, 구축 비용

 

 

요구사항

• 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약 조건
• 유형 
  • 기능 요구사항(Function Requirements) : 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항
  • 비기능 요구사항(Non-Fuction Requirements) : 품질이나 제약사항과 관련된 요구사항
  • 사용자 요구사항(User Requirements) : 사용자 관점에서 본 시스템에 제공해야 할 요구사항
  • 시스템 요구사항(System Requirements) : 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

 

 

요구사항 개발 프로세스

• 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동
• 단계 : 도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 확인(Validation)
  • 요구사항 도출(Requirement Elicitation, 요구사항 수집)
    • 시스템, 사용자, 개발자 등 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정
    • 소프트웨어 개발 생명 주기(SDLC)동안 지속적으로 반복
    • 기법
      • 청취와 인터뷰
      • 설문
      • 브레인스토밍(Brain Storming) : 3인 이상의 자유롭게 의견을 교환하면서 독창적인 아이디어를 도출해 내는 방법
      • 워크샵
      • 프로토타이핑(Prototyping) : 프로토타입을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출하는 작업
      • 유스케이스(Usecase) : 사용자의 요구사항을 기능 단위로 표현하는 것
  • 요구사항 분석(Requirement Analysis)
    • 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
    • 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
    • 도구
      • 자료 흐름도(DFD; Data Flow Diagram) : 자료의 흐름 및 변환과 기능을 도형 중심으로 기술하는 방법
      • 자료 사전(DD; Data Dictionary) : 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
  • 요구사항 명세(Requirement Specification)
    
    • 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것
    • 기능 요구사항을 빠짐없이 기술
    • 비기능 요구사항은 필요한 것만 기술
  • 요구사항 확인(Requirement Vaildation, 요구사항 검증)
    • 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동

 

 

요구 공학(Requirements Engineering)

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