Лекция 6. Заключительные этапы создания ПО

Содержание

Конспект лекций

Нахождение на практике линейной регрессии.

Чтобы найти линию регрессии необходимо посчитать:

- Мат ожидание

- Отклонение

- Коэффициент корреляции

-

-

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

специальность 7.091401 – системы управления и автоматики

Лекция 1. Основные понятия программного обеспечения. 7

1.1. Что такое программное обеспечение. 7

1.2. Процесс создания программного обеспечения. 8

1.3. Модель процесса создания ПО.. 9

1.4. Методы инженерии программного обеспечения. 10

1.5. Характеристики качественного программного обеспечения. 12

1.6. Проблемы специалистов по программному обеспечению.. 13

1.7. Профессиональные и этические требования к специалистам по ПО.. 14

Лекция 2. Системотехника компьютеризированных систем. 18

2.1. Интеграционные свойства систем. 20

2.2. Система и ее окружение. 23

2.3. Моделирование систем. 26

Лекция 3. Системотехника компьютеризированных систем. 32

3.1. Процесс создания систем. 32

3.1.1. Определение системных требований. 34

3.1.2. Проектирование систем. 36

3.1.3. Разработка подсистем. 37

3.1.4. Сборка системы.. 38

3.1.5. Инсталляция системы.. 39

3.1.6. Ввод системы в эксплуатацию.. 40

3.1.7. Эволюция систем. 40

3.1.8. Вывод систем из эксплуатации. 41

3.2. Приобретение систем. 42

Лекция 4. Модели процесса создания и разработки ПО.. 46

4.1. Модели процесса создания ПО.. 47

4.1.1. Каскадная модель. 49

4.1.2. Эволюционная модель разработки. 52

4.1.3. Формальная разработка систем. 54

4.1.4. Разработка ПО на основе ранее созданных компонентов. 56

Лекция 5. Модели процесса создания и разработки ПО (продолжение) 59

5.1. Итерационные модели разработки ПО.. 59

5.1.1. Модель пошаговой разработки. 60

5.1.2. Спиральная модель разработки. 63

5.2. Спецификация программного обеспечения. 66

5.3. Проектирование и реализация ПО.. 68

5.3.1. Методы проектирования. 70

5.3.2. Программирование и отладка. 72

Лекция 6. Заключительные этапы создания ПО. 74

6.1. Аттестация программных систем. 74

6.2. Эволюция программных систем. 77

6.3. Автоматизированные средства разработки ПО.. 79

6.4. Классификация CASE-средств. 81

Лекция 7. Требования к программному обеспечению.. 87

7.1. Функциональные и нефункциональные требования. 89

7.1.1. Функциональные требования. 90

7.1.2. Нефункциональные требования. 92

7.1.3. Требования предметной области. 96

7.2. Пользовательские требования. 97

Лекция 8. Системные требования. 99

8.1. Структурированный язык спецификаций. 101

8.2. Создание спецификаций с помощью PDL. 102

8.3. Спецификация интерфейсов. 105

5.4. Документирование системных требований. 107

Лекция 9. Модели систем. 113

9.1. Модели системного окружения. 115

9.2. Поведенческие модели. 118

9.2.1. Модели потоков данных. 119

9.2.2. Модели конечных автоматов. 121

Лекция 10. Модели систем (продолжение) 126

10.1. Модели данных. 126

10.2. Объектные модели. 130

10.2.1. Модели наследования. 132

10.2.2. Агрегирование объектов. 135

10.2.3. Моделирование поведения объектов. 136

10.3. Инструментальные CASE-средства. 137

Лекция 11. Прототипирование программных средств. 140

11.1. Прототипирование в процессе разработки ПО.. 143

11.1.1. Эволюционное прототипирование. 145

11.1.2. Экспериментальное прототипирование. 149

Лекция 12. Прототипирование программных средств (продолжение) 153

12.1. Технологии быстрого прототипирования. 153

12.1.1. Применение динамических языков высокого уровня. 154

12.1.2. Программирование баз данных. 156

12.1.3. Сборка приложений с повторным использованием компонентов. 159

12.2. Прототипирование пользовательских интерфейсов. 163

Лекция 13. Формальные спецификации ПО.. 166

13.1. Формальные спецификации в процессе разработки ПО.. 167

