소개

현대의 복잡한 시스템에서 가장 중요한 부분은 소프트웨어 제품인 지적 구성 요소입니다. 소프트웨어 제품은 이제 경제, 사회, 군사 및 기타 영역에서 인간 활동의 거의 모든 영역에서 관리 문제를 해결하는 데 사용됩니다. 보안 고품질국내 소프트웨어 제품 대량 개발국가 및 세계 시장에서 다양한 애플리케이션에 대한 공급이 전략적 목표가 되었습니다.

현재 소프트웨어 엔지니어링 및 소프트웨어 제품 품질 보증에는 거의 독립적인 두 가지 표준화 영역이 있으며 조건부로 ISO(국제 표준 기구) 표준 프로필 및 SEI(미국 소프트웨어 엔지니어링 연구소) 성숙도 모델이라고 할 수 있습니다. 첫 번째 것은 [ , ]로 완전히 표현되고 두 번째 것은 [ , ]에서 완전히 표현됩니다. 이 기사의 주요 내용은 성숙도 모델에 전념합니다.

복잡한 소프트웨어 제품의 세계에서 경쟁력을 확보하고 성공적인 수출 가능성을 보장하려면 요구 사항에 따라 개발 및 인증해야 합니다. 국제 표준 프로필기초에 ISO 9000:2000또는 성숙 모델 - CMMI:2003(능력 성숙도 모델 통합 - 통합 소프트웨어 엔지니어링 성숙도 평가 모델). 이 두 방향은 방법론적으로 매우 가깝고 상호 참조를 통해 부분적으로 교차합니다.

기술 및 경제 지표의 개선과 소프트웨어 제품의 품질뿐만 아니라 오류 및 결함 방지는 다음을 사용하여 보장됩니다. 현대 기술소프트웨어 엔지니어링 및 시스템 컴퓨터 지원 설계. 이는 소프트웨어 도구(PS)의 설계, 구현 및 유지 관리를 위한 총 자원 비용을 줄이는 것을 목표로 하는 고품질, 신뢰성 및 보안의 소프트웨어 컴플렉스를 생성하기 위한 고성능 자원 절약 기술입니다. 이를 위해서는 우선 분석과 설계를 위한 방법과 도구를 적용하여 처음부터 목표, 목적, 기능을 구체화하고 가장 정확하게 표현하는 것이 필요하다. 라이프 사이클(LC) PS의 다음 개발 단계에 가능한 시스템 결함의 확산을 방지합니다. 이러한 소프트웨어 엔지니어링 기술을 사용하면 작동을 위해 전송된 소프트웨어 제품의 시스템, 알고리즘 및 소프트웨어 오류 수준을 제거하거나 크게 줄일 수 있습니다. 또한 PS를 수정하고 유지하는 것은 물론 외부 환경의 변화에도 효과적입니다.

복잡하고 중요한 시스템 사용의 품질, 신뢰성 및 안전성을 인증하기 위해 해당 시스템에 사용되는 소프트웨어 제품은 인증인증된 문제 중심 테스트 센터 또는 실험실. 이러한 테스트는 프로그램이 복잡하고 중요한 프로세스 또는 프로세스 정보의 결함이나 불충분한 품질로 인해 심각한 손상을 초래할 수 있는 매우 중요한 프로세스 정보를 관리할 때 수행해야 합니다. 인증 테스트는 소프트웨어 컴플렉스가 문서의 요구 사항을 준수하는지 확인하고 테스트 중에 연구된 외부 환경 매개변수의 변경 한도 내에서 작동할 수 있도록 해야 합니다. 이러한 유형의 테스트는 검사의 심각도와 깊이가 가장 큰 특징이 있으며 개발자 및 고객(사용자)과 무관한 전문가가 수행해야 합니다.

인증의 근거는 표준화된 고객 요구 사항, 특별히 설계된 테스트 문제 및 생성기, 테스터의 높은 자격 및 권한 준수를 위해 소프트웨어 패키지를 테스트하기 위한 상세하고 효과적인 프로그램 및 방법이어야 합니다. 기업 - 소프트웨어 제품 개발자에 적용, 요구 사항에 따라 PS의 수명 주기 보장을 위한 인증된 품질 시스템 ISO 9000:2000또는 CMMI:2003, 수명 주기의 프로세스 및 제품에 대한 높은 지속 가능한 품질 관리를 보장하고 많은 경우 최종 소프트웨어 제품의 인증을 용이하게 합니다. 따라서 복잡한 소프트웨어 프로젝트의 고객은 조정된 국제 표준 프로필 또는 성숙도 모델을 기반으로 하는 품질 보증 시스템의 적용을 인증하는 인증서가 있는 구현 계약자를 선택하는 경향이 있습니다.

소프트웨어 엔지니어링 방법 교육의 격차는 작업 품질을 평가하는 전문가의 자의성과 소프트웨어 프로젝트의 수많은 결함 및 오류의 출현에 대한 넓은 영역을 남깁니다. 프로그램으로 해결되는 현대적인 작업의 복잡성과 책임이 증가하고 결과의 불충분한 품질로 인한 손상 가능성이 높아짐에 따라 품질 특성 및 측정 방법에 대한 요구 사항에 대한 완전하고 표준화된 설명 방법을 마스터하는 관련성이 크게 높아졌습니다. 소프트웨어 라이프 사이클의 다양한 단계에서 실제 달성된 가치. 전문가가 소프트웨어 제품의 품질 특성을 평가하기 위한 개념, 정의 및 방법을 알아야 할 필요성이 급격히 증가했습니다.

소프트웨어 컴플렉스의 급격한 증가와 복잡성으로 인해 전문 분업이 있는 대규모 프로그래밍 팀이 만들어지고, 이 팀에서는 단일 프로젝트에서 전문가 그룹의 조정된 활동을 규제해야 합니다. 합의된 기간 내에 고품질 소프트웨어를 제공하겠다는 개발자의 약속은 종종 지켜지지 않습니다. 종종 이것은 고객과 계약자가 다른 기준에 따라 품질 수준을 평가하고이 문제에 대해 동의하지 않고 프로그램 품질을 평가하는 접근 방식이 충분히 공식화되지 않았기 때문에 발생합니다. 또한 때로는 고품질 프로그램을 달성하는 데 필요한 자원을 적절하게 평가하는 능력이 부족합니다. 결과적으로 소프트웨어 제품의 품질은 종종 국제 시장에서 낮고 신뢰할 수 없으며 경쟁력이 없습니다. 따라서 많은 개발 및 적용에서 가장 중요한 문제는 현대 시스템소프트웨어 엔지니어링 분야의 전문가 교육 및 교육, 소프트웨어의 고품질에 기여하는 국제 표준 사용 및 주요 목표와 함께 신뢰할 수 있는 평가 - 프로젝트 프로세스 만들기 다루기 쉬운, 그리고 결과는 예측 가능한. 이 품질을 보장하고 개선하는 데 사용할 수 있는 리소스를 고려하여 요구 사항을 공식화하고 복잡한 소프트웨어 패키지의 기능 및 적용 품질 특성의 특정 값을 달성할 수 있어야 합니다.

CMMI 성숙도 모델 - 1.1이전 모델을 개선하고 개선합니다. CMM(참조), 소프트웨어 관리 분야의 기존 국제 표준의 기본 요구 사항도 부분적으로 고려합니다. 에 상당한 관심 CMMI고객 요구 사항, 기능, 구성 요소, 테스트 및 프로젝트 문서에 대한 추적 가능성을 변경할 때 개발 프로세스 및 반복에 대한 설명이 제공됩니다. 최근 2003 버전의 SEI 버전 현대화에 대한 정보가 나타났습니다. CMMI-1.1축적된 경험과 기업의 피드백을 바탕으로 2006년에 출시될 예정이며 상당히 업그레이드된 버전의 모델입니다. CMMI-1.2, 이후 버전 1.1은 단계적으로 제거되어야 합니다. 2007년 말까지 사용자는 버전으로 전환해야 합니다. CMMI-1.2, 그리고 미래에는 소프트웨어 엔지니어링 분야에서 기업 기술의 품질(인증)에 대한 공식 평가를 위해 의무화될 것입니다. 인증서의 유효 기간은 3년으로 제한됩니다. 대규모 소프트웨어 시스템의 고객과 개발자는 SEI에서 버전 1.2를 공식적으로 발표하기 전에 이러한 변경 사항에 대비해야 합니다.

CMMI 성숙도 모델의 구조와 내용 - 1.1

두 가지 모델 옵션 CMMI-1.1제공하도록 설계 마디 없는프로세스의 복잡한 평가 특정 지역소프트웨어를 만들거나 단계적기업의 성숙도를 평가 및 개선하고 일반적으로 프로그램 단지의 수명주기를 구성합니다. 모델 CMMI제품을 구성 및 개선하고 PS 개발 및 유지 관리 프로세스를 간소화하고 서비스하는 데 전문가를 지원합니다. 이러한 모델의 개념은 복잡한 시스템의 성숙도, 소프트웨어 엔지니어링, 통합 소프트웨어 제품 생성 및 개발 개선 프로세스의 관리 및 평가를 포함합니다. 연속 및 단계별 모델의 구성 요소는 대체로 유사하며 특정 프로젝트의 속성 및 특성에 따라 다른 구성 및 사용 순서로 선택 및 적용할 수 있습니다.

모델 설명 옵션은 일반 섹션을 포함하는 단일 구성표에 따라 작성됩니다.

머리말;
1 섹션 - 소개;
섹션 2 - 구성 요소 모델;
섹션 3 - 용어
섹션 4 - 모델의 각 버전(목표 및 절차 개발)의 수준 및 주요 구성 요소의 내용;
섹션 5 - 프로세스 상호 작용의 구조; 섹션 7의 4가지 프로세스 범주, CMMI 프로세스의 일반 개요 및 상호 작용 체계에 주석이 달려 있습니다.
- 공정 관리;
- 관리 - 프로젝트 관리;
- 공학 기술);
- 지원하다;
섹션 6 - 모델 사용 CMMI- 모델 및 교육 적용에 대한 사용자를 위한 간략한 권장 사항 표준의 2부와 3부에서 이전 CMM 모델의 규제된 프로세스와 모델 프로세스의 호환성 및 준수가 표시됩니다. ISO 15504.
섹션 7은 각 표준에서 마지막으로 가장 큰 것으로 전체 문서의 약 500페이지, 즉 700페이지가 넘는다. 이 섹션에서는 특정 모델의 특성을 고려하여 여기에 나열된 각 프로세스의 구현에 대한 자세한 권장 사항을 제공합니다.

첫 번째 옵션(연속) 모델은 문서를 반영합니다. 시스템 엔지니어링/소프트웨어 엔지니어링/통합 제품 및 프로세스 개발을 위한 CMMI(Capability Maturity Model Integration), 버전 1.1, 연속 표현 (CMMI-SE/SW/IPPD, V1.1, 연속). 통합 시스템 엔지니어링/소프트웨어 엔지니어링/통합 제품 및 개발 프로세스 성숙도 평가 모델 - 연속보기. 이 모델에서 일곱 번째 섹션은 프로세스로 구성됩니다.

