요구사항 확인

요구사항 확인

요구사항 확인

1. 요구사항 확인

1) 현행 시스템 파악

– 현재 개발하고자 하는 시스템의 개발 범위를 설정하기 위해 구성과 기능, 연계정보, 소프트웨어, 하드웨어, 네트워크의 구성을 파악하는 과정을 의미한다.

2) 현행 시스템 파악 절차

현행 시스템 구성 파악

현행 시스템 기능 파악

인터페이스 현황 평가

기간 업무, 지원 업무

제공하는 기능 파악, 계층형 표시

데이터 종류, 통신규약, 연계 유형

아키텍처 구성 파악

소프트웨어 구성 파악

업무 수행 기술 요소들이 사용되는지 최상위 수준에서 파악

소프트웨어 제품명, 용도, 라이선스 수, 적용 방식 명시

하드웨어 구성 파악

네트워크 구성 파악

서버의 주요 사양, 서버의 이중화, 수량

네트워크 구성 파악을 위해 네트워크 연결 방식을 구성도로 작성

3) 소프트웨어 아키텍처(서술형)

– 여러가지 소프트웨어 구성요소와 외부 특성, 구성요소 간의 관계를 표현하는 시스템 구조

– 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체

4) 소프트웨어 아키텍처 프레임워크(서술형)

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

– 기본 구조, 소프트웨어의 베이스(개발 기반), 역할 : 품질유지, 원칙, 지침

– 동일한 아키텍쳐 = 기본 구조가 같은 여러 형태의 결과물

* 소프트웨어 프레임워크의 특징

– 모듈화(Modularity)

: 프레임워크는 인터페이스에 의한 캡슐화를 통해서 모듈화를 강화하고 설계와 구현의 변경에 따르는 영향을 극소화하여 소프트웨어의 품질을 향상시킨다.

– 재사용성(Reusability)

: 프레임워크가 제공하는 인터페이스는 반복적으로 사용할 수 있는 컴포넌트를 정의할 수 있게 하여 재사용성을 높여준다. 또는 재사용성은 소프트웨어의 품질을 향상시킬 뿐만 아니라 개발자의 생산성도 높여준다.

– 확장성(Extensibility)

: 프레임워크는 다형성을 통해 애플리케이션이 프레임워크의 인터페이스를 넓게 사용할 수 있게 한다. 또한 애플리케이션 서비스와 특성을 변경하고 프레임워크를 애플리케이션의 가변성으로부터 분리함으로써 재사용성의 이점을 얻게 한다.

– 제어의 역흐름(Inversion of control)

: 프레임워크 코드가 전체 애플리케이션의 처리 흐름을 제어하여 특정한 이벤트가 발생할 때 다형성을 통해 애플리케이션이 확장한 메소드를 호출함으로써 제어가 프레임워크로부터 애플리케이션으로 반대로 흐르게 한다.

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

* 정의 : 고객의 요구사항을 정리해둔 시나리오 4개의 관점으로 바라보는 소프트웨어적인 접근 방법

* 4+1뷰의 종류

– 유스케이스 뷰 : 아키텍처를 도축하고 설계하는 작업을 주도하는 뷰

– 논리 뷰 : 설계 모델의 추상화, 클래스 식별 -> 클래스 다이어그램

– 프로세스 뷰 : 런타임 시 스레드와 프로세스 사이의 상호 작용

– 배포 뷰 : 물리적인 노드의 구성 -> 배포 아이어그램

– 구현 뷰 : 정적인 소프트웨어 구현 -> 컴포넌트 뷰, 컴포넌트 다이어그램

* 런타임 : 컴퓨터 프로그램이 실행되고 있는 동안의 동작 상태

* 스레드 : 프로세스의 실행을 담당하는 실행의 기본 단위

* 프로세스 : 운영체제가 관리하는 실행 단위며 PCB를 가진 시스템

* 프레임워크 : 소프트웨어의 특정 부분을 설계 및 구현 시 재사용이 가능하도록 클래스 제공

6) 개발 기술 환경 정의

* 운영체제(서술형) : 사용자와 하드웨어의 인터페이스 역할을 하며 컴퓨터 시스템의 자원을 관리하는 소프트웨어

– 키워드 : 신뢰성, 성능, 기술 지원, 주변 기기, 구축 비용

* DBMS(서술형) 사용자와 Database 사이에서 사용자의 요구에 따라 정보를 생성해주고 Database를 관리해주는 소프트웨어

– 데이터의 중복성과 종속성을 해결

– 키워드 : 가용성, 성능, 기술 지원, 상호 호환성, 구축비용

* JDBC : JAVA 언어를 이용하여 DB에 접근하여 관리할 수 있는 인터페이스

* ODBC : 응용프로그램에서 DB에 접근하여 데이터를 관리할 수 있는 표준 인터페이스

* 미들웨어 : 운영체제와 소프트웨어 Application 사이에서 원만한 통신이 이루어질 수 있도록 중개 및 제어 역할을 하는 소프트웨어

미들웨어의 종류

