[소프트웨어 공학] 3. 프로젝트 계획과 관리

April 19, 2025

INTRO

여러가지 자원, 인력, 비용, 재료, 기술을 효과적으로 사용해 프로젝트 목표를 달성하는 것.

핵심은 시간표를 잘 짜라.
스스로 추적 관리를 해라.
스타트업에 몸담고 있는 교수님의 말씀은 교재 보다는 현장에서 몸으로 느끼는 것이 중요하다고 한다.

실질적으로 학생 입장에서는 이걸 체험해 보기 어렵다고 하시면서 프로젝트를 할때 꼭 규모를 키워서 진행해 보라고 하셨다.
그런 의미에서 지금 하고 있는 졸업 프로젝트, 창업 동아리가 많은 도움이 되는 것 같다.
이 내용은 다른 글에서 정리해 보겠다.

WBS (Work Breakdown Structure)

개발 팀이 프로젝트 목표를 달성하고 결과물을 산출하기 위하여 수행하여야 할 작업을 계층적으로 분할한 것

스케줄링

WBS를 기반으로 일정을 정의 하는 것
스케줄링 결과는 간트 차트로 표현 가능한데 다음과 같은 순서의 작업이 필요하다.

작업 사이의 의존 관계 파악
CPM을 활용해 여유 시간 계산
소요 자원 할당

CPM Network (Critical Path Method Network)

작업의 선후 관계를 따지고 나면 작업이 끝나기 최소 시간을 계산할 수 있다.
수업에서는 실무 관점에서 유용하지는 않은 것 같다고 하셨다.

이걸 하는 이유는 인적 자원이 쉬는 시간, 여유시간(slack time)
즉 낭비되는 시간을 파악하기 위해서이다.
하지만 현실적으로 계획처럼 모든게 진행되기는 힘들다.

구체적으로 간트 차트, 칸반보드로 나타낼 수 있고
Jira confluence를 언급하셨다.

비용 예측 기법

위에서 나온 비용을 실질적으로 계산하고 예측하는 방법이다.

여기서 M은 manpower로 투입되는 인력의 투입 비율의 총합.
쉽게 말해 투입되는 모든 사람이 일할 수 있는 양
예를 들어, 주에 40시간 일하는 사람 2명을 100% 투입하면 manpower는 80이 된다.

그리고 E는 effort로 프로젝트를 수행하기 위해 필요한 총 작업량이다.
예를 들어 위 예시에서 effort가 160시간이라면 D(duration) 걸리는 시간은 2주가 된다.

COCOMO-81

1981년에 등장한 원시 프로그램의 규모에 의한 방법을 말한다.
완성될 시스템의 규모를 추정하고 이를 준비된 수식에 대입해 소요 MM(Man-Month)을 예측한다.

노력 = A * (SIZE)^B * M
으로 나와 있는데 A는 개발 기관의 특징, 소프트웨어 유형에 좌우되는 상수.
Size는 개발될 소프트웨어의 원시코드 라인수나 기능 점수.
B는 노력 승수로 1에서 1.5사이의 값으로 프로젝트에 대한 노력이 규모에 선형적으로 비례하지 않는다는 것을 의미한다.

COCOMO-81에서는 규모(size)를 KDSI(Kilo Delivered Source Instructions)로 정의한다.
표에서 볼 수 있듯이 규모가 커질수록, 복잡한 시스템일수록 2.4, 3.0, 3.6으로 계수가 증가하고 차수도 1.05, 1.12, 1.20으로 증가한다.

COCOMO2

COCOMO-81의 단점을 보완하기 위해 1995년에 발표된 모델이다.
소프트웨어 개발 프로젝트가 진행된 정도에 따라 세가지 다른 모델을 제시한다.

1 단계: 프로토타입 만드는 단계 화면이나 출력 등 사용자 인터페이스, 3 세대 언어 컴포넌트 개수를 세어 응용 점수(application points)를 계산
이를 바탕으로 노력을 추정
2 단계: 초기 설계 단계
자세한 구조와 기능을 탐구
3 단계: 구조 설계 이후 단계
시스템에 대한 자세한 이해

1단계에서 설명한 응용 점수를 추정하는 과정은 다음과 같다.

특히 5번을 주목하라고 하셨는데, 재사용률이 높아야 빠르고 효율적으로 개발할 수 있으며
객체 지향적인 설계를 강조하셨다.
이는 뒤에서 나온다.

기능 점수를 추정할때는 LOC (Line of Code)를 사용한다고 하는데,
이는 구조적인 설계나 코드를 짧고 효율적으로 작성하는 능력과도 연관이 있을 수 있기 때문에
효율적이지 않을 수 있다고 한다.
맞는 말인 것 같다

PM 연습문제

FP 연습 문제

뭔가 좀 이상한데 시험에 나올 듯

프로젝트 팀 조직

팀 역할에는 크게

프로젝트 관리자 Product Manager
시스템 운영자 System Administrator
시스템 분석가 System Analyst
소프트트웨어 아키텍트 Software Architect
소프트웨어 개발자 Software Developer
데이터베이스 엔지니어 Database Engineer

