Presentation is loading. Please wait.

Presentation is loading. Please wait.

(Software Process Improvement & Case)

Similar presentations


Presentation on theme: "(Software Process Improvement & Case)"— Presentation transcript:

1 (Software Process Improvement & Case)
소프트웨어 프로세스 개선 및 적용 사례 (Software Process Improvement & Case) 2002년 6월 1일 편 흥 열 박사 에이비앤아이㈜ 소개: 신한금융지주회사 정보전략계획수립 컨설팅 프로젝트에서 소프트웨어 프로세스 개선(SPI) 파트를 맡고 있는 편흥열입니다. 본 프로젝트는 지난 2월 4일부터 시작하여 4월 19일까지 진행되는 프로젝트입니다. 지난 주에 중간보고를 마쳤습니다. 그 동안 신한금융계열의 현황분석을 통해 보고 느낀 점들이 많아 이 자리에 섰습니다. 느낀 점들은 교육 도중에 말씀 드리도록 하겠습니다.

2 목 차 Software Process Maturity : An Introduction Software Process Improvement CASE STUDY 교육할 목차입니다. 소프트웨어 프로세스란 무엇인가, 성숙도란 무엇인가, SPICE란 무엇인가? CMM이란 무엇인가? 소프트웨어 프로세스 개선(SPI)란 무엇인가? 에 관련된 내용들을 말씀 드리겠습니다. 혹시 CMM, SPICE에 대한 교육이나 공부를 하신 분은 계십니까?

3 Software Process Maturity : An Introduction
B Process

4 S/W 산업의 문제점 낮은 생산성 낮은 품질 Computer Channal Inc., 1993 Standish Group
1994, 8,380 Proj. 15%의 프로젝트들은 전혀 인도되지 못했음. 소프트웨어 프로젝트들의 50% 이상은 납기 지연 비용은 항상 100% 이상 추가적으로 발생 했음. 품질, 납기, 비용을 충족한 프로젝트 비율은 16.2%에 불가함. 재작업 없이 프로젝트를 완료는 것은 6%에 불가함. 낮은 생산성 낮은 품질 제대로 납기와 비용을 지킨 프로젝트가 없었습니다. 신한은 납기만큼은 잘 키지는 조직 같습니다. 비용도 별로 초과하는 일이 없는 것 같습니다. 아웃소싱 계약에 의해 개발하시니까 추가 노력 부분들은 아웃소싱 업체에서 담당해서 그런 것이 아닌가 십습니다. 그러나 품질은 과연 보장되는가에 대해서는 장담할 수 없는 것 같습니다. 아웃소싱 개발의 경우 철저하게 관리되지 않으면 품질을 보장하기 쉽지 않을 것 같습니다. 또한 자체 개발의 경우에도 현업 요구사항 분석이 철저하게 이루어지지 않으면 현업 만족을 시키기기 쉽지 않을 것 같습니다. 소프트웨어 프로세스 개선은 이러한 생산성과 품질을 동시에 만족시키기 위한 최선의 방법인 것입니다. 개발 지연 소프트웨어 결함 비용 초과 사용자 불만 사업 기회 상실 이익 감소

5 H/W 제조 프로세스 Factory P & Q (안정화) 최종 제품 원재료
품질활동(QA) P & Q (안정화) 최종 제품이 생산되기까지 많은 검사와 제조 프로세스의 통제를 통해 품질을 보증함. 프로세스의 최종 단계까지 문제점이 발견되지 않은 채 문제가 더욱 악화 되는 것을 허용하지 않으며, 품질 측정을 통해 결함이 있는 제품이 대량 생산되기 전에 결함이 있는 프로세스는 변경되어 짐. 제조업에서의 품질 관리는 매우 철저하게 이루어지고 있습니다. 만약 결함이 있는 제품이 발생하면 즉각적으로 원인을 규명하여 조치가 되어집니다. 제조업에서의 Z Defect 운동이나 6 시그마 운동은 그 대표적인 예입니다. 제조에서는 무엇보다 프로세스(공정)에 대한 관리를 철저히 함으로써 품질과 생산성을 보장합니다. 그렇다면 과연 소프트웨어 개발에서의 품질과 생산성은 어떻게 보장하시겠습니까? 출처 : Schulmeyer, Zero Defect Software

