Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘решение’

CMMI DEV v1.3 – Анализ и Принятие Решений

Posted by Шамрай Александр на Июль 19, 2011

Перевод Шамрай А.В.

Процессная область Поддержки уровня зрелости 3

Назначение

Назначением Анализа и Принятия Решений (АПР) является анализ возможных решений, используя формальный процесс оценки, который оценивает выявленные альтернативы на основе установленных критериев.

Вступительный комментарий

Процессная область Анализ и Принятия Решений включает в себя процесс установки руководящих принципов для того, чтобы определить, какие вопросы должны быть предметом формального процесса оценки, и применения формальных процессов оценки по этим вопросам.

Формальный процесс оценки представляет собой структурированный подход к оценке альтернативных решений с учетом установленных критериев для определения рекомендованных решений.

Формальный процесс оценки включает в себя следующие действия:

  • Установка критериев оценки альтернатив
  • Определение альтернативных решений
  • Выбор методов оценки альтернатив
  • Оценка альтернативных решений с использованием установленных критериев и методов
  • Выбор рекомендуемых решений из альтернатив на основе критериев оценки

Вместо того чтобы каждый раз использовать фразу «альтернативные решения для решения вопросов» в этой процессной области будет использоваться одна из двух коротких фраз: «альтернативные решения» или «альтернативы».

Формальный процесс оценки снижает субъективный характер принятия решений и обеспечивает более высокую вероятность выбора решения, отвечающего различным требованиям соответствующих заинтересованных сторон.

Хотя главное применение этой процессной области заключается в технических проблемах, формальные процессы оценки могут быть применены ко многим нетехнических вопросам, в частности, когда проект находится в стадии планирования. Вопросы, которые имеют несколько альтернативных решений и критерии оценки, поддаются формальной процедуре оценки.

Поиск лучшего решения для оборудования или программного обеспечения являются типичными примерами формальных процессов оценки.

Во время планирования определяются конкретные вопросы, требующие формального процесса оценки. Типичные вопросы включают отбор среди архитектурных и альтернатив проектирования, использование многоразовых или коммерческих готовых компонентов, выбор поставщика, условий технической поддержки или связанные с ними инструменты, тестовые среды, поставка альтернатив, а также логистика и производство. Формальный процесс оценки может также быть использован для принятия решения сделать-или-купить, разработки процессов производства, выбор мест распространения, а также другие решения.

Руководство создается для принятия решения, когда следует использовать формальные процессы оценки для решения незапланированных вопросов. Руководство часто предлагают использовать формальные процессы оценки, когда вопросы связаны с рисками со средним-высоким уровнем влияния или когда проблемы влияют на возможность достижения целей проекта.

Определение вопросов хорошо помогает определить границы альтернатив, подлежащих рассмотрению. Правильные границы (т.е. не слишком широкие, не слишком узкие) помогут при принятии соответствующего решения для решения выделенных вопросов.

Формальные процессы оценки могут варьироваться в формальности, типа критериев и методов. Менее формальные решения могут быть проанализированы в течение нескольких часов, используя несколько критериев (например, эффективность, стоимость реализации), и результатом чего будет одно или двухстраничный отчет. Для более формальных решений может потребоваться отдельное планирование, месяцы работы, встречи для разработки и утверждения критериев, моделирования, прототипов, пилотов и подробной документации.

Оба, числовые и нечисловые критерии, могут быть использованы в формальном процессе оценки. Числовые критерии используют вес с учетом относительной важности критериев. Нечисловые критерии используют субъективное ранжирование масштаба (например, высокий, средний, низкий). Более формальные решения могут требовать полного отраслевого обследования.

Формальный процесс оценки выявляет и оценивает альтернативные решения. Возможный выбор решения может включать в себя итерационную деятельность идентификации и оценки. Части определенных альтернатив могут быть скомбинированы, новые технологии могут изменить альтернативы, а также бизнес-ситуации поставщиков могут меняться в течение периода оценки.

Альтернативы рекомендуется сопровождаться документированием выбранных методов, критериев, альтернатив и обоснования рекомендаций. Документация распространяется среди соответствующих заинтересованных сторон, она обеспечивает запись формального процесса оценки и обоснования, что будет полезно для других проектов, которые могут столкнуться с аналогичной проблемой.

Некоторые из решений, принятых в течение всего времени действия проекта связаны с использованием формального процесса оценки, другие нет. Как уже упоминалось ранее, руководящие принципы должны быть созданы, чтобы определить, какие вопросы должны быть предметом формального процесса оценки.

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

См. процессную область Комплексное Управление Проектом для получения дополнительной информации о создании определенного процесса проекта.

См. процессную область Управление Рисками для получения дополнительной информации об определении и анализе рисков и снижении рисков.

Перечень специфических целей и практик

  • СЦ 1 Оценить Альтернативы
    • СП 1.1 Разрабатывайте Руководства для Анализа Решений
    • СП 1.2 Устанавливайте Критерии Оценки
    • СП 1.3 Определяйте Альтернативные Решения
    • СП 1.4 Выберите Методы Оценки
    • СП 1.5 Оценивайте Альтернативные Решения
    • СП 1.6 Выберите Решения

Специфические практики по целям

СЦ 1 Оценить Альтернативы

Решения приняты на основе оценки альтернатив с использованием установленных критериев.

Вопросы, требующие формального процесса оценки, могут быть идентифицированы в любое время. Цель заключается в выявлении таких вопросов, как можно раньше, чтобы максимизировать возможное время для их решения.

СП 1.1 Разрабатывайте Руководства для Анализа Решений

Создавайте и поддерживайте принципы для определения, какие вопросы могут иметь формальный процесс оценки.

Не каждое решение может быть достаточным, чтобы требовать формального процесса оценки. Выбор между тривиальным и действительно важным вопросом неочевиден без явного руководства. В любом случае, решение существенно или нет, это обуславливается проектом и обстоятельствами и определяется установленными правилами.

Типичные руководства для определения того, что требуется формальный процесс оценки, включают следующее:

  • Решение напрямую связано с вопросами, которые имеют риск от среднего до высокого уровня влияния.
  • Решение, связанно с изменением рабочих продуктов, которые находятся под управлением конфигурацией.
  • Решение вызовет отставание от графика на определенный процент или количество времени.
  • Решение влияет на достижение целей проекта.
  • Расходы на формальный процесс оценки являются обоснованными по сравнению с воздействием решения.
  • Существуют юридические обязательства в требованиях.
  • Когда конкурирующие требования к атрибутам качества могут привести к отличной архитектурной альтернативе.

См. процессную область Управление Рисками для получения дополнительной информации об оценке, классификации и установке приоритетов для рисков.

Примеры деятельностей, которые могут использовать формальный процесс оценки, включают следующие:

  • Принятие решений, связанных с закупкой материала, когда 20 процентов партии материала составляет 80 процентов от общей стоимости материалов
  • Принятия решения по проектированию, когда проблемы технической производительности могут вызвать катастрофический сбой (например, безопасность полетов)
  • Принятие решений, способных существенно снизить риск проектирования, инженерных изменений, время цикла, время отклика и стоимости производства (например, использовать литографические модели для оценки формы и соответствия возможности перед выпуском инженерных чертежей и производственных сборок)

