프로젝트 계획

1. 프로젝트 관리

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

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

PMBOK(Project Management Body Of Knowledge)

PMI(Project Management Institute)에서 제작한 프로젝트 프로세스 및 지식 체계
5단계 프로세스 그룹
- 착수-계획-실행-통제-종료

2. 개발 비용 산정

1. 소프트웨어 계발 비용 계획

개발에 소요되는 인원, 자원, 기간 등으로 소프트웨어의 규모를 파악하여 필요한 비용을 산정
비용 계획 결정 요소 (개발자 역량, 소프트웨어 크기와 복잡도, 개발기간, 요구되는 신뢰도 & 기술 수준)
비용 산정 기법

기법	종류
하향식 산정 기법	- 전문가 판단 기법
	- 델파이 기법
상향식 산정 기법	- 원시 코드 라인수(LOC, Line of Code)
	- 개발 단계별 노력 기법
수학적 산정 기법	- COCOMO 기법
	- PUTNAM 기법
	- FP(기능 점수) 기법

2. 하향식 산전 기법(Top-Down)

1) 전문가 기법

조직 내 경험있는 전문가가 비용 산정

2) 델파이 기법

여러 전문가의 의견을 종합하여 판단

3. 상향식 산정 기법(Bottoms-Up)

1) LOC(원시코드 라인수) 기법

비관치(가장 많은 라인 수), 낙관치(가장 적은 라인수), 중간치(평균 라인 수)
LOC = 낙관치 + (4 * 중간치) + 비관치)/6

2) 단계별 인원수(MM)기법

LOC를 발전시켜 더 정확함

4. 수학적 산정 기법

1) COCOMO 기법

개발할 S/W의 규모를 예측한 후 S/W 종류에 따라 각 비용 산정 공식에 대입하여 비용을 산정하는 기법
LOC 기법을 개발유형에 따라 다르게 적용한 기법

COCOMO 기법 - 개발유형

개발 유형	설명
조직형(Organic Mode)	- 5만 라인 이하의 프로젝트
	- 일반 업무용 소프트웨어
반분리형(Semidetached Mode)	- 30만 라인 이하의 프로젝트
	- 운영체제, DBMS 등
내장형(Embedded Mode)	- 30만 라인 이상의 프로젝트
	- 미사일 유도 시스템, 신호기 제어 시스템 등 복잡한 프로젝트

2) Putnam 기법

Putnam이 제안
시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다
대형 프로젝트에 이용
개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소
SLIM: Rayleigh-Norden 곡선과 Putnam 예측 모형을 기초로 개발한 자동화 추정도구

3) 기능 점수 기법(FP, Function Point)

기능별로 기능을 구현하는데 얼마인지 산정 후 합산하는 방법
A.J,Albrecht가 고안
ESTIMACS: FP모형을 기초르 개발된 자동화 추정 도구
소프트웨어 기능 분류

비용산정에 이용되는 요소
- 자료 입력, 정보 출력, 명령어, 데이터 파일, 필요한 외부 루틴과의 인터페이스

개발 일정 산정

1. 소프트웨어 개발 일정 계획

소프트웨어를 개발하기 위해 어떤 작업이 필요한지 정의
작업의 우선순위를 정하여 일정 계획을 세움
작업 순서:
1. 작업분해
2. CPM 네트워크 작성
3. 최소 소요기간을 구함
4. 소요 M/M, 기간 산정하여 CPM 수정
5. 간트 차트로 표현

2. WBS(Work Breakdown Structure)

프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화 하는 작업
WBS 작성방법
- 전체를 큰 단위로 분할
- 각각의 부분에 대해 작은 단위로 분해 -> 계층적 표현
- 담당인원 배치
  그룹 프젝에서 임무분담 역할의 상세화된 버전

3. Network Chart(PERT/CPM)

1) PERT

미해군 Polaris 미사일 일정계획을 관리하기 위해 개발됨
시간을 모를때 시간단축을 목표로 함
낙관치, 기대치, 비관치로 나누어 예측치 구함
예측치 = (낙관치 + (4 * 기대치) + 비관치) / 6

2) COM

미국 듀폰사와 레밍톤사의 화학공장 유지 및 관리를 위해 개발됨
최소비용을 고려하여 시간 단축을 목표로 함

