포인트1. 프로젝트 시작단계에 해야 할 일은 무엇인가? 포인트2. 어떻게 목표를 정하고 일정을 계획하는가? 포인트3. 어떻게 프로젝트 비용을 산정하는가? 포인트4. 개발 팀은 어떻게 구성하는가? 포인트5. 프로젝트 수행을 어떻게 모니터링하고 제어하는가? 포인트6. 어떤 위험 요소가 있으며 이를 관리하는 방법은 무엇인가? 프로젝트 - 정해진 기간 안에 한정된 자원으로 일정한 목적을 달성하기 위해 수행하는 업무 프로젝트는 여러 분야의 업무에서 진행이 되지만 소프트웨어 개발 작업에서의 관리는 다음과 같은 어려움이 따른다.
프로젝트 관리의 네 가지 활동 
프로젝트 관리의 목표
3-1. 프로젝트 시작 프로젝트의 첫 작업은 목표 설정 및 가치와 리스크 이해이다. 프로젝트를 시작 할 것인지 말 것인지를 결정하는 것은 프로젝트 가치와 리스크에 의해 결정된다. - 프로젝트 가치 프로젝트 가치를 평가하는 방법
- 프로젝트 리스크 고려해야 할 위험 요인들
- 타당성 분석 프로젝트를 공식적으로 인정하고 기관의 목표와 연결시키는 문서 - 프로젝트 선택에 기초가 됨 포함되어야 할 내용들
3-2. 프로젝트 계획과 스케줄링 프로젝트 초기에는 다음과 같은 사항들에 대해 계획한다.
- 목표 설정 목표 설정 = 범위 설정 -> 프로젝트 관리의 중요한 활동 중 하나 목표에는 프로젝트에서 다루어야 할 모든 작업들이 포함되어야 하며, 범위 밖의 작업이 포함되어서는 안된다. 프로젝트 범위에는 다음과 같은 내용들이 들어가야 한다
- 프로젝트 범위
[ 예시 ] 수강신청 시스템의 프로젝트 범위 정하기 문제가 광범위하고 부수적 문제가 많으면 시스템의 범위가 크고 따라서 복잡할 것이다. 프로젝트 범위를 정하는 목적은 범위를 좁히는 것이다. 시스템의 문제정의에 '시스템은 교무행정실의 모든 기능을 자동화 한다' 라고 적으면 밑에 있는 그림처럼 매우 광범위하게 된다. 모든 기능을 포함할 가능성이 열려 있기 때문이다. 범위를 정하기 위해서는 시스템이 해결할 것으로 예상되는 문제들을 모두 리스트로 적는 것이다. 문제 리스트에서 몇 가지를 삭제하여 별도의 프로젝트로 남김으로써 범위를 줄일 수 있다. - WBS ( Work Breakdown Structure ) 개발 팀이 프로젝트 목표를 달성하고 결과물을 산출하기 위하여 수행해야 할 작업을 계층적으로 분할 한 것 소작업들에 대한 소요 일정이 예측되어야 프로젝트의 일정을 계획할 수 있다. 작성 목적 - 프로젝트에서 진행하는 모든 작업을 찾아내기 위한 것 위 그림에 재고 관리 시스템 개발 프로젝트의 주요 작업들이 표시되어 있다. WBS
- 스케줄링 WBS를 기초로 하여 일정을 정의하는 것
> 작업 의존 관계 작업을 수행하는 순서는 논리적으로 정해져 있다. 예를 들어서 기둥을 세우기 전에 지붕부터 세울 수는 없는 것처럼 작업 사이의 의존 관계는 강한 관계, 약한 관계가 존재한다.
위에 표는 작업의 의존 관계와 소요 시간을 표로 나타낸 것이다. 선행작업은 말 그대로 작업을 시작하기 전에 완료되어야만 하는 작업이다. ex > C 작업을 하기 위해서는 A를 먼저 완료해야 함 이러한 관계는 WBS자체에서는 나타나지 않는다. > CPM(Critical Path Method) 네트워크 노드와 간선으로 구성 된 네트워크 노드에는 작업을 표시, 간선은 작업사이의 선후 의존관계를 나타낸다. CPM 네트워크는 프로젝트 완성에 필요한 작업을 나열하고, 각 작업들의 선후 관계를 한 눈에 볼 수 있도록 나타내어 전체 프로젝트의 최소 소요 기간을 구하는 데 사용된다. > 임계 경로와 여유 시간 계산 CPM 네트워크를 통하여 계산한 소요기간이 가장 긴 경로를 임계경로(Critical Path)라고 한다. 여유시간(TS = slack time) = TL(Latest Start Time) - TE(Earliest Start Time) TE - 그 작업을 시작할 수 있는 최단 시간 즉, 각 작업이 최대한 빠르게 시작할 수 있는 날짜 TL - 그 작업을 최대로 늦추어 시작할 수 있는 날 예를 들어 C 작업을 통해 계산해 본다고 해 보자 ( CPM 네트워크란에 있는 그림 참고 ) C 작업의 TE는 A작업이 끝나고 나서 바로 시작할 수 있으니 A작업을 수행하는 데 걸리는 8일이 될 것이다. C 작업의 TL은 최대 경로인 55일에서 구하고자 하는 작업을 포함하여 뒤에 있는 작업들의 경과시간을 빼면 나오게 된다. C(15일), I(15일), K(7일), L(10일) = 47일 55 - 47 = 8일이 나오게 된다. 즉, TE와 TL이 같게 나오므로 TS(여유시간)는 0이 될 것이다. 여유시간이 0이라는 것은 C 작업은 임계 경로에 있다는 것을 의미한다. 임계 경로에 있다는 것은 해당 작업이 늦춰지게 되면 전체 프로젝트가 지연 된다는 의미이기에 더욱 신경을 써 주어야 한다. E 작업에 대해서 여유시간을 계산 해 보면 TE는 15일이 나오고 TL은 55 - ( 10 + 15 ) = 30일이 나온다. 즉, 여유시간이 15일이 있음으로 임계경로에 존재하지 않는다는 것을 알 수 있다. > 자원 할당과 간트 차트 간트차트 - 각 작업에 대한 여유시간을 구한 후 작업별로 시작, 종료 기간을 수평 막대로 표현한 것 소프트웨어 개발에 필요한 자원
소요자원은 인력이 작업에 투입된 시간으로 표기된다. 간트차트의 각 열에는 투입된 자원의 총량이 표시된다. 3-3. 비용 예측 기법 프로젝트 계획 작업에서는 개발 비용과 기간에 대해 예측을 할 필요가 있다. 먼저 노력(Effort), 자원(Resource), 기간(Duration)의 관계는 다음과 같다. D = E / M 여기서 M(Manpower)은 투입되는 인력의 투입 비율의 총합이다. 비용 예측 기법
기대치 = (a + 4b + c) / 6
알고리즘식 방법의 종류
- COCOMO-81 규모를 기반으로 하는 수학적 공식을 사용한다. 노력 = A x ( Size )^B x M A - 개발 기관의 특징과 개발 소프트웨어의 유형에 좌우되는 상수 Size - 개발될 소프트웨어의 원시코드 라인 수나 기능 점수 B - 1~1.5사이의 값 M - 프로젝트에 영향을 주는 여러 가지 다른 요소들 ( 제품의 성격, 목표 컴퓨터 시스템의 특성, 개발 구성원의 특성 등 )에 따라 달라지는 계수 M은 예측한 노력을 보정하기 위해서 사용한다 승수 요소(B)는 밑에 나와 있는 표를 참고하면 된다.
프로젝트에 대한 노력은 규모에 선형적으로 비례하지 않으며 지수함수의 형태를 띄게 된다. 예시 더보기 초기 COCOMO-81 모델에 대한 예시이다. 위 표는 규모를 KDSI(Kilo Delivery Source Instruction) 으로 정하고 세 가지 프로젝트 유형에 따른 산출 공식을 적어 놓은 표이다. 위 그래프는 표에 있는 세 가지 유형의 프로젝트들의 KDSI 별 PM을 그래프로 나타낸 것이다. - 단점
- COCOMO II COCOMO II 모델은 소프트웨어 개발 프로젝트가 진행된 정도에 따라 단계 별로 세 가지 다른 모델을 제시한다. 1단계 - 프로토타입을 만드는 단계
2단계 - 초기 설계 단계
3단계 - 구조설계 이후 단계
노력 추정에 사용되는 기본 모델 E = b*S^(c)*m(X) b S^(c) 가 기초 소요노력 벡터값을 의미하며, m(X)는 비용승수의 벡터이다. 응용합성모델
모델을 사용한 노력 추정 과정 1. 애플리케이션을 구성하는 화면, 보고서, 3세대 언어 컴포넌트의 숫자를 센다. 2. 밑에 있는 표를 이용하여 화면과 보고서의 복잡도 수준을 결정한다.
3. 밑에 있는 표를 이용하여 화면과 보고서, 3세대 언어 컴포넌트를 위한 복잡도 가중치를 찾는다.
4. 화면, 보고서, 3세대 언어 컴포넌트의 개수에 가중치를 곱하여 객체 점수(Object Point)를 계산한다. 5. 재사용률(reuse)을 예측하여 다음 공식에 대입하면 NOP(New Object Point)를 구할 수 있다. NOP = OP x (100 - Reuse)/100 6. 밑에 있는 표를 이용하여 객체 점수 생산성(PROD)을 결정한다.
7. 객체 점수 생산성을 식 PM = NOP/PROD에 대입하여 최종PM(Person Month)값을 구한다. 예시 더보기 시스템의 일부를 프로토타이핑 하고자 한다. 프로토타입은 3개의 화면, 4개의 보고서가 필요하고, 3세대 언어 컴포넌트는 사용되지 않는다. 각 화면은 뷰가 1개, 서버 자료 테이블이 1개 포함된다. 한 보고서는 2개의 섹션이 있으며 자료 테이블은 사용하지 않는다. 다른 보고서는 2개는 각각 4개이상의 섹션이 있으며 4개의 서버 테이블을 접근한다. 프로토타입의 50%는 이미 존재하는 컴포넌트를 재사용할 것이다. 개발환경은 중간급이며 응용 도메인에 대한 경험은 거의 없다고 한다. 우선 복잡도 수준을 결정해야 한다. 화면에는 뷰가 1개, 서버 자료 테이블이 1개 있으므로 표를 이용하여 복잡도 수준은 '단순'임을 알 수 있다. 그리고 한 보고서에는 2개의 센션이 있고 자료 테이블은 0개이니 보고서의 복잡도 역시 '단순'이다. 그리고 나머지 2개의 보고서는 4개 이상의 섹션, 4개의 서버테이블이 있으니 '복잡'이다. 이 것들을 통하여 복잡도 가중치를 찾아 준다. 화면은 각각 1점을 가지게 되어 총 4점을 가지고, 1개의 보고서는 2점, 나머지 2개의 보고서는 각각 8점의 점수를 가진다. 점수를 합하여 객체 점수(Object Point)를 계산하게 되면 OP = 4 + 2 + 16 = 22점이 나오게 된다. 재사용률이 50%이므로 이를 적용하면 NOP = 22 x ( 100 - 50 ) / 100 = 11점이 나오게 된다. 이제 PROD를 계산 해 보자. 개발 환경은 중간급이므로 표를 통해 13점이 나오며, 응용 도메인에 대한 경험은 거의 없으므로 개발자의 경험이 낮다고 볼 수 있다. 즉, 7점으로 산정되게 된다. 두 점수의 평균은 10점이므로 PROD는 10점이다. 따라서 노력 = NOP/PROD = 11/10 = 1.1MM이 된다. - 기능 점수 방법 기능점수
입력 개수 - 사용자가 시스템에 제공하는 입력 자료의 개수 출력 개수 - 시스템이 사용자에게 제공하는 출력의 개수 질의 개수 - 사용자가 시스템의 특정 기능을 요청하는 데 필요한 대화형 질의의 개수 파일 개수
인터페이스 개수
주의할 점
기능점수(Function Point) 구하기 FP(기능점수) = GFP(총 기능점수) x PCA(보정계수) 방법 1. 다섯 가지 기능 분야에 해당되는 개수를 파악하여 밑에 있는 표에 채운다.
2. 각 다섯 기능에 대한 복잡도(단순, 보통, 복잡)를 결정하여 표시한다. 3. 총 기능점수(GFP)를 구한다. ( FP들의 총 합 ) 4. 다음 표에 있는 14개의 질문을 이용하여 각 처리 복잡도의 정도에 따라 0~5까지 할당한다. 0 - 영향없음 1 - 미미 2 - 약간 3 - 보통 4 - 상당 5 - 많음
5. 처리 복잡도 보정계수(PCA)를 다음 식을 이용하여 구한다. PCA = 0.65 + 0.01 x (1~14번의 처리 복잡도 합) 0.65는 경험에 의한 상수값이며, 0.65~1.35의 범위 내에서 정한다. 6. 다음 식에 넣어 기능 점수(FP)를 구한다. FP = GFP x PCA 예시 더보기 개발하여야 하는 소프트웨어는 다음과 같이 구성될 것이다. 사용자 입력 = 10개, 사용자 출력 = 5개, 사용자 질의 = 8개, 자료 파일 = 30개, 외부 인터페이스 = 4개, 모두 복잡도는 '단순'이다. 처리복잡도를 계산하기 위한 14개의 질문들에는 신뢰도 높은 백업, 사용 친근성은 '복잡도가 매우 높음'이고, 나머지는 '복잡도가 보통'이다. 개발팀의 생산성은 주당 60 기능점수를 구현하면 이 프로젝트를 수행하기 위한 노력은 얼마인가? 먼저 GFP를 계산 해 준다. 표를 이용하면 GFP = 10 x 3 + 5 x 4 + 8 x 3 + 30 x 7 + 4 x 5 = 304FP 가 나오게 된다. 처리 복잡도가 보정된 PCA를 계산하면 PCA = 0.65 + 0.01 x ( 5 x 2 + 3 x 12 ) = 0.65 + 0.46 = 1.11이 나온다. 여기에서 기능점수(FP)를 계산한다. FP = GFP x PCA = 304 x 1.11 = 337.44 마지막으로 노력을 계산한다. E = FP / Productivity = 337.44 / 60 = 5.624 person-weeks 즉 이 프로젝트를 수행하기 위한 노력은 5.624가 된다. 문제점
국내 기능점수 산정 가이드
기능 타입
각 기능 요소들을 카운트 한 다음에는 밑에 있는 표 들을 이용하여 복잡도 수준과 가중치를 계산한다. 복잡도 판별 표
기능 유형별 복잡도 가중치
예시 더보기 어떤 시스템의 사용자 지원을 위한 '서비스 가이드' 서브시스템을 개발하려고 한다. 서브시스템의 기능은 도움말, 사용자 질문 등록, 사용자 질문 응답, FAQ, 자료실이다. 기능점수 방법을 이용하여 노력을 추정해 보자. 개발하여야 할 소프트웨어는 다음과 같은 기능 분야로 구성될 것으로 추정된다. 내부 논리파일 4개(FAQ 제외), 외부 인터페이스 파일 0개, 외부 입력(입력, 수정, 삭제 각 5개씩) 15개, 외부 출력 0개, 외부 조회 5개 먼저 각 기능 요소에 대하여 복잡도 판별 표를 통하여 복잡도를 판별하여야 한다. 복잡도 판별이 어려운 경우 국내 기능점수 산정 가이드에서는 기능 유형별 평균 복잡도를 다음 표에서와 같이 간이법을 이용하게 된다. 복잡도를 고려한 기능점수(간이 계산)
이렇게 구해진 기능점수에 국내 평균 생산성(기능점수당 투입 공수)을 곱하면 노력 산정값이 나온다. 2019년 기준 국내 기능점수당 평균 생산성
평균 노력 E = FP / 평균 생산성 = 109.5/23.4 = 4.67MM 이 된다. 3-4. 프로젝트 팀 조직 조직의 구성은 소프트웨어 개발 생산성에 큰 영향을 미친다. 프로젝트 팀 조직은 다음 세 가지를 정하는 일
팀 역할
직능별 조직 역할에 따라 같은 부서에 속하게 하는 것 인력의 효율적 운영, 전문지식 공유 가능 -> 기술 발전, 기업 노하우 축적 서로 다른 부서가 한 프로젝트의 다른 단계에 들어와 작업을 수행한다. 프로젝트의 협력은 부서별로 이루어지며, 한 부서의 작업 결과가 다른 부서에 전달되어야 하므로 문서나 회의 등 의사 전달체계가 잘 확립되어야 한다. 프로젝트별 조직 서로 다른 역할을 담당하는 직능별 개발자들이 한 프로젝트 안에 배정됨 의사전달 경로가 짧으며 인력, 진도 등 프로젝트 관리가 수월하다. 프로젝트 관리자가 독립성을 가지고 관리할 수 있다.
매트릭스 조직 프로젝트별 조직 구성 + 직능별 조직 구성 관리자, 개발자는 직능별 조직에 속함 전문지식이 필요한 프로젝트를 위해 간헐적으로 일함 매트릭스 조직의 구분 - 강한 매트릭스
- 약학 매트릭스
애자일 조직 서로 밀접하게 협력하는 5~9명의 팀 결과와 이슈에 대한 오너쉽을 공유함 스크럼 - 대표적 애자일 방법 스크럼의 역할
애자일 팀의 단점
3-5. 실행과 모니터링 - 프로젝트 실행
- 프로젝트 모니터링 목적 : 프로젝트의 현황 파악, 차이 분석을 하여 필요하면 조치를 취하기 위함 중점적 모니터링의 대상
일정 모니터링 주어진 시간 계획의 스냅샷을 기초로 실행값을 비교 실제 시작한 날, 종료한 날, 실제로 들어간 노력과 진행상황을 비교한다. 프로젝트에 투입된 노력을 시간단위로 환산하여 데이터를 수집할 수도 있음 작업단위로 투입된 각 개발자의 노동시간을 수집하여 합하면 주 또는 달별로 투입된 노력을 구할 수 있음 장점
단점
어닝 밸류 분석 비용과 일정을 통합된 방법으로 모니터링 하는 것 계획 된 노력(비용), 실제 진적도(어닐 밸류), 노력(실제 비용) 을 금전적 가치로 측정하여 통합된 모니터링을 제공 >> 계획, 작업, 진척도를 같은 단위로 측정, 비교 가능 계획된 비용과 실제 사용된 비용을 누적하여 표현하되 결과물의 달성도를 금액으로 환산한 가치로 나타낸다. 계획, 실행 단계를 비교하여 진행상황의 추이 확인 가능, 미래 비용과 일정 예측 가능 장점
단점
번다운 차트 수행 될 작업보다는 남아 있는 작업에 대해 초점을 두어 일정을 모니터링하는 것 목표 - 기능이 출시되는 속도를 측정하는 것 3-6. 리스크 관리 목적 - 위험이 발생되었을 때의 영향을 줄이기 위함 리스크 파악 프로젝트에 기본적으로 영향을 줄 수 있는 리스크가 무엇인지 이해하고, 특징을 문서화 한다. 리스크를 찾는 방법
리스크 평가 리스크를 프로젝트에 대한 영향도에 따라 평가하고 우선순위를 매긴다. 확률과 리스크가 발생했을 때 미치는 영향이 우선순위를 좌우함 정성적인 방법
리스크 관리 위험 요소를 해소하기 위한 방법을 강구하고 프로젝트를 실행하는 동안 이를 적용하는 작업 방법
완전히 큰 위험 요소는 파악할 필요가 없음 -> 프로젝트 시작을 포기하는게 더 나음 영향을 원인과 혼돈하지 말 것 ex> 프로젝트 지연, 지체 보상금 부과는 프로젝트에 미치는 영향이다. 프로젝트 계획서 프로젝트 계획서에는 개요, 자원 및 일정 예측, 조직 구성, 작업 분해, 기술 관리 방법 등이 포함되어야 함 1. 개요 1.1 프로젝트 개요 2. 자원 및 일정 예측 2.1 자원 가. 인력 2.2 일정 3. 조직 구성 및 인력 배치 3.1 조직 구성 4. WBS 5. 기술 관리 방법 5.1 변경 관리 6. 표준 및 개발 절차 6.1 개발 방법론 7. 검토 회의 7.1 검토회 일정 8. 개발 환경 9. 성능 시험 방법 10. 문서화 11. 유지 보수 12. 설치, 인수 13. 참고 문헌 및 부록 개요
자원 및 일정 예측
조직 구성 및 인력 배치
WBS
기술 관리 방법
표준 및 개발 절차
부록
|
소프트웨어 프로젝트 계획서 예시 - sopeuteuweeo peulojegteu gyehoegseo yesi
관련 게시물
저작권 © 2024 toptenid.com Inc.
