Страница разрабатывается

CMM. Различные области специализации

— SW-CMM (Capability Maturity Model for Software) — модель зрелости возможностей создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение.
— SE-CMM (Systems Engineering CMM) describes the essential elements of an organization’s systems engineering process that must exist to ensure good systems engineering. It does not specify a particular process or sequence. In addition, the SE-CMM provides a reference for comparing actual systems engineering practices against these essential systems.
— People CMM (Developing human talent) is a maturity framework that focuses on continuously improving the management and development of the human assets of an organization. It describes an evolutionary improvement path from ad hoc, inconsistently performed practices, to a mature, disciplined, and continuously improving development of the knowledge, skills, and motivation of the workforce that enhances strategic business performance. The People Capability Maturity Model (People CMMI) is a framework that helps organizations successfully address their critical people issues.
— SA-CMM (Software Acquisition CMM) is a model for benchmarking and improving the software acquisition process. The model follows the same architecture as the Capability Maturity Model for Software (SW-CMM), but with a unique emphasis on acquisition issues and the needs of individuals and groups who are planning and managing software acquisition efforts.
— TS-CMM (Trusted Software, tailored CMM) defined levels of trust, with lower trust levels emphasizing resistance to unintentional vulnerabilities and higher trust levels adding processes to counter malicious developers.
— IPD-CMM (Integrated Product Development)
— CMMI (CMM Integration) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определённых областей деятельности. Набор моделей CMMI включает три модели: CMMI for Development (CMMI-DEV), CMMI for Services (CMMI-SVC) и CMMI for Acquisition (CMMI-ACQ). Наиболее известной является модель CMMI for Development, ориентированная на организации, занимающиеся разработкой программного обеспечения, аппаратного обеспечения, а также комплексных систем.

Классификация требований

Requirement — (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a product, service, product component, or service component to satisfy a supplier agreement, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).

Эта процессная область описывает три типа требований:
— требования заказчика (потребности заинтересованных сторон, ожидания, ограничения и взаимодействия)
— требования к продукту
— требования к компонентам продукта

Nontechnical requirements — Requirements affecting product and service acquisition or development that are not properties of the product or service. Contractual provisions, commitments, conditions, and terms that affect how products or services are to be acquired. Examples include products to be delivered, data rights for delivered commercial off-the-shelf (COTS) nondevelopmental items (NDIs), delivery dates, and milestones with exit criteria. Other nontechnical requirements include training requirements, site requirements, and deployment schedules.
Technical requirements — Properties (attributes) of products or services to be acquired or developed.
Customer requirement — The result of eliciting, consolidating, and resolving conflicts among the needs, expectations, constraints, and interfaces of the product’s relevant stakeholders in a way that is acceptable to the customer.
Product component requirements — A complete specification of a product or service component, including fit, form, function, performance, and any other requirement.
Product requirements — A refinement of customer requirements into the developers’ language, making implicit requirements into explicit derived requirements.

Security Requirements

Методы сбора требований

Examples of techniques to elicit needs include the following:
Technology demonstrations — Демонстрация технологий
Interface control working groups
Technical control working groups
Interim project reviews
Questionnaires, interviews, and operational scenarios obtained from end users — Анкеты, интервью и сценарии операций, полученные от конечных пользователей
Operational walkthroughs and end-user task analysis — Операционные пошаговые руководства и анализ задач конечного пользователя
Prototypes and models — Прототипы и модели
Brainstorming — Мозговой штурм
Quality Function Deployment — Разработка функции качества
Market surveys — Исследования рынка
Beta testing — Бета-тестирование
Extraction from sources such as documents, standards, or specifications — Извлечение из источников, таких как документы, стандарты или спецификации
Observation of existing products, environments, and workflow patterns — Наблюдение за существующими продуктами, средой и шаблонами рабочих процессов
Use cases — Варианты использования
Business case analysis — Анализ бизнес-кейсов
Reverse engineering (for legacy products) — Реверсивное проектирование (для устаревших продуктов)
Customer satisfaction surveys — Исследования удовлетворенности клиентов

Examples of sources of requirements that might not be identified by the customer include the following:
Business policies
Standards
Business environmental requirements (e.g., laboratories, testing and other facilities, and information technology infrastructure)
Technology
Legacy products or product components (reuse product components)