현행 시스템 파악
시스템 구성 파악
: 현행 시스템의 구성은 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술한다.
시스템 기능 파악
: 현행 시스템의 기능은 단위 업무 시스템이 현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시한다.
시스템 인터페이스 파악
: 현행 시스템의 인터페이스에는 단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시한다.
- 데이터를 어떤 형식으로 주고받는지, 통신규약은 무엇을 사용하는지, 연계 유형은 무엇인지 등을 고려해야 한다.
아키텍처 구성 파악
: 현행 시스템의 아키텍처 구성은 기간 업무 수행에 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성한다.
소프트웨어 구성 파악
: 소프트웨어 구성에는 단위 업무 시스템별로 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시한다.
하드웨어 구성 파악
: 하드웨어 구성에는 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 이중화의 적용 여부를 명시한다.
네트워크 구성 파악
: 네트워크 구성은 업무 시스템들의 네트워크 구성을 파악할 수 있도록 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성한다.
개발 기술 환경 파악
개발 기술 환경: 개발하고자 하는 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어, 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈 소스 사용 시 주의해야 할 내용을 제시한다.
운영체제 관련 요구사항 식별 시 고려사항
- 가용성, 성능, 기술 지원, 주변 기기, 구축 비용
DBMS 관련 요구사항 식별 시 고려사항
- 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용
웹 애플리케이션 서버(WAS) 관련 요구사항 식별 시 고려사항
- 가용성, 성능, 기술 지원, 구축 비용
오픈 소스 사용에 따른 고려사항
- 라이선스의 종류, 사용자 수, 기술의 지속 가능성
요구사항 정의
요구사항: 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타낸다.
- 요구사항은 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다.
- 요구사항은 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게 하므로 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 준다.
- 요구사항이 제대로 정의되어야만 이를 토대로 이후 과정의 목표와 계획을 수립할 수 있다.
요구사항의 유형
| 유형 | 내용 |
| 기능 요구사항 | - 시스템이 무엇을 하는지, 어떤 기능을 하는지? - 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지? - 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지? - 시스템이 반드시 수행해야 하는 기능 - 사용자가 시스템을 통해 제공받기를 원하는 기능 |
| 비기능 요구사항 | - 시스템 장비 구성 요구사항 - 성능 유구사항 - 인터페이스 요구사항 - 데이터 요구 사항 - 테스트 요구사항 - 보안 요구사항 - 품질 요구사항 - 제약사항 - 프로젝트 관리 요구사항 - 프로젝트 지원 요구사항 |
| 사용자 요구사항 | - 사용자 관점에서 본 시스템이 제공해야 할 요구사항 - 사용자를 위한 것으로 친숙한 표현으로 이해하기 쉽게 작성된다. |
| 시스템 요구사항 | - 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항 - 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현된다. - 소프트웨어 요구사항이라고도 한다. |
요구사항 개발 프로세스
도출(Elicitation) -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)
요구사항 도출
: 시스템, 사용자, 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정
- 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계이다.
- 소프트웨어 개발 생명 주기(SDLC) 동안 지속적으로 반복된다.
- 요구사항을 도출하는 주요 기법에는 인터뷰, 설문, 브레인스토밍, 워크삽, 프로토타이핑, 유스케이스 등이 있다.
요구사항 분석
: 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
요구사항 명세
: 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것을 의미
요구사항 확인
: 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동
요구사항 분석 기법
: 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위한 방법
- 요구사항 분석 기법에는 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석 등이 있다.
요구사항 분류
- 기능 요구사항과 비기능 요구사항으로 분류한다.
개념 모델링
: 요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현한 것
- 개념 모델의 종류에는 유스케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터액션, 객체 모델, 데이터 모델 등이 있다.
- 모델링 표기는 주로 UML을 사용한다.
요구사항 할당
: 요구사항을 만족시키기 위한 구성 요소를 식별하는 것
요구사항 협성
: 요구사항이 서로 충돌될 경우 이를 적절히 해결하는 과정
정형 분석
: 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정
요구사항 확인 기법
: 요구사항 개발 과정을 거쳐 문서화된 요구사항 관련 내용을 확인하고 검증하는 방법
- 요구사항에 자원이 배정되기 전에 문제 파악을 위한 검증을 수행해야 한다.
- 요구사항 확인 기법에는 요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트 등이 있다.
UML
: 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
- UML을 이용하여 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있다.
- UML의 구성 요소에는 사물, 관계, 다이어그램 등이 있다.
사물
: 모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들을 의미
- 구조 사물(Structural Things)
- 시스템의 개념적, 물리적 요소를 표현
- 클래스, 유스케이스, 컴포넌트, 노드 등
- 행동 사물(Behavioral Things)
- 시간과 공간에 따른 요소들의 행위를 표현
- 상호작용, 상태 머신 등
- 그룹 사물(Grouping Things)
- 요소들을 그룹으로 묶어서 표현
- 패키지
- 주해 사물(Annotation Things)
- 부가적인 설명이나 제약조건 등을 표현
- 노트
관계
: 사물과 사물 사이의 연관성을 표현하는 것으로, 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등이 있다.
연관 관계
: 2개 이상의 사물이 서로 관련되어 있음을 표현한다.
집합 관계
: 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현한다.
포함 관계
: 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현한다.
일반화 관계
: 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현한다.
의존 관계
: 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현한다.
실체화 관계
: 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현한다.
다이어그램
: 사물과 관계를 도형으로 표현한 것
- 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램을 사용한다.
구조적 다이어그램의 종류
- 클래스 다이어그램
- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한다.
- 시스템의 구조를 파악하고 구조상의 문제점을 도출할 수 있다.
- 객체 다이어그램
- 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현한다.
- 컴포넌트 다이어그램
- 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현한다.
- 구현 단계에서 사용되는 다이어그램이다.
- 배치 다이어그램
- 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현한다.
- 노드와 의사소통(통신) 경로로 표현한다.
- 구현 단계에서 사용되는 다이어그램이다.
- 복합체 구조 다이어그램
- 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현한다.
- 패키지 다이어그램
- 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현한다.
행위 다이어그램의 종류
- 유스케이스 다이어그램
- 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용한다.
- 사용자(Actor)와 사용 사례(Use Case)로 구성되며, 사용 사례 간에는 여러 형태의 관계로 이루어진다.
- 시퀀스 다이어그램
- 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현한다.
- 커뮤니케이션 다이어그램
- 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데, 메시지뿐만 아니라 객체들 간의 연관까지 표현한다.
- 상태 다이어그램
- 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현한다.
- 활동 다이어그램
- 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현한다.
- 상호작용 개요 다이어그램
- 상호작용 다이어그램 간의 제어 흐름을 표현한다.
- 타이밍 다이어그램
- 객체 상태 변화와 시간 제약을 명시적으로 표현한다.
'IT Study > 정보처리기사' 카테고리의 다른 글
| 2020 정보처리기사 (4장. 통합 구현) (0) | 2020.10.10 |
|---|---|
| 2020 정보처리기사 (3장. 데이터 입출력 구현) (0) | 2020.10.05 |
| 2020 정보처리기사 (11장. 제품 소프트웨어 패키징) (0) | 2020.10.02 |
| 2020 정보처리기사 (10-2장. 응용 SW 기초 기술 활용) (0) | 2020.09.29 |
| 2020 정보처리기사 (10-1장. 응용 SW 기초 기술 활용) (0) | 2020.09.28 |
댓글