Пример рабочих продуктов

1. Руководство для принятия решения, когда необходимо применять формальный процесс оценки

Подпрактики

1. Разрабатывайте руководства для принятия решения, когда необходимо использовать формальный процесс оценки.

2. Включайте использование руководящих принципов в определенный процесс по мере необходимости.

См. процессную область Комплексное Управление Проектом для получения дополнительной информации о создании определенного процесса проекта.

СП 1.2 Устанавливайте Критерии Оценки

Создавайте и поддерживайте критерии оценки альтернатив и относительный ранг этих критериев.

Критерии оценки служат основой для оценки альтернативных решений. Критерии ранжируются так, что самый высокий ранг критерия оказывает наибольшее влияние на оценки.

На эту процессную область ссылаются во многих других процессных областях в модели, и существует много контекстов, в которых формальный процесс оценки может использоваться. Поэтому в некоторых ситуациях может оказаться, что критерии уже были определены как часть другого процесса. Данная практика не предполагает, что разработка критериев должна проводиться заново.

Четко определенная постановка вопроса для рассмотрения и решения для принятия фокусируют анализ, который должен быть выполнен. Такая постановка также помогает в определении критериев оценки, которые сводят к минимуму возможность того, что решения будет повторно приниматься или что основания для принятия решения будут забыты. Решения, основанные на критериях, которые четко определены и установлены, устраняют барьеры для заинтересованных сторон.

Пример рабочих продуктов

1. Документированные критерии оценки

2. Ранги важности критериев

Подпрактики

1. Определяйте критерии оценки альтернативных решений.

Критерии должны быть связаны с требованиями, сценариями, экономическим обоснованием, бизнес-целями или другими документальными источниками.

Типы критериев, которые следует рассмотреть следующее:

  • Технологические ограничения
  • Воздействие на среду
  • Риски
  • Бизнес-значение
  • Влияние на приоритеты
  • Общая доступность и стоимость жизненного цикла

2. Определяйте ранг и величину для ранжирования критериев оценки.

Величина относительной значимости критериев оценки может быть установлена с не численными значениями или с помощью формул, которые касаются оценки числового веса параметра.

3. Ранжируйте критерии.

Критерии ранжируются в соответствии с определенным рангом и величиной с учетом потребностей, целей и приоритетов заинтересованных сторон.

4. Оценивайте критерии и их относительную важность.

5. Выявляйте критерии оценки для улучшения их достоверности.

6. Документируйте обоснование выбора и отказа от критериев оценки.

Документирование критериев отбора и обоснования могут быть необходимы для обоснования решений или для использования в их будущем.

СП 1.3 Определяйте Альтернативные Решения

Определяйте альтернативные подходы к решению вопросов.

Широкий круг альтернатив может быть обнаружен с привлечением стольких заинтересованных сторон, насколько это практически оправдано. Вклад со стороны заинтересованных сторон с различными навыками и опытом может помочь командам определить и устранить допущения, ограничения и погрешности. Сессии мозгового штурма могут стимулировать инновационные альтернативы за счет быстрого взаимодействия и обратной связи.

Для анализа может быть передано не достаточно кандидатов для решений. В течение анализа другие альтернативы должны быть добавлены к списку возможных кандидатов решений. Генерация и рассмотрение различных альтернатив в начале анализа решений и процесс принятия решения увеличивает вероятность того, что приемлемое решение будет принято, и что последствия этого решения будут поняты.

Пример рабочих продуктов

1. Выявленные альтернативы

Подпрактики

1. Выполняйте поиск существующих материалов.

Поиск существующих материалов поможет обнаружить, что делали другие и внутри и вне организации. Такой поиск может дать более глубокое понимание проблемы, альтернативы для рассмотрения, препятствия на пути реализации, существующий поиск лучших решений и уроки, извлеченные из аналогичных решений.

2. Определяйте альтернативы для рассмотрения в дополнение к альтернативам, которые могут быть предоставлены с вопросом.

Критерии оценки – это эффективная отправная точка для поиска альтернатив. Критерии оценки определяют приоритеты соответствующих заинтересованных сторон и важность с технической, материально-технической стороны или другие проблемы.

Объединение ключевых атрибутов существующих альтернатив может создать дополнительные, а иногда и более сильные альтернативы.

Запрашивайте альтернативы от соответствующих заинтересованных сторон. Сессии мозгового штурма, интервью и рабочие группы могут быть эффективно использованы для поиска альтернатив.

3. Документируйте предложенные альтернативы.

СП 1.4 Выберите Методы Оценки

Выберите методов оценки.

Методы оценки альтернативных решений с учетом установленных критериев могут варьироваться от моделирования с использованием вероятностных моделей и теории принятия решений. Эти методы должны быть тщательно отобраны. Уровень детализации метода должен быть соизмерим со стоимостью, планированием, исполнением и влиянием риска.

Хотя многие проблемы могут потребовать только один метод оценки, некоторые проблемы могут потребовать несколько методов. Например, моделирование может расширить отраслевое обследование, чтобы определить, какой проект альтернативы наилучшим образом соответствует данному критерию.

Пример рабочих продуктов

1. Выбранные методы оценки

Подпрактики

1. Выбирайте методы, основываясь на целях анализа решения и доступности информации, используемой для поддержки метода.

Например, методы, используемые для оценки решения, когда требования слабо определены, могут отличаться от методов, используемых при четко определенных требованиях.

Типичные методы оценки включают следующее:

  • Тестирование
  • Моделирование и имитация
  • Инженерные исследования
  • Производственные исследования
  • Оценка затрат
  • Изучение возможностей бизнеса
  • Опросы
  • Экстраполяция на основе опыта работы на местах и прототипы
  • Рецензии и комментарии конечных пользователей
  • Решения, предоставляемые экспертами или группой экспертов (например, метод Делфи)

2. Выбирайте методы оценки на основе их способности сосредоточиться на существующих вопросах, не будучи чрезмерно под влиянием второстепенных вопросов.

Результаты моделирования могут быть искажены в результате случайных действий в решении, которые непосредственно не связаны с существующими вопросами.

3. Определите меры, необходимые для поддержки метода оценки.

Рассматривайте влияние на стоимость, график, выполнение и риски.

СП 1.5 Оценивайте Альтернативные Решения

Оценивайте альтернативные решения с использованием установленных критериев и методов.

Оценка альтернативных решений включает в себя анализ, обсуждение и рецензирование. Иногда необходимы итерационные циклы анализа. Поддержка анализов, экспериментов, прототипов, пилотирования или моделирования могут быть необходимы для обоснования выгоды и выводов.

Часто, относительная важность критериев является неточным и общей влияние на решение не является очевидным, пока не выполнен анализ. В случаях, когда результаты оценки сравнительно слабо отличаются, сделать лучший выбор среди альтернативных решений может быть сложно. Предложения для критериев и предположений должны поощряться.

Пример рабочих продуктов

1. Результаты оценки

Подпрактики

1. Оценивайте предлагаемые альтернативные решения с использованием установленных критериев оценки и выбранных методов.