3) PERT/CPM

작업의 선/후행 관계를 고려하여 완료시간을 결정(PERT) 추가비용 투입을 고려햐여 완료시간을 단축하는(CPM) 분석 기법
입계경로(Critical Path)
- 프로젝트를 끝내기 위해 필요한 최소 소요기간(사실상 PERT/CPM의 최대길이)

4) 간트 차트(Gantt chart)

일정 계획의 최종 산춘물
일정관리를 위한 바 형태로 업무별 일정의 시작과 끝을 보여줌
업무(activities) 사이의 관계를 보여줌

Work Breakdown Structure -> PERT/CPM(임계 경로) -> 간트 차트

요구사항 분석

1. 현행 시스템 분석

1. 현행 시스템 파악

정의: 시스템의 구성, 기능, 하드웨어, 네트워크, 데이터베이스 등을 파악하는 활동
목적: 개발하고자 하는 시스템의 개발범위 및 이행 방향성 설정에 도움을 줌

2. 플랫폼 기능 분석

플랫폼 정의: 애플리케이션을 구동시키는데 필요한 하드웨어+소프트웨어
하드웨어 플랫폼, 소프트웨어 플랫폼(운영체제), 서비스 플랫폼(구글, 네이버 등등)
플렛폼의 유형:
- 싱글 사이드 플랫폼(single-side platform)
- 투 사이트 플랫폼(two-side platform)
- 멀티 사이트 플랫폼(multi-side platform)
CPND(Contents Platform Network Device)
- 콘텐츠를 플랫폼에 맞게 가공하고 네트워크를 통해 사용자의 단말기로 서비스가 이루어짐을 표현하는 무선 인터넷 서비스의 가치사슬
- 컨텐츠 - 플랫폼 - 네트워크 - 장비를 맞추는 과정

3. 운영체제 분석

운영체제 개념: 컴퓨터 시스템 자원을 효율적으로 관리하여 사용자가 컴퓨터를 편리하게 사용할 수 있도록 환경을 제공해주는 시스템 소프트웨어
하드웨어+소프트웨어 사용하게 만들어줌
종료: UNIX, Linux, Windows, MacOS, iOS, Android, 윈오우폰 OS

4. 네트워크 분석

네트워크 개념: 노드(컴퓨터)들이 지원을 공유할 수 있게 하는 디지털 전기 통신망
프로토콜: 데이터를 교신하기 위한 통신 규칙
- 3요소: 구문(Syntax), 의미(Semantic), 타이밍(Timing)

5. DBMS(Database Management System) 분석

개념: 사용자, 애플리케이션 등의 상호 작용을 위해 데이터를 저장하고 분석하는 소프트웨어

관계형 데이터베이스를 가장 많이 씀 (Oracle, MySQL, MsSQL 등)

6. 미들웨어(Middleware) 분석

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

원격 프로시저 호출(RPC, Remote Procedure Call)
- 클라이언트가 원격에서 동작하는 프로시저를 호출
메시지 지향 미들웨어(MOM, Message Oriented Middleware)
- 응용 소프트웨어 간의 데이터 통신을 위한 소프트웨어
- 메시지 기반
- 비동기식
  MOM에 메세지들을 쌓아두고 WAS가 여유 있을때 처리
ORB(Object Request Broker)
- 객체지향 시스템에서 객체 및 서비스 요청, 전송을 지원함
DB 접속 미들웨어:
- 앱 - DB 연결을 도와줌
- ex) ODBC, JDBC
TP 모니터
- 분산 시스템의 앱 지원
- 트랜잭션이 올바르게 처리되고 있는지 데이터를 감시, 제어
웹 애플리케이션 서버(WAS, Web Application Server)
- 동적인 콘텐츠를 처리하기 위한 미들웨어
엔터프라이즈 서비스 버스(ESB, Enterprise Service Bus)
- 메시지 기반으로 느슨한 결합형태의 표준 인터페이스 통신을 지원하는 미들웨어
- 기업 안팎에 있는 모든 시스템 환경을 연동하는 미들웨어

2. 요구 공학

1. 요구사항 개념:

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

2. 요구사항 필요성:

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

3. 요구사항 분류:

1) 참여자 관점

