Материал: Н. Э. Баумана (национальный исследовательский университет) А. Е. Бром, З. С. Терентьева организация и управление жизненным циклом наукоемкой продукции Курс лекций

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
Требование должно обладать следующими характеристиками:

  1. Единичность — требование описывает одну и только одну вещь.

  2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.

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

  4. Атомарность — требование нельзя разделить на более мелкие.

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

  6. Актуальность — требование не стало устаревшим с течением времени.

  7. Выполнимость — требование может быть реализовано в рамках проекта.

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

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

  10. Проверяемость — реализованность требования может быть проверена.
В соответствии с ITILv3 все требования в проекте можно разделить на следующие группы:

  1. Функциональные (Functional) — реализуют саму бизнес-функцию.

  2. Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.

  3. Эргономические (Usability) — к удобству работы конечных пользователей.

  4. Структурные (Architectural) — требования к структуре системы.

  5. Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.

  6. Сервисного уровня (Service Level) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.
Классификация групп управления требованиями представлена на рисунке 3.1.
Рис. 3.1 – Группы управления требованиями

3.3. Технология управления конфигурацией

При создании нового образца техники создается и обращается информация об изделии по следующим основным категориям:• концепция изделия, в которой описываются потребности покупателей; можетсуществовать отдельно от проекта изделия или физического изделия, и напрямую влияет на требования к изделию;• требования к изделию формулируются в форме показателейфункциональности: набор выполняемых основных и обеспечивающих функций, показатели производительности и эффективности эксплуатации (работы) изделия; формулирование требований даёт возможность сопоставить необходимую функциональность и проект изделия;• проект изделия, включающий функциональный проект, физическийпроект, проект поддержки эксплуатации (это может быть комплект конструкторской, технической и эксплуатационной документации, КД, ТД, ЭД);• физическое изделие; информация содержит данные о реально произведенных и эксплуатируемых изделиях.Существует определенная проблема соблюдения изначальных требований к изделию при обращении информации по всем этим категориям, которое может занимать еще и довольно длительное время. Для контроля соответствия характеристик изделия заданным требованиям на всех стадиях ЖЦ предназначена технология управления конфигурацией изделия.Под конфигурацией изделия понимается совокупность функциональных, эксплуатационных и физических атрибутов (характеристик) изделия. Конфигурация представляется древовидной (иерархической) структурой, элементами которой являются объекты управления конфигурацией (ОК). Каждый ОК представляет собой изделие или его часть, осуществляющую в этом изделии какую-либо функцию. Каждому объекту конфигурации могут быть поставлены в соответствие одно или несколько конструктивных решений, обеспечивающих реализацию требуемых характеристик изделия. Согласование между заказчиком и разработчиком/поставщиком изделия требований к изделию, формализованных в контракте и в техническом задании (ТЗ), определяют начало процесса управления конфигурацией изделия (УК).
Результатом УК является набор документированных доказательств соблюдения производителем заданных заказчиком требований к изделию и его компонентам. Документация, позволяющая определить и идентифицировать функциональные, физические и эксплуатационные характеристики изделия, называется документацией конфигурации. С одной стороны, набор документации по процессам разработки и производства изделия служит основой гарантии качества, а с другой стороны - защищает поставщика от необоснованных претензий заказчика в спорных ситуациях. Технология УК обеспечивает целостность и документирование всех данных об изделии, «прослеживаемость» всех шагов, связанных с внесением изменений в структуру изделия, в конструкции отдельных блоков и агрегатов изделия. Набор документации о изделии позволяет в любой момент воспроизвести процесс изготовления экземпляра изделия с гарантией получения его требуемых характеристик. Конфигурация по изделию в целом и по составляющим его ОК должны быть соответствующим образом документированы и утверждены, вплоть до привлечения представителей заказчика к процессу утверждения. В качестве документации конфигурации принято рассматривать технические требования (условия), техническое задание, чертежи изделия, спецификацию на материалы, технологии или электронные данные аналогичного назначения. Утвержденную в компании в установленном порядке документацию конфигурации называют базовой конфигурацией. Существует несколько видов базовых конфигураций (БК). На стадии технического задания и технического предложения формируется функциональная ДК, описывающая требования потребителя (заказчика) к функциональности и надежности изделия, его эксплуатационным свойствам, наличию систем безопасности и диагностики, а также названия и перечень процедур для проверки выполнения разработчиком этих требований. Утвержденный комплект ДК на этой стадии называется функциональной базовой конфигурацией (ФБК). В ходе проектных работ (создания аван-проекта, эскизного проекта, непосредственно проекта изделия) создается проектная ДК. Утвержденный комплект ДК называется проектной базовой конфигурацией (ПБК). Здесь проявляется важное свойство управления конфигурации – наследуемость всех информационных данных, накопления памяти поколений, т.е. технические требования к объектам конфигурации наследуются конструктором из предыдущего контекста и используются как основа для принятия проектных технических решений.
ПБК, помимо чертежей и иных документов, должна содержать сведения, подтверждающие выполнение требований к изделию и его компонентам на стадии проектирования (результаты расчетов, математического, компьютерного и/или натурного моделирования и т.п.). При изготовлении конкретного экземпляра изделия в процессе производства создается «физическая» ДК (ФзДК), содержащая комплект электронной технической документации (ЭТД), спецификации на материалы, технологии оборудование, оснастку и т.д., результаты выходного контроля качества, результаты опытного производства и испытаний изделия, подтверждающие выполнение требований заказчика. Утвержденная ФзДК называется физической базовой конфигурацией (ФзБК). Любые конструктивные изменения, приводящие к появлению модификаций или исполнений изделия, требуют обязательного внесения изменений в соответствующие БК. В западных компаниях часто существует должность «менеджер конфигурации» - это специалист, контролирующий не только создание ДК по всем процессам ЖЦ , но и внесение изменений в ДК установленном порядке. В соответствии с описанными понятиями технология управления конфигу-рацией состоит из следующих процессов. 1. Идентификация конфигурации: - группирование требований, выделение ОК, «отвечающих» за отдельные группы выполняемых функций и технико-экономических характеристик изделия, введение обозначений и системы кодирования для дальнейшей работы; - утверждение функциональной ДК и идентификация ФБК. 2. Контроль конфигурации: - установление связей между ОК и данными, полученными в процессе конструирования; результаты опытно-конструкторских работ (ОКР) должны содержать оценки характеристик изделия, полученные расчетными или экспериментальными методами (в зависимости от стадии ЖЦ); - сопоставление полученных данных с требованиями, содержащимися в ОК; нахождение расхождений между ОК и соответствующих им конструктивных элементов; - внесение и документирование изменений в конструкцию изделия и его элементов с целью устранения отклонений от требований; - установление последовательности (очередности) внесения и утверждения изменений. идентификация изменений; - оценка эффективности реализованных изменений в отношении степени удовлетворения требований и связанных с этим затрат. 3. Учет статуса конфигурации: процедура систематической проверки и документального оформления наличия утверждений ОК, БК всех видов и иных объектов, относящихся к конфигурации.
Источник: https://files.student-it.ru/previewfile/166309