[협업]개발 학생의 협업 도전기 #2-2.객체지향 개발 방법론(OOAD) : Stage 1000 Planning

지난 포스팅 객체지향 개발 방법론(OOAD) : OOP, UP에서 OOP, UP에 대해 소개하였다.

이번 포스팅부터는 본격적으로 OOPT에 대해 소개하려 한다. OOPT의 첫 번째 단계인 Stage 1000 Planning 단계에서는

이름처럼 제작할 시스템에 대한 명칭, 전반적인 계획, 비전, 투입 금액 산정, 요구사항 정의 등의 스케치 작업들을 수행한다.

시스템 개발 측면에서 크게 할 일은 없고, 비즈니스와 관련한 내용들이 오히려 주를 이룬다.

회사 내에서는 프로젝트 착수전 보고 단계이며, UP에서는 feasibility study를 수행하는 Inception Stage로 대응될 수 있다.

 

INDEX

1. Activity 1001. Define a draft plan
2. Activity 1002. Create Preliminary Investigation Report
3. Activity 1003. Define Requirements
4. Activity 1004. Record Terms in Glossary
5. Activity 1006. Define Business Use Case
6. Activity 1008. Define Draft System Architecture
7. Activity 1009. Develop System Test Case

---

Activity 1001. Define a draft plan

Activity 1001. Define a draft plan stage에서는 개발 배경, 필요성, 요구사항부터 Man month(또는 Person month)까지 프로젝트에서 고려해야 할 비기능적 요소들을 언급한다. 프로젝트 시작 전 간단한 UX를 생각해보는 단계이다.

다른 Activity에 비해 간단하게 진행된다.

우리팀에서 진행한 Draft planning은 아래와 같다.

 

012

Define a draft plan

시계의 컨셉이 위와 같이 정해짐에 따라, Digital Watch System의 이름은 '잘챙기시계'로 결정되었다.

Activity 1002. Create Preliminary Investigation Report

Activity 1002. Create Preliminary Investigation Report에서는 Alternative Solutions, Project Justification, Risk Management, Risk Reduction Plan의 작업들을 논의하고 고려한다.

 

Alternative Solutions와 Project Justification은 하나의 묶음으로 '시스템 자체 개발 타당성'을 검증한다.

먼저, Alternative Solutions에서는 개발 팀에서 개발하려는 시스템이 이미 시장에 존재하는지, 또는 다른 업체에 해당 시스템의 개발을 의뢰하는 방법 등을 고려하는 것으로써, 시스템을 자체 개발하는 것의 대안이 될 수 있는 방법들을 찾는다.

Project Justification에서는 그렇게 찾아진 Alternative Solutions에 비해 개발팀에서 자체 개발하는 것이 더 이점이 많다는 것을 설명한다.

그렇지 않으면 다른 방안들을 통해 시스템을 구축하는 것이 더 경제적이기 때문이다.

자체 개발 타당성 검증 단계를 넘어가면, 프로젝트를 진행하면서 발생할 수 있는 위험 사항들에 대해 고려한다.

Risk Management 단계에서 위험 사항들이 발생할 수 있는 가능성과, 해당 위험성이 프로젝트에 영향을 미치는 정도를 수치화하여 두 수치의 곱을 통해 얻어진 점수가 가장 높은 것 몇 가지를 뽑아내어 위험성을 줄일 수 있는 방법을 Risk Reduction Plan에서 논의한다.

우리 팀이 작성한 Preliminary Investigation Report는 아래 슬라이드와 같다.

 

01

Create Preliminary Investigation Report

Activity 1003. Define Requirements

Activity 1003. Define Requirements에서는 시스템의 기능 요구사항을 Functional Requirements 형태로 작성한다.

여기서 정의된 Functional Requirements들은 Activity 1006에서 정의되는 Business Use Case에 1:1 대응된다.

Functional Requirements는 시스템에 요구되는 사항들을 '시스템 관점'에서 서술한 것으로, 시계를 예시로 하면 '시간 변경' 따위가 있겠다.

Requirements에는 Evident requirements, Hidden requirements 두가지의 category가 존재하는데,

Evident Requirements는 사용자가 시스템에 대해 특정 액션을 취해주면 그 액션에 반응하여 나타나는 requirement이고

Hidden Requirements는 사용자의 특정 액션이 없어도 시스템 내부적으로 수행되는 requirements이다.

가령 '시간 변경하기'는 Evident requirement일 것이고, '시간 흐름'은 Hidden requirement가 될 것이다.

 

이와 같은 방식으로, 시스템이 해야 하는 일을 모두 찾아내는 것이 Activity 1003에서 해야할 일이다.

우리팀의 Functional Requirements는 아래와 같이 도출되었다.

 

012

Define Requirements

Activity 1004. Record Terms in Glossary

Activity 1004. Record Terms in Glossary에서는 소위 'Data Dictionary'를 정의한다.