6 S/W 개발은 무엇이 문제인가? 소프트웨어 프로세스 P & Q (향상)
S/W 개발 생산성은 개발 인력의 능력과 개발 프로세스 수준에 의해 좌우됨 Watts Humphrey 개선 포인트 과거에 소프트웨어 개발에 있어 관심 사항은 품질과 생산성이었습니다. 그러나 품질과 생산성이 개별적으로 관리되어졌습니다. 그러나 오늘날 두 마리의 토끼를 동시에 잡고자 하는 노력들이 이루어졌으며, 그 결과 프로세스에 의한 접근방법에 의해 그 실마리가 풀리게 되었던 것입니다. 소프트웨어 개발의 품질과 생산성은 프로세스의 품질과 프로세스의 능력에 의해 좌우된다는 것입니다. 소프트웨어 프로세스 제품 서비스 요구사항 P & Q (향상)

7 S/W 프로세스 정의 B A D C 프로세스 (Process)
프로세스 - 일정한 목적을 위해 수행되어지는 일의 순서 (IEEE) S/W 프로세스 - 사람들이 S/W 및 관련 산출물을 개발하고 유지 보수하기 위해 사용하는 일련의 활동, 방법, 실무 및 변형(CMM) 프로세스 (Process) 스킬, 교육 및 동기 부여가 되어 있는 인원들 툴과 장비들 작업들의 관계를 정의하는 절차와 방법들 A D C B 과연 프로세스란 무엇입니까? 프로세스는 단순한 절차(Procedure)가 아닙니다. 프로세스는 사람과 절차와 도구의 세트입니다. 따라서 앞으로 프로세스란 용어를 사용하거나 명기하실 때 반드시 사람과 절차와 도구의 세트로서의 개념으로 사용하시기 바랍니다.

8 효과적인 프로세스 프로세스가 효과적이기 위해서는 프로세스의 실제 결과를 예측할 수 있어야 함.(비용, 일정, 품질 등) 프로세스를 따르므로 해서 기대되는 결과를 예측하기 위해서는 프로세스가 명시적으로 정의되고, 관리되고, 예측되고, 통제될 수 있어야 함 Procedures And Methods People 우리들이 어떤 일을 할 때 고민하는 것은 어떻게 이 일을 효과적으로 하며, 효율적으로 수행하는가 하는 문제들을 생각합니다. 효율성(efficiency)은 일 하는 방법을 최적화하여 생산성 있게 일하게 하는 것이며, 효과성(effectiveness)은 어떻게 최선의 목표를 달성할 수 있느냐 하는 문제입니다. 저희들은 이 두 가지가 모두 중요한 과제입니다. 일을 효율적으로 수행해야 하며, 반드시 효과적인 결과를 만들어내야 합니다. 이렇게 하기 위해서는 프로세스를 관리하지 않으면 안됩니다. 관리된다(managing)는 의미가 무엇입니까? 잘 관리되고 있다. 일을 무조건 하도록 시키는 것이 잘 관리되는 것입니까? 일 잘 될 수 있도록 철저한 계획과 준비, 철저한 수행과 통제, 철저한 평가와 피드백이 필요합니다. 프로세스가 잘 이루어지고 있다. 프로세스 수준이 높다는 것은 이러한 조건들이 잘 갖추어져서 이루어질 때를 말합니다. 요구사항 제품 서비스 Process P & Q Tools and Equipments

