프로젝트관리

프로젝트에서의 일정계획이란 = 시간, 일, 사람을 정하는 것이다.

💎 개요

💍 소프트엔지니어링 :

• 소프트엔지니어링은 노동집약적이다. 제조업과 매출을 비교 했을 때 제조업의 경우 인건비가 매출의 10%를 차지한다고 본다면 소프트웨어 회사는 인건비가 20~50%까지를 차지한다.

💍 프로젝트 관리 :

• 범위관리 : 가장 중요한 것은 프로젝트의 범위의 관리이다. 즉 해야 할 일과 안 할일을 명확하게 구분하는 것이 중요하다. 프로젝트의 breakdown을 하여 사람간의 역할을 분담 할 때에도 범위 관리의 영역에 해당된다. 사람이 하는 일의 영역을 정할 때는 서로 하는 일이 겹쳐져서는 안된다.

• 일정관리

• 비용관리 : 측면에서 예시로 누군가 새로운 인력이 추가 된다고 할 때, 이 경우 프로젝트에 이해가 부족한 새로운 인력이 기존 인력의 시간을 뺏고, 오히려 더 지체가 될 수도 있다. 그렇기에 초기에 비용을 잘 설정하고 관리하는 것이 중요하다.

• 품질관리 : 고객이 원하는 것과 실제로 개발한 것의 차이를 줄이는 것이 품질관리이다.

• 위험관리 : 예시로 의사소통의 위험성을 들 수 있다.

💎 프로젝트 관리란?

💍 프로젝트

• 정해진 기간 안에 한정된 자원으로 일정한 목적을 달성하기 위해 수행하는 업무

💍 프로젝트 관리 작업

• 프로젝트를 계획하고 수행하는 데 필요한 모든 작업을 총 망라

💍 프로젝트 관리의 실패 사례

• 요인 : 요구변경, 예상치 못한 기술적 문제, 프로젝트 관리의 미숙

• 사례 : KT의 고객 통합 시스템 - 수백억원을 투입하여 개발한 컴포넌트를 통합 시험하지 못하고 결국 실패

💎 소프트웨어 개발 프로세스

💍 즉흥적인 개발 프로세스 : 프로그래밍 -> 만족할 때 까지 수정 -> 개선을 위해 아이디어 짜내기 (반복)

• 좋은 엔지니어링 프로세스를 따르지 않았을 때 일어나느 문제점들 -> 결국 개발과 유지보수에 비용이 증가함

💍 폭포수 모델

💍 점증적 모델

💍 나선형 모델

• 소프트웨어의 기능을 나누어 점증적으로 개발

• 여러 번의 점증적인 릴리스

• 반복 사이클의 단계
  1) 각 사이클의 목표, 대안, 제약 조건 결정
  2) 목표와 제약애 대한 평가 - 위험 요소 분석 및 해결
  3) 다음 레벨의 프로토타입 개발 (분석-설계-코딩)
  4) 다음 사이클을 위한 목표와 계획을 검증

• 나선형 모델의 장점 :
  1) 대규모 시스템 개발에 적함 - 위험성을 낮추는 역할
  2) 반복적인 개발 및 테스트 - 강인성 향상
  3) 한 사이클에 추가 못한 기능은 다음 단계에 추가 가능

• 나선형 모델의 단점 :
  1) 관리가 복잡
  2) 위험 분석을 잘못하여 지나친 경우 피해가 큼
  3) 성공 사례가 많이 알려지지 않음

• 적용 가능한 상황 :
  1) 재정적 또는 기술적으로 위험 부담이 큰 경우
  2) 요구 사항이나 아키텍처 이해에 어려운 경우

💍 Unified Process

• Unified Process 안에 애자일 프로세스가 있고, 애자일 프로세스 안에 익스트림 프로그래밍이 있다.

• 반복적이고 점진적이다.

• 종류 :
  1) Unified 프로세스의 가장 잘 알려지고 광범하게 문서화된 버전은 RUP임
  2) OpenUp
  3) 애자일 프로세스

• RUP의 단계
  1) 도입 : 범위 설정, 구조설계, 일정 및 테스트 계획
  2) 정련 : 아키텍터 설계, 일부 구현
  3) 구축 : 제조 단계, 원시코드 작성
  4) 전환 : 사용자에게 릴리스

💍 애자일 프로세스

• 2주~ 6주간의 짧은 주기로 개발을 반복

• 실행되는 소프트웨어를 개발하여 단계적으로 시스템 전체를 완성

• 대표적 애자일 프로세스 모델 : 익스트림 프로그래밍(XP), 스크럼(scrum)