공정 관리:
- 훈련 조직;
- 프로세스의 변환(변경) 조직;
- 혁신 및 확장 조직화;
프로젝트 관리:
- 프로젝트 계획;
- 프로젝트 프로세스의 모니터링 및 제어;
- 위험 관리;
- 양적 프로젝트 관리;
공학 기술):
- 요구사항 관리;
- 요구사항 개발;
- 기술 솔루션;
- 제품 통합;
- 확인;
- 검증(증명, 승인);
지원하다:
- 구성 관리;
- 변경 사항에 대한 분석 및 의사 결정;
- 근본 원인 분석 및 문제 해결(결함 제거).

5개의 부록은 다음을 제공합니다.

하지만- 사용된 문헌 및 문서의 구성(그러나 표준에 대해서는 언급하지 않음) ISO;

에- 약어;

에서- 용어집 기반 용어 ISO 4가지 표준에서만 사용 ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D - 성숙도에 따른 모델 구성 요소 형성에 대한 요구 사항 및 제안에 대한 설명

E - 개발 참가자 목록 CMMI- 프로젝트.

이 모델에서는 조직 프로세스, 소프트웨어 프로젝트 구현을 위한 프로세스 계획, 관리 및 제어, 소프트웨어 제품에 대한 요구사항 개발 및 관리에 주의를 집중합니다. 다음은 세부 사항의 예입니다. CMMI그들 중 일부.

프로젝트 기획이 모델과 두 번째 모델에는 다음이 포함됩니다.

소프트웨어 제품의 가능한 크기(규모) 평가;
PS 프로젝트의 기능 및 특성의 복잡성 평가;
소프트웨어 패키지 라이프 사이클의 모델 및 단계 정의;
프로젝트의 타당성 조사 - 변전소 수명주기의 비용, 노동 강도 및 기간 결정;
단계별 작업 일정 및 프로젝트 예산 개발;
프로젝트 위험의 분석, 식별 및 평가;
PS 프로젝트의 수명 주기에서 프로세스 및 제품의 문서를 계획하고 관리합니다.
PS 라이프 사이클의 단계에 따른 기술 및 인적 자원의 계획 및 배포;
프로젝트 구현을 위한 전문가 팀의 지식 및 자격 제공 계획;
PS 프로젝트 계획 세트의 일반화 및 분석;
PS 프로젝트의 고객과 개발자가 라이프 사이클 단계에 대한 작업 및 리소스 조정;
작업 계획 및 프로젝트 개발자 관리자의 승인을 문서화합니다.

요구사항 개발 프로세스소프트웨어 제품에 대한 프로세스는 두 모델의 프로세스와 유사하며 다음을 포함합니다.

소프트웨어 제품의 기능 및 특성에 대한 고객 및 사용자의 실제 요구 식별
소프트웨어 제품 기능에 대한 초기 기본 요구 사항의 고객과 개발자 간의 개발 및 조정
소프트웨어 제품군 프로젝트의 사용 가능한 리소스 및 제한 사항 결정
PS 기능에 대한 기본 초기 요구 사항을 소프트웨어 패키지의 구성 요소 및 테스트에 대한 요구 사항 집합으로 분해합니다.
운영 및 외부 환경과 함께 구성 요소 간의 인터페이스에 대한 요구 사항의 공식화
소프트웨어 제품의 개념 및 사용 시나리오의 개발
기능적 적합성의 일반화된 특성 및 의도된 목적을 위한 소프트웨어 제품의 기능 사용에 대한 요구사항 개발.

요구사항 관리두 모델에는 다음이 포함됩니다.

고객과 개발자가 PS 프로젝트에 대한 요구 사항을 명확하게 이해합니다.
소프트웨어 제품에 대한 모든 요구 사항을 충족할 의무를 개발자로부터 고객이 얻습니다.
고객과 개발자 간에 합의된 PS 프로젝트에 대한 요구 사항 변경 관리;
PS 프로젝트에 대한 일반 요구 사항에서 구성 요소 및 특정 프로세스에 대한 요구 사항에 대한 변경 사항의 정확성을 보장합니다.
프로젝트 개발 프로세스와 고객 요구 사항 간의 불일치를 식별하고 식별합니다.

두 번째 옵션문서를 제시합니다: 시스템 엔지니어링/소프트웨어 엔지니어링/통합 제품 및 프로세스 개발을 위한 CMMI(Capability Maturity Model Integration), 버전 1.1, 단계적 표현 (CMMI-SE/SW/IPPD, V1.1, 단계적). 통합 시스템 엔지니어링/소프트웨어 엔지니어링/통합 제품 및 개발 프로세스 성숙도 평가 모델 - 단계적 도입. 이 모델은 5단계 성숙도 개념을 유지하는 데 기반을 두고 있습니다. CMM[ , ]. 프로세스의 구성은 모델의 첫 번째 버전에 대해 위에 제공된 것과 실질적으로 반복되지만 약간 다른 순서로 비교적 적은 추가가 추가됩니다.

첫 번째 수준다양한 비교적 간단한 프로젝트에서 프로세스의 구성과 내용에 상당한 불확실성이 있는 것이 특징이므로 문서에서 설명하지 않습니다. 따라서 단계적 버전에서 프로세스의 내용을 명확하고 자세히 설명할 때 CMMI제한하는 것이 좋습니다 네 가지 주요 수준:

두 번째 수준- 공식화하다 기본 관리프로젝트:
- 요구사항 관리;
- 프로젝트 계획;
- 프로젝트 모니터링 및 제어;
- 공급업체와의 계약 관리;
- 프로세스 및 제품의 측정 및 분석;
- 프로세스 및 제품의 품질 보장;
- 구성 관리;
세 번째 수준- 주요 프로세스의 표준화를 포함합니다.
- 요구사항 개발;
- 기술 솔루션;
- 제품 통합;
- 확인;
- 검증(인증);
- 조직 프로세스의 내용;
- 조직 프로세스의 정의;
- 훈련 조직;
- 프로젝트 프로세스 및 제품의 통합 관리;
- 위험 관리;
- 개발 팀의 통합;
- 통합 공급업체 관리;
- 문제 분석 및 해결(결함 제거);
- 통합을 위한 환경 구성;
네 번째 수준- 정량적 관리를 정의합니다.
- 프로세스 품질의 대표 조직;
- 전체 프로젝트 및 자원의 양적 관리;
다섯 번째 수준- 최적화, 지속적인 개선:
- 조직, 혁신, 프로세스의 양적 관리 및 자원 제공;
- 불량원인분석, 품질개선, 공정 및 제품관리

모델의 두 번째 버전에 있는 응용 프로그램은 구성이 첫 번째 모델에 대한 위의 응용 프로그램과 유사합니다. 각각의 높은 성숙도에서 신청하는 것이 좋습니다. 모든 프로세스이전 낮은 수준. 모델의 두 버전에서 위에 강조 표시된 각 기본 프로세스는 구조적으로 통합된 약 20-30페이지에 대한 설명이 포함된 실제 구현에 대한 자세한 권장 사항과 함께 주석 처리됩니다.

달성할 프로세스의 전반적인 목표;
프로세스 기능에 대한 소개 및 일반적인 설명;
특정 프로세스 목표;
공정 관리;
프로세스 요구 사항 개발;
다른 프로세스와의 상호 작용 및 인터페이스
실제 목표 - 프로세스 활동의 필요한 결과;
특정 프로세스에서 계획 작업;
프로세스 구현 결과의 분석 및 검증(승인);
프로세스의 모니터링 및 제어.

기본 프로세스에 대한 설명의 범위, 내용 및 완전성 측면에서 이러한 권장 사항은 에 제시된 PS 수명 주기 프로필에 대한 여러 표준과 유사합니다. 성숙도에 따라 사용되는 프로세스의 완성도를 주문하고 평가하면 예측된 프로세스 품질 및 활동 결과 및 인증 준비 측면에서 소프트웨어 제품 개발자인 기업의 생산 잠재력을 설정할 수 있습니다. 특정 수준의 모델 성숙도 준수 CMMI - 1.1.

모델 강조 CMMI PS 프로젝트의 관리 프로세스에 부여됩니다. 모델의 이러한 요구 사항 및 프로세스는 실제로 표준의 규제되고 세부적인 권장 사항에 해당합니다. ISO 9001:2000및 복잡한 PS 수명 주기 표준의 프로필의 주요 구성 요소 [ , ]. 표준의 기능 섹션 4-8에 있는 프로세스 요구 사항 ISO 9001, ISO 9004, ISO 90003내용에 적절한 섹션의 수는 모델에서 비교할 수 있습니다. CMMI(그림 1에서 콘텐츠 중첩 영역). 프로세스 및 요구 사항의 공통성은 구성, 용어, 구조, 권장 관리 프로세스 목록, 사용 가능한 리소스에 대한 설명, 소프트웨어 엔지니어링 프로세스 구현, 평가 및 전문가 조직과 같은 유사성으로 구성됩니다.

그림 1. 표준 및 성숙도 모델의 프로세스 및 요구 사항의 공통성

대규모 소프트웨어 프로젝트의 전체 수명 주기를 지원하고 규제한다는 관점에서 모델의 단점은 CMMI기존 표준의 프로필에 관하여 ISO다음을 포함할 수 있습니다.

위에 제시된 PS의 수명 주기를 보장하기 위한 프로세스의 성숙도 수준을 결정하기 위해 1998년에 광범위한 기술 보고서가 개발되고 처음 승인되었습니다. ISO 15504, 아홉 부분과 많은 응용 프로그램으로 구성되어 있습니다. 그것은 성숙 모델을 설명합니다 CMM그리고 여덟 기본 원리들표준에 기반한 소프트웨어 엔지니어링 ISO 9000:2000. 그런 다음 ISO이 문서는 목적과 개념을 완전히 유지하면서 구조와 내용의 근본적인 수정, 축소, 단순화를 거쳤으며 승인되었습니다. 표준으로다섯 부분으로.

기준 ISO 15504:1-5:2003-2006기업이 수행하는 소프트웨어 도구 및 시스템을 생성, 유지 관리 및 개선하는 프로세스의 성숙도에 대한 평가 및 인증을 규제합니다.

자신의 상태를 확립하기 위해 기술 프로세스및 개선 사항;
특정 요구 사항 또는 고객 요구 사항 클래스를 충족하기 위한 자체 프로세스의 적합성을 결정합니다.
성능에 대한 적합성을 고려하여 특정 조약 PS 및 시스템의 고객과 함께.

이 표준은 기업 성숙도에 대한 자체 평가, 인증된 프로세스의 적절한 관리 보장, 프로세스 등급 프로파일 결정, OS 및 시스템의 범위 및 크기에 적합합니다. 표준의 적용은 기업 및 전문가 개발을 목표로 합니다. 지속적인 개선 기술 성숙의 문화프로젝트의 비즈니스 목표를 충족하는 PS의 수명 주기를 보장하고 가용 자원의 사용을 최적화합니다. 엔터프라이즈 프로세스 성숙도 평가는 특정 프로젝트에 선호되는 비교 및 선택 기회를 제공합니다.

