CMM Level 5

Best Practices

Handysoft

2005. 11.30

황순삼 실장 (Sam Hwang)

목차

1 HandySoft CMM Level 5 달성 사례

3 프로세스 개선의 제언

2 S/W제품 개발 단계별 Best Practices

HandySoft CMM Level 5 달성 사례

• 핸디소프트 SPI 추진 목적

• 핸디소프트 SPI 추진 방안

• 핸디소프트 정량적 품질 관리 체계

• 핸디소프트 품질경영 추진 내역

• 핸디소프트 CMM 추진 내역 1 (개선 인프라 정비)

• 핸디소프트 CMM 추진 내역 2 (개선체계 적용 및 심사)

• CMM 심사 일정 및 활동 내역

• CMM 심사 결과

• Global Strengths

핸디소프트 SPI 추진 목적

지속적인 프로세스 개선 (Optimizing)

정량적인 품질 관리(SQM)

개발업무의 생산성 향상

정량적인 프로세스 관리(QPM)

제품 개발 주기 단축

제품의 혁신적 품질 향상

조직역량 강화

고객 만족 향상

대외 경쟁력 강화

핸디소프트 SPI 추진 방안

Pilot 대상 선정 및 수행 정량적 관리 체계

• Business Goals

• Quality Goals

• QPM & SQM 관련 Process Asset

- Processes

- Procedures

- Templates

- Measurement Program

• PCB

• Quality Goal이 합리적인지?

• 정해진 측정 항목이 Business와 Quality의

충족 여부를 확인하기에 충분한지?

• 설정된 PCB가 합리적인지?

• 프로세스 및 관련 절차/양식에 대한 변경이

필요한지?

• 그 외 Lessons Learned는 무엇인지?

Pilot 결과 분석

SPIM 보완을 통한

정량적 관리체계의 시스템화

보완

핸디소프트 정량적 품질 관리 체계

200108011P진행 200111012P진행 200302031P진행 200305061P진행 200110037P진행 20020101OP진행 200302102P진행

마사회 자원관리시스템구축 관세청삼아알미늄 통합정

보시스템구축NHN BPM 구축 NINE2 HAWAII Jupiter-Europa

서비스프로젝트 서비스프로젝트 제품개발프로젝트 제품개발프로젝트 제품개발프로젝트

선택하지 않음 선택하지 않음 선택하지 않음

Contingency for Growth(%)

Contingency for N&C(%)

요구사항 개수 33 36 27 36 86 83 60

설계문서 Page수 62 80 72 103 172 153 112

단위테스트케이스수

통합테스트케이스수 50 100 55 45 140 199 92

시스템테스트케이스수 18 40 22 33 25 34 45

사용자테스트케이스수 9 25 30 21 - - -

사용자 문서 페이지수 131 150 200 106 231 130 150

분석 8.00% 10.00% 7.00% 9.00% 8.00% 7.00% 10.00%

설계 20.00% 17.00% 18.00% 20.00% 17.00% 14.00% 16.00%

개발 25.00% 23.00% 25.00% 22.00% 30.00% 28.00% 29.00%

단위테스트 30.00% 25.00% 26.00% 27.00% 25.00% 26.00% 17.00%

통합테스트 10.00% 12.00% 12.00% 13.00% 15.00% 16.00% 18.00%

시스템테스트 5.00% 7.00% 8.00% 6.00% 5.00% 9.00% 10.00%

사용자테스트 2.00% 6.00% 4.00% 3.00% 0.00% 0.00% 0.00%

Release Product Testing Coding Design Analysis

Inspection

Process DB

초기 견적시

활용

설계 단계 진척율 추적

14%

33%

56%

83%

100%

17%

37%

62%

83%

100%

0%

20%

40%

60%

80%

100%

120%

03/5/6 03/5/13 03/5/20 03/5/27 03/6/3

1주 2주 3주 4주 5주

계획진척율 실적진척율

견적대비 Size, Cost,

Effort 등 추적