• 애자일 선언
  1) 형식적인 문서보다는 커뮤니케이션을 통하여 프로젝트가 목표를 향하여 나아가게 함
  2) 사용자는 문서가 아니라 실행되는 소프트웨어를 통하여 요구를 확인
  3) (계약 협상 보다 고객과의 협업이 중요) 사용자의 요구는 비즈니스 환경에 따라 프로젝트 중간에 바뀔 수 있음을 고려
  4) (계획을 따르는 것보다 변경에 대한 응답이 더 중요) 짧은 주기 동안 요구 정의에서 구현, 테스트까지 이루어지며, 각 반복 주기의 반성 의견을 다음 계획에 포함

• 특징
  1) 짧은 릴리스와 반복 : 작업을 작은 조각으로 나눠 되도록 자주 릴리즈
  2) 점증적 설계 : 설계에 대한 많은 지식이 쌓일 때까지 결정을 미룸
  3) 사용자 참여
  4) 문서 최소화
  5) 비공식적 커뮤니케이션
  6) 변화

💍 익스트림 프로그래밍

• 사용자 스토리 : 긴 요구정의 대신 간단한 사용자 스토리를 작성

• 매일 빌드와 통합

• 테스트 주도 개발((TDD) : 코딩 전에 테스트 시나리오 작성 -> 테스트 시나리오를 통과하기 위한 최소한의 코딩 -> 작성한 코드를 리팩토링

• 페어 프로그래밍 : 2인의 프로그래머의 협업 1인- 코딩, 1인- 확인하면서 개발

💍 스크럽

• 개발팀이 개발 연습을 하면서 개발 능력을 향상할 수 있는 프레임워크

• 개발 팀원 모두가 함께 소통하고 협력하여 짧은 주기를 반복하며 소프트웨어를 개발하는 작업방법, 역할, 결과물의 집합체

• 용어
  1) 백로그 : 제품 개발을 위해 남겨진 일
  2) 스프린트 : 스크럽에서의 제품 개발 과정
  

💎 개발 노력의 추정

💍 노력 추정 공식

• 개발에 얼마만큼의 작업이 필요한지를 예측

• 개발 노력 : MM(인원/월)로 나타내는 노동량, 개발 노력의 산정을 금전으로 환산

• 일반적 추정 공식
  

💍 COCOMO 추정 모델

• 기본 모델 단계
  1) 기본형, 중간형, 내장형 중 어떤 프로젝트 유형을 선택. 유형을 선택하면 추정 공식이 결정됨
  2) 프로젝트의 크기, KLOC(kilo lines of code)를 추정. COCOMO 2 에서는 기능점수를 프로젝트 크기로 대신 사용
  3) 비용 승수라고 부르는 15개의 영향 요인에 대해 영향 정보를 예측
  4) 노력 추정 공식에 추정된 값을 넣어 노력을 결정

• 기본 모델 COCOMO-81의 단점
  - 프로젝트 초기에 size 값 예측이 어려움
  - 기본쳬측모델에서 c와 ACCUM(factor)의 값에 영향을 주는 요소들이 주관적
  - 프로그래밍 언어별 Line of Code가 달라짐
  - 충분한 프로젝트 데이터(과거 데이터)를 확보하고 있는 기관이 드묾

💍 COCOMO 2

• 개발 단계에 따라 다음 3가지 모델을 제시
  1) 프로토타이핑 단계에 적용하는 추정방법 -> 기능 점수
  2) 요구가 파악된 후 초기 설계 단계에 추정하는 방법 -> 객체 점수
  3) 설계가 끝난 후 코딩이 시작되기 전에 추정하는 방법 -> LoC

💍 COCOMO 2 - 기능 점수 기반 추정 모델

• 소프트웨어가 갖는 기능의 개수로 소프트웨어의 규모와 복잡도를 나타내고, 이를 시스템 개발에 필요한 기간과 소요 인력 계산의 기초로 삼는 방법

• 소프트웨어를 구성하는 요소인 다음의 5가지로 규모를 산정
  1) 외부 입력 : 사용자가 시스템에 제공하는 입력자료의 개수
  2) 외부 출력 : 시스템이 사용자에게 제공하는 출력의 개수
  3) 외부 질의 : 사용자가 시스템의 특정 기능을 요청하는데 필요한 대화형 질의의 개수
  4) 내부 논리 파일 : 시스템이 유지 보관하는 정보의 그룹
  5) 외부 인터페이스 파일 : 외부 시스템과 인터페이스

💍 COCOMO 2 - 객체 점수 기반 추정 모델

• 객체지향 시스템을 개발할 때 객체를 기초로 한 추정 방법
  - 최종 소프트웨어 제품의 구성요소인 클래스의 개수, 클래스와 관련된 가중치를 바탕으로 노력을 추정

• 객체 점수 기반 추정 기법의 단계
  1) 클래스의 개수를 추정
  2) 인터페이스의 유형을 분류
  3) 총 클래스의 개수 계산
  4) 총 노력을 계산