Category Archives: Practical Software metrics for Project management

public and private project metric


metric산출하여 개인적 역량을 평가할 수도 있겠으나, 좋은 점보다는 꼼수가 만발할 것이므로, metric을 측정하기 위해서는 주의해야 할 필요가 있다.

아래 표는 public및 private metric에 대한 사례이다.

Private(to individual) Private (to project team)
(Public to team members)
Public (to company)
결함율(by individual) 결함율(team 단위) 결함율(project단위)
결함율(by function) NCSS/function NCSS(제품단위)
결함율(개발 단계에서) Estimated NCSS/function Effort(project단위)
컴파일 횟수 re-inspection 횟수 Calendar times
함수당 결함수 함수당 결함수
결함당 Effort(평균)

개인 단위로 metric을 측정하는 것은 바람직하지 않음. team단위로 metric을 매기는것은 괜찮음.

팀 멤버가 metric을 측정하는 것에 대한 합의가 이루어져야 함.

Functional Management 1. 개인을 평가하기 위해 메트릭을 사용하는 것을 허용하지 말 것.
2. 명확한 목표를 세우고 성공을 위한 메트릭을 정의하는 것을 직원이 돕도록 하라
Project management 1. 개인적 성과를 측정하려는 시도를 하지 말 것
2. 추적하려는 메트릭에 대해 팀 구성원들의 동의를 얻고 프로젝트 계획에 정의하라
3. 수집하고자 하는 데이터에 대해 팀에게 정기적인 피드백을 제공하라
Project team 1. 정확하고, 즉시적인 데이터를 보고하는데에 최선을 다하라
2. 프로세스를 개선하기 위해 데이터에 집중할 수 있도록 도와라
3. 개인적 성과를 드러나도록 하는 목적으로는 사용하지 말라

이 부분을 보면 metric data는 판도라의 상자인 것 같기도 하고.. 회사 분위기를 안좋게 만들 수 있는 강력한 무기인것 같기도 하다..

Advertisements

Engineering effort및 일정을 최소화하기 위한 프로젝트 관리


비용 및 일정을 줄이는 것은 고객의 니즈와 당신의 조직에게 아주 효과적인 방법이다.

이 전략을 적용하기 위한 지표들로는 다음과 같은 것들이 있을 수 있다.

  • engineering months by product/component/activity
  • engineering months by defects/enhancements
  • defect and enhancement request counts
  • counts of remaining critical and serious defects
  • calendar time by phase and activity
  • code stability(% of code changed)
  • size(NCSS, tasks, objects, components)
중요 특징들 엔지니어링 노력 및 스케줄의 최소화
중요 비즈니스 요인 신제품 개발에 대한 경쟁력 압력 및 비용 제어
가장 중요한 시점 여러 경쟁사들이 제품을 만든다면 당신들은 이윤이 나는 제품을 더 팔아야 한다.
특징적 요소들 인도 날짜 및 노력에 집중함
가장 시각적 메트릭 날짜, 엔지니어링 노력, 결함
전략을 이끌어나가기 위한 그룹 회사 관리 부서
고객과 직접적 접촉을 해야 하는 그룹 마케팅/공장 고객 지원
너무 제한적 집중으로 인한 잠재적 문제점 결함 백로그는 관리가 안될 수 있다; 고객과 개발자들이 혼란스러울 수 있다.

노력과 시간을 줄이기 위한 방법?

  • 대부분의 시간을 소비하는 활동들을 개선한다.
  • 자주 defect가 발생하는 영역에 집중한다.
  • 대부분의 effort를 하는 defect에 집중한다.

어디서 비용이 많이 발생하는가?
– 알고 싶으면 tracking이 필요하다. 프로젝트 모니터링은 프로세스 개선을 위한 첫걸음이다.

개발 단계에 따른 엔지니어링 노력의 비율

Firmware
(31 projects)
Systems
(48 projects)
Applications
(53 projects)
Requirements 15% 14% 22%
Design 21% 19% 16%
Implementation 39% 30% 34%
Test 25% 37% 28%

위의 표는 엔지니어링 effort를 개선하기 위한 목적 외에도 여러가지 목적을 위해 사용될 수 있을 것 같다.  저 표를 보고 “어? 우리는 저렇게 일 안하는데? 라고 하는 조직이 많을 텐데, 그렇다고 하면 그 둘 간의 gap으로 인하여 어떤 차이가 있는지를 분석해보는 것도 해당 조직의 생산성을 높일 수 있는 방법이 될 수 있을 것으로 보인다.

또한 위의 표로부터 project의 기간 산정을 하는데 매우 유용한 reference가 될  수도 있다는 점이다. 비례식을 적용하여 requirement를 완성하는데 5달이 걸렸다면 대충 requirement의 개발 시간 비율을 20%로 가정하면, 25개월, 즉 2년 1개월이 프로젝트를 수행하는데 필요한 시간이라는 것을 알 수도 있을 것이다.

비용을 줄일 수 있는 새로운 방법을 학습하기

엔지니어들은 잘 알고 있을 수도 있겠지만, 신기술을 도입하면 마치 비용이 줄어드는 환상을 갖는 비전문가이면서 높은 자리에 있는 분들을 생각하게 되는 섹션이다. in the long run, 아마도 그렇게 될 수 있을 것으로 생각한다. 근데, 고위직에 있는 분들이 모두 그런 투자가 장기적 투자를 필요로 한다는 사실은 잘 모르고 있는 듯 하다. (현실과 이상의 gap은 항상 거리가 있다.)

개발 및 시험 스케줄을 줄이기 위한 추적

위의 표에서 보면 코딩 및 시험이 개발 일정의 60%를 차지한다는 것을 알 수 있으므로, 해당 활동에 대한 detail을 추적하여 분석한다.

  • 클래스의 갯수를 추적
  • operation(or method)의 갯수를 추적
  • non-comment source statements(NCSS)를 추적
  • number of defects per hours of testing time
  • amount of test execution time between defects
  • past average times to find and fix defects

고객 만족을 최대화하기 위한 프로젝트 관리


고객만족을 최대화하기 위한 목적을 가진 프로젝트 관리는 고객의 니즈에 대한 이해가 필요하다. 그리고 그런 이해가 제품에 막대한 영향을 미치게 된다.

중요 특징들 고객만족 극대화
중요 비즈니스 요인 마켓 쉐어를 잡으려는 시도
가장 중요한 시점 시장에 초기 진입할 때
특징적 요소들 고객 의사소통, 빠른 대응
가장 시각적 메트릭 조사, 인터뷰 데이터, 제품 메트릭, 결함
전략을 이끌어나가기 위한 그룹 초기에는 개발 팀, 나중에는 고객 대응팀
고객과 직접적 접촉을 해야 하는 그룹 개발 팀
너무 제한적 집중으로 인한 잠재적 문제점 제품 개발의 프로세스가 개선되지 않을 수 있다.

주요 지표

  • product metrics
  • survey data
  • counts of unresolved critical and serious defects
  • calendar time by phase and activity(emphasis on times customers experience problems)
  • defect and enhancement request counts
  • break/fix ratio

Customer needs에 대해 구조화하기

1) FURPS+ model을 이용하는 방법. ISO9126의 품질속성 관점과 유사한 것 같다. 각 관점에서 고객이 원하는 내용을 유도한다.

functionality feature set
capabilities
generality
security
usability human factors
aesthetics
consistency
documentation
reliability frequency/severity of failure
recoverability
predictability
accuracy
mean time to failure
performance speed
efficiency
resource consumption
thruput
response time
supportability testability
extensibility
adaptability
maintainability
compatibility
configurability
serviceability
installability
localizability

2) QFD(Quality function deployment) 방법 사용하기

FURPS+모델로부터 고객의 요구사항을 도출하고, 현재 시스템이 가지고 있는 점수를 기술하고, 앞으로 나아가야 할 방향(Engineering effort)을 제시

상당히 유용한 접근법인 것 같다. 꼭 프로젝트 모니터링에서만 사용될 필요가 있는 것은 아닌 것 같고, 여러가지 용도로 활용가능한 방법론인 듯 싶음

QFD

3) Surveys and interviews

고객의 요구를 이끌어내기 위해서 그리고 편향되지 않은 결과를 얻어내기 위해서는 질문이 중요하다. 특정 속성에 대한 질문이 의도적으로 많아서 그 질문만 하여 답을 얻어내게 되면, 그 자료로부터의 해석이 마치 그 속성이 강조된 것으로 오해될 수 있다. (고객은 유도당한 꼴이 됨)

이런 문제를 해결하기 위해서는 관련 참조 문헌을 통해 균형적 시각을 유지해야 할 필요가 있다. 아직 읽어보진 않았지만, 고객의 요구사항을 도출하기 위해서 읽어두면 좋을 내용이라고 생각한다. (추후 읽어보고 요구사항 분석과정을 위한 권장도서 목록에 포함할지의 여부를 결정할 것임)

일부 가이드라인(from HP group)

  • survey의 목적, 어떤 질문을 답해야 하는지, 어떻게 데이터를 분석할 것인지, 어떻게 결과를 표현할 것인지를 정의한다. 샘플 결론을 명시하거나 그래프로 표현한다.
  • survey를 배포하여 설문을 하기 전에 survey를 테스트하고 데이터 분석 방법을 적용한다.
  • 정량적이거나 y/n로 응답받을 수 있는 질문을 한다.
  • 설문지는 짧게
  • 부가적인 material을 주어서 섞이지 않도록 한다.
  • 회수하기 쉬운 형태가 되도록 한다.

참고문헌

Asking question: A practical guide to questionnaire design

QFD가 궁금하다면?