Всего за 480 руб. Купить полную версию
Требования к интерфейсам, как часть системных требований, должны быть идентифицированы во время определения системных решений. Основным источником информации об интерфейсах является задаваемая схема потоков рабочих сред, где каждая стрелка представляет собой интерфейс и связь между функциями. Для систем высокой сложности интерфейсы можно структурировать путем размещения их в матрице входов и выходов системы (строк и столбцов) N
2
Требования к интерфейсам должны удовлетворять определенным правилам для исполнения задаваемых функций.
1. Интерфейсы возникают как между подсистемами, так и между подсистемами и системой.
2. Функции, характеристики, ограничения и допущения этих интерфейсов должны быть определены и зафиксированы в требованиях к интерфейсам.
3. Должен быть определен один владелец каждого интерфейса, даже если это очевидно.
4. Требования к интерфейсу определяют функциональные, физические, характеристические, электрические, экологические, человеческие требования и ограничения, которые существуют на общей границе между двумя или более функциями, элементов системы, элементов конфигурации или систем.
5. Требования к интерфейсу включают логические и физические интерфейсы.
Также на этапе разработки требований необходимо определить методы их верификации. Целесообразно для безусловного выполнения требований проекта организовать поэтапную верификацию исполнения требований к системе, начиная с момента появления предварительного облика разрабатываемой системы (на контрольном рубеже с обзором предварительного проекта системы).
Валидация требований входит в один из этапов принятия решений. В процессе валидации требуется проверить, что системные требования полны, непротиворечивы, и каждое требование достижимо и проверяемо. Валидацию требований проводят эксперты по конкретным вопросам, организация-разработчик и уполномоченные представители заказчика.
В результате процесса разработки формируется набор требований, который должен быть выполнен при создании продукта или системы. Этот завершающий комплект требований содержится в документах контракта, спецификациях или технических заданиях на выполнение работ (statement of work, SOW). Характеристики этого набора будут идентичны вышеописанным пунктам отдельных требований и удовлетворяют двум условиям. Набор должен быть полным, то есть не нуждается в дополнительных пунктах требований. Входящие в него требования должны быть согласованными, то есть не содержат противоречий, дублирований, и др. Далее на всех этапах разработки системы выполняется процесс управления требованиями (см. раздел 2.2).
Идеальным случаем, не встречающимся в практике, является вариант, что все требования, созданные до того, как проект будет начат, останутся такими же после его завершения. Отслеживание их изменений имеет первостепенное значение в работе менеджера для отображения прогресса, модификаций, запросов на финансирование или на другие ресурсы, которые могут меняться по мере продвижения процесса разработки.
1.4 Организация команды проекта и синтез системы
При создании новых изделий и систем важнейшей задачей является формирование команды управленцев и компетентных исполнителей по разным направлениям. Далее необходимо выполнить распределение ролей, налаживание коммуникаций внутри интегрированной команды проекта, с соисполнителями и со стейкхолдерами программы. Нужно организовать эффективное принятие коллегиальных решений и исполнение ряда других процессов системной инженерии для успешной реализации поставленных задач проекта или программы. Декомпозиция задач проекта по ролям для персонала команды обеспечивает эффективность системно-инженерного подхода, упрощает цели участников работ.
Сегодня большинство сложных проектных работ делают в рамках матричной организации команд проекта. Матричная модель представляет собой структуру отношений полномочий и отчетности, созданную наложением проектной команды на традиционную функциональную организацию (подробности в разделе 3.2.1). Под конкретный проект необходимо создавать междисциплинарную интегрированную команду проекта (ИКП). Ее формируют на ранней стадии проекта и наделяют ресурсами и полномочиями для принятия решений, влияющих не только на проект, но и на полный жизненный цикл конечного продукта или системы. Лидер и участники команды выбираются менеджером, ответственным за проект.
Важную роль играют внешние по отношению к ИКП представители заинтересованных лиц программы. Можно выделить для них типичные группы и характерные интересы.
Пользователь: функциональность, удобство использования.
Клиент, спонсор, руководство: корпоративные цели, видение, выгода.
Законодатели: стандарты, руководящие принципы, этические, моральные и правовые условия.
Заказчик, покупатель: стоимость лицензии, условия контракта, цена.
Поставщик, продавец: маржа, объем функций, условия контракта.
Маркетинг, продажи: набор функций, цена, срок поставки, доступность.
Противники и сторонники проекта: корректировка целей проекта.
Ремонтный и обучающий персонал: техническое обслуживание, обучение.
При этом важно помнить, что у таких разнородных групп одной программы могут быть конфликтующие интересы.
В проекте следует определить и задокументировать роли и обязанности в области СИ для членов проектной команды и функциональных руководителей. На большой программе или при наличии у организации филиалов, расположенных в разных географических точках, команд может быть несколько.
Концептуальное проектирование является первым, и наиболее важным шагом в процессе проектирования системной инженерии. Чтобы объективно оценить возможность успеха реализации проекта, изучают потенциальный рынок и группы клиентов, учитывают факторы окружающей среды, доступ к необходимым ресурсам, готовность персонала, и наличие текущих или разрабатываемых технологий. На предыдущем этапе фиксируют системные потребности и эксплуатационные требования, которые собирают в один всеобъемлющий документ. На основе требований к системе изучаются концепции проектирования в сочетании с анализом осуществимости системы. На этой стадии рассматривают наиболее широкий спектр потенциально возможных решений, которые могут дать значительные преимущества для будущего продукта. Анализ осуществимости проекта дает ответы на вопросы «Выгодно ли проектировать систему?» и «Сможем ли мы это сделать?» Критериями при оценке осуществимости ОКР выбирают стоимость проекта и ценности для организации, полученные при проектировании.
Рассматривают три взаимосвязанных компонента осуществимости, технический, эксплуатационный и экономический. Техническая осуществимость оценивает доступность технических ресурсов, готовность и зрелость существующих и новых технологий. Также при разработке системы следует учесть законы, нормативные акты, стандарты и кодексы, которым должна удовлетворять новая разработка, включая стандарты безопасности и характеристик. В них указаны требования по охране труда, управлению качеством, экологии, и так далее.
Эксплуатационная осуществимость показывает, насколько хорошо предлагаемая система удовлетворяет заданным требованиям. Для анализа этого фактора разработчикам необходимо ответить на ряд вопросов. Хорошо ли эта система работает с существующей средой? Как система удовлетворяет потребности клиентов? Есть ли у разработчиков необходимые резервы для создания такой системы, включая возможности организации, готовность ресурсов, навыков и обучения персонала? По ответам оценивают потенциальные плюсы и минусы эксплуатационной эффективности системы.