13.2. Специфицирование интерфейсов. 170

Лекция 14. Спецификация поведения систем. 179

Лекция 15. Архитектурное проектирование. 187

15.1. Структурирование системы.. 190

15.1.1. Модель репозитория. 192

15.1.2. Модель клиент/сервер. 195

15.1.3. Модель абстрактной машины.. 196

Лекция 16. Модели управления. 199

16.1. Централизованное управление. 199

16.2. Системы, управляемые событиями. 202

16.3. Модульная декомпозиция. 206

16.3.1. Объектные модели. 207

16.3.2. Модели потоков данных. 208

Лекция 1. Основные понятия программного обеспечения

1.1. Что такое программное обеспечение

Многие отождествляют термин программное обеспечение с компьютерными программами. Это весьма ограниченное представление. Программное обеспечение — это не только программы, но и вся сопутствующая документация, а также конфигурационные данные, необходимые для корректной работы программ. Программные системы состоят из совокупности программ, файлов конфигурации, необходимых для установки этих программ, и документации, которая описывает структуру системы, а также содержит инструкции для пользователей, объясняющие работу с системой, и часто адрес Web-узла, где пользователь может найти самую последнюю информацию о данном программном продукте.

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

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

2. Программные продукты, созданные на заказ. Это программные системы, которые создаются по заказу определенного потребителя. Такое ПО разрабатывается специально для данного потребителя согласно заключенному контракту. Программные продукты этого типа включают системы управления для электронных устройств, системы поддержки определенных производственных или бизнес-процессов, системы управления воздушным транспортом и т.п.

Важное отличие между этими типами программных продуктов заключается в том, что при создании общих программных продуктов спецификация требований на них разрабатывается компанией-производителем. Для заказных программных продуктов спецификация обычно разрабатывается организацией, покупающей данный продукт. Спецификация необходима разработчикам ПО для создания любого программного продукта.

1.2. Процесс создания программного обеспечения

Создание ПО — это совокупность процессов, приводящих к созданию программного продукта. Эти процессы основываются главным образом на технологиях инженерии программного обеспечения. Существует четыре фундаментальных процесса, которые присущи любому проекту создания ПО.

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

2. Создание программного обеспечения. Разработка и создание ПО согласно спецификации на него.

3. Аттестация программного обеспечения. Созданное ПО должно пройти аттестацию для подтверждения соответствия требованиям заказчика.

4. Совершенствование (модернизация) программного обеспечения. ПО должно быть таким, чтобы его можно было модернизировать согласно измененным требованиям потребителя.

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

1.3. Модель процесса создания ПО

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

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

2. Модели потоков данных и процессов. В них процесс создания ПО представляется в виде множества активностей (процессов), в ходе реализации которых выполняются преобразования определенных данных. Например, на вход активности (процесса) создания спецификации ПО поступают определенные данные, на выходе этой активности получают данные, которые поступают на вход активности, соответствующей проектированию ПО, и т.д. Активность в такой модели часто является процессом более низкого порядка, чем этапы работ в модели предыдущего типа. Преобразования данных при реализации активностей могут выполнять как разработчики ПО, так и компьютеры.

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

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

1. Каскадный подход. Весь процесс создания ПО разбивается на отдельные этапы: формирование требований к ПО, проектирование и разработка программного продукта, его тестирование и т.д. Переход к следующему этапу осуществляется только после того, как полностью завершаются работы на предыдущем.

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

3. Формальные преобразования Основан на разработке формальной математической спецификации программной системы и преобразовании этой спецификации посредством специальных математических методов в программы. Такое преобразование удовлетворяет условию «сохранения корректности». Это означает, что полученная программа будет в точности соответствовать разработанной спецификации.

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

1.4. Методы инженерии программного обеспечения

Эти методы представляют собой структурный подход к созданию ПО, который способствует производству высококачественного программного продукта эффективным, в экономическом аспекте, способом. Такие методы, как структурный анализ и JSD (метод Джексона разработки систем), впервые были представлены еще в 1970-х годах. Эти методы, названные функционально-модульными или функционально-ориентированными, связаны с определением основных функциональных компонентов программной системы и в свое время широко использовались. В 80 - 90-х годах к этим методам добавились объектно-ориентированные методы, предложенные Бучем (Booch) и Рамбо (Rumbaugh). Эти методы, использующие разные подходы, ныне интегрированы в единый унифицированный метод, построенный на основе унифицированного языка моделирования UML (Unified Modeling Language).

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