Data Dictionary라 함은 프로젝트의 전반적인 진행에서 사용될 단어들에 대한 정의를 문서화하는 것을 의미한다.

이것을 만들어두는 이유는 개발 관련 문서들을 한 개발팀에서만 보는 것이 아니라, 검증팀이나 다른 개발팀등 여러 사람이 보게 될 가능성이 크기 때문에 의미의 부정확한 전달을 방지하기 위해서이다.

예를들어 우리팀의 경우 시계의 시간이 흘러가고 있는 화면을 '기본 화면'이라고 정의했는데, 실제로 검증팀에서 기본 화면이 어떤 것인지 모르겠다고 얘기하여서 Data Dictionary를 보여준 적이 있다.

팀 단위의 작업이기 때문에 Data Dictionary 또한 상당히 중요한 부분이기에 공을 들일수록 깔끔한 의사소통에 도움이 된다.

우리팀의 Data Dictionary는 아래와 같다.

01

Data Dictionary

Activity 1006. Define Business Use Case

Use Case Categorization

Activity 1003. Define Requirements에서 사용자가 시스템에게 요구하는 사항들을 만족시키기 위한 여러가지 Functional Requirements들을 도출하였고, 이것이 (Business)Use Case와 1:1 mapping됨을 언급하였다.

언급한대로 Functional Requirements를 Use Case와 대응시키는 것이 Use Case Categorization 단계인데 굳이 이렇게 두 가지를 만들어 서로 mapping하는 이유는, Functional Requirements는 공식 문서인 SRS(Software Requirements Specification)에 기술하기 위함이고 Use Case는 개발자들이 개발 용도로 사용하기 위함이기 때문이다.

 

대략 아래와 같은 형태로 Categorization을 진행한다.

 

Use Case Categorization

 

Use Case Description

Use Case는 개발자들이 개발을 위해 사용할 용도로 작성하는 텍스트 형태의 문서이다.

Use Case에는 3가지 format이 존재하는데, 그에 대한 설명은 아래의 접은글에 작성한다.

Brief Format : 한 단락의 간결한 요약 형태로 작성하며, 일반적으로 (Main)Success Scenario만 작성함.

Casual Format : 비형식적 단락형태로, 다양한 경우를 cover하기 위해 여러 단락으로 작성함.

Casual Format use case

 

Fully-dressed Format : 모든 단계와 변화, supporting sections(i.e 선행조건)를 반영하는 구체적 문서

Fully-dressed format

출처 : Applying UML and Patterns

 

현재는 단순히 시스템이 요구하는 요구사항들이 무엇이 있는가를 찾아내기 위해 Brief format으로 작성하고,

이후 Analysis, Design을 거치면서 현재 정의된 Use Case를 Casual format, Fully dressed format으로 확장해나간다.

 

우리팀이 작성한 Use Case Categorization 및 Use Case Description은 아래와 같다.

012

Use Case Categorization

012345

Use Case Description

Activity 1008. Define Draft System Architecture

Activity 1008. Define Draft System Architecture에서는 시스템의 전체적인 Architecture를 정하는 단계 이전에, Rough한 수준의 Architecture를 미리 뽑아본다.

간단한 Architecture를 정의하는 이유는, 해당 시스템이 Business Use Case를 만족할 수 있는지 판단하고, 앞으로의 프로그램 설계에 있어 시뮬레이션을 해보기 위함이다.

교재상에 기술된 순서는 다음과 같다.

1. Target System의 Logical/Physical layer를 정의

2. 전체 시스템을 여러개의 subsystem으로 분할

3. 분할된 각 subsystem에 business use case를 배치

4. Business Use case를 배치함에 따라 필요한 하드웨어 자원들을 식별하고 작성

 

수업중에는 교재보다는 간단한 방식으로 시계의 어떤 버튼이 어떠한 기능을 하는지 그림으로 나타내었다.

Define Draft System Architecture

Activity 1009. Develop System Test Case

Stage 1000의 마지막 Activity인 1009. Develop System Test Case에서는 시스템이 완성되었을 때 테스트할 테스트 케이스들을 작성한다.

시스템 개발의 초창기에 마지막 단계에나 진행될 테스트 케이스들을 작성하는 것은 V-model의 방법론을 차용한 것이라고 볼 수 있겠다.

이렇게 하는 것의 이점은, 시스템을 분석하고 설계하는 단계에 돌입하면 시스템을 내부 구현 수준의 관점으로 보게 되는 경향이 있어 최대한 시스템 수준에서 테스트를 설계하기 위함이 아닐까 생각한다.

여기서 작성된 시스템 테스트 케이스들은 추후 시스템이 완성되면 검증팀에서 해당 케이스들을 보고 검증하여 시스템이 제대로 동작하는지 확인한다.

 

우리팀이 작성한 시스템 테스트 케이스는 아래와 같다.

012345