계획대비 진행

상태 추적

데이터에 의한

원인 분석

필요 시

시정조치

활동 수행

결함 분석/추적

PCB

설정 품질목표

설정

시정조치

활동 수행

정기적인

상태 보고서

핸디소프트 품질경영 추진 내역

2006년 05월 : ISO 9001:2000 2차 갱신

2005년 07월 : CMM Level 5 달성

2004년 05월 : 신품질포럼 신품질혁신상 수상

2003년 10월 : ISO 9001:2000 전환 갱신

2002년 06월 : CMM Level 3 달성

2001년 02월 : CMM Level 2 달성

2000년 09월 : ISO 9001 인증 획득

2000년 01월 : 품질경영실 설립

핸디소프트 CMM 추진 내역 1 (개선 인프라 정비)

CMM

L3

심사

2002.06 2002.08 2002.10 2002.11 2003. 01 2001.02

CMM

L2

심사

Level 3

개선

• L3 개선 및 향후

SPI 계획 수립

• 프로세스 보완

• 표준 보완

• 교육

• 프로젝트 적용

확산

Business Goal

정의

비즈니스 목표

정의

품질 목표

정의

프로세스 기준

설정(PCB)

데이터 수집/분석

체계 정의

• Measurement

Program

-수집 데이터

-수집 주기

-분석 방법

• 관련 Process

Assets 개발

• 관련 시스템 보완

Measurement Framework 정의

Process

DB

재정의

핸디소프트 CMM 추진 내역 2 (개선체계 적용 및 심사)

프로젝트

시범 적용

1차 정량적

관리 체계

보완 및 확산

Gap 분석 2차 정량적

관리 체계

보완 및 확산

CMM

L4&5 심사 계획/

공식심사

2003.02 2003.09 2004. 08 2004.09 2004.10

주

요

활

동

• 대상 프로젝트

선정

• 인원 교육

• 프로젝트

시범 적용

• 자동화 도구 적용

(분석/설계, 테스팅)

• 시범 적용 결과

분석

• 정량적 관리 체계

보완

• Process DB 및

Library 보완과

재구축

• 표준 모델 재정립

및 확산

• CMM 목표 대비

Gap 분석 실시

• Gap 결과 검토

• Gap 분석 결과

보고 및 공유

• 개선 계획 (action

plan)수립

• 정량적 관리 체계

보완

• 사내 교육 계획

수립 및 교육 실시

• 개선 계획 및

정량적 관리 체계

보완

• 지속적인 개선활동

실시 및 보완

• CMM L4 & L5 예비

심사

• CMM L4 & L5 본

심사

2005.07

CMM 심사 일정 및 활동 내역

2005.07.26 2005.07.11

1.

Opening Meeting

수행

2.

프로젝트 리더

인터뷰

2.

중간 관리자

인터뷰

2.

기능별 대표자

인터뷰

3.

통합정리

3.

통합정리

3.

통합정리

4.

심사 결과

초안 준비

5.

심사 결과

초안 발표

6.

통합정리,

등급결정,

최종 보고 준비

7.

심사 결과

최종 보고

9.

심사 정리

8.

경영진 세션

병행 활동 :

문서 검토 수행

추가 인터뷰 수행

CMM 심사 대상 프로젝트 : 4개 (제품 개발 2개, 외부 서비스 프로젝트 2개)

예비 심사 일정 : 2005.05.16 ~ 2005.07.01

심사 투입 시간 : 1,116시간

심사 팀: 11명 (librarian 포함) x 92 시간 = 920 시간

인터뷰 대상자: 32 명 x 3 시간 = 96 시간

현장 심사 활동

CMM 심사 결과

Maturity Level 5

Defined KPAs Peer reviews

Intergroup coordination

Software product engineering

Integrated software management

Training program

Organization process definition

Organization process focus

Repeatable KPAs Software configuration management

Software quality assurance

Software subcontract management

Software project tracking & oversight

Software project planning

Requirements management

NA

Managed KPAs Software quality management

Quantitative process management

Managed KPAs Defect Prevention Technology Change Management Process Change Management

NA

fully satisfied

not satisfied

not applicable

not rated

X

Global Strengths

• HandySoft supports all processes of each KPA with policies, procedures, resources, training, measures and reviews.

• In all projects, formal reviews are conducted with customers and other related groups (e.g., consulting team, sales team, service project team) at the end of each phase to address project progress, risks, costs and issues.

• CEO and senior managers are focusing on continuous improvement activities, quantitative management of business goals and related process measures and motivating people.

• Almost all of the people think that they are involved in the improvement activities. Some of the improvement programs, such as SQR program, focuses on the restructuring of development processes and team structure, are proposed by the groups of developers.

S/W제품 개발 단계별 Best Practices

•Requirements Process

•CSR/Defect tracking

•착수 단계 Process

•프로젝트 관리

•HandySoft 개발방법론

•Inspection

•Test team

•종료 단계 Process

Requirements Process

Gather Input

Analyze Requests Update Roadmap

Product Release

Roadmap & Enhancement Input Mechanisms Monthly International Meeting Monthly North America Meeting Initiator provides Business Case:

Potential Revenue $ Potential Increased Market Share Potential Increased Customer Acquisition

Initiator provides Details: Customer Pain Benefits of Enhancement, etc.

Requirements Sources International

HSK, HSJ – Marketing & Sales HSK – R&D International Sales

North America HSU – Product Marketing & Solutions

Marketing HSU – Sales Engineering & Sales HSU – Services (Customer Support ,

Professional Services, Training) HSU – Engineering (Solution

Architecture, D&E, R&D, QA)

Customers & Partners

Variety of analysis before requests can be put on the Roadmap Product Marketing provides

NA competitive analysis, assessment of req. prioritization North American strategy docs for market & product direction

D&E provides international assessment of requirements prioritization strategy for product technical innovation, ensuring product quality,

stability and performance and localization, less costly support, and ability to OEM and partition product

Roadmap Production

D&E prioritizes requirements based upon above analysis

D&E designate a target on roadmap for completion for major enhancement requests

D&E produces internal and external roadmap

D&E establish a theme for each major release and assigns enhancements requests to a target release

Bi-Yearly Meeting with Executive Management to go over roadmap

Release Outline

D&E works with Product Marketing to establish a target date for the release

D&E works with Product Marketing, HSJ and HSK to establish ‘Top 10’ for the release

CSR/Defect tracking

고객

CSD system

Home page

Promise(RMT)

Promise(CSR) Promise(DMT)

SE,협력사 PDM/Tester/

Developer

“고객으로부터의 배움이 최대의 기술 개발” “유지보수 관리가 고객의 충성을 좌우한다” “고객의 불만과 요구는 끝까지 추적하고 관리한다”

착수 단계 Process

작성일 작성자

기타내역

기타내역

번호 등급 인원(m/m) 1월 2월 3월 4월 5월 6월 7월 8월 9월 10월

1 임원 4.8 7,398 7,398 7,398 7,398

2 수석 20.4 36,159 36,159 18,079 18,079

3 책임 85.1 111,749 108,869 67,971 67,971

4 주임 18.4 17,298 17,298 15,411 10,918

128.7 172,604 169,724 108,860 104,366

번호 구분 1월 2월 3월 4월 5월 6월 7월 8월 9월 10월

1

2

3

4

5

번호 구분 납품월

1

2

3

4

5

6

7

8

9

10

번호

1

2

3

4

5

6

7

8

9

10

172,604 169,724 108,860 104,366

소요 비용

도서인쇄비

소모품비

운반비

내 역

복리후생비

교육훈련비

수선비

잡급

지급임차료

4,493

7,090

여비교통비

상세내역

회사명/상품명

비고/특이사항

9,247

5,760

프로젝트일반정보

BizFlow 6.7 제품의 개발 및 업그레이드를 수행하는 내부 프로젝트 임

프로젝트 손익 프로젝트 이익율(%)

프로젝트손익정보

-761,983

상품 프로젝트 경비 프로젝트 금액 프로젝트 비용

자사 인력 761,983

프로젝트 코드

프로젝트명

외주 용역

프로젝트 개요

매출액 자사 제품

월 별 합 계

상품비용지출계획

경비 합계

소요 비용

프로젝트경비지출

상품

통신비

자사인력금액정보

외주용역지출계획

회사명

기준가격(원가)

외주용역

Initial Project Report

솔루션 타입(선택)

Risk 정보(선택)

프로젝트 수행 기간

PM 소속/성명

2004. 7. 1 ~ 2004.12.31

SES연구소 / 이승호 이사

2004.7.20

고객사명/고객번호 내부프로젝트

이승호

합계

계약번호

BizFlow 6.7 개발 및 업그레이드 개발 프로젝트EKP

High

착수 프로세스 • 프로젝트 PM이 프로젝트 계획서와 함께 IPR과 크기 평가표를 작성한다(연구본부의 제품 개발/유지보수 프로젝트도 예외 없음)

제품 개발 계획의 착수 1.PM이 릴리즈를 위한 Master Requirements document를 작성

개선 요구사항과 새로운 feature에 대한 요구사항을 grouping 주요 마케팅 또는 구조적 주제와 맞는 지를 분석 요구사항에 우선순위 부여 요구사항이 서브 릴리즈로 지정됨

2. PM이 Draft Project Plan을 수립 # of sub-release, how often we spiral, major milestones 등

3. PM과 D&E가 프로세스를 선택 및 조정(방법론/도구/환경의 조정) 4. PM이 Supported & Recommended Configurations를 수립

PM과 Software Architect가 supported versions 수립 PM이 릴리즈에 대한 recommend configurations을 선택

5. PM이 Architect 및 개발팀, PQM팀과 협력하여 필요한 공수 산정

new features versus bug fixes, % of work to be outsourced versus done in-house, experience level of the staff를 고려

크기 평가표를 통하여 산출물 크기 및 투입 공수 문서화 7. PM이 릴리즈에 대한 deliverables and goals을 수립하여 공표

PQM팀, 고개지원팀, 프로젝트 수행팀, 마케팅, 사업본부에 공지하고 피드백

Project Management

• Daily Tea Meeting

• 프로젝트 관리 시스템을 통한 진척 및 위험 관리 (진척관리는 MS-Project로 통일)

• 일별 Time card 작성 (단계별 활동 및 투입 공수 추적 관리)

• 주간 보고

– PM 및 본부장 관리 사항: 진척도, 위험, 이슈 관리

– 경영분석회의 : 주요 프로젝트의 위험 및 이슈 사항, 프로젝트 진척도, Inspection 현황, 계약 이슈 현황, 결함 보고 및 Promise 지연 현황

• 월간보고

– 연구본부 관리 사항: 릴리즈 시의 제품 결함밀도, 릴리즈 후의 결함 보고 추이, 프로젝트 공수 투입 현황(billable, non-billable 등을 몇가지로 구분), 프로젝트 비용 집행 현황(IPR 대비), 프로젝트 진척도 및 이슈, 사이즈, 주요 릴리즈 계획 변경

– 개발본부 관리사항: 제안 및 계약 현황, 프로젝트 진척도, Cost recovery 현황, 가동율 등

• 분기별 보고

– 분기별 종합 보고, 분기별 실행 계획

HandySoft Development Methodology

제품별 표준 개발방법론 Handy*MATE(Methodology Accompanied with

Technology Enhancement) Series

• Handy*MATE-PD: for package

development

• Handy*MATE-BPM: for BPM

development

• Handy*MATE-KD: for knowledge

mgt. System development

• Handy*MATE-GD: for groupware

system development

• Handy*MATE-Web: for web

application development

• Handy*MATE-PRAD: for package

rapid application development

Model Driven 개발 체계 구축 Sparx System사의 Enterprise Architect를

전사 표준 모델링 도구로 도입 (사이트 라이센스)

핸디 베이스 모델 구축

확립된 개발 절차에 기초하여 표준 모델을

모든 개발 공정에 적용함으로써 분석/설계

단계의 표준화 및 자산화

Inspection

• Inspection의 효율성 제고 노력 – 연구본부의 중점 추진 사항: 모든 제품에 대하여 인스펙션 효과성 목표 달성 평가

– 정량적 데이터의 수집.보고(preparation time, 결함 유형, Inspection 속도, 효과성 중심)

– 주간, 월별/분기별 보고(품질경영실이 경영분석회의에 보고)

– Promise시스템을 통한 인스펙션 활동 및 결함의 추적 관리

– Jtest (parasoft)도구를 통하여 코드 검토 및 단위 테스트의 자동화 (핸디에 맞는 custom rule를 작성하여 개발 코드에 대한 코드 검토 및 단위 테스트 실시) 인스펙션 투입시간의 획기적 감소 및 코드 품질 개선 )

< 10월 4 주차 연구본부 Inspection 현황>

인스펙션 누적 기간 : 2004.06.01 ~ 2004.10.22 (19 주 누계)

예외부서

- EDMS 제품: 현재 EDMS 개발 진행중인 프로젝트 없음

- GTEC 팀: 미국법인 지원으로 인스펙션 미 실시

- RPG, RTM 은 프로젝트 종료됨

- KM 개발팀은 프로젝트가 더 이상 없어 제외함.

특이사항

- GW 개발팀/컴포넌트개발팀/공통개발팀의 경우, 그룹단위로 제품을 개발하여 인스펙션

실적이 많음

- EAI개발팀의 경우, 10 월부터 인스펙션 활동을 실시하여 타부서에 비해 실적이 적음

- BPM개발팀은 경우, 인스펙션 실적과 결함 제거 활동이 매우 저조함

누적 부서명 제품

금주

실적 실적 발견결함 제거결함 결함제거율

GW 개발팀 GW 1 26 45 38 84%

메신저 0 9 18 12 67%

GW 0 11 13 7 54% 컴포넌트개발팀

합계 1 20 31 19 61%

GW 0 2 3 0 0%

RPG 0 17 35 15 43%

RTM 0 16 34 28 82% 공통개발팀

합계 0 35 72 43 60%

BIP 1 3 18 7 39%

BPM 0 1 3 3 100% EAI개발팀

합계 0 4 21 10 48%

BPM개발팀 BPM 0 4 27 0 0%

자료관사업부 자료관 1 11 54 47 87%

No ID 부서명 제품 버전 제목 월 회의일자 단계참가

자수

준비크

기검토크기

총준비

시간

검토

시간

결함

수

제거

수

재작업

시간

총준비

시간

(hr)

평균준

비시간

(hr)

검토시

간

(hr)

총시간 준비속도 검토속도 결함밀도

1 52512 공통개발팀 RPG RPG 1.0

[Groupware RPG1.0]modGlobal.bas 2004-06-01

6월 2004-06-01코드

검토3 508 508 120 180 3 2 20 2 0.67 3 11.01 758 169 0.59

2 52488 CM개발팀 EDMS EDMS 2.0[EDMS 2.0] 기능정의서 2004-06-01

6월 2004-06-01설계

검토5 6 6 60 60 4 4 1081 1 0.2 1 6 30 6 666.67

3 52529 공통개발팀 RTM RTM 1.1

[Groupware RTM1.1]SeviceProcDialog.cpp2004-06-03

6월 2004-06-03코드

검토3 1419 1419 80 120 4 4 45 1.33 0.44 2 7.32 3225 710 0.28

4 52371 GTEC팀 GTEC GTEC 1.0

[GTEC 1.0] Gracefulserver shutdownspec.doc 2004-06-03

6월 2004-06-03설계

검토6 3 3 30 30 2 2 0 0.5 0.08 0.5 3.48 38 6 66.67

5 52489 CM개발팀 EDMS EDMS 2.0[EDMS 2.0] 기능정의서 2004-06-07

6월 2004-06-07설계

검토5 60 60 60 60 3 3 1442 1 0.2 1 6 300 60 50

6 52513 공통개발팀 RPG RPG 1.0

[Groupware RPG1.0]frmOrganization.frm2004-06-08

6월 2004-06-08코드

검토3 357 357 90 80 3 0 180 1.5 0.5 1.33 5.49 714 268 0.84

7 52370 GTEC팀 GTEC GTEC 1.0

[GTEC 1.0] EasierPoint and Click -Visable/Enable ByConditi 2004-06-10

6월 2004-06-10설계

검토6 1 1 30 40 6 6 0 0.5 0.08 0.67 4.5 13 1 4020

8 52531 공통개발팀 RTM RTM 1.1

[Groupware RTM1.1]GetServiceResult.cpp2004-06-11

6월 2004-06-11코드

검토3 431 431 180 80 4 4 270 3 1 1.33 6.99 431 324 0.93

9 52443 CM개발팀 자료관 Arcieve 2.0

[Archive 2.0] 개발 소스 ( 즐겨찾기,반출)2004-06-11

6월 2004-06-11코드

검토8 1860 1860 60 2 9 9 1820 1 0.13 0.03 1.28 14308 62000 0.48

10 52533 공통개발팀 RTM RTM 1.1

[Groupware RTM1.1]MonitoringInformationBase.java 2004-06-16

6월 2004-06-16코드

검토3 728 728 120 60 1 1 30 2 0.67 1 5.01 1087 728 0.14

11 52490 CM개발팀 EDMS EDMS 2.0[EDMS 2.0] 버그리스트 2004-06-16

6월 2004-06-16코드

검토4 4 4 60 60 20 3 156 1 0.25 1 5 16 4 500

12 52514 공통개발팀 RPG RPG 1.0

[Groupware RPG1.0]frmChangeTNS.frm2004-06-17

6월 2004-06-17코드

검토3 495 495 90 50 2 2 100 1.5 0.5 0.83 3.99 990 596 0.4

13 52369 GTEC팀 GTEC GTEC 1.0

[GTEC 1.0] TriggerDatabase/WebServiceaction without scripti2004-06-17

6월 2004-06-17설계

검토6 1 1 30 40 3 3 0 0.5 0.08 0.67 4.5 13 1 2010

14 52689 GW개발팀 GW GW 6.5

[Groupware 6.5]EdmsTool.javaInvalidArgumentExce2004-06-18

6월 2004-06-18코드

검토7 2000 800 60 120 1 1 120 1 0.14 2 14.98 14286 400 0.13

15 51641 KM개발팀 KMS KMS 5.0[KMS 5.0] PLATINUMUI설계서 2004-06-18

6월 2004-06-18설계

검토5 20 20 10 70 5 2 16 0.17 0.03 1.17 6 667 17 292.5

16 51694 KM개발팀 KMS KMS 5.0[KMS 5.0] 변환된 JSP페이지 2004-06-21

6월 2004-06-21코드

검토5 245 245 10 80 6 6 36 0.17 0.03 1.33 6.8 8167 184 2.45

17 52119 GTEC팀 GTEC GTEC 1.0

[GTEC 1.0] APIDescription.xls 2004-06-23

6월 2004-06-23설계

검토6 1 1 30 40 2 2 0 0.5 0.08 0.67 4.5 13 1 200

Test team

Unit Test • Logic Test

• Data structure

Test

• UI Test

• Boundary Test

Integration Test • By using Test Case

• Regression Test System Test • Stress Test

• Performance Test Env. Test • for various Env. Installation Test • New installation Test

• Upgrade Test

•Member: PDM,

Head of test team,

Tester representatives,

PM,…

Test Review • Review of test

result

• Decision of

release

Tester Release Review Committee