고객, 구매자, 소프트웨어 제품 및 시스템 사용자: 공급업체의 수명 주기 프로세스의 현재 및 잠재적 성숙도를 결정할 수 있는 능력;
공급업체 및 개발자: 자체 소프트웨어 및 시스템 수명 주기 프로세스의 현재 및 잠재적 성숙도, 프로세스 개선을 위한 영역 및 우선 순위를 결정할 수 있는 능력;
입학 평가자를 위한: 평가 프로세스를 수행하고 개선하기 위한 프레임워크.

표준의 승인은 다음에서 처리됩니다. 두 가지 측면: 특정 기업의 PS 및 시스템의 수명 주기 프로세스를 개선하고 선언된 프로젝트 또는 기업 지원 프로세스의 성숙도가 사용된 실제 프로세스와 일치하는지 확인합니다. 이것은 표준의 다음 다섯 부분에 반영됩니다. ISO 15504:1-5:2003-2006.

1 부 - 개념과 어휘.소프트웨어 및 시스템의 성숙도 인증 프로세스에 대한 일반 정보와 표준의 일부 사용에 대한 권장 사항이 포함되어 있습니다. 개요 일반적인 요구 사항인증, 용어, 구조에 대해서는 표준의 나머지 부분의 범위가 결정됩니다.

2 부 - 인증의 성능(생산).여기에는 PS 및 시스템의 수명 주기를 보장하기 위한 기술 프로세스의 성숙도 수준을 개선하고 결정하기 위한 기반으로 인증 프로세스를 수행하기 위한 세부 요구 사항이 포함됩니다. 이 문서는 증명을 수행하기 위한 프로세스, 증명을 위한 권장 프로세스 모델을 정의하고 프로세스가 객관적이고 의미 있고 대표되도록 검증합니다.

3부 - 인증제작 안내입니다.성숙도 평가 프로세스를 수행하고 요구 사항 구현을 해석하기 위한 기술의 개요를 제공합니다. 이는 다음을 반영합니다. 인증 성과; 성숙도를 결정하기 위한 측정 도구; 인증 도구의 선택 및 적용; 인증자의 적격성 평가 선언된 요구 사항에 대한 증명의 적합성 검증. 검증 도구는 기업이 소프트웨어 제품 및 시스템을 계획, 관리, 모니터링, 제어 및 개선하고 획득, 개발, 적용 및 유지 관리하는 데 사용할 수 있습니다.

파트 4 - 이 두 가지 측면에서 프로세스 개선 및 프로세스 성숙도를 위한 사용자 지침. 다음을 포함하는 여러 단계가 권장됩니다. 검증 프로세스의 결과를 적용합니다. 성숙도 평가를 위한 목표 설정; 인증을 위한 초기 데이터 결정; 결과적인 위험의 가능한 감소에 대한 평가; 프로세스를 개선하기 위한 단계; 성숙도를 결정하는 단계; 자격 분석 결과를 요구 사항과 비교합니다.

5부 - 2부에 제시된 요구 사항을 준수하기 위한 증명 프로세스의 샘플 모델입니다.광범위한 문서(162페이지)는 다양한 응용 프로그램 영역, 소프트웨어 프로젝트 및 기업에 대한 수명 주기 프로세스 성숙도 평가를 구성, 평가 및 개선하기 위한 표준의 이전 부분에 대한 실용적인 예를 제공합니다.

프로젝트의 실제 구현과 복잡한 소프트웨어의 수명 주기를 보장할 때 개발자와 공급자가 응용 프로그램을 위한 모델의 장점을 식별하고 강조하는 것이 때때로 어렵습니다. CMMI. 기업의 전통과 대규모 프로젝트의 특성에 따라 PS를 주요 전체로 사용하는 것이 좋습니다. 표준 프로필ISO, 그리고 고객 평가를 위해 성숙도 PS 프로젝트의 관리, 조직 및 기술 지원은 특정 권장 사항을 적용합니다. CMMI. 이 지침은 다음에서 효과적으로 사용될 수 있습니다. 공정 품질 인증 PS의 수명 주기를 제공하는 기업에서 대안으로 또는 일련의 관리 표준에 따른 인증과 함께 ISO 9000, 프로젝트의 세부 사항 및 라이프 사이클을 보장하기 위한 소프트웨어 제품 또는 기술 인증 신청자의 요구 사항에 따라 다릅니다.

소프트웨어 제품 인증 조직

인증은 다음을 구성하는 일련의 조직 프로세스로 구성됩니다. 인증 시스템, 이러한 프로세스는 규정된 절차 및 문서에 의해 지원되며 자격을 갖춘 인증된 전문가(검사관)가 수행해야 합니다. 기업 개발자 인증 및 활동 결과 - 소프트웨어 제품, 모델 CMMI또는 표준 프로파일 ISO[ , ] PS의 라이프 사이클 환경과 개체의 특정 특성에 맞게 조정되어야 하는 특정 분야가 권장됩니다. 아래 나열된 프로세스 및 문서는 대규모 프로젝트를 위해 설계되었으며 간단한 경우 개발자, 고객 및 인증자 간의 합의에 의해 축소될 수 있습니다.

인증 작업은 기관 또는 시험소의 인증, 인증의 적절성에 대한 결정을 위해 중앙 인증 기관에 신청서 및 일련의 문서를 작성 및 제출하는 것으로 시작됩니다. 검사 결과가 양성이면 인정 증명서가 작성되어 발급됩니다.

인증기관 또는 시험기관에 관한 규정시험의 인증, 법적 지위, 기능, 구조, 권리와 의무, 방법, 수단 및 조직의 주제 영역을 설정하는 주요 문서입니다. 인증기관(센터)의 여권에는 장비에 대한 정보가 포함되어 있어야 합니다. 컴퓨터 과학테스트에 필요한 인력 및 인력, 테스트 도구가 있는 장비, 규정, 기술 및 방법론 문서 제공 및 테스트에 필요한 기타 리소스.