9 효과적인 프로세스 특성 주요 프로세스 특성 효과적인 프로세스를 위한 환경 수행되는(followed)
프로세스가 일관성 있게 수행될 때만이 효과적이다. 추진되는(enforced) 프로세스가 일관성 있게 추진될 때만이 수행되는 것이다. 모니터링되는(monitored) 프로세스가 일관성 있게 모니터링 되고 평가될 때만이 추진된다. 훈련되는(trained) 프로세스가 훈련 받은 사람에 의해 행해지고, 훈련내용이 적용될 때만이 일관성 있게 수행되는 것이다. 측정되는(measured) 프로세스가 측정되고 측정결과가 프로세스 개선 계획에 피드백 될 때만이 개선될 수 있다. 소유되는(owned) 프로세스가 책임있는 소유권이 있을 때만이 유지보수 될 수 있다. 관리자에 의해 뚜렷하게 지원되는(visibly supported by management) 프로세스가 시니어 관리자에 의해 뚜렷하게 지원될 때만이 비즈니스 목표로 조절될 수 있다. 스탭 인센티브가 프로세스 목표로 조절되는(Staff incentives are aligned with process goals) 팀원 생산성 측정과 인센티브가 프로세스 수행능력에 의할 때만이 팀원 활동은 조절된다. 새 스탭은 프로세스상에서 적절하게 훈련되는(New staff are properly trained in the process) 프로세스에 대한 초기 훈련이 일관성 있게 새 스탭에 공급될 때만이 프로세스 수준은 저하되지 않는다. 만약에 스탭이 그런 훈련을 받지 못하면, 그들 자신의 방법으로 활동을 행하게 된다. 스탭의 피드백은 프로세스 개선을 촉진하고, 분석하고, 이끄는(Staff feedback is encouraged and analysed and leads to process improvement) 스탭은 프로세스가 그들에게 작업을 도와주는 방법에 대한 피드백을 주고, 그러한 피드백이 프로세스 개선 활동으로 바뀔 때만이 프로세스는 효과성이 증대된다 프로세스는 기술에 의해 충분하게 지원되는(The process is adequately supported by technology) 기술적 인프라와 도구는 프로세스 활동과 프로세스 모니터링과 피드백을 지원하기 위해 선택된다

10 소프트웨어 프로세스 환경 (ISO/IEC 15504 Part 1) (ISO/IEC 15504 Part 9) 프로세스 환경
인프라 개선 로드맵 개선 계획 평가 방법 환경 (ISO/IEC Part 1) 프로세스 환경 소프트웨어 인프라 (ISO/IEC Part 2) 프로세스 개선계획 (ISO/IEC Part 7) 평가 (ISO/IEC 15504 Part 3,4,6,8) 프로세스 개선 로드맵 (ISO/IEC Part 5) (ISO/IEC Part 9)

11 소프트웨어 프로세스 환경 소프트웨어 프로세스 개선 로드맵 소프트웨어 프로세스 평가 소프트웨어 프로세스 개선 계획 1 2 3
소프트웨어 프로세스를 특성화하는 모델 효과적인 소프트웨어 프로세스 구현을 위한 논리적이고 단계적인 접근법 로드맵은 현단계에서 목표 단계로 갈 수 있는 지도 ‘어디에 있는지 알지 못하면, 어디로도 갈 수 없다’ - 중국속담 조직의 현 소프트웨어 프로세스, 활동, 인프라의 수준을 평가하는 방법이나 기술 프로세스 개선 로드맵을 기반으로 함 평가 결과는 프로세스의 효과성을 개선하기 위한 강점과 약점으로 제언 ‘어디에 있는지 모르면, 지도도 소용없다.’ - 험프리 프로세스 평가 결과인 약점을 극복하고자 하는 계획을 수립 조직적/관리적 인프라와 기술적 인프라를 향상시키고자 함

12 효과적인 프로세스 환경 효과적인 프로세스 프로세스의 내재적 제도화 효과적인 프로세스 조건 프로세스 문화 프로세스 기반구조
오너쉽 프로세스 훈련 프로세스 결과의 측정과 피드백 프로세스 사용자로 부터의 피드백 외부 환경 에서의 피드백 추진과 점검 메카니즘 효과적인 프로세스 조건

