1. 요구사항 확인
현행 시스템 분석
현행 시스템 파악
현행 시스템 파악 개념
현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지를 파악하는 활동. 사용하고 있는 소프트웨어 및 하드웨어는 무엇인지, 네트워크의 구성은 어떻게 되어 있는지 파악하는 활동.
현행 시스템 파악 절차
구성/기능/인터페이스 파악 → 아키텍처 및 소프트웨어 구성 파악 → 하드웨어 및 네트워크 구성 파악
소프트웨어 아키텍처
여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체를 의미. 소프트웨어를 설계하고 전개하기 위한 지침이나 원칙
소프트웨어 아키텍처 프레임워크
- 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준
소프트웨어 아키텍처 프레임워크 구성요소
- 아키텍처 명세서 : 아키텍처를 기록하기 위한 산출물.
- 이해관계자 : 시스템 개발에 관련된 모든 사람과 조직
- 관심사 : 시스템에 대해 이해관계자들의 서로 다른 의견, 목표
- 관점 : 개별 뷰를 개발할 때 토대가 되는 패턴, 양식
- 뷰 : 서로 관련 잇는 관심사들의 집합
- 근거 : 아키텍처 결정 근거. 회의 보고 결과
소프트웨어 아키텍처 4+1 뷰
- 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법. 4개의 분리된 구조로 구성되는 아키텍처 개념을 제시하고, 이들 4개 구조가 서로 충돌되지 않는지, 시스템의 요구사항을 충족시키는지를 증명하기 위해 체크 방법으로 유스케이스를 사용.
- 소프트웨어 아키텍처 4+1뷰 구성 요소 : 4+1에서 1은 유스케이스 뷰이고 4는 논리 뷰, 구현 뷰, 프로세스 뷰, 배포 뷰다.
유스케이스 뷰
- 아키텍처를 도출하고 설계하는 작업을 주도하는 뷰. 다른 뷰를 검증하는 데 사용.
논리 뷰
- 설게 모델의 추상화이며, 주요 설게 패키지와 서브 시스템, 클래스를 식별하는 뷰. 시스템의 기능적인 요구사항 지원. 클래스와 이들 간 관계에 대한 집합을 보여주는 클래스 다이어그램으로 표현
프로세스 뷰
- 런타임 시의 시스템의 테스크, 스레드, 프로세스와 이들 사이의 상호작용 등의 관계를 표현하는 뷰. 성능이나 가용성과 같은 시스템의 비기능적인 요구사항을 고려
구현 뷰
- 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 표현하는 뷰. 개발자 관점에서 소프트웨어의 구현과 관리적인 측면을 컴포넌트 다이어그램으로 표현
배포 뷰
- 물리적인 노드의 구성과 상호 연결 관계를 배포 다이어그램으로 표현하는 뷰. 다양한 실행 파일과 다른 런타임 컴포넌트가 해당 플랫폼 또는 컴퓨팅 노드에 어떻게 매핑되는가를 보여주며, 가용성, 신뢰성, 성능, 확장성 등의 시스템의 비기능적인 요구사항을 고려.
개발 기술 환경 정의
개발 기술 환경 현행 시스템 분석
운영체제
컴퓨터 시스템이 제공하는모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고, 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램
운영체제 현행 시스템 분석 시 고려 사항
- 신뢰도
- 성능
- 기술 지원
- 주변 기기
- 구축 비용
네트워크
컴퓨터 장치들의 노드 간 연결(데이터 링크)을 사용하여 서로에게 데이터를 교환할 수 있도록 하는 기술. 데이터 링크들은 광케이블과 같은 유선 매체 또는 와이파이(Wi-Fi)와 같은 무선 매체를 통해 확립.
OSI 7계층
네트워크 통신에서 생긴 여러 가지 충돌 문제를 완하하기 위해 국제 표준화 기구에서 제시한 네트워크 기본 모델.
- 응용 계층
- 표현 계층
- 세션 계층(이상 단위 데이터)
- 전송 계층(단위 세그먼트)
- 네트워크 계층(단위 패킷)
- 데이터 링크 계층(단위 프레임)
- 물리 계층(단위 비트)
DBMS(Database Management System)
데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램.
기능
- 중복 제어
- 접근 통제
- 인터페이스 제공
- 관계 표현
현행 시스템 분석
데이터베이스의 가용성, 성능, 기술 지원, 호환성, 구축 비용을 분석
미들웨어
미들웨어는 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어. 운영체제와 소프트웨어 애플리케이션 사이에 위치. 대표적으로 WAS를 예로 들 수 있음.
현행 시스템 분석
미들웨어의 가용성, 성능, 기술 지원, 구축 비용을 분석
웹 애플리케이션 서버(WAS; Web Application Server)
웹 애플리케이션 서버는 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이 기종 시스템과의 애플리케이션 연동을 지원하는 서버.
개발 기술 환경 요구사항 파악
온라인 트랜잭션 처리(OLTP) 시스템
네트워크 상의 여러 이용자가 실시간으로 데이터베이스의 데이터를 갱신하거나 조회하는 등의 단위작업을 처리하는 방식
요구사항 확인
요구사항
요구사항 개념
기능적 요구사항
시스템이 제공하는 기능, 서비스에 대한 요구사항.
특성
- 기능성
- 완전성
- 일관성
비기능적 요구사항
시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항
특성
- 신뢰성
- 사용성
- 효율성
- 유지보수성
- 이식성
요구사항 개발 프로세스
도출 → 분석 → 명세 → 확인
요구사항 개발 프로세스 주요 기법
도출
- 인터뷰
- 설문 조사
- 브레인 스토밍(아이디어 수용 회의)
- 워크숍
분석
- 자료 흐름 지향 분석 : DFD;Data Flow Diagram으로부터 소프트웨어 구조를 유도
- 객체지향 분석
확인 및 검증
- 동료 검토
- 워크 스루 : 자료를 사전 배포 및 검토 후 짧은 시간 회의
- 인스펙션: 저작자 외의 다른 전문가 or 팀이 검사하여 오류를 찾음
요구사항 관리 프로세스
요구사항 협상 → 요구사항 기준선 → 요구사항 변경 관리 → 요구사항 확인 및 검증
요구사항 분석
요구사항 분석 기법
- 요구사항 분류 : 기능인지 비기능인지
- 개념 모델링: 엔티티들과 개별 관계 및 종속성 반영, 유스케이스 다이어그램, UML 사용
- 요구사항 할당 : 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별, 추가 요구사항의 발견
- 요구사항 협상 : 적절한 지점 합의
- 정형 분석 : 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현
UML(Unified Modeling Language)
객체지향 소프트웨어 개발과정에서 산출물을 명세화, 시각화, 문서화할 시 사용되는 모델링 기술과 방법론을 통합해 만든 표준화된 범용 모델링 언어
요구사항의 확인
요구사항 확인 기법
- 요구사항 검토
- 프로토 타이핑 : 프로토 타입으로 구현, 사용자의 피드백을 통해 개선 및 보완
- 모델 검증
- 인수 테스트
요구사항의 확인 프로세스
- 요구사항 목록 확인
- 요구사항 정의서 작성 여부 확인
- 비기능적 요구사항의 확인
- 타 시스템 연계 및 인터페이스 요구사항 확인
요구사항의 시스템화 타당성 분석
요구사항의 기술적 타당성 검토
- 성능 및 용량 산정의 적정성
- 시스템 간 상호 운용성
- IT 시장 성숙도 및 트렌드 부합성
- 기술적 위험 분석
요구사항의 기술적 타당성 분석 프로세스
- 타당성 분석 결과 기록
- 타당성 분석 결과의 이해관계자 검증
- 타당성 분석 결과 확인 및 배포/공유
비용산정 모델
비용산정 모델 분류
하향식 산정방법 : 경험이 많은 전문가에게 비용산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식
- 전문가 판단
- 델파이 기법
상향식 산정방법 : 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식
- LOC(Lines of Code)
- Man Month(M/M)
- CoCoMo 모형
- Putnam 모형
- FP(Function Point) 모형
Man Month
한사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 기법.
Man Month = LoC ÷ 프로그래머의 월간 생산성
프로젝트 기간 = Man Month ÷ 프로젝트 인력
COCOMO
- 단순형(Organic Mode) : 5만라인 이하. 일괄 자료 처리. 과학 기술 게산용. 비즈니스 자료 처리 개발.
- 중간형(Semi-Detached Mode) : 30만 라인 이하. 데이터베이스 관리 시스템 개발
- 임베디드형(Embedded Mode) : 30만 라인 이상. 트랜잭션 처리 시스템 운영체제 개발
분석 모델 확인하기
분석 모델 검증
요구사항 도출 기법을 활용하여 업무 분석가가 제시한 분석 모델에 대해서 확인하는 활동
분석 모델 검증 방법
- 유스케이스 모델 검증
- 개념 수준의 분석 클래스 검증
- 분석 클래스 검증
분석 클래스의 스테레오 타입
- 경계 : 시스템과 외부 액터와의 상호작용을 담당하는 클래스
- 엔티티 : 시스템이 유지해야 하는 정보를 관리하는 기능을 전담하는 클래스
- 제어 : 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스
분석 모델 검증 프로세스
검토의견 컬럼 추가 → 검토의견 작성 → 검토의견 정제
분석 모델의 시스템화 타당성 분석
분석 모델이 개발할 응용 소프트웨어에 미칠 영향을 검토하여 기술적인 타당성을 조사
분석 모델의 기술적 타당성 검토
분석 모델의 기술적 타당성 검토 항목
- 성능 및 용량 산정의 적정성
- 시스템 간 상호 운용성
- IT 시장 성숙도 및 트렌드 부합성
- 기술 위험 분석
분석 모델의 시스템화 타당성 분석 프로세스
타당성 검토의견 컬럼 추가 → 타당성 검토의견 작성 → 타당성 분석 결과 검증 → 타당성 분석 결과 확인 및 배포/공유