계획
- 계획을 제대로 세우지 않고 수행하는 소프트웨어 개발은 일정 지연, 비용 초과, 품질 저하라는 결과를 낳게 된다.
- 소프트웨어 개발의 성패는 비용, 기간, 인력과 같은 자원을 토대로 초기에 얼마나 계획을 잘 세우느냐에 달려있다.
문제정의
- 문제를 정의하려면 개발하고자 하는 영역의 배경 지식이 필요하다.
- 유사한 프로젝트를 개발한 경험이 있는 분석가가 참여하는 것이 도움이 된다.
- 문제를 파악하기 위해 현재 운영중인 시스템을 사용해보고,
- 실무 면담자와 면담해 자료를 수집한 후 면밀히 분석해보는 것이 필요하다.
타당성 분석
경제적 타당성
- 경영자 입장에서 의사결정을 하는 데 매우 중요한 요소다.
- 시장 분석을 통해 시장성을 확인
- 경제적 타당성 분석으로 투자 효율성과 시장성을 검증한 후 개발 여부를 판단한다.
기술적 타당성
- 사용자가 요구하는 프로젝트가 최신 기술이 필요하다면 기술적 타당성을 먼저 검토한다.
- 요구하는 기술을 회사가 갖고 있는지 확인한다.
- 부족하다면 필요한 기술을 갖고 있는 소프트웨어 개발자를 채용하거나 외주 개발로 해결한다.
법적 타당성
- 오픈소스는 소프트웨어 개발에서 분쟁 발생 소지가 높다.
- 소프트웨어 개발에서 오픈소스를 사용하는 것은 비용 절감 측면에서 매우 효율적이다.
- 오픈 소스는 원시 코드가 개방되어 있다는 것이지 아무렇게나 가져다 사용할 수 있는 것은 아니다.
- 법적인 문제가 발생하지 않으려면 오픈소스를 사용할 때 어디까지 무료로 사용할 수 있는지 확인해야 한다.
개발 비용 산정
개발에 영향을 주는 요소
- 프로그래머 자질
- 소프트웨어 복잡도
- 소프트웨어 크기
- 가용 시간
- 요구되는 신뢰도 수준
- 기술 수준
비용 산정 기법 : 하향식
전문가 판단 기법
- 경험이 많은 전문가들이 프로젝트를 수행하는 데 비용이 어느정도 들어가는지 평가한 금액을 개발 비용으로 산정
- 경험이 많은 전문가가 판단을 내린 만큼 신뢰성이 있고 편리하다는 장점
- 짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우 많이 사용한다.
- 수학적 계산에 의해 산정하지 않고 경험에만 의존할 경우 부정확할 수 있다.
델파이 기법
- 전문가의 경험을 중요시해 비용을 산정하는 것은 같으나 전문가들의 편견이나 분위기에 영향을 받지 않게 조정자를 둔다.
- 여러 전문가가 모여 각자의 의견대로 비용을 산정 후 결과를 공유하고 의견을 조율하여 개발 비용을 산정한다.
- 조정자는 전문가가 모여 비용 산정을 하는 회의에서 간사 역할을 수행한다.
- 전문가는 비용을 산정할 수 있는 자료를 충분히 검토하고, 필요하다면 의견을 나눈다.
- 전문가 각자가 비용을 산정한다. 이때 계산된 결과를 조정자에게 익명으로 제출
- 조정자는 각 전문가가 제출한 자료를 요약 정리
- 조정자는 각 전문가가 제출한 자료에서 산정 내용에 차이가 크면 이 문제를 해결하기 위해 회의를 소집한다.
- 전문가는 다시 익명으로 비용 산정 작업을 실시
비용 산정 기법 : 상향식
원시 코드 라인 수 기법
소프트웨어 각 기능의 원시 코드 라인 수 LOC(Line of Code)의 비관치, 낙관치, 중간치를 측정해서 예측치를 구하고 이를 이용해 노력, 개발 비용, 개발 기간, 생산성 등의 비용을 산정하는 기법이다.
(M/M)은 (Man/Month)
예제
- 소프트웨어 개발 기간은 1년(12개월). 5명의 개발자가 12개월 동안, 7명의 개발자가 5개월 동안 참여한다면 개발의 노력 M/M은 얼마인가?
풀이 : (5명 *12개월) * (7명 * 5개월) = 60M/M + 35M/M = 95M/M - LOC 기법에 의해 예측한 총 라인이 50,000이고 개발자가 10명 참여. 또 개발자들이 월 평균 500라인을 코딩한다면 개발 기간이 얼마나 되는가?
노력^M/M = 원시 코드 라인 수 / (1인당 월평균 생산 코드 라인 수 ) =50,000/500 = 100M/M
개발 기간 = (M/M)/참여 인원 = 100(M/M)/10명 = 10개월
원시 코드 라인 수 기법
각 기능을 구현하는 데 필요한 M/M을 소프트웨어 개발 생명주기의 각 단계에 적용해 단계별로 산정한다.
비용 산정 기법 : 수학적 산정 기법
COCOMO 방법
- 소프트웨어 개발 비용을 산정할 때 원시 코드의 크기, 즉 라인 수를 중심에 두는 방법
- 먼저 완성될 소프트웨어의 크기(라인 수 LOC)를 추정하고 이를 준비된 식에 대입해 개발에 필요한 M/M을 예측한다
CoCoMO 방법의 고려사항
- 프로그램 유형에 따른 가중치를 둔다.
- 개발하려는 소프트웨어를 제품, 컴퓨터, 개발자, 프로젝트의 4가지 특성에 따라 총 15가지로 분류한 후 인건비를 더 보정한다.
가중치 반영하기
- 단순형 프로젝트(크기 50KDSI 이하)
- 중간형 프로젝트(크기 300KDSI 이하)
- 내장형(임베디드) 프로젝트(크기 300KDSI 이상)
개발 인건비 초기 예측
보정 계수 반영하기
- 노력 조정 수치(EAF): 보정에 사용하는 값, 필요한 각 항목별 승수 값을 모두 곱한 값
- 15개의 세부 항목에 따른 보정 값을 모두 정해놓음.
- 이 부분은 책을 구매해 보는 것이 좋을 것 같습니다. 너무 세부적..
총 개발 기간 산정하기
COCOMO II(2) 방법
- 1단계에서는 입출력 화면 중심의 사용자 인터페이스 개수 등을 계산해 다음의 객체 점수를 산출한다.
- 개발 범위에 속한 객체(입출력 화면 등)을 찾는다.
- 객체가 제공하는 기능의 복잡도를 3가지(단순형, 보통형, 복잡형)로 분류한다.
- 객체의 개수에 가중치(단순형, 보통형, 복잡형)를 부여해 결괏값을 산출한다.
초기 설계 모델
- 2단계는 초기 설계 단계에서 예측값을 구한다.
- 초기 설계 단계쯤 되면 1단계보다는 시스템의 구조와 기능을 좀 더 상세히 알 수 있어 1단계보다 덩욱 정확한 예측이 가능하다.
구조 설계 이후 모델
- 3단계에서는 이미 기능 점수가 나왔기 때문에 노력을 추정하는게 어렵지 않다.
- 기능 점수를 바탕으로 LOC를 추정해 소프트웨어 규모를 산정한다.
아래는 COCOMO II에 적용되는 기본 공식이다.
기능 점수 산정 방법
- 사용자 관점에서 소프트웨어의 기능을 정량화해 소프트웨어 개발 비용 산정에 활용한다.
- 소프트웨어의 기능이 얼마나 복잡한지 상대적인 점수로 표현한다.
- 사무용 또는 관리용 소프트웨어에서 매우 유용한 방법이다.
기능 점수 산정 방법의 용도
- 소프트웨어 개발 시 비용을 산정하는 데 사용
- 소프트웨어 유지보수 비용을 산정하는 데 사용
- 소프트웨어 개발 시 필요한 자원을 산정하는 데 사용
기능점수 산정 방법의 특징
- 소프트웨어 규모를 측정하는 방법
- 기능적 요구사항이 중심이 되는 측정 방법
- 소프트웨어의 요구사항 복잡도를 측정
- 구현 관점(물리적 파일, 화면, 프로그램 수)이 아닌 사용자 관점의 요구 기능을 정량적으로 산정
- 측정의 일관성을 유지하기 위해 개발 기술, 개발 방법, 품질 수준 등은 고려하지 않는다.
- 소프트웨어 개발에 사용하는 언어와는 무관
- 소프트웨어 개발 생명주기의 전체 단계에서 사용 가능
기능 점수의 기준이 되는 소프트웨어 기능은 크게 데이터 기능과 트랜잭션으로 구분된다.
장점
- 사용자의 요구사항만으로 기능을 추출해 측정
- 객관적인 요구사항만으로 측정
- 모든 개발 단계에서 사용
단점
- 높은 분석 능력이 필요하다.
- 기능 점수 전문가 필요
- 내부 로직 위주의 소프트웨어에는 다소 부적합하다.
- 개발 공수보다 개발 규모 측정에 적합하다.
간이 기능 점수 산정 방법
프로젝트 초기 단계에서 각 기능의 요소를 모르는 경우에 평균 복잡도 가중치를 사용해 소프트웨어 기능의 크기를 측정
평균 복잡도 가중치
- 과거에 수행한 소프트웨어의 기능 점수 산정 결과를 분석해 5가지 유형에 적용된 복잡도를 계산한 가중치의 평균값
- 사업 초기에는 기능 점수를 산정할 수 있을 만큼 자료가 충분하지 않으므로 평균 복잡도 가중치에 의존해 기능 점수를 산정한다.
- 정상적인 기능 점수 산정 결과를 검증할 때도 평균 복잡도 가중치를 적용해 기능 점수를 산정한다.
측정 유형 결정
기능 정수를 측정하는 첫 번째 단계는 측정 유형을 결정하는 것이다.
프로젝트가 신규로 개발되는 것인지, 기능을 보강하는 개선 프로젝트인지, 신규 또는 개선 후의 특정한 시점에서의 측정인지에 따라 아래 3가지로 나뉜다.
- 개발 프로젝트 기능 점수 (개발 규모 측정)
- 개선 프로젝트 기능 점수 (변경 규모 측정)
- 애플리케이션 기능 점수 (응용 규모 측정)
측정 범위와 애플리케이션 경계 설정
측정 범위에 포함될 요소(서브시스템)을 식별한다. 측정 범위는 기능 점수를 측정하고자 하는 대상을 말한다.
그 대상에는 몇 개의 애플리케이션이 포함될 수도 있다.
애플리케이션 경계란 기능 점수를 계산하는 대상을 제외한 다른 애플리케이션이나 외부 사용자를 구분한 경계다.
경계를 지을 때 주의할 점은 사용자 관점에서 구분해야한다. (개발자 입장 X)
데이터 기능 점수 계산
- 사용자가 등록/수정/삭제/조회를 하기 위한 대상으로, 데이터베이스에 존재하는 데이터 모임(데이터베이스의 정보)
- 데이터베이스의 정보들은 기능 점수 측정 대상으로 애플리케이션 내부에서 파일로 유지
외부 연계 파일
- 측정 대상 애플리케이션에서는 참조만 하고 다른 애플리케이션에서 유지되는 파일
트랜잭션 기능 점수 계산
트랜잭션 기능을 측정한다는 것은 외부 입력, 외부 출력, 외부 조회의 횟수를 세는 것이다. 기능 점수에서 트랜잭션 기능의 복잡도는 입력, 출력, 조회의 개수로 결정된다.
- 외부 입력 : 데이터베이스에 데이터를 등록하거나 수정·삭제하는 것(학생정보 등록, 수정, 삭제
- 외부 출력 : 계산하는 로직을 거쳐 데이터나 제어 정보를 사용자에게 보여주는 기능(학생 학점 조회)
- 외부 조회 : 로직이 필요 없고 데이터베이스에 존재하는 데이터를 찾아 그대로 표시만 해주는 기능(학생 정보 조회)
미조정 기능 점수 계산
앞에서 구한 데이터 기능 점수화 트랜잭션 기능 점수를 합한 값이다.
단순히 기능적인 요구사항에 대해서만 계산하지, 여러 가지 특성에 대한 고려를 하지 않는다.
예시는 아래와 같다.
보정 전 개발 원가 계산
보정 전 개발 원가는 앞에서 구한 미조정 기능 점수에 기능 점수당 단가를 곱해 계산한다.
보정 계수
규모와 유형도 다양하고, 연계 복잡성 수준, 성능요구 수준, 운영 환경 호환성, 보안성 수준이 프로젝트의 특성에 따라 다르다. 실제 개발 비용에 영향을 미치므로 이들에 대 해 보정 계수를 정하고 이를 반영해 보정한 후 개발 원가를 구해야 한다.
규모 보정 계수, 애플리케이션 복잡도 보정 계수등이 있다. 이 부분도 예시가 너무 길어 직접 책을 확인하면 좋겠다.
보정 후 원가 개발 계산
최종 조정된 기능 점수 인 보정 후 개발 원가는 다음 공식으로 계산한다.
여기까지 타자로 직접 공부하는데 어지럽다ㅋㅋ... 3단원 특히 간이 기능 점수법은 이렇게 있구나 하고 넘어가야겠다.
위에서 너무 예시 중심적이고 내용이 길어 생략한 부분은 책을 참고하면 좋겠다.
일정 계획
소프트웨어를 개발하기 위해 어떤 작업이 필요한지 찾은 후, 이를 진행할 순서를 결정하거나 주어진 개발 기간에 소작업의 개발 기간 및 그들 간의 순서, 필요한 자원 등과 같은 일정을 계획하는 것이다.
일정 계획의 시작 : 작업 분할 구조도 (WBS)
프로젝트 목표를 달성하는 데 필요한 활동과 업무를 세분화하는 작업이다
작업 패키지 : 계층 구조에서 최하위에 있는 항목, 해당 업무의 담당자를 할당할 수 있을 정도로 작게 나눈다.
WBS의 용도와 장점
- 사용자와 개발자의 의사소통 도구로 사용
- 프로젝트 업무 내역을 가시화할 수 있어 관리가 용이
- 프로젝트 팀원의 책임과 역할이 분명
- 필요 인력과 일정 계획을 세우는 데 기초로 활용
- 개발비 산정 시 기초로 활용
- 성과 측정 및 조정 시 기준선으로 활용할 수 있음
일정 계획 차트 1: 네트워크 차트
WBS의 작업 순서, 소요 기간 등을 네트워크 형태의 그래프로 표현한 후 일의 중요도와 일정 관리를 명확히 하는 데 사용전체 작업 일정을 세분화해 지연을 사전에 예방할 수 있고, 개발 기간 단축에 활용해 일정을 효율적으로 관리할 수 있음유사성과 상호 장단점 때문에 PERT/CPM이라 해 두 기법을 혼합한 방법을 사용하기도 한다.
- PERT : 프로젝트를 평가하고 검토하는 프로젝트 관리 기법. 프로젝트 진행 상황을 통계적인 방법으로 파악하고 이를 통해 일정 계획 및 통제를 할 수 있도록 고안
- CPM : 건설 공사와 같이 단위 작업이 확정적 소요 시간을 갖는 프로젝트인 경우에 적합하다.
CPM 작업 과정
- 노드(작업)과 간선(작업들 간 선후 의존 관계)을 이용해 CPM 네트워크를 그린다.
- ES 값을 구한다. ES 값이란 가능한 빨리 시작할 수 있는 시간으로, 선행 작업이 완료되었을 때 해당 작업을 시작할 수 있는 가장 빠른 시점이다.
- EF 값을 구한다. EF는 가장 빠른 시작 시간으로 시작했을 때의 가장 빠른 완료 시간이다.
- LS 값을 구한다. LS는 어떤 작업을 늦어도 시작해야 하는 시간, 즉 가장 늦게 시작할 수 있는 시간이다.
- LF 값을 구한다. LF는 가장 늦게 시작할 수 있는 시간에 시작해 작업을 완료한 시간이다.
- ST 값을 구한다. ST는 여유 시간, LS - ES를 계산하면 구할 수 있다.
- 임계 경로를 구한다. 임계 경로는 여유 시간이 없는 경로다.
일정 계획 차트 2: 간트 차트를 이용한 일정표 작성
프로젝트 일정 관리를 위한 바 형태의 도구다.
프로젝트의 주요 활동을 파악한 후, 각 활동의 일정을 시작하는 시점과 끝나는 시점을 연결한 막대 모양으로 표시한다.
위험 분석
- 소프트웨어 개발에 방해가 되는 요소를 파악
- 위험 요소의 발생 확률과 영향도를 평가
- 분석한 결과에 따라 위험 우선순위를 정해 그에 맞게 대책을 정한다.
위험 요소 식별
- 발생 가능한 위험 요소를 브레인스토밍해서 도출한다.
- 이전 유사 프로젝트를 참고해 위험 요소를 참조하는 방법
- 예시로는 개발자의 이직, 요구 사항 변경, 발주사의 재정적 어려움 등이 있다.
위험 관리 절차
- 위험 분석 : 발생 가능성의 척도와 영향력의 정도로 분류한다.
- 위험 계획 수립 : 위험을 관리하기 위한 전략을 찾는다. 위험 대응 방안을 잘 세워야함.
- 위험 감시
이상으로 포스팅을 마치겠습니다. 감사합니다.
참고자료
쉽게 배우는 소프트웨어 공학 2판 (3단원 계획)
http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791156645429
댓글