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

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

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. Пересматривайте документацию по установке, эксплуатации и обслуживанию по мере необходимости.

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

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

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

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