계획과 문제정의
- 계획은 일상생활에서의 의미와 동일하게 비용, 기간, 자원등을 고려해 소프트웨어 개발을 효율적으로 하도록 도모한는 것을 위해함
- 소프트웨어 개발을 위해서는 문제가 무엇인지 정의하는것을 가장 우선해야 함
해당 영역의 배경 지식이 필요하고, 현재 상황과 구현될 시스템 목표, 제약 조건등을 포함해 개발 범위를 결정하게 됨
타당성 분석
- 개발 범위를 결정하면 개발 프로젝트의 타당성을 조사해야함
- 타당성 분석 시에는 경제적 타당성, 기술적 타당성, 법적 타당석을 검토함
경제적 타당성: 투자 효율성과 시장성이 있는가?
기술적 타당성: 개발에 요구하는 기술을 보유하고 있는가? 없다면 기술을 가진 개발자를 불러올 수 있는가?
법적 타당성: 상용 소프트웨어, 오픈소스 코드의 저작권을 침해하지 않는가?
개발 비용 산정
- 소프트웨어 개발 비용을 산정하는 것은 개발자가 중심이 되기 때문에 명확하지 않음
- 프로그래머의 실력, 소프트웨어 복잡도와 크기, 가용 시간, 소프트웨어의 신뢰도 등을 고려해 개발 비용을 산정하게 됨
하향식 산정 기법
- 과거의 경험을 바탕으로 전문가의 의견을 반영해 비용을 산정하는 방법
- 전문가의 의견만을 반영하는 비용 산정 기법은 전문가 판단 기법, 전문가 이외의 조정자를 두는 방법을 델파이 기법이라고 함
- 델파이 기법에서는 전문가들의 익명으로 비용 산정을 하고, 조정자가 이를 정리한 결과가 전문가들의 의견과 일치할때까지 반복함
상향식 산정 기법
- 프로젝트의 세부 작업 단위별로 비용을 산정한후 전체 비용을 합산하는 방법
- 프로젝트의 소스코드 라인을 바탕으로 하는 원시 코드 라인 수(Line Of Code) 기법과 생명주기 단계별로 노력을 산정하는 계발 단계별 노력(Effort Per Task) 기법이 있음
- LOC에서는 코드가 가장 적다 예상되는 낙관치, 가장 많다 예상되는 비관치, 평균적이라 예상되는 중간치의 코드 라인수를 추정한 다음, (낙관치 + (4 * 중간치) + 비관치)/6의 값을 LOC로 산정함
수학적 산정 기법
COCOMO 방법
- 소프트웨어 개발 비용 산정을 위해 원시 코드의 라인 수를 중심으로 두는 방법
- 프로그램 유형에 따라 가중치를 두어 초기 인건비를 계산함
크기에 따라 단순형 프로젝트, 중간형 프로젝트로 구분되며, 하드웨어와 밀접한 프로젝트는 임베디드형 프로젝트로 구분
- 인건비를 계산하면 아래 사진과 같은 프로젝트의 상세한 속성별로 보정값들을 곱해 노력 조정 수치(Effort Adjustment Factor)를 구하고, 최종적으로 소프트웨어 개발에 필요한 인력을 구하게 됨

COCOMO II 방법
- 개발 초기 단계에서 원시 코드의 라인 수를 예측하는 방법을 모델을 통해 추가로 도입한 방법
- 개발 범위에 속한 객체를 찾아 객체에 가중치를 부여해 결과값을 산출하는 애플리케이션 합성 모델, 초기 설계 단계에서 소스코드 길이를 구하는 초기 설계 모델, 구조 설계 이후에 소스코드의 라인 수를 구하는 구조 설계 이후 모델이 있음
기능 점수 산정 방법
- 소스코드 길이가 아닌 입출력, DB 테이블, 인터페이스 등의 기능의 수를 개발 비용 산정의 근거로 활용하는 방법
- 사용자 관점의 요구 기능을 정량적으로 산정하며, 사용하는 언어, 개발 기술, 품질 수준 등은 고려하지 않음
기능 점수의 기준이 되는 소프트웨어 기능은 크게 데이터 기능과 트랜젝션 기능으로 구분할 수 있음
- 모든 개발단계에서 사용할 수 있고, 객관적인 사용자 요구사항만으로 소프트웨어 규모를 측정가능하다는 장점이 있음
- 높은 분석능력이 필요하고, 내부 로직 위주의 소프트웨어에 사용하기에 부적합한 방법이라는 단점이 있음
간이 기능 점수법을 이용한 기능 점수 산정
- 예산을 수립할 때 각 기능의 복잡도와 가중치를 도출하기는 어려움 -> 기능 수준정도만을 가지고 있기 때문에 미리 계산된 평균 복잡도 가중치를 사용하게 됨
- 평균 복잡도 가중치를 사용해 기능 점수를 산정하는 방법을 간이 기능 점수법이라 하며, 산정 절차는 아래 그림과 같음

