Главная | Обратная связь | Поможем написать вашу работу!

Приобретение систем

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

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

1. Для покупки или заключения контракта на разработку и построение системы необходима полностью законченная системная спецификация.

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

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

На рис. 2.7 показаны этапы процесса приобретения как готовых систем, так и разрабатываемых по заказу. Перечислим некоторые важные моменты процесса приобретения.

1. Приобретаемые компоненты, как правило, не удовлетворяют в точности всем системным требованиям, вследствие чего необходима подгонка требований в соответствии с этими компонентами. Более того, обычно стоит нелегкая дилемма выбора между системными требованиями и свойствами приобретенной системы. Чаще всего "в жертву" приносятся системные требования. Это, в свою очередь, оказывает влияние на другие подсистемы.

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

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

Рис. 2.7. Процесс приобретения системы

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

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

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

Рис. 2.8. Модель "подрядчик-субподрядчик"

КЛЮЧЕВЫЕ ПОНЯТИЯ

• Системотехника – это комплексная технология создания систем, которая требует привлечения многих инженерных дисциплин.

• Интегрированные свойства системы – это свойства, которые присущи системе как единому целому, а не ее отдельным компонентам. К интегрированным системным свойствам относятся безотказность, производительность, удобство эксплуатации, безопасность и защищенность системы.

• Архитектура системы, обычно представляемая в виде блок-схемы, показывает основные подсистемы и их взаимосвязь.

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

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

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

Упражнения

2.1. Объясните, почему системное окружение может оказать непредвиденное воздействие на функционирование системы.

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

2.3. Объясните, почему процесс специфицирования систем, используемых аварийными службами для управления в чрезвычайных ситуациях, является "злостной" проблемой.

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

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

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

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

2.8. Нарисуйте блок-схему возможной архитектуры такой системы. Также определите основные подсистемы и взаимосвязи между ними.

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

2.10. Рассмотрите системотехнику как профессию и сравните ее с профессией инженера-электронщика и специалиста по программному обеспечению.

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

⇐ Предыдущая 14 15 16 17 181920 21 22 23 Следующая ⇒