13 프로세스 성숙도(Process Maturity)
특정 프로세스가 명시적으로 정의되고, 관리되고, 측정되고, 통제되고, 효과적인 정도. 성숙도가 높아짐에 따라 프로세스의 안정성과 변동의 예측가능성이 높아지므로 프로세스 능력이 향상됨. 신뢰할 수 있는 생산성과 품질로 고객만족을 가져올 수 있음. - 정확한 예측으로 비용과 위험을 감소시킬 수 있음. 성숙된 프로세스는 고도의 프로세스를 말합니다. 고도의 프로세스는 프로세스가 효율적을 잘 수행되어지고 있으며, 효과적인 결과를 잘 만들어 낼 수 있는 프로세스를 말합니다. 즉, 잘 관리되고 있는 안정된 프로세스를 의미합니다. 따라서 프로세스 성숙도는 프로세스 수행 능력과 프로세스 성과를 동시에 포함하는 개념입니다. 단, 프로세스는 개인의 능력과 성과를 의미하지는 않습니다. 프로세스 능력 프로세스 성과

14 프로세스 능력의 진화와 성과 5 4 3 2 1 단계 프로세스 특징 예상되는 성과 프로세스 개선을 제도화함
최적화 프로세스 개선을 제도화함 4 관리됨 제품과 프로세스를 정량적으로 통제함 S/W 엔지니어링과 관리 프로세스를 정의(표준화)하고 통합함 3 정의됨 단계별 성숙도에 따라 그 능력의 특징들이 정의되어 있습니다. 1단계는 결과를 예측할 수 없는 단계이며, 사람에 의해 결과가 좌지우지되는 단계를 말합니다. 2단계는 비슷한 결과들이 예측되고 반복되어지는 경험 많은 조직입니다. 관리는 되고 있으나 이 것이 내재화되고 표준화된 프로세스에 의한 관리가 아닌 것입니다. 마찬가지고 사람의 경험이 노하우가 되어 관리는 되고 있으나 공유할 수 있는 경험과 지식이 아닌 것입니다. 현재의 신한이 이러한 단계의 모습을 보이고 있습니다. 이 단계에서는 능력있고 경험많은 관리자가 빠져나가면 다시 1단계의 수준으로 되돌아 갈 수 밖에 없는 조직입니다. 능력이 조직화되어 조직에 내재화되어 있어야 합니다. 3단계는 프로세스가 표준화되고 잘 정의되어 있으며, 잘 수행되고 있습니다. 그러나 이 프로세스가 관리되거나 통제되지 않은 단계입니다. 4단계는 프로세스가 관리되고 통제되는 단계입니다. 관리되고 통제되기 위해서는 측정되거나 평가되어 그 결과를 데이터로 관리하고 있어야 합니다. 프로세스 수행 결과에 대한 데이터를 수집하고 분석하여 결과를 피드백할 수 있는 단계입니다. 5단계는 지속적인 프로세스 개선에 의해 최적의 프로세스를 갖추고 있는 단계를 말합니다. 프로세스에 관련된 조직(인력), 제도, 인프라 등이 최적화되어 있는 상태입니다. 오른쪽 그림을 보면 약간의 차이점이 발견될 수가 있습니다. 1단계는 목표를 제대로 못 맞추는 모습이며, 2 단계는 비슷하게 맞추기는 하지만 시행착오가 많은 단계입니다. 3단계부터는 목표에 대한 정확도가 높으면서 점점 납기가 짧아지는 모습을 볼 수 있습니다. 그 만큼 생산성이 높아지는 것을 볼 수 있습니다. 2 반복 프로젝트 관리는 되고 있으며, 성능이 반복적임 1 초기 프로세스가 비공식적이고 예측할 수 없음

15 프로세스 성숙 수준의 Benefits Level Outcome Optimizing Productivity & Quality
Managed Defined Repeatable Initial Productivity & Quality Risk 조직이 성숙될 수록 생산성과 품질은 좋아지고 리스크는 적어진다는 것입니다.

