[정보처리기사 실기] 2. 현행 시스템 분석

 

1. 현행 시스템 파악

• 현행 시스템 파악 : 현행 시스템의 SW 및 HW, 네트워크 구성 및 제공 기능 등을 파악하는 활동
• 현행 시스템 절차 
  1. 구성/기능/인터페이스 파악
  2. 아키텍처 및 소프트웨어 구성 파악
  3. 시스템 하드웨어 및 네트워크 구성 파악
• 소프트웨어 아키텍처 : 소프트웨어의 구성요소와 외부 특성, 관계를 표현하는 구조
• 소프트웨어 아키텍처 프레임워크 : 소프트웨어 시스템에서 아키텍처가 표현해야 하는 내용을 제공하는 기술 표준
• 소프트웨어 아키텍처 4+1 뷰 : 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 접근 방법
• 소프트웨어 아키텍처 4+1 뷰 구성요소
  • Usecase View : 다른 뷰를 검증하는 데 사용
  • Logical View : 기능적 요구사항이 어떻게 제공되는지 설명
  • Process View : 시스템의 비기능적인 속성 표현
  • Implementation View : 정적인 소프트웨어 모듈의 구성
  • Deployment View : 물리적인 아키텍처에서 컴포넌트의 배치 매핑
• 소프트웨어 아키텍처 패턴 : 소프트웨어 설계 시 참조할 수 있는 해결 방식
• 소프트웨어 아키텍처 패턴 유형
  • Layered Pattern : 하위 모듈들은 특정 수준의 추상화를 제공하고, 각 계층은 다음 상위 계층에 서비스를 제공
  • Client-Server Pattern : 클라이언트를 통해 서버에 서비스를 요청하면 서버는 클라이언트에 서비스 제공
  • Pipe-Filter Pattern : 데이터 스트림을 생성하고 처리하는 단방향 패턴. 데이터 변환 오버헤드가 발생
  • Broker Pattern : 클라이언트가 브로커에 서비스를 요청하면 브로커는 적합한 서비스로 리다이렉션
  • Model View Controller Pattern : 3개의 서브 시스템으로 구조화하여 서로 영향을 받지 않고 개발 작업 수행
  • Master-Slave Pattern : 연산, 통신, 조정을 책임지는 마스터와 제어되고 동기화 되는 슬레이브로 구성된 실시간 시스템 패턴
• 소프트웨어 아키텍처 평가 모델 : 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성 평가
• 소프트웨어 아키첵처 평가 모델 종류
  • SAAM : 변경 용이성과 기능성에 집중
  • ATAM : 아키텍처 품질 속성을 만족시키는지 판단
  • CBAM : ATAM 바탕에서 경제성 평가 보강
  • ADR : 응집도 평가
  • ARID : 전체 아키텍처가 아닌 특정 부분의 품질 요소에 집중