2. Оценивайте допущения, связанные с критериями оценки, и доказательства того, что поддерживает предположения.

3. Оценивайте, влияет ли неопределенность значений для альтернативных решений на оценку, и решайте эти неопределенности по мере необходимости.

Например, если оценка колеблется между двумя значениями, разница достаточно существенна, чтобы изменить окончательный набор решения? Есть ли вариации в количественном значении представляющие высокое влияние риска? Для решения этих проблем, моделирование может быть использовано, дальнейшие исследования могут быть выполнены или критерии оценки могут быть изменены и т.д.

4. Выполняйте симуляции, моделирование, прототипирование, и проведение пилотов, которые необходимы для осуществления критериев оценки, методов и альтернативных решений.

Непроверенные критерии, их относительной важность, а также соответствующие данные или функции могут поставить правильность решения под сомнение. Критерии и их относительные приоритеты и величина могут быть проверены с помощью пробных пусков для множества альтернатив. Эти пробные пуски выбранных наборов критериев позволяют оценить кумулятивное воздействие критериев решения. Если пробные пуски выявляют проблемы, другие критерии или альтернативы могут рассматриваться для избегания погрешности.

5. Рассматривайте новые альтернативные решения, критерии или методы, если предлагаемые альтернативы не проходят тесты достаточно хорошо, повторяйте оценки альтернатив пока тест не пройдет.

6. Документируйте результаты оценки.

Документируйте обоснование добавление новых альтернатив или методов и изменения в критерии, а также результаты предварительных оценок.

СП 1.6 Выберите Решения

Выберите решения из альтернатив на основе критериев оценки.

Выбор решения включает в себя результаты взвешивания оценки альтернатив. Риски, связанные с осуществлением решения должны быть оценены.

Пример рабочих продуктов

1. Рекомендуемые решения для решения важных вопросов

Подпрактики

1. Оценивайте риски, связанные с реализации рекомендованных решений.

См. процессную область Управление Рисками для получения дополнительной информации о выявлении и анализе рисков и смягчении рисков.

Решения часто должны быть сделаны с неполной информацией. Здесь может быть существенный риск, связанный с решениями, которые имеют неполную информацию.

Когда решения должны приниматься в соответствии с определенным графиком, время и ресурсы могут быть недоступны для сбора полной информации. Следовательно, рискованные решения, принятые с неполной информацией могут потребовать повторного анализа позже. Выявленные риски должны быть проверены.

2. Документируйте и передавайте соответствующим заинтересованным сторонам результаты и обоснование для рекомендуемых решений.

Очень важно зафиксировать, и почему решение выбрано, и почему другое решение было отклонено.

Реклама

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , , , | 2 комментария »

CMMI DEV v1.3 – Техническое Решение

Posted by Шамрай Александр на Июнь 27, 2011

Перевод Шамрай А.В.

Инженерная Процессная область уровня зрелости 3

Назначение

Назначением Технического Решения (ТР) является выбор, проектирование и применение решений для требований. Решения, результаты проектирования и реализации охватывают по отдельности или в соответствующей комбинации продукт, компоненты продукта и связанные с продуктом процессы жизненного цикла.

Вступительный комментарий

Процессная область Техническое Решение применима на любом уровне архитектуры продукта и для любого продукта, компонента продукта и связанного с продуктом процесса жизненного цикла. В процессных областях, когда используются термины «продукт» и «компонент продукта», их предполагаемым значением также покрываются услуги, системы обслуживания и их компоненты.

Эта процессная область фокусируется на следующем:

  • Оценка и выбор решений (иногда известные как «подходы к проектированию», «концепция проектирования» или «предварительное проектирование»), которые потенциально удовлетворяют соответствующему набору обнаруженных функциональных требований и требований к атрибутам качества
  • Выполнение детализированного проектирования для выбранного решения (подробного в контексте содержащего все сведения необходимые для производства, кодирования или иного образа преобразования результатов проектирования в продукт или компонент продукта)
  • Реализация результатов проектирования в виде продукта или компонента продукта

Как правило, эти мероприятия интерактивно поддерживают друг друга. Для того, чтоб иметь возможность выбрать решение, некоторые уровни проектирования должны быть должным образом детализированы. Прототипы или пилоты могут использоваться в качестве методов для получения достаточных знаний для разработки пакетов технических данных или для обеспечения полного набора требований. Модели атрибутов качества, симуляции, прототипы или пилоты могут быть использованы для получения дополнительной информации о свойствах потенциальных решений проектирования, чтобы помочь в выборе решения. Моделирование может быть особенно полезно для проектов разработки систем-из-систем.

Специфические практики Технического Решения применимы не только к продукту и компонентам продукта, но и к процессам, связанным с жизненным циклом продукта. Процессы, связанные с жизненным циклом продукта разрабатываются согласно с продуктом или компонентами продукта. Такая разработка может включать в себя выбор и адаптацию существующих процессов (в том числе стандартных процессов) для использования, а также разработку новых процессов.

Процессы, связанные с процессной областью Техническое Решение, получают требования к продукту и требования к компонентам продукта из процессов управления требованиями. Процессы управления требованиями устанавливают требования, которые возникают в процессах разработки требований, при соответствующем управлении конфигурацией и поддержке их трассировки к предыдущим требованиям.

Для проектов технического обслуживания или сопровождения, требования, которые нуждаются в поддержке или пере-проектировании, могут быть обусловлены потребностями пользователей, технологиями созревания и устаревания или скрытыми дефектами в компонентах продукта. Новые требования могут возникнуть в результате изменений в операционной среде. Такие требования могут быть обнаружены в процессе верификации продукта(ов), где его фактическая производительность может сравниваться с его необходимой производительностью и может быть идентифицирована неприемлемая деградация. Процессы, связанные с процессной областью Техническое решение, должны использоваться для обеспечения усилий технического обслуживания или сопровождения в области проектирования.

Для линейки продуктов такая практика применяется для разработки основных активов (например, построение для повторного использования) и разработки продуктов (например, построение с повторным использованием). Разработка основного актива дополнительно требует управления вариациями линейки продукта (механизмы выбора и внедрения вариации линейки продукта) и планирования производства линейки продукта (разработка процессов и других рабочих продуктов, которые определяют, как продукция будет построена с целью наилучшего использования этих основных активов).

В Agile среде акцент устанавливается на раннем исследовании решения. Делая выбор и альтернативные решения более явными, процессная область Техническое решение помогает улучшить качество этих решений, как индивидуально, так и с течением времени. Решения могут быть определены в терминах функций, набора функций, релизов или любых других компонентов, которые облегчают разработку продукта. Когда кто-то другой, а не команда, будет работать с продуктом в будущем, информация о релизе, протоколы обслуживания и другие данные, как правило, должны включаться в установленный продукт. Для поддержки будущих обновлений продукта приводятся обоснования (для альтернатив, интерфейсов и покупных частей), чтоб было лучше понятно как продукт работает. Если выбранное решение имеет низкий риск, то необходимость формального описания решений значительно уменьшается. (См. «CMMI при использовании Agile подходов» в части I.)

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

