И. Соммервилл - Инженерия программного обеспечения (1133538), страница 12
Текст из файла (страница 12)
На этом этапе может возникнуть необходимость вернуться к атапу проектирования для того, чтобы на уровне требований "подогнать" купленное излелие к системе. Это нзлелие может не удовлетворять всем требованиям, прсдьявляемым к компоненту, который оно замещает, но если ассортимент коммерческих продуктов достаточно широк, затраты на повторное проектирование невелики.
Все подсистемы, как правило, разрабатываются параллельно. Если возникают внутренние проблемы, прерывающие процесс разработки подсистем, может потребоваться модификация всей системы. Когда система в значительной степени состоит из аппаратных компонентов, проведение модификации системы после начала производства ее компонентов может оказаться весьма затратным. Приходится находить какое-то "обходное" решение для выхода нз подобных ситуаций. Часто таким решением является включение в систему программных компонентов, поскольку они достаточно гибкие и сравнительно легко поддаются модификациям.
В свою очередь, это ведет к изменению требований, предъявляемых к программному обеспечению, и, как подчеркивалось в главе 1, к изменениям в проекте ПО. 2.4.4. Сборка системы Сборка представляет собой интеграцию независима разработанных подсистем в единую законченную систему. В процессе сборки может использоваться метод большого взрыва", когда все полсистемы интегрируются одновременно. Но по техническим и организационным причинам гораздо предпочтительнее последовательная сборка, когда отдельные подсистемы интегрируются в систему по очереди, одна за другой.
Процесс последовательной сборки считается более подходящим для системной интеграции по двум причинам. 1. Обычно невозможно составить такой график работ, при котором у всех подсистем этап разработки заканчивается одновременно. 2. Системотехиика вьгчислительпьгх систем 47 2. Последовательная сборка уменьшает количество ошибок, связанных с неправильной интеграцией системы. Если одновременно интегрнруетсл несколько подсистем, то причиной обнаруженной в процессе тестирования ошибки может быть любал из них, Если интегрируется одна подсистема в уже работающую систему, то причиной обнаруженной ошибки, вероятнее всего, будет последняя интегриро.
ванная подсистема или вновь установленные связи между ней и существующими подсистемами. Ошибки и дефекты отдельных подсистем и системы в целом часто проявляются именно на этапе сборки. Зто может вызвать полемику и конфликты между разработчиками разных подсистем из-за того, чью подсистему признать "виновной" в этом. Самое неприятное в данной ситуации то, что на решение возникших проблем может потребоваться несколько недель, а то и месяцев работы.
2.4.5. Инсталляция системы При инсталляции система "погружается" э то окружение, в котором она должна работать. В процессе инсталляции сложных систем могут проявгшься различные проблемы, на решение которых подчас уходит несколько месяцев, а то и лет. Среди них могут быть про. блемы, описанные ниже. 1. Окружение, в котором инсталлируется система, не совпадает с тем, для которого она спроектирована. Это общая проблема, которая часто возникает при инсталляции ПО. Например, программная система может использовать функции, которые предоставляет только определенная версия операционной системы.
Однако версия, опреде. лающая текущее окружение инсталлируемой программной системы, может не обла. дать этими функциями. В этом случае после инсталляции система может не работать совсем либо некоторые ее функции окажутся не реализованными. 2. Потенциальныс пользователи могут относиться враждебно к внедрению этой системы в своей органиэации. Это может уменьшить огвсгсгвсппосгь и количество рабат, необходимых для внедрения системы в данной организации. Люди могут осознанно отказываться от сотрудничесгва со специалистами, которые инсталлируют систему.
Например, они могут отказываться от обучения работе с этой системой или не предоставлять информацию, необходимую для инсталляции системы. 3. Новая система может сосуществовать со старой до тех пор, пока в организации, где она инсталлируется, не убедятся, что новая система работает так, как требуется. Зто может привести к определенным проблемам при инсталляции системы, особенно если новая и старая системы не являются полностью независимыми, а имеют некато. рые общие компоненты. Случаются ситуации, когда новую систему вообще невозможно внедрить без деинсталляции старой системы.
Прн этом испытания новой системы можно провести только тогда, когда старая система не функционирует. 4. При инсталляции возможны также чисто физические проблемы. Могут возникнуть сложносги при подгонке системы к тому зданию, где она инсталлируется. Это здание может не иметь достаточного количества помещений с каналами для сетевых кабелей, мокнут потребоваться дополнитсльныс воаяушпыс кондиционеры илн другие встраиваемые в здание приборы и т.п. А если это памятник истории, охраняемый шконом, то при инсталляции системы изменения в здании вообще невозможны.
48 Часть 1. Инженерии программного обеспечении: обзор 2.4.6. Ввод системы в эксплуатацию После того как система инсталлирована, ее необходимо ввести в эксплуатацию. Это подразумевает проведение обучения системных операторов и изменение их обычного рабочего процесса для того, чтобы более эффективно использовать новую систему.
На этом этапе могут возникнуть непредвиденные проблемы, если системная спецификация содержит ошибки илн упущения. Пока система функционирует в соответствии со спецификацией, эти дефекты мокнут пе прсшвпться, и поэтому разработчики могут нс предусмотреть соответствующих режимов эксплуатации системы. Например, проблемой, которая может проявиться только после ввода системы в эксплуатацию, является совместимость новой н существующих систем. Это может быль чисто физическая проблема совместимости. Возможны проблемы при передаче данных от одной системы к другой.
Более "хитрой" проблемой может стать различие интерфейсов разных систем. Тогда ввод в эксплуатацию новой системы может привести к возрастанщо ошибок системных операторов вследствие неправильного использования интерфейсных команд новой системы. 2.4.7. Эволюция систем Большие и сложные системы имеют очень длительный срок жизни. В течение своей жизни они совершенствуются п)тем исправления ошибок в исходных системных требова. ниях, а также для учета новых требований, предъявляемых к пнм. Вычислительные ком. понепты систем заменяются новыми, более производительными компоисптамп.
Организации, эксплуатирующие систему, ма~ус быть реорганизованы н, следовательно. использовать систему иным образом, чем предусматривалось первоначально, Может измениться внешнее окружение системы, что также требует внесения в нее изменений. Необходимость эволюции систем, как и программного обеспечения (эта тема обсуждается в части т)1), вызвана рядом причин. 1. Прсдполапемые изменения в технической и деловой областях, полученные па основе тщательного анализа перспектив развития этих областей.
Здесь необходимо учитывать мнение широкого круга специалистов, прежде чем принимать какие- либо решения. 2. Поскольку системы никогда не является полностью не зависимыми др)т от др)та, изменения в одной подсистеме обязательно окажут влияние на производитель. ность или поведение других подсистем.
Следовательно, прн внесении изменений в одну подсистему необходимы изменения практически во всех подсистемах. 3. Причины, приводящие к принятию определенных решений на псрвоначальнои этапе проелтирования исходной системы, редко протоколируются или вообще фиксируются. Это может вызвать пересмотр некоторых решений, принятых на первоначальном этапе проектирования, а следовательно, изменения в самой системе. 4. По мере увеличения "возраста" системы ее структура вследствие сделанных ранее изменений нарушается, что, в свою очередь, приводит к возрастанию затрат на сс модификацию. Вследствие все возрастающей зависимости нашего общества от систем самых разнообразных типов значительно болыве усилий прилагается для совершенствования существуюгцих систем, чем для разработки новых.
Такис раисе созданныс системы, которые необходимо сохранить (путем их модернизации), иногда называют нпо~гдуачымк олсиюисчи (1едазу зуисщз). Этп системы обсуждаются в главе 26. 2. Системотехнина вычислительных систем 49 2.4.8. Вывод систем из эксплуатации Вывод из эксплуатации означает извлечение системы из ее окружения после окончания срока службы.
Часто это не предполагает каких-либо сложностей. Но некоторые системы могут содержать материалы, потенциально опасные для окружающей среды. Системотехники должны предусмотреть процедуру вывода такой системы из эксплуатации еще иа этапе ее проектирования. Например, используемые в системе токсичные химических соединения должны быть заключены в герметические контейнеры, каждый из которых можно удалить из системы как единый элемент для последующей утилизации. При дсинстэллвции программного обеспечения обычно не возникает физических проблем.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
