Study/정보처리기사

정보처리기사 실기 2강 - 요구사항 확인 ②

상맹 2021. 9. 15. 00:57
반응형

1. 현행 시스템 파악

 현행 시스템이 어떤 하위 시스템으로 구성 되어있는지, 제공 기능 및 연계 정보, 어떤 기술 요소를 사용하는지 파악

 

 1.1 현행 시스템 파악 절차

   1단계 : 구성 / 기능 / 인터페이스 파악 → 2단계 : 아키텍쳐, 소프트웨어 구성 파악 → 3단계 : 하드웨어, 네트워크 구성 파악

 

 1.2 소프트웨어 아키텍처

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

   시스템의 구조나 구조체

   - 소프트웨어 아키텍처 프레임워크 : 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준이다.

   - 구성요소 : 아키텍처 명세서, 이해관계자, 관심사, 관점, 뷰, 근거, 목표, 환경, 시스템

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

    ① 유스케이스 뷰 : 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용

    ② 논리 뷰 : 시스템의 기능적인 요구사항이 어떻게 되는지 설명해준다.

    ③ 프로세스 뷰 : 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현

    ④ 구현 뷰 : 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰

    ⑤ 배포 뷰 : 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여준다.

 

  1.3 소프트웨어 아키텍처 패턴

    소프트웨어을 설계할 떄 참조할 수 있는 전형적인 해결 방식

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

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

    ② 클라이언트-패턴 : 하나의 서버와 다수의 클라이언트로 구성하는 패턴

    ③ 파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴

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

    ⑤ 모델-뷰-컨트롤러 패턴

      - 모델: 핵심 기능 과 데이터 보관

      - 뷰 : 사용자에게 정보 표시(하나 이상의 뷰가 정의될 수 있음)

      - 컨트롤러 : 사용자로부터 요청을 입력받아 처리

  

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

    - SAAM : 변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능 

    - ATAM : 아키텍처 품질 속성을 만족시키는 판단 및 품질 속성들의 이해 상충관계까지 평가

    - CBAM : ATAM 바탕의 시스템 아키텍처 분석 중심 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델

    - ADR : 소프트웨어 아키텍처 구성요소 간 응집도를 평가

    - ARID : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델

   

   1.5 디자인 패턴

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

    - 디자인 패턴 구성요소 : 패턴 이름, 문제 및 배경, 솔루션, 사례, 결과, 샘플 코드

    - 디자인 패턴 유형 

     목적 : 생성, 구조 행위

     범위 : 클래스, 객체

    - 디자인 패턴 종류

     생성 패턴 : 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

 

2. 개발 기술 환경 정의

 2.1 개발 기술 환경 현행 시스템 분석

  ① 운영체제 현행 시스템 분석

  ② 네트워크 현행 시스템 분석 : OSI 7계층(물리, 데이터링크, 네트워크, 전송, 세션, 표현, 응용)

  ③ DBMS 현행 시스템 분석 : 성능 측면(가용성, 성능, 상호 호환성) , 지원 측면(기술 지원, 구축 비용)

  ④ 미들웨어 현행 시스템 분석 : WAS(Web Application Server)

 

3. 요구사항

 3.1 요구공학

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

 - 요구사항의 분류 

  기능적 요구사항 : 시스템이 제공하는 기능, 서비스에 대한 요구사항

  비기능적 요구사항 : 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구 사항

 

 3.2 요구사항 프로세스

도출 분석 명세 확인
- 요구사항 소스
- 도출기법
- 요구사항 분류
- 개념 모델링
- 기술 구조 설계 및 요구사항 할당
- 요구사항 협상
- 시스템 정의서
- 시스템 요구사항 명세서
- 소프트웨어 요구사항 명세서
- 검토
- 프로토타이핑
- 모델 검증
- 인수테스트

 - 요구사항 도출 단계 주요 기법 : 인터뷰, 브레인 스토밍, 델파이 기법, 롤 플레잉, 워크숍, 설문조사

 - 요구사항 분석 단계 주요 기법 : 자료 흐름 지향 분석, 객체지향 분석

 - 요구사항 명세 단계 주요 기법 : 비정형 명세 기법, 정형 명세 기법

 - 요구사항 확인 및 검증 단계 주요 기법 : 요구사항 검토, 정형 기술 검토(동료 검토, 워크 스루, 인스펙션), 프로토타이핑 활용, 모델 검증, 

                                                               테스트 케이스 및 테스트를 통한 확인, CASE 도구 활용 검증, 베이스라인, 요구사항 추적표

 - 상세 정형 기술 검토 법 : 관리 리뷰, 기술 리뷰, 인스펙션, 워크스루, 감사

 - 요구사항 분석 기술 : 청취, 인터뷰와 질문, 분석, 중재, 관찰, 작성, 조직, 모델 작성

 - 요구사항 명세 원리 및 검증 항목 :명확성, 완전성, 검증 가능성, 일관성, 수정 용이성, 추적 가능성, 개발 후 이용성

 

 

 

반응형