См. процессную область Разработка Требований для получения дополнительной информации о выявлении требований к компонентам продута, создание операционных концепций и сценариев, а также выявления требований к интерфейсам.

См. процессную область Верификация для получения дополнительной информации о выполнении коллегиальных оценок и проверки отдельных рабочих продуктов.

См. процессную область Анализ и Принятие Решений для получения дополнительной информации об анализе возможных решений, используя формальный процесс оценки, которая оценивает выявленные альтернативы по установленным критериям.

См. процессную область Управление Показателями Организации для получения дополнительной информации о выборе улучшений и внедрения улучшений.

См. процессную область Управление Требованиями для получения дополнительной информации об управлении требованиями продукта и компонента продукта проекта и обеспечения соответствия между этими требованиями, планами проекта и рабочими продуктами

Перечень специфических целей и практик

  • СЦ 1 Выбрать Решения для Компонентов Продукта
    • СП 1.1 Разрабатывайте Альтернативные Решения и Критерии Выбора
    • СП 1.2 Выбирайте Решения для Компонентов Продукта
  • СЦ 2 Выполнить Проектирование
    • СП 2.1 Проектируйте Продукт и Компоненты Продукта
    • СП 2.2 Устанавливайте Пакеты Технических Данных
    • СП 2.3 Проектируйте Критерии Использования Интерфейсов
    • СП 2.4 Выполняйте Анализ Разработки, Покупки или Повторного Использования
  • СЦ 3 Реализовать Результаты Проектирования Продукта
    • СП 3.1 Реализовывайте Результаты Проектирования
    • СП 3.2 Разрабатывайте Документацию Поддержки Продукта

Специфические практики по целям

СЦ 1 Выбрать Решения для Компонентов Продукта

Решения для продукта или компонента продукта выбраны из альтернативных решений.

Перед выбором решения рассматриваются альтернативные решения и их относительные достоинства. Основные требования, вопросы проектирования и ограничения устанавливаются для использования при анализе альтернативного решения. Рассматриваются архитектурные решения и шаблоны, которые помогают достичь требования к атрибутам качества. Кроме того, использование готовых коммерческих компонентов продукта рассматриваются относительно затрат, сроков, разработки и риска. Готовые коммерческие альтернативы могут быть использованы с или без изменений. Иногда такие элементы могут потребовать внесения изменений в такие аспекты, как интерфейсы или настройки некоторых возможностей, чтобы исправить несоответствия с функциональными требованиями или требованиями к атрибутам качества, или с проектом архитектуры.

Одним из показателей хорошего процесса проектирования является то, что решение для проектирования было выбрано после его сравнения и оценки среди альтернативных решений. Вопросы по архитектуре, выбор разработки или готовый продукт и модульность компонентов продукта характерны для вопросов для решений по проектированию. Некоторые из этих решений могут потребовать использования формального процесса оценки.

См. процессную область Анализ и Принятие Решения для получения дополнительной информации об анализе возможных решений, используя формальный процесс оценки, которая оценивает выявленные альтернативы по установленным критериям.

Иногда поиск решений рассматривает альтернативные экземпляры одного и того же требования без его распределения на низкий уровень компонентов продукта. Такой вариант может иметь место в основе архитектуры продукта. Есть также случаи, когда фиксируются одно или несколько решений (например, определенное решение выбрано для использования или доступные компоненты продукта, такие как готовые коммерческие, обследованы для использования).

В общем случае, решения определяются как набор. То есть, при определении следующего слоя компонентов продукта, устанавливается решение для каждого из компонентов продукта в наборе. Альтернативные решения это не только различные подходы к решению тех же требований, но они также отражают различные распределения требований по компонентам продукта, включающих набор решения. Цель состоит в оптимизации набора в целом, а не отдельных частей. Здесь будет значительное взаимодействие с процессами, связанными с процессной областью Разработка Требований, для поддержки предварительного распределения по компонентам продукта до тех пор, пока набор решения не выбран и не установлено окончательное распределение.

Процессы, связанные с жизненным циклом продукта, устанавливаются на основе решений компонентов продукта, которые выбираются из альтернативных решений. Примерами таких процессов, связанных с жизненным циклом продукта, являются процессы производства, поставки и поддержки.

СП 1.1 Разрабатывайте Альтернативные Решения и Критерии Выбора

Разрабатывайте альтернативные решения и критерии выбора.

См. специфическую практику Распределяйте Требования к Компонентам Продукта в процессной области Разработка Требований для получения дополнительной информации о получении распределения требований по альтернативам решения для компонентов продукта.

См. процессную область Анализ и Принятие Решений для получения дополнительной информации об установке критериев оценки.

Альтернативные решения должны быть определены и проанализированы для того чтобы выбрать сбалансированное решение с учетом жизни продукта с точки зрения затрат, сроков, выполнения и риска. Эти решения основаны на предложенных архитектурных решениях продукта, которые направлены на удовлетворение важнейших требований к атрибутам качества продукта и ограничение пространства для проектирования допустимых решений. Специфические практики, связанные со специфической целью Выполнить Проектирование, обеспечивают больше информации о разработке потенциальных архитектурных решений продукта, которые могут быть включены в альтернативные решения для продукта.

Альтернативные решения часто включают альтернативные распределения требований по различным компонентам продукта. Эти альтернативные решения могут также включать в себя использование готовых коммерческих решений в архитектуре продукта. Процессы, связанные с процессной областью Разработка Требований, в дальнейшем будут использоваться для обеспечения более полного и устойчивого предварительного распределения требований по альтернативным решениям.

Альтернативные решения охватывают приемлемый диапазон затрат, сроков и исполнения. Требования к компонентам продукта получены и используются наряду с вопросами проектирования, ограничений и критериев для разработки альтернативных решений. Критерии выбора, как правило, затрагивают затраты (например, время, люди, деньги), выгоды (например, эксплуатационные характеристики продукта, возможности, эффективность) и риски (например, технические, стоимость, график). Вопросы альтернативных решений и критериев отбора включают следующие:

  • Стоимость разработки, производства, закупки, технического обслуживания и поддержки
  • Достижение ключевых требований к атрибутам качества, таким как время реакции продукта, безопасность, надежность и восстанавливаемость
  • Сложность процессов жизненных циклов компонента продукта и продукта
  • Стабильность к операционному использованию продукта и условиям использования, режимам работы, среде и изменениям в процессах, связанных с жизненным циклом продукта
  • Расширение и развитие продукта
  • Технологические ограничения
  • Чувствительность к методам и материалам построения
  • Риск
  • Эволюция требований и технологий
  • Размещение
  • Возможности и ограничения для конечных пользователей и операторов
  • Характеристики готовых коммерческих продуктов

Вопросы, перечисленные выше, представляют базовый набор; организации должны разрабатывать критерии отбора, чтобы сузить список альтернатив, которые соответствуют их бизнес-целям. Стоимость жизненного цикла продукта, параметр который желательно свести к минимуму, может быть вне контроля организации разработки. Заказчик может быть не готов платить за функции, которые стоят больше в краткосрочной перспективе, но в конечном итоге снижают затраты в течение срока действия продукта. В таких случаях заказчики должны быть хотя бы информированы о любых потенциальных возможностях для снижения стоимости жизненного цикла. Критерии, используемые для выбора окончательного решения, должны обеспечить сбалансированный подход к расходам, выгодам и рискам.