품질 퀴드원칙에 대한 설명, 인증 기관 또는 실험실의 주요 기능 및 작업 수행과 관련된 방법 및 절차에 대한 설명을 포함하여 테스트의 품질과 평가, 테스트 및 시험 결과에 대한 신뢰를 보장합니다. 품질 매뉴얼에는 일반적으로 [ TWLSC$ 섹션이 포함됩니다.

시험 및 시험의 품질 보증 분야의 정책;
센터에 관련 방법론적 자료와 소프트웨어 및 테스트 도구를 제공합니다.
테스트 개체에 대한 요구 사항의 공식화;
센터의 기술 장비 및 직원 개발 분야의 정책;
인증 결과 문서의 보관 및 안전 관리.

인증 대상 제품 또는 프로세스의 평가를 위해 신청자는 인증 시스템에서 채택한 형식으로 인증 기관에 신청서를 보냅니다. 인증 기관은 신청 시 제품 인증 준비 및 구성 작업을 수행합니다. 이 작업에는 다음이 포함됩니다.

제품의 특성(볼륨, 기술, 규제 문서의 요구 사항 등) 및 개발자 제안을 고려한 인증 체계 선택;
표준에 명시되어 있지 않은 경우 샘플링 및 테스트할 구성 요소의 수와 순서 결정;
시험을 수행할 공인 시험소의 선택 및 식별;
작업 수행을 위한 계약 초안 준비.

인증 작업의 준비 부분은 인증 시스템에서 채택된 형식의 결정 발표로 끝납니다. 결정은 작업 수행에 대한 계약 초안과 함께 신청자에게 전송됩니다. 인증 테스트를 구성 할 때 인증을 위해 선언 된 제품에 대한 현재 규제 문서의 선택 및 연구, 테스트 및 결과 평가 방법이 수행됩니다.

신청자는 주어진 시간 간격으로 인증 중에 검증 대상이 되는 품질 시스템, 영역 및 조직 및 기술 활동 유형의 요소를 최종 결정합니다. 신청자는 확인 절차를 보장하기 위해 조건을 만들고 문서를 제출해야 합니다. 그는 제품 개발 및 생산 중에 수행된 테스트 보고서, 제3자 테스트 연구소에서 수행한 테스트에 대한 문서 및 기술 또는 제품이 설정된 요구 사항을 준수함을 나타내는 기타 문서를 인증 기관에 제출할 수 있습니다. 인증 기관은 애플리케이션과 함께 제품이 확립된 요구 사항을 준수한다는 문서화된 증거 분석을 기반으로 테스트 범위를 축소하거나 인증서를 발급하기로 결정할 수 있습니다.

테스트는 규제, 인증 문서에 제공된 테스트만 수행하도록 인증된 테스트 연구소에서 수행합니다. 인가된 시험소의 시험시설에서 시험을 수행할 수 없는 경우에는 시험소의 자체 시설 또는 공급자가 제공하는 시험 시설을 이용하여 본 제품의 제조자 또는 소비자에서 본 시험소의 직원이 시험을 수행할 수 있다. .

소프트웨어 제품 및 엔터프라이즈 품질 시스템 인증 프로세스에는 다음이 포함됩니다.

이 분야에서 유능한 기관과 인증 테스트를 수행하기 위해 인증된 실험실의 개발자 또는 고객(신청자)에 의한 분석 및 선택;
신청자가 인증 기관에 테스트 신청을 제출하고 신청에 대한 결정, 인증 체계 선택, 인증 계약 체결에 대한 인증자가 채택합니다.
기업의 품질 시스템 및/또는 테스트할 소프트웨어 제품 버전에 대한 요구 사항 식별
인증 연구소에 의한 회사의 품질 시스템 또는 소프트웨어 제품 버전에 대한 인증 테스트 수행;
획득한 결과 분석 및 신청자에게 적합성 인증서 발급 가능성에 대한 시험소 및/또는 인증 기관의 의사 결정
인증 기관에서 신청자에게 발급 - 적합성 마크를 사용하고 인증된 제품을 발급하기 위한 인증서 및 라이센스 - 소프트웨어 제품 버전
기업 및 / 또는 제품의 인증 된 품질 시스템 인증 기관에 의한 검사 관리 구현;
품질 시스템 및 / 또는 제품 프로세스가 확립 된 요구 사항과 일치하지 않고 적합성 표시가 잘못 적용된 경우 신청자가 시정 조치를 취합니다.

제품 품질에 대한 개발자 관리의 책임을 확인할 때 기업 또는 프로젝트에 문서화된 품질 정책, 목표 및 약속이 있으며 이 정책이 작업 조건에서 이해, 구현 및 유지되는 정도가 결정되어야 합니다. 조직의 모든 수준. 기업에는 다른 의무에 관계없이 품질 시스템의 표준 및 규제 문서의 요구 사항을 지속적으로 구현할 권한과 책임이 있는 관리 대표가 있어야 합니다. 전 생애에 걸쳐 통합된 프로세스인 품질 시스템의 모든 구성요소, 요구사항 및 조항의 관련성과 체계적인 문서화뿐만 아니라 품질 시스템 프로세스의 실질적인 구현을 위한 요구사항, 절차, 도구 및 훈련된 인력의 가용성 PS의 주기를 확인해야 합니다. 품질 시스템 점검정의를 포함해야 합니다:

기술 문서의 가용성 및 완전성 및 실제 요구 사항 준수;
기술 장비의 상태 및 유지 관리를 위한 시스템의 가용성;
통제 및 테스트 시스템의 존재와 효율성;
측정 및 테스트 도구의 상태;
제품 또는 기술에서 식별된 결함을 식별하고 제거하기 위한 시스템의 가용성.

테스트를 기반으로 얻은 결과가 평가되고 규제 문서의 요구 사항에 대한 제품 또는 프로세스의 준수 여부에 대한 결론이 입증됩니다. 테스트 보고서는 인증 기관과 신청자의 요청에 따라 제출됩니다. 테스트 보고서는 제품 인증 시스템의 규칙과 테스트 기관의 문서에 설정된 기간 동안 보관되어야 하지만 3년 이상입니다.

문서의 완성도와 품질을 접수하고 확인한 후 시험소의 전문가는 다음을 수행해야합니다. 품질 시스템의 실제 적용 정도 검토기업에서. 테스팅은 후속 작업을 위한 작업 계획의 역할을 하는 품질 시스템 테스트 프로그램의 개발로 시작됩니다. 이 프로그램은 시험소의 내부 작업 문서이며 개발자 기업의 세부 사항에 따라 상세하게 설명된 작업 목록을 포함해야 하며 제출된 소스 문서의 완전성 및 품질 및 실제 적용 정도에 대한 분석을 포함해야 합니다. 소프트웨어의 설계, 개발 및 제공. 품질 시스템 절차의 적용 검사는 PS의 수명 주기를 제공하는 기업의 작업장에 있는 시험소에서 수행합니다. 작업장에 관련 문서의 전문가-개발자의 존재와 해당 조항 및 권장 사항의 사용 완전성에 대한 점검이 수행됩니다. 프로젝트 상태에 대한 검토와 품질 시스템, 프로세스 및/또는 제품의 내부 감사는 이러한 작업의 구현에 직접 책임이 있는 사람과 독립적인 직원이 수행해야 합니다.

개발 품질 확인 방법제공되어야 한다 필요한 자원테스트 프로그램의 구현, 계획 방법 및 개인 테스트 절차 개발. 방법에는 다음이 포함되어야 합니다. 평가된 품질 지표; 테스트를 위한 조건 및 절차; 테스트 결과의 처리, 분석 및 평가 방법; 기술적 지원테스트 및 보고. 테스트 및 테스트 절차 동안 사용된 하드웨어 및 소프트웨어 및 예상되는 점검 결과를 표시해야 합니다. 감사 관리 서비스에서 이러한 요청을 받은 경우 수정을 제어하는 방법, 결함을 수정하기 위한 조치를 개발해야 합니다. 시험 프로그램 관리 서비스는 모든 시험 정보와 평가자가 보유한 데이터의 기밀성을 유지하기 위한 절차를 수립해야 합니다.

테스트 보고서신청자와 인증 기관에 제출합니다. 신청자는 유효성 조건을 고려하여 제품 개발 및 생산 중에 수행된 테스트 보고서 또는 인증 시스템에서 인증 또는 승인된 국내외 테스트 연구소에서 수행한 테스트에 대한 문서를 인증 기관에 제출할 수 있습니다. 인증 테스트 프로토콜을 기반으로 획득한 결과가 평가되고 제품이 규정 문서의 요구 사항을 준수하는지 여부에 대해 도출된 결론이 입증됩니다.

인증시험 결과 결론인증자에 의해 개발되었으며 테스트 결과 및 인증서 발급 근거에 대한 일반화된 정보를 포함합니다. 인증 테스트에서 음성 결과를 얻은 경우 적합성 인증서 발급을 거부하기로 결정합니다. 인증된 제품 또는 품질 시스템이 완료된 후 테스트를 반복할 수 있습니다. 기술 또는 제품 품질 현황 분석 결과 행위에 의해 작성된다, 테스트 프로그램의 모든 위치에 대한 추정치를 제공하고 생산 및 제품 상태에 대한 일반적인 평가, 시정 조치의 필요성을 포함한 결론을 포함합니다. 이 법은 테스트 보고서, 소프트웨어 제품에 대한 인증서의 유효 기간을 발급 및 결정하기 위한 응용 프로그램, 검사 제어 빈도 및 시정 조치를 작성하기 위한 응용 프로그램과 함께 인증 기관에서 사용합니다.

인증 테스트 및 문서 검토 결과에 따라 인증서 발급이 결정됩니다. 인증 테스트에서 음성 결과를 얻은 경우 다음과 같이 결정합니다. 인증서 발급 거부규정 준수. 또한, 부정적인 테스트 결과의 주장된 원인을 제거하기 위해 신청 기업에 제안을 보낼 수 있습니다. 인증 제품 완료 후 테스트를 반복할 수 있습니다.

인증 기관은 테스트 보고서를 분석하고, 생산을 평가하고, 품질 시스템을 인증하고, 신청 결정에 명시된 문서를 분석하고, 설정된 요구 사항에 대한 제품의 적합성을 평가하고, 전문가의 의견에 따라 인증서를 작성합니다. 그리고 등록합니다. 인증 중에 인증된 시스템 또는 소프트웨어 제품의 품질에 영향을 미칠 수 있는 설계 또는 운영 문서를 변경할 때 신청자는 추가 테스트의 필요성을 결정하기 위해 이에 대해 인증 기관에 알려야 합니다. 등록 후 인증서가 효력을 발생하며 신청 회사에 발송됩니다. 인증서 발급과 동시에 신청 기업이 발급될 수 있습니다. 특허적합성 마크를 사용할 권리.

적합성 인증서의 전체 유효 기간 동안 작동하는 인증된 소프트웨어 제품의 경우, 검사 통제. 검사 통제는 주기적 및 예정에 없던 검사기술 및 인증 제품의 품질 요구 사항 준수. 인증 체계에 따라 제어 대상은 인증된 제품, 품질 시스템 또는 기업 개발자의 생산 안정성입니다. 검사의 빈도와 범위를 결정할 때 다음 요소가 고려됩니다. 소프트웨어 제품의 잠재적 위험 정도, 생산 안정성, 릴리스 볼륨, 개발 중 품질 시스템의 가용성 및 적용, 정보 제조업체, 국가 통제 및 감독 기관이 수행 한 제품 및 생산 테스트 결과.

검사관리 결과 행위에 의해 작성된다샘플 테스트 및 기타 검사 결과를 평가하는 는 인증된 제품의 생산 상태 및 발급된 인증서의 유효성을 유지할 가능성에 대한 일반적인 결론을 내립니다. 행위는 인증 기관에 저장되고 그 사본은 개발자와 검사 통제에 참여한 조직으로 전송됩니다. 검사 관리 결과에 따라 인증 기관은 제품이 인증 중에 관리되는 규제 문서의 요구 사항을 준수하지 않는 경우 인증서를 정지 또는 취소하고 적합 마크 사용 권한에 대한 라이센스를 취소할 수 있습니다. 다음과 같은 경우:

성숙도 모델, 표준 프로필, 제품 규정 또는 테스트 방법의 근본적인 변경
디자인(구성)의 변경, 제품의 완성도;
개발 및 생산의 조직 또는 기술 변경;
기술 요구 사항, 제어 및 테스트 방법, 품질 시스템의 비준수, 나열된 변경 사항이 인증 중에 제어되는 요구 사항과 제품의 비준수를 유발할 수 있는 경우.

인증서를 발급한 인증 기관과 합의한 시정 조치를 통해 신청자가 발견된 비준수 원인을 제거하고 적합성을 확인할 수 있는 경우 적합성 마크 사용 권리에 대한 인증서 및 라이센스의 유효 기간을 정지하는 결정이 내려지지 않습니다. , 공인된 실험실에서 재시험 없이 제품 또는 프로세스가 규범 문서에 적합함. 이것이 불가능할 경우 인증서의 유효성이 취소되고 적합성 마크 사용 권한에 대한 라이센스가 취소됩니다. 인증서의 정지 또는 취소에 대한 정보는 인증서를 발급한 인증 기관이 신청자, 소비자 및 기타 관련 기관에 제공합니다. 개발자 기업이 다음 조건을 충족하는 경우 인증서의 유효성과 적합성 표시로 제품에 라벨을 붙일 수 있는 권리를 갱신할 수 있습니다.

불이행의 원인을 식별하고 제거합니다.
제품 품질을 개선하고 보장하기 위해 수행한 작업에 대한 보고서를 인증 기관에 제출합니다.
방법에 따라 인증 기관의 통제하에 제품에 대한 추가 테스트를 수행하고 긍정적 인 결과를 얻습니다.

소프트웨어 제품 인증 프로세스 및 결과 문서화

품질시스템 인증을 위한 문서의 구성 및 내용기업은 소프트웨어의 설계, 개발 및 수정의 특성과 품질 요구 사항 및 기술 환경의 특성에 따라 달라집니다. 따라서 이러한 특성과 관련하여 각 기업 또는 프로젝트에 필요한 문서 세트를 선택하고 조정해야 합니다. 인증 중에 평가되는 품질 시스템의 지표는 관련 문서의 가용성과 특정 수준의 성숙도 모델 요구 사항의 실제 이행입니다. SMMI또는 다음을 기반으로 하는 조정된 표준 프로필 ISO 9000:2000, 뿐만 아니라 기반으로 만들어졌습니다. 직업 설명기업 개발자의 전문가. 신청자는 고객과 개발자가 합의하고 규제 문서에 따라 신뢰성, 구성의 충분성 및 기술을 검증하기 위해 승인된 일련의 문서를 준비하여 테스트 연구소에 제출해야 합니다.

인증을 위한 기본 문서 세트는 세 그룹으로 구성됩니다.

기초적인 규정에 기반한 표준 프로파일의 명칭 및 내용에 따른 품질 시스템 ISO 9000:2000또는 성숙 모델 SMMI, 개발자가 기본적으로 준비한 프로그램, 매뉴얼 및 지침은 감사 대상 기업의 품질 시스템 또는 제품의 테스터(전문가)에게 제공됩니다.
품질 인증을 위해 프로젝트 관리가 준비한 특정 기업 또는 프로젝트의 특성과 소프트웨어 도구의 수명 주기를 나타내는 소스 문서
인증 기관, 신청자 및 감사 대상 기업의 경영진에게 제출된 기업의 품질 시스템 및/또는 소프트웨어 제품에 대한 감사(인증) 결과를 반영하는 테스터의 보고 문서.

인증을 위해 제출된 소프트웨어 제품 또는 기업 품질 시스템은 관련 문서와 함께 제출되어야 합니다. 이 문서 그룹의 목록과 대략적인 내용은 대형 소프트웨어 제품의 수명 주기를 보장하는 기업의 품질 시스템을 확인하는 일반적인 경우에 중점을 둡니다. 문서 세트는 소프트웨어 프로젝트의 특성에 따라 신청자, 인증자 및 감사 대상 기업 경영진 간의 합의에 따라 축소 및 조정될 수 있습니다. 일부 문서는 구현에 대한 특정 전문가의 명확한 책임이 있는 통합 보고서로 결합될 수 있습니다.

엔터프라이즈 품질 시스템 및 소프트웨어 수명 주기의 기본 문서

성능 개선을 위한 개념, 용어, 요구 사항 및 지침 - 품질 관리 시스템 - ISO 9000:2000또는 CMMI 성숙도 모델의 버전.
표준의 수정된 버전 또는 섹션 목록 및 권장 사항 ISO 12207, ISO 15504, 특정 기업 또는 소프트웨어 제품 프로젝트의 품질 시스템에서 사용하기 위해 적응 중에 선택되고 필수 사항인 변경 사항 및 적용 지침.
표준의 수정된 버전 또는 섹션 목록 및 권장 사항 ISO 900003, 적응 중에 선택되고 소프트웨어 제품을 생산하는 기업의 품질 시스템에서 사용하기 위해 필수입니다.
PS 프로젝트의 기본 특성 및 품질 속성, 표준을 기반으로 식별, 조정 및 지정 ISO 12182, ISO 9126, ISO 14598, ISO 25000.
표준 권장 사항을 기반으로 한 유지 관리 및 형상 관리 매뉴얼의 개정판 및 승인판 ISO 14764, ISO 10007, ISO 15846.
특정 PS 프로젝트에 대한 엔터프라이즈 품질 시스템 절차에 관련된 직원의 작업을 수행 및 확인하는 모든 관리자의 상호 작용에 대한 책임, 권한 및 절차를 정의하는 일련의 작업 설명.

특정 소프트웨어 도구의 수명 주기 기능을 반영하는 소스 문서

기업에서 생성된 소프트웨어 제품의 특성, 시스템 및 라이프 사이클의 외부 환경에 대한 설명, PS 프로젝트 및 기업 품질 시스템의 표준 및 요구 사항의 작업 버전을 적용하고 준비하는 데 필요합니다. 표준의 권고 ISO 12207, ISO 15504, ISO 90003그리고 ISO 9126.
품질 시스템 분야에서 기업 개발자의 목표, 요구 사항 및 의무에 대한 설명, 개발 프로세스 및 제품에 대한 품질 기준, 소프트웨어의 전체 수명 주기에 대한 제공 및 지원.
수정된 표준을 기반으로 하는 특정 버전의 소프트웨어 제품의 수명 주기와 사용을 보장하기 위해 고객과 사용자에게 제공되는 일련의 운영 문서 ISO 9294, ISO 15910, ISO 18019.
소프트웨어 제품의 수명 주기를 보장하는 데 사용되는 설계, 개발, 수정, 제어 및 테스트를 위한 문서화 및 자동화 도구입니다.
응용 프로그램을 테스트하고 기업 및 소프트웨어 제품의 품질 시스템 프로세스의 효율성을 평가하기 위한 계획 및 방법.
유지 관리 방법, 소프트웨어 제품 구성 요소 및 문서 식별, 소프트웨어 및 데이터 컴플렉스 버전 분석 및 승인.
구성 관리, 승인, 저장, 보호, 소프트웨어 제품 버전 및 첨부 문서 복사 및 소프트웨어 제품 버전의 수명 주기 동안 엔터프라이즈 아카이브에 등록된 품질 특성에 대한 데이터의 축적 및 저장을 위한 방법론.

결과 테스트 문서 - 기업 및 / 또는 소프트웨어 제품의 품질 시스템 인증

소프트웨어 제품의 전체 수명 주기 동안 통합된 품질 보증 프로세스를 제공하는 엔터프라이즈 품질 시스템의 요구 사항 및 조항에 맞게 조정된 문서의 가용성, 관련성 및 체계적인 실행에 대한 보고서입니다.
품질 시스템의 상태와 적용을 모니터링하고 테스트한 결과는 적합성과 효율성을 결정하기 위해 주기적으로 수행됩니다.
검사를 수행하는 방법의 가용성 및 유지 관리에 대한 보고서 및 고객과의 인증 계약 요구 사항을 충족하면서 달성된 품질의 결과에 대한 문서화된 보고서.
소프트웨어 패키지의 달성된 품질 특성 등록 결과: 식별, 축적, 소프트웨어 제품 및 그 구성 요소의 품질 특성 및 속성에 대한 등록 데이터의 저장.
개발 계획의 구현 결과, 개발 단계의 문서화된 입력 및 출력 데이터 및 PS의 수명 주기 구현을 확인하기 위한 프로토콜.
품질 프로그램의 실제 구현 및 PS 수명 주기의 모든 단계에서 품질 분야의 규제된 활동 구현 결과.
환경 시뮬레이터 및 테스트 생성기의 인증 결과 및 소프트웨어 제품의 인증 테스트 수행에 대한 적합성 평가
계획 및 테스트 방법, 테스트 보고서, 테스트 결과의 요구 사항 준수 평가 및 신청자, 고객 및 공급 업체 대표가 승인 한 테스트 결과의 구현 분석 결과.
소프트웨어 시스템 및 기업의 품질 시스템 수명 주기의 실제 특성 검증 결과, 소프트웨어 제품 생산 인증 요구 사항 준수에 대한 결론.
기업 및 / 또는 소프트웨어 제품의 품질 시스템 인증서 및 수명주기 보장, 적합성 마크 사용에 대한 라이센스.

문학

V.V. 리파예프 -- 소프트웨어 수명 주기 표준 프로필. -- 제트기 정보, 뉴스레터, N 12 , 2005

K. Milman, S. Milman -- SMMI는 미래로의 한 걸음입니다. -- 개방형 시스템., N 5-6.(2005), N2.(2006), 2005, 2006

소프트웨어 도구 및 정보 시스템 ISO IEC TR 15504-CMMI 생성 및 유지 관리 프로세스의 성숙도 평가 및 인증. 당. 영어로부터 -- 남: 책과 사업, 2001

V.V. 리파예프 -- 복잡한 소프트웨어 수명 주기의 프로세스 및 표준. 예배 규칙서.-- M.: SINTEG, 2006

V.V. 리파예프 -- 대규모 소프트웨어의 품질을 보장하는 방법.-- M.: RFBR. 2003년 신텍

"; antisource: "소프트웨어 제품은 이제 경제, 사회, 군사 및 기타 영역에서 인간 활동의 거의 모든 영역에서 관리 문제를 해결하는 데 사용됩니다. 국내 소프트웨어 제품의 대량 개발 및 국내 및 세계 시장의 다양한 응용 프로그램에 대한 납품 시 고품질을 보장하는 것이 전략적 과제가 되었습니다."; 조건: 1]$

주석: 개발 프로세스를 개선하기 위한 가장 잘 알려진 방법론의 기초가 되는 아이디어의 범위를 자세히 연구합니다. 소프트웨어- 에스엠. HMM의 논리와 구조를 분석한다. HMM과 이전에 연구된 프로세스 모델 간의 연결이 표시됩니다.

의 프레임워크 내에서 만들어진 멋진 실용적인 도구 프로세스 접근 방법활동 설명에 디자인 조직특히, 개발하는 조직 정보 시스템 , HMM 방법론을 보여줍니다. CMM은 Capability Maturity Model의 약자로, 대략적으로 "관리 시스템 성숙도 모델"을 의미합니다. 문헌에서 CMM은 일반적으로 조직 성숙도 모델이라고 하며, 저도 그 전통을 따를 것입니다.

SMM의 등장 연혁은 다음과 같다. 80년대 말. 지난 세기에 미 국방부는 소프트웨어 공학 연구소 1Eng를 주문했습니다. SEI - 소프트웨어 공학 연구소 Carnegie Mellon University는 소프트웨어 개발 프로젝트에서 하청업체를 선택하기 위한 기준 시스템을 구축하기 위해 노력하고 있습니다. 작업은 1991년에 완료되었고 그 결과가 CMM이었습니다. 모델에 재정적, 경제적, 정치적, 조직적 선택 기준하도급자 및 비밀 작업에 대한 허용 기준 (아마도 그러한 작업은 설정되지 않았습니다). 우리는 소프트웨어 시스템 개발 측면에서 잠재적인 하청업체의 능력을 설명하는 기준에 대해서만 이야기하고 있습니다.

CMM 구조

모델의 작성자는 조직의 프로세스를 조직의 품질 작업을 수행하는 능력을 평가하는 기초로 삼았습니다. 그런 다음 그들은 몇 가지 중요하지 않은 가정을 했고, 이후에 많은 IT 전문가(아마도 그들 대부분)에 의해 공정한 것으로 받아들여지고 인정되었습니다.

가정 1. 질적으로 다른 수준의 성숙도가 있습니다. 디자인 조직개발 중 정보 시스템(HMM 모델에는 5가지 레벨이 있습니다).

가정 2. 모든 개발 조직은 더 높은 수준의 성숙도로 이동하는 데 관심이 있습니다.

가정 3. 전환은 순서대로 다음 레벨로만 가능합니다. 수준을 "점프"하는 것은 불가능합니다(보다 정확하게는 조직의 위험이 급격히 증가함).

따라서 수준은 조직이 다음과 같이 상승하는 "사다리"를 형성합니다. 자체 개발. 각 수준은 조직 프로세스의 특정 구성과 속성이 특징입니다. SMM "레벨 사다리"는 널리 받아 들여지고 보급되었습니다. 그녀의 모습은 다음과 같습니다.

레벨 1 "초보자". 전체의 생산 과정은 특정 프로젝트를 위해 매번 생성되고 때로는 혼란스럽게 생성되는 것이 특징입니다. 소수의 프로세스만 정의되며 프로젝트의 성공은 개인의 노력에 달려 있습니다.

레벨 2 "반복 가능". 주요 프로젝트 관리 프로세스가 설정되어 비용을 추적하고 작업 일정과 생성 중인 소프트웨어 솔루션의 기능을 모니터링할 수 있습니다. 유사한 애플리케이션 개발 프로젝트에서 과거의 성공을 복제하는 데 필요한 프로세스 원칙을 수립했습니다.

레벨 3 "확실한". 생산 프로세스는 두 가지 모두에 대해 문서화되고 표준화됩니다. 관리 업무뿐만 아니라 디자인을 위해. 이 프로세스는 조직의 표준 제조 프로세스에 통합됩니다. 모든 프로젝트는 조직의 표준 운영 프로세스의 승인된 맞춤형 버전을 사용합니다.

레벨 4 "관리됨". 생산 공정 및 생산되는 제품의 품질에 대한 상세한 정량적 지표가 수집됩니다. 제조 공정과 제품 모두 정량적 관점에서 평가되고 관리됩니다.

레벨 5 "최적화". 정량적 프로세스를 통해 지속적인 프로세스 개선이 이루어집니다. 피드백그 안에 있는 진보된 아이디어와 기술의 프로세스와 구현.

엄격함이 없음에도 불구하고 위의 정의는 직관적으로 가장 자주 이의를 제기하지 않습니다. 또한 경험이 풍부한 전문가는 왜 다음 단계로만 전환이 가능한지, 그리고 그러한 전환을 위해 노력할 가치가 있는 이유를 이해합니다. 동시에 HMM 모델에는 그러한 접근 방식에 대한 정량적 또는 형식적 입증이 포함되어 있지 않지만, 이는 장점을 손상시키지 않습니다.

또한 그들이 말했듯이 기술의 문제입니다. 모델의 구조가 정의되고(그림 7.1), 정의가 제공되며, 각 수준에서 각 프로세스를 정확하게 설명하기 위한 힘든 작업이 시작됩니다. 수행한 작업의 실제 가치를 평가하기 위해 이 경로의 일부를 살펴보겠습니다.

쌀. 7.1.

무화과에. 7.1에는 다음 개념이 포함되어 있습니다.

핵심 프로세스 그룹. (Paulk, et al., 1995)에서 언급한 바와 같이, "핵심 프로세스의 각 그룹은 관련 활동의 블록을 정의하며, 그 결과 생산 프로세스의 생산성을 높이는 데 중요한 일련의 목표가 달성됩니다. 예를 들어 핵심 프로세스 그룹의 경우 " 요구사항 관리"(그림 7.2 참조) 목표는 고객과 개발자 간의 소프트웨어 개발 프로젝트 요구 사항을 조정하는 것입니다."

CMM에는 개별 프로세스가 없습니다. 대신에 개인 작품, 핵심 사례(아래 참조)라고 하며 입력과 출력으로 서로 연결되어 있으며 건물 프로세스의 소스 자료 역할을 합니다. CMM은 프로세스가 어떻게 구성되어야 하는지, 즉 핵심 사례를 논리적 순서로 연결하는 방법에 대한 지침을 제공하지 않습니다. 핵심 사례 집합을 핵심 프로세스 그룹이라고 합니다.

쌀. 7.2.

CMM의 주요 프로세스 그룹은 성숙도 수준에 매핑됩니다(그림 7.2). 즉, 한 수준의 모든 관행은 서로만 상호 작용하고 다른 수준의 관행과 상호 작용하지 않습니다. 이를 통해 특정 수준에서 모든 프로세스의 전체 성능을 보장할 수 있으므로 수준을 조직 개발의 완료된 단계와 연관시킬 수 있습니다.

형용사 "key"는 다음이 있음을 의미합니다. 프로세스 그룹(즉, 일련의 관행) 특정 성숙도 수준의 관점에서 핵심이 아닌, 즉 이 수준의 목표 달성과 관련이 없는(아래 참조) HMM 모델이 모든 것을 설명하지는 않습니다. 프로세스 그룹소프트웨어 개발 및 유지 관리에 관한 것입니다. 생산 프로세스의 생산성을 결정하는 핵심 요소로 식별되는 그룹만 설명합니다.

목표. CMM의 목표는 프로세스와 연관되지 않고 주요 프로세스 그룹과 연관됩니다. 위에서 언급한 바와 같이 목표는 핵심 관행의 구현을 통해 달성됩니다. CMM에서 목표를 달성한다는 것은 첫째, 핵심 사례를 구현한 후에 원하는 결과를 얻고 둘째, 매우 일관되게 얻는 것을 의미합니다. 핵심 프로세스 그룹의 목표가 달성되는 방식은 프로젝트마다 차이로 인해 다를 수 있습니다. 대상 지역 또는 환경.

이러한 목표가 모든 프로젝트에 대해 실현되면 조직이 이 핵심 프로세스 그룹과 관련된 생산 프로세스의 성숙도 수준에 도달했음을 의미합니다.

장. 섹션(각 수준에 5개가 있으며 항상 동일함)은 해당 수준에서 구현해야 하는 주요 프로세스 그룹의 속성을 나타냅니다. 이러한 속성은 프로세스가 구현되는 방식과 조직에서 어느 정도 합법화되는지, 즉 공식적으로 승인되고 기업 절차, 정책 및 기타 프로세스와 조정되는지를 설명합니다. 다음은 5개 섹션입니다.

이행의무

프로세스가 확립되고 안정적임을 보장하기 위해 조직이 취해야 하는 조치를 설명합니다. 수행 의무는 일반적으로 조직 정책 수립 및 최고 경영진의 지원과 관련이 있습니다.

전제 조건

제조 공정의 유능한 구현을 위해 프로젝트 또는 조직에서 충족되어야 하는 전제 조건을 설명합니다. 일반적으로 자원, 조직 구조 및 필요한 교육과 관련이 있습니다.

진행 중인 작업

진행 중인 작업 섹션에서는 이 수준에서 수행해야 하는 실질적인 작업에 대해 설명합니다. 수행되는 작업에는 일반적으로 계획 수립 및 특정 작업 구현, 작업 실행 및 추적, 필요에 따라 시정 조치 수행이 포함됩니다.

측정 및 분석

섹션 "측정 및

"핵심 프로세스의 각 그룹은 핵심 관행으로 표현되며, 그 구현은 그룹의 목표 달성에 기여합니다. 핵심 관행은 주요 프로세스 그룹의 효과적인 구현 및 설정에 가장 많이 기여하는 인프라 및 운영을 설명합니다.

각 핵심 사례는 단일 문장으로 구성되며 종종 예와 설명이 포함될 수 있는 보다 자세한 설명이 뒤따릅니다. 최상위 핵심 사례라고도 하는 핵심 사례는 핵심 프로세스 그룹에 대한 기본 정책, 절차 및 운영을 설정합니다. 자세한 설명 구성 요소는 종종 하위 사례라고 합니다."

핵심 사례는 무엇을 해야 하는지 설명하지만 목표를 어떻게 달성해야 하는지에 대한 도그마로 받아들여서는 안 됩니다. 핵심 프로세스 그룹의 목표는 대안적 실행을 통해 달성할 수 있습니다. 핵심 관행에 대한 해석은 합리적이어야 하며 핵심 프로세스 그룹의 목표 달성을 허용해야 합니다. 효과적인 방법, 권장되는 CMM과 형식적으로 다를 수 있습니다.

프로세스 대신 구성 요소가 고려되는 IT 관리 활동을 살펴보면 핵심 사례에서 구축할 수 있는 것으로서 프로세스가 가상으로만 존재한다는 것이 언뜻 보기에는 다소 이국적으로 보입니다. 지금까지 IT 관리 개선 과제는 참조 프로세스 모델에서 기성 프로세스를 도입하여 해결되었습니다. 이제 이질적인(즉, 프로세스에 통합되지 않은) 핵심 사례와 수준을 이동하기 위한 권장 순서를 포함하는 많은 수준이 있습니다. CMM에 따르면 IT 관리는 성숙도가 높아짐에 따라 개선됩니다. 이 프로모션은 어떻게 되나요?

수준의 정의(그림 7.2 참조)에서 "생산 과정"과 같은 것이 나타났습니다. 이는 주요 프로세스 그룹의 정의에도 존재하며 이는 우연이 아닙니다. 제조 공정 또는 CMM에서 적절하게 호출되는 표준 제조 공정조직(OSS)은 전체 모델의 중심 개념 중 하나입니다.

1986년 11월, SEI(American Software Engineering Institute)는 Mitre Corporation과 함께 내부 프로세스를 개선하는 데 도움이 되도록 소프트웨어 개발 프로세스 성숙도 조사를 개발하기 시작했습니다.

이 검토의 개발은 소프트웨어 개발을 위한 하청업체를 평가하는 방법에 대한 미국 연방 정부의 요청에 의해 촉발되었습니다. 진짜 문제는 관리 능력 부족 큰 프로젝트. 많은 회사에서 프로젝트가 상당히 늦게 그리고 예산을 초과하여 전달되었습니다. 이 문제에 대한 해결책을 찾는 것이 필요했습니다.

1987년 9월 SEI는 짧은 리뷰성숙도에 대한 설명이 포함된 소프트웨어 개발 프로세스와 개선이 필요한 회사 영역을 식별하도록 설계된 설문지. 그러나 대부분의 기업은 이 설문지를 기성품 모델로 여겼고, 그 결과 설문지는 4년 만에 실제 모델인 CMM(Capability Maturity Model for Software)으로 전환됐다. 1991년에 릴리스된 CMM의 첫 번째 버전(버전 1.0)은 1992년에 약 200명의 소프트웨어 전문가와 개발자 커뮤니티 구성원이 참석한 작업 회의 참가자에 의해 수정되었습니다.

초등학교. 조직의 가장 원시적인 상태. 조직은 소프트웨어를 개발할 수 있습니다. 조직에는 명시적으로 의식적인 프로세스가 없으며 제품의 품질은 전적으로 개발자의 개별 능력에 의해 결정됩니다. 한 사람이 주도권을 잡고 팀은 그의 지시를 따릅니다. 한 프로젝트의 성공이 다른 프로젝트의 성공을 보장하지는 않습니다. 프로젝트가 끝나면 인건비, 일정 및 품질에 대한 데이터가 기록되지 않습니다.
반복 가능. 어느 정도 프로세스가 모니터링됩니다. 인건비 및 계획에 대한 기록이 작성됩니다. 각 프로젝트의 기능은 서면으로 설명됩니다. 1999년 중반에는 조직의 20%만이 레벨 2 이상이었습니다.
설치되었습니다. 정의하고 문서화하고 확립된 과정개인과 독립적으로 일합니다. 즉, 합의 전문적인 기준, 개발자가 구현합니다. 이러한 조직은 이전에 완료된 프로젝트와 유사한 프로젝트의 비용을 상당히 안정적으로 예측할 수 있습니다.
관리됨. 그들은 작업 시간과 비용을 정확하게 예측할 수 있습니다. 누적 측정 데이터베이스가 있습니다. 그러나 새로운 기술과 패러다임의 등장에도 변화는 없습니다.
최적화되었습니다. 새롭고 개선된 방법과 도구를 찾고 마스터하기 위한 지속적인 절차가 있습니다.

개발

실제로 모델의 사용은 소프트웨어 개발 프로세스의 더 높은 수준의 조직을 달성하기 위한 접근 방식의 모호성을 드러냈습니다. 따라서 2002년까지 개발 프로세스를 개선하기 위한 권장 사항이 개발되고 있습니다. CMMI(역량 성숙도 모델 통합). 현재 최신 버전 CMMi - 1.3(2010년 11월 게시) .

또한보십시오

연결

MIT 학생 포럼 > 메인 섹션 > 테스트 > 제어 시스템 시뮬레이션

보다 풀 버전: 제어 시스템 시뮬레이션

나는 모든 모듈을 풀고 4로 모든 것을 통과하고 2로 마지막 모듈을 통과했습니다. 이제 3일 후에 다시 통과하려고 합니다. 단 하나의 동일한 질문이 없었습니다. 기말고사를 맞혀보려고 했는데 맞나를 장담할 수 없어 내가 가진 모든 것을 공개해, 어쩌면 나보다 더 잘 통과할 사람이 있을지도 몰라. 누군가가 두 번째, 세 번째 시도를 했다면 포기하고, 괜찮다면 규율을 하는 것이 정말 어렵습니다.:eek:

최종 테스트 100점 만점에 100점

매번 결과가 다른가요?

여기에 나열되지 않고 나를 사로잡은 더 많은 질문. 나는 답을 찾지 않았다. 왜냐하면 그것 없이 나는 4를 통과했기 때문이다. 혼란스러워하고 싶은 사람은 나머지를 위해 여기에 답을 업로드하십시오 🙂

모듈 1:
비즈니스 프로세스의 특징으로 간주해서는 안 되는 것은 무엇입니까?

부가가치

하나의 답변을 선택하십시오:
이전에 설정된 목표를 구현하는 프로세스의 산물

하나의 답변을 선택하십시오:

결승전(4.

능력 성숙도 모델이란 무엇입니까? (CMM)

다음 질문 + 이미 포럼에 있는 질문):
1. 올바른 문장을 고르세요.
하나의 답변을 선택하십시오:
사업부의 업무 프로세스는 다양한 Value Chain으로 구성됨(UNSURE)
종단 간 비즈니스 프로세스는 비즈니스 프로세스로 구성됩니다. 다양한 조직
교차 기능 비즈니스 프로세스는 일반적으로 부서의 비즈니스 프로세스로 구성됩니다.

2. 보편적인 비즈니스 프로세스 흐름도의 요소가 아닌 것은?
하나 이상의 답변을 선택하십시오.
프로세스 리소스
위험
비즈니스 프로세스 관리 활동
환경적 요인
입력을 출력으로 변환하는 활동

3. 물질적 자원프로세스의 기본 요소는 다음과 같습니다.
하나의 답변을 선택하십시오:
서로 및 다른 리소스와 상호 작용하는 시스템에서 결합된 활동의 능동적 주체
프로세스의 목표와 결과를 결정하는 활동 대상에 대한 활동 주체가 지시하는 조치를 제어합니다.
프로세스를 수행하는 데 사용되는 수동 시설 및 활동(확실하지 않음)

28.03.2014, 10:07

모듈 1:
비즈니스 프로세스의 특징으로 간주되어서는 안 되는 것은 무엇입니까? 하나 이상의 답변을 선택하십시오.
입력을 출력으로 변환
외부 소비자에게 제품 전달
부가가치
잉여가치 및/또는 사용가치의 형성

프로세스의 기본 요소로서의 결과는 다음과 같습니다.
하나의 답변을 선택하십시오:
서로 및 다른 리소스와 상호 작용하는 시스템에서 결합된 활동의 능동적 주체
이전에 설정된 목표를 구현하는 프로세스의 산물 프로세스를 수행하는 데 사용되는 수동 시설 및 활동
프로세스를 완료하는 데 필요한 재료, 에너지 및 정보 개체 세트

비즈니스 프로세스 내에서 피드백이란 무엇입니까?
하나의 답변을 선택하십시오:
원하는 결과를 보장하도록 설계된 프로세스에 대한 의도적이고 의식적인 영향
이전에 설정된 목표와 프로세스 결과의 분석 및 비교
시스템 기능의 다양한 종류의 편차의 원인이되는 환경 요소 및 대상 시스템에 대한 영향
나는 그렇게 대답했다! 그래도 4가 나왔다

결승전 - 다음 질문 + 이미 존재하는 질문:
1 목록에서 설계 대상 구조의 단점을 선택합니다.

2 목록에서 명령 사용 예를 선택합니다.
품질 머그
위원회
작업 팀

3 유기적 조직 구조를 적용하기 위한 조건을 목록에서 선택합니다.
근로자는 복잡한 요구에 의해 동기 부여됩니다.
목표가 흐릿하고 동적으로 변합니다.
권력에 의문이 제기되고 테스트되며 부하 직원의 확인이 필요합니다.

4 프로젝트 기반 조직 구조의 이점을 목록에서 선택합니다.
프로젝트 관리자에 대한 직원의 직접적인 종속 및 따라서 이러한 직원의 노력 방향의 명확성이 달성됩니다.

5 지원 프로세스:
제공하다 효과적인 구현주요 공정

최종 5학년
질문 1
명령 사용 예 목록에서 선택합니다.

품질 머그
위원회
작업 팀

질문 2
기능적 구조 내에서 중개자는 무엇을 사용합니까?

다양한 구조적 부서의 활동을 통합하기 위해

질문 3
SADT 모델의 관계 유형 이름:
제어
출구 메커니즘
입력 피드백

질문 4
다음 비즈니스 프로세스 중 가장 짧은 것은?
사업부 업무 프로세스

질문 5
비즈니스 프로세스 정보 모델을 생성하는 데 사용할 수 있는 방법, 방법론 및 도구는 무엇입니까?

Gein-Sarson 방법론
Chen과 Barker의 모델링 언어

질문 6
다음 중 가장 낮은 수준에 해당하는 비즈니스 프로세스 표현은 무엇입니까?

비즈니스 프로세스 운영

질문 7
비즈니스 프로세스 길이:

주관적이다

질문 8
프로세스의 기본 요소인 재료 자원은 다음과 같습니다.

프로세스를 수행하는 데 사용되는 수동적 수단 및 활동 대상

질문 9
프로젝트 기반 조직 구조의 이점을 목록에서 선택하십시오.

프로젝트 관리자에 대한 직원의 직접적인 종속이 구현되어 이러한 직원의 노력 방향이 모호하지 않습니다.

질문 10
매트릭스 조직 구조의 이점을 목록에서 선택하십시오.

유연하게 커스터마이징 가능 조직 구조넓은 스펙트럼 내에서: 약한 매트릭스에서 강한 매트릭스까지

질문 11
비즈니스 시스템 관리의 두 번째 루프에는 무엇이 포함됩니까?

작동 제어 하위 시스템
개발 관리 하위 시스템

질문 12
비즈니스 시스템의 일반 프로세스 모델에는 다음 요소가 포함됩니다.

출구
프로세스
입구
방해

질문 13
활동, 흐름 및 개체 상태를 모델링할 수 있는 IDEF 표준은 무엇입니까?

질문 14
강력한 매트릭스 구조에서 프로젝트 관리자의 권한은 무엇입니까?

중간에서 높음

질문 15
투자 및 재무 프로세스의 주요 요소는 무엇입니까?

투자자
대출 기관

질문 16
설계 대상 구조의 단점을 목록에서 선택하십시오.

기능 영역의 제조 가능성 감소

제어 시스템 모델링.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

SADT 다이어그램에서 우세한 순서는 무엇입니까?
답변: 가장 지배적인 기능은 왼쪽 상단 모서리에 있습니다.

도움 3그것을 가지고있는 교육 pliz

1분 후 추가됨
제어 시스템 모델링이 있는 사람에게 3가지 교육을 요청합니다.

다음과 같이 말할 수 있는 번역:

IS 개발 방법론. CMM/CMMI 성숙도 모델.

1991년, 대학 소프트웨어 공학 연구소

Carnegie Mellon(Software Engineering Institute, SEI)은 소프트웨어 제품 개발을 위한 CMM 성숙도 모델(Capability Maturity Model)을 만들었습니다. 시간이 지남에 따라 전체 모델 제품군이 출시되었습니다.

소프트웨어 제품용 SW-CMM, 시스템 엔지니어링용 SE-CMM, 조달용 Acquisition CMM, 인적 자원 관리용 People CMM, 제품 통합용 ICMM.

다양한 모델은 이해하고 구현하기가 상당히 어려웠습니다. 그들이 만들어졌을 때부터 다른 그룹전문가들은 이러한 모델의 내용이 항상 서로 일치하지 않았을 뿐만 아니라

국제 표준의 요구 사항. 따라서 2002년 SEI는 이전에 출시된 모델을 결합하고 요구 사항을 고려하여 새로운 CMMI 모델(Capability Maturity Model Integration)을 발표했습니다.

국제 표준. CMMI는 다양한 규모와 활동의 조직에서 프로세스를 개선하기 위한 일련의 모델(방법론)입니다. CMMI는 다음과 같은 개선 영역 그룹을 구분합니다. 프로세스 관리, 프로젝트 관리, 엔지니어링 영역, 서비스

지역. 이 경우 모든 영역은 구현 방식이 아니라 인터페이스 요구 사항을 결정하는 요구 사항 형식으로 지정됩니다. 이것으로부터 두 가지 결과가 있습니다.

결과 1. CMMI는 다양한 구현이 가능하며 MSF, Scrum, RUP 등과 같은 소프트웨어 개발 방법론이 아닙니다. 후자는 구현에 사용될 수 있습니다. 예를 들어, CMMI용 MSF라는 특수 프로세스 템플릿이 CMMI용 VSTS에 있습니다.

결론 2. CMMI는 회사의 프로세스 성숙도를 인증하는 데 사용됩니다. 처음에는 80년대 후반과 90년대 초반에 CMM(당시 아직 CMMI가 아님)이 인증 수단으로 정확하게 만들어졌습니다.

연방 하청업체. 그리고 나중에야 세계에 널리 보급되어 사용되기 시작했고 프로세스 개선에 중점을 두었습니다. 우리는 하나 더 주목 중요한 특성 CMMI. 이것은 소프트웨어 시스템의 개발만을 위한 것이 아닙니다. 많은 대기업그들은 소프트웨어가 아니라 소프트웨어가 필수적인 부분으로 포함된 대상 제품을 생산합니다.

예를 들어, 항공, 항공 우주 산업. 즉, 소프트웨어 개발

다른 유형의 엔지니어링 작업과 함께 발생합니다. 그리고 하나의 프로젝트에 두 가지 이상의 서로 다른 유형의 엔지니어링이 관련된 경우가 종종 있습니다. CMMI의 임무는 이러한 프로젝트와 회사에 개발 프로세스를 구성하기 위한 단일 플랫폼을 제공하는 것입니다.

엄격하게 계층적이고 레벨별로 프로세스를 순차적으로 개선할 수 있었던 기존 CMM 모델과 달리 CMMI 모델은 다음과 같은 두 가지 차원을 가지고 있습니다.

CMM과 동일하고 지속적이며 임의적인 방식으로 조직의 프로세스를 어느 정도 개선할 수 있습니다. 여기서 우리가 집중할 순차 모델. 5개의 레벨이 있습니다

프로세스 성숙도(그림 1).

첫 번째 수준(성숙도 레벨 1)은 정의상 모든 회사가 해당하는 레벨입니다. 이 수준에서 소프트웨어 개발은 다소 혼란스럽습니다.

관리 수준(성숙 수준 2) - 회사 수준에서 승인된 프로세스 구성을 위한 정책 및 절차가 이미 여기에 표시됩니다. 그러나 프로세스의 전체 범위는 개별 프로젝트의 프레임워크 내에서만 존재합니다.

일정 수준(성숙도 레벨 3) - 여기에서 표준 프로세스는 전체 회사 수준에서 나타납니다.

능력 성숙도 모델(CMM)이란 무엇입니까? CMM 레벨이란 무엇입니까?

이는 문서 템플릿, 문서 템플릿,

라이프 사이클 모델, 소프트웨어 도구, 관행 등. 이 표준에서 잘라내어 특정 프로세스를 얻습니다.

정량적 수준(성숙도 4)는 회사에서 측정 시스템의 출현을 의미하며, 이는 표준 프로세스를 기반으로 발생하며 개발의 양적 관리를 허용합니다.

최적화 수준(성숙도 레벨 5)는 점진적, 점진적 및 혁명적 개발 프로세스의 지속적인 개선을 의미합니다. 동시에 이러한 변화는 강제적인 것이 아니라 능동적인 문제와 어려움이다. 프로세스는 자체적으로 개선되고 있으며 지속적으로 적절한 메커니즘이 구현되었습니다.

많은 사람들이 약어 CMMI를 알고 있고 많은 사람들이 이것이 모델이라는 것을 알고 있습니다. 예를 들어 소프트웨어 개발과 관련된 프로세스를 개선하는 방법에 대한 일련의 권장 사항. 그러나 몇 가지 CMMI 모델이 있다는 것을 아는 사람은 거의 없습니다. 그 중 가장 유명한 것이 CMMI for Development(CMMI-DEV)로, 개발 회사(즉, 특정 소프트웨어 제품 또는 기타 복잡한 소프트웨어 및 하드웨어를 개발 및 공급하는 회사 및 조직)의 활동과 여러 측면에서 실제로 연결되어 있습니다. 해결책).

