cmm level 5 달성 전략및노하우품질보증(품질측정거의없음) 품질측정,...

Software Insight 2005

CMM level 5 달성

전략 및 노하우

CMM level 5 달성

전략 및 노하우

안유환 Ph.D.

상무/연구개발본부장

㈜핸디소프트12. 2. 2005.

CMM level 5 달성 전략


목 차목 차

1. 소프트웨어 프로세스 개선의 필요성

2. CMM의 주요 요구사항

3. 프로세스 개선 추진 전략

- 실패 원인

- 내재화

- Infrastructure

- Business Driver에 기반한 정량적 관리

4. 개발 단계별 주요 이슈 및 best practices

5. 프로세스 개선의 제언


S/W 프로세스 개선의 필요성S/W 프로세스 개선의 필요성

H/W 제조 vs. S/W 개발 프로세스소프트웨어 관리 원칙

소프트웨어 프로세스 개선의 Myths제품의 품질과 프로세스 능력

프로세스 개선 효과



H/W 제조 vs. S/W 개발 프로세스H/W 제조 vs. S/W 개발 프로세스

제조

원재료

최종 제품제품 설계공정 설계

요구사항

Process Control

제품/서비스

제품 설계(분석, 설계, 코딩, 시험)요구사항

품질보증(품질 측정 거의 없음)

품질 측정, 시제품 검증공정 설계/검증

제품 검사/시험, 불량품 폐기/재작업

복사,인도

H/W 제조 프로세스

S/W 제조 프로세스

H/W 제조 프로세스 : 설계와 구현은 서둘러 끝내고 테스트에서 고치는

방법으로 제품을 생산하는 것은 없음

최종 제품이 생산되기까지 많은 검사와 제조 프로세스의 통제를 통해 품질을

보증함.

프로세스의 최종 단계까지 문제점이 발견되지 않은 채 문제가 더욱 악화 되는것을 허용하지 않으며, 품질품질 측정을측정을 통해통해 결함이결함이 있는있는 제품이제품이 대량대량 생산되기생산되기 전에전에

결함이결함이 있는있는 프로세스는프로세스는 변경되어변경되어 짐짐.

초가집을 짓는 프로세스로는 빌딩을 세울 수 없음S/W의 중요성이 커지고 활용범위.규모가 증대하면서 이미 초가집이 아님!!!

철저하게 공정을 설계/검증하고, 공정을 준수하고, 공정의 결과물을 검증한 후에다음 공정으로…

http://imagebingo.naver.com/album/image_view.htm?user_id=bwj820425&board_no=27792&nid=4311



소프트웨어 관리 원칙소프트웨어 관리 원칙

품질이야 말로 가장 중요한 것임–Aston Tate사의 Dbase IV Boland사로 인수됨

•릴리즈 계획 1998.5 1988.10 (“출시해; 나중에 고쳐도 돼”)

–제품결함이 너무 많음. 1991년 2월에도베타테스트 중 CEO 교체, 인수됨

•Time to Market vs. 품질 : Quick and dirty는 비용을 더 많이 들게 함

–NASA의 “더 빠르게, 더 좋게, 더싸게”

•1999년 9월 화성기후관측 우주선 화성충돌 : 194 M$ 손실

–우주선의 두개 부품이 서로 다른 척도사용(미터와 야드)

•1999년 12월 화성극점 착륙선 화성 충돌–S/W가 잘못 읽어들인 가짜 신호로 엔진을너무 일찍 정지

• “더 좋게’는 무시한 채 “더 빠르게, 더싸게”에 집중

–“더 빠르게, 더 싸게”는 측정하는 방법을 잘알았지만, 아무도 “더 좋게”를 측정하는지표를 만들지 않음

연마(Disciplined)되고 의욕적인사람이 고품질의 소프트웨어를 개발

품질관리 방법을 훈련받지 못한관리자와 개발자는

•품질이 중요하다는 것을 믿지 않음

•고품질의 제품을 만드는데 필요한실천사항을 지키지 않음

품질은 우연히 얻어지는 것이 아님

•측정하지 않으면 관리할 수 없고 관리하지않으면 개선되지 않음

•현대의 기술 중 설계와 구현은 서둘러끝내고 테스트에서 고치는 방법으로제품을 생산하는 것은 없음 – 반도체, 건축

소프트웨어 엔지니어는 왜 품질에집중하지 않는 것일까?

•그렇게 훈련하고 관리하였기 때문임–“가장 존경받는 프로그래머는 번개처럼 빨리코드를 작성하는 사람이다”

–“Fix-it-later”

자료원: 소프트웨어로승부하자(최종섭외공역)Winning with Software: An executive Strategy(Watts S. Humphrey)



소프트웨어 프로세스 개선의 Myths (1)소프트웨어 프로세스 개선의 Myths (1)

제품만 좋으면 돼!– 나머지는 좋은 제품으로 다 해결돼! 프로세스 개선은 다음에…

– 프로세스가 나빠도 좋은 인력만있으면 좋은 제품의 개발이 가능해!

– 제품만 좋으면 marketing, sales, profit 문제는 다 해결돼!

– 조기 출시를 통한 시장 선점이최고야!

프로세스 개선의 효과가 적다!– 프로세스 개선을 한 조직이 그효과를 정량적으로 잘 설명하지못하던데…

– 생산성, 품질, 라이프사이클에미치는 영향을 잘 못느끼는데…

프로세스 개선을 할 여력이 없다!– 우리의 목표는 생존(Survive)이야!

– 내년부터 여력이 되면 하자!

고객의 선택기준은 제품 개발 및유지보수 능력임

– 좋은 프로세스가 좋은 제품을반복적으로 만들 수 있음

– 제품의 개발 lifecycle – 기획, 상품화, marketing/sales, 유지보수, 업그레이드

