1. 1장: 관리 행위
1) 소프트웨어 프로젝트의 관리상 특징
● 보이지 않는다.
건축관리자의 경우 작업중인 건물을 쉽게 눈으로 확인할 수 있으나 소프트웨어는 눈에 보이지 않기 때문에 진행상황을 파악하기가 어렵다. 그렇기 때문에, 소프트웨어 개발의 경우 진척사항을 확인하기 위해 문서에 의존하게 된다.
● 소프트웨어 프로세스에 대한 표준이 없다.
철도를 놓는 등 역사가 오래된 기존의 공학에서는 반복되고 검증된 프로세스를 사용할 수 있지만, 소프트웨어 프로세스는 역사가 짧고 아직 이해가 부족하거나 검증이 필요한 부분이 많다.
● 큰 규모의 소프트웨어 프로젝트는 1회성인 경우가 많다.
컴퓨터 또는 통신분야의 기술은 발전 속도가 빠르기 때문에 큰 규모의 프로젝트를 진행 했을 경우 얻은 경험을 재활용하기가 어렵다.
이러한 문제점들 때문에 시간, 예산을 지키지 못하거나 스케줄대로 진행하기 어렵다.
2) 관리자 활동
① 제안서 쓰기
프로젝트의 목적, 어떻게 진행할 것인가에 대해 쓴다. 비용이나 스케줄이 산출되기도 한 다. 이 프로젝트가 특정 조직에 왜 필요한지에 대한 설명이 들어가기도 한다. 제안서를 잘 쓰는 것은 특별히 정해진 방법이 있는 것이 아니라 경험에 의해 얻어지는 기술이다.
② 프로젝트 계획 및 스케줄링
프로젝트를 진행할때의 업무나 중간 산출물(milestones) 또는 결과물(deliverables)를 정 리한다. 프로젝트의 진행이 처음 목적에 맞는 방향으로 이루어져야 하며, 비용산출을 위 한 토대가 되는 작업이기도 하다.
③ 프로젝트 비용산출
프로젝트 계획이나 스케줄을 실행하기 위해 필요한 자원이나 이에 대한 비용을 미리 계산해낸다.
④ 프로젝트 모니터링과 검토
모니터링은 계속적으로 필요한 작업이며, 프로젝트가 계획이나 비용대로 진행되고 있는지를 검사한다.
숙련된 관리자는 팀원들과의 비공식적인 대화로부터도 프로젝트 진행에 대한 많은 정보를 얻을 수 있다.
⑤ 인력 선택과 평가
개인의 능력과 프로젝트 비용, 스케줄을 고려하여 적절한 사람을 선택하고, 필요한 경우 교육을 시켜주어야 하며, 이들의 수행사항을 평가할 수 있어야 한다.
⑥ 보고서 작성 및 프레젠테이션
고객뿐 아니라 계약기관에 제출할 보고서를 작성한다. 보고서는 명확하고 이해하기 쉬 워야하며, 진척사항검토를 위한 경우는 프레젠테이션도 필요하다. 그렇기 때문에 문서 작업뿐 아니라 구두상으로 효과적으로 커뮤니케이션하는 것도 관리자가 갖추어야 할 하 나의 기술이다.
2. 2장: 프로젝트 계획
1) 계획의 종류
● 품질 계획(Quality plan)
: 프로젝트에 사용될 품질 프로시져와 표준에 대해 기술
● 검증 계획(Validation plan)
: 시스템 검증에 사용될 접근법, 자원, 스케줄에 대해 기술
● 구성 관리 계획(Configuration management plan)
: 사용될 구성 관리 프로시져와 구조에 대해 기술
● 유지보수 계획(Maintenance plan)
: 시스템 유지보수 비용등에 대한 유지보수 요구사항들을 예측
● 직원 개발 계획(Staff development plan)
: 프로젝트 팀 직원들의 기술이나 경험을 어떻게 개발할 것인지를 기술
2) 소프트웨어 프로젝트 개발 계획의 구성
① 도입(Introduction)
프로젝트의 목적과 제약 조건들에 대해 간략히 기술
② 프로젝트 조직(Project organization)
개발팀이 구성되는 방법과 팀에서 담당자들의 역할에 대해 기술
③ 위험 분석(Risk analysis)
가능한 프로젝트 위험에 대해 기술하며, 이러한 위험을 줄일 수 있는 방법이 제안된다.
④ 하드웨어/소프트웨어 자원 요구사항(Hardware and software resource requirements) 개발을 하는데 필요한 하드웨어나 소프트웨어에 대해 기술한다. 만약 하드웨어 구입이 필요하다면 가격측정이나 진행 스케줄 등이 포함된다.
⑤ 업무 분해(Work breakdown)
프로젝트를 세부활동으로 분해하고, 중간산출물(milestones)이나 결과물(deliverables)를 분석해낸다.
⑥ 프로젝트 스케줄(Project schedule)
각 활동들 사이의 의존상태(Dependency)를 파악하고, 각각의 중간산출물(milestones)을 얻는데 예상되는 시간을 분석해내고, 인력을 프로젝트 세부활동별로 적절히 배치한다.
⑦ 모니터링과 보고(Monitoring and reporting mechanisms) 모니터링을 통해 필요한 시기에 보고서를 작성
3) 중간산출물(Milestones)과 결과물(deliverables)
● 관리자는 프로젝트 진척사항에 대한 정보가 필요하다 : 소프트웨어는 손으로 만질 수 없기 때 문에, 이러한 정보는 “ 문서” 로 제공되어야 한다. 이러한 정보가 없다면, 진행사항이나 비 용측정, 스케줄링이 불가능하다.
● 중간산출물(milestones)의 특징(작성요령)
- 소프트웨어 프로세스 활동의 종료시점에 얻어지는 산출물
- 보고서와 같은 형식적인 결과물이어야 한다.
- 문서량이 많을 필요는 없다.
- 애매한 표현은 피해야한다.
(“ 코딩의 80퍼센트 완료” 와 같은 표현은 프로젝트 관리에 도움이 되지 않는다.)
● 결과물(deliverables)
- 고객에게 전달되는 프로젝트 결과물이다.
- 주요 프로젝트 단계(phase)의 종료시점에 얻어진다. (명세, 설계 등)
- 결과물(Deliverables)은 중간산출물(milestones)이지만 역의 경우는 성립하지 않는 경우도 있다. 즉, 중간산출물(milestones)는 프로젝트 관리자가 사용하는 내부적인 결과물인 경우가 많다.
프로토타이핑(prototyping)이 요구사항 검증(validation) 방법에 사용될 경우 요구사항 명 세(requirements specification)와 관련한 활동을 보여준다. 각 활동(activity)에서 얻어지는 주요 중간산출물들을 보여주고 있으며 시스템 요구사항이 결과물이다.
3. 3장: 위험요소 관리
1) 프로젝트 관리자의 주요한 업무 중 하나는 프로젝트 스케줄이나 소프트웨어의 품질에 영향
을 줄 수 있는 위험요인을 미리 예측하고 이를 해결하는 것이다. 이를 “ 위험 관리(Risk management)” 라고 한다.
2) 위험(risk)의 종류
● 프로젝트 위험(Project risks): 프로젝트 스케줄이나 자원에 영향을 줌
● 제품 위험(Product risks): 개발되는 소프트웨어(software)의 품질(quality)이나 성능(performance)에 영향을 줌
● 사업 위험(Business risks): 소프트웨어를 개발하거나 생산하는 조직에 영향을 줌
3) 위험은 복합적일 수도 있다.
숙련된 프로그래머가 프로젝트를 그만두게 된다면,
- 프로젝트 위험(Project risk): 시스템 개발이 지연
- 제품 위험(Product risk): 대체인력은 이전만큼 숙련되지 못하여 실수할 가능성이 높다.
- 사업 위험(Business risk): 그만큼의 경험을 추후 사업에 적용할 수 없다.
4) 가능한 소프트웨어 리스크의 예
● 직원 이직(Staff turnover)
프로젝트 위험::숙련된 직원이 프로젝트와 완료되기 전에 그만둠
● 관리 변경(Management change)
프로젝트 위험::다른 우선순위 때문에 조직상의 관리에 변화가 생김
● 하드웨어 부재(Hardware unavailability)
프로젝트 위험::프로젝트를 위해 필수적인 하드웨어가 스케줄에 따라 확보되지 못하였다
● 요구사항 변경(Requirements change)
프로젝트, 제품 위험:: 예상보다 큰 요구사항의 변화가 발생하였다.
● 명세 지연(Specification delays)
프로젝트, 제품 위험:: 필수적인 인터페이스의 명세가 스케줄에 맞게 이루어지지 못했다.
● 규모 과소평가(Size underestimate)
프로젝트, 제품 위험:: 시스템의 규모가 과소평가 되었다.
● CASE도구 비효과(CAES tool underperformance)
제품 위험:: CASE툴이 예상보다 효과적이지 못했다.
● 기술 변화(Technology change)
사업 위험:: 시스템을 위한 기반 기술이 새로운 것으로 바뀌었다.
● 제품 경쟁(Product competition)
사업 위험:: 시스템이 완료되기 전에 경쟁 제품이 먼저 출시되었다.
5) 위험 관리 프로세스
● 위험 확인(risk identification)
가능한 프로젝트, 제품, 사업 위험요소의 확인
● 위험 분석(risk analysis)
각 위험들에 대한 결과 분석
● 위험 계획(risk planning)
위험을 피하거나(avoid) 최소화(minimize)하는 방법에 대한 정리
● 위험 모니터링(risk monitoring)
위험은 계속적으로 평가되고, 이에 따라 계획은 끊임 없이 변경된다.
6) 위험 확인(Risk identification)
● 프로젝트에서 가능한 위험들을 찾아내는 것
● 가능한 위험 요소들의 예
① 기술 위험(Technology risks)
- 데이터베이스가 예상보다 많은 수의 트랜잭션을 처리하지 못한다
- 재활용하는 컴포넌트가 기능상의 결함을 가진다.
② 사람 위험(People risks)
- 필요한 기술을 가진 인력을 구할 수 없다.
- 중요한 시기에 주요 인력이 사고를 당했다.
- 직원을 위한 필요한 훈련이 불가능하다.
③ 조직 위험(Organizational risks)
- 조직의 변경으로 관리체계가 바뀌었다.
- 회계상의 문제로 프로젝트 예산이 삭감되었다.
④ 도구 위험(Tools risks)
- CASE도구에 의해 생성된 코드가 비효율적이다.
⑤ 요구사항 위험(Requirements risks)
- 요구사항의 변경 때문에 주요 설계의 재작업이 필요하다.
- 고객이 요구사항의 변화가 가져오는 영향을 이해하지 못한다.
⑥ 추정 위험(estimation risks)
- 소프트웨어 개발 기간이 잘못 예측되었다.
- 결함률이 실제보다 낮다고 예측했다. 소프트웨어 규모를 과소 평가했다.
7) 위험 분석(risk analysis)
● 위험 요인이 생길 가능성과 결과의 심각성 정도를 판단합니다.
8) 위험 계획(risk planning)
● 위험 계획은 주요 위험 요소에 대한 대책을 세우는 것입니다.
- 회피 전략(Avoidance strategies): 위험이 발생할 확률을 줄인다. ( 예 - 결함이 있는 컴 포넌트를 안정적인 컴포넌트로 대체하는 경우 )
- 최소화 전략(Minimization strategies): 위험 발생시 영향의 정도를 줄인다. ( 예 – 팀원 들의 업무를 겹치게 재구성하여, 서로간의 업무를 평소에 잘 이해할 수 있도록 한다.)
- 긴급 대책 계획(Contingency plans): 주요 문제가 발생했을 경우 대안을 미리 마련해 놓도록 하는 것 ( 예 – 프로젝트가 사업의 목적에 필요한 중요한 위치에 있음을 설명하 는 자료를 미리 준비)
9) 위험 모니터링(risk monitoring)
주기적으로 위험을 재확인하고, 변경사항이 있는지를 점검. 모든 관리 진행에 대하여 계속 적으로 이루어져야 함
[ 정리하기 ]
▣ 효과적인 소프트웨어 프로젝트 관리는 예산과 스케줄을 고려하여 소프트웨어를 개발하기 위 해 필수적이다.
▣ 소프트웨어 관리자는 프로젝트 계획, 추정이나 스케줄링과 같은 주요한 업무를 수행한다. 특 히, 계획과 추정은 계속적으로 반복된다.
▣ 프로젝트 중간 산출물(milestone)은 관리 목적상 프로젝트 활동별로 얻어지는 것이며, 결과물(deliverable)은 프로젝트 고객에게 전달되는 산출물이라고 할 수 있다.
▣ 주요 프로젝트 위험(risk)에 대해서는 확인, 평가하여 발생 가능성과 발생시 예상 결과가 분석되어야 한다.
[ 참고하기 ]
Assessment and Control of Software Risk by T. Capers Jones, 1994, Prentice Hall
이 책은 소프트웨어 프로젝트 관리에서 발생될 수 있는 50가지 이상의 문제와 예방/ 치료책을 요약한 안내서이다.
방법론이나 도구, 조직 구성, 기술, 고객 및 사회 환경과 관련된 위험 문제를 다뤘다.
Software Risk Management- Principles and Practices Barry W. Boehm (1991)
이 글은 현재의 위험 관리 방법을 조사하고 저자의 경험을 기술한 내용이다.
'정보과학 > 소프트웨어공학특론' 카테고리의 다른 글
| 요구 공학 프로세스 (2) | 2023.11.25 |
|---|---|
| 소프트웨어 요구사항 (1) | 2023.11.25 |
| 소프트웨어 프로세스(1) (1) | 2023.11.23 |
| 시스템 공학 (0) | 2023.11.23 |
| 소프트웨어공학특론 개요 (3) | 2023.11.23 |