16 Characteristics of an Immature Organization
Software Processes Improvised Existing Software Processes Not Enforced Managers are Reactionary Deliverables not Compliant Schedules and Budgets Routinely Exceeded 미성숙된 조직의 특성은 첫째, 기존 소프트웨어 프로세스들이 강조되지 않은 조직입니다. 둘째, 소프트웨어 프로세스들이 즉흥적으로 이루어지는 조직입니다. 셋째, 관리자들은 문제해결에만 급급한 조직입니다. (계획, 예측, 관리가 안됨) 넷째, 납기가 지켜지지 않은 조직입니다. 다섯째, 제품에 대한 품질이 예측되지 않는 조직입니다. 여섯째, 일정과 예산이 언제나 초과하는 조직입니다. 일곱째, 검토와 테스트가 흔히 무시되어지는 조직입니다. Reviews and Testing Often Shortchanged Product Quality Difficult to Predict

17 Characteristics of a Mature Organization
Defined, Mandated Practices Estimating Systems Software Policies Schedules and Budgets Based on Historical Performance Activities Follow Processes Communicated to Employees 성숙된 조직의 특성은 다음과 같습니다. 1) 정책과 방침이 수립되어 있고 2) 의사소통이 잘 되고 3) 실제 활동들은 프로세스를 잘 준수하고 있으며 4) 일정과 예산은 과거의 경험치에 의해 잘 수립되어지며 5) 관리자들은 방침과 프로세스를 강조하고 있으며 6) 관리자들은 제품 품질과 상태를 모니터링(감시)하고 있으며 7) 관리자들은 고객 만족 (사용자 만족)을 지속적으로 모니터링(감시)하고 있는 조직입니다. Managers Monitor Customer Satisfaction Managers Enforce Policies and Processes Managers Monitor Product Quality and Status Customer Satisfaction Surveys Status Reports SQA

18 Software Process Improvement
ACT PLAN CHECK DO AB&I

19 프로세스 개선의 공통점 프로세스 개선의 공통점은
개선의 초점은 사람의 잘못을 꾸짖는 것이 아닌 프로세스의 결점을 찾아 고치는 데 있음. 개선은 반드시 측정되어야 하고 정기적으로 보강해야 함. 개선은 일관된 투자와 보상, incentive를 필요로 함. 개선은 지속적인 프로세스임. 어느 정도 이상 불편함을 느끼지 못한다면, 변화되지 않음. 프로세스 개선의 공통점은 다음과 같습니다. 프로세스 개선은 사람이 아니라 프로세스 그 자체입니다. (조직을 개선하고 인력을 조정하고 하는 것이 초점이 아닙니다.) 개선은 반드시 측정되어 현재의 수준을 파악하고 있어야 합니다. 저희들은 신한 조직에 대한 수준 평가 결과를 가지고 있습니다. 개선하기 위해선는 반드시 시간과 돈이 필요합니다. 따라서 일관된 투자가 보장되어야 합니다. 보상되지 않으면 움직이지 않습니다. 보상과 벌이 함께 이루어져야 합니다. 지속적으로 이루어져야 합니다. 프로세스에 대한 일관된 신념과 마인드가 필요합니다. 개선의 동기는 불편해야 합니다. 그런데 현 조직과 조직원들은 현상에 젖어 있어 불편함을 느끼지 못하고 있을 수 있습니다. 언제나 그랬듯이 쉽지 않을거야, 내가 어떻게 해, 경영자가 움직여야지, 잘못 내가 나섯다간 욕만 얻어먹지…. 맞습니다. 그렇습니다. 그러니까 저희들이 필요하죠…컨설팅과 컨설턴트………

20 조직의 Vision&Goal & Strategy과 연계
Business Software SPI Vision Vision Vision Support Support Strategy Strategy Strategy 프로세스 개선의 공통점은 다음과 같습니다. 프로세스 개선은 사람이 아니라 프로세스 그 자체입니다. (조직을 개선하고 인력을 조정하고 하는 것이 초점이 아닙니다.) 개선은 반드시 측정되어 현재의 수준을 파악하고 있어야 합니다. 저희들은 신한 조직에 대한 수준 평가 결과를 가지고 있습니다. 개선하기 위해선는 반드시 시간과 돈이 필요합니다. 따라서 일관된 투자가 보장되어야 합니다. 보상되지 않으면 움직이지 않습니다. 보상과 벌이 함께 이루어져야 합니다. 지속적으로 이루어져야 합니다. 프로세스에 대한 일관된 신념과 마인드가 필요합니다. 개선의 동기는 불편해야 합니다. 그런데 현 조직과 조직원들은 현상에 젖어 있어 불편함을 느끼지 못하고 있을 수 있습니다. 언제나 그랬듯이 쉽지 않을거야, 내가 어떻게 해, 경영자가 움직여야지, 잘못 내가 나섯다간 욕만 얻어먹지…. 맞습니다. 그렇습니다. 그러니까 저희들이 필요하죠…컨설팅과 컨설턴트……… Technical Plans Technical Plans Technical Plans