여기서 또 실질적인 이야기를 해주셨다
예를 들어 PM 하지마라.. ㅋㅎㅎㅎ
사람 관리하고 사람 대하는 일이 참 힘들다
어찌보면 개발만 하는게 행복한 일이다
갑 을 병이 있으면 을보다는 병이 나을 수 있다.. 왜냐하면 을이 풍파를 맞아주기 때문에..?

추가적으로 우리는 개발자가 아니라
아키텍트, 엔지니어가 되어야 한다고 하셨다.
공장으로 치면 디자인, 설계를 하는 사람이 되어야 하지
조립만 하는 사람이 되면 곤란하다고 하셨다.

이 부분에서는 개인적으로 PM처럼 사람 관리하는게 힘들지만, 꼭 할줄 알아야 한다 그리고 그래야 높이? 올라갈 수 있다라고 역설적으로 말하시는 걸로 들렸다.
개발 실력은 당연한거고..
그래서 소프트웨어 공학이라는 과목이 중요한 것 같다.

직능별 조직

프로젝트별 조직

실행, 모니터링

앞에서는 계획에 대한 이야기고
이제 계획을 실행하면서 잘 실행되고 있는지 모니터링하는 단계이다.

BAC (Budget at Completion) = 예산의 총합
EV (Earned Value) = 실제로 완료된 작업의 가치
AC (Actual Cost) = 실제로 사용된 비용
CV (Cost Variance) = EV - AC
PV (Planned Value) = 계획된 작업의 가치

위 그림에서 계획된 비용보다 EV가 작기 때문에
계획된 일정보다 늦어지고 있는 상황이라고 분석 할 수 있다.

AC가 EV보다 크기 때문에
비용이 초과되고 있는 상황이라고 분석 할 수 있다.

예제 - EV 분석

3.1 ~ 3.10 계획과 3.7 ~ 3.20 계획이 있고 오늘은 3.3이다.
최종적으로 구하고 싶은 값은 TCPI (To Complete Performance Index)이다.
즉 현재 상황으로 프로젝트를 끝낼때 까지 얼마만큼 비용이 필요한지 예측하려는게 목표다.

그 과정을 보면
현재 상황을 정리한다 - BAC, PV, EV, AC
일정 관점에서 현재 상황을 정리한다 - SV = EV - PV, SPI = EV / PV
비용 관점에서 현재 상황을 정리한다 - CV = EV - AC, CPI = EV / AC
미래 상황을 예측한다 - ETC = (BAC - EV) / CPI, EAC = AC + (BAC - EV), VAC = EV - AC, TCPI = (BAC - EV) / (BAC - AC) OR (BAC - EV) / (EAC - AC)

풀어서 하나씩 풀어서 보면
BAC (Budget at Completion) : budget이라고 생각하면 된다(예산)
PV (Planned Value) : 지금까지 완료했어야 하는 가치
EV (Earned Value) : 지금까지 완료된 가치
AC (Actual Cost) : 지금까지 사용된 비용

SV (Schedule Variance) : 계획에 비해 현재 얼마나 진행 되었는지
EV - PV, 음수라면 계획보다 지연되고 있는 상황
SPI (Schedule Performance Index) : 계획에 비해 얼마나 진행 되었는지 비율
EV / PV, 1보다 작다면 계획보다 지연되고 있는 상황

CV (Cost Variance) : 계획에 비해 현재 얼마나 비용을 사용했는지
EV - AC, 음수라면 계획보다 비용이 초과되고 있는 상황 (가치를 못내주고 있다고 해석가능)
CPI (Cost Performance Index) : 계획에 비해 얼마나 비용을 사용했는지 비율 (일을 얼마나 잘하고 있는지로 해석)
EV / AC, 1보다 작다면 일을 잘 못하고 있는 상황

ETC (Estimate to Complete) : 남은 작업을 완료하기 위해 필요한 비용
(BAC-EV) / CPI
남은 비용은 BAC - EV, 일을 하는데 비용이 얼마나 드는 의미인 CPI로 나눈다
EAC (Estimate at Completion) : 프로젝트가 끝날때까지 예상되는 총 비용
AC + (BAC - EV)
현재까지 쓴 비용 + 남은 비용
VAC (Variance at Completion) : 프로젝트가 끝날때까지 예상되는 총 비용과 예산의 차이
EV - AC
TCPI (To Complete Performance Index) : 프로젝트가 끝날때까지 예상되는 총 비용과 예산의 차이를 고려한 성과 지수
(BAC - EV) / (BAC - AC) OR (BAC - EV) / (EAC - AC)
BAC - EV 더 써야하는 비용, BAC - AC는 쓸수 있는 남은 비용
이걸로 나누면 남은 비용을 얼마나 잘 써야하는지 알 수 있다.
조정된 예산을 고려했을 때 (BAC - EV) / (EAC - AC)라고 하는데 계산하면 (BAC - EV) / (BAC - EV)랑 똑같아서 항상 1..? 조금 이상하다