– 제품 개발과 관련된 이런 프로세스가좋지 않으면 경쟁력이 없음

S/W 프로세스 개선의 효과는 이미1990년대에 입증되었음

– 주변의 개선 조직이 정량적 효과를제시하지 못하는 것은 정량적 결과를충분히 축적한 수준으로 까지는개선되지 못했기 때문임

– 개선의 효과가 의문스러우면 절대시도하지 마라!

개선없이 Survive는 없다!!!- 생존을 위한 목표 달성(일정, 품질, 비용 목표)을 제대로 하고 있는가?

- 과도한 노력을 줄이면서 시작하는방법이 있다.

고객의 선택기준은 제품 개발 및유지보수 능력임

– 좋은 프로세스가 좋은 제품을반복적으로 만들 수 있음

– 제품의 개발 lifecycle – 기획, 상품화, marketing/sales, 유지보수, 업그레이드

– 제품 개발과 관련된 이런 프로세스가좋지 않으면 경쟁력이 없음

S/W 프로세스 개선의 효과는 이미1990년대에 입증되었음

– 주변의 개선 조직이 정량적 효과를제시하지 못하는 것은 정량적 결과를충분히 축적한 수준으로 까지는개선되지 못했기 때문임

– 개선의 효과가 의문스러우면 절대시도하지 마라!

개선없이 Survive는 없다!!!- 생존을 위한 목표 달성(일정, 품질, 비용 목표)을 제대로 하고 있는가?

- 과도한 노력을 줄이면서 시작하는방법이 있다.



소프트웨어 프로세스 개선의 Myths (2)소프트웨어 프로세스 개선의 Myths (2)

프로세스 개선을 하기 위한 방법을잘 모르겠다!

– 무엇을 어디서 부터 해야 할지…– 무엇이 가장 중요한지…

이거 새로운 개선 모델이잖아? 완전히 새로 해야되는구만…

– 이거 또 다른 개선 활동의시작이구먼… 그전에도 다른 개선활동을 적당히 하다가 별 효과가없이 중단 했는데…

– CMM이면 다 되는거지?

프로세스 개선을 위한 Roadmap을제공하는 개선 모델의 활용이 가능함

개선 모델과 비즈니스 목표의 조화에따른 지속적인 개선이 필요함

일반적인 roadmap을 활용하고Goal을 달성하기 위해 필요한practices를 이해하는 것이 중요함

개선 활동을 통한 개발 및 유지보수활동의내재화(Institutionalization)이중요함

프로세스 개선의 philosophy는 같음!

단지, 이를 달성하기 위한 방법, Roadmap 등이 틀림

기존의 개선활동은 대부분 그대로적용 가능함

CMM이 모든 문제를 다 해결하지는못함 – S/W 개발 및 유지보수에집중

프로세스 개선을 위한 Roadmap을제공하는 개선 모델의 활용이 가능함

개선 모델과 비즈니스 목표의 조화에따른 지속적인 개선이 필요함

일반적인 roadmap을 활용하고Goal을 달성하기 위해 필요한practices를 이해하는 것이 중요함

개선 활동을 통한 개발 및 유지보수활동의내재화(Institutionalization)이중요함

프로세스 개선의 philosophy는 같음!

단지, 이를 달성하기 위한 방법, Roadmap 등이 틀림

기존의 개선활동은 대부분 그대로적용 가능함

CMM이 모든 문제를 다 해결하지는못함 – S/W 개발 및 유지보수에집중



제품의 품질과 프로세스 능력제품의 품질과 프로세스 능력

좋은 프로세스가 필연적으로 좋은 제품을 공급한다는 것은아님

– 좋은 프로세스가 있다 하더라도 원하지 않는 제품 및 서비스를 공급할수 있음 사업 전략과 관련된 문제여서, 사업목표에 의거한 적절한제품 및 서비스를 선정했다면 효과적인 프로세스는 좋은 품질로 제품및 서비스를 공급할 수 있음

반대로, 좋은 프로세스가 없음에도 좋은 품질의 소프트웨어제품을 생산할 수 있을까?

– 상당한 기술과 경험을 가진 인력으로 구성된 소규모 개발팀에서는명확히 문서화되고 지켜져야 하는 프로세스가 없이도 좋은 제품의품질을 얻을 수 있음

– 나머지 대부분의 경우에는 잘 정의되지 않은 프로세스 환경 하에서는품질은 예측 불가능하고 걷잡을 수 없을 것임: 품질을 계획하거나관리할 수 없을 뿐만 아니라, 설사 좋은 품질을 얻었다 하더라도 그이유가 무엇인지, 다시 또 반복적으로 좋은 품질을 얻을 수 있을것인가에 대한 확신을 가지지 못함

Major Determinants of Software Cost, Schedule, and Quality Performance

PEOPLE

PROCESS

TECHNOLOGY

Maturity of Process Capability in CMMMaturity of Process Capability in CMM

Initial

Repeatable

Defined

Process is informal and unpredictableProcess is informal and unpredictable

Project management system is in place; performance is repeatable

Project management system is in place; performance is repeatable

Software engineering and organizational processes are defined and integrated

Product and process are quantitatively controlledProduct and process are quantitatively controlled

Time/$/...

Time/$/...

Time/$/...

Optimizing Process improvement is institutionalizedProcess improvement is institutionalized

Time/$/...

Time/$/...

Level Process Characteristics Predicted Performance

Managed

1 1

2

3

4

5 능력(Process Capability)

• 프로세스가 요구되는 목표(goal)을 달성하는능력 [ISO/IEC 15504-9]

• 소프트웨어 프로세스를 따름으로서 성취할 수있는 가능한 예상결과의 폭(range of expected results) [CMM v.1.1]

• 비용, 일정, 납기, 고객 만족, 생산성등의 여러 목표를 달성하는 확률로 쉽게이해할 수 있음