21 효과적인 프로세스 개선 활동 소유권 프로세스 개선과 기술적 진보 훈련 결과와 피드백의 측정 프로세스 사용자와 활동과
도구들 프로세스 사용자와 프로젝트 관리자에 의한 피드백 결과와 피드백의 측정 프로세스 개선의 공통점은 다음과 같습니다. 프로세스 개선은 사람이 아니라 프로세스 그 자체입니다. (조직을 개선하고 인력을 조정하고 하는 것이 초점이 아닙니다.) 개선은 반드시 측정되어 현재의 수준을 파악하고 있어야 합니다. 저희들은 신한 조직에 대한 수준 평가 결과를 가지고 있습니다. 개선하기 위해선는 반드시 시간과 돈이 필요합니다. 따라서 일관된 투자가 보장되어야 합니다. 보상되지 않으면 움직이지 않습니다. 보상과 벌이 함께 이루어져야 합니다. 지속적으로 이루어져야 합니다. 프로세스에 대한 일관된 신념과 마인드가 필요합니다. 개선의 동기는 불편해야 합니다. 그런데 현 조직과 조직원들은 현상에 젖어 있어 불편함을 느끼지 못하고 있을 수 있습니다. 언제나 그랬듯이 쉽지 않을거야, 내가 어떻게 해, 경영자가 움직여야지, 잘못 내가 나섯다간 욕만 얻어먹지…. 맞습니다. 그렇습니다. 그러니까 저희들이 필요하죠…컨설팅과 컨설턴트………

22 관리(Management) 프로세스 소프트웨어 프로세스 개선은 구조화된 프레임워크 내에서 적용되고,
조정되었을 때만 실현이 가능함. 이러한 프레임워크는 소프트웨어 프로세스 개선이 조직되고, 계획되고, 측정되며, 모든 프로세스 개선 활동에 대한 관리적 검토가 수행되는 것을 말함 프로세스 개선을 위한 조직 구성 프로세스 개선을 위한 계획 프로세스 개선의 측정 프로세스 개선 활동의 검토

23 프로세스 개선을 위한 조직 구성 효율적 수행을 위해서는 전 조직이 포함되어야 함 역할에 따른 책임의 구분
상위 경영자(senior management) 프로세스 개선 프로그램 담당(process improvement program) 프로세스 개선 프로젝트 담당(process improvement project) 프로세스 담당자(process owner) 조직 단위(organizational unit) 실제 조직에서는 책임들이 명확히 구분되지 않고 여러 조직 부분이나 개인들에 걸쳐져 있음

24 프로세스 개선을 위한 조직 활동 중역 후원자 소프트웨어 PIT #4 소프트웨어 PIT #4 소프트웨어 PIT #4 소프트웨어
운영위원회 (EIT) 프로세스 자산에 훈련 협조 접근 전체적 자원 전략 새로운 기술, 프로세스, 가이드라인, 전문성 피드백 개선 실행에 피드백 (SEPG) 소프트웨어 프로세스 엔지니어링 그룹 프로젝트 #4 프로젝트 #3 프로젝트 #2 프로젝트 #1 피드백 피드백 피드백 피드백

