[정보처리기사 실기] 1장 요구사항 확인 - 현행 시스템 분석

현행 시스템 분석

---

현행 시스템 파악

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

소프트웨어 및 하드웨어, 네트워크의 구성은 어떤지 파악 등...

 

현행 시스템 파악 절차

1단계 

• 시스템 구성 현황 파악
• 시스템 기능 파악
• 시스템 인터페이스 파악

2단계

• 아키텍처 파악
• SW 구성 파악

3단계

• 시스템 하드웨어 현황 파악
• 네트워크 구성 파악

 

(1) 1 단계

• 구성 현황 파악 : 처리 업무와 지원 업무로 구분 
  • 업무에 속한 시스템의 명칭, 주요 기능 명시, 모든 시스템 현황 파악이 가능
• 기능 현황 파악 : 단위 업무 시스템이 현재 제공하는 기능
  • 주요 기능과 하부 기능으로 계층형
• 인터페이스 현황 파악 :다른 시스템과 주고 받는 데이터의 종류, 데이터 형식, 프로토콜, 연계 유형, 주기 파악
  • 데이터 형식을 주고받는지, 통신규약은 어떻게 되는데, 연계 유형은 무엇인지 표시

(2) 2 단계

• 아키텍처 구성 파악 : 계층별로 어떤 기술 요소들을 사용하고 있는지 최상위 수준에서 파악
  • 아키텍처가 다른 경우에는 가장 핵심이 되는 기간 업무 처리 시스템 기준 파악
• 소프트웨어 구성 파악 : 제품명, 용도, 라이선스 적용 방식, 라이선스 수 파악
  • 라이선스 적용 방식의 기준과 보유한 라이선스 수량 파악 중요

 

(3) 3 단계

• 하드웨어 구성 파악 : 위치, 주요 사양과 수량, 이중화 구현 여부 파악
  • 서비스 기간, 장애 대응 정책에 따라 필요성 여부 결정, 인프라 구축 기술 난이도 및 비용 증가 가능성이 존재
• 네트워크 구성 파악 : 어떤 네트워크 장비를 사용
  • 서버의 위치, 서버 간의 네트워크 연결 방식 파악

 

소프트웨어 아키텍처

 

(1) 소프트웨어 아키텍처

여러 가지 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나느 특성, 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체

 

(2) 프레임워크

소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 관계를 제공하는 기술 표준

 

(2) -1 구성요소

• 아키텍처 명세서 : 기록하기 위한 산출물, 관심을 관점에 맞춰 작성한 뷰
  • 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등
• 이해 관계자 : 개발에 관련된 사람과 조직 
  • 고객, 최종 사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등
• 관심사 : 서로 다른 의견과 목표
  • 사용자 : 기능, 신뢰, 보안, 사용성, 품질
  • 유지보수자 : 용이성
  • 개발자 : 비용과 인력
• 관점 : 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식, 다른 역할이나 책임으로 산출물에 대해 보고 싶은 관점
• 뷰 : 관심사들의 집합, 전체 시스템, 하나 이상의 뷰로 구성
• 근거 : 결정 근거, 회의 결과 및 보고
• 목표 : 목적, 사용, 운영, 방법
• 환경 : 개발에 외부 요인 또는 시스템에 영향을 주는 요인
• 시스템 : 어플리케이션, 서브 시스템, 시스템의 집합 등 구현체

(3) 4 + 1 뷰

요구 사항을 정리 해놓은 시나리오 -> 소프트웨어적 접근 방법이다.

 

1 = 유스 케이스

4 = 논리, 구현, 프로세스, 배포 뷰

 

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

(4) 아키텍처 패턴

설계 시 참조할 수 있는 전형적인 패턴, 일반화되고 재사용 가능한 솔루션

 

(4) - 1 필요성

상황별 패턴을 수립, 의사소통을 통해 요구사항 만족, 생산성과 품질 확보, 개발 시간 단축, 고품질 생산, 안정적 수행, 예측 가능

 

(4) - 2 유형

