[소프트웨어 공학] planning and Management

프로젝트 계획과 관리 

프로젝트 : 정해진 기간 안에 한정된 자원으로 일정한 목적 달성 위해 수행하는 업무

(참여인원, 시간제한, 재료,비용 등 고려) 

 

프로젝트 관리 목적 : 필요한 여러자원,인력,비용,등을 효과적으로 사용 -> 목표달성

 

프로젝트 관리의 어려운점 : 개발대상 눈에 보이지 않음, 조직마다 프로세스 다름, sw 기술발전 빠름

 

프로젝트 관리 활동 : 계획, 조직, 모니터링, 조정

 

프로젝트 관리의 목표

-고객요구만족

-프로젝트 속성(품질,보안 등) -> 요청수준 부합

-계획된 일정 맞게 진행

-실행과정 모니터링, 조정 

-리스크 예측, 대비

 

*올바른 프로젝트의 가치분석과 리스크 파악(시간, 기술적어려움) 이 좋은 결과를 보장한다. 

*기술적 문제가 무엇인지 이해하는 것 자체가 프로젝트 관련 리스크를 결정하는 중요 요인

프로젝트 가치 

 

프로젝트의 타당성 분석 : 목표, 제한조건, 창출할 가치와 위험요인, 

 

* 목표가 품질, 비용, 시간 측명에서 달성 가능함을 보여야 함 

 

프로젝트 범위

일정계획 : 목표 및 범위 설정 -> wbs :모든 작업 확인 -> 스케줄링 순으로 진행된다. 

 

sw 개발 프로젝트 계획은 대상 업무나 문제의 범위를 정하는 것으로부터 시작한다. 이때 문제의 범위는 사용자 입장에서 작성한다.

(정확히 범위 한정, 구현될 시스템의 목표와 제약조건 정의)

 

*범위 설정 문서가 포함할 세가지 내용 : 프로젝트 목표및 요구, 가정과 제약조건, 산출물과 점검 일정

 

wbs

업무분업구조  - 개발팀이 프로젝트 목표를 달성하고 결과물 산출 위해 수행해야 할 작업을 계층적으로 분할한 것 

 

-일어나는 모든 작업을 찾아내는 것을 목표로 한다. 

-소작업들에 대한 소요일정이 예측되어야 전체 프로젝트 일정 계획 가능

-말단 노드의 수행에 필요한 자원 예측은 프로젝트 전체 수행에 필요한 자원 예측의 기초가됨 

-작업단위 프로세스 위주로 작성 가능, 산출물 위주로도 구성 가능 

 

*작업, 비용 정의 후 담당을 정하고 모니터링 하는데 유용

*작업에 책임진 부서 파악 도움

*wbs 는 스케줄링 작업의 입력이 됨 

*스케줄링 - wbs에서 계층적으로 분할된 작업들을 어떤 순서로 수행할지 정하는 작업 , 일정 단축을 위해 작업순서를 최적화해야 한다. 

 

스케줄링

 

wbs 를 기초로 작업의 일정을 정의하는것이다. 

- 일정파악 -> 인력규모, 비용 추정 가능

 

스케줄링은 간트 차트로 표현 

-작업 사이의 의존관계 파악

-cpm 방법 이용한 여유시간 계산

 

작업 의존관계
강한의존관계 : 제거시 재작업 비용 발생, 선행작업이 끝나야 작업 가능

약한 의존관계: 한 작업이 완료되지 않아도 다른작업 시작 가능

 

노드와 간선으로 구성된 네트워크 

-노드에는 작업, 간선은 작업 사이의 선후 의존관계 표시 

-노드에는 작업의 소요일자 or 시작, 완성이리 표시 

-일부 노드는 이정표(프로젝트 중요 중간결과 완성했단 표시, 이정표일 완성 못하면 일정 수정해야 ) 지정 가능 

 

임계 경로와 여유시간 계산

임계경로 = 소요시간이 가장 긴 경로 (이 경로상의 어떤 작업이라도 늦어지면 전체 프로젝트 지연-> 관리자의 중간점검 대상)

여유시간 = 가장 늦은 착수일 - 가장빠른 착수일 