• 디자인 패턴(GoF) : 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법
• 디자인 패턴 구성요소 : 패턴의 이름, 문제 및 배경, 솔루션, 사례, 결과, 샘플 코드
• 디자인 패턴 유형
  • 생성 패턴 : 객체 인스턴스 생성에 관여
    • Builder : 복잡한 인스턴스를 조립하여 만드는 구조
    • Prototype : 원형을 생성 후 복사하여 필요한 부분만 수정 후 사용
    • Factory Method : 상위 클래스에서 객체 생성 인터페이스를 정의하고 하위 클래스에서 인스턴스 생성
    • Abstact Factory(Kit) : 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공
    • Singletone : 객체를 하나만 생성하여 생성된 객체를 어디에서든지 참조
  • 구조 패턴 : 클래스나 객체의 조합
    • Bridge : 추상화된 부분과 실제 구현 부분을 독립적으로 확장
    • Decorator : 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴
    • Facade : 단순한 인터페이스를 제공하여 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 패턴
    • Flyweight : 본질적인 요소를 클래스 화하여 공유함으로써 메모리를 절약
    • Proxy : 실재 객체에 대한 대리 객체
    • Composite : 객체 관계를 트리 구조로 구성하여 부분-전체 계층을 표현
    • Adaptor : 기존에 생성된 클래스를 재사용할 수 있도록 하는 인터페이스 생성
  • 행위 패턴 : 클래스나 객체들이 상호작용하는 방법과 역할 분담
    • Mediator : 중간에 중재자를 두고 중재자에게 요구하여 통신의 빈도수를 줄여 객체 지향의 목표를 달성
    • Interpreter : 분리된 구문의 해석을 맡는 클래스를 각각 작성
    • Iterator (Cursor): 집합체 안에 있는 모든 항목에 반복자를 사용하여 접근
    • Template Method : 작업의 일부분을 캡슐화하여 전체 구조는 바꾸지 않고 특정 단계의 내용을 바꾸는 패턴
    • Observer : 한 객체의 상태가 바뀌면 의존하는 다른 객체들이 자동으로 갱신
    • State : 객체 상태를 캡슐화하여 클래스화
    • Visitor : 처리 기느을 분리 후 각 클래스를 돌아다니며 특정 작업을 수행
    • Command : 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행
    • Strategy : 행위를 클래스로 캡슐화해 동적으로 행위를 바꿀 수 있는 디자인 패턴
    • Memento : 객체의 정보를 저장할 필요가 있을 때 적용하는 디자인 패턴
    • Chain of Responsibility : 한 요청을 2개 이상의 객체에서 처리

 

2. 요구사항

• 요구공학 : 사용자의 요구가 반영된 시스템을 개발하기 위한 구조화된 활동
• 요구공학의 목적 : 요구사항 누락 방지 및 이해 오류로 인한 불필요한 비용을 절감하고 요구사항 변경 추적 가능
• 요구사항 분류
  • 기능적 요구사항
    • 개념 : 시스템이 제공하는 기능, 서비스
    • 도출 방법 : 특정 입력, 상황에 대해 시스템이 어떻게 동작해야 하는지 기술
    • 특성 : 기능성, 완정성, 일관성
  • 비기능적 요구사항
    • 개념 : 시스템 구축에 대한 제약사항, 기능 이외의 사항
    • 도출 방법 : 품질 속성, 제한 조건에 관한 기술
    • 특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항
• 요구공학 프로세스
  1. 요구사항 개발 단계
     1. 요구사항 도출 단계 : 인터뷰, 브레인스토밍, 델파이 기법, 롤 플레잉, 워크숍, 설문 조사, 프로토타입
     2. 요구사항 분석 단계 : 데이터 흐름도(DFD), 자료 사전(DD), UML
     3. 요구사항 명세 단계 : 비정형 명세기법, 정형 명세기법 -> 요구사항 명세서 산출
     4. 요구사항 확인 및 검증 단계 : 동료 검토, 워크 스루, 인스펙션
  2. 요구사항 관리 단계
     1. 요구사항 협상 : 우선순위 설정, 시뮬레이션
     2. 요구사항 기준선 설정 : 공식 회의, 형상 관리
     3. 요구사항 변경 관리 : 형상 통제 위원회, 영향도 분석
     4. 요구사항 확인 및 검증 : 확인 및 검증
• 델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한기법
• 워크숍 : 단기간의 집중적인 노력을 통해 전문적인 정보 획득, 팀 협력과 사전 준비 요구
• 비정형 명세기법 : 자연어 기반으로 사용자 요구 서술
• 정형 명세기법 : Z-스키마, Petry, Nets, 상태 차트를 활용해 사용자 요구 표현 
• 워크 스루 : 검토 자료를 회의 전에 배포해서 사전 검토 후 짧은 시간 동안 회의를 진행
• 인스펙션 : 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식 검토 방법
• 형상 관리 : 소프트웨어 생명주기 동안 발생하는 변경 사항을 체계적으로 관리하여 소프트웨어 품질보증 향상