프로세스 개선 효과프로세스 개선 효과

• 미국내 정보산업 관련 13개 대표적 업체 대상 조사평가 영 역 범 위 M ed ian

연 간 생 산 성 이 득 9 ~ 6 7% 3 5%

연 간 시 장 출 시 시 간 감 소 율 15~ 23% 1 9%

연 간 출 시 후 결 합 발 견 보 고 감 소 율 10~ 94% 3 9%

사 업 가 치 (S av in g /S P I 비 용 ) 4 .0~ 8 .8 : 1 5 .0 : 1

(1994 Herbsleb)• 사례: 보잉사

0

5

10

15

20

25

시간.결

함

테스

팅

+ 인

스펙

션

+ 검

토

결함제거 전략에 따른 시간 및 잔존 결함(for 100KLOC)

시간(*1000) 결함(*100)

품질우선 전략으로 시간과 돈을절약할 수 있다!!!

정성적 효과: 조직 문화의 변화

사용자와 개발자가 한 팀으로 일함

팀간(프로젝트간) 협력 증대

역할과 책임의 명확화

인력 변동시 최소한의 영향

직원들이 품질경영에 의한 새로운 일의방식을 이해하고 감사함

고참/신입 사원 간의 mentoring 증가

“매우 재미 있습니다”

정성적 효과: 조직 문화의 변화

사용자와 개발자가 한 팀으로 일함

팀간(프로젝트간) 협력 증대

역할과 책임의 명확화

인력 변동시 최소한의 영향

직원들이 품질경영에 의한 새로운 일의방식을 이해하고 감사함

고참/신입 사원 간의 mentoring 증가

“매우 재미 있습니다”

결함의 90%가 릴리즈 전에 수정됨

94%의 프로젝트가 일정 산정치를 만족시킴

소프트웨어 재사용율이 64% 증가함

테스트 시간은 94% 줄어듬

생산성은 70% 증가함(CMM 3 level 이상조직에서)

고객만족은 12% 증가함(CMM 3 level 이상조직에서)

직원 만족은 20% 증가함(CMM 3 level 이상조직에서)

결함의 90%가 릴리즈 전에 수정됨

94%의 프로젝트가 일정 산정치를 만족시킴

소프트웨어 재사용율이 64% 증가함

테스트 시간은 94% 줄어듬

생산성은 70% 증가함(CMM 3 level 이상조직에서)

고객만족은 12% 증가함(CMM 3 level 이상조직에서)

직원 만족은 20% 증가함(CMM 3 level 이상조직에서)


CMM의 주요 요구사항CMM의 주요 요구사항

Management View of Maturity Level in CMMKPA(Key Process Area) of CMM

Multiple Views of CMM



Management View of Maturity Level in CMMManagement View of Maturity Level in CMMMgmt View of Maturity Level

In OutLevel 5

In OutLevel 4

In OutLevel 3

In OutLevel 2

Level 1OutIn



KPA(Key Process Area) of CMMKPA(Key Process Area) of CMM

Initial

Software Configuration ManagementSoftware Quality AssuranceSoftware Subcontract ManagementSoftware Project Tracking & OversightSoftware Project PlanningRequirements Management

Peer ReviewsIntergroup CoordinationSoftware Product EngineeringIntegrated Software ManagementTraining ProgramOrganization Process DefinitionOrganization Process Focus

Software Quality ManagementQuantitative Process Management

Process Change ManagementTechnology Change ManagementDefect Prevention

4

5

1

2

Managed

Defined

Repeatable

Optimizing

3

Plan vs. ActualPlan

Org. Std. Process Defined process

LCL

UCL

Quantitative Control

LCL

UCL

LCL

UCL

Common Causes Control



Multiple Views of CMMMultiple Views of CMM

Level 프로젝트 관리 측정

Optimizing정량적인 분석에 의한 개선안 제안, 결함 관리

지속적인 개선이 사업 목표 및 비용-효과 분석에 기반하여 이루어짐

통계적 프로세스 관리(SPC) 원칙에위해 데이터가 분석됨. 실제 측정치가평균 및 분산치(Control Limit)에비교됨

조직 전체의 모든 프로젝트에 대하여일관된 정의 존재관리 및 품질에 관한 데이터가전사적으로 수집됨

프로젝트에서 크기, 공수/비용, 일정, 위험, 컴퓨터 자원 등에 대한 관리데이터를 수집프로젝트 마다 다른 정의를 사용할 수있음

측정에 계획성 없음(비용과 공수 데이터생성은 가능할 수 있음)

Managed

조직의 PCB(Process Capability Baseline) 설정, 프로젝트 프로세스의정량적 통제(Control Limit 설정 및통제), 통계적 프로세스 관리

Defined

S/W공학 활동(개발 활동/작업)이 관리활동과 통합Threshold(조직 방침에 의한 편차범위)에 의한 관리, Critical Path 관리

Repeatable

산정(크기, 공수/비용, 일정, 위험, 컴퓨터 자원) 및 계획Estimate에 비교한 Actuals 측정, Deviation 발생시시정조치(Deviation 기준 없음)

InitialNot visiblePM의 능력에 의존(산정, 계획, 추적 및감시 체계가 프로젝트마다 틀림)


프로세스 개선 추진 전략프로세스 개선 추진 전략

프로세스 개선의 실패 원인개선 – 내재화, 조직 문화의 구축

내재화 요건 in SW-CMM 조직적 Infrastructure소프트웨어 프로세스 자산

주요 이행 능력여러분의 생각은?

정량적 관리 : Concept of process managementBusiness Driver에 기반한 목표 설정 및 성과 관리



프로세스 개선의 실패 원인프로세스 개선의 실패 원인

Business Driver

개선의 필요성을 절감하지 못함 -no business driver명확한 품질목표 부재

품질개선을 측정, 보상하기 위한성과관리 시스템 부재