Таблица 1.1. Компоненты методов инженерии ПО

Компонент	Описание	Пример
Описание модели системы	Описания моделей создаваемых систем и нотация, используемая для разработки этих моделей	Модели объектов, модели потоков данных, модели конечных автоматов и т.п.
Правила	Правила и ограничения, которые необходимо выполнять при разработке моделей систем	Каждый элемент модели должен иметь уникальное имя
Рекомендации	Эвристические советы и рекомендации, отражающие практический опыт применения данного метода	Любой объект в модели не должен иметь более семи подчиненных ему объектов
Руководство по применению метода	Описание работ, которые необходимо выполнить для построения модели системы, а также рекомендации по организации этих работ	Атрибуты любого объекта должны быть документированы, прежде чем будут определены операции, связанные с этим объектом

Не существует идеального и универсального метода — каждый метод имеет свою область применимости. Например, объектно-ориентированные методы часто применяются для создания интерактивных (диалоговых) программных систем, но практически не используются при разработке систем, работающих в режиме реального времени.

1.5. Характеристики качественного программного обеспечения

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

Конечно, множество тех показателей или характеристик, которые можно ожидать от ПО, зависит от типа программной системы. Например, банковская система должна быть защищенной, интерактивная игра должна быть чувствительной к действиям пользователя-игрока, систему телефонных переключений, прежде всего, характеризует ее надежность и т.д., Но эти специфические показатели, как и множество других подобных характеристик, можно обобщить в виде показателей качественных программных систем, приведенных в табл. 1.2.

Таблица 1.2. Основные показатели качественного ПО

Показатель	Описание
Удобство сопровождения	ПО должно быть таким, чтобы существовала возможность его усовершенствования в ответ на измененные требования заказчика или пользователя. Это определяющий показатель, поскольку любое ПО неминуемо подвергается модернизации вследствие изменений, происходящих в реальном мире
Надежность	Определяется рядом характеристик, таких как безотказность, защищенность и безопасность. Надежность ПО означает, что возможные сбои в работе системы не приведут к физическому или экономическому ущербу
Эффективность	Работа ПО не должна приводить к расточительному расходованию таких системных ресурсов, как память или время занятости процессора. Поэтому эффективность ПО описывается следующими характеристиками: скорость выполнения, используемое процессорное время, объем требуемой памяти и т.п.
Удобство в использовании	ПО должно быть удобным в эксплуатации и не требовать чрезмерного напряжения усилий пользователя того уровня, на которого оно рассчитано. Это означает, что программная система должна обладать соответствующим пользовательским интерфейсом и необходимой документацией

1.6. Проблемы специалистов по программному обеспечению

В XXI столетии специалисты по программному обеспечению столкнутся с описанными ниже проблемами.

1. Проблема наследования ранее созданного ПО. Многие большие программные системы, эксплуатируемые в настоящее время, созданы много лет назад, но до сих пор выполняют свои функции надлежащим образом. Проблема наследования означает поддержку и модернизацию таких систем, причем при минимальных финансовых и временных затратах.

2. Проблема все возрастающей разнородности программных систем. В настоящее время программное обеспечение должно быть способно работать в качестве систем, распределенных в компьютерных сетях, состоящих из компьютеров разных типов и использующих различные операционные системы. Проблема возрастающей разнородности программных систем состоит в том, что необходимо разрабатывать надежные программные системы, способные работать совместно с ПО разных типов.

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

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

1.7. Профессиональные и этические требования к специалистам по ПО

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

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

1. Конфиденциальность. Специалист должен соблюдать конфиденциальность, т.е. не разглашать никаких сведений о работодателе и клиентах, независимо от того, подписывал он или нет какое-либо соглашение о соблюдении конфиденциальности.

2. Компетентность. Специалист не должен скрывать (или ложно представлять) свой уровень компетенции и не должен браться за работу, которая этому уровню не соответствует.

3. Защита прав интеллектуальной собственности. Специалист не должен нарушать соответствующее законодательство о защите авторских прав при использовании чужой интеллектуальной собственности (патентов и т.п.). Он также должен защищать интеллектуальную собственность работодателя и клиентов.

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