25 [참고] IDEAL 모델의 프로세스 개선 기반 조직
MSG (Management Steering Group) 조직 내용 역할 활동 SEPG Software Process Engineering Group TWG (Technical Working Group) -조직의 최상위 관리층을 대표 하는 팀으로서 조직의SPI 이행 활동을 지도 -SPI 프로그램의 목표를 수립 하고 방향 및 우선 순위를 결정 -SPI 전략 활동 계획을 승인 -TWG를 수립 -TWG 강령의 초안 작성 -전술 활동 계획 초안 작성 -매월 모임(2-4시간) -평가 활동의 결과 검토 -자원을 배정 -작업 그룹의 진척을 감독 -시범 적용 활동의 결과에 따라 개선을 확대 승인 -진척사항을 경영진에 보고 -SPI에 관련된 활동, 즉 활동 계획 수립, 프로세스 개선, 기술 개선 및 다른 활동들에 대한 책임을 가지고 조정 -전반적 SPI 활동에 대해 조직이 지속적으로 알 수 있게 하며, 개선 활동의 성공적인 완수를 보장하기 위해 조정자의 역할 -주간 회의를 갖음 -개선 활동을 파악하고 MAG에 권고 -개선의 진척을 추적하고 MSG에 보고 -개선의 효과성을 판단 -프로세스 데이타베이스를 개발하고 유지 -교육 계획을 세우고 교육을 준비 -프로젝트에 자문을 제공 -CBA-IPI를 조정 -MSG 회의를 조정 -SPI 프로그램의 해결안 개발자 -자신이 평가하고 개선하도록 부여된 프로세스를 개선 -프로세스 오너가 리더가 된다. -문제점을 연구하고 해결안을 파악 -해결안 작성 -선택된 해결안에 맞도록 전술 활동 계획을 수정 -가능한 해결안들과 그 중 권고 하는 해결안을 MSG에 발표 -최초 Prototype 그룹 선택 -Prototyping 실시 -Prototype 결과를 평가 -Prototype의 경험에 따라 전술 활동 계획을 수정

26 프로세스 개선을 위한 인프라 소프트웨어 프로세스 인프라의 두 가지 측면 조직 및 경영 인프라 기술 및 도구 인프라
효과적인 인프라의 요건 프로세스 오너십에 대한 R&R 프로세스 훈련과 지식 전파를 위한 R&R 프로세스 표준의 정착을 위한 절차의 추진 프로세스 성과에 대한 피드백 데이터의 수집과 분석을 위한 피드백 메커니즘 위와 같은 역할과 절차를 가증하도록 지원하기 위한 도구와 기술

27 프로세스 개선을 위한 인프라 조직적/관리적 인프라 기술적 인프라 중역 기업 후원자 운영 위원회 기업 SEPG 프로젝트 #1
프로젝트 #2 프로젝트 #3 프로젝트 #4 소프트웨어 프로세스 개선팀 #1 소프트웨어 프로세스 개선팀 #2 소프트웨어 프로세스 개선팀 #3 소프트웨어 프로세스 개선팀 #4 기업 SEPG 중역 기업 후원자 운영 위원회 조직 표준 소프트웨어 프로세스를 위한 데이터와 문서 저장 그리고 추출 도구 특정 프로젝트 맞춤 추출과 의사결정 지원 도구 프로젝트 정의 소프트웨어 프로세스를 위한 측정과 피드백 도구

28 조직적/관리적 인프라 경영진 조정 위원회 경영진 조정 위원회 소프트웨어 프로세스 개선팀(PIT) #1
소프트웨어 프로세스 개선팀(PIT) #N 프로젝트 #1 프로젝트 #2 프로젝트 #3 프로젝트 #4 전사 SEPG 경영진 조정 위원회 요구사항 관리 PIT 프로젝트 계획 및 추적 PIT 소프트웨어 품질보증 PIT 소프트웨어 형상관리 PIT 프로젝트 #1 프로젝트 #2 프로젝트t #3 프로젝트 #4 전사 SEPG 경영진 조정 위원회

29 기술적 인프라 조직 및 경영 프로세스 역할 프로세스 지원 도구 기업의 소프트웨어 프로세스 자산 프로세스 기술 인프라 활용
접근과 갱신 프로세스 기술 인프라 전사 표준 소프트웨어를 위한 기술적 인프라 프로젝트별 소프트웨어 프로세스를 프로세스 특성별 조정 검색 및 의사결정 도구 자료와 문서저장/검색 도구 측정 및 피드백 도구