– DB(DataBase)

: 데이터베이스 벤더(Vendor)에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어

– RPC(Remote Procedure Call)

: 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어

 MOM(Message Oriented Middleware)

: ​메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어

– TP-Monitor(Transaction Processing Monitor)

: 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어

– ORB(Object Request Broker)

객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어

 WAS(Web Application Server)

: 사용자의 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어

– 키워드 : 가용성, 성능, 기술 자원, 구축 비용

– WAS 종류 : Tomcat, JBoss, Jetty, JEUS

* 가비지 컬렉선 : 실제로 사용되지 않고 있지만 반환되지 않은 메모리 공간을 강제로 해제하여 사용할 수 있도록 하는 메모리 관리 기법

* 오픈소스 : 누구나 제한 없이 사용할 수 있는 소스코드를 공개한 라이선스를 만족하는 소프트웨어

– 키워드 : 라이선스 종류, 사용자의 수, 기술 지속 가능성 고려

* tpmC : 1분당 최대 처리 건수, 하드웨어 성능 지표로 사용

* OLTP/배치/데이터베이서 서버 -> tpmC

* WEB/WAS 서버 -> OPS(Operations per Second)

7) 요구사항

* 소프트웨어가 문제를 해결하기 위해 제공되는 서비스 설명과 제약조건을 나타낸다.

– 기능적 요구사항 : 시스템이 제공하는 기능, 서비스 (기능성, 완전성, 일관성)

– 비기능적 요구사항 : 기능외의 제약사항이나 보안적인 요소

– 사용자 요구사항 : 사용자 관점에서 시스템이 제공해야 할 기능 및 서비스

– 시스템 요구사항 : 개발자 관점

– 요구사항 개발 프로세스

도출

분석

명세

확인

– 요구사항 식별
– 인터뷰
– 브레인스토밍
– 리서치
– 워크숍

– 요구사항 분류
– 개념 모델링
– 요구사항 협상
– 요구사항 할당
– 정형 분석

– 문서화
– 시스템 요구사항 명세서
– 시스템 정의서

– 요구사항 검토
– 프로토타이핑
– 모델 검증
– 인수 테스트

개념 모델링 : 요구사항 분석의 핵심으로 요구사항을 단순화하여 개념적으로 표현한 것
* 유스케이스 다이어그램 : 액터(사용자)와 시스템의 관계를 표현하고 기능적인 요구사항을 유스케이스라는 단위로 표현
* UML : 개발자들이 효율적으로 의사소통을 하기 위해 만들어진 표준 통합 모델링 언어

요구사항 할당 : 아키텍처 구성요소 식별

정형 분석 : 구문과 의미를 갖는 정형화된 언어를 수학적 기호로 표현하여 분석

모델 검증 : 정적 분석 수행

인수테스트 : 사용자의 입장에서 테스트하는 방법으로 알파 테스트와 베타 테스트가 존재

프로토타이핑 : 새로운 요구사항을 도축하기 위한 수단 또는 요구사항에 대해 소프트웨어 엔지니어가 해석한 것으로 확인하기 위한 수단

8) 비용 산정 모델

– 하향식 선정 방법 : 전문가 판단, 델파이 기법

– 상향식 선정 방법 : LOC, M/M(Man/Month), Putnam, COCOMO

* Putnam : 개발 주기의 단계별 요구, 인원 분포도 가정

* COCOMO : 보헴이 정의 / 프로그램 규모에 따라 비용 산정

* 상호 운용성 : 서로 다른 시스템 간의 데이터를 주고 받아 효율적으로 운용될 수 있는 특성

9) 분석 모델 검증

 (1) 유스케이스 모델 검증 ( 액터, 유스케이스 )

 (2) 개념 수준의 분석 클래스 검증

 (3) 분석 클래스 검증

– 경계 : 외부 액터와 상호작용

– 엔티티 : 시스템이 유지해야 하는 정보를 관리

– 제어 : 시스템이 제공하는 기능의 로직, 제어 담당

– 기술적 타당성 검토

 (1) 성능 및 용량 산정의 적정성

 (2) 시스템 간 상호 운용성

 (3) IT 시장 성숙도 및 트렌드 부합성

 (4) 기술적 위험 분석

10) UML

* 정의 : 개발자들이 원활한 의사소통을 하기 위해 고안된 표준화 통합 모델링 언어

* 6개의 구조 다이어그램 + 7개의 행위 다이어그램

* 구성요소 : 사물, 관계, 다이어그램

– 사물 : 구조, 그룹, 행동, 주해

– 관계

  – 연관관계 : 2개 이상 사물이 서로 연관

  – 집합관계 : 하나의 사물이 다른 사물에 포함

  – 포함관계 : 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

  – 일반화 : 상속 관계

  – 의존 : 필요에 의해 짧은 기간 동안 관계 유지

  – 실체화 : 서로를 그룹화할 수 있는 인터페이스