В разработке подобных этических обязательств большая роль принадлежит профессиональным обществам и институтам. Такие организации, как ACM (Association for Computing Machinery— Ассоциация по вычислительной технике), IEEE (Institute of Electrical and Electronics Engineers — Институт инженеров по электротехнике и электронике) и British Computer Society (Британское компьютерное общество), опубликовали кодекс профессионального поведения, или этический кодекс. Члены этих организаций принимают на себя обязательство следовать данному кодексу. Правила поведения из этого кодекса основаны на общечеловеческих этических нормах.

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

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

Особо трудная ситуация для специалиста возникает тогда, когда работодатель ведет себя неэтичным образом. Скажем, компания разрабатывает программную систему, критическую в отношении безопасности. Но вследствие дефицита времени были подделаны протоколы проверки системы на защищенность. Должен ли специалист в этой ситуации поддерживать конфиденциальность, т.е. неразглашение информации о работодателе, либо все же следует предупредить заказчика ПО или придать гласности тот факт, что система может быть незащищенной?

Сложность этой проблемы состоит в том, что не существует критериев абсолютной защищенности систем. Фактическая защищенность системы может быть проверена только в процессе ее длительной эксплуатации. Даже если система удовлетворяет заранее определенным критериям защищенности, это еще не означает, что она лишена ошибок и не может возникнуть каких-либо сбоев в ее работе.

Лекция 2. Системотехника компьютеризированных систем

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

Существует множество самых разнообразных определений понятия «система», от очень абстрактных до чрезвычайно конкретных. Наиболее удачным определением системы можно считать следующее.

Система - это совокупность взаимодействующих компонентов, работающих совместно для достижения определенных целей.

Это определение охватывает очень широкий круг систем. Например, такая простая система, как карандаш, состоит из двух или нескольких «аппаратных» компонентов, в то время как система управления полетами может состоять из тысяч аппаратных и программных компонентов плюс операторы, которые принимают решения на основе данных, предоставляемых информационными подсистемами.

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

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

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

Приведем примеры интеграционных свойств.

1. Суммарный размер системы. Это пример интеграционного показателя системы, который можно вычислить, исходя только из свойств отдельных компонентов.

2. Безотказность системы. Это свойство зависит от безотказности отдельных компонентов и взаимосвязи между ними.

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

Специалист по программному обеспечению должен знать системотехнику компьютеризированных систем, поскольку здесь программный компонент играет очень важную роль. Например, в 1969 году для осуществления посадки человека на Луна в программе «Аполлон» использовалось ПО, занимающее всего 10 Мбайт, а ПО космической станции — 100 Мбайт. Таким образом, технологии инженерии программного обеспечения часто являются критическим фактором при разработке сложных компьютеризированных систем.

2.1. Интеграционные свойства систем

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

Существует два типа интеграционных свойств.

1. Функциональные свойства, которые проявляются только тогда, когда система работает как единое целое. Например, велосипед имеет функциональные свойства транспортного средства только тогда, когда собран из своих компонентов.

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

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

Существует три тесно связанных между собой фактора, которые влияют на общую безотказность системы.

1. Безотказность аппаратных средств. Этот показатель определяется вероятностью выхода из строя отдельных аппаратных компонентов и временем, необходимым на их замену.

2. Безотказность программного обеспечения. Это показатель работы компонента ПО без сбоев и ошибок. Программные ошибки обычно не оказывают влияния на аппаратные средства системы. Поэтому система может продолжать функционировать даже тогда, когда ПО выдает некорректные результаты.

3. Ошибки операторов. Операторы, эксплуатирующие систему, также могут допускать ошибки в своей деятельности.

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

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

Допустим, система предназначена для эксплуатации при нормальной комнатной температуре. Для того чтобы система могла функционировать при других температурных режимах, се электронные компоненты должны быть рассчитаны для работы в определенном температурном интервале, скажем, от 0 до 45°С. При выходе из этого температурного интервала компоненты могут вести себя непредсказуемым образом. Теперь предположим, что система является внутренней составной частью воздушного кондиционера. Если кондиционер неисправен и гонит горячий воздух через электронные компоненты, то они, а, следовательно, и вся система могут выйти из строя. Если кондиционер работает нормально, то система также должна работать нормально. Но вследствие физической замкнутости кондиционера могут возникнуть непредвиденные влияния разных компонентов устройства друг на друга, что также может привести к различным сбоям.

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