Пример рабочих продуктов

1. Критерии отбора для альтернативного решения

2. Отчеты об оценке новых технологий

3. Альтернативные решения

4. Критерии выбора для окончательного выбора

5. Отчеты об оценке готовых коммерческих продуктов

Подпрактики

1. Определяйте для рассмотрения критерии отбора для выбора набора альтернативных решений.

2. Выявляйте технологии, используемые в настоящее время, и новые технологии для продукта для достижения конкурентного преимущества.

См. процессную область Управление Показателями Организации для получения дополнительной информации о выборе улучшений и внедрения улучшений.

Проект должен определить технологии, применяемые для уже существующих продуктов и процессов, и следить за прогрессом технологий, которые в настоящее время используются, в течение всего срока проекта. Проект должен определять, отбирать, оценивать и инвестировать в новые технологии для достижения конкурентного преимущества. Альтернативные решения могут включать новые разработанные технологий, но также можно включать применение зрелых технологий в различных приложениях или для поддержания существующих методов.

3. Определяйте кандидатов готовых коммерческих продуктов, которые удовлетворяют требованиям.

См. процессную область Управление Соглашениями с Поставщиками для получения дополнительной информации о выборе поставщиков.

Поставщик готового коммерческого продукта должен удовлетворить требования, которые включают следующее:

  • Функциональность продукта и атрибуты качества
  • Сроки и условия гарантийных обязательств для продукта
  • Ожидания (например, включение деятельности рецензирования), ограничения или контрольный список, которые помогают смягчить ответственность поставщиков за текущее обслуживание и поддержку продуктов

4. Определяйте компоненты решения для повторного использования или применимые архитектурные шаблоны.

Для линейки продукта, основные активы организации могут быть использованы в качестве основы для решения.

5. Генерируйте альтернативные решения.

6. Получайте полное распределение требований для каждой альтернативы.

7. Разрабатывайте критерии для отбора лучшего альтернативного решения.

Критерии должны включать вопросы, которые связаны с проблемами проектирования для жизни продукта, такие как положения для более легкой вставки новых технологий или способность более эффективного использования коммерческих продуктов. Примеры включают критерии, связанные с открытыми концепциями проектирования или архитектуры для оценки альтернатив.

СП 1.2 Выбирайте Решения Компонента Продукта

Выбирайте решения компонента продукта, основываясь на критериях отбора.

См. специфические практики Распределяйте Требования к Компонентам Продукта и Идентифицируйте Требования к Интерфейсам в процессной области Разработка Требований для получения дополнительной информации о получении распределенных требований к компонентам продукта и требований интерфейсам по компонентам продукта.

Выбор компонентов продукта, которые наилучшим образом удовлетворяют критериям, устанавливает распределения требований на компоненты продукта. Требования низкого уровня создаются из выбранной альтернативы и используются для проектирования компонента продукта. Интерфейсы для компонентов продукта описываются. Физическое описание интерфейсов включается в документацию для описания взаимодействия с внешними, по отношению к продукту, элементами и деятельностями.

Описание решений и обоснование выбора документируются. Документация развивается по мере того как решения и подробное проектирование выполняется и результаты этого проектирование реализовываются. Поддержка записей обоснования имеет решающее значение для принятия решений в дальнейшем. Такие записи в дальнейшем позволяют заинтересованным сторонам не переделать работу и дать представление о применении технологии по мере наступления условия для применения.

Пример рабочих продуктов

1. Решения и обоснование о выборе компонента продукта

2. Документированные связи между требованиями и компонентами продукта

3. Документированные решения, оценки и обоснования

Подпрактики

1. Оценивайте каждое альтернативное решение/множество решений на основе критериев выбора, установленных в контексте операционных концепций и сценариев.

Разрабатывайте операционные сценарии работы с продуктом и взаимодействия с пользователем для каждого альтернативного решения.

2. Оценивайте адекватность критериев отбора на основе оценки альтернатив и обновляйте эти критерии в случае необходимости.

3. Выявляйте и решайте проблемы с альтернативными решениями и требованиями.

4. Выбирайте лучший набор альтернативных решений, которые удовлетворяют установленным критериям отбора.

5. Устанавливайте функциональные и требования к атрибутам качества, связанные с выбранным набором альтернатив, как множество распределенных требований по тем компонентам продукта.

6. Определяйте решения компонента продукта, которые будут повторно использоваться или приобретаться.

См. процессную область Управление Соглашениями с Поставщиками для получения дополнительной информации об управлении приобретением товаров и услуг от поставщиков.

7. Создавайте и поддерживайте документацию о решениях, оценках и обоснованиях.

СЦ 2 Выполнить Проектирование

Выполнено проектирование продукта и компонентов продукта.

Проектирование продукта или компонента продукта должно обеспечивать соответствующее описание не только для реализации, но и для других этапов жизненного цикла продута, таких как модификация, переприобретение, обслуживание, восстановление и инсталляция. Документация проектирования обеспечивает описание для поддержки взаимного понимания проектирования соответствующими заинтересованными сторонами и поддерживает будущие изменения в результаты проектирования, как в ходе разработки, так и в последующих этапах жизненного цикла продукта. Полное описание результатов приводится в пакетах технических данных, которые включают в себя полный набор функций и параметров, включая форму, комплектацию, функции, интерфейс, характеристики производственного процесса и другие параметры. Созданные организационные или проектные стандарты (например, контрольные списки, шаблоны, объектные платформы) обеспечивают основу для достижения высокой степени определенности и полноты в документации проектирования.

СП 2.1 Проектируйте Продукт и Компонент Продукта

Выполняйте проектирование для продукта и компонента продукта.

Проектирование продукта состоит из двух широких фаз, которые могут перекрываться в исполнении: предварительное и детальное проектирование. Предварительное проектирование устанавливает возможности продукта и архитектуру продукта, в том числе архитектурные стили и шаблоны, разделение продукта, идентификацию компонентов продукта, состояния и режимы системы, основные межкомпонентные интерфейсы и внешние интерфейсы продукта. Детальное проектирование полностью определяет структуру и возможности компонентов продукта.

См. специфическую практику Устанавливайте Определение Необходимой Функциональности и Атрибутов Качества в процессной области Разработка Требований для получения дополнительной информации о разработке архитектурных требований.

Определение архитектуры исходит из множества архитектурных требований, разработанных в процессе разработки требований. Эти требования определяют атрибуты качества, которые имеют решающее значение для успеха продукта. Архитектура определяет структурные элементы и механизмы координации, которые либо непосредственно удовлетворяют требованиям либо поддерживают достижение требований по мере того как детализируются результаты проектирования продукта. Архитектура может включать в себя стандарты и правила проектирования, управляя разработкой компонентов продукта и их интерфейсов, а также выступая в качестве вспомогательного руководства для разработчиков продукта. Специфические практики специфической цели Выбрать Решения Компонента Продукта содержат больше информации об использовании архитектуры продукта в качестве основы для альтернативных решений.

