1 / 38

소프트웨어 프로세스 개선 및 적용 사례 (Software Process Improvement & Case)

소프트웨어 프로세스 개선 및 적용 사례 (Software Process Improvement & Case). 2002 년 6 월 1 일 편 흥 열 박사 에이비앤아이㈜. 목 차. Software Process Maturity : An Introduction ----------------------------------------------3 Software Process Improvement --------------------------18

Télécharger la présentation

소프트웨어 프로세스 개선 및 적용 사례 (Software Process Improvement & Case)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 소프트웨어 프로세스 개선 및 적용 사례 (Software Process Improvement & Case) 2002년 6월 1일 편 흥 열 박사 에이비앤아이㈜

  2. 목 차 • Software Process Maturity :An Introduction ----------------------------------------------3 • Software Process Improvement --------------------------18 • CASE STUDY ---------------------------------------------36

  3. B A D C Process Software Process Maturity :An Introduction

  4. S/W 산업의 문제점 Computer Channal Inc., 1993 Standish Group 1994, 8,380 Proj. • 15%의 프로젝트들은 전혀 인도되지 못했음. • 소프트웨어 프로젝트들의 50% 이상은 납기 • 지연 • 비용은 항상 100% 이상 추가적으로 발생 • 했음. • 품질, 납기, 비용을 충족한 프로젝트 • 비율은 16.2%에 불가함. • 재작업 없이 프로젝트를 완료는 것은 • 6%에 불가함. 낮은 생산성 낮은 품질 개발 지연 소프트웨어 결함 비용 초과 사용자 불만 사업 기회 상실 이익 감소

  5. 품질활동(QA) Factory 최종 제품 원재료 P & Q(안정화) 품질활동(QA) H/W 제조 프로세스 • 최종 제품이 생산되기까지 많은 검사와 제조 프로세스의 통제를 통해 품질을 보증함. • 프로세스의 최종 단계까지 문제점이 발견되지 않은 채 문제가 더욱 악화 되는 것을 허용하지 않으며, 품질 측정을 통해 결함이 있는 제품이 대량 생산되기 전에 결함이 있는 프로세스는 변경되어 짐. 출처 : Schulmeyer, Zero Defect Software

  6. S/W 개발은 무엇이 문제인가? • S/W 품질은 그것을 개발하고 유지보수 하는 데 사용된 프로세스의 품질에 의해 좌우됨. • S/W 개발 생산성은 개발 인력의 능력과 개발 프로세스 수준에 의해 좌우됨. - Watts Humphrey 개선 포인트 소프트웨어 프로세스 제품 서비스 요구사항 P & Q(향상)

  7. B 작업들의 관계를 정의하는 절차와 방법들 A D C 프로세스 (Process) 스킬, 교육 및 동기 부여가 되어 있는 인원들 툴과 장비들 S/W 프로세스 정의 • 프로세스 - 일정한 목적을 위해 수행되어지는 일의 순서 (IEEE) • S/W 프로세스 -사람들이 S/W 및 관련 산출물을 개발하고 유지 보수하기 위해 사용하는 일련의 활동, 방법, 실무 및 변형(CMM)

  8. 효과적인 프로세스 • 프로세스가 효과적이기 위해서는 프로세스의 실제 결과를 예측할 수 있어야 함.(비용, 일정, 품질 등) • 프로세스를 따르므로 해서 기대되는 결과를 예측하기 위해서는 프로세스가 명시적으로 정의되고, 관리되고, 예측되고, 통제될 수 있어야 함 Procedures And Methods People 제품 서비스 요구사항 Process P & Q Tools and Equipments

  9. 효과적인 프로세스 특성

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

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

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

  13. 프로세스 성숙도(Process Maturity) • 특정 프로세스가 명시적으로 정의되고, 관리되고, 측정되고, 통제되고, 효과적인 정도. • 성숙도가 높아짐에 따라 프로세스의 안정성과 변동의 예측가능성이 높아지므로 프로세스 능력이 향상됨. • 신뢰할 수 있는 생산성과 품질로 • 고객만족을 가져올 수 있음. • - 정확한 예측으로 비용과 위험을 • 감소시킬 수 있음. 프로세스 능력 프로세스 성과

  14. 프로세스 능력의 진화와 성과 단계 프로세스 특징 예상되는 성과 5 최적화 프로세스 개선을 제도화함 4 제품과 프로세스를 정량적으로 통제함 관리됨 S/W 엔지니어링과 관리 프로세스를 정의(표준화)하고 통합함 3 정의됨 프로젝트 관리는 되고 있으며, 성능이 반복적임 2 반복 1 초기 프로세스가 비공식적이고 예측할 수 없음

  15. Optimizing Productivity & Quality Managed Defined Repeatable Risk Initial 프로세스 성숙 수준의 Benefits Level Outcome

  16. Deliverables not Compliant Schedules and Budgets Routinely Exceeded Characteristics of an ImmatureOrganization Software Processes Improvised Existing Software Processes Not Enforced Managers are Reactionary 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 Managers Monitor Customer Satisfaction Managers Enforce Policies and Processes Managers Monitor Product Quality and Status Customer Satisfaction Surveys Status Reports SQA

  18. ACT PLAN DO CHECK Software Process Improvement 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 소프트웨어 PIT #4 운영위원회 (EIT) 프로세스 자산에 훈련 협조 접근 전체적 자원 전략 새로운 기술, 프로세스, 가이드라인, 전문성 피드백 개선 실행에 피드백 (SEPG) 소프트웨어 프로세스 엔지니어링 그룹 프로젝트 #4 프로젝트 #3 프로젝트 #2 프로젝트 #1 피드백 피드백 피드백 피드백

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

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

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

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

  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.

  33. [참고]프로세스 개선 Guidance - SPICESPI 조직의소프트웨어 프로세스개선 - 조직의요구 - 프로세스개선 요구 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. 3 2 1 SPI CASE STUDY AB&I

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

  38. Q & A

More Related