계획
- 계획을 제대로 세우지 않은 소프트웨어 개발은 일정 지연, 품질 저하의 결과를 낳게 됨
- 소프트웨어 개발의 성패는 비용, 기간, 인력과 같은 자원을 토대로 초기에 얼마나 계획을 잘 세우느냐에 달림
문제 정의
- 문제를 잘 정의하려면 개발하고자 하는 영역의 배경지식이 필요
- 유사한 프로젝트 경험이 있는 분석가가 참여하는게 도움이 됨
- 문제를 파악하기 위해서는 현재 운영중인 시스템을 이용해 실무 담당자와 면담해 자료를 수집한 후 면밀한 분석이 필요
타당성 분석
- 경제적 타당성
- 경영자 입장에서 의사결정을 하는데 매우 중요한 요소
- 시장 분석을 통해 시장성 확인
- 경제적 타당성 분석으로 투자 효율성, 시장성을 검증한 후 개발 여부를 판단 - 기술적 타당성
- 사용자가 요구하는 프로젝트가 최신 기술이 필요하다면, 기술적 타당성을 먼저 검토
- 요구하는 기술을 회사가 가지고 있는지 확인
- 부족하다면 필요한 기술을 가진 개발자를 채용하거나 외주 개발로 해결 - 법적 타당성
- 오픈소스는 개발에서 분쟁 발생 소지가 높음
- 소프트웨어 개발에서 오픈소스를 사용하는 것은 비용 절감 측면에서 매우 효율적
- 오픈 소스는 원시 코드가 개방되어 있다는 것이지, 아무렇게 가져와 쓸 수 있는 것이 아님
- 법적 문제가 발생하지 않으려면 오픈소스를 어디까지 무료로 사용할 수 있는지 확인해야 함
개발 비용 산정
- 소프트웨어의 가격은 일반적인 물건의 단가와 같이 명확한 근거를 제시하기 어려워 소비자가 받아들이기 쉽지 않음
- 개발 프로세스가 다양하기 때문에 표준화, 자동화가 어려우며 개발 프로세스에 따라 생산성, 품질이 서로 다를 수 있음
개발 비용에 영향을 주는 요소
- 프로그래머 자질
- 초급 프로그래머와 경험이 많은 프로그래머의 생산성에는 큰 차이가 있음 - 소프트웨어 복잡도
- 브룩스의 법칙 "애플리케이션을 개발하는 것 보다 유틸리티를 개발하는 것이 세 배 어렵고, 유틸리티를 개발하는 것 보다 시스템 프로그램을 개발하는 것이 세 배 어렵다" - 소프트웨어 크기
- 개발하려는 소프트웨어 규모가 크면 개발 인력, 개발 기간, 복잡도가 늘어남 - 가용 시간
- 관리자의 잘못된 생각 중 하나가 개발 기간을 단축하려면 인력과 자원을 늘리면 된다는 것 - 요구되는 신뢰도 수준
- 사고나 오류 발생 시 재산에 큰 손실을 끼치거나 인명 피해가 발생할 수 있는 소프트웨어는 개발 시 높은 신뢰도를 요구 - 기술 수준
- 소프트웨어 개발 시 고급 언어를 사용하면 저수준 언어를 사용할 때 보다 프로그래머의 생산성이 대폭 늘어남
비용 산정 기법 : 하향식 산정 기법
- 전문가 판단 기법
- 경험이 많은 여러 전문가가 프로젝트 수행에 비용이 얼마나 들어가는지 평가한 금액을 개발 비용으로 산정
- 경험이 많은 전문가가 판단을 내린 만큼 신뢰성 있고 편리하다는 장점
- 짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우 많이 사용
- 수학적 계산에 의해 산정하지 않고 경험에만 의존할 경우 부정확할 수 있음 - 델파이 기법
- 전문가의 경험을 중요시해 산정하는 것은 같으나, 전문가의 편견이나 분위기에 영향받지 않도록 조정자를 둠
- 여러 전문가가 모여 각자의 의견대로 비용 산정 후 결과를 공유하고 조율하여 비용 산정
1. 조정자는 전문가들이 모여 비용을 산정하는 회의에서 간사 역할 수행
2. 전문가들은 비용을 산정할 수 있는 자료를 검토하고 의견을 나눌 수 있음
3. 전문가들 각자 비용을 산정함. 이때 계산된 결과를 조정자에게 익명제출
4. 조정자는 각 전문가가 제출한 자료를 요약정리
5. 조정자는 제출받은 자료에서 산정 내용에 차이가 크면 이 문제를 해결하기 위해 회의를 소집
6. 전문가는 다시 익명으로 비용 산정 작업 실시 -> 전문가들의 의견이 일치할 때 까지
비용 산정 기법 : 상향식 산정 기법
- 원시 코드 라인 수 기법
- 소프트웨어 각 기능의 원시 코드 라인 수 LOC의 비관치, 낙관치 , 중간치를 측정해서 예측치를 구하고 이를 이용해 노력, 개발 비용, 개발 기간, 생산성 등의 비용을 산정하는 기법
- 노력(인/월) = (참여인원/월) * 개발 기간 = 추정LOC / 1인당 월 평균 생산 코드 라인 수
- 개발 비용 = (M/M) * 단위 비용(1인당 월평균 인건비)
- 개발 기간 = (M/M) / 참여 인원
- 생산성 = LOC / (M/M)
- 소프트웨어 개발 기간이 1년이다. 5명의 개발자가 12개월동안, 7명의 개발자가 5개월동안 참여한다면 이 소프트웨어 개발의 노력M/M은 얼마인가 -> (5 * 12) + (7 * 5) = 60 + 35 = 95M/M
- LOC 기법에 의해 예측한 총 라인이 50000라인이고 개발자가 10명 참여한다. 그리고 개발자들이 월 평균 500라인을 코딩한다면 개발기간은 얼마나 되는가? -> 50000 / 500 = 100M/M, 개발 기간은 -> 100 / 10 = 10개월 - 개발 단계별 노력 기법
- 각 기능을 구현하는데 필요한 M/M을 소프트웨어 개발 생명주기의 각 단계에 적용해 단계별로 산정
비용 산정 기법 : 수학적 산정 기법
- COCOMO 방법
- 비용 산정시 원시 코드의 크기, 즉 라인수를 중심에 두는 방법
- 완성될 소프트웨어의 크기(LOC)를 추정하고 이를 준비된 식에 대입해 개발에 필요한 M/M을 예측
- 고려사항으로는 프로그램 유형에 따른 가중치를 두어야함(제품, 컴퓨터, 개발자, 프로젝트 총 4가지 특성에 따라 총 15가지로 분류한 후 인건비를 더 보정)
가중치 반영 방법
- 단순형 프로젝트 : 난이도가 비교적 높지않은 업무용 소프트웨어 = 중소 규모 정도에 50KDSI 이하
- 중간형 프로젝트 : 일반 업무용 소프트웨어보다 규모가 더 큰 운영체제, DB 관리 프로그램 등 = 300KDSI 이하
- 임베디드형 프로젝트 : 자동화 기기나 전자제품과 같이 하드웨어와 밀접하게 관련있는 내장형 소프트웨어 = 300KDSI 이상 - COCOMO II 방법 : COCOMO에서 초기에 원시 코드 라인수를 예측하기 어렵다는 점을 고려해 개선된 방식
1. 애플리케이션 합성 모델
- 1단계에서는 입출력 화면 중심의 UI 개수 등을 계산해 다음 객체 점수 산출
- 개발 범위에 속한 객체(입출력 화면)를 찾음
- 객체가 제공하는 기능의 복잡도를 3가지(단순, 보통, 복잡)로 분류
- 객체의 개수에 가중치(단순, 보통, 복잡)를 부여해 결과값 산출
2. 초기 설계 모델
- 2단계는 초기 설계 단계에서 예측값을 구함
- 초기 설계 단계쯤 되면 1단계보다는 시스템 구조와 기능을 상세히 알 수 있어 1단계보다 더 정확한 예측이 가능
3. 구조 설계 이후 모델
- 3단계에서는 이미 기능 점수가 나왔기 때문에 노력을 추정하기 어렵지 않음
- 기능 점수를 바탕으로 한 LOC를 추정해 소프트웨어 규모를 산정
기능 점수 산정 방법 개요
- 사용자 관점에서 소프트웨어 기능을 정량화해 개발 비용 산정에 활용
- 소프트웨어 기능이 얼마나 복잡한가를 상대적 점수로 표현
- 사무용, 관리용 소프트웨어에서 유용
기능 점수 산정 방법의 용도
- 소프트웨어 개발 비용을 산정하는데 사용
- 유지보수 비용 산정에 사용
- 개발시 필요한 자원 산정에 사용
기능 점수 산정 방법의 특징
- 소프트웨어 규모를 측정하는방법
- 기능적 요구사항의 중심이 되는 측저방법
- 소프트웨어 요구사항의 복잡도를 측정
- 구현 관점(물리적 파일, 화면, 프로그램 수)이 아닌 사용자 관점의 요구 기능을 정량적으로 산정
- 측정의 일관성을 위해 개발 기술, 방법, 품질 수준은 고려하지않음
- 개발에 쓰는 언어는 무관
- 개발 생명주기의 전체 단계에서 사용 가능
기능 점수 산정 방법
- 크게 데이터 기능(내부 논리 파일, 외부 연계 파일), 트랜잭션 기능(외부입력, 외부출력, 외부조회)으로 구분
- SW사업 대가산정 가이드에서는 정규 기능 점수법, 간이 기능 점수법으로 구분
기능 점수 산정 방법의 장점
- 사용자의 요구사항만으로 기능을 추출해 측정
- 객관적인 요구사항만으로 측정
- 모든 개발단계에서 사용가능
기능 점수 산정 방법의 단점
- 높은 분석 능력 필요
- 기능 점수 전문가 필요
- 내부 로직 위주의 소프트웨어에는 부적합
- 개발 공수보다 개발 규모측정에 적합
간이 기능 점수법을 이용한 기능 점수 산정 방법
1. 측정 유형(개발, 개선, 어플리케이션) 결정
2. 개발하려는 소프트웨어의 측정 범위, 애플리케이션 경계 설정
3. 데이터 기능 점수 계산 : 데이터기능(내부 논리파일, 외부연계파일)도출 -> 도출된 데이터 기능의 개수 * 평균 복잡도 가중치
4. 트랜잭션 기능 점수 계산 : 트랜잭션 기능(외부 입출력, 외부 조회)도출 -> 도출된 트랜잭션 기능의 개수 * 평균 복잡도 가중치
5. 보정 전 개발 원가 계산 : 총 기능점수 * 기능 점수당 단가(총 기능 점수 = 데이터 기능점수 + 트랜잭션 기능 점수)
6. 보정 후 개발 원가 계산 : 보정 전 개발 원가 * 보정 계수(규모, 어플리케이션 복잡도(연계복잡성수준, 성능요구수준, 운영환경호환성, 보안성수준))
평균 복잡도 가중치
- 과거에 수행한 소프트웨어 기능 점수 산정 결과를 분석해 5가지 유형에 적용된 복잡도를 계산한 가중치의 평균값
- 사업 초기에는 기능 점수를 산정할만큼 자료가 불충분하므로 평균 복잡도 가중치에 의존해 기능점수 산정
- 정상적인 기능 점수 산정 결과를 검증할때도 평균복잡도 가중치를 적용해 기능 점수 산정
측정 유형 결정
- 개발 프로젝트 기능 점수(개발 규모 측정) : 프로젝트가 완료되어 최초 설치했을 때 기능 크기를 산정 = 프로젝트에서 사용자를 위해 제공된 모든 기능을 측정
- 개선 프로젝트 기능 점수(변경 규모 측정) : 사용중인 소프트웨어에 변경이 발생했을 때 변경된 부분의 기능을 측정 = 완료된 프로젝트에서 추가, 수정, 삭제된 부분만 크기를 측정
- 어플리케이션 기능 점수(응용 규모 측정) : 어플리케이션 기능 점수는 현재 운용중인 어플리케이션의 기능을 측정 = 개발 프로젝트 기능 점수에 개선 프로젝트 기능 점수까지 전부 포함
측정 범위와 어플리케이션 경계 설정
- 측정 범위에 포함될 요소(서브시스템)의 식별, 측정 범위 = 기능 점수를 측정하고자 하는 대상
- 어플리케이션 경계 : 기능 점수를 계산하는 대상을 제외한 다른 어플리케이션이나 외부 사용자를 구분하는 경계
- 경계를 지을때 주의점은 사용자 관점에서 구분해야함(개발자관점 X)
데이터 기능 점수 계산
- 내부 논리 파일 개수와 외부 연계 파일의 개수를 계산해 각각 평균 복잡도에 따라 데이터 기능 점수가 결정
- 내부 논리 파일 : 사용자가 등록/수정/조회를 하기 위한 대상으로, DB에 존재하는 데이터 모음이며 DB의 정보들은 기능 점수 측정 대상으로 어플리케이션 내부에서 파일로 유지
- 외부 연계 파일 : 측정 대상 어플리케이션에서는 참조만하고 다른 어플리케이션에서 유지되는 파일
트랜잭션 기능 점수 계산
- 외부 입력(EI) : 데이터베이스에 데이터를 등록하거나 수정/삭제하는 것(학생정보 등록, 수정, 삭제)
- 외부 출력(EO) : 계산하는 로직을 거쳐 데이터나 제어 정보를 사용자에게 보여주는 기능(학생 학점 조회)
- 외부 조회(EQ) : 로직이 필요없고 데이터베이스에 존재하는 데이터를 찾아 그대로 표시만 해주는 기능(주소 검색, 학생 정보 조회)
미조정 기능 점수 계산(UFP)
- 앞에서 구한 데이터 기능, 트랜잭션 기능의 점수를 합한 값
- 기능적 요구사항만 계산하고 여러 특성에 대한 고려를 하지 않음
간이 기능 점수법을 이용한 기능 점수 산정 방법
- 보정 전 개발 원가 계산 -> 미조정 기능 점수(UFP) * 기능 점수당 단가, 분석/설계/구현/테스트를 별도의 사업으로 진행한다면 복잡도 가중치와 가중치에 따른 단계별 단가를 적용
보정 계수
- 규모, 유형이 다양하고 복잡성, 성능요구수준, 운영환경 호환성, 보안요구성 등이 프로젝트 특성에 따라 다름
- 실제 개발 비용에 영향을 미치므로 이들에 대해 보정 계수를 정하고 이를 반영해 보정한 후의 개발 원가를 구해야함
- 규모 보정 계수 : 500FP 미만이면 1.28, 3000FP 초과면 1.153 적용
- 연계 복잡성 수준에 따른 보정 계수
1. 타 기관과 연계 없음 = 0.88
2. 1 ~ 2개의 타 기관과 연계 = 0.94
3. 3 ~ 5 = 1.00
4. 6 ~ 10 = 1.06
5. 10개 초과 = 1.12
- 성능 요구 수준에 따른 보정 계수
1. 응답 성능에 요구사항이 없다 = 0.91
2. 응답 성능에 요구사항이 있으나 특별 조치가 필요없다 = 0.95
3. 응답시간이나 처리율이 피크타임에 중요하며 처리 시한이 명시되어있다 = 1.00
4. 응답시간이나 처리율이 모든 업무 시간에 중요하며 처리 시한이 명시되어있다 = 1.05
5. 응답 성능 요구사항이 엄격해 설계 단계부터 성능 분석이 요구되거나 설계/구현 단계에서 성능 분석 도구가 사용된다 = 1.09
- 운영 환경 호환성에 따른 보정 계수
1. 운영 환경 호환성에 요구사항이 없다 = 0.94
2. 요구사항이 있으며 동일 하드웨어 및 소프트웨어 환경에서 운영되도록 설계된다 = 1.00
3. 요구사항이 있으며 유사 하드웨어 및 소프트웨어 환경에서 운영되도록 설계된다 = 1.06
4. 상이한 운영 환경에 대한 요구사항이 있으며 이질적 하드웨어 및 소프트웨어 환경에서 운용되도록 설계된다 = 1.13
5. 4번에 더해 일반적 산출물 외 여러 장소에서 원활한 운영을 보장하기 위한 운영 절차의 문서화와 사전 모의훈련이 요구된다 = 1.19
- 보안성 수준에 따른 보정 계수
1. 암호화 점검, 웹 취약점 점검, 시큐어코딩, 개인정보보호 등 1가지 이상 보안 요구사항이 포함되어 있다. = 0.97
2. 2가지 이상 = 1.00
3. 3가지 이상 = 1.03
4. 4가지 이상 = 1.06
5. 5가지 이상 = 1.08
- 보정 후 개발 원가 계산 = 보정 전 개발 원가 * (보정 계수1 * 보정 계수2 * 보정 계수n......)
일정 계획
- 소프트웨어 개발 전, 어떤 작업이 필요한지 찾은 후 이를 진행할 순서를 결정하거나 주어진 기간 속 소작업의 개발 기간 및 그들 간의 순서, 필요한 자원 배분과 같은 일정을 계획하는 것을 말함
WBS : 일정 계획의 시작
- 프로젝트 목표 달성에 필요한 활동과 업무를 세분화하는 작업
- 이 때 계층구조 최하위에 있는 항목(업무)을 담당자를 할당할 수 있을 정도로 잘게 나누는데 이를 작업 패키지라 함
WBS의 용도와 장점
- 사용자와 개발자의 의사소통 도구로 사용
- 업무 내역을 가시화할 수 있어 관리가 용이
- 팀원의 책임과 역할이 분명
- 필요 인력, 일정 계획을 세우는 데 기초로 활용
- 개발비 산정 시 기초로 활용
- 성과 측정 및 조정 시 기준선으로 활용
일정계획기법 1 : 네트워크 차트(PERT/CPM)
- WBS의 작업 순서, 소요 기간 등을 네트워크 형태의 그래프로 표현한 후 일의 중요도와 일정관리를 명확히 하는데 사용
- 전체 작업 일정을 세분화해 지연을 예방하고 개발기간 단축에 활용해 일정을 효율적으로 관리
- 유사성과 상호 장단점으로 PERT/CPM이라 하며 두 기법을 혼합하기도 함
PERT
- 프로그램을 평가하고 검토하는 프로젝트 관리 기법
- 프로젝트 진행 상황을 통계적 방법으로 파악하고 이를 통해 일정 계획 및 통제할 수 있도록 고민
CPM
- 듀퐁사에서 화학공장의 건설 계획을 조직적으로 추진하기 위해 개발
- 건설 공사와 같이 단위 작업이 확정적 소요시간을 갖는 프로젝트에 적합
- CPM으로 네트워크를 그리려면 애플리케이션 수행에 필요한 작업, 선행 작업, 작업 소요 기간이 필요
CPM 작업 과정
1. CPM 네트워크를 그림 : 노드와 간선을 이용해 초기 CPM 네트워크를 그리며, 노드는 작업, 간선은 작업들 간의 선후 관계를 나타냄
2. ES값을 구함 : ES는 가능한 빨리 시작할 수 있는 시간(Earliest Start time), 즉 선행 작업이 완료되었을 때 해당 작업을 시작할 수 있는 가장 빠른 시점으로 ES값을 구할 때는 맨 앞에서 끝방향으로 가며 계산함
- ES에서 주의할 부분은 두 작업이 합류하는 지점의 작업 시작 시간은 두 작업이 모두 완전히 끝났을 때임
3. EF값을 구함 : EF는 ES로 시작했을 때 가장 빠른 완료 시간(ES + 작업소요시간)
4. LS값을 구함 : LS는 어떤 작업을 늦어도 시작해야 하는 시간, 즉 가장 늦게 시작할 수 있는 시간으로 LS값을 구할 때는 맨 뒤에서 앞방향으로 가며 계산함
- 두 지점으로 갈라지는 곳에서는 다음 작업의 시작 시간에 영향을 주지 않고 시작할 수 있는 시간을 찾아 기입
5. LF값을 구함 : LF는 LS로 시작해 작업을 완료한 시간(LS + 작업소요시간)
6. ST값을 구함 : ST는 여유시간, 각 작업에서 '가장 늦게 시작하는 시간'에서 '가장 빨리 시작하는 시간'을 뺀 시간
- 전체 작업 시간을 줄이고 싶을 때는 여유시간이 존재하는 작업의 시간을 줄이면 됨
7. 임계 경로를 구함 : 임계 경로는 여유 시간이 없는 경로로 모든 일정 계획은 임계경로에 좌우됨
- 임계 경로에서 벗어난 활동을 수행하는데 걸리는 시간이 한도 내에서 늦춰지거나 당겨질 경우에는 전체 프로젝트 완료 시간에는 변화가 없음
일정 계획 기법 2 : 간트 차트를 이용한 일정표 작성
- 프로젝트 일정 관리를 위한 바 형태의 도구
- 프로젝트 주요 활동을 파악한 후 각 활동의 일정을 시작하는 시점과 끝나는 시점을 막대모양으로 연결하여 전체 일정을 한눈에 볼 수 있음