사용자 요구사항
시스템 요구사항
소프트웨어 요구사항

2) 요구사항 내용의 종류 (중요!)

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

4. 요구사항 개발 프로세스

도출 -> 분석 -> 명세 -> 확인

도출(Elicitation)
- 요구사항 소스
- 요구사항 도출 기법:
  - 인터뷰(interview)
  - 관찰 또는 문화기술적 연구(ethnography)
  - 사용자 스토리
  - 시나리오
  - 설문조사
  - 브레인 스토밍
  - 포커스 그룹(사용자 대표들이 브레인스토밍)
분석(Analysis)
- 요구사항 분류
- 개념 모델링 및 요구사항 할당
- 요구사항 협상
- 업무환경과 상호작용 파악(도메인 분석)
- 구조적 분석 도구:
  - DFD(Data Flow Diagram): 자료흐름도
  - Data Dictionary: 자료 사전
  - Mini-Spec: 소단위 명세서
  - ERD(Entity Relationship Diagram): 개체 관계도
  - STD(State Transition Diagram): 상태 전이도
- 객체지향 분석도구
  - UML(Unified Modeling Language)
  - 모델링
명세(Specification)
- 문서를 작성하는 단계
- 산출물: 시스템 정의서, 시스템 요구사항 명세서, 소프트웨어 요구사항 명세서 등

구분	정형 명세 기법	비정형 명세 기법
기반	수학, 논리학	자연어, 그림 중심
작성 기법	수학적 기호, 정형화된 표기법	일반 명사, 동사등 자연어나 다이어그램으로 작성
장점	명세 오류 및 모호성 쉽게 파악	의사전달이 편함
단점	작성이 어렵고, 시간이 많이 걸림	내용이 모호, 검증이 곤란
언어 종류	VDM, Z, Petri-net, CSP 등	FSM, Decision Table, ER 모델링, State Chart 등

확인(Validation)
- 확인, 검증: Validation, Verification
- 형상관리 수행

요구사항 분석 기법:
요구사항 분류(Requirement Classification) - 기능 / 비기능 분류
개념 모델링(Conceptual Modeling)
요구사항 할당(Requirement Allocation)
요구사항 협상(Requirement Negotiation)
정형 분석(Formal Analysis)

요구사항 분석 도구
1) 요구사항 분석 CASE(Computer Aided Software Engineering) 도구
분류
상위 CASE: 생명주기 전반부에 사용, 분석, 설계
하위 CASE: 생명주기 후반부에 사용, 구현, 테스트
통합 CASE: 전체 과정에서 사용
종류
SADT(Structured Analysis and Design Technique)
TAGS(Technology for Automated Generation of Systems)
PSL(Problem Statement Language)/PSA(Problem Statement Analyzer)
미시간 대학에서 개발
SREM(Software Requirements Engineering Methodology)
실시간 처리 소프트웨어 시스템에서 사용

2) HIPO(Hierarchy Input Process OutPut)

하향식 소프트웨어 개발을 위한 문서 도구
가시적 도표(Visual Table of Content)
- 흐름을 보여줌
- 입력, 출력, 처리 없음
총체적 도효(Overview Diagram)
- 기능을 기술
- 입력, 출력, 처리 있음
세부적 도표(Detail Diagram)
- 총체적 도표보다 상세히 기술되는 도표

3. 요구사항 분석 모델링

1. 모델링 개념:

복잡한 시스템을 쉽게 이해하기 위해 그림으로 표현

2. 모델링 구분

구분	설명
기능적 모델링	- 시스템의 기능을 사용자 관점으로 표현
	- 사용 사례 다이어그램, 엑티비티 다이어그램
정적 모델링	- 시스템을 구조화하여 클래스 단위로 표현
	- 클래스 다이어그램
동적 모델링	- 시스템이 어떤 기능을 수행하는지의 상호작용 표현
	- 순서 다이어그램, 상태 다이어그램, 커뮤니케이션 다이어그램

3. 분석 모델의 종류:

구조적 분석 모델: 하향식
객체 지향 분석 모델: 상향식
정보공학 분석 모델
정형화 분석 모델

4. 구조적 분석 모델

도구:

자료 흐름도(DFD, Data Flow Diagram)
- 자료의 흐름과 처리 과정을 도형 중심으로 기술
- 자료 흐름 그래프 또는 버블 차트라고도 함
자료사전(DD, Data Dictionary)
- 자료흐름도에 기술된 자료들에 대한 자세한 정의

기호	의미
=	자료의 정의: ~로 구성되어 있다(is composed of)
+	자료의 연결: 그리고(and)
()	자료의 생략: 생략 가능한 자료(Optional)
[\|]	자료의 선택: 또는(or)
{ }	자료의 반복(Iternation of)
* *	자료의 설명: 주석(Comment)

ex) 회원정보 = 회원번호 + 회원성명 + [전화번호 휴대폰번호]

소단위 명세서(Mini-Specification) aka 프로레스 명세서
- 자료흐름도에서 어떤 일이 수행되는지를 정의하기 위해서 각 처리들이 수행하는 업무를 상세하게 작성
개체 관계도(ERD, Entity Relationship Diagram)
- 개체의 구성과 속성, 관계를 표현하여 모델화하는데 사용

출처: https://gitmind.com/erd-examples.html

상태 전이도(STD, State Transition Diagram)
- 상태와 상태간의 전이를 모델화한 것

5. 객체 지향 분석 모델

1) 객체 지향 분석

모든 클래스, 관련된 속성과 연산, 그리고 그들 간의 관계를 정의하여 모델링
1) 객체지향 분석 방법론
Rumbaugh(럼바우) 방법
- 가장 일반적으로 사용
- 객체모델, 동적 모델, 기능 모델로 나누어 수행 (객동기)

객체: 객체 동적: 상태 기능: DFD

Booch(부치) 방법
- 미시적, 거시적 프로세스를 사용
Jacobson 방법
- Use case강조
Coad와 Yourdon 방법
- ERD를 사용
Wirfs-Brock 방법
- 분석과 설계 구분이 없음
- 고객 명세서를 평가하여 설계 작업까지 한번에

프로토타입 (Prototype):
실제 제품 또는 시스템의 초기 버전 또는 모델
아이디어 또는 컨셉을 시각화, 실험하기 위해 사용
주로 개발자, 디자이너, 고객 등과의 의사소통과 이해를 돕고, 제품이나 시스템의 동작과 기능을 빠르게 테스트하고 개선하는 데 사용됨
프로토타입은 실제로 작동할 수 있는 기능을 포함할 수도 있고, 간단한 모형일 수도 있음

와이어프레임 (Wireframe):
인터페이스의 구조와 레이아웃을 시각적으로 표현한 저작물
주로 간단한 선, 상자, 텍스트 등을 사용하여 웹 페이지 또는 애플리케이션의 레이아웃과 기능을 나타냄
사용자 인터페이스의 요소, 배치, 탐색 구조 등을 보여줌으로써 개발자, 디자이너 및 이해 관계자들 간의 의사소통과 공유를 돕음
디자인의 초기 단계에서 사용되며, 아이디어를 시각화하고 개념을 확인하기 위해 사용됨
일반적으로 그림판, 와이어프레임 도구 등을 사용하여 작성됨

스토리보드 (Storyboard):
시각적인 이야기 또는 순서에 따라 캡처된 이미지 또는 일러스트레이션의 시퀀스
주로 애니메이션, 영화, 게임 등의 스토리를 전달하고 구성하기 위해 사용됨
스토리의 흐름과 시퀀스, 각 장면의 레이아웃, 캐릭터 및 이벤트 등을 시각적으로 표현함
사용자 이해, 시나리오 설명 및 컨셉 전달 등에 사용됨
대부분의 경우, 스토리보드는 그림이나 일러스트레이션의 형태로 작성되며, 필요에 따라 텍스트나 주석이 추가될 수 있음

목업 (Mockup):
실제 디자인의 모형 또는 시각적 표현
완성된 디자인의 모습과 사용자가 상호작용하는 방식을 시뮬레이션함
사용자 인터페이스의 외관과 느낌을 보여주기 위해 사용됨
디자인의 최종적인 모습과 레이아웃, 색상, 폰트 등의 디자인 요소를 포함함
주로 그래픽 디자인 도구를 사용하여 디자인됨

[정보처리기사]1과목 소프트웨어 구축-2.프로젝트 계획 및 분석