그러나 제품이 아니라 서비스를 제공하는 사람들은 어떻습니까(예: 총 노동 비용에서 개발의 미미한 부분을 차지하는 제품 지원 또는 노동 비용이 전혀 없음)? 이들을 위한 일련의 권장 사항인 CMMI for Services 모델(CMMI-SVC)도 있습니다. 예를 들어 IT 부서의 경우 이 모델(보다 정확하게는 권장 사항)은 예를 들어 동일한 ITIL 권장 사항이 일종의 "신성한 관행"이 아닌 정상적인 프로세스가 되도록 수행해야 하는 작업을 이해하는 데 도움이 될 수 있습니다.

능력 성숙도 모델(CMM)

이 모델의 권장 사항이 매우 보편적이며 다음에 대해서만 "닫지" 않는 것이 궁금합니다. 정보 기술. 이 모델의 시범 도입은 미국의 한 병원에서 이루어졌습니다(결국 의료도 서비스임).

그러나 나열된 모델 중 하나를 배우는 것이 좋습니다. 그리고 전체 CIS(약 250-300명)에 대해 CMMI-DEV 모델로 훈련된 사람이 수백 명이라면 CIS에서 CMMI-SVC 모델로 훈련된 사람은 6명뿐입니다. 우리는 강사가 아니라 훈련된 사람에 대해 이야기하고 있습니다. 이것이 바로 2011년 12월까지의 주요 문제였습니다. CMMI-DEV의 경우 전 세계에 SEI(CMMI 모델 개발자)에서 인증한 러시아어를 할 수 있는 강사가 단 한 명뿐이었고 다른 모델의 경우 전혀 없었습니다! 이제 그러한 강사는 CMMI-SVC 모델에 따라 나타났습니다(따라서 처음 6명이 훈련됨). 이 강사는 이 간행물의 저자이며 언급된 모델 및 정식 교육에 대한 모든 질문에 답할 수 있습니다. 묻다!

