И. Соммервилл - Инженерия программного обеспечения (1133538), страница 13
Текст из файла (страница 13)
Вместе с тем некоторые программные компоненты молт быть инкорпорироввнными в системы, необходимые для деинсталляцни ПО; например, если ПО использовалось для мониторинга состояния других системных компонентов. После вывода системы из эксплуатации некоторые ее компоненты могут использоваться в друпщ системах. Если ланные из дсиисталлируемой системы Лолжны верн)тьсл в организацию, для этого могут быть прииенены какие-либо другие системы. Эти данные часто имеют значительную стоимость. Тема повторного использования данных рассматривается в главе 28. 2.5. Приобретение систем Заказчиками сложных вычислительных систем обычно явллются крупные организации, например военное ведомство, правительство или аварийные службы.
Такие системы можно купить как единое целое, можно купить отдельные части, которые затем интегрируются в создаваемую систему, можно спроектировать систему и разработать по отдельному заказу "с нуля". Длл больших систем процесс выбора одного из этик вариантов может растян)ться на несколько месяцев нли даже лет.
Процесс приобретения системы — это определение наиболее оптимального для организации пути ее приобретения и выбор наилучшего поставщика системы. Процесс приобретения системы полностью подчиняется процессу системотехннкн. До начала самого процесса приобретения необходимо разработать системную спецификацию н архитектуру системы, что обусловлено двумя основными причинами. 1. Для покупки или заключения контракта на разработку и построение системы необходима полностью законченная системная спецификация.
2. Практически всегда дешевле купить систему, чем разработать ее (как отдельный проект). Архитектура системы необходима для того, чтобы определить, какие ее подсистемы можно купить, а какие необходимо разрабатывать. Большие сложные системы обычно состоят из приобретенных компонентов и компо. центов, специально созданных для данной системы. Это одна из предпосылок, требующая включения программных компонентов в состав систем — программное обеспеченно должно "склеить" в единое целое (причем эффективно работающее) отдельные сущест в»ющне аппаратные компоненты. В необходимости разработки програмьшого "клев" кроется причина того, что экономия от применения приобретенных компонентов нс такая большая, как ожидается, Подробно тема приобретенных систем обсуждастгл в главе 14.
На рис. 2.7 показаны этапы процесса приобретения как готовых систем, так и разрабатываемых по заказу, Пере шслим некоторые важные моменты процесса приобретения, 50 кХасть 1. Инженерия программного обеспечения: обзор Е Приобретаемые компоненты, как правило, не удовлетворяют в точности всем системным требованиям, вследствие чего необходима подгонка требований в соответствии с этими компонентами. Более того, обычно стоит нелегкая дилемма выбора между системными требованиями и свойствами приобретенной системы. Чаще всего "в жертву" приносятсл системные требования.
Это, в свою очередь, оюшывает влилние па другис подснстекты. 2. Если система разрабатывается по заказу, спецификация требований является основой контракта на приобретаемую систему. Таким образом, спецификация имеет такую жс правовую силу, как и другал техническая документация. 3. После выбора разработчика системы в контракте с ним необходимо оговорить возможности внесения изменений в требования, хотя зто может привести к изменению стоимости системы. Приобретение готовой системы Форнирование заявки нв покупку Выбор нродавнз Выбор системы Ааалтирование требований Рвзоешение нв валолнение контрапа Форю~рнне трейианий к разравлчику Заказ нв радабстку системы Рис 2. Е Процесс лриофеихнкя сиснммм Выбор рззрв бегина Заключение контракта Большинство аппаратных подсистем и многие программные подсистемы (такие, как системы управленил базами данных) нс разрабатываются специально для включения н состав больших систем.
Часто в них встраиваютсл уже готовые системы. Очень немногие организации имеют возможности для проектирования, произволства и тестированил всех компонентов сложных больших систем. Органиэация — разработчик системы, которую обычно называют ведущим или генеральным подрядчиком, может заключать контракты на разработку отделы<сан подсистем с другими субподрядчиками (рнс.
2.8). Для создания больших систем, таких как системы управления полетами, группа организаций-разработчиков может создать консорциум для выполнения контракта. В консорциум лолжны входить разработчики и поставщики всех компонентов системы, например разработчики вычислительных устройств и программного обеспечения, поставщики периферийного оборудованил и специального оборудовании (скажем, радаров). Модель "подрлдчик-субподрядчик" минимизирует количество организаций, участ.
вующнх в реализации контракта. Субподрядчики разрабатывают и производят части системы в соответствии со спецификацией, предоставляемой ведущим подрядчиком. После завершения работ субподрядчиками система собирается из отдельных частей ведущим подрядчиком. Готован система поставляется заказчику (покупателю).
В зависимости от условий контракта, заказчик может предоставить ведущему подрядчику свободный выбор субподрядчиков либо потребовать, чтобы субподрядчики выбирались из заранее оговоренного списка. 2, Системотехника вычислительных систем $1 Рис. 2.В. Модсль "мдуэгдчик-субнсдрадчнк" ,э: ' !КЛЮЧЕВЫЕ ПОНЯТИЯ °:!:. Систембтехйика'-'"'зто комшюкснея' тиаолгопн создания гсистем тдторвя",,~ребусет привлечения йу.:-.': ~аюпншмюйерньа дисциплин;.,;..;, яъ ь "' ' 'йг' . -':,.";:.;~,:,";.' " ...: ..
у чеууд.,'тчитегрирюванные"свойствахсисамы — это свойства,' котоаргйв присущи системе как едшюму цело- му, а нв ее отдельным щгыпонентзй. К интегрированным системным снтбставм относятся безтт- , сскыноств,.произаодитепьнссть, удобство эксплуатации, бевжюсность и защищенность системы.
''ь'!вАфбттвктурв 'системы, 'обычно 'предстаяляняая в виде блок.схемы, показывает 'основные подсис,.е-,:,';„'Фунициональиые,комввенты'систем' делятся'на следуаюгцие тйпы: Сенсорйчыв вгсполннтельные, ~, '.;; '«': вычислителвйые;координйрующие, ютммуниецианные и'интерфейсные.. ~~-.~",',Пргщесс создангм систем'включает след~пощие этапы:"составление специфигшции, прсектирова- ;ние, равработку, интеграцию (сборку1 и тестирование. Наиболее ответственным аталом является :., сборка системы, когда различныв подсистемы, подчас ст разных произитдитеяей, интегрируются ь1гс-',В едлную систем]г .
"д . л! ' ,.'в.',,'-: Прэцес,приофеиния сисщмы вклютает зиггы' спецггфицИрования сисЩмы,'формирована эмгмм на ~:,-':;",~',: ' присбретенйе,",'выбрр пестзвщию и жнем эаюжзюние нмтраюв нв шжупку или риработку системы. г ','~: Часто ннюврыеявсщ вычисапельгяа систем присбреташся у сврюнних производителей. Упражнения 2.1, Обьясните, почему системное охрухюниэ может оказать непредвиденное воздействие на функцио- нирование системы. 2,2. Измените схему на рис. 2.6 таким образом, чтобы включить в нее этап приобретения подсистем после этапа их идентификации, Покажите на новой схеме обратную связь от включенного этапа присб.
ретения к другим этапам процесса проектирования системы. 2.3, Объясните, почему процесс специфицирования систем, используемых аварийными службами для управления в чрезвычайных ситуациях, является "злостной" проблемой. 2.4. Объясните важность получения полного описания системной архитектуры на самой ранней стадии процесса разработки системной спецификации.
2.б. На рис. 2.1 показана иерархия систем отдельного здания. Система безопасности, вквочающая систему защиты от несанкционированного проникновения в здание и противопожарную систему, является расширением системы, представленной на рнс. 2.2. Она содержит датчики дыма, датчики дви- 52 кйастж 1. Инженерия программного обеспечения: обзор женив и дверные датчики, видеокамеры, управляемые компьютером, расположенные в разных местах строения, пульт управления, где собирается вся информация ат системы безопасности, средства внешних коммуникаций для связи с соответствующими службами, такими как полиция и пожарная охрана. Нарисуйте блок-схему архитектуры такой системы.
2.6. Разрабатывается система предупреждения наводнений для города, которому угрожают частые наводнения. Система включает множество датчиков уровня воды в реке, связь с метеослужбой, предоставляющей прогноз погоды, связь со службами безопасности (полицией, береговой охраной и тд), видеомониторы, установленные в различных местах, и комнату управления, оборудованную пультам управления и монитораыи. 2.7. Дежурные операторы имеют доступ к базе данных и могут переключать видеомониторы. База данных содержит информацию с датчиков, расположенных в других городах, также подверженных риску наводнения, о ситуации в этих городах (уровень воды, сила и направление ветра и т.п.), таблицу высот прибрежных городов, местоположение оборудования, контролирующего уровень воды, контактные телефоны служб безопасности, частоты местных радиостанций и т.д.
2.9. Нарисуйте блок-схему возможной архитектуры такой системы. Также определите основные подсистемы и взаимосвязи между ними. 2.9. Назовите три проблемы, которые мснут возная)пь при инсшлляции системы в сторонней организации. 2.10. Рассмотрите системотехнику как профессию и сравните ее с профессией инженера. электронщика и специалиста по программному обеспечению. 2.11.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
