[실기] 제 1과목 - 요구사항 확인 요점 정리

현행 시스템 분석

   - 현행 시스템의 구성, 기능, 인터페이스 현황 파악 (현행 시스템 분석서, 기능 정의서, 인터페이스 현황 정의서)

   - 현행 시스템의 아키텍쳐 및 소프트웨어 구성 현황 파악 (현행 시스템 아키텍쳐 구성도, 소프트웨어 구성도)

   - 현행 시스템의 하드웨어 및 네트워크 구성 현황 파악 (현행 하드웨어 구성도, 네트워크 구성도)

 

목표 시스템 아키텍쳐 선정

   - 목표 시스템의 소프트웨어 및 아키텍쳐 정의, 아키텍쳐 평가 (소프트웨어 아키텍쳐 정의서, 시스템 아키텍쳐 정의서, 아키텍쳐 평가 결과서)

 

목표 시스템 개발 표준 정의

   - 목표 시스템 모델링 표준 정의, 프로그램 표준 정의, 개발환경 표준 정의 (모델링 표준 정의서, 프로그램 표준 정의서, 개발환경 표준 정의서)

 

IEEE 1471 - 유연성과 확장성을 가진 SW 중심의 시스템 아키텍쳐를 기술하기 위한 개념적 프레임워크 표준 모델 (표준성, 독립성, 범용성, 의사소통, 가이드라인)

 

4+1 View 모델 - 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적 관점 (Use-Case, Logical, Implementation, Process, Deployment)

 

품질 속성 시나리오 - 요구사항과 관련된 품질 속성을 도출하고 구체적으로 명세하며, 시스템에 대한 자극과 반응을 측정해 요구사항 도출 (자극의 원천, 자극, 대상체, 환경, 응답, 응답 측정)

 

소프트웨어 아키텍쳐 스타일

   - 저장소 구조 : Repository Architecture, 서브 시스템, 단일 중앙 저장소, 독립적

   - MVC : Model, View, Controller, 데이터 관리, UI 관리, 상호작용 정의

   - 클라이언트/서버 구조 : 서버는 클라이언트라고 불리는 서브 시스템에 서비스를 제공

   - Data Flow : 파이프 필터 구조, 서브 시스템이 입력 데이터를 받아 다른 시스템에 보내는 작업의 반복

   - 계층 구조 : 각 서브 시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브 시스템이 사용

 

요구사항 추출 기법 - 인터뷰, 설문, 워크샵, 브레인 스토밍, 스토리 보드, 프로토 타이핑, 롤플레잉

 

IEEE std.830 좋은 요구사항의 특징 - 정확성, 명확성, 완전성, 검증가능성, 우선 순위 포함, 일관성, 수정용이성, 추적가능성, 개발 후 이용성, 이해용이성

 

IEEE std.1012 요구사항 명세서 주의 항목 - 이해성, 상호성, 기능정의, 제약조건, 테스트 기준, 품질 측정

 

요구 추적 매트릭스 - Project 정보, ID, Associated ID, 기술적 가정, 우선 순위, 기능적 요구, 상태, 아키텍쳐/설계문서, 기술적 사양, System Component, SW Module, Test Case Number, Verification, Additional Coment

 

스크럼의 제품 백로그 - ID, 이름, 중요도, 추정치, 데모 방법, 참고

 

UML - Unified Modeling Language, 객체 지향 모델링 언어 (뷰, 다이어그램, 모델요소, 일반적 체계)

   - 요구사항

         > Use Case (사용자 입장에서 본 시스템의 행동, 시스템의 기능적인 요구 정의)

   - 정적 모델링

         > Class (시스템 내 클래스의 정적 구조 표현, 클래스는 객체들의 집합으로 속성과 동작으로 구성)

         > Object (클래스의 여러 Object 인스턴스를 나타내는 대신 실제 클래스 사용, 관계 있는 모든 인스턴스 표현)

         > Component (코드의 물리적 구조 표현, 논리적 클래스나 클래스 자신의 구현에 대한 정보 포함)

         > Deployment (시스템 HW, SW 간의 물리적 구조 표현, 실질적인 컴퓨터와 Drive 간의 관계 표현)

   - 동적 모델링

         > Sequence (객체 간의 상호작용을 시간의 흐름에 따라 메시지로 표현, Object 사이에 메세지를 보내는 시간, 순서를 보여주는데 사용)

         > Collaboration (Object 간의 연관성 표현, 내용이 중요한 경우 사용)

         > Activity (Object의 행위를 순서적 흐름으로 표시)

         > State Transition (객체가 가질 수 있는 모든 가능한 상태와 상태 간 전이 표현)

 

디자인 패턴 - SW 설계의 공통된 문제에 대한 표준적인 해법, 패턴 이름, 문제, 해법, 결과

   - 생성 패턴 : 객체의 생성 방식 결정, 클래스의 정의, 객체 생성 방식의 구조화, 캡슐화 지향

         - 클래스

               > Factory Method (인스턴스화 될 객체의 서브 클래스)

         - 객체

               > Abstract Factory (제품 객체 군)

               > Builder (복합 객체 생성)

               > Proto Type (인스턴스화 될 객체 클래스)

               > Singleton (인스턴스가 하나일 때)

   - 구조 패턴 : 객체를 조직화하는 일반적인 방법, 별도의 클래스를 통합하는데 유용, 객체 구성에 유동성, 확장성 추가 기능

         - 클래스

               > Adaptor (객체 인터페이스)

         - 객체

               > Bridge (객체 구현)

               > Composite (객체의 합성과 구조)

               > Decorator (서브클래싱 없이 객체의 책임성)

               > Facade (서브 시스템에 대한 인터페이스)

               > Proxy (객체 접근 방법)

   - 행위 패턴 : 객체의 행위를 조직화 관리, 연합, 객체나 클래스의 연동에 대한 유형 제시, 복잡한 제어 흐름 결정에 사용

         - 클래스

               > Interpreter (언어의 문법과 해석 방법)

               > Templete Method (알고리즘 단계)

         - 객체

               > Chain of Responsibility (요청 처리 객체)

               > Command (요청 처리 시점과 방법)

               > Iterator (집합 객체 요소 접근 / 순회 방법)

               > Mediator (객체 상호 작용)

               > Memento (객체 정보 외부 저장)

               > Observer (종속 객체 상태 변경)

               > State (객체 상태)

               > Strategy (알고리즘)

               > Visitor (클래스 변경 없이 객체에 적용할 수 있는 오퍼레이션)