*임계경로 상에 있으면 바로 시작해야! 여유시간 이 0이다. 

 

비용 예측 기법

프로젝트 계획 작업에서는 sw 개발비용과 기간을 예측할 필요가 있음

- 예측은 개발 시작전에 이루어져야

- sw 개발을 위한 입찰 시 비용예측이 아주 중요

 

노력 자원 기간 사이의 관계 이해가 필요하다. 

노력(E) : 필요한 작업 양 (일,주,월 단위 표현) 

자원(R) : 동원될 수 있는 인력 양 (m)

기간(D): 작업 수행 기간

 

관계식 

D = E/M

(m = 인력 투입 비율의 총합) => 투입하는 인원에 대해 기간 파악 가능

 

비용 예측의 주요 변수는 엔지니어 인원수 와 작업기간 이다. 

 

비용 예측 기법

- wbs 를 기초로 전문가가 각 작업 소요비용 추정

- pert : 기간을 결정하기 위해 가중평균, 즉 기대치를 계산하는 방법 
    1) 낙관적일때 예측되는 소요기간(o)

    2) 보통일때 소요기간 (m)
    3) 비관적을 때 소요기간 (p) 

=> t = (o + 4m + p) / 6(경험적으로 얻은 상수)

-알고리즘식 방법 : 개발 종료된 프로젝트 데이터로 측정함수 f 추정, COCOMO , 기능점수, 객체 점수모델 등이 있음

 

COCOMO -81

 cocomo 초기모델 -> 코드 라인수가 많으면 노력을 많이 했겠지 ~ : 완성될 시스템의 규모 추정 -> 수식에 대입해 비용과 노력(MM)추정

 

노력을 규모 기반으로 추정하는 모델 

-개발 sw 유형, 팀, 프로세스 등 제품에 영향주는 요인 고려

-완성된 프로젝트의 비용, 속성 분석 -> 경험에 근거해 예측공식 구축

 

노력 = A * size^b *M

 

A : 개발기관 특징, 개발 sw 유형에 좌우되는 상수

B : 1~1.5 사이 의 값 ( 노력이 규모에 선형적으로 비례 하지 않음을 위해 둠) 

M : 프로젝트에 영향주는 다른요소들의 보정계수 (제품성격, 시스템 특성 등) 

 

코코모 모델 유형

유기형 : 소규모 팀이 개발

반 결합형 : 유기형과 임베디드 중간, 트렌잭션, os , db 관리 시스템

내장형 : 하드웨어가 포함된 신시간 시스템 , 미사일 유도 등 

 

단점

프로젝트 초기단계의 size 예측 어려움 ( 기능규모 예측이 더 쉬움 )

기본 예측 모델에서는 b와 m 에 영향 주는 요소 주관적

규모기반 모델은 공통적으로 보정에 의존적  

 

기능점수 

소프트웨어 시스템이 가지는 기능을 정량화 한 것이다. 

-초기단계에서는 정확한 코드라인 수 예측 불가

-입 출력 질의 등의 개수로 sw 규모 , 복잡도 산정

- 시스템이 사용자에게 제공하는 기능을 기초로 sw 규모 측정

 

기능점수는 총 기능 점수와 처리복잡도 보정계수를 곱한것 

fp = gfp * pca(보정계수)

-구현되는 언어에 관계없는 메트릭(지표)임

-단위시간당 프로그래머의 생산성을 기능점수로 표현한 자료 요구

-기능 점수 방법은 모든 항목에 일률적 가중치 적용됨 문제있을수 있음

 

프로젝트 팀 조직

팀 구성 방법이 프로젝트 운영 sw 결과물에 영향 미친다. 

 

팀 역할

중앙 집중식 조직 : pm 위주

분산형 조직 : 모두 동료 

혼합형 조직 : pm 두고 서브 그룹장 둔다. 

 

직능별 조직 

개발자들을 역할에 따라 같은 부서에 속하게 하는것 

- 서로 다른 부서가 한 프로젝트의 다른 단계에 들어와 작업 수행 

- 부분적으로 완성된 결과물이 한 부서에서 다른 부서로 전달되면서 sw 진화 

