Process Improvement Seminar

1,327 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,327
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Process Improvement Seminar

  1. 1. 프로세스 개선의 이해 신병호 [email_address]
  2. 2. 프로세스… 프로세스… <ul><li>과업이 아닌 연속적 업무의 묶음을 말한다 . </li></ul><ul><ul><ul><li>예를 들며 , 주문프로세스는 소비자의 주문이 접수되는 단계에서 주문 품목이 소비자에게 전달되기까지의 모든 과정을 의미한다 . </li></ul></ul></ul><ul><ul><ul><li>ISO9000 시리즈 개정 2000 판에서는 ‘입력을 출력으로 변환시키는 , 상호관련되거나 상호작용하는 활동의 집합’이라고 정의하였다 </li></ul></ul></ul><ul><ul><ul><li>CMMI 에서는 ‘하나의 문제를 해결하기 위한 일련의 작업들’이라고 정의하였다 . </li></ul></ul></ul><ul><ul><ul><li>- 출처 : 두산백과사전 </li></ul></ul></ul>
  3. 3. 방법론 ? 절차 ? 프로세스 ?? … … 문서 업무 업무 업무 문서 문서
  4. 4. 프로세스의 초점 프로세스 절차 사람 도구 문서 업무 업무 업무 문서 문서 … …
  5. 5. 프로세스의 종류 <ul><li>비즈니스 프로세스 </li></ul><ul><li>연구 / 개발 프로세스 </li></ul><ul><li>IT 서비스 프로세스 </li></ul><ul><li>… </li></ul>목표 문서 업무 업무 업무 문서 문서 … …
  6. 6. IT 프로세스의 분류
  7. 7. 개발 프로세스의 필요성 <ul><li>If programmers have make a plane </li></ul><ul><ul><li>출처 : http://kr.youtube.com/watch?v=UZq4sZz56qM&fmt=18 </li></ul></ul>동영상
  8. 8. 개발 프로세스의 종류
  9. 9. ISO/IEC 12207 수명주기
  10. 10. CMMI 의 Framework
  11. 11. ISO/IEC15504 (SPICE)
  12. 12. RskMGMT( 기초 ) <ul><li>Risk Management ( 위험관리 ) </li></ul><ul><ul><li>프로젝트에서 리스크 요소는 발생 여부가 불명확한 조건이나 사건을 말하는데 , 이것이 현재화 될 경우 , 프로젝트는 원하지 않는 결과를 보이게 된다 . 리스크 관리는 이러한 잠재적인 문제가 현재화 되기 전에 그 문제를 식별하고 , 관리 가능한 상태로 두어 프로젝트의 실패 확률을 최소화하는 관리 방법이다 . </li></ul></ul><ul><li>Boehm 위험 관리 </li></ul>리스크 평가 리스크 식별 프로젝트에 영향을 줄수 있는 요소들을 식별하고 문서화한다 리스크 분석 식별한 리스크의 발생 확률 (likelihood) 과 그 영향력 (consequence) 을 평가한다 . 리스크 우선순위 부여 리스크 분석의 결과에 근거를 두고 상대적인 우선순위를 부여한다 리스크 제어 리스크 경감계획 식별된 각 리스크에 대한 경감 계획을 세우고 문서화한다 리스크 해결 리스크 경감 계획을 이행한다 리스크 감시 각 리스크의 상황을 정기적으로 감시한다
  13. 13. RskMGMT( 참조 ) <ul><li>CMMI 위험관리 </li></ul><ul><ul><li>CMMI 의 리스크 관리는 3 개의 특정 골 (Specific Goal) 과 7 개의 특정 활동 (Specific Practice) 로 구성되어 있다 . </li></ul></ul><ul><li>ISO/IEC 15504 위험 관리 </li></ul><ul><ul><li>ISO/IEC 15504 는 크게 고객 공급자 프로세스 범주 (Customer-Suppler Process Category), 공학 프로세스 범주 (Engineering Process Category), 지원 프로세스 범주 (Support Process Category), 관리 프로세스 범주 (Management Process Category), 조직 프로세스 범주 (Organization Process Category) 5 개의 범주로 분류하고 리스크 관리는 관리 프로세스 범주에 속해 있다 . </li></ul></ul>GOAL PRACTICE SG1. 리스크 관리의 준비가 실시되고 있다 . SP1.1 리스크의출처 ( 구분 ) 을 결정한다 . SP1.2 리스크 파라미터를 정의한다 . SP1.3 리스크 관리 전략을 확립한다 . SG2. 리스크가 특정되고 분석된다 SP2.1 리스크를 특정한다 . SP2.2 리스크를 평가 분류하고 우선순위를 지정한다 SG3. 리스크가 경감 (mitigation) 된다 SP3.1 리스크 경감 계획을 책정한다 SP3.2 리스크 경감 계획을 수행 , 감시한다 목적 : 「리스크 관리」의 목적은 , 잠재적인 문제가 표면화하기 전에 그 문제를 특정하는 것이다 . 이것에 의해 , 목표 달성의 방해가 되는 것과 같은 영향을 경감 (mitigation) 하기 위해서 , 성과물 또는 프로젝트의 전반에 걸쳐 필요에 따른 리스크 활동이 계획되고 개시된다 . ISO/IEC 리스크관리 기본 활동 사항 <ul><li>리스크 관리의 범위 (Scope) 를 확립한다 . </li></ul><ul><li>리스크 관리 전략을 정의한다 . </li></ul><ul><li>리스크를 식별한다 . </li></ul><ul><li>리스크를 분석한다 . </li></ul><ul><li>리스크 처리 액션을 정의하고 수행한다 . </li></ul><ul><li>리스크를 감시한다 . </li></ul><ul><li>정정조치를 강구한다 . </li></ul>
  14. 14. RskMGMT( 개발 ) <ul><li>제안 위험관리 </li></ul><ul><ul><li>- 조직관점의 위험관리 </li></ul></ul><ul><ul><li>- 역할별 위험 관점 </li></ul></ul>리스크를 객관적으로 평가한다 복수의 시점 , 정량적인 정보로부터 리스크 레벨을 이끌어내야 하며 , 객관적으로 리스크를 평가해야 한다 . 리스크의 변화를 추적한다 일정 , 품질 , 형상 등 날마다 변하는 데이터를 추적함으로써 리스크가 현재화되는 상황을 조기에 파악해 빠른 대처가 가능하다 . 리스크를 가시화 한다 리스크를 모두가 이해할 수 있는 형태로 가시화해 , 공유 가능하게 한다 . 이에 따라 , 조직적으로 리스크 관리가 이루어 질 수 있다 . 프로젝트 리더 프로젝트의 개발계획과 고객의 요구사항에 근거하여 리스크를 식별한다 . 이것은 실제 개발 현장에서 느끼는 리스크 항목들이 기술되어 있다 . 프로젝트 관리자 프로젝트 규모 ( 공수 , 수주액 ) 등 경영 지표에 대한 리스크를 표현한다 . 시니어 관리자 전략지표의 식별을 행한다 . 예를들어 고객의 속성을 정량화 한다
  15. 15. 애자일 선언의 원칙 우리는 다음의 원칙을 따릅니다 :   우리는 가치있는 소프트웨어를 가능한한 빠르게 계속적으로 인도함 으로써 고객의 만족도를 높이는 것을 최 우선으로 합니다 .   요구사항의 변경은 비록 개발 마지막 단계라도 반영합니다 . 애자일 프로세스는 변화를 포용 함으로써 고객의 경쟁력을 높여줍니다 .   동작하는 소프트웨어가 2~3 주에서 2~3 개월정도에 릴리즈 될만큼 짧은 시간 간격으로 반복해서 인도 합니다 .   사업자와 개발자는 프로젝트를 통해 매일 매일 함께 일하지 않으면 안됩니다 .   의지가 가득한 사람들을 모아 프로젝트팀을 구성합니다 . 그러하니 , 그들이 필요로 하는 환경과 지원을 해 주어 , 프로젝트가 성공적으로 끝날때 까지 그들을 신뢰하십시오 .   개발 팀에 대해서 , 혹은 개발팀 내부에서 정보를 주고받는 가장 효과적인 방법은 마주보고 이야기 하는 것입니다 .   동작하는 소프트웨어 가 진척상황을 측정하는 가장 중요한 요소입니다 .   기민한 프로세스는 지속 가능한 개발을 촉진합니다 . 스폰서 , 개발자 , 사용자는 일정한 페이스로 계속된 유지 보수를 할 수 있도록 해야 합니다 .   탁월한 기술과 뛰어난 설계 에 끊임없이 집중하면 기민성이 높아집니다 .   단순함 -- 작업없이 끝내는 양을 최대한으로 높이는 예술 -- 이 본질입니다 .   최고의 아키텍쳐 , 요구사항 , 설계는 스스로 조직된 팀 에서 만들어집니다 .   어떻게해야 팀의 효율을 높일 수 있을까에 대하여 정기적으로 되돌아보며 , 그에 기초하여 스스로의 방식으로 최적의 개선 을 합니다 . . . . . < 출처 : 애자일 연합 선언문 >
  16. 16. 애자일 프로세스 계획은 변경된다 . 개발은 예측 불가능하다 . 사람이 결과를 좌우한다 . VS 정형 경험
  17. 17. XP & Scrum <ul><li>의사소통 : 대화하고 함께 일하기 </li></ul><ul><li>단순성 : 불필요하거나 덜 중요한 작업 , 요구사항 , 설계 제거 </li></ul><ul><li>존중 : 같이 일하는 사람을 존중하기 , 자신의 프로젝트를 존중하기 </li></ul><ul><li>피드백 : 자주 빨리 보여주고 의견을 수렴 </li></ul><ul><li>용기 : 의사소통 , 단순성 , 피드백을 수행할 용기 </li></ul><ul><li>확약 : 약속한 것을 확실히 실현되는 것 </li></ul><ul><li>전념 : 확약한 것의 실현에 전념하는 것 </li></ul><ul><li>숨기지 않음 : 비록 자신에게 있어서 불리한 일에서도 숨기지 않는 것 </li></ul><ul><li>존중 : 자신과 다른 사람에게 경의를 표하는 것 </li></ul><ul><li>용기 : 확약해 , 숨기지 않고 , 경의를 표하기 위해서 용기를 가지는 것 </li></ul>
  18. 18. 프로세스 표준화 ? 개선 ? 제공한다 따른다 프로세스 개선 프로세스 표준화 ? 인증 SOX 지침… 규제 ! 이상적인 프로세스 “ Management” vs “Control”
  19. 19. 프로세스 개선 GAP
  20. 20. QNA

×