2. 프로젝트 계획 및 분석

02 프로젝트 계획 및 분석
Section 1. 프로젝트 계획

1. 프로젝트 관리

⑴ 프로젝트 관리의 개념

- 특정한 목적을 가진 프로젝트를 한정된 기간, 예산, 자원 내에서 사용자가 만족할 만한 제품을 개발하도록 행하는 기술적, 관리적 활동

⑵ 프로젝트 핵심 관리대상(3P)

- 사람(People)
- 문제(Problem)
- 프로세스(Process)

⑶ PMBOK(Project Management Body of Knowledge)

- PMI(Project Management Institute)에서 제작한 프로젝트 관리 프로세스 및 지식 체계
■ PMBOK 5단계 프로세스 그룹
- 1단계 : 프로젝트 착수
- 2단계 : 프로젝트 계획
- 3단계 : 프로젝트 실행
- 4단계 : 프로젝트 통제
- 5단계 : 프로젝트 종료

 

2. 개발 비용 산정

3. 개발 일정 산정

⑴ 소프트웨어 개발 일정 계획

■ 작업 순서
- 작업분해(Work Breakdown Structure)
- CPM 네트워크 작성
- 최소 소요 기간을 구함
- 소요 M/M, 기간 산정하여 CPM 수정
- 간트 차트로 표현

⑵ WBS(Work Breakdown Structure)

- 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화 하는 작업

⑶ Network Chart(PERT/CPM)

■ CPM 소작업 리스트
작업

선행작업

소요기간(일)

A

-

15

B

-

10

C

A, B

10

D

B

25

E

C

15

■ CPM 네트워크 작성

■ 소요기간 산정
- 임계경로(Critical Path) : 40일
- D의 가장 빠른 착수일 : 10일
- D의 가장 늦은 착수일 : 15일
- D의 여유기간 : 5일

⑷ 간트 차트(Gantt chart)

- 일정 계획의 최종 산출물
- 프로젝트 일정관리를 위한 바(bar)형태의 도구

Section 2. 요구사항 분석

1. 현행 시스템 분석

⑴ 현행 시스템 파악

- 현행 시스템이 어떤 하위 시스템으로 구성되어 있는지
- 제공하는 기능이 무엇인지
- 다른 시스템들과 어떤 정보를 주고받는지
- 어떤 기술요소를 사용하고 있는지
- 사용하고 있는 소프트웨어 및 하드웨어는 무엇인지
- 네트워크는 어떻게 구성되어 있는지

⑵ 플랫폼 기능 분석

① 플랫폼 정의
- 어플리케이션을 구동시키는데 필요한 하드웨어와 소프트웨어의 결합

② 플랫폼의 유형
■ 싱글 사이드 플랫폼(single-side platform)
- 제휴 관계를 통해 소비자와 공급자를 연결하는 형태
■ 투 사이드 플랫폼(two-side platform)
- 두 그룹을 중개하고 모두에게 개방하는 형태
■ 멀티 사이드 플랫폼(multi-side platform)
- 다양한 이해관계 그룹을 연결하여 중개하는 형태

⑶ 미들웨어(Middleware) 분석

① 미들웨어 개념
- 양 쪽을 연결하여 데이터를 주고 받을 수 있도록 중간에서 매개 역할을 하는 소프트웨어

② 미들웨어 종류
■ RPC(Remote Procedure Call)
- 클라이언트가 원격에서 동작하는 프로시저를 호출하는 시스템
■ MOM(Message Oriented Middleware)
- 응용 소프트웨어 간의 데이터 통신을 위한 소프트웨어
- 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어
■ ORB (Object Request Broker)
- 객체지향 시스템에서 객체 및 서비스를 요청하고 전송할 수 있도록 지원하는 미들웨어
■ DB 접속 미들웨어
- 애플리케이션과 데이터베이스 서버를 연결해주는 미들웨어
■ TP 모니터
- 온라인 트랜잭션을 처리 및 감시하는 미들웨어
■ WAS(Web Application Server)
- 동적인 콘텐츠를 처리하기 위한 미들웨어
■ ESB(Enterprise Service Bus)
- 메시지 기반으로 느슨한 결합형태의 표준 인터페이스 통신을 지원하는 미들웨어

2. 요구 공학

⑴ 요구공학 개념

- 고객 요구를 체계적으로 수집, 분석, 명세화, 검증하고 추적, 변경되는 요구사항을 도출하고 관리하는 기법