이 자료는 Club.CNews 커뮤니티 회원의 개인 기록입니다.
씨뉴스의 편집자는 그 내용에 대해 책임을 지지 않습니다.

우리는 "프로세스 성숙도 모델" 또는 "능력 향상 모델"을 기반으로 품질 보증 모델의 진화를 고려할 것입니다. CMM(능력 성숙도 모델).모델임에도 불구하고 SMM소프트웨어의 품질을 보장하는 것을 목표로 하며 그 방법론적 측면은 모든 제품(상품, 작업, 서비스)의 품질을 보장하기 위한 모델에 적용할 수 있습니다.

모델의 주요 SMM조직적 성숙도의 개념이다.

미성숙소프트웨어 개발 프로세스가 특정 수행자와 관리자에게만 의존하고 결정이 종종 "즉시" 내려지는 조직으로 간주됩니다. 이 경우 예산을 초과하거나 프로젝트를 수행하지 못할 가능성이 높기 때문에 관리자는 즉각적인 문제 해결에만 대처할 수 있습니다.

성숙한조직은 다음 조건을 충족하는 것으로 간주됩니다.

– 소프트웨어 제품 및 프로젝트 관리를 생성하기 위한 잘 정의된 절차가 있으며, 이는 다음에서 개선되고 개선됩니다. 파일럿 프로젝트"비용 - 이익"의 구성 요소를 분석하여;
– 작업 수행에 소요되는 시간과 비용의 추정치는 축적된 경험을 기반으로 하므로 매우 정확합니다.
– 회사는 소프트웨어의 개발, 테스트 및 구현 프로세스에 대한 표준, 최종 프로그램 코드, 구성 요소, 인터페이스 설계에 대한 규칙을 가지고 있습니다. 이 모든 것이 인프라를 구성하고 기업 문화소프트웨어 개발 프로세스를 지원합니다.

