3. 계획

1. 계획이 필요한 이유

• 허술하면 실패 확률이 높다.
• SW 계획에 들어가는 세 가지: 비용, 기간, 자원(인력).
• 계획 없으면 일정 지연 → 비용 초과 → 품질 저하 → 유지보수비 증가.
• 어려움: 계획 다음이 요구분석인데, 지금은 요구가 흘릿한 상태에서 수치·기간을 잡아야 한다.
• 폭포수에서 계획은 개발 이전. 계획 단계에서 다루는 내용: 문제 정의 / 타당성 분석 / 비용 산정 / 일정 계획 / 위험 분석.

2. 문제 정의

• 개발의 첫 작업. 무엇을 만들지 범위를 정한다.
• 초기 타당성·초기 계획의 기초 자료. 정의가 바뀌면 계획을 다시 쓴다.
• 필요 사항 3가지
  • 도메인 지식: 코딩만으로는 부족. 금융이면 금융, 자동차면 전장 상식.
  • 현재 시스템을 써 본다. 세상에 없는 것을 제로 만드는 일은 드물다. 팀 프로젝트는 기존 키오스크를 참고하는 케이스.
  • 실무 담당자 면담·자료 수집 후 분석. 요구분석 이전에도 정보를 모아야 한다.
• 교수: “내 생각에는 이렇 것 같다”는 무모. 세 가지 모두 근거를 만드는 작업.

3. 타당성 분석

경제적 (Economic)

• 투자 효율(cost-benefit) + 시장성(marketability).
• B2B: 고객사 RFP·기술영업으로 설득 가능. B2C: 일반 대중 예측이 어렵다.
• 한 줄: 만들어서 돈이 되는가.

기술적 (Technical)

• 현재 기술로 요구 기능을 구현할 수 있는가.
• 하드웨어 성능이 받쳐줘 주는가, 개발자 기술력은 되는가.
• 계약서는 법적 의무. “돈 될 것 같으니 무조건 갑시다”가 아니라 진짜 될 수 있는지 확인.
• 사례: 과제에서 소프트웨어만으로 불가능한 폴리곤 성능을 목표로 적었다. 1년 평가 실패 → 개발비 환수 + 업체 교체. 다음 회사는 GPU 칩을 쓰면 될 수 있다는 기술적 타당성을 보고 받았다. 계약서에 칩 금지 조항이 없었기 때문.

법적 (Legal)

• 개발용 SW·도구 라이선스, 지적소유권, 프로그램 보호법.

4. 개발 비용 산정이 어려운 이유

• 전자제품·건축은 재료·평당가 속으로 원가가 나온다. SW는 사람 의존 + 프로세스 다양 + 생산성·품질 편차가 크다.
• 비용에 영향하는 요소
  • 프로그래머 자질: 초급·고급 생산성 차이가 크다
  • 복잡도: Brooks — 앱리케이션 보다 유틸리티 3배, 유틸리티보다 시스템 3배 어렵다
  • 크기: 인력·기간·복잡도 같이 증가
  • 가용 시간: 인력을 늘린다고 무한 단축 불가. Boehm — 정상 계획 대비 최대 75%까지만 줄일 수 있다
  • 신뢰도: 높을수록 비용 증가
  • 기술 수준: 고급언어가 저급언어 대비 생산성 5—10배

5. 비용 산정 기법

5-1. 하향식

• 과거 유사 경험으로 회의. 비과학적.
• 전문가 판단: 신뢰는 높으나 경험 의존이라 정확도는 낮다. 입찰·초급 산정에 쓸.
• 델파이 = 전문가 판단 + 조정자(coordinator). 전문가가 각자 산정 → 조정자가 의견 낭독 → 의견 일치 여부 → 불일치면 다시 산정.

5-2. 상향식

• 세부 작업별로 산정 후 합산.
• M/M (Man/Month): 1명이 1개월 일한 양. PM(Person/Month)는 같은 단위의 성중립 표현.
• LOC 기법
  • 추정 LOC = (낙관치 + 4×중간치 + 비관치) / 6
  • 노력 M/M = LOC / 1인당 월평균 코딩 라인 수
  • 개발 비용 = M/M × 1인당 월 평균 인건비
  • 개발 기간 = M/M / 참여 인원
  • 생산성 = LOC / M/M
• LOC는 구현 단계만 본다. 개발 단계 노력(Effort per task) 기법은 요구·설계등 단계별 M/M까지 더해 LOC보다 정확.

퀴즈 3-1, 3-2 (슬라이드 계산)