ex) 분석팀, 설계팀, 개발팀, db팀

 

특징 

- 팀원은 한 부서에 소속, 지시와 보고는 관리자 한 사람을 통해 이뤄짐

- 부서별 협력을 위해 문서, 회의등 의사전달 체계 잘 확립 되어야 

- 전문지식을 공유할 수 있어 개인의 기술발전과 기업 노하우 축적에 도움

 

* 부서 사이의 sdlc 각 단계의 커뮤니케이션 필요 

* 효과적 인력사용, 전문성 유지 , 기술 전수 용이, 협력적, 안정적,

* 회신이 느림, 고객 인터페이스 약함, 플젝 관리 취약

프로젝트별 조직 

서로 다른 역할을 담당하는 직능별 개발자들이 프로젝트별로 부서를 조직 

- 어떤 프로젝트에 투입되어 시작부터 끝까지 그 프로젝트 부서에서 일하는것 

- 같은 팀이 소프트웨어 개발주기의 모든 작업을 담당함

=> 프로젝트 완결되면 사라짐, 독립적으로 존재 

 

특징

-팀 내부에서 작업결과의 전달과 협력 이루어짐 

-의사 전달 경로가 짧으며 인력, 진도 등 프로젝트 관리 편함

-프로젝트 관리자가 독립성 가지고 관리 (고객 -개발팀 접촉 쉬움)

 

* 일정 및 비용관리 용이, 고객과 연결 간단, 빠른 회신, 커뮤니케이션 간단, 관리 교육 용이 , 플젝 파악 쉬움

* 기술적 불확실성, 미래 작업 배정 불투명, 플젝 사이의 기술적 정보 교류 취약 

 

매트릭스 조직 

직능별 조직과 프로젝트별 조직 구성 혼합

- 관리자와 개발자는 직능별 조직에 속해 있되 전문지식이 필요한 지정된 프로젝트 위해 간헐적으로 일함 

- 직능별 조직의 관리자가 프로젝트 책임 맡고 직능별 조직부서에 소속된 개발자가 프로젝트 참여 

- 모든 팀원이 보고한느 두명 이상의 관리자 ( 직능별, 프로젝트별) 이 있음 

 

장점 

자원 효율 극대화 : 각 조직의 인력을 프로젝트에 공유

유연한 대응 : 필요따라 특정 프로젝트에 더 많은 자원 할당

전문성 유지 : 팀원은 전문 직능 조직에 속해있을 수 있어 전문성 유지와 지속적 기술발전 도모 

 

단점

이중보고 : 보고혼란 , 우선순위갈등

의사소통 복잡 : 여러부서 인력 협력, 의사소통 힘들 수 있음

 

매트리스 조직 분류

강한 매트릭스 조직( 직능  < 프로젝트 ) : 프로젝트 관리자가 플젝 책임, 팀원들은 직능별 조직보다 프로젝트에 더 개입

약한 매트릭스 조직( 직능 > 프로젝트) : 프로젝트의 책임을 직능별 관리자가 맡고, 팀원도 여러 프로젝트에 적극적 담당

 

* 자원사용 효율은 직능 < 매트릭스 < 프로젝트 순이다. 

애자일 조직

애자일 선언 - 구성원의 상호작용과 고객과의 협력, 요구변경 중요시 여김

-> 밀접히 협력하는 5-8 명의 작은 인원으로 팀 구성 (개인에게 많은 책임)

- 개인보다 팀 중요시 생각, 책임 역할 교환가능

- 결과와 이슈에 대한 오너쉽 공유, 융통성 있는 조직 (공동책임)

- 팀원이 여러 직능 담당 가능, 필요따라 팀 재구성 가능 ( 팀원이 스스로 책임지고 관리하는 독립적 부서) 

 

스크럼에서의 정의

- 스크럼 마스터 : 프로젝트 진도 측정 및 문제 해결 , 팀 보호

- 고객 : 고객도 개발조직에 포함되어 요구분석 결과물의 오너가 됨

- 팀 : 작업 수행위해 스스로 조직 -> 책임을 짐

 

애자일 팀 단점

- 큰 규모의 프로젝트에 적합 x 

 