• 계층화 패턴 : 계층으로 구분, 특정한 수준 추상화 제공, 다음 상위 계층 서비스 제공, 마주보는 두 개의 계층에서만 상호 작용 발생
• 클라이언트 - 서버 패턴 : 하나의 서버와 다클라, 서비스 요청시 서비스 제공 서버는 항상 대기
• 파이프 - 필터 패턴 : 데이터 스트림 생성하고 처리, 데이터 받아 처리 후 결과를 다음으로 넘겨줌 반복
  • 재사용성 및 확장성 용이
• 브로커 패턴 : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 상호 작용이 가능한 패턴
  • 통신을 조정하는 역할
  • 클라이언트가 브로커에 서비스를 요청하면 브로커는 자신의 레지스트리에 있는 서비스로 리다이렉션
• 모델- 뷰 - 컨트롤러 패턴 : MVC, 서로 영향 X 개발 작업 수행 가능, 효율적인 재사용, 대화형 어플리케이션
  • 모델 : 핵심 기능과 데이터 보관
  • 뷰 : 사용자에게 정보 표시
  • 컨트롤러 : 요청을 입력받아 처리

 

(5) 비용 평가 모델

접근법이 품질 속성에 미치는 영향을 판단하고 적합성을 평가

 

(5) - 1 종류

• SAAM : 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능한 모델
• ATAM : SAAM을 계승해 발전, 아키텍처 품질 속성을 만족시키는지 판단 및 이해 상충관계까지 평가
• CBAM : ATAM에서 부족한 경제성 평가를 보강, 경제적 의사결정에 대한 요구 충족
• ADR : 응집도 평가하는 모델
• ARID : ATAM + ADR, 특정 부분에 대한 품질요소 집중하는 비용 평가

 

디자인 패턴

- 공통으로 발생하는 문제에 대해 자주 쓰이는 설계법을 정리한 패턴 | 효율성과 유지보수성, 운용성이 높아지며, 최적화에 도움

 

(1) 구성요소

• 패턴의 이름, 문제 및 배경, 솔루션, 사례, 결과, 샘플 코드

(2) 유형

• 목적
  • 생성 : 인스턴스, 클래스, 객체 등 구조화, 캡슐화 수행하는 패턴
  • 구조 : 클래스나 객체의 조합을 다루는 패턴
  • 행위 : 상호 작용하는 방법과 역할 분담을 다루는 패턴
• 범위
  • 클래스 : 클래스 간 관련성, 컴파일 타입에 정적으로 결정
  • 객체 : 객체 간 관련성 다룸, 런타임에 동적으로 결정

(3) 종류

• 생성 패턴 
  • Builder : 생성과 표기를 분리해 복잡한 객체 생성
  • Prototype : 기존 객체를 복제하므로써 객체 생성
  • Factory Method : 오버라이딩하여 생성할 객체의 클래스를 국한하지 않고 객체 생성
  • Abstract Factory : 동일한 주제의 다른 팩토리를 묶음
  • Singleton : 한 클래스에 한 객체만 존재하도록 제한
• 구조 패턴
  • Bridge : 독립적, 추상화 된 부분까지 변경해야 하는 경우 활용
  • Decorator : 객체의 결합을 통해 기능을 동적으로 유연하게 확장
  • Facade : 통합된 인터페이스 제공
  • Flyweight : 여러 개의 가상 인스턴스를 제공해 메모리 절감
  • Proxy : 특정 객체로의 접근을 제어하기 위한 용도로 사용
  • Composite : 복합 객체와 단일 객체를 동일하게 취급
  • Adapter : 호환되지 않는 클래스들을 함께 이용할 수 있게 타 인터페이스 오버로딩
• 행위 패턴
  • Mediator : 상호 작용의 유연한 변경을 지원, 중재자
  • Interpreter : 문법 자체를 캡슐화
  • Iterator : 내부구조 노출 X, 복잡 객체의 원소를 순차적으로 접근 가능하게 해주는 패턴
  • Template Method : 상위 변경하지 않고 서브 클래스로 작업의 일부 변경
  • Observer : 일대다 의존, 상태에 따라 다른 객체의 상태 연동
  • State : 최소화와 편의성, 상태에 따라 변경
  • Visitor : 기능만 따로 추가하거나 확장할 때 사용
  • Command : 요구 사항을 객체로 캡슐화
  • Strategy : 행위를 클래스로 캡슐화해 동적으로 자유로이 변경
  • Memento : 객체를 이전 상태로 복구시켜야 하는 경우 Undo
  • Chain of Responsibility : 한 요청을 2개 이상의 객체에서 처리

 