Архитекторы обуславливают и разрабатывают модель продукта, принимают решения о распределении функциональных и требований к атрибутам качества компонентов продукта, включая аппаратное и программное обеспечение. Могут быть разработаны и проанализированы несколько архитектур, поддерживающих альтернативные решения, чтобы определить преимущества и недостатки в контексте архитектурных требований.

Операционные концепции и сценарии операционного взаимодействия, восстановления и разработки используются для создания вариантов использования и сценариев, связанных с атрибутами качества, которые используются для уточнения архитектуры. Они также используются в качестве средства для оценки пригодности архитектуры по их прямому назначению во время оценивания архитектуры, которое проводится периодически в течение проектирования продукта.

См. специфическую практику Устанавливайте Операционные Концепции и Сценарии в процессной области Разработка Требований для получения дополнительной информации о разработке операционных концепций и сценариев, используемых для оценки архитектуры.

Примеры задач определения архитектуры включают следующее:

  • Установка структурных связей частей и правил, касающихся взаимодействия между элементами внутри частей и между частями
  • Выбор архитектурных шаблонов, которые поддерживают функциональные и требования к атрибутам качества, и инсталляция или композиция этих шаблонов для создания архитектуры продукта
  • Выявление основных внутренних интерфейсов и всех внешних интерфейсов
  • Определение компонентов продукта и интерфейсов между ними
  • Формальное определение поведения компонентов и взаимодействия с использованием языка описания архитектуры
  • Определение координационных механизмов (например, программное обеспечение, аппаратное обеспечение)
  • Установка инфраструктурных возможностей и сервисов
  • Разработка шаблонов компонента продукта или классов и структур
  • Установка правил проектирования и полномочий для принятия решений
  • Определение модели процесса/потока
  • Определение физического развертывания программного обеспечения на аппаратные средства
  • Выявление основных подходов и источников повторного использования

Во время выполнения детального проектирования, детали архитектуры продукта будут завершены, компоненты продукта полностью определены и интерфейсы полностью характеризуются. Проектирование компонента продукта может быть оптимизировано для определенных атрибутов качества. Проектировщики могут оценивать использование наследования и готовых коммерческих продуктов для компонентов продукта. По мере того как проектирование созревает, требования, назначенные на нижний уровень компонентов продукта, отслеживаются, чтобы обеспечить выполняемость этих требований.

См. процессную область Управление Требованиями для получения дополнительной информации об обеспечении соответствия между проектными работами и требованиями.

Для разработки программного обеспечения детальное проектирование ориентировано на разработку программного обеспечения компонентов продукта. Внутренняя структура компонентов продукта определяется, формируются схемы данных, разрабатываются алгоритмы и устанавливаются эвристики для того, чтобы обеспечить возможности компонентов продукта, которые удовлетворяют установленным требованиям.

Для аппаратного обеспечения детальное проектирование ориентировано на разработку электронных, механических, электрооптических и других аппаратных продуктов и их компонентов. Разрабатываются электрические схемы и диаграммы взаимосвязей, создаются механические и оптические модели сборки и разрабатываются процессы изготовления и монтажа.

Пример рабочих продуктов

1. Архитектура продукта

2. Технический проект компонента продукта

Подпрактики

1. Создавайте и поддерживайте критерии, по которым проектирование может быть оценено.

Примерами атрибутов качества, в дополнение к ожидаемой производительности продукта, для которых критерии проектирования могут быть установлены, включают следующее:

  • Модульность
  • Прозрачность
  • Простота
  • Сопровождаемость
  • Проверяемость
  • Портативность
  • Надежность
  • Точность
  • Безопасность
  • Масштабируемость
  • Простота использования

2. Определяйте, разрабатывайте или приобретайте методы проектирования подходящие для продукта.

Эффективные методы проектирования могут воплощаться широким спектром деятельностей, инструментов и описательных техник. Является ли данный метод эффективным или нет, зависит от ситуации. Две компании могут иметь эффективные методы проектирования для продуктов, в которых они специализируются, но эти методы не могут быть эффективными в совместных предприятиях. Высоко сложные методы не всегда эффективны в руках проектировщиков, которые не были обучены в использовании методов.

Эффективен ли метод также зависит от того сколько помощи он предоставляет проектировщику и от экономической эффективности такой помощи. Например, многолетние усилия по прототипированию могут быть неподходящими для простых компонентов продукта, но могут быть подходящими для разработки беспрецедентного, дорогого и сложного продукта. Однако техники быстрого прототипирования могут быть весьма эффективным для многих компонентов продукта. Методы, которые используют инструменты для обеспечения того, чтобы проектирование охватывало все необходимые атрибуты, которые необходимы для реализации компонента продукта, могут быть эффективными. Например, инструмент проектирования, который «знает» возможности производственных процессов может позволить учитывать вариабельность производственного процесса при проектировании допусков.

Примеры способов и методов, которые способствуют эффективному проектированию, включают следующее:

  • Прототипы
  • Структурные модели
  • Объектно-ориентированное проектирование
  • Анализ основных систем
  • Модели связей сущностей
  • Проектирование для повторного использования
  • Шаблоны проектирования

3. Убедитесь, что проектирование придерживается стандартам и критериям проектирования.

Примеры стандартов проектирования включают следующие (все или некоторые из этих стандартов могут быть критериями проектирования, особенно в тех случаях, когда стандарты не были установлены):

  • Стандарты Интерфейсов оператора
  • Тестовые сценарии
  • Стандарты безопасности
  • Ограничения проектирования(например, электромагнитная совместимость, целостность сигнала, среда)
  • Ограничения продукта
  • Допуски проектирования
  • Производственные стандарты (например, производственные лом, отходы)

4. Убедитесь, что проектирование придерживается выделенных требований.

Идентифицированные компоненты готового коммерческого продукта должны быть приняты во внимание. Например, при вставке существующих компонентов продукта в архитектуру продукта может изменить требования и распределение требований.

5. Документируйте результаты проектирования.

СП 2.2 Устанавливайте Пакеты Технических Данных

Устанавливайте и поддерживайте пакеты технических данных

Пакет технических данных предоставляет разработчику подробное описание, как разработан продукт или компонент продукта. Такой пакет также обеспечивает гибкость поставки материалов в различных обстоятельствах, таких как контракты с вознаграждением, зависящим от показателей работы, или изготовления единичного изделия под заказ. (См. определение «пакет технических данных» в глоссарии).

Результаты проектирования записываются в пакет технических данных, который создается в ходе предварительного документирования при документировании определения архитектуры. Этот пакет технических данных сохраняется в течение всего срока службы продукта для записи важных данных проектирования продукта. Пакет технических данных обеспечивает описание продукта или компонента продукта (в том числе связанных с продуктом процессов жизненного цикла, если не обрабатываются в виде отдельных компонентов продукта), которое поддерживает стратегию приобретения или реализации, производства, инженерного обеспечения и обеспечения логистики фаз жизненного цикла продукта. Описание включает определения необходимой конфигурации проектирования и процедуры для обеспечения адекватности реализации продукта или компонента продукта. Оно включает в себя все соответствующие технические данные, такие как рисунки, связанные списки, спецификации, описание результатов проектирования, проектирование баз данных, стандарты, требования к атрибутам качества, условия гарантии качества и описания пакета. Пакет технических данных включает в себя описание выбранного альтернативного решения, которое было выбрано для реализации.