Developer

종료 단계 Process

종료 프로세스 •프로젝트 PM은 최종 산출물을 등록한다. •프로젝트 PM은 유지보수 인수인계서를 작성하여 고객지원팀에게 전달한다.

•프로젝트 종료 승인서를 작성하여 품질경영실에게 전달한다.

•프로젝트 PM은 프로젝트 종료 보고를 수행한다. • PM의 소속 팀장은 프로젝트 종료를 승인한다. •품질경영실과 경영기획팀이 프로젝트 종료에 대한 검토를 수행한다.

•소속 본부장이 프로젝트 종료를 승인한다. •프로젝트에 대한 종료 평가가 수행된다. •프로젝트 고객만족도 설문조사를 수행한다. •우수한 프로젝트를 성공사례로 등록한다. •프로젝트를 종료 처리한다.

Customer Satisfaction Survey Overview

for major service project by QA manager & CS Team • Interim survey(after design phase) • Final survey (after completion of project)

Method of survey Using questionnaire from representative end users

and operators Survey of satisfaction of 4 phases

• Sales, Analysis/Design, Development, Operation

Evaluation items 10 items for each phase(7 Scale)

Corrective action Corrective action taken by PM(for below average

satisfaction) Root causes of dissatisfaction analyzed and reflected

to OSSP Summary of CSS and corrective actions taken

reported to monthly management meeting

프로세스 개선의 제언

• 중소 S/W업체에서의 품질 개선 문제점

• Practices of 소규모 조직. vs. 대규모 조직

• 과도한 문서화 노력을 줄이는 방법

• 개선 - 조직 문화의 구축

• 측정 지표의 단순화 및 사업목표와의 정렬

중소 S/W업체에서의 품질 개선 문제점

• 중소 S/W업체의 주요 사업목표: Survive !

–품질 개선 및 프로세스 개선에 있어서의 문제점

•현상태에 불만족, 품질개선과 프로세스 개선은 분명

도움이 될텐데…

•필요한 자원과 역할의 할당이 어려움

–개선에 소요되는 비용과 자원을 감당할 수 있느냐?

–일부분만 한다면 무엇부터 해야 하느냐?

• 중소 S/W업체의 문화

–우리는 모두 해당 업무에 적격이다

–우리는 의사소통 하는데 문제가 없다

–우리는 모두 영웅이다

•필요한 것은 모두 우리가 한다, 규칙은 필요 없다,

단기간의 cycle time과 stress는 당연하다

• 품질개선 문제점

–테스트 및 평가 – 출시 시점에 임박한 개발 완료, 테스트 부족,

재작업 시간 부족

–요구사항의 관리 – 문서화?

–프로젝트 관리 – 관리 경험?

–자원의 할당 – 우리는 작다 !

–교육.훈련의 제공 – 우리 직원 모두는 적격이다

–검토 수행 – 누가 자격이 있고 가용한가?

–문서의 생성 – 시간이 있으면…

–진척도의 측정 – 제일 모르는…

프로세스 개선의 필요성이 의심되는가?

비용 대비 효과가 의심되는가?

요구사항관리가 과도한 요구사항을

제거한다면 불필요한 작업이라고 할

수 있는가?

동료검토가 재작업을 50% 정도

줄인다면 불필요한 작업이라고 할 수

있는가?

프로세스 개선은 프로세스를 추가하는

것이 아님

현재 일어나고 있는 모든 것은 하나

또는 그 이상의 프로세스와 관련이

있음

중소 규모 조직에서는 프로세스

개선은 사업에 초점을

맞추고(business-focus) 적고(less)

더좋은(better) 프로세스를 요구함

Practices of 소규모 조직. vs. 대규모 조직

소규모 조직은 대규모 조직의 practice를 사용할

수는 없음.

– Johnson and Brodman

• 소규모 기업/조직/프로젝트(SB/SO/SP)에

적용하기 위해서는 조정 필요: CMM 실무 절차의

82%가 변경

• 주요 변경이 일어나야 하는 분야는 문서화

(documentation), 관리 (management), 검토

(review), 자원 (resources), 훈련 (training),

관련이 없는 실무 절차 (unrelated practices) 등

– Humphrey

• 핵심 실무 절차를 생략하는 것이 아니라 작업

산출물의 상세도와 핵심 실무 절차의 수행의

엄밀성을 조정

– 항상 필요한 사항

• 문서화된 고객(시스템) 요구사항

• 고객(또는 최종사용자)와의 의사소통

• 합의된 commitment

• 문서화된 절차

• WBS(Work Breakdown Structure)

상황에 따라 다를 수 있는 practices

대규모 조직에 유용한 practices • 형상관리그룹 및 변경통제위원회

– 소규모 조직에서도 형상관리는 필요

• 독립적인 품질보증 그룹 – 소규모 조직에서도 객관적인 검증은 필요

• (독립적인) 테스트 그룹 – 소규모 조직에서도 테스트는 필요

대부분 조직구조와 관련된 구현상의 문제임

소규모 조직에 조정되어야 할 사항(예)

계획시의 과거 데이터 사용: 작은 노력은 과거 데이터 없이 산정

교육.훈련 • 외부교육 위주

• 내부 프로세스에 대한 훈련은 소규모

조직에서도 중요함

위험관리 • 프로젝트의 사소한 위험의 관리

과도한 노력을 줄이는 방법

• 기반구조: 없으면 체계적인 진행이 안됨 –개선을 주도하는 그룹 필요(Management Steering Committee, SEPG그룹, PIT(Process Improvement Team)

•소규모 조직에서는 SEPG(S/W Engineering Process Group)를 part-time 참여자로 할 수 있음

–경영층의 동의, 감시, 지휘, 강화가 필요함

• 프로세스 개선 초점 –프로세스 정의

•없는 것을 개선할 수는 없기 때문에 있어야 하나, 프로세스 문서는 간결하게 유지

–기본적인 프로세스 정의는 생략할 수 없음

–초기의 정의된 프로세스는 goal당 최대 2 페이지 이내로 제한

–프로세스 정의 시에 1주에 최대 2~3개의 작업들을 정리

–텍스트 뿐 아니라 그래픽도 사용

»EVTX, IDEF0, Information Mapping

–템플리트 및 Checklist 형태로 !!!

–프로세스 자산 라이브러리 및 Process Owner 식별 필요

검증(verification) 다양한 검토 기법을 적용(워크쓰루우,

인스펙션, 기술검토 등) 특히 동료검토는 가장 효과를 보는 방법임

• 모든 것을 검토할 필요는 없고, 매우 효과적이어야 함

교육.훈련 여러가지 형태: 내부에서 개발된 교육 외부

교육, OJT, Guided self-study 등

프로젝트 계획 비슷한 프로젝트에 쉽게 재사용됨 초기 프로젝트 계획은 10페이지 이내로

제한. 관련 지원 문서를 포함하여 작성하는데 8시간 이내 소요

위험 관리 효과적인 위험관리 프로세스는 핵심 사업

목적에 초점을 둠

측정 및 분석 신속 개발, 다양한 프로젝트 들에서는

메트릭은 부적절하나, 어떤 수준의 산정 및 예측은 여전히 필수적임(Business Driver에 맞게)

개선 - 조직 문화의 구축

조직 문화

“바로 우리가 하려고 하는 것이야…”

조직 문화

“바로 우리가 하려고 하는 것이야…”

외부 요구사항 내부 요인 내재화(Institutionalization)

고객 요구사항

경쟁사업 전략기술 변화

스폰서Change agents

리더쉽역량기술능력

방침표준절차지침훈련감시검토감사

WHYWHAT

HOWPerformance

Time

초기 상태

프로세스 개선 시작

학습곡선

포기해서는 안된다

개선된 상태

“절망의 계곡을 두려워 말라”

Q & A

• 감사합니다.