2.2. Система и ее окружение

Любая система зависит от сигналов, данных или другой информации, поступающей на ее входы; иными словами, система функционирует в определенном окружении, которое влияет на ее функционирование и производительность. Иногда окружение можно рассматривать как самостоятельную систему, состоящую из множества других систем, которые влияют друг на друга.

На рис. 2.1 показано несколько систем, объединенных в систему жизнеобеспечения офисного здания. Система отопления, электроэнергетическая система, система освещения, системы водоснабжения и канализации и система безопасности являются подсистемами строения, которое, в свою очередь, также можно рассматривать как систему. Здание расположено на улице, которая также является системой более высокого уровня. Улица будет подсистемой системы города и т.д. Таким образом, окружение какой-либо системы само является системой более высокого уровня. В общем случае окружение какой-либо системы — это композиция ее локального окружения и окружения системы более высокого уровня.

Рис. 2.1. Иерархия систем

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

Приведем две основные причины, которыми вызвана необходимость учитывать при разработке систем их окружение.

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

2. Часто качество функционирования системы может зависеть от параметров окружения самым непредсказуемым образом. Так, система электроснабжения напрямую зависит от уличного окружения здания. Например, работы, проводимые по благоустройству улицы, по недосмотру могут повредить силовой кабель и, следовательно, вывести из строя всю систему электроснабжения здания. Либо грозовой разряд может индуцировать большие токи в электрической системе, что может нарушить ее нормальное функционирование.

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

На разработку систем влияют как человеческие, так и организационные факторы, входящие в окружение системы.

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

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

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

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

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

2.3. Моделирование систем

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

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

На рис. 2.2 представлена блок-схема основных компонентов системы сигнализации, предупреждающей о несанкционированном проникновении в жилище. В табл. 2.1 приведено краткое описание подсистем, которым соответствуют определенные блоки на рис. 2.2.

Рис 2.2. Простая система сигнализации

Таблица 2.1. Функциональные подсистемы системы сигнализации

Подсистема	Описание
Датчики движения	Реагируют на движение в комнатах, которые контролирует система
Дверные датчики	Определяют, открыты ли наружные двери дома
Контроллер	Управляет действиями всей системы
Сирена	Издает мощный звуковой сигнал при незаконном проникновении в жилище
Синтезатор голоса	Синтезирует голосовое сообщение о проникновении в дом
Телефонный информатор	Делает внешний телефонный звонок для уведомления службы безопасности (например, полиции) о проникновении в дом

На этом уровне детализации система разбивается на отдельные подсистемы. Каждая подсистема, в свою очередь, может быть представлена как декомпозиция своих функциональных компонентов. Это такие компоненты подсистемы, которые, исходя из предназначения подсистемы, выполняют какую-либо одну функцию. В противоположность этому подсистема обычно выполняет несколько функций. Конечно, декомпозицию подсистем (и самой системы) можно проводить по другим признакам, например конструктивным или технологическим.

Исторически сложилось так, что модель системной архитектуры используется для вычленения аппаратных и программных компонентов системы, которые обычно разрабатываются параллельно. Вместе с тем противопоставление «аппаратные средства — программное обеспечение» в современных системах чаще всего неуместно и несущественно, поскольку практически все системные компоненты обладают определенными вычислительными возможностями. Например, машины, связывающие множество компьютеров в единую сеть, состоят из репитеров[1], сетевых шлюзов[2] и соединительных кабелей. Репитеры и шлюзы имеют процессоры и программы, управляющие этими устройствами, и, конечно же, другие электронные компоненты.

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

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

Рис. 2.3. Архитектура системы управления полетами

Системная архитектура описывается в терминах функциональных подсистем, независимо от того, являются ли эти подсистемы аппаратными или программными. Вместе с тем функциональные компоненты в системе можно классифицировать по целому ряду категорий, некоторые из них приведены ниже.

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

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

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

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

5. Координирующие компоненты согласуют работу других компонентов. Примером является планировщик заданий в системах реального времени. Планировщик определяет, какой процесс в данный момент времени может обрабатываться процессором.