그래서 표준 SMM조직의 성숙도를 평가하기 위한 기준과 기존 프로세스를 개선하기 위한 방법으로 구성된 품질 보증 모델입니다. 모델에서 SMM조직의 성숙도를 5단계로 정의하고 그 특성을 그림 1에 나타내었다. 5.3.

쌀. 5.3. 5단계 모델 성숙도SMM

첫 번째 수준 (초기 레벨)다음 수준에서 기업의 발전을 위한 기초입니다. 조직의 엔트리 레벨 엔터프라이즈에는 고품질 소프트웨어를 만들기위한 안정적인 조건이 없다고 믿어집니다. 결과적으로 모든 프로젝트의 결과는 전적으로 관리자의 개인적 자질과 프로그래머의 경험에 달려 있습니다. 이것은 동일한 관리자와 프로그래머가 다음 프로젝트에 배정되어야만 한 프로젝트의 성공을 반복할 수 있음을 의미합니다. 반면에 프로젝트 경험이 있는 관리자나 프로그래머가 회사를 떠나면 생산된 소프트웨어의 품질이 퇴사하면서 급격히 떨어집니다.

스트레스가 많은 상황에서 초기 수준에서 인적 요인개발 프로세스는 코드 작성과 최소한의 테스트로 축소됩니다.