연관
Association
집합
Aggregation
포함
Composition
일반화
Generalization
의존
Dependency
실체화
Realization
정의 2개 이상 사물 서로 관련 하나의 사물, 다른 사물에 포함 포함되는 사물에게 영향 미침 사물끼리 일반적, 구체적 표현 연관은 있으나 영향줄 때만 연관을 유지 행위, 인터페이스로 서로 그룹화할 수 있는 관계
표기법
* 다수, .. 또는
상위개념 실선 일시적, 점선 상위개념, 점선
예시 자동차-타이어 컴퓨터 ◇
마우스
마우스 ◆
마우스 리시버
토레타 포카리 – 이온음료  고객등급 —
사은품
폰, 벽시계 —
시간확인

– 다이어그램(6개의 구조 다이어그램 + 7개의 행위 다이어그램)

  – 6개 구조 다이어그램 : 클래스, 객체, 컴포넌트, 배치

   – 컴포넌트 다이어그램 : 컴포넌트와의 관계나 인터페이스를 표현

   – 배치 다이어그램 : 물리적인 요소들의 위치 표현

  – 7개 행위 다이어그램 : 유스케이스, 시퀀스, 커뮤니케이션, 상태

구조적 다이어그램 행위 다이어그램
종류 키워드 종류 키워드
클래스 구조 유스케이스 모델링
객체 관계 시퀀스 메시지
컴포넌트 구현, 인터페이스 커뮤니케이션 메시지 + 연관관계
배치 구현, 위치 상태 상태 변화
복합체 구조 내부 구조 활동 로직 흐름
패키지 그룹 상호작용 개요 제어 흐름
타이밍 시간제약

* 유스케이스 다이어그램 구성요소 : 액터, 유스케이스, 시스템, 관계

* 유스케이스 : 액터에게 제공하는 서비스, 기능을 표현

요구사항 확인

현행 시스템 아키텍처 및 소프트웨어

1) 아키텍처 구성도 파악

: 기간 업무를 수행하기 위하여 계층별로 어떠한 기술 요소들을 사용하고 있는지 최상위 수준에서 그림으로 표현한것
– 단위 업무 시스템 별로 아키텍처가 다른 경우에는 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 한다.

2. 현행 시스템 구성/기능 및 인터페이스

: 현행 시스템 구성 현황은 조직의 주요 업무를 처리하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술

– 각 업무에 속하는 단위 업무 정보시스템들의 명칭, 주요 기능들을 명시함으로써 조직 내 존재하는 모든 정보시스템의 현황을 파악

: 단위 업무 시스템이 현재 제공하고 있는 기능을 기술

– 단위 업무 시스템에서 제공하는 기능들을 주요 기능과 하부 기능으로 구분하여 계층형으로 표시한다.

: 단위 업무 시스템이 다른 단위 업무 시스템과 주고받는 데이터의 종류, 데이터 형식, 프로토콜, 연계유형, 주기 등을 명시

– 중요한 고려 사항으로는 어떤 형식(format)으로 데이터를 주고받는지(XML, 고정 포맷, 가변 포맷 등), 어떤 통신규약(TCP/IP, X.25 등)을 사용하고 있고, 연계유형(EAI, FEP 등)은 무엇인지 등이 있다.

3. 현행 시스템 아키텍처 및 소프트웨어

: 기간 업무를 수행하기 위하여 계층별로 어떠한 기술 요소들을 사용하고 있는지 최상위 수준에서 그림으로 표현한것

– 단위 업무 시스템 별로 아키텍처가 다른 경우에는 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 한다

: 단위 업무 시스템의 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수를 명시한 것

– 시스템 구축 시 인프라 구축 비용에서 하드웨어 비용뿐만 아니라 소프트웨어 비용이 적지 않기 때문에, 상용 소프트웨어의 경우에는 라이선스 적용 방식의 기준(사이트, 서버, 프로세서, 코어(core), 사용자 수 등)과 보유한 라이선스 수량 파악이 중요하다.

하드웨어 및 네트워크

: 단위 업무 시스템들이 어디에 위치하고 있는 서버에서 운용되고 있는지 서버의 주요 사양(CPU 처리 속도, 메모리크기, 하드디스크의 용량 등)과 수량, 이중화(장애시 계속 서비스)가 적용되어 있는지 여부를 명시한 것

– 이중화는 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요성 여부가 결정되며, 현행 시스템에서 이중화가 적용된 경우에는 목표 시스템에서도 이중화가 필요한 경우가 대부분이며, 이에 따라 인프라 구축 기술 난이도 및 비용 증가 가능성이 존재한다.

: 업무 처리 시스템들이 어떠한 네트워크 구성을 가지고 있는지 그림으로 표현한 것

– 네트워크 구성도의 작성을 통해 서버의 위치, 서버 간의 네트워크 연결 방식을 파악할 수 있다. 네트워크 구성도는 조직 내 서버들의 물리적인 위치 관계 파악, 조직 내 보안 취약성 분석 및 대응, 네트워크 장애 발생 추적 및 대응 등의 다양한 용도로 활용될 수 있다.

Start typing and press Enter to search

Shopping Cart