현행 시스템 분석서 작성 및 검토

 

(1) 현행 시스템 관련 자료 수집

- 수집 자료의 톡성에 따라 3개의 팀 구성

 

팀 구성

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

 

(2) 수집 자료의 분석

- 정보를 취합, 정제하고 중복이거나 유효하지 않은 정보 삭제 | 불 명확한 부분은 체크 후 분석 및 설계를 통해 구체적 조사 | 이슈와 문제점을 파악하는 단계이다.

 

분석 대상

• 정보 시스템 구성 기능 및 인터페이스 자료 수집팀
  • 정보 시스템 구성 기능 구성도
    • 정보시스템의 구분, 정보시스템 명, 주요 기능, 정보시스템의 기능 구성
  • 인터페이스 현황
    • 송수신 시스템, 연계 방식 및 연계 주기, 연동 데이터 형식, 주요 연동 데이터
• 현행 시스템 아키텍처 및 소프트웨어 자료 수집팀
  • 현행 시스템 아키텍처 구성도 
    • 운영체제의 종류, 적용 프레임워크, 계층별 적용 기술, 데ㅣ터 연동 방식, 데이터 저장소, 외부시스템 연계 방식
  • 소프트웨어 구성도
    • 단위 시스템별 필요 소프트웨어의 제품명 및 용도, 라이선스 적용 방식, 라이선스 수
  • 하드웨어 및 네트워크 자료 수집팀
    • 하드웨어 구성도
      • 단위 시스템별 서버 제품명 및 용도, CPU/메모리/하드 용량 및 수량, 이중화 적용 여부
    • 네트워크 구성도
      • 장비 용도 및 제품명, 수량 및 주요 사양, 위치 및 연동 프로토콜

 

(3) 결과 기반 산출물 작성

- 각 결과를 기반으로 산출물을 작성하고, 이슈나 문제점을 상세하게 포함해 작성한다.

 

(4) 산출물 검토 수행

- 팀별로 작성한 산출물을 상호 검토해 의견 제시, 의견 반영 및 수정으로 최종 완성

 

---

개발 기술 환경 정의

 

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

 

(1) 운영체제 현행 분석

- 운영체제는 사용자와 하드웨어 간의 인터페이스를 담당하는 프로그램, 분석시 품질과 지원 측면에서 고려한다

 

고려사항

• 품질 측면
  • 신뢰도 : 장애 발생 가능성, 버그로 인한 재가동 여부
  • 성능 : 대량 배치 작업 처리, 지원 가능 메모리 크기
• 지원 측면
  • 기술 지원 : 안정 기술, 오픈 소스 여부
  • 주변 기기 : 설치가능 하드, 주변 기기 지원
  • 구축 비용 : 지원 가능 비용, 라이선스 정책 및 비용, 유지 관리 비용

종류

• PC
  • Windows, Unix, Linux
• Mobile
  • Android, IOS

 

(2) 네트워크 현행 시스템 분석

 

- 네트워크 : 컴퓨터 장치의 노드 간 연결을 사용해 서로 데이터를 교환하는 기술, 데이터 링크는유 무선 매체를 통해 확립

 

- OSI 7계층 : 여러 충돌 문제를 완하하기 위해 국제 표준화 기구(ISO)

- 물리 - 데이터 링크 - 네트워크 - 전송 - 세션 - 표현 - 응용

 

