[정보처리기사] 요구사항 확인 2
요구사항 확인 2
유스케이스(Use Case) 다이어그램
- 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것
- 유스케이스 다이어그램의 구성 요소
| 구성 요소 | 내용 |
|---|---|
| 시스템(System) / 시스템 범위(System Scope) | 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현한 것 |
| 액터(Actor) |
|
| 유스케이스(Use Case) | 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것 |
| 관계(Relationship) |
|
유스케이스에서 나타날 수 있는 관계
| 포함(Include) 관계 |
|
|---|---|
| 확장(Extend) 관계 |
|
클래스(Class) 다이어그램
- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것
- 클래스 다이어그램의 구성 요소
| 구성 요소 | 내용 |
|---|---|
| 클래스(Class) |
|
| 제약조건 |
|
| 관계(Relationships) |
|
시퀀스(Sequence) 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정을 그림으로 표현한 것
- 시퀀스 다이어그램의 구성 요소
| 구성 요소 | 의미 |
|---|---|
| 액터(Actor) | 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미 |
| 객체(Object) | 메시지를 주고받는 주체 |
| 생명선(Lifeline) |
|
| 실행 상자 (Active Box, 활성 상자) | 객체가 메시지를 주고받으며 구동되고 있음을 표현 |
| 메시지(Message) | 객체가 상호 작용을 위해 주고받는 메시지 |
| 객체 소멸 | 해당 객체가 더 이상 메모리에 존재하지 않음을 표현 |
| 프레임(Frame) | 다이어그램의 전체 또는 일부를 묶어 표현 |
커뮤니케이션(Communication) 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것
- 커뮤니케이션 다이어그램의 구성 요소
| 구성 요소 | 의미 |
|---|---|
| 액터(Actor) | 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미 |
| 객체(Object) | 메시지를 주고받는 주체 |
| 링크(Link) |
|
| 메시지(Message) |
|
| 상태 전환 | 상태 사이의 흐름, 변화를 화살표로 표현 |
| 이벤트(Event) |
|
| 프레임(Frame) | 상태 다이어그램의 범위를 표현 |
패키지(Package) 다이어그램
- 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것
- 패키지 다이어그램의 구성 요소
| 구성 요소 | 의미 |
|---|---|
| 패키지(Package) |
|
| 객체(Object) | 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들 |
| 의존 관계 (Dependency) |
|
구조적 방법론
- 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Precess) 중심의 방법론
- 이해가 쉽고 검증이 가능한 프로그램 코드를 생성하는 것이 목적
- 구조적 방법론의 개발 절차
컴포넌트 기반 방법론(CBD; Component Based Design)
- 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
- 컴포넌트의 재사용(Reusability)이 가능하여 시간과 노력을 절감할 수 있음
- 컴포넌트 기반 방법론의 개발 절차
소프트웨어 재사용(Software Reuse)
- 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
- 소프트웨어 재사용 방법
| 합성 중심 (Composition- Based) | 전자 칩과 같은 소프트웨어 부품, 즉 블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법으로, 블록 구성 방법이라고도 함 |
|---|---|
| 생성 중심 (Generation- Based) | 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법으로, 패턴 구성 방법이라고도 함 |
CASE(Computer Aided Software Engineering)
- 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
- CASE의 주요 기능
- 소프트웨어 생명 주기 전 단계의 연결
- 다양한 소프트웨어 개발 모형 지원
- 그래픽 지원
LOC(source Line Of Code, 원시 코드 라인 수) 기법
- 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
- 산정 공식
- 노력(인월) = 개발 기간 X 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수
- 개발 비용 = 노력(인월) X 단위 비용(1인당 월평균 인건비)
- 개발 기간 = 노력(인월) / 투입 인원
- 생산성 = LOC / 노력(인월)
수학적 산정 기법
- 수학적 산정 기법은 상향식 비용 산정 기법으로, 경험적 추정 모형, 실험적 추정 모형이라고도 함
- 수학적 산정 기법은 개발 비용 산정의 자동화를 목표
- 주요 수학적 산정 기법
- COCOMO 모형
- Putnam 모형
- 기능 점수(FP) 모형
COCOMO의 소프트웨어 개발 유형
- 조직형(Organic Mode)
- 기관 내부에서 개발된 중·소 규모의 소프트웨어
- 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리용 등의 5만(50KDSI) 라인 이하의 소프트웨어를 개발하는 유형
- 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합
- 반분리형(Semi-Detached Mode)
- 조직형과 내장형의 중간형 소프트웨어
- 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형
- 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합
- 내장형(Embedded Mode)
- 초대형 규모의 소프트웨어
- 트랜잭션 처리 시스템이나 운영체제 등의 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형
- 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합
Putnam 모형
- 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
- 푸트남(Putnam)이 제안한 것으로, 생명 주기 예측 모형이라고도 함
- 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
기능 점수(FD; Function Point) 모형
- 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하면, 총 기능 점수와 영향도를 이용하여 기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정하는 기법
- 소프트웨어 기능 증대 요인
- 자료 입력(입력 양식)
- 정보 출력(출력 보고서)
- 명령어(사용자 질의수)
- 데이터 파일
- 필요한 외부 루틴과의 인터페이스
비용 산정 자동화 추정 도구
| SLIM | Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구 |
|---|---|
| ESTIMACS | 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구 |
CPM(Critical Path Method, 임계 경로 정보)
- 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
- 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타냄
ISO/IEC 12207
- ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스
- 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 새명 주기 표준을 제공
- ISO/IEC 12207 구분
| 기본 생명 주기 프로세스 | 획득, 공급, 개발, 운영, 유지보수 프로세스 |
|---|---|
| 지원 생명 주기 프로세스 | 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상 관리, 문제 해결 프로세스 |
| 조직 생명 주기 프로세스 | 관리, 기반 구조, 훈련, 개선 프로세스 |
CMMI(Capability Maturity Model Integration)
- 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델
- CMMI의 소프트웨어 프로세스 성숙도
| 단계 | 특징 |
|---|---|
| 초기(Initial) | 작업자 능력에 따라 성공 여부 결정 |
| 관리(Managed) | 특정한 프로젝트 내의 프로세스 정의 및 수행 |
| 정의(Defined) | 조직의 표준 프로세스를 활용하여 업무 수행 |
| 정량적 관리 (Quantitatively Managed) | 프로젝트를 정량적으로 관리 및 통제 |
| 최적화 (Optimizing) | 프로세스 역량 향상을 위해 지속적인 프로세스 개선 |
SPICE의 프로세스 수행 능력 단계
| 수준 | 단계 | 특징 |
|---|---|---|
| 0 | 불완전 (Incomplete) | 프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계 |
| 1 | 수행 (Performed) | 프로세스가 수행되고 목적이 달성된 단계 |
| 2 | 관리 (Managed) | 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계 |
| 3 | 확립 (Established) | 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계 |
| 4 | 예측 (Predictable) | 프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계 |
| 5 | 최적화 (Optimizing) | 프로세스 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계 |
소프트웨어 개발 프레임워크(Framework)
- 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러 가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템
- 선행 사업자의 기술에 의존하지 않는 표준화된 개발 기반으로 인해 사업자 종속성이 해소됨
소프트웨어 개발 프레임워크의 특성
- 모듈화(Modularity)
- 프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 소프트웨어의 품질을 향상시킴
- 프레임워크는 개발 표준에 의한 모듈화로 인해 유지 보수가 용이
- 재사용성(Reusability)
프레임워크는 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능 - 확장성(Extensibility)
프레임워크는 다형성(Polymorphism)을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능 - 제어의 역흐름(Inversion of Control)
개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상시킴
This post is licensed under CC BY 4.0 by the author.