실행과 모니터링

프로젝트 실행 동안 모니터링 계획과 현재상황 비교 -> 변경 한다. 

 

프로젝트 실행 

작업 시작 미팅 : 팀원과의 소통회의 

작업 결과 수집 : 결과물을 체계적으로 수집 , 결과물을 수집하는 도구는 보관함과 버전화 ( 버전화해서 보관함에 넣고 뭐가 변경됐는지 문서로 기술) , 진행상황에 대한 정보 수시로 수집, 작업상황이나 난이도에 대한 느낌 또한 수집 (진행상황 파악 위해)

 

모니터링 목적 - 프로젝트 현황 파악, 차이 분석 하여 조치하기 위함

- 현황은 범위, 일정, 비용, 품질 등 관점으로 파악

- 데이터 수집/분석하면 미래의 프로젝트에 대한 정확한 예측 가능 

- 모니터링의 중점부분 : 일정과 비용, 진척도 

 

일정 모니터링 

계획된 일정을 기초로 실행 값을 비교

- 시작일, 종료일,노력과 진행상황 비교 

- 노력을 시간단위로 환산하여 데이터 수집 가능

직관적이고 간단하지만 진행상황 한 눈에 볼 수 없다. 

 

어닝 밸류 분석

비용과 일정을 통합하여 모델링한다. 

-분석 과정 복잡, 전체 진척상황 이해 쉬움

- 계획된 노력(비용) , 실제 진척도 ( 어닝밸류 ) , 노력(실제비용) 을 금전적 가치로 측정

*계획, 작업, 진척도를 같은 단위로 측정

 

pv - ev = 일정차이

ac - ev = 비용차이 

 

번다운 차트 

스크럼에서는 수행된 작업보다 남아있는 작업에 초점을 두어 일정 모니터링 ( 소프트웨어 개발까지 걸리는 추가비용 계산 )

- 구현될 각 기능에 이상적인 투입시간 할당

- 각 기능은 스프린트에 배정되어 기능이 완성되면서 소멸되는 스프린트 점수로 기록 

 

목표 : 기능이 출시되는 속도 측정

 

리스크 관리 

계획 단계에서는 목적 달성을 위해 다양한 불확정성을 다뤄야 한다. 

- 계획은 명시되어 있으나 성취를 위해서는 현실적인 변화와 부정적 요인에 대한 고려 필요 

 

리스크 관리 - 위험 요인을 파악, 평가 ,관리하는 기술과 노하우, 프로세스 의미 

목적 : 프로젝트에 대한 긍정적인 사건의 가능성 높이고, 부정적인 사건의 일어날 가능성 낮추는것

 

리스크 파악- 위험요인 이해하고 특징 문서화

반복적 작업이며 리스크를 등록하여 정량, 정석적 평가의 기초 자료로 이용한다. 

리스크 찾는 방법

-회의 

-문서 분석 :프로젝트 관련 문서로부터 추출

-리스크 분할 구조, 체크리스트 : 위험 아이템을 분할하여 계층 구조로 그리거나, 체크리스트 만들어 파악

-유추: 비슷한 프로젝트 유형과 비교하여 유추 

 

리스크 평가  - 리스트를 프로젝트에 대한 영향도에 따라 평가 , 우선순위 부여 

정성적 방법 : 리스크 발생 확률에 대한 정확한 정보 부재 시 고려 (리스크 매트리스 활용(주관적), E 는 관리대상, H 는 모니터링 대상, 그외는 일반 위험)

정량적 방법 : 리스크 발생 확률을 고려한 영향을 비용으로 환산 

 

관리전략

- 회피위해 계획 변경

- 다른 기관에 책임 위임

- 프로토타이핑 수행

- 불확실성 제거 위해 유능한 인재 등용

- 제 3자와 협업 (위험 분산) 

 

유념사항

-완전히 큰 위험요소 파악 필요 x ( 그런 플젝은 시작이 안됐을 것 )

- 영향을 원인과 혼돈하지 말것 ( 일정 지연이나 자체보상금 부과는 프로젝트에 미치는 영향임 ) 원인은? 개발능력 부족 등 

원인을 찾아야 !