• 물리 계층 : 0과 1 비트 정보를 회선에 보내기 위한 전기적 신호 변환 : RS-232C : 비트 단위
• 데이터 링크 계층 : 인접 시스템 데이터 전공, 전송 오류 제어, 동기화 전송 기능 제공, 오류 검출 및 재전송 기능 제공 : 이더넷 : 프레임 단위
• 네트워크 계층 : 단말 간 데이터 전송 최적화 경로 : IP, ICMP : 패킷 단위
• 전송 계층 : 신뢰성 통신, 데이터 분할과 조립, 제어 담당 : TCP, UDP : 세그먼트 단위
• 세션 계층 : 연결 및 동기 제어 : SSH, TLS : 데이터 단위
• 표현 계층 : 데이터 형식 설정과 부호 교환, 암복호화 : JPEG, MPEG : 데이터 단위
• 응용 계층 : 사용자와 네트워크 간 응용 서비스 연결, 데이터 생성 : HTTP, FTP : 데이터 단위

네트워크 시스템 분석

- 구성도를 통해 분석, 서버 위치, 연결 방식을 파악 가능, 백본망, 라우터, 스위치, 게이트웨이, 방화벽 분석, 물리 관계와 취약성 분석 및 대응후 추적이 가능하다.

 

(3) DBMS 현행 시스템 분석

 

- DBMS : 데이터의 집합을 만들고, 저장 및 관리 가능 

 

기능

• 중복 제어 : 중복 데이터 여러 위치에 중복 저장 방지
• 접근 통제 : 권한에 따라 데이터 접근 제어
• 인터페이스 제공 : SQL, CLI, GUI 등 제공
• 관계 표현 : 서로 다른 데이터 간 다양한 관계 표현 기능 제공
• 샤딩/파티셔닝 : 구조 최적화를 위해 작은 다위로 나누는 기능
• 무결성 제약 조건 : 무결성에 관한 제약 조건을 정의 검사하는 기능 제공
• 백업 및 회복 : 데이터베이스  장애 발생시 데이터 보존 기능 제공

 

고려 사항

• 성능 측면 
  • 가용성 : 장기간 시스템을 운영할 대 장애 발생 가능성, 백업 및 복구 편의성, 이중화 및 복제 지원 여부
  • 성능 : 대규모 데이터 처리 성능, 대량 거래 처리 성능, 다양한 튜닝 옵션 지원 여부, 비용 기반 최적화 지원 및 설정의 최소화 지원 여부
  • 상호 호환성 : 가능 운영체제, JDBC, ODBC
• 지원 측면
  • 기술 지원 : 업체의 안정적인 기술 지원 여부, 다수의 사용자 간의 정보 공유 여부, 오픈 소스 여부
  • 구축 비용 : 라이선스 정책 및 비용, 유지 관리 비용

 

(4) 미들웨어 현향 시스템 분석

 

- 미들웨어 개념 : 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경에 원만한 통신이 이뤄지도록 제어, OS와 SW 사이에 존재, 대표적으로 WAS가 존재

 

Web Application Server : WAS

- 서버는 서버 계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 수행, 이기종 시스템과의 연동 지원

 

- 시스템 분석 : 가용성 성능 기술지원 구축비용 분석

 

고려 사항

• 성능 측면
  • 가용성 : 장기간 시스템 운영시 장애 발생, 안정적인 트랜잭션 수행, 패치 설치 위한 재기동 기능 지원 여부, WAS 이중화 지원 여부
  • 성능 : 대규모 처리 성능, 다양한 성정 옵션 지원 여부, 가비지 컬렉션 
• 지원 측면 
  • 기술 지원 : 공급 벤더의 안정적인 기술 지원 여부, 다수이 정보 공유, 오픈 소스 여부
  • 구축 비용 : 라이선스 정책 비용, 유지 및 관리 비용, 총 소유 비용

(5) 오픈 소스 고려 사항

- 라이선스 종류, 사용자 수, 기술의 지속 가능성 고려

 

개발 기술 환경 요구사항 파악

 

(1) 기술 환경 정의 위한 자료 수집

- 수집 자료 목록 및 조사 설정

 

(2) 조사 자료 분석 및 개발 기술 환경 설정

- 운영체제, 데이터베이스, WAS 결정, 항목별 고려 사항 반영

 

(3) 요구 사항 정의서, 목쵸 시스템 구성 반영 및 검토

- 시스템 용량 산정 결과 요구 사항 정의, 목표 소프트웨어 구성도, 목표 하드웨어 구성도 반영

- 산출물을 상호 검토하여 의견을 제시 -> 수정하고 최종 완료