6. Интерфейсные компоненты преобразуют систему представлений, которыми оперирует один системный компонент, в систему представлений, применяемых другим компонентом. Примером «человеческого» интерфейсного компонента может служить модель какой-нибудь системы и представление ее в виде, понятном другому человеку. Другим примером является аналогово-цифровой преобразователь, преобразующий аналоговый сигнал в последовательность чисел.

В табл. 2.2 описан тип функциональных компонентов архитектуры системы сигнализации, представленной на рис. 2.2.

Таблица 2.2. Типы компонентов системы сигнализации

Тип компонента	Компонент	Функции компонента
Сенсорный	Датчик движения, дверной датчик	Регистрирует движение в защищенном помещении, определяет, открыта ли наружная дверь
Исполнительный	Сирена	Издает звуковой сигнал при незаконном проникновении в жилище
Коммуникационный	Телефонный информатор	Делает телефонный звонок в центр управления при проникновении в дом. Получает ответную команду из центра управления
Координирующий	Контроллер	Координирует все системные компоненты. Действует по командам панели управления и центра управления
Интерфейсный	Синтезатор голоса	Синтезирует сообщение о проникновении в дом

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

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

Лекция 3. Системотехника компьютеризированных систем.

3.1. Процесс создания систем

Этапы процесса создания системы показаны на рис. 3.1. Эти этапы оказывают большое влияние на процесс разработки программного обеспечения в соответствии с каскадной моделью, которая будет описана далее.

Рис. 3.1. Процесс создания системы

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

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

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

В команду разработчиков систем неизбежно включаются специалисты разных профилей. Команда разработчиков должна обладать широким кругом знаний, чтобы всесторонне рассмотреть все системные возможности при принятии каких-либо решений. Рассмотрим систему управления полетом (СУП), в которой используется радиолокационная или какая-нибудь другая сенсорная система для определения местонахождения самолетов (рис. 2.3). На рис. 3.2 схематично показаны тс инженерные дисциплины, которыми должны владеть члены команды разработчиков системы.

Рис. 3.2. Инженерные дисциплины, вовлекаемые в процесс системотехники

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

Поскольку ПО по своей природе является гибким и сравнительно легко настраиваемым, часто решение многих неожиданно возникших проблем перекладывается на плечи специалистов по программному обеспечению. Пусть, например, при создании СУП неудачно выбрано местоположение одной радарной установки — на экране локатора иногда происходит раздвоение изображений. Для удаления этого эффекта необходимо передвинуть радарную установку, что практически не осуществимо. Решением этой проблемы может быть создание специального ПО, которое поможет удалить раздвоение изображений. Но в этом случае может потребоваться более мощная вычислительная техника, чем та, которая изначально запланирована, и это, в свою очередь, также может стать определенной проблемой.

Перед специалистами по программному обеспечению часто ставятся задачи, которые необходимо решать без увеличения стоимости аппаратных средств. Поэтому многие так называемые программные ошибки не являются следствием каких-либо «врожденных» черт или свойств ПО. Они могут быть результатом попытки модернизировать программное обеспечение в соответствии с изменениями требований, предъявляемых к создаваемой системе.

3.1.1. Определение системных требований

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

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

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

3. Свойства, которые должны отсутствовать у системы. Порой гораздо важнее указать, что система не должна делать, чем-то, что она должна выполнять.

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

Подчас основная трудность в определении системных требований состоит в том, что система строится для того, чтобы помочь в решении «злостной» проблемы (wicked problem). «Злостная» проблема — это проблема такой большой сложности и имеющая столько взаимосвязанных входных воздействий, что ее невозможно точно описать. Истинная природа такой проблемы может проявиться только в процессе ее решения. В качестве экстремального примера «злостной» проблемы можно привести задачу предсказания землетрясений. В настоящее время не существует точных способов предсказания ни эпицентра землетрясения, ни его времени, ни силы, ни воздействия на окружающую среду. Поэтому невозможно заранее полностью спланировать все действия на случай большого землетрясения — это можно сделать только тогда, когда оно произойдет.

3.1.2. Проектирование систем

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

Рис. 3.3. Этапы проектирования системы

1. Разбиение требований на группы. Требования анализируются и разбиваются на отдельные группы. Обычно множество требований можно разбить на группы многими способами, на этом этапе сохраняются все «жизнеспособные» разбиения.