선도기업이 하니까…뭔가 나아지겠지…하다못해 marketing needs라도있어야 함

Sponsorship단기적 commitment

비현실적인 기대치

‘silver bullet’이라는 믿음

Culture현상태에 대한 평가 절하

Culture를 바꾸는 것을 사소한 것으로생각함

‘토론이 불가능하다’는 가정

TransitionTransition 계획 부족: ‘계획보다는 hope’Transition의 관리 부족

단기적 결과의 기대

새로운 행위와 보상의 연결 부족

Resistance to change저항의 인식 부족

듣고 싶지 않은 피드백의 무시/거절

변화해야 할 사람의 참여 부재

적절한 업무 부하 고려 부족

안정적이고 명확한 업무 환경

Change Agent조직과 무관해짐

개인적으로 방해/역류함

Smart하기 보다는 열심히 일함

공격적이고 낙관적인 일정의 약속



개선 – 내재화, 조직 문화의 구축개선 – 내재화, 조직 문화의 구축

조직문화

“바로 우리가하려고하는것이야…”조직문화

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

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

고객요구사항경쟁사업전략기술변화

스폰서Change agents리더쉽역량기술능력

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

WHYWHAT

HOWPerformance

Time

초기상태

프로세스개선시작

학습곡선

포기해서는안된다

개선된상태

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



내재화 요건 in SW-CMM 내재화 요건 in SW-CMM

Commitment to Perform Ability to Perform

Measurement & Analysis Verifying Implementation

written organizational policyLeadership: Designated Personnel for responsibilities

Documentation: Policy(Org. level), Process(Org. + Project), Procedure(project)Responsibilities AssignedAdequate Resources and FundingTraining문서화(방침, 절차), 지침담당자 선임 및 업무의 정의자원 및 비용의 할당담당자 교육

Measurements are made and used to determine the status

각 활동의 측정 및활용(측정한 측정치와 이를활용한 증거)

Reviewed with senior managementReviewed with project managerQA reviews and audits

상위경영자 보고/검토PM 보고/검토QA담당자 검토 및 시정조치 추적

품질방침, 품질절차서, 개발절차서, 부서별 업무지침

Institution-alization



조직적 Infrastructure조직적 Infrastructure

최고경영층의 지원운영위원회(Steering Committee): 개선 전략의 검토, 전체 개선활동의 감시 및 보고소프트웨어 프로세스 공학 그룹(SEPG): SEPG는 엔지니어 역할 보다는 조정의 역할을하는 전담 전문가로 구성되어 개선실무추진팀(PIT: Process Improvement Team)의활동을 조정.

– 프로세스 표준 설정, 프로세스 DB 유지, 기술 도입의 중심 역할, 주요 프로세스 교육제공, 프로젝트 자문 제공, 주기적 심사 및 상태보고

개선실무추진팀(PIT): 전술적, 기술적 관점에서 현행 프로세스를 문서화, 분석, 재설계하고, 프로세스의 수행을 추적,평가하며, 프로세스를 지원하기 위한 새로운 방법과 기술과 도구를도입하는 실무팀프로젝트(팀): 새로운 프로세스 및 기술을 시범 적용하고 그 프로세스의 효율성을 피드백

최고경영층Sponsor

최고경영층Sponsor

SEPGSEPG

S/WPIT#4

S/WPIT#4

SteeringCommittee

SteeringCommittee

S/WPIT#1

S/WPIT#1

S/WPIT#2

S/WPIT#2

S/WPIT#3

S/WPIT#3

Project#4

Project#4

Project#4

Project#4

Project#4

Project#4

Project#4

Project#4

신기술, 절차, 지침, 경험 지식개선에대한피드백

교육조정

프로세스자산액세스

자원전략감독 피드백

피드백피드백



SPI OrganizationsSPI Organizations

CEOMgt. Steering Committee

(MSC)

SEPG Sub-team

Technical Working Group

(TWG)

QM/QA Sub-team

MISSub-Team

Mgr. of Service Center

팀장/그룹장팀장/그룹장Mgr. of

team/group QA & TestTeam

QA officer Prod. Mgr.

QM Dept.

Product Mgt. Team

Test sub-teamSupport

Mgr.

Planning Mgr.

QA Manager

Group

Mgr. of R&D Center

Project Manager

DevelopmentTeam Mgr.

Sub-teamLeader: PL

Sub-teamLeader: PL

Mgr. of QM Dept.

QA officer



SEPG 개요SEPG 개요

Definition of SEPG(Software Engineering Process Group)– A group of specialists who facilitate the definition,

maintenance, and improvement of the software process

used by the organization– Generically referred to as “The group responsible for the organization’s software process activities”

Role of SEPG– 프로세스 표준의 설정

– 프로세스 DB의 유지

– 기술 도입의 중심 역할

– 주요 프로세스 교육 제공

– 프로젝트 자문 제공

– 주기적 심사 및 상태보고

Involved people– Software professionals

– 상위 경영자, 프로젝트 관리자, SQA담당자, 교육/재무/관리 담당자 등

– 소프트웨어 관련자 들의 1~3%에 해당하는 전담요원(full time) 필요• 보통 2%, 소규모 조직이라도 최소 1명(불가능할 경우 위원회 및 특별 작업그룹의

지원을 받는 매니저)



소프트웨어 프로세스 자산소프트웨어 프로세스 자산

조직표준S/W 프로세스

조직표준S/W 프로세스

조직S/W

프로세스Database

조직S/W

프로세스Database

S/W프로세스관련 문서라이브러리

S/W프로세스관련 문서라이브러리

S/W 프로세스생명주기

Description

S/W 프로세스생명주기

Description

조직 S/W프로세스의

조정지침/기준

조직 S/W프로세스의

조정지침/기준

조직 표준S/W 프로세스Description-프로세스 구조-프로세스 요소

