시스템 개발 방법론

목차

1. 폭포수형

2. 프로토 타이핑 기법

3. 나선형

4. 4th

5. 점증적 기법

6. 컴포넌트 기법

본문내용

세히 기술된다. 유스케이스 설명서(Description)는 시스템이 단계적으로 액터와 어떻게 상호작용 하는가와 시스템이 무엇을 하는지를 설명한다.
유스케이스 역할은 시스템의 개발 주기 전체에 걸쳐 통합된 매개체(Thread)의 기능을 하는 것이다. 동일한 유스케이스 모델이 요구사항 수집, 분석 및 설계와 테스트 동안에 사용된다.
작업자와 작업흐름(Workers and Workflow)
각 작업자는 활동 집합과 행동에 대해 책임을 진다. 각 프로세스 컴포넌트는 고유의 작업자들과 그 작업자가 활동을 진행하는 논리적 방법인 작업흐름을 가지고 있다. 아래의 작업자들은 요구사항 수집에서 정의된다.
유스케이스 모델 아키텍트(Use-Case Model Architect)
유스케이스 명세자(Use-Case Specifier)
요구사항 검토자(Requirements Reviewer)
아키텍트(Architect)
아래 그림은 요구사항 수집에서 작업흐름에 대한 전체적인 개요를 보여주고 있다.
[그림 5] 요구사항 수집 단계
분석 및 설계(Analysis & Design)
프로세스 컴포넌트 중 분석 및 설계의 목표는 구현 단계에서 시스템이 어떻게 실현되는가를 보여주는 것이다. 아래 사항을 만족하는 시스템을 구축하여야 한다.
유스케이스 설명서에 명시된 작업(Task)과 기능(Functions)을 구체적인 구현 환경에서 수행한다.
시스템의 모든 요구사항을 충족한다.
견고한 구조를 가진다(기능적 요구사항 변화가 있을 때 쉽게 변경할 수 있는가)
유스케이스 모델은 추가 요구사항 명세서(Supplementary Specifications)와 함께 설계의 토대가 된다.
분석 및 설계에서는 소스 코드의 추상적 개념을 보여주는 설계 모델을 만들어 낸다. 설계 모델은 어떻게 소스 코드가 구조화되어져 있고 쓰여졌는지를 보여주는 청사진과 같은 역할을 한다. 설계 또한 유스케이스의 내부에 관한(Inside-view) 설명서 또는 참여하는 객체/클래스의 관점에서 유스케이스가 어떻게 실현되는지를 기술한 유스케이스 실현(Use-Case Realization)을 만든다.
설계 모델은 설계 패키지에 구조화된 설계 클래스들로 구성되어 있다. 또한 설계 모델은 유스케이스를 수행하기 위해서 어떻게 이들 설계 클래스의 객체들이 상호작용하고 있는지를 기술한 내용을 담고 있다.
설계 활동은 아키텍쳐 측면에 집중한다. 이 아키텍쳐의 생산(Production) 및 확인(Validation)은 초기 설계 반복의 주요한 초점이 된다. 아키텍쳐는 몇 개의 아키텍쳐(Architectural) 뷰에 의해 표현된다. 이들 뷰에는 주요하고 구조적인 설계 결정사항들이 수집된다. 본질적으로 아키텍쳐 뷰는 상세 부분에서 탈피하여 중요한 특성을 보다 쉽게 볼 수 있도록 전체 설계를 추상화 혹은 단순화하는 것이다. 아키텍쳐는 좋은 설계 모델을 개발하는 것뿐만 아니라 시스템 개발 동안 모델의 품질을 증대시키기 위한 중요한 수단이다.
작업자와 작업흐름(Workers and Workflow)
아래의 작업자들은 분석 및 설계에서 정의된다.
아키텍트(Architect)
유스케이스 설계자(Use-Case Designer)
설계자(Designer)
설계 검토자(Design Reviewer)
다음의 그림은 분석 및 설계에서 작업흐름의 전체적인 개요를 보여주고 있다. 작업흐름은 아키텍쳐-레벨(Architectre-Level) 설계와 클래스-레벨(Class-Level) 설계로 나뉘어 진다.
[그림 6] 분석 및 설계 단계
구현(Implementation)
시스템은 구현을 통해서 생성되는 소스, 즉 소스 코드 파일(Source-Code Files), 헤더 파일(Header Files), 메이크 파일(Make Files) 등에 의해서 실현된다. 이 소스는 실행 가능한 시스템을 만들어 낼 것이다. 그리고 소스는 구현 패키지(Implementation Packages)에 구성된 모듈(Modules)로 이루어져 있는 구현 모델(Implementation Model)에서 설명된다. 설계 모델은 구현을 위한 기초 자료가 된다. 구현은 별개의 클래스 또는 패키지의 테스팅을 포함하고 있지만, 동시에 패키지와 클래스를 함께 테스팅하는 것은 포함하지 않는다. 이것은 다음 프로세스 컴포넌트 "테스트(Test)"에서 설명된다.
작업자와 작업흐름(Workers and Workflow)
아래의 작업자들은 분석 및 설계에서 정의된다.
아키텍트(Architect)
시스템 통합자(System integrator)
구현자(Implementor)
코드 검토자(Code Reviewer)
다음의 그림은 구현에서 작업흐름의 전체적인 개요를 보여주고 있다. 작업흐름은 구현 뷰(Implementation View)를 정의하는 것으로부터 클래스의 구현과 통합의 계획 및 수행까지의 활동을 연결(Span)한다.
[그림 7] 구현 단계
테스트(Test)
테스트는 시스템 전체를 검증한다. 참여하고 있는 클래스들이 잘 어울려져 올바르게 작동하는가를 검증하기 위해서는, 먼저 개별적으로 유스케이스를 테스트한다. 그런 후에 유스케이스 설명서를(어떤 관점에서의) 테스트의 입력 자료로 사용하여 전체적으로 시스템을 테스트한다. 테스트를 끝낸 후에 시스템은 전달되어 진다.
작업자와 작업흐름(Workers and Workflow)
아래의 작업자들은 분석 및 설계에서 정의된다.
테스트 설계자(Test Designer)
통합 테스터(Integration Tester)
시스템 테스터(System Tester)
설계자(Designer)
구현자(Implementer)
다음의 그림은 테스트에서 작업흐름의 전체적인 개요를 보여주고 있다. 작업흐름은 계획에서부터 설계, 구현 그리고 수행하는 테스트 절차(Procedures)까지 전체적인 활동을 연결(Span)한다.
[그림 8] 테스트 단계
▶ 컴포넌트 기반 s/w 개발
장점
- 시간 절약상 디자인된 컴포넌트를 이용, 처음부터 만드는 것보다 개발시간 절약
- 개발시간, 개발비용, 시장 출시기회에서 유리
- 테스트와 디버깅 단계에서 크리티컬한 시간 절약

키워드

시스템 개발 방법론,   폭포수형,   나선형,   점증적 기법,   프로토 타이핑 기법