• 3-1: 5명×10개월 + 7명×6개월 + 3명×3개월 = 101 M/M. (총 기간 1년은 함정에 쓰지 않는다. 중첩 여부는 문제에 없다.)
• 3-2: M/M = 30,000 / 500 = 60. 기간 = 60 / 10 = 6개월.

6. COCOMO (Boehm, 1981)

• 원시 코드 크기 + SW 종류로 비용을 산정.
• KDSI = LOC / 1000.
• 유형 3가지: 단순형(organic) / 중간형(semi-detached) / 내장형(embedded).

1단계 — 초기 PM

2단계 — EAF 보정

• EAF = 제품·컴퓨터·개발자·프로젝트 15개 승수를 모두 곱한 값.
• PM = a \times (KDSI)^{b} \times EAF
• 능력·경험이 높으면 승수 < 1 (노력 감소). 신뢰도·복잡도·제약이 높으면 승수 > 1.
• 일정 촉박은 “요구되는 개발 일정” 항목의 매우 낮음 = 1.23 (줄일수록 비용이 더 들어간다).

3단계 — 총 개발 기간 TDEV (개월)

• 유형과 상관없이 상수 2.5
• 평균 인원 개념 = PM / TDEV.

퀴즈 3-3—3-5 (슬라이드 계산)

COCOMO II

• 초기에 LOC를 몰라 예측하기 힘들어 단계별 모델로 바꿈.
• 앱 합성: Object Point(화면 중심). 초기 설계: 기능점수. 구조 설계 이후: 기능점수 → LOC.

기능 점수 (Albrecht, 1979 / ISO/IEC 14143)

• 사용자 관점 기능(입력·출력·조회·내부논리파일·외부연계파일) 갯수로 규모 측정. 언어와 무관.
• 장: 구현방식·팀과 무관하게 일관성. 전 생명주기에 쓸 수 있다.
• 단: 기능 도출 분석력 필요, 내부 로직 중심 SW에는 부적, 규모지 공수(M/M)는 아님.

7. 일정 계획

• 사전 작업 분석 + 순서 + 자원 계획.
• 예: 학사관리 6개월 = 사용자정보 → 교과과정 → 수업 → 수강 → 성적 → 테스트.

WBS (Work Breakdown Structure)

• 목표를 계층으로 세분. 맨 앞이 Work Package.
• 용도: 고객–개발자 소통, 가시화, 역할 확정, 일정·인력·비용의 기초, 성과 측정.

네트워크 (PERT/CPM)

• PERT: 통계적(확률적) 소요. CPM: 확정적 소요(건설형).
• 노드=작업, 간선=선행 의존.
• 슬라이드 학사 예시 최소 기간 = 25주. 이것이 미니머.

ES / EF (앞에서)

• ES = 선행이 다 끝난 뒤 가장 빠른 시작.
• EF = ES + 소요 기간.
• 예: A 0–2, B 2–8, C 2–6, D는 B·C 중 늦은 B(8) 뒤 8–10, … M 22–25.

LS / LF (뒤에서)

• LS = 전체 25주를 밀지 않고 가장 늦게 시작할 수 있는 시점.
• LF = LS + 소요.
• 슬라이드 28p J의 LF=12는 오타. LS 21 + 1주 = LF 22.

ST(여유) = LS − ES

• C=2, F=5, G=2, I=5, J=8. 나머지 ST=0.
• 여유 있는 작업을 당기·당겨 인력을 나눌 수 있다.

임계 경로 (Critical Path) = ST=0 경로

• 예시: A – B – D – E – H – K – L – M (2+6+2+4+4+2+2+3 = 25주)
• 여기가 1주만 늦어도 전체가 26주가 된다. PM이 여기를 먼저 본다.

간트 차트

• 행=작업(WBS), 열=주 단위 달력.
• 회색 바 = 계획, 파란 바 = 실적. 한눈에 지연 여부.
• 계획 단계 과제는 실적 바가 비어 있는 게 정상.

8. 위험 분석

• 기간+비용 안에 끝내는 확률 약 20%.
• 절차: 위험 요소 식별(잠재 목록) → 분석(중요도) → 계획(대응) → 감시(적절성). 상황이 바뀌니 주기적으로 돌린다.
• 교수: PM은 싸한 느낌이 오면 그냥 넘기면 안 된다. 확인되지 않으면 잘 안 돼가는 중이라고 보라.
• 빈번 위험: 개발자 이직, 요구 변경, 발주사 재정, 예상 벗나간 인력·기간·개발비. 손대서에는 경험 부족, 팀워크, 관리 부족도.