Kosta - 2012년 강의중 소프트웨어 시스템 구축을 위한 실전 프로젝트 관리 를 듣고 적음
+ 개인 의견이 다분하게 녹아들어서 작성됩니다.
서두. 프로젝트 관리란?
Teresa S. Stover의 저서 Microsoft® Office Project 2003 Inside Out 에서
발췌한 이 글이 프로젝트 관리 정의에 대해서 틀을 잡아줄 수 있겠어요
서두-1. 다루는 범위
여기에서는 다음 두가지 사항에 대해서 확인합니다.
- 프로젝트 각 과정별 대괄적인 진행사항
- 프로젝트 중간 시점별로 부족해지거나 챙기기 어려운 부분
(잘 보이지 않는 부분들)
- 산출물은 어느것을 준비해야 하는가
서두-2. 따라서 이번 게시물에서 언급하고자 하는 사항들
- 프로젝트 시작을 위한 주요 활동
- 시작시 해야할 것
- 진행현황 확인방법
- 프로젝트 종료를 위한 준비
* 애자일 프로젝트 관리
차례.
1. 프로젝트 시작을 위한 주요 활동
2. 프로젝트 진행
3. 관리 방법론
4. 개발 방법론
1. 프로젝트 시작을 위한 주요 활동
1-1) 입찰 작업 전 진행되는 사항
※() 묶은 부분은 발주자가 작성함
1-1)-(1) (문제 정의)
발주자가 필요한 부분이 무엇인지 큰 단락을 정해야 함
플잭 컨설턴트 하는 분 내용을 발췌 (http://www.venturesquare.net/39532)
1-1)-(2) (정보요청작업(RFI:Request For Information))
발주자는 필요한 부분에 대하여
이걸 구현하고자 할때 혹은 만들고자 할때 필요한 기술?
이걸 구현하고자 할때 혹은 만들고자 할때 필요한 기술?
알고 있는 대상은 누구인가?
등등 필요한 정보를 얻기위한 목적을 위해 1-1)-(2)를 진행
문서를 받은 입장에서(보통 사업제안자) 제안 회사에서 보유하지 않는
기술이지만 정보요청에 꼭 포함되어야 하는 내용인 경우 해당 기술을
포함하는 업체 등을 확인하여 재요청하는 형태로 정보를 제공해 줘야함
기술이지만 정보요청에 꼭 포함되어야 하는 내용인 경우 해당 기술을
포함하는 업체 등을 확인하여 재요청하는 형태로 정보를 제공해 줘야함
1-1)-(3) 사업계획 수립
(1), (2) 내용을 기초로 사업 제안자가 작성
※ 사업계획서 작성 : (5) 제안 요청서의 내용이 거의다 작성할수 있는 정도의 디테일
1-1)-(4) 사전 규격 검증 기간(현장 설명회)
갑, 을 누구라도 기술 이해 혹은 프로세스 이해를 위한 의견교환이나 구체적인 설명이
필요하다고 판단되면 진행
큰 규모의 프로젝트라면 보통 진행
큰 규모의 프로젝트라면 보통 진행
1-1)-(5) 제안요청(RFP : Request For Proposal)
발주자가 작성 공개 정도를 기준으로 한 분류 방법으로
제한, 공개, 경쟁, 가격 측정 방식으로 나눠짐
※ 제안 요청서 작성시 제안 안내 내용의 스펙 내에 작성해야 함
※ 보통 몇가지 측면으로 측정해 점수화하는데 되도록 많은 득점이 되도록 작성되야함
※ 예정가격 결정방법 :
컨소시엄(지분을 나누는 방법)
하도급 (대장이 받아서 이전에 구두 혹은 문서 약속대로 줌)
공공기관 방식 : 보통 법령에 정한대로 진행함
1-1)-(6) 제안서 수집(현장수집, 제안 설명회)
큰 프로젝트의 경우 제안 요청 이후에도 입찰을 위한 활동들이 진행된다.
1-1)-(7) 입찰 및 계약
입찰되면 계약할때까지 ppt준비하고 보고서 준비하고 조율하고
대상자 선정되면 다시 협상하고 계약하고 계약 안되면... 다른거 입찰하고....
1-2) 입찰부터 계약 진행까지
1-2)-(1) 입찰 참여활동
1-2)-(2) 사전영업
1-2)-(3) 타당성 분석(이익 분석)
1-2)-(4) 제안팀 구성
1-2)-(5) RFP검토
1-2)-(6) 제안서 작성
1-2)-(7) 제안서 제출
1-2)-(8) 제안 설명회 참석
1-2)-(9) 우선 협상 대상자 선정 및 협상(추가 협상 또는 기술협상)
1-2)-(10) 계약
2. 프로젝트 진행
2-1) 개요 및 소프트웨어 개발 프로젝트 이해
3. 관리 방법론
4. 개발 방법론
주로 이 2가지가 프로젝트 구성에 뼈대가 됨
2-1)-(1) 소프트웨어 개발 프로젝트 이해
보통 개발 순서는 진행되는데 : 요구사항 정의 - 분석 - 설계 - 개발 - 테스트
여기서 프로젝트 관리란 : 소프트웨어 구축범위, 개발인력, 개발일정 관리(관리방법론)
이런것들은 관리하겠다 라고 정의하고 여기 정의해놓은거에 의해 활동하는 전체
기간 : 프로젝트 끝날때까지(인도 할때까지)
누가 : pm을 포함한 제품에 발을 담근 모든 관계자
3. 개발 방법론 : ~~한 수행체계
3-1) 개발 방법론 역사? 또는 종류
3-1)-(1) 소프트웨어 개발 생명주기(Software Develoment Life Cycle)
눈으로 확인할 수 없는 개발 과정을 눈에 보이도록
요구사항 정의 ,분석 등으로 단계를 세분화 하여 가시화를 시도
3-1)-(2) 세분화한 각 단계별 할일들을 구체화(활동, 도구, 기법, 산출물)
어떻게 하느냐에 따라서 각각의 방법론이 발전함
3-1)-(2)-1> 구조적 방법론(1960년대)
기존 방법론에 대한 언급은 아래 링크나 구글 형님과 대화하거나 괜찮은
도서를 구입하시는게 좋습니다.
3-1)-(2)-2> 정보공학 방법론
3-1)-(2)-3> 객체지향 방법론
3-1)-(2)-4> CBD방법론(기능, 프로세스 중심)
이런 도서를 추천합니다
3-1)-(2)-5> Enterprise 데이터 중심
엔터프라이즈 방법론은 좀 거대한 기업 시스템에 초첨을 맞춘 개념
3-1)-(2)-6> 객체 중심
객체 지향 이냐 객체 중심이냐 인데 같은 의미로 받아들여도 됩니다.
3-1)-(2)-7> component 중심
재사용성을 증가시키는 라이브러리 단위 개발
3-1)-(2)-8> White Box reUse / Black Box reUse
방법론이라기 애매하지만 보통 자사가 가지고 있는 라이브러리는 jar 형태로
제공하는게 보통이기 때문에 그에 해당 하는게 Black Box라 보면 될 듯.
3-1)-(3) 개방 방법론은 재사용성을 향상시키는 방향으로 발전함
2010년 이후 제안서 작성시 주로 등장하는 방법론은(방법론만 보았을때)
객체 지향 및 정보공학 방법론을 많이 사용함(한국)
3-2) 개발 방법론의 조건
3-2)-(1) 하나의 프로젝트를 일정 단계로 나눌 수 있음 3-2)-(2) (1)에서 정의한 각 단계별 산출물 리스트 보유 3-2)-(3) 각 산출물 리스트 에 사용할 산출물 양식 또는 문서를 포함 3-2)-(4) 해당 산출물 및 산출물 양식은 (1)에서 정의한 일정에서 요구하는 방법론 진행하는데에 있어 일치해야함 3-2)-(5) 한국에서 사용하는 개발 방법론 묶음? 또는 개발 방법론
3-2)-(5)-1> 관리기법1 - 한국 전산원에서 제공
- 구조적, 정보공학 방법론을 기초로 작성됨
- 개발 방법론, 관리 방법론에 대한 산출물들이 다 정의되어 있음
※ 마르미에 대한 설명 http://daddycat.blogspot.kr/2011/06/iii.html
3-2)-(5)-2> 마르미1 - 모름
- 구조적, 정보공학 방법론에 기초
3-2)-(5)-3> 마르미2
- 객체지향 방법론에 기초
3-2)-(5)-4> 마르미3 - 한국정보화 진흥원(2011.12)
- CDB를 기초
- 최초 작성시 ETRI에서 작성 이후 한국정보화진흥원으로 기술 이전
4. 관리 방법론
4-1) 관리 방법론 종류
4-1)-(1) PMBOK
관련 자격증이 PMP
PIM에서 제시한 방법
관리표준 ISO21500 국제 표준이됨(2013 5차 부터 적용)
4-1)-(2) CMMi
카네기 멜론대학내 SI 단체에서 제시한
프로젝트 성숙도 모델
프로젝트 관리 방법론과 통합된 개념
일정 이상 수준의 프로젝트 관리 방법론이 적용되었다면
일정 품질 이상의 제품이 도출된다. 1~5단계로 평가되고
3단계부터 유효성을 지님
우리 나라 업체도 많이 함. 보통 4단계 3단계 많이 따는걸 들음
4-1)-(3) SP인증제
CMMi 비용 과다에 따라 한국에서 자체 수행하는 인증
1~3등급으로 관리중 2012년에는 많이 하지 않지만 하는
업체도 있다고 했는데 지금은 ...?
4-1)-(2) PRINCE2 방법론
유럽에서 많이 쓰이는 방법론,
유럽 진출시 필요, 한국에서는 잘 안쓴다고 함
4-2) 관리 방법론의 영역, 그리고 관리 영역의 수행체계 (혹은 PMBOK)
4-2)-(1) 프로젝트 관리 삼요소
예산, 일정, 품질
예산, 일정, 범위
개념은 붉은색, 실무에서는 파란색을 비중있게 보고
자격증에서는 두가지를 다 알고 있어야 함
4-2)-(2) 프로젝트 관리 영역
4. 통합관리
5. 범위관리
6. 일정관리
7. 원가관리
8. 품질관리
9. 인력관리
10. 의사소통관리
11. 위험관리
12. 조달관리
+ 이해관계자 관리
※각 관리명칭 앞의 숫자는 pmbok에서 정한 관리영역별 번호
4-2)-(3) 각 관리 영역별 산출물
(각 항목 서류 양식은 시험 준비하신다면 손닿는데 있습니다 )
4-2)-(3)-1> 통합 :
- 프로젝트 관리 계획서
- 사업 수행 계획서
- (추가) 변경 관리 대장, 혹은 내역서 (포함) 변경 요청서
4-2)-(3)-2> 범위 :
- WBS(Work Breakdown Structure)
- (추가) 요구사항 정의서
- (추가) 영향분석서
- (추가) 개발방법론
4-2)-(3)-3> 인력
- 인력투입 계획서
- 공정별 인력투입현황표
- (추가)인력변경 요청서
4-2)-(3)-4> 품질
- 품질관리 계획서
- 인스펙션 결과서
- 테스트 결과서
- (추가)인스펙션 계획서
- (추가)테스트 케이스
- (추가)시나리오
- (추가)개발 방법론
4-2)-(3)-5> 위험
- 위험관리 계획서
- 위험관리 등록부
- (추가) 주간, 월간 보고(이슈 현황이 포함된) 혹은 이슈 현황
4-2)-(3)-6> 일정
- 인력별 프로그램 개발현황
- (추가) WBS
- (추가) PMS
4-2)-(3)-7> 의사소통
- 주간, 월간, 수시보고
- (추가) 착수 및 완료 보고
4-2)-(3)-8> 원가관리
- 실행예산 계획서
- 집행내역
- 결과서
- (추가)PMS
4-2)-(3)-9> 조달관리
- 조달구매 계획서
- 납품내역
- 결과서
- (추가)PMS
4-2)-(3)-10> 이해관계자 관리
4-2)-(4) 통합관리
플잭 진행중 하나의 변경 사항에 대한 다른 변경사항을 통제,
조정하도록 조율하는 관리 영역
(2010년 초반부터 PMO 라는 조직을 큰 프로젝트에 넣도록
하고 있는데 이와 관련 있음 또는 PM이 하는일)
4-2)-(5) 범위관리
범위관리에서는 요구사항 관리를 반드시 관리해야 하며
이를 위해서 WEB, 요구사항 정의서 두가지를 꼭 상의없는
변경이 이루어지면 안된다.
PM 그리고 담당 개발자가 모르는 사이 정의서 내용이 수시로 바뀌게
되면 프로젝트에 치명적일수 있음
WBS작성은 범위 관리분야에서 주도하여 작성
여기에 요구사항 상세화, 작업범위 크기 가 작성되야 하며
해당 문서에 고객의 동의가 되어야 하며
이후 고객의 변경된 요구사항을 같이 정리 할수 있어야 함
(=변경점관리가 되야함)
차후 검수시 요구사항 상세화 내용으로 검증 진행할수 있는 수준
아무리 큰 플잭도 2주 이내 작성해야 하며 그 이하는 범위를 쪼개서
작업,
WBS 관련 내용은 주기적인 내용을 고객에게 보고하는 체계를
갖추는게 좋음
요구사항 정의서
유형 분류(기능 혹은 비기능 -> 비기능에는 품질, 보안 성능 등등)
중요도/ 우선순위(등급별로 체크)
난이도
요구사항 추적표 : 중간 변경 요청시 반영을 고려
요구사항, 요구사항 변경에 따른 개발 지침
- 형상관리는 케이스별로 이렇게 한다.
- 요구사항 변경에 대해 이렇게 대처 한다. 정도가 포함되어야 함
4-2)-(6) 일정관리
WBS, 프로그램 개발 일정표 두가지를 중심으로 작업 진행 체크
가중치 항목 혹은 중요도 : 사업관리 영역, 또는 구현부분에서
가중치 부여 정도를 결정, 정의하는 부분
작업 완료 기준서? 혹은 기준 제시서 등
구현 완료의 기준이란? 어디까지 일까?
- 작성 완료
- Git 또는 서버에 업로드 완료
- 개발자가 테스트 완료하고 업로드 한 시점
- 업로드 후 테스터 조직이 테스트를 시작할 수 있는 시점
- 테스트 완료 시점
- 테스트를 완료 후 X개 이하 오류 검출시 완료
- 해당 부분에 대한 테스트 후 버그를 완전이 제거하여 재
테스트 후 다시 업로드 한 시점
- 테스터 조직이 테스트 후 오류가 없는 시점
아직 구현이 완료되지 않았는데 90%, 80%의 공정이란
소프트웨어 개발에서는 갭차이가 발생할 수 있음(아주 크게)
WEB를 작성하기 위한 툴들 : ex)CPM(Critical Path Methodology) 등등
일정 관리 차트 (작성보다는 이용한다는 게 더 알맞다고 봄)
간트 차트 (바 형태로 표현)
마일스톤(간트 차트 + 특정 이벤트를 포함시킴(감리, 이벤트 점검 등)
Pert기범(chart) 예상 소요일수을 판단해 현재 진행 상태가
어느정도의 퍼포먼스를 내고 있는지 판단함
CPM 각 활동을 도시화하여 표현, 전체 프로젝트 일정을 확인
PERT/CPM (CPM과 동일 단 PERT 방법으로 산출해냄)
4-2)-(7) 인력관리
중요 담당자
품질, 표준(통합)담당자 (개발환경구성, 프레임웍 구성, API개발)
인프라 구축
시스템
사용자
개발자
프로젝트에 소요되는 인적 자원을 관리하는 것
이를 관리하기 위해서는 필요한 정보, 수정해야할 사항은
계획표 또는 현황표
변경관리 내역서(변경관리 대장과 같이 작성)
제안서(방법론, 그러나 플잭 들어와서는 거의 결정된다고 봐야함)
방법론을 바꾸고자 하는 경우 아래 절차대로 진행
사업수행 계획서 작성(계약시 결정사항에 대해 재검토)
-> 고객 협의 -> WEB 작성(산출물, 일정, 추진절차)
-> 계획서는 최종본으로 수정되고 공문 처리
4-2)-(8) 예산관리
원가 및 예산산정
원가 를 결정하는 요소들
4-2)-(8)-1> 소프트웨어 개발비(인력비)
- 본수 또는 MM(Man/Month) 또는 FP(Function Potin) 소프트웨어 규모산정
- FP 측정순서 : 자료 입출력 혹은 조회-> 내.외부 논리 및 연계 파일(DB table)
-> 데이터 및 트랜잭션 기능 측정 -> 미조정 기능점수 계산 및 조정 인자 결정
-> 조정 기능 점수 계산
4-2)-(8)-2> 하드웨어 비용
- 트랜잭션과 동시사용자, 서버, 메모리, 디스크 용량 산정
- 위 내용을 토대로 하드웨어 Spec 결정 및 비용산정
4-2)-(8)-3> 소프트웨어 구매비용
- 웹 레포팅 툴, 문서보안, WEB-WAS-DBMS 등 시스템 소프트웨어
- 소프트웨어는 설치대상, copy수, 대상 서버 스펙, 설치대상 Agent수로 비용산정 함
4-2)-(8)-4> 출장비
4-2)-(8)-5> 인쇄비
4-2)-(8)-6> 동영상 제작
4-2)-(8)-7> 장소 임대 및 기타 간접비용
4-2)-(9) 조달구매관리
필요한 산출물
원가 산정내역서(대상,기준,계산과정을 보여주는 내용)
원가 산정 계획표 및 현황
4-2)-(10) 위험관리
정의 : 프로젝트 진행에 긍정적, 부정적 영향을 미치는 이벤트, 사건
리스크 : 잠재된 위험
이슈 : 위험이 외부로 보여지는 상태
작성 문서
위험관리계획서(사업 초반에 작성)
- 위험관리 계획서는 아래 순서로 작성함
- 리스크 관리 계획 수립
- 리스크 식별
- 정성적 리스크 분석
- 정량적 리스크 분석(정량적 리스크는 이슈라고 정의하기도 함)
- 리스크 대응계획 수립
- 리스크 감시 및 통제
위험관리대장(각 단계별로 작성) 혹은 리스트 등록대장
작성문서는 계획단계부터 개발이 진행되는 상황별로 계속
작성하는게 기본임.
(계속 세분화, 식별, 수시 작성, 업데이트)
정량적 리스크 분석 방법
민감도 분석(Sensitivity Analysis) : 환경을 억제하고 1개 값 변화시
결과값의 변화폭을 확인(에러나 값이 예상 밖의 변화를 기대함)
몬테카를로 시뮬레이션(Monte Carlo Simulation)
비슷한 유형 프로젝트 경험치를 보고 해당 프로젝트의 성공
가능성을 판단하는 방법
위험분류체계(RBS: Risk Breakdown Structure)
위험 등급을 분류 : 발생 가능성, 발생시 영향도
위험요소 측정 대상을 정의
확인 주기
확인 방법
위험 분류체계는 정기 보고 이전에 체크되어 작성포함되어야 함
4-2)-(11) 품질관리
작성 문서
품질관리 계획 및 결과서 혹은 품질 보증 계획서
- 포함사항 : 품질지표, 품질측정 대상, 방법, 주기 는 필수
- 장려사항 : 전문인력 확보, 품질활동 결과분석 및 조치
공적표준(공신력 지닌 기관에서 지정한 표준 KS, TTA, ISO9126)등
사실표준(산업계 표준처럼 쓰는 표준 CMMi, GS(Good Software)
- 인스펙션 계획(계획 단계에서 시기, 대상, 범위를 정의) 또는 동료 검토서
품질 담당자의 중재하 진행 필요
※ 오버뷰 : 실행전 계획 구체화, 품질관리 확인 대상자에게 교육
※ 사전검토 : 인스펙션 수행, 결과확인 까지 진행
테스트 활동 계획 및 결과서
품질지표(ISO9126)
- 프로세스(이행율 및 조치율)
- 품질활동(방법, 주기, 대상) 정의
- V&V모델이 품질관리 기본이 됨
테스트 : 내용이 커서 별도로 묶음
큰 프로그램내 테스트 100% 통과가 가능할까?
로또 맞는 정도라고 보면 적당하지 않을까?
그래서 정의하길 핵심과제는 100% 충족
그 밖에는 데드라인을 정하고 그 이상의 품질을 목표로 함
테스트는
- 단위테스트(기능 테스트)
- 통합테스트(전체 시스템 구동 테스트)
- 시스템 테스트(전체 시스템을 구동 + 보안, 시스템성능, 부하 측정)
- 인수 테스트(사용자 요구에 맞는가?)
감리활동(중요한 품질활동중 하나)
한국의 경우 공기업은 일정 금액 이상시 필수 진행(2012년 이전 기준)
감리는 중간감리(설계단계 끝날시), 와 최종감리(구현완료, 오픈전)
검사는 산출물 대상으로 감리가 진행되며 감리 대상은
사업관리(품질), 응용시스템, DB, 인프라 중심으로 진행
품질 활동으로 영역이 커지고 있다고 생각됨
4-2)-(12) 의사소통관리 - 13번과 내용이 일부 중첩되어 뒤로 미룸
문건들
이해 관계자 식별
의사소통 계획수립
정보 배포서
기대사항 관리, 성과보고서
관리중점
의사결정자, 실 사용자의 명확한 구분이 필요
회의시 적절한 대상을 참석하여 정보 획득 필요함
개발중에도 실 사용자에 대한 접근도 필요함
의사소통 관리 계획서
회의록 개념이지만 다른 차원에서 접근(장기적인 측면)
4-2)-(13) 이해관계자 관리(2013 이후 포함된 개념)
4-2)-(14) 프로젝트 진척 현황 관리
기성고 관리 : 시간, 인원을 모두 금액(숫자)로 환원
EVM(Earned Value Management)
계획과 실제가 틀어지는 갭을 조정하기 위한 계획대비 실적관리
통제 기법
계획대비 일정 진척률 차이(SV), 진척률 차이(SPI)
변경관리(범위, 일정변경, 인력, 원가 품질 등등)
적용 순서는 아래와 같음
변경 대상 식별
->영향도 분석
->반영여부, 반영 수준 협의(회의록 또는 공문처리와 병행)
->변경요청 공식화(변경요청서)
->변경에 따른 계획 수정(WBS, 사업수행 계획서)
->변경 내용 공유, 배포(변경관리 내역서, 자기 정기보고)
위험요소 관리
위험요소 현황확인
->요소별 분석
->대응방안 확인
->조치 및 대응
품질확인하기(실제 플젝간 참여 시기)
요구사항 분석
->설계
->구현(계획서 작성 및 품질 확인 준비)
->테스트(결과서 작성과 병행)
4-2)-(15) 프로젝트 종료하기
산출물 정리
검수 요청서, 검수 기준서(필수)
과업내용 대비표, 감리조치결과포(감리 포함시 필수)
유지보수 계획서, 잔여업무 수행 및 조치계획
(사용자와 프로그램 인도조건에 해당 사항이 포함시)
(보통 결국엔 포함되는 경우가 많음)
하자보수 이행 증권
(하자보수 이행 계약이 포함시)
(보통 결국엔 포함되는 경우가 많음)
프로젝트 이후 개선 방향 도출하기
댓글 없음:
댓글 쓰기