일정 계획
- 소프트웨어를 개발하기 위해 어떤 작업이 필요한지 찾은 후, 이를 진행할 순서를 결정하고 필요한 자원을 확인하는 등의 일정을 계획하는 것
- 작업 분할 구조도를(Work Breakdown Structure)를 사용해 프로젝트 내의 활동을 세분화 함

네트워크 차트
문제를 하나 풀면서 알아보자.
국가공무원 7급 소프트웨어공학 2018년 기출문제
다음 표는 프로젝트를 수행하는 데 필요한 작업, 소요 기간, 선행 작업을 나타낸 것이다. 작업 T5를 담당한 개발자가 이직하여 대체 인력을 확보하였으나 대체 인력의 교육에 15일이 소요되어, 작업 T5는 소요 기간이 35일로 변경되었다. 프로젝트를 완료하기까지 필요한 최소 소요 기간은 개발자 이직 전보다 얼마나 증가하는가?
작업 | 소요 기간(일) | 선행 작업 |
---|
T1 | 10 | - |
T2 | 15 | T1 |
T3 | 15 | - |
T4 | 10 | T2, T3 |
T5 | 20 | T3 |
T6 | 20 | T5 |
T7 | 15 | T4 |
T8 | 15 | T5, T7 |
1. CPM 네트워크 그리기
- 우선 node와 edge를 이용해 CPM(Critical Path Method) 네트워크를 그러야 한다. 이 문제에서는 다음과 같은 그래프를 얻을 수 있다

2. ES, EF 값 구하기
- 가능한 빨리 시작할 수 있는 시간인 ES(Earliest Start Time)을 구하고, 이에 작업 소요 시간을 더한 EF(Earilist Finish Time)을 구한다.
작업 | ES | EF |
---|
T1 | 0 | 10 |
T2 | 10 | 25 |
T3 | 0 | 15 |
T4 | 25 | 35 |
T5 | 15 | 35 |
T6 | 35 | 55 |
T7 | 35 | 50 |
T8 | 50 | 65 |
3. LS, LF, ST 값 구하기
- 작업이 지연되지 않는 한에서 가장 늦게 시작하는 시간인 LS, 작업 소요 시간을 더한 LF, 작업에 허용된 지연 시간인 ST(Slack Time)을 추가로 구함
ST = LS - ES
작업 | ES | EF | LS | LF | ST |
---|
T1 | 0 | 10 | 0 | 10 | 0 |
T2 | 10 | 25 | 10 | 25 | 0 |
T3 | 0 | 15 | 10 | 25 | 10 |
T4 | 25 | 35 | 25 | 35 | 0 |
T5 | 15 | 35 | 35 | 50 | 20 |
T6 | 35 | 55 | 45 | 65 | 10 |
T7 | 35 | 50 | 35 | 50 | 0 |
T8 | 50 | 65 | 50 | 65 | 0 |
4. 임계 경로 구하기
- 그래프에서 여유 시간인 ST가 없는 node를 잇는 경로가 임계 경로가 되며, 일정 계획은 임계 경로에 좌우됨
- 문제에서는 T1 -> T2 -> T4 -> T7 -> T8 경로가 임계 경로가 되며, 총 작업기간은 임계 경로의 작업 기간을 전부 더한 65일이 됨
만약 T5 경로에서 작업 시간이 35시간이 되면 각 값들은 아래 표와 같이 바뀜
|작업 |ES |EF |LS | LF| ST
|---|---|---|---|---|---
|T1 |0 |10 |5 |15 |5
|T2 |10 |25 |15 |30 |5
|T3 |0 |15 |0 |15 |0
|T4 |25 |35 |30 |40 |5
|T5 |15 |50 |15 |50 |0
|T6 |50 |70 |50 |70 |0
|T7 |35 |50 |40 |65 |5
|T8 |50 |65 |55 |70 |5
임계경로는 T3 -> T5 -> T6으로 바뀌며 총 작업기간은 5일이 더해진 70일이 됨
간트 차트

- 프로젝트 일정 관리를 위한 바 형태의 도구
- 각 활동의 일정을 막대 모양으로 표시하게 됨
위험 분석
- 소프트웨어 개발 시 계획 단계에서 위험요소를 찾아 대비책을 마련해야 함
- 잠재적인 위험 목록을 식별하여, 이를 중요도별로 위험 분석을 하고, 대응 방안을 마련한 위험 계획을 수립한 다음, 위험을 감시하며 대응 방안이 적절한지 평가해야 함
출처:
쉽게 배우는 소프트웨어 공학 2판, 김치수, 한빛아카데미
https://itwiki.kr/w/%EC%9E%84%EA%B3%84%EA%B2%BD%EB%A1%9C