두 번째 달성 반복 가능한 수준 (반복 가능한 수준) 기업의 프로젝트 관리 기술 구현에 의해 결정됩니다. 기업의 계획 및 프로젝트 관리는 축적된 경험을 기반으로 하며 개발된 소프트웨어에 대한 표준이 있고 사용되며 준수는 특별 품질 보증 그룹에 의해 제어됩니다. 두 번째 수준은 추가 개선(세 번째 수준으로의 전환)을 위한 기회를 제공할 수 있으며 중요한 조건에서 소프트웨어 개발 프로세스의 품질이 초기 수준으로 퇴행할 가능성을 배제하지 않습니다.

제삼, 특정 수준 (왼쪽 정의)소프트웨어 개발에서 프로젝트 관리에 이르기까지 소프트웨어를 만들고 유지 관리하는 표준 프로세스가 완전히 문서화되어 있다는 사실이 특징입니다. 이 수준의 도입에 대한 가설은 표준화 과정에서 기업이 가장 효과적인 관행과 기술로 이동한다는 것입니다. 조직에서 소프트웨어 개발 및 프로젝트 관리에 대한 표준을 만들고 유지하려면 특수 그룹을 만들어야 합니다. 세 번째 수준에 도달하기 위한 전제 조건은 기업에서 지속적인 전문성 개발 및 직원 교육 프로그램을 제공하는 것입니다. 이 수준에서 시작하여 조직은 특정 개발자의 자질에 더 이상 의존하지 않고 스트레스가 많은 상황에서 더 낮은 수준으로 내려가는 경향이 있다고 믿어집니다.

넷째, 관리 수준 (관리 수준)기업은 소프트웨어 제품 및 일반적으로 생성 프로세스 모두에 대해 정량적 품질 지표를 설정합니다. 따라서 다양한 프로젝트 지표의 편차를 줄임으로써 더 나은 프로젝트 관리가 달성됩니다. 동시에 구현된 소프트웨어 개발 프로세스의 의미 있는(신호) 변동과 프로세스의 무작위(노이즈) 변동이 분리됩니다.

다섯 번째(최고), 최적화 수준 (최적화 수준)기존 프로세스뿐만 아니라 새로운 기술 도입의 효율성을 평가하기 위해 개선 조치를 적용한 것이 특징입니다. 이 수준에서 기업의 주요 임무는 기존 프로세스를 지속적으로 개선하는 것입니다. 동시에 프로세스 개선은 예방에 도움이 되어야 합니다. 가능한 오류및 결함. 동시에 소프트웨어 개발 비용을 줄이기 위한 작업을 수행해야 합니다.

조직 프로세스 관리의 5가지 진화 단계. 능력 성숙도 모델의 설명. CMM

CM-CEI Capability Maturity Model은 조직의 프로세스가 관리되는 5개의 진화적 단계(레벨)를 설명하는 조직 모델입니다.

원래 소프트웨어 개발을 위해 생성된 기능 성숙도 모델의 요점은 조직이 소프트웨어 응용 프로그램을 수락하고 지원할 수 있어야 한다는 것입니다. 이 모델은 또한 조직이 다음 단계로 성장하는 데 도움이 되는 구체적인 단계와 이니셔티브를 제안합니다.

능력 성숙도 모델의 5단계

초기(프로세스가 임시적이거나 혼란스럽거나 실제로 정의된 프로세스가 거의 없음) 반복 가능(기본 프로세스가 설정되고 해당 프로세스를 고수하는 규율이 있음) 정의됨(모든 프로세스가 정의되고 문서화됨) , 통합되고 통합됨) 관리됨( 프로세스는 프로세스 및 품질에 대한 세부 데이터를 집계하여 측정) 최적화(양적 피드백 및 새로운 아이디어 및 기술 테스트를 통한 지속적인 프로세스 개발)

소프트웨어 개발 모델

CMM은 소프트웨어 프로세스 성숙도 개념의 기초가 되는 원칙과 관행을 설명합니다. 소프트웨어 개발 및 판매 회사가 소프트웨어 프로세스의 정교함을 진화적으로 개선하는 데 도움이 되도록 설계되었습니다. 임시적이고 혼란스러운 프로세스에서 시작하여 성숙하고 훈련된 소프트웨어 프로세스로 이동합니다. 규율 있는 소프트웨어 프로세스를 구성할 수 있는 주요 프로세스 영역과 모범 사례를 식별하는 데 중점을 둡니다. CMM 성숙도의 개념은 다음과 같은 맥락을 만듭니다.

연습은 반복할 수 있습니다. 일부 작업을 반복하지 않으면 개선해서는 안됩니다. 조직이 구현하고 일관되게 실행하도록 하는 규칙, 절차 및 관행이 있습니다. 생산 작업을 구성하기 위한 모범 사례는 그룹 간에 빠르게 공유할 수 있습니다. 관행은 프로젝트 간의 교환을 허용하도록 정의되어 조직에 일부 표준화를 제공합니다. 이러한 방법의 실행 편차가 최소화됩니다. 작업에 대한 양적 목표가 설정됩니다. 평가의 기초를 형성하기 위해 측정이 수립, 생산 및 유지됩니다. 능력 향상(최적화)을 위해 사례를 지속적으로 개선합니다.

기능 성숙도 모델은 소프트웨어 개발뿐만 아니라 일반적으로 조직의 진화 수준을 설명하고 조직이 구현했거나 달성하고자 하는 관리 수준을 설명하는 데 유용합니다.

기능 개발 모델의 구조

일반적 특성

프로세스 정의 기준

프로세스 정의 기준은 사람들이 실제로 사용하기 위해 소프트웨어 프로세스 설명에 포함되어야 하는 일련의 프로세스 요소입니다. 기준을 설정하려면 "어떤 정보가 소프트웨어 프로세스문서에 필요한?

소프트웨어 시스템 설계를 위한 성숙도 모델 cmm. 디자인 조직의 성숙도

소개