[정보처리기사] 1강 요구사항 확인

 

1.현행시스템분석

 

1-1) 현행 시스템 파악

시스템의 개발 범위를 명확히 설정하기 위해 현행 시스템의 구성과 제공 기능, 소프트& 하드웨어, 네트워크 구성등을 파악하는 것.

 

1-1-2) 파악 절차

1단계 ( 구성/기능/인터페이스 파악 )

2단계 ( 아키텍쳐 및 소프트웨어 구성 파악 )

3단계 ( 하드웨어 및 네트워크 구성 파악)

 

1-1-3) 소프트웨어 아키텍쳐

소프트웨어를 설계하고 전개하기 위한 지침이나 원칙

여러가지 소프트웨어 구성요소의 특성 및 외부에 드러나는 특성 그리고 구성요소 간의 관계를 표현하는 시스템 구조등을 의미한다.

 

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

=> 고객의 요구사항을 4개의 관점에서 바라보는 관점이다.

이를 통해 4개의 분리된 구조로 아키텍처 개념을 제시하고, 4개의 관점이 서로 충돌하지 않는지 고객의 요구사항을 충족하는지 증명하기 위해 유스케이스 관점을 사용한다.

 

[4개 : 논리, 구현, 프로세스, 배포 // 1개 : 유스케이스 ]

 

1-2) 개발 기술 환경정의

운영체제, 네트워크, DBMS => 나중에 구체적으로 설명

 

#미들웨어란?

분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경이 원활한 통신을 할 수 있도록 돕는 소프트웨어.

컴퓨터와 컴퓨터 간의 연결을 쉽고, 아전하게 할 수 있도록 해주고 이를 관리하는 소프트웨어

=> 예시 : WAS

 

2. 요구사항 확인

2-1) 요구사항

고객에 의해 요구되거나 표준을 만족하기 위하여 시스템이 가져야하는 제약사항

 

2-1-2) 요구사항 분류

#기능적 요구사항

시스템이 제공하는 기능 및 서비스에 관한 요구사항

#비기능적 요구사항

시스템을 수행하기 위한 기능 이외의 구축에 대한 제약 조건에 대한 요구사항

 

2-1-3) 요구사항 개발 프로세스

1. 도출 [ 인터뷰, 설문조사, 브레인 스토밍, 워크숍 ]

요구사항이 어디에 있는지, 어떻게 수집할 것인지를 파악

 

2. 분석 [ UML ]

상충되는 요구사항을 해결하고 다른 환경과 어떻게 상호작용하는지 이해하는 단계

 

- 개념 모델링 [ 분석 기법 ]

요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현하기 위한 과정

개념 모델은 문제의 주체인 개체들과 그들 간의 관계 및 종속성을 반영하는 것을 목적으로한다.

다양한 방법이 존재하지만, 모델링 표기는 주로 UML을 사용한다.

 

3. 명세 [ 자연어에 의한 처리, 정형화 기법]

체계적으로 검토, 평가, 승인 될 수 있도록 문서를 작성하는 단계

 

4. 확인 [ 동료 검토, 워크스루, 인스펙션, 프로토타이핑, 인수테스트 ]

문서가 표준에 적합하고, 이해가 가능하며 일관성이 있는지 즉, 완전한지를 검토하는 단계.

 

 

2-2) 비용산정 모델

2-2-1) 하향식 [ 경험이 많은 전문가에게 비용 산정을 의뢰 ]

1) 전문가 판단

조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법

 

2) 델파이 기법

전문가의 경험적 지식을 통한 문제 해결 및 예측

=> 전문가 익명 의견 제출 -> 조정자 의견 요약 및 배포 -> 전문가들 익명 투표 : 반복

=> 전문가 판단 기법과 다른 점은 익명을 중심으로 하여, 편견 배제가 가능.

 

2-2-2) 상향식 [ 세부적인 요구사항과 기능에 다라 필요한 비용을 계산하는 방식 ]

1)LoC 기법

낙관치+ 4* 중간치 + 비관치 / 6

(비관치 : 최대 코드 수, 중간치 : 평균 코드 수, 낙관치 : 최소 코드 수 )

 

2) Man Month

한 사람이 1달 동안 일할 수 있는 양의 기준으로 프로젝트 비용을 산정

=? LoC % 프로그래머의 월간 생산성

# 프로젝트 기간 => Man month % 프로젝트 인력

 

 

3. 분석 모델 확인하기

 

3-1) 분석 모델 검증

요구사항 도출 기법을 활용하여 업무 분석가가 제시한 분석 모델에 대해서 확인하는 활동

# 검증방법

유스케이스, 개념 수준의 분석, 분석 클래스 검증

 

 

#UML [ 요구사항 분석 단계에서 사용]

시스템 분석, 설계, 구현등 시스템 개발 과정에서 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어 질 수 있도록 하는 객체지향 모델링 언어이다.

 

UML의 구성요소

1. 사물

모델을 구성하는 가장 중요한 기본 요소로 다이어그램 안에서 관계가 형성 될 수 있는 대상들을 말한다.

-구조 사물 : 시스템의 개념적, 물리적 요소를 표현

- 행동 사물 : 시간과 공간에 따른 요소들의 행위를 표현

- 그룹 사물 : 요소들을 그룹으로 묶어서 표현

- 주해 사물 : 부가적인 설명이나 제약조건을 표현

 

2.관계

연관, 집합[컴퓨터와 프린터]. 포함 [문과 열쇠], 일반화 [커피 / 아메,에스프레소], 의존 [ 등급 / 할인율]

실체화 [ 날 수 있는 / 비행기, 새 ]

 

3. 다이어그램

3-1) 클래스 다이어그램 [ 클래스 ,객체, 컴포넌트, 배치 ]

 

*클래스 다이어그램 [ 클래스, 제약조건, 관계 ]

시스템을 구성하는 클래스, 속성, 오퍼레이션, 제약조건, 관계에 대해 서술한 다이어그램이다.

주로 시스템의 구성 요소를 문서화하는데 사용한다.

 

 

 

3-2) 행위 다이어그램 [유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동 ]

 

*유스케이스 다이어그램 (행위 + 기능 다이어그램 )

=> 시스템 범위, 액터, 유스케이스, 관계로 구성

개발 될 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 할 수 있는 기능을 사용자의 관점에서 표현한 것.

 

*활동 다이어그램 [ 액션, 액티비티, 노드, 스윔레인(Swim lane) ]

사용자의 관점에서 프로그램이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것

 

*시퀀스 다이어그램 [ 액터, 객체, 라이프라인, 활성 상자, 메세지]

객체들이 메시지를 주고 받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체 메시지등의 요소를 사용하여 그림으로 표현

 

* 커뮤니케이션 다이어그램 [ 액터, 객체, 링크, 메세지 ]

시스템 또는 객체들이 메세지를 주고 받으며 시간의 흐름에 따라 상호 자굥하는 과정을 다양한 요소를 통해 그림으로 표현 한 것

시퀀스과의 차이점은 메세지뿐만 아니라 객체들 간의 관계까지 표현한다는 점.