2. Определение подсистем. Определяются подсистемы, которые индивидуально или совместно реализуют системные требования. Группа требований обычно проецируется на несколько подсистем, поэтому можно объединить несколько требований в одно. Вместе с тем на определение систем влияют не только системные требования, но и организационные или производственные факторы.

3. Распределение требований по подсистемам. В принципе эта операция должна быть выполнена на предыдущем этапе определения подсистем. Но на практике не всегда можно четко согласовать разбиение требований и определение подсистем. Или, например, ограниченный ассортимент подсистем, приобретаемых у внешних поставщиков, может привести к пересмотру требований к системе.

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

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

На рис. 3.3 линии, соединяющие этапы, имеют стрелки на обоих концах. Это означает наличие обратной связи между этапами и возможность возвращаться к предыдущему этапу в процессе проектирования системы.

Для большинства систем можно разработать несколько проектов. Это предполагает широкий диапазон возможных решений, состоящих из разных комбинаций аппаратных и программных компонентов и человеческого фактора. Для дальнейшей разработки выбирается решение, наиболее полно удовлетворяющее системным требованиям. Вместе с тем на выбор проекта часто влияют организационные и политические факторы. Например, если система разрабатывается по заказу правительства, обычно выбираются национальные поставщики комплектующих изделий, даже если по определенным параметрам они уступают зарубежным; это, естественно, влияет на выбор проекта системы.

3.1.3. Разработка подсистем

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

Иногда разработка всех подсистем начинается «с нуля» Но чаще бывает так, что некоторые подсистемы можно приобрести на рынке промышленных изделий и затем интегрировать в создаваемую систему. Обычно бывает дешевле купить готовое изделие, чем разрабатывать собственную подсистему. На этом этапе может возникнуть необходимость вернуться к этапу проектирования для того, чтобы на уровне требований «подогнать» купленное изделие к системе. Это изделие может не удовлетворять всем требованиям, предъявляемым к компоненту, который оно замещает, но если ассортимент коммерческих продуктов достаточно широк, затраты на повторное проектирование невелики.

Все подсистемы, как правило, разрабатываются параллельно. Если возникают внутренние проблемы, прерывающие процесс разработки подсистем, может потребоваться модификация всей системы. Когда система в значительной степени состоит из аппаратных компонентов, проведение модификации системы после начала производства ее компонентов может оказаться весьма затратным. Приходится находить какое-то «обходное» решение для выхода из подобных ситуаций. Часто таким решением является включение в систему программных компонентов, поскольку они достаточно гибкие и сравнительно легко поддаются модификациям. В свою очередь, это ведет к изменению требований, предъявляемых к программному обеспечению, и к изменениям в проекте ПО.

3.1.4. Сборка системы

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

Процесс последовательной сборки считается более подходящим для системной интеграции по двум причинам.

1. Обычно невозможно составить такой график работ, при котором у всех подсистем этап разработки заканчивается одновременно.

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

Ошибки и дефекты отдельных подсистем и системы в целом часто проявляются именно на этапе сборки.

3.1.5. Инсталляция системы

При инсталляции система «погружается» в то окружение, в котором она должна работать. В процессе инсталляции сложных систем могут проявиться различные проблемы, на решение которых подчас уходит несколько месяцев, а то и лет. Среди них могут быть проблемы, описанные ниже.

1. Окружение, в котором инсталлируется система, не совпадает с тем, для которого она спроектирована. Это общая проблема, которая часто возникает при инсталляции ПО. Например, программная система может использовать функции, которые предоставляет только определенная версия операционной системы. Однако версия, определяющая текущее окружение инсталлируемой программной системы, может не обладать этими функциями. В этом случае после инсталляции система может не работать совсем либо некоторые ее функции окажутся не реализованными.

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

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

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

3.1.6. Ввод системы в эксплуатацию

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

Например, проблемой, которая может проявиться только после ввода системы в эксплуатацию, является совместимость новой и существующих систем. Это может быть чисто физическая проблема совместимости. Возможны проблемы при передаче данных от одной системы к другой. Тогда ввод в эксплуатацию новой системы может привести к возрастанию ошибок системных операторов вследствие неправильного использования интерфейсных команд новой системы.

3.1.7. Эволюция систем

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

Дата добавления: 2013-12-12