⑵ 요구공학의 필요성

- 분석의 어려움
- 요구사항 변화
- 관점별 차이 발생

⑶ 요구사항의 분류

■ 기능적 요구사항
- 소프트웨어를 구성하는 기능들이 무엇인지를 정의한 것
■ 비기능적 요구사항
- 소프트웨어의 기능들에 대한 조건과 제약 사항들이 무엇인지 정의한 것
- 보안, 성능, 품질, 안정성 등

⑷ 요구사항 개발 프로세스

① 도출
- 소프트웨어가 해결해야 할 문제를 이해하고 요구사항이 어디에 있고, 어떻게 수집할 것인가를 확인

② 분석
- 요구사항들 간에 상충 되는 것을 해결
■ 구조적 분석 도구
- DFD(Data Flow Diagram) : 자료 흐름도
- Data Dictionary : 자료 사전
- Mini-Spec : 소단위 명세서
- ERD(Entity Relationship Diagram) : 개체 관계도
- STD(State Transition Diagram) : 상태 전이도
■ 객체지향 분석 도구
- UML(Unified Modeling Language)
- 모델링

③ 명세
- 정형 명세 기법
- 비정형 명세 기법

④ 확인
- 분석가가 요구사항을 이해했는지 확인(Validation)
- 요구사항 문서가 일관성 있고 완전한지 검증(Verification)

⑸ 요구사항 분석 도구

① 요구사항 분석 CASE(Computer Aided Software Engineering) 도구
분류
상위 CASE

하위 CASE
통합 CASE

설명
- 생명주기 전반부에 사용되며, 소프트웨어의 계획과 요구분석, 설계 단계를 지원한다.
- 모순검사, 오류검사, 자료흐름도 작성 등의 기능을 수행한다.
- 생명 주기 후반부에 사용되며, 코드의 작성과 테스트, 문서화 하는 과정을 지원한다.
- 구문 편집기, 코드 생성기 등의 기능을 수행한다.
- 소프트웨어 생명주기에 포함되는 전체 과정을 지원한다.

② HIPO(Hierarchy Inut Process Output)
■ HIPO 의 개념
- 하향식 소프트웨어 개발을 위한 문서화 도구
■ HIPO Chart 종류
- 가시적 도표 (Visual Table of Content)
- 총체적 도표 (Overview Diagram)
- 세부적 도표 (Detail Diagram)

3. 요구사항 분석 모델링

⑴ 모델링의 개념

- 복잡한 시스템을 쉽게 이해하기 위해 불필요한 부분을 생략하고 추상화하여 간단한 모델로 표현하는 것을 의미

⑵ 구조적 분석 모델

■ 자료 흐름도(DFD, Data Flow Diagram)
- 자료의 흐름과 처리 과정을 도형 중심으로 기술
■ 자료사전(Data Dictionary, DD)
- 자료흐름도에 기술된 모든 자료들에 대한 사항을 자세히 정의
- 이름 + 주소 + [남|여] + {대여목록}
■ 소단위 명세서(Mini-Specification)
- 자료 흐름도에서 어떤 일이 수행되는지를 정의하기 위해 각 처리들이 수행하는 업무를 상세하게 작성
■ 개체 관계도(Entity Relationship Diagram, ERD)
- 시스템에서 처리되는 개체(자료)와 개체의 구성과 속성, 개체 간의 관계를 표현하여 자료를 모델화하는데 사용
■ 상태 전이도(State Transition Diagram, STD)
- 시스템에 어떤 일이 발생할 경우 시스템의 상태와 상태 간의 전이를 모델화한 것

⑶ 객체 지향 분석 모델

① 객체 지향 분석
- 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 이와 연관된 속성과 연산, 그들 간의 관계
등을 정의하여 모델링하는 작업

② 객체지향 분석 방법론
■ Rumbaugh(럼바우) 방법
- 객체 모델링 (Object Modeling) : 객체 다이어그램
- 동적 모델링 (Dynamic Modeling) : 상태 다이어그램
- 기능 모델링 (Functional Modeling) : 자료 흐름도(DFD)
■ Booch(부치) 방법
- 미시적 개발 프로세스와 거시적 개발 프로세스를 모두 사용하는 분석 방법
■ Jacobson 방법
- Use case를 강조하여 사용하는 분석 방법
■ Coad와 Yourdon 방법
- E-R 다이어그램을 사용하는 기법
■ Wirfs-Brock 방법
- 분석과 설계간 구분 없음