30 프로세스 인프라의 조직별 수준 조직 수준 프로세스 유형 주요 목표 전사 수준 기업표준 프로세스 일관성 프로젝트/팀 수준
정의 프로세스 효과성 개인 수준 개인별 소프트웨어 프로세스 성과

31 프로세스 개선의 측정 프로세스 측정 Framework 조직의 요구 분석 선택 사용 검증에 사용 표현에 사용 현 상태 측정 비교
소프트웨어 프로세스 목표 선택 Metrics 사용 검증에 사용 표현에 사용 현 상태 측정 목표치 개선 결과 비교 기준점 달성을 위해 출발점 만들어 짐 개선 활동

32 프로세스 개선의 성공을 위한 조건 Top 10 Reasons Why SPI Fails(2)
- Herb Krasner:Austin Professional SPI coach Can't agree on the nature and severity of the problems. Don't know enough about the basics(TQM,SPI,software engineering). No long-term committed leadership. Bad attitudes(fear of change, NIH,software cowboy culture). Not skilled in cultural change. No clear vision of the desired results. No concrete action plan(Ready! Fire! Aim!). No quantitative feedback on progress. SPICE/CMM applied incorrectly. Too many organizational learning disabilities. SPI 실패 원이 10가지 1) 문제를 심각하게 받아들이지 않는다. 2) 기본적인 개념이 없다. 3) 장기적인 경영자 의지와 지원이 없다. 4) 변화를 두려워하는 조직문화 5) 조직 문화 변화에 대한 경험이 미숙 6) SPI에 대한 분명한 비전이 없다. 7) 확고한 실행 계획이 없다. 8) 진행 상에 계량적인 피드백 시스템이 없음. 9) SPICE 및 CMM이 부정확하게 적용되었다. 10) 너무 많은 조직적 학습의 장애 요인들이 존재한다.

33 [참고] 프로세스 개선 Guidance - SPICE SPI
조직의 소프트웨어 프로세스 개선 - 조직의 요구 - 프로세스 개선 요구 1. 조직의 요구 파악 확인된 개선 결과 개선의 제도화 7. 개선 성과의 유지 8. 성과 모니터링 6. 개선 확인 범위와 우선 순위 결정 개선 착수 수행후의 개선 상태 재심사 결과 분석 재심사 요청 예비 프로세스 개선 프로그램계획 2. 프로세스 개선 착수 승인된 활동 항목 5.개선 활동 수행 심사 결과 4. 결과 분석 및 활동계획 도출 3. 프로세스 심사 준비와 수행 심사 요청 프로세스 개선 프로그램 계획 - 산업 벤치마크 - BP 또는 MP 현재의 능력 상태 목표 능력 프로파일

34 [참고] 프로세스 개선 Guidance - IDEAL Model
Learning Acting 경험을 문서화하고 분석 프로세스와 측정치 정의 조직적 접근방법 재조정 파일럿 계획 및 실행 구현 계획, 실행,추적 프로세스 실행 팀 구성 개선에 대한 자극 대상 선정 및 지원 체계 구축 개선을 위한 기반 구조 구축 Initiating 실행계획 수립 현재 프로세스 평가 전략과 우선순위 수립 개선 계획 수립 Establishing Diagnosing

35 [참고] 프로세스 개선 Guidance - PDCA
ACT PLAN 1 단계: 기반 조직 구성 2 단계: SPI 목표 설정 3 단계: SPI 접근 방법 개발 4 단계: 관리자 승인 획득 10 단계: 개선결과를 다른 프로젝트에 전파 5 단계: 프로세스 심사 수행 및 강.약점 파악 6 단계: 시정 활동 결정 및 개선 계획 수립 7 단계: 개선안 이행 9 단계: SPI 활동 검토 8 단계: 진척, 문제점, 이슈 보고 CHECK DO

36 SPI CASE STUDY 1 2 3 AB&I

37 SPI CASE STUDY 본 내용은 특정 기업과 관련될 수 있으므로 게재하지 않습니다.

38 Q & A


Download ppt "(Software Process Improvement & Case)"

Similar presentations


Ads by Google