Дипломная работа: Автоматизированные системы управления производственно-технологическими процессами (на примере АО «Грасис»)
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
20
Этот метод мог бы работать удовлетворительно, если бы требования к
дизайну могли быть идеально проработаны до начала разработки дизайна, и
если бы дизайн был полностью готов и согласован к моменту началась
реализация программы, и если бы код был совершенен до начала тестирования,
и если бы тестирование гарантировало, что ошибок не осталось в коде до того,
как пользователи начали работать с ним, и, конечно, если пользователи никогда
не меняли свое мнение о требованиях. Увы, идеальных условий не бывает.
Некоторые простые АСУ ТП могут быть разработаны с применением
метода водопада, но эта модель плохо работает для АСУ ТП средней и большой
сложности. Просто невозможно гарантировать правильность любой АСУ ТП
более чем с 200 переменными процесса, столь же строго, как математическое
доказательство. Доказательство функциональности АСУ ТП априори было
выгодно и полезно в первые дни внедрения систем управления, когда такие
АСУ ТП были крошечными, но сегодняшние многофункциональные АСУ ТП
могут обрабатывать до миллиона переменных, поэтому, данный метод в
современных условиях не столь эффективен.
Основные достоинства модели водопада:
1) Простая структура модели, нет потребности в профессиональных
разработчиках;
2) Благодаря строгим этапам разработки легко отслеживать прогресс,
ресурсы и риски;
3) Задачи системы стабильны и ясны разработчикам с начала проекта;
4) Стоимость и сроки проекта могут быть определены на начальном
этапе.
Основные недостатки модели водопада:
1) Процесс разработки модели водопада не является гибким, требуется
больше времени и ресурсов для исправления ошибок, допущенных в начале
разработки;
2) Нельзя вносить изменения в процессе разработки проекта;
21
3) Тестирование проводится только готового продукта, а не отдельных
модулей, возможно появление внутренних ошибок в процессе эксплуатации.
Быстрое прототипирование уже давно используется при разработке
однотипных АСУ ТП, разрабатываемых для решения похожих или хорошо
изученных задач. Последнее время метод активно применяется для
прототипирования более крупных систем в двух вариантах - «не используемой»
модели и «эксплуатационной» модели, которая на самом деле является
дополнительной моделью. Этот процесс разработки создает программу, которая
выполняет некоторый существенный или, возможно, типичный набор функций
для конечного продукта.
Прототипный подход, основанный на простом использовании, часто
используется, если целью является проверка метода реализации, языка или
приемлемости для конечного пользователя. Если эта технология полностью
жизнеспособна, прототип может стать основой для разработки конечного
продукта, но обычно это всего лишь средство достижения абсолютно
безопасной функциональной спецификации (Рисунок ).
С этого момента процесс очень похож на модель водопада. Основное
различие между этой моделью и моделью водопада заключается не только в
создании эксплуатационного прототипа или функционального подмножества.
Суть в том, что это делается очень быстро - отсюда и термин «быстрая».
Основные достоинства модели быстрого прототипирования:
1) Быстрое получение продукта для начального просмотра;
2) Повторное использование блоков системы снижает стоимость;
3) Привлечение пользователей сводит риск неудовлетворенности
системой к нулю.
Основные недостатки модели быстрого прототипирования:
1) Требуются разработчики и пользователи готовые к быстрому
выполнению работ ввиду временных ограничений на создание прототипов;
2) Требуются высококвалифицированные разработчики знакомые с
инструментальными системами разработки для ускорения времени разработки;
22
Рисунок 4. Модель быстрого прототипирования
3) Есть возможность замкнутого цикла разработки, при котором проект
не завершиться никогда.
Инкрементная модель учитывает, что этапы разработки АСУ ТП не
являются дискретными. Вместо этого, Сборка 0 (прототип) улучшается и
функциональность добавляется до тех пор, пока она не станет Сборкой 1,
которая после улучшения станет сборкой 2 и т. д. Эти сборки не являются
версиями, выпущенными для конечного производства, а являются лишь
поэтапными компиляциями разрабатываемой системы на новом уровне
функциональности или полноты.
23
По мере приближения сроков к сдаче проекта к завершению, диспетчер
проекта может планировать новую сборку каждый день в 5 часов вечера.
Благодаря такому подходу, сразу видно программиста или команду, у
кого нет готового модуля к сборке, или чей модуль вызывает сбои компиляции
или регрессионного тестирования.
На рисунке 5 показано, что инкрементная модель является вариантом
моделей водопада и быстрого прототипирования. Метод предназначен для
предоставления оперативной оценки качества продукта на каждом этапе
сборки, но каждая сборка еще не содержит конечный продукт.
Рисунок 5. Инкрементная модель
Одним из самых больших преимуществ инкрементной модели является
то, что она достаточно гибкая, чтобы реагировать на критические изменения
продукта по мере развития. Еще одно очевидное преимущество заключается в
том, что аналитики и разработчики могут решать более сложные задачи.
24
Пользователи и разработчики развиваются в процессе разработки новой
системы, и любая модель, которая позволяет им включать это обучение в
продукт, является предпочтительной.
Риском является, конечно, то, что обучение превышает
производительность, и проект становится исследовательским, превышающим
время и бюджет или, что еще хуже, никогда не получается готовый продукт
вообще. Поскольку почти каждая разрабатываемая программа - это та, которая
никогда ранее не была написана или не была написана этой конкретной
командой, синдром исследовательской деятельности встречается слишком
часто. Тем не менее, обучение не должно превышать реальную разработку, если
команда разработчиков осведомлена о риске и ориентирована на требования
клиентов.
Основные достоинства инкрементной модели:
1) Снижение длительности разработки системы;
2) Снижение стоимости разработки системы;
3) Упрощение данных модели делает их более понятными
разработчикам.
Основные недостатки инкрементной модели:
1) Необходимо постоянно измерять прогресс разработки системы;
2) Структура системы ухудшается при добавлении новых компонентов и
делает дорогостоящими последующие изменения;
3) Нет возможности учитывать возникающие изменения в требованиях к
системе.
Спиральная модель, разработанная доктором Барри Боем в TRW,
является усовершенствованием модели водопада / быстрого прототипа с
анализом рисков, предшествующим каждой фазе каскада.
Можно представить модель быстрого прототипирования, выполненную
в виде спирали (Рисунок ).
Эта модель была успешно использована для внутренней разработки
больших систем и особенно полезна, когда повторное использование АСУ ТП
Источник: https://baza.diplomsite.ru/previewfile/2529