process improvement seminar
DESCRIPTION
TRANSCRIPT
프로세스… 프로세스…
• 과업이 아닌 연속적 업무의 묶음을 말한다 .
• 예를 들며 , 주문프로세스는 소비자의 주문이 접수되는 단계에서 주문 품목이 소비자에게 전달되기까지의 모든 과정을 의미한다 . • ISO9000 시리즈 개정 2000 판에서는 ‘입력을
출력으로 변환시키는 , 상호관련되거나 상호작용하는 활동의 집합’이라고 정의하였다• CMMI 에서는 ‘하나의 문제를 해결하기 위한 일련의
작업들’이라고 정의하였다 .
- 출처 : 두산백과사전
방법론 ? 절차 ? 프로세스 ??
문서
업무
업무
업무
문서 문서
…
…
프로세스
프로세스의 초점
절차
사람도구
문서
업무
업무
업무
문서
문서
…
…
프로세스의 종류
• 비즈니스 프로세스• 연구 /개발 프로세스• IT 서비스 프로세스• … 목표
문서
업무
업무
업무
문서
문서
…
…
IT 프로세스의 분류
개발 프로세스의 필요성
• If programmers have make a plane– 출처 :
http://kr.youtube.com/watch?v=UZq4sZz56qM&fmt=18
동영상
개발 프로세스의 종류
ISO/IEC 12207 수명주기
CMMI 의 FrameworkEngineering Support
ProjectMGMT Process MGMT
Validation
Verification
Product Integration
Technical Solution
Requirements Development
Requirement Management
Quantitative Project Management
Validation
Verification
Product Integration
Technical Solution
Requirements Development
Requirement Management
Quantitative Project Management
Causal Analysis and Resolution
Organizational Environment for Integration (IPPD)
Decision Analysis and Resolution
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
Causal Analysis and Resolution
Organizational Environment for Integration (IPPD)
Decision Analysis and Resolution
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
Integrated Supplier Management
Integrated Teaming (IPPD)
Risk Management
Integrated Project Management for IPPD (IPPD)
Supplier Agreement Management
Project Monitoring and Control
Project Planning
Integrated Supplier Management
Integrated Teaming (IPPD)
Risk Management
Integrated Project Management for IPPD (IPPD)
Supplier Agreement Management
Project Monitoring and Control
Project Planning
Organizational Innovation and Deployment
Organizational Process Performance
Organizational Training
Organizational Process Definition
Organizational Process Focus
Organizational Innovation and Deployment
Organizational Process Performance
Organizational Training
Organizational Process Definition
Organizational Process Focus
ISO/IEC15504 (SPICE)Primary life cycle Processes Supporting life cycle Processes
Organizational life cycle Processes
CUS.1 AcquisitionCUS1.1 Acquisition preparationCUS1.2 Supplier selectionCUS1.3 Supplier monitoringCUS1.4 Customer acceptance
CUS.2 Supply
CUS.3 Requirement elicitation
CUS4.1 Operational useCUS4.2 Customer support
CUS.4 Operation
ENG.1 Development
ENG.2 System and Software Maintenance
ENG1.1 System requirement analysis and design
ENG1.2 Software requirement analysisENG1.3 Software design
ENG1.4 Software constructionENG1.5 Software integrationENG1.6 Software testingENG1.7 System integration
testing
SUP.1 Documentation
SUP. 2 Configuration management
SUP.3 Quality assurance
SUP.4 Verification
SUP.5 Validation
SUP.6 Joint review
SUP.7 Audit
SUP.8 Problem resolution
MAN.1 Management
MAN.2 Project management
MAN.3 Quality management
MAN.4 Risk management
ORG.1 Organizational alignment
ORG.1 Human resource management
ORG.4 Infrastructure
ORG.5 Measurement
ORG.6 Reuse
ORG.2 ImprovementORG.2.1 Process establishmentORG.2.2 Process assessmentORG.2.3 Process improvement
Primary life cycle Processes Supporting life cycle Processes
Organizational life cycle Processes
CUS.1 AcquisitionCUS1.1 Acquisition preparationCUS1.2 Supplier selectionCUS1.3 Supplier monitoringCUS1.4 Customer acceptance
CUS.2 Supply
CUS.3 Requirement elicitation
CUS4.1 Operational useCUS4.2 Customer support
CUS.4 Operation
ENG.1 Development
ENG.2 System and Software Maintenance
ENG1.1 System requirement analysis and design
ENG1.2 Software requirement analysisENG1.3 Software design
ENG1.4 Software constructionENG1.5 Software integrationENG1.6 Software testingENG1.7 System integration
testing
SUP.1 Documentation
SUP. 2 Configuration management
SUP.3 Quality assurance
SUP.4 Verification
SUP.5 Validation
SUP.6 Joint review
SUP.7 Audit
SUP.8 Problem resolution
MAN.1 Management
MAN.2 Project management
MAN.3 Quality management
MAN.4 Risk management
ORG.1 Organizational alignment
ORG.1 Human resource management
ORG.4 Infrastructure
ORG.5 Measurement
ORG.6 Reuse
ORG.2 ImprovementORG.2.1 Process establishmentORG.2.2 Process assessmentORG.2.3 Process improvement
RskMGMT( 기초 )• Risk Management ( 위험관리 )
– 프로젝트에서 리스크 요소는 발생 여부가 불명확한 조건이나 사건을 말하는데 , 이것이 현재화 될 경우 , 프로젝트는 원하지 않는 결과를 보이게 된다 . 리스크 관리는 이러한 잠재적인 문제가 현재화 되기 전에 그 문제를 식별하고 , 관리 가능한 상태로 두어 프로젝트의 실패 확률을 최소화하는 관리 방법이다 .
• Boehm 위험 관리리스크 평가
리스크 식별 프로젝트에 영향을 줄수 있는 요소들을 식별하고 문서화한다
리스크 분석 식별한 리스크의 발생 확률 (likelihood) 과 그 영향력 (consequence) 을 평가한다 .
리스크 우선순위 부여
리스크 분석의 결과에 근거를 두고 상대적인 우선순위를 부여한다
리스크 제어
리스크 경감계획 식별된 각 리스크에 대한 경감 계획을 세우고 문서화한다
리스크 해결 리스크 경감 계획을 이행한다
리스크 감시 각 리스크의 상황을 정기적으로 감시한다
RskMGMT( 참조 )GOAL PRACTICE
SG1. 리스크 관리의 준비가 실시되고 있다 .
SP1.1 리스크의출처 ( 구분 ) 을 결정한다 .
SP1.2 리스크 파라미터를 정의한다 .
SP1.3 리스크 관리 전략을 확립한다 .
SG2. 리스크가 특정되고 분석된다
SP2.1 리스크를 특정한다 .
SP2.2 리스크를 평가 분류하고 우선순위를 지정한다
SG3. 리스크가 경감(mitigation)된다
SP3.1 리스크 경감 계획을 책정한다
SP3.2 리스크 경감 계획을 수행 , 감시한다
목적 : 「리스크 관리」의 목적은 , 잠재적인 문제가 표면화하기 전에 그 문제를 특정하는 것이다 . 이것에 의해 , 목표 달성의 방해가 되는 것과 같은 영향을 경감 (mitigation) 하기 위해서 , 성과물 또는 프로젝트의 전반에 걸쳐 필요에 따른 리스크 활동이 계획되고 개시된다 .
ISO/IEC 리스크관리 기본 활동 사항
① 리스크 관리의 범위 (Scope) 를 확립한다 . ② 리스크 관리 전략을 정의한다 . ③ 리스크를 식별한다 . ④ 리스크를 분석한다 . ⑤ 리스크 처리 액션을 정의하고 수행한다 . ⑥ 리스크를 감시한다 . ⑦ 정정조치를 강구한다 .
• CMMI 위험관리– CMMI 의 리스크 관리는 3 개의 특정 골
(Specific Goal) 과 7 개의 특정 활동(Specific Practice) 로 구성되어 있다 .
• ISO/IEC 15504 위험 관리 – ISO/IEC 15504 는 크게 고객 공급자
프로세스 범주 (Customer-Suppler Process Category), 공학 프로세스 범주 (Engineering Process Category), 지원 프로세스 범주(Support Process Category), 관리 프로세스 범주 (Management Process Category), 조직 프로세스 범주(Organization Process Category) 5개의 범주로 분류하고 리스크 관리는 관리 프로세스 범주에 속해 있다 .
RskMGMT( 개발 )
리스크를 객관적으로 평가한다
복수의 시점 , 정량적인 정보로부터 리스크 레벨을 이끌어내야 하며 , 객관적으로 리스크를 평가해야 한다 .
리스크의 변화를 추적한다
일정 , 품질 , 형상 등 날마다 변하는 데이터를 추적함으로써 리스크가 현재화되는 상황을 조기에 파악해 빠른 대처가 가능하다 .
리스크를 가시화 한다
리스크를 모두가 이해할 수 있는 형태로 가시화해 , 공유 가능하게 한다 . 이에 따라 , 조직적으로 리스크 관리가 이루어 질 수 있다 .
프로젝트 리더
프로젝트의 개발계획과 고객의 요구사항에 근거하여 리스크를 식별한다 . 이것은 실제 개발 현장에서 느끼는 리스크 항목들이 기술되어 있다 .
프로젝트 관리자
프로젝트 규모 ( 공수 , 수주액 ) 등 경영 지표에 대한 리스크를 표현한다 .
시니어 관리자
전략지표의 식별을 행한다 . 예를들어 고객의 속성을 정량화 한다
Date: P-code: :보고자
모르겠다[1]
① .고객담당자의 조정능력에 불안이 있다② SRA 고객과 의 역할 책임범위가 불명확하다③ ・・・④ ・・・
① 요건이 불명확하다② 요건의 이해력 부족③ 요건에 대한 합의 부족④ ・・・⑤ ・・・
① .추정이 낙관적이다② .필요로 생각되어지는 업무 및 작업이 빠져있다③ 추정의 항목부족④ ・・・⑤ ・・・
① 요원이 기술력 부족② ・・・
①②
①②
①②
①②
①②
① .계약전에 프로젝트가 시작될 가능성이 있다② ・・・
리스크 식별시트
리스크항목
10. 기타
2. 소프트웨어 요건에 관한 리스크
3. 추정에 관한 리스크
4. SRA 내부에 관한 리스크
5. 품질에 관한 리스크
6. 개발환경에 관한 리스크
생략
생략
발생시 영향도 발생확률
생략
생략
7. 기술에 관한 리스크
8. (moral e) 모럴 에 관한 리스크
1. 고객에 관한 리스크
9. 계약에 관한 리스크
생략
[1-4] [1-3]
• 제안 위험관리- 조직관점의 위험관리
- 역할별 위험 관점
애자일 선언의 원칙
우리는 다음의 원칙을 따릅니다 :
우리는 가치있는 소프트웨어를가능한한 빠르게 계속적으로 인도함 으로써
고객의 만족도를 높이는 것을 최 우선으로 합니다 .
요구사항의 변경은 비록 개발 마지막 단계라도 반영합니다 .
애자일 프로세스는 변화를 포용함으로써고객의 경쟁력을 높여줍니다 .
동작하는 소프트웨어가 2~3 주에서 2~3 개월정도에 릴리즈 될만큼
짧은 시간 간격으로 반복해서 인도합니다 .
사업자와 개발자는 프로젝트를 통해매일 매일 함께 일하지 않으면 안됩니다 .
의지가 가득한 사람들을 모아 프로젝트팀을 구성합니다 .그러하니 , 그들이 필요로 하는 환경과 지원을 해 주어 ,
프로젝트가 성공적으로 끝날때 까지 그들을 신뢰하십시오 .
개발 팀에 대해서 , 혹은 개발팀 내부에서정보를 주고받는 가장 효과적인 방법은마주보고 이야기 하는 것입니다 .
동작하는 소프트웨어가 진척상황을 측정하는 가장 중요한 요소입니다 .
기민한 프로세스는 지속 가능한 개발을 촉진합니다 .스폰서 , 개발자 , 사용자는 일정한 페이스로
계속된 유지 보수를 할 수 있도록 해야 합니다 .
탁월한 기술과 뛰어난 설계에 끊임없이 집중하면 기민성이 높아집니다 .
단순함 -- 작업없이 끝내는 양을 최대한으로
높이는 예술 -- 이 본질입니다 .
최고의 아키텍쳐 , 요구사항 , 설계는스스로 조직된 팀에서 만들어집니다 .
어떻게해야 팀의 효율을 높일 수 있을까에 대하여
정기적으로 되돌아보며 , 그에 기초하여 스스로의 방식으로최적의 개선을 합니다 .
.
.
.
.< 출처 : 애자일 연합 선언문 >
애자일 프로세스
계획은 변경된다 . 개발은 예측 불가능하다 . 사람이 결과를 좌우한다 .
VS정형
경험
XP & Scrum
• 의사소통 : 대화하고 함께 일하기• 단순성 : 불필요하거나 덜 중요한 작업 , 요구사항 , 설계 제거• 존중 : 같이 일하는 사람을 존중하기 , 자신의 프로젝트를 존중하기 • 피드백 : 자주 빨리 보여주고 의견을 수렴• 용기 : 의사소통 , 단순성 ,피드백을 수행할 용기
• 확약 : 약속한 것을 확실히 실현되는 것• 전념 : 확약한 것의 실현에 전념하는 것• 숨기지 않음 : 비록 자신에게 있어서 불리한 일에서도 숨기지 않는 것• 존중 : 자신과 다른 사람에게 경의를 표하는 것• 용기 : 확약해 , 숨기지 않고 , 경의를 표하기 위해서 용기를 가지는 것
프로세스 표준화 ? 개선 ?
제공한다
따른다
프로세스개선
프로세스표준화
?인증 SOX
지침… 규제 !
이상적인프로세스
“Management” vs “Control”
프로세스 개선
GAPGAP
QNA