조직 표준S/W 프로세스Description-프로세스 구조-프로세스 요소

외부요구사항

외부요구사항

시스템요구사항

시스템요구사항

S/W에할당된시스템요구사항

S/W에할당된시스템요구사항

프로젝트에적용할생명주기선정

프로젝트에적용할생명주기선정

프로젝트에서 정의된

S/W프로세스의

개발

프로젝트에서 정의된

S/W프로세스의

개발

프로젝트프로세스

Description-생명주기-프로젝트프로세스

프로젝트프로세스

Description-생명주기-프로젝트프로세스

프로젝트의S/W 개발 계획

프로젝트의S/W 개발 계획

프로젝트활동

프로젝트활동

프로젝트 결과및 작업산출물

프로젝트 결과및 작업산출물

조직 수준

프로젝트 수준



주요 이행 능력(Ability to Perform) 주요 이행 능력(Ability to Perform)

Level 프로세스 영역 주요Infra 역할 및 책임 교육

RM RM 변경통제 및 요구사항 관리시스템과 프로세스

변경통제위원회(CCB) 요구사항 추적

SPP PP 프로젝트 계획 수립 도구, 비용견적 도구, 과거 결과 DB

계획서작성/검토/승인 견적, 계획

SPTO PMC 프로젝트 계획 및 성과 추적

도구 PM 시정 조치, EV관리

M&A 데이터 분석도구와 메트릭 DB 메트릭수집/보고/분석/정의

측정 개념 및도구

SQA PPQA 품질보고/추적 도구 및 DB 품질보증 담당자 제품/프로세스품질 검토

SCM CM 형상관리도구, 변경관리도구/프로세스

변경통제위원회(CCB) 형상관리 기술

SPE, PR

RD, TS, PI, V&V

시스템공학 방법 및 프로세스, 설계 도구 및 프로세스, 테스트도구, 동료검토 가이드라인 및

DB

분석/설계/프로그램/테스트/product 산출물 담당자

분석/설계/코팅/테스팅 기술

OPF OPF PAL, Process DB SEPG, PIT S/W공학, 심사

OPD OPD PAL, 프로세스 개선 그룹 SEPG 프로세스 모델링

TP OT 교육/훈련 DB, 과정 개발프로세스 교육/훈련 관리자 교육 과정 개발

기술

DAR 분석 도구 및 지침 문제해결 담당자 의사결정 분석기술

4 QPM OPP 통계분석 도구 통계분석 전문가, SEPG 통계 기법

3

2



여러분의 생각은 ?여러분의 생각은 ?

“그게 우리가 일하는 방식인데 뭘…결국 같은 것 아닌가?”– 현재 상태를 바꾸고 싶지 않음

“이제 더 이상의 새로운 품질 프로그램은 싫다 !”– 예전의 품질 프로그램의 실패 또는 성공에 영향을 미침

• 예전에도 잘 안되었는데 뭘…안 따라도 별 탈 없던데…• 또 다른 문서와 기록을 만들어야 하나…

“지금은 너무 바쁘니, 내년에 합시다”– 조직적 스트레스가 너무 심함 – 비성숙된 조직 :결국 내년에도 못함

– 적절한 업무 부하의 고려가 필요함

“전체적으로는 좋은데 우리 업무에는 안맞아…”– 이해 부족

– 변화에 대한 저항

– 조직 문화

“그래서 나한데 좋은게 뭔데: What’s in it for me”: WIIFM– Buy-in

– 보상시스템

– ROI

내재화 되면 생산성이 올라감



정량적 관리 : Concept of process management정량적 관리 : Concept of process management

Concept of process management is founded on the principles of statistical process control

– By establishing and sustaining stable levels of variability, process will yield predictable results under statistical control

– Controlled process are stable processes, and stable processes enable you predict results

Improve Process

Improve Process

DefineProcessDefine

ProcessMeasureProcess

MeasureProcess

Control Process

Control Process

ExecuteProcess

ExecuteProcess

• Keeping the processwithin normal performance boundaries: Measurement detection correction

• Determine whether the process is stable

• Identify performance variations that are caused by process anomalies (assignable causes)

• Eliminate the sources of assignable causes

• Sustaining activities



Business Driver에 기반한 목표 설정 및 성과 관리Business Driver에 기반한 목표 설정 및 성과 관리

정량적 측정/통제 FrameworkSelect and implement pilot

• Business Goals• Quality Goals• Process Asset related to QPM & SQM - Processes- Procedures- Templates- Measurement Program

• PCB

• Is the quality goal practical?• Is defined measures sufficient to represent the business and quality needs?

• Is defined PCB reasonable?• Is there any need to change process, procedure and forms?

• What lessons we have learned?

Pilot result analysis

정량적 측정/통제 시스템의 구축

Improve

조직의 실제적인 사업상의 이득(benefit)(개선 경향)을 보이는가?

어떤 critical process들이 정량적으로 관리되는가? 또는 관리되지않는가?

– Vital few 프로세스 및 측정치가 통제되는가?

관리 대상 프로세스들이 프로세스 step level에서 측정되고 통제되는가?

일상적인 의사결정이 (적절한 경우에) 정량적 분석에 기반하고 있는가?

품질 목표가 우선순위가 부여되고 모순이 해결되는가?


개발 단계별 주요 이슈 및best Practices

개발 단계별 주요 이슈 및best Practices

개발 조직개발 전략

Best practices



PARKPARK 개발개발 체계체계-- PProduct Managerroduct Manager

-- QQAA LeaderLeader

-- Tech.Tech. AARRchitectchitect

-- KKnowledge Recycle Processnowledge Recycle Process((필요지식필요지식 정의정의,,생성생성,,평가평가,,활용활용 사이클사이클 ))

전문개발자전문개발자 경력경력 관리관리PM PM 인증인증 제도제도-- PM PM 교육교육//시험시험//인터뷰를인터뷰를 통한통한 사내사내 인증인증-- PMPM에에 PMPM수당수당 지급지급-- 11년년 이내에이내에 PMP PMP 자격증자격증 취득취득 조건조건

개발 조직 : 역할 및 경력 관리개발 조직 : 역할 및 경력 관리

Associate

Senior

AssociateSW Engineer

AssociateSW Engineer

Specialist

Master

ComponentDesigner

ComponentDesigner

SystemDesigner

SystemDesigner

PMPM

DBSpecialist

DBSpecialist

Sr. DBEngineer

Sr. DBEngineer

DBDB개발개발분석설계분석설계PMPM

SeniorSW Engineer

SeniorSW Engineer

MasterArchitect

MasterArchitect

SystemArchitect

SystemArchitect SW Engineer

Specialist

SW EngineerSpecialist

MasterSW Engineer

MasterSW Engineer

Master DBEngineer

Master DBEngineer

R&D 역량

Project Management

Leadership

개발방법론

Tester Tester

SeniorTester

SeniorTester

TestSpecialist

TestSpecialist

TestTest

MasterQA

MasterQA

SeniorQA

SeniorQA

QASpecialist

QASpecialist

QAQA

Associate

Senior

Specialist

Master

Designer Designer

SeniorDesigner

SeniorDesigner

DesignSpecialist

DesignSpecialist

DesignerDesigner

MasterTech. Writer

MasterTech. Writer

SeniorTech. Writer

SeniorTech. Writer

Tech. WritingSpecialist

Tech. WritingSpecialist

WriterWriter



개발 전략: Engineering does much more…개발 전략: Engineering does much more…

BizFlow

ReleasesCustomer

Support

Level 3

Support

Patches &

Hot Fixes

Proof of

Concept &

Partner

Support

Accelerator

Development

Special

Projects

IT

Knowledge

Transfer

Roadmap &

Enhancement

Requests

Performance

Benchmarking

Engineering

Engineering does much more…

Engineering PhilosophyProduct needs to be well received by our customers and

partners• to drive additional revenue• to provide references for future sales

Product needs to be robust so that• we don’t eat up our profits in support costs• we don’t lose those customers it cost so much to

obtain in 1st place• we deliver what we promised and meet customer

expectations

View each release as having its own lifecycle

Professional Services:ConsultingTroubleshooting

Special Projects

Sales:RFP ResponsesProof of Concepts

It takes a Village …

Fulfillment: Masters, Packaging, License Generator



Best Practice(1): Requirements ProcessBest Practice(1): Requirements Process

Gather Input

Analyze RequestsUpdate 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 PainBenefits of Enhancement, etc.

Requirements SourcesInternational

HSK, HSJ – Marketing & Sales HSK – R&DInternational Sales

North AmericaHSU – Product Marketing & Solutions MarketingHSU – Sales Engineering & SalesHSU – 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. prioritizationNorth American strategy docs for market & product direction

D&E provides international assessment of requirements prioritizationstrategy for product technical innovation, ensuring product quality, stability and performance and localization, less costly support,and ability to OEM and partition product

Roadmap ProductionD&E prioritizes requirements based upon above analysisD&E designate a target on roadmap for completion for major enhancement requestsD&E produces internal and external roadmap D&E establish a theme for each major release and assigns enhancements requests to a target releaseBi-Yearly Meeting with Executive Management to go over roadmap

Release OutlineD&E works with Product Marketing to establish a target date for the releaseD&E works with Product Marketing, HSJ and HSK to establish ‘Top 10’ for the release



Best Practice(2): CSR/Defect trackingBest Practice(2): CSR/Defect tracking

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

Customer

CSD system

Home page

Promise(RMT)

Promise(CSR) Promise(DMT)

SE,협력사PDM/Tester/Developer

CSR : 릴리즈 이후에발생하는 사이트요구사항과 결함, 기술지원 이슈에 대한대응에 사용

(Customer Support Response)

RMT : 개발 단계의 제품에대한 요구사항을 관리

(Requirement Management Tool)

DMT : 개발 단계의 제품에대한 결함을 등록하여처리

(Defect Management Tool)

Inspection : 개발 단계의제품에 대한 동료 검토결과를 등록하여 관리



Best Practice(3): 착수 단계 ProcessBest Practice(3): 착수 단계 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.31SES연구소 / 이승호 이사

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팀, 고개지원팀, 프로젝트 수행팀, 마케팅, 사업본부에 공지하고피드백



Best Practice(4) : 분석/설계/코딩 checklist Best Practice(4) : 분석/설계/코딩 checklist

개발자들은 상세설계서를 보고 코딩하십니까?– 개발 과정 중에 산출물의 일관성, 추적성은

확보되어야 함

– 요구사항의 변경에 따라 다른 산출물(설계서, 코드, 테스트 시나리오)은 일관성 있게 변경관리되어야 함

– 명세서는 일관성과 정확성이 최우선사항임(완전성의 범위는 고려 필요)

표준 방법론을 프로젝트에 조정하여사용하십니까?

– 최소한의 산출물/deliverables 이결정되었는가?

SRS가 다음을 포함하는가?– 새로운 features, enhancements, and

architectural updates에 대하여Engineering Requirements가 명세화되는가?

– high level Use Cases를 포함하고 있는가?

– 이전 버전과의 호환성, 업그레이드 목표가검토되는가?

– engineering requirements가 검토되고공표/공유되는가?

– 기능적 요구사항 외의 비기능적 요구사항이포함되는가?

구조설계가 다음을 포함하는가?전체적인 architectural strategy가 포함되어있는가?

• guidelines for localization, support, and ability to divide the product가 포함되는가?

새로운 features or enhancements에 대한구조가 product quality, stability and performance, scalability, modularity, testability 등을 고려하여 결정되었는가?표준에 대한 적합성이 고려되었는가?

주요 기술적 concept에 대한 prototype이이루어졌는가?User Interface Guidelines이 있는가?

다음의 표준 및 지침이 준비되고 이것을 따르고있음이 검토되는가?

설계 표준

설계 검토 지침

코딩 표준(성능 관점 코딩 표준, 언어별 코딩 표준)

각 단계별 공식검토가 수행됩니까?Engineering requirements review

SRS review (by marketing & SE(especially for UI), R&D, PQM)

Architecture Review

Detailed design Review

명세서의 개발, 코딩 과정에서 Walkthrough 및Inspection이 수행됩니까?



Best Practice(5) : Base ModelBest Practice(5) : Base Model

활동 범위 선정

내부 개발 공정 평가 외부 개발 공정 벤치마크

활동 Vision 정의

활동 과제 선정

과제 작성 및 검토

개발공정 문제보고서 외부개발공정 벤치마크 보고서

Modeling Handbooks

using BASE MODEL

HANDY BASE MODEL

교육 훈련 교재 작성

및 교육 훈련개발 공정 평가 방안 수립

활동 시작

활동 평가 활동 종료

완수된 활동

미완된 활동

완료된 산출문서

완료된 산출모델

Base Model–모델링 도구 “Enterprise Architect”에서즉각적으로 활용되는베이스 모델

Modeling Guide Handbooks

–각 모델링 개념 및 지침설명

–각 모델링 공정의 목표, 역할, 산출물, Workflow 정의

–템플릿, 가이드라인Modeling Examples

–각 모델 별 시나리오 및모델링 예제

DEMO–Handy Base Model을활용한 Modeling 데모

–산출물 템플릿

–Handbook에 포함된가이드라인

Base Model–모델링 도구 “Enterprise Architect”에서즉각적으로 활용되는베이스 모델

Modeling Guide Handbooks

–각 모델링 개념 및 지침설명

–각 모델링 공정의 목표, 역할, 산출물, Workflow 정의

–템플릿, 가이드라인Modeling Examples

–각 모델 별 시나리오 및모델링 예제

DEMO–Handy Base Model을활용한 Modeling 데모

–산출물 템플릿

–Handbook에 포함된가이드라인

접근방법 산출물



Best Practice(6): 프로젝트 관리Best Practice(6): 프로젝트 관리

Daily Tea Meeting

Time card 작성 (WISE 시스템: 비용/공수 추적)

주간 보고

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

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

월간보고

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

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

분기별 보고

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

품질경영실 보고

– 주간: 프로젝트 진척 현황 및 이슈

– 월간/분기별: 인스펙션 현황, 프로젝트 평가 결과, 고객만족도 조사 결과

– 연간 : 품질백서



Best Practice(7): 개발방법론Best Practice(7): 개발방법론

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

Enhancement) Series

Handy*MATE-PD: for package developmentHandy*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

방법론 개발 방향현행 practice의 약점을 보완 : 현행 practice를최대한 활용

최소한의 산출물 위주로 정리유지보수용 최소 문서(설계서, 코드의 주석문, 코딩 표준의 준수)

필수 제품 문서(사용자 매뉴얼, S/E 매뉴얼)

산출물의 구체적 작성 지침 제공산출물별 필수 항목 및 작성 요령 정리

기법에 dependent한 항목의 작성방법은 별도의지침서로 정리

업무에 필요한 필수지침 위주로 정리 필요Inspection 지침, 테스트 지침/체크리스트

개발자의 관점 외에 관리/지원 활동과의 조화PM, QA, Software Manufacturing Group의 업무관점 포함

개발 작업과 유기적으로 연결되도록 활동 및 작업정의

관련 표준에의 적합성 검토

실제 프로젝트에 적용 및 유효성 확인



Best Practice(8) : InspectionBest Practice(8) : Inspection

Inspection의 효율성 제고 노력– 연구개발본부의 중점 추진 사항– 정량적 데이터의 수집.보고(preparation time, 결함 유형, Inspection 속도, 효과성

중심) – 주간, 월별/분기별 보고(품질경영실이 경영분석회의에 보고)– Promise시스템을 통한 결함의 추적 관리

< 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



Best Practice(9) : Test & 릴리즈 검토회의Best Practice(9) : Test & 릴리즈 검토회의

1. 목적 및 범위

1.1 요구사항 구현 확인

1.2 오류 제거

1.3 범위

2. 검사 환경

2.1 서버 환경

2.2 Client 환경

3. 업무 분장

4. 검사 결과

4.1 요구사항 목록에 대한 확인 결과

4.2 6.7.1 전체 문제 발생 및 처리 현황

4.3 전체 6.7.1 일자별 오류 보고 현황

4.4 1차 Feature Build 후 일자별 오류 보고현황

4.5 기능별 오류 발견 현황

4.6 전체 오류 처리 현황

4.7 전체 오류 미처리 현황

4.8 개발팀 처리 진행 사항

4.9 예상 Known Bug

5. 검사 판정

5.1 문제점

5.2 판정

[별첨 #1] 요구사항 항목별 현황

[별첨 #2] 빌드 및 테스트 일정 계획

4.6 전체 오류 미처리 현황

기능 치명적 매우심각 심각 보통 합계

문서함(아래한글결재) 18 2 20

양식작성기 1 1

전자결재(아래한글결재) 1 3 15 5 24

전자문서유통 1 1

통계(아래한글결재 통계) 1 1

공유설비 2 2

노티파이 3 3

로그인_초기화면 2 2

설치 2 2

시스템관련 1 1

전자게시판 1 1

전자우편 1 11 12

조직도관리 1 1

환경설정 1 1

합계 1 7 56 8 72

Unit Test• Logic Test• Data structure

Test• UI Test• Boundary Test

Unit Test• Logic Test• Data structure

Test• UI Test• Boundary Test

Integration Test• By using Test Case• Regression TestSystem Test

• Stress Test• Performance TestEnv. Test

• for various Env.Installation Test

• New installation Test• Upgrade Test

Integration Test• By using Test Case• Regression TestSystem Test

• Stress Test• Performance TestEnv. 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

•Member: PDM, Head of test team, Tester representatives, PM,…

Test Review• Review of test result

• Decision of release

테스트팀 릴리즈검토위원회

개발자

릴리즈 검토회의 자료



Best Practice(10) : 종료 단계 ProcessBest Practice(10) : 종료 단계 Process

Customer Satisfaction SurveyOverview

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

Method of surveyUsing questionnaire from representative end users and operatorsSurvey of satisfaction of 4 phases

• Sales, Analysis/Design, Development, OperationEvaluation 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 OSSPSummary of CSS and corrective actions taken reported to monthly management meeting

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

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

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

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



Best Practice (11) : 사업 목표 및 품질 목표Best Practice (11) : 사업 목표 및 품질 목표

Business Goals

Effort DistributionProductivityCostschedule deviation

Process CapabilityBaseline

Effort DistributionProductivityInspectionEffectivenessDelivered Qualityschedule deviation

Increase Profits

Increase customersatisfaction

Measures Quality GoalsInspectionEffectiveness(60%)Delivered Quality(0.02 Defect/Kloc)Schedule deviation(+4%)

Service ProjectsProduct Development Projects

Effort DistributionProductivityInspectionEffectivenessCostDelivered QualitySchedule deviation



Best Practice (12): Organization’s PALBest Practice (12): Organization’s PAL

Web-based process asset library

품질매뉴얼및품질절차서• PM핸드북

• 개발방법론• 프로세스맵, 절차서/지침, 산출물템플리트의공유


프로세스 개선의 제언프로세스 개선의 제언

중소 S/W업체에서의 품질 개선 문제점과도한 노력을 줄이는 방법

프로세스 개선 영역의 우선 순위?



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

중소 S/W업체의 주요 사업목표: Survive !–품질 개선 및 프로세스 개선에 있어서의 문제점

•현상태에 불만족, 품질개선과 프로세스개선은 분명 도움이 될텐데…

•필요한 자원과 역할의 할당이 어려움–개선에 소요되는 비용과 자원을 감당할 수있느냐?

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

중소 S/W업체의 문화–우리는 모두 해당 업무에 적격이다–우리는 의사소통 하는데 문제가 없다–우리는 모두 영웅이다

• 필요한 것은 모두 우리가 한다, 규칙은 필요 없다, 단기간의 cycle time과 stress는 당연하다

품질개선 문제점–테스트 및 평가 – 출시 시점에 임박한 개발 완료, 테스트 부족, 재작업 시간 부족

–요구사항의 관리 – 문서화?–프로젝트 관리 – 관리 경험?–자원의 할당 – 우리는 작다 !–교육.훈련의 제공 – 우리 직원 모두는 적격이다–검토 수행 – 누가 자격이 있고 가용한가?–문서의 생성 – 시간이 있으면…–진척도의 측정 – 제일 모르는…

프로세스 개선의 필요성이의심되는가? 비용 대비효과가 의심되는가?

요구사항관리가 과도한요구사항을 제거한다면 불필요한작업이라고 할 수 있는가?

동료검토가 재작업을 50% 정도줄인다면 불필요한 작업이라고 할

수 있는가?

프로세스 개선은 프로세스를추가하는 것이 아님

현재 일어나고 있는 모든 것은하나 또는 그 이상의 프로세스와관련이 있음

중소 규모 조직에서는 프로세스개선은 사업에 초점을맞추고(business-focus) 적고(less) 더좋은(better) 프로세스를 요구함



과도한 노력을 줄이는 방법과도한 노력을 줄이는 방법

기반구조: 없으면 체계적인 진행이 안됨

–개선을 주도하는 그룹필요(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에 맞게)



프로세스 개선 영역의 우선 순위?프로세스 개선 영역의 우선 순위?

1. 검증(Verification)(동료 검토)– 모든 프로젝트팀에 적용됨. 소프트웨어 제품에직접적인 영향을 줌

2. 위험 관리– 어찌보면 모든 것이 위험관리의 대상임

– 위험관리를 어떤 프로세스 영역이 사업의성공에 필수적인가를 결정하는데 활용함

3. 교육.훈련– 작은 조직/프로젝트일수록 한 사람이 경험이적은 여러가지 역할을 담당하기에 더욱 필요함

4. 프로세스 정의– 정의된 프로세스가 융통성, 기민함, 신속한응답을 제공할 수 있음

– 정의된 프로세스는 이직으로 인한 조직적지식의 손실 감소, 신입직원의 적응기간 감소등의 효과가 있음

5. 품질보증– 보통 품질보증이 가동되면 다른 모든 것들이가동됨

– 적절히 구현되면 품질보증은 저비용-고효과의지원 기능이 됨

프로세스 개선의 기본프로세스 개선은 진화적이고지속적이며 주기를 따라야 한다

사람과 조직은 변경에 따른유인책(business driver)이 있는경우에만 바뀐다

프로세스 변경은 목표 지향적이어야한다

개선활동을 작은 프로젝트로간주한다

너무 욕심을 내지 않는다

작은 승리에 만족한다

부드럽게 그렇지만 쉼없이 압박한다

집중, 집중, 집중한다

후원자를 찾는다

행동으로 표현되지 않는 활동계획은쓸모가 없다



감사합니다. 감사합니다감사합니다. .

Dr. Yu-whoan AhnExecutive Director / Handysoft Corp.

[email protected]

cmm level 5 달성 전략및노하우품질보증(품질측정거의없음) 품질측정,...

Documents