Т.к. описание результатов проектирования может включать большое количество данных и может иметь решающее значение для успешного разработки компонентов продукта, рекомендуется установить критерии для организации данных и отбора содержимого данных. Особенно полезно использовать архитектуру продукта в качестве средства организации этих данных и абстрагирующих представлений, которые прозрачны и относятся к интересующим вопросам или особенностям. Эти представления включают следующее:

  • Заказчики
  • Требования
  • Среда
  • Функциональность
  • Логичность
  • Безопасность
  • Данные
  • Состояния/режимы
  • Сборка
  • Управление

Эти представления описываются в пакете технических данных.

Пример рабочих продуктов

1. Пакет технических данных

Подпрактики

1. Определяйте число уровней проектирования и соответствующий уровень документации для каждой уровня проектирования.

Определение числа уровней компонентов продукта (например, подсистема, элемент аппаратной конфигурации, платы, элемент конфигурации компьютерного программного обеспечения, компонент продукта компьютерного программного обеспечения, единица компьютерного программного обеспечения), которые требуют документации и трассируемости требований, является важным для управления стоимостью документации и для поддержки планов интеграции и верификации.

2. Определяйте представления, которые будут использоваться для документирования архитектуры.

Представления выбираются так, чтобы структура документирования была присуща продукту и направлена на конкретные проблемы заинтересованных сторон.

3. Основывайте подробные описания проектирования на требованиях компонента продукта, архитектуре и проектировании высокого уровня.

4. Документируйте результаты проектирования в пакет технических данных.

5. Документируйте ключевые (т. е. имеющие существенное влияние на стоимость, график или технические характеристики) принятые или определенные решения, включая их обоснование.

6. Пересматривайте пакет технических данных по мере необходимости.

СП 2.3 Проектируйте Интерфейсы Используя Критерии

Проектируйте интерфейсы компонентов продукта, используя установленные критерии.

Проектирование интерфейсов включает следующее:

  • Источник
  • Направление
  • Вызывающее событие и характеристики данных для программного обеспечения, в том числе ограничения последовательности или протоколов
  • Ресурсы, потребляемые для выполнения частного стимулирующего воздействия
  • Управление обработкой исключений или ошибок для вызывающих событий, которые являются ошибочными или выходят за указанные пределы
  • Электрические, механические и функциональные характеристики аппаратного обеспечения
  • Сервисные линий связи

Критерии для интерфейсов часто отражают критические параметры, которые должны быть определены или, по крайней мере, обследованы, чтобы выяснить их применимости. Эти параметры часто свойственны данному типу продукта (например, программное обеспечение, механические, электрические, сервисы) и часто связаны с надежностью, безопасностью, долговечностью и критически важными характеристиками.

См. специфическую практику Идентифицируйте Требования к Интерфейсам в процессной области Разработка Требований для получения дополнительной информации об идентификации требований к интерфейсам продукта и компонентов продукта.

Пример рабочих продуктов

1. Спецификации проектирования интерфейса

2. Документы управления интерфейса

3. Спецификация критериев интерфейса

4. Обоснование для выбранного проекта интерфейса

Подпрактики

1. Определяйте критерии к интерфейсам.

Эти критерии могут быть частью активов организационных процессов.

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании и поддержке используемого комплекса активов организационных процессов и стандартов рабочей среды.

2. Определяйте интерфейсы, связанные с другими компонентами продукта.

3. Определяйте интерфейсы, связанные с внешними элементами.

4. Определяйте интерфейсы между компонентами продукта и процессами, связанными с жизненным циклом продукта.

Например, такие интерфейсы могут включать взаимодействие между собираемым компонентом продукта и креплениями и зажимными приспособлениями, которые используются в процессе производства.

5. Применяйте критерии для проектирования альтернатив интерфейса.

См. процессную область Анализ и Принятие Решений для получения дополнительной информации об анализе возможных решений, используя формальный процесс оценки, которая оценивает выявленные альтернативы на основе установленных критериев.

6. Документируйте выбранный проект интерфейса и обоснование выбора.

СП 2.4 Выполняйте Анализ Разработки, Покупки или Повторного Использования

Оценивайте, должны ли компоненты продукта быть разработаны, приобретены или повторно использованы на основе установленных критериев.

Определение, какие продукты или компоненты продукта будут приобретены, часто называют «анализ сделать-или-купить». Он основан на анализе потребностей проекта. Такой анализ сделать-или-купить начинается на ранней стадии проекта в течение первой итерации проектирования; продолжается в течение процесса проектирования, и завершается решением разработать, приобрести или повторного использовать продукт.

См. процессную область Разработка Требований для получения дополнительной информации о выявлении, анализе и установке заказчиков, продуктов и требований к компоненту продукта.

См. процессную область Управление Требованиями для получения дополнительной информации об управлении требованиями.

Факторы, влияющие на решение сделать-или-купить, включают следующее:

  • Функции, которые обеспечит продукт, и как эти функции будут вписываться в проект
  • Доступные ресурсы проекта и навыки
  • Сравнение затрат на приобретение и внутреннюю разработку
  • Критические даты поставки и интеграции
  • Стратегические бизнес-альянсы, в том числе бизнес-требования высокого уровня
  • Исследование рынка на предмет доступных продуктов, включая готовые коммерческие продукты
  • Функциональность и качество предлагаемых продуктов
  • Навыки и возможности потенциальных поставщиков
  • Влияние на ключевые компетенции
  • Лицензии, гарантий, обязательства и ограничения, связанные с приобретением продукта
  • Наличие продукта
  • Вопросы собственности
  • Снижение риска
  • Совпадение между потребностями и основными активами линийки продуктов

Решение сделать-или-купить может быть проведено с использованием формального подхода к оценке.

См. процессную область Анализ и Принятие Решений для получения дополнительной информации об анализе возможных решений, используя формальный процесс оценки, которая оценивает выявленные альтернативы по установленным критериям.

Т.к. технологии развиваются, то необходимо делать обоснование выбора разработки или покупки компонента продукта. Хотя трудоемкость разработки может способствовать покупке готовых компонентов продуктов, достижения в области производительности и инструментов могут обеспечить противоположные обоснования. Готовые продукты могут иметь неполную или неточную документацию и могут или не могут поддерживаться в будущем.

После принятия решения о покупке компонента готовых продуктов, как реализовать это решение зависит от типа приобретаемого элемента. Есть моменты, когда готовый элемент ссылается на существующий элемент, который не всегда доступен, потому что он должен быть сначала настроен в соответствии с частными требования заказчика, требованиями к производству и другим характеристикам продукта в рамках этих закупок (например, авиационные двигатели). Для управления такими закупками, устанавливается соглашение с поставщиком, которое включает в себя эти требования и критерии приемки, которые должны быть выполнены. В других случаях, готовые продукты буквально готовы (например, программное обеспечение обработки текста) и нет необходимости в управлении соглашением с поставщиком.

См. специфическую цель Заключить Соглашение с Поставщиком процессной области Управление Соглашениями с Поставщиками для получения дополнительной информации об управлении соглашениями с поставщиками для модифицированных готовых коммерческих продуктов.

Пример рабочих продуктов

1. Критерии для проектирования и повторного использования компонента продукта

2. Анализ сделать-или-купить

3. Руководства по выбору готовых коммерческих компонентов продукта

Подпрактики

1. Разрабатывайте критерии для повторного использования результатов проектирования компонентов продукта.

2. Анализируйте результаты проектирования для определения компонентов продукта, которые должны быть разработаны, повторно использованы или куплены.

3. Анализируйте последствия для обслуживания при рассмотрении приобретения или не разработки (например, готовые коммерческие продукты, готовые правительственные продукты, продукты повторного использования) элементов.

Примеры последствий для обслуживания включают следующее:

  • Совместимость с будущими версиями готовых коммерческих продуктов
  • Управление конфигурацией изменений поставщика
  • Дефекты в неразрабатываемых элементах и их решение
  • Незапланированное устаревание

СЦ 3 Реализовать Результаты Проектирования Продукта

Компоненты продукта и связанная с ними документация поддержки реализуется на основе результатов проектирования.

Компоненты продукта реализуются из результатов проектирования созданных специфическими практиками специфической цели Выполнить Проектирование. Реализация обычно включает модульное тестирование компонентов продукта перед отправкой их на интеграцию продукта и разработкой конечной пользовательской документации.

СП 3.1 Реализовывайте Результаты Проектирования

Реализовывайте результаты проектирования компонентов продукта.

Как только проектирование было завершено, оно реализуется как компонент продукта. Характеристики реализации зависит от типа компонента продукта.

Реализация проектирования на верхнем уровне иерархии продукта включает в себя спецификации каждого из компонентов продукта на следующем уровне иерархии продукта. Эта деятельность включает в себя распределение, переопеределение и верификацию каждого компонента продукта. Она также включает в себя координацию между различными усилиями по разработке компонентов продукта.

См. процессную область Интеграция Продукта для получения дополнительной информации об управлении взаимодействием и сборкой компонентов продукта.

См. процессную область Разработка Требований для получения дополнительной информации о распределении требований компонентов продукта и анализе требований.

Примерами характеристики данной реализации являются:

  • Закодированное программное обеспечение.
  • Документированные данные.
  • Документированные сервисы.
  • Изготовленные электрические и механические части.
  • Введенные в эксплуатацию уникальные процессы производства продукта.
  • Документированные процессы.
  • Настроенные сервисы.
  • Произведенные материалы (например, уникальным для продукта материалом может быть нефть, масло, смазка, новый сплав).

Пример рабочих продуктов

1. Реализованные результаты проектирования

Подпрактики

1. Используйте эффективные методы для реализации компонентов продукта.

Примеры методов программного кодирования включают следующее:

  • Структурное программирование
  • Объектно-ориентированное программирование
  • Программирование, ориентированное на аспекты
  • Автоматическая генерация кода
  • Код программного обеспечение повторного использования
  • Использование применимых шаблонов проектирования

Примеры методов аппаратной реализации включают следующее:

  • Ворота уровня синтеза
  • Печатная плата (места и маршруты)
  • Автоматические схемы проектирования
  • Моделирование расположения
  • Методы изготовления

2. Придерживайтесь действующим стандартам и критериям.

Примеры стандартов реализации включают в себя следующее:

  • Языковые стандарты (например, стандарты для языков программирования, языки описания аппаратных средств)
  • Разработка требований
  • Стандартные списки частей
  • Изготовленные части
  • Структура и иерархия компонентов программного продукта
  • Процесс и стандарты качества

Примеры критериев включают в себя следующее:

  • Модульность
  • Прозрачность
  • Простота
  • Надежность
  • Безопасность
  • Восстанавливаемость

3. Проводите коллегиальную оценку выбранных компонентов продукта.

См. процессную область Верификация для получения дополнительной информации о выполнении коллегиальных оценок.

4. Выполняйте модульное тестирование компонентов продукта по мере необходимости.

Отметим, что модульное тестирование не ограничивается программным обеспечением. Модульное тестирование включает в себя тестирование отдельных аппаратных или программных модулей или групп связанных элементов до интеграции этих элементов.

См. процессную область Верификация для получения дополнительной информации о проверке выбранных рабочих продуктов.

Примеры методов модульного тестирования (ручного или автоматического) включают в себя следующее:

  • Тестовое покрытие инструкций
  • Тестовое покрытие ветвей
  • Тестовое покрытие предикатов
  • Тестовое покрытие путей
  • Тестирование граничных значений
  • Тестирование специальных значений

Примеры методов модульного тестирования включают следующее:

  • Функциональное тестирование
  • Радиационный контроль
  • Конфигурационное тестирование

5. Пересматривайте компонент продукта по мере необходимости.

Например, компонент продукта, возможно, должен быть пересмотрен, когда в ходе реализации возникают проблемы, которые не могли быть предусмотрены во время проектирования.

СП 3.2 Разрабатывайте Документацию Поддержки Продукта

Разрабатывайте и поддерживайте документацию для конечных пользователей.

Данная практика разрабатывает и поддерживает документацию, которая будет использоваться для установки, эксплуатации и обслуживания продукта.

Пример рабочих продуктов

1. Материалы для обучения конечных пользователей

2. Руководство пользователя

3. Руководство по эксплуатации

4. Руководство по обслуживанию

5. Контекстная помощь

Подпрактики

1. Рецензируйте требования, результаты проектирования, продукт и результаты тестирования для обеспечения того, чтобы вопросы, касающиеся документации по установке, эксплуатации и обслуживанию были выявлены и решены.

2. Используйте эффективные методы для разработки документации по установке, эксплуатации и поддержке.

3. Придерживайтесь применимых стандартов для документации.

Примеры стандартов для документации включают в себя следующее:

  • Совместимость с необходимыми текстовыми процессорами
  • Приемлемые шрифты
  • Нумерация страниц, разделов и пунктов
  • Согласованность руководства с необходимым стилем
  • Использование сокращений
  • Маркировка классификации безопасности
  • Требования к интернационализации

4. Разрабатывайте предварительные варианты документации по установке, эксплуатации и поддержки на ранних стадиях жизненного цикла проекта для рассмотрения соответствующими заинтересованными сторонами.

5. Проведите коллегиального оценку документации по установке, эксплуатации и поддержке.

См. процессную область Верификация для получения дополнительной информации о выполнении коллегиальных оценок.

6. Пересматривайте документацию по установке, эксплуатации и обслуживанию по мере необходимости.

Примеры, когда документация, возможно, потребует пересмотра, включают следующие события:

  • В требования были внесены изменения
  • В результаты проектирования были внесены изменения
  • В продукт были внесены изменения
  • В документации были выявлены ошибки
  • Определены альтернативные пути для обнаруженных проблем

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | Leave a Comment »

 
%d такие блоггеры, как: