58
Данная модель имеет более приближенный к современным методам
алгоритм, однако все еще имеет ряд недостатков. Является одной из основных
практик экстремального программирования. Данная модель основывается на
разработки прототипов и прототипирования продукта.
Преимущества и недостатки данной модели близки к каскадной
модели. К преимуществам относятся:
1. Сроки разработки чётко фиксируются.
3. Стоимость разработки фиксированная.
4. Ориентация на тестирование позволяет избегать накопления ошибок
после каждого этапа, постоянно проверяя проект
Недостатком является то, что необходимо заранее знать все требования
и параметры создаваемого ПО. После начала разработки их изменять нельзя.
Данная модель остаётся недостаточно гибкой в плане разработки, но её
уровень тестового покрытия позволяет использовать эту модель для создания
ПО на ответственные системы, с повышенной защитой от сбоев и ошибок.
Эта модель подходит для создания малых и средних проектов, в условиях,
когда все требования заранее определены.
В инкрементной модели разработка начинается с анализа, который
может быть выполнен для всего проекта один раз, после чего всё делится на
модули (рис.10).
Рисунок 10. Инкрементная модель разработки программного
обеспечения.
59
В каждом отдельном модуле можно что-то спроектировать,
запрограммировать, протестировать, а после этот модуль добавить к
основной программе, расширяя её функционал. Одновременно могут
разрабатываться несколько модулей.
Преимуществом инкрементной модели является то, что есть
возможность выпускать продукт по частям в виде отдельных модулей
которые расширяют функционал основной программы и недостатки. Кроме
того, необходимо заранее знать все требования и параметры создаваемого
ПО, но после начала разработки их можно изменять или дополнять.
К недостаткам инкрементной модели относятся следующие:
1) при изменении или дополнении функционала могут изменяться
сроки разработки.
2) стоимость разработки также может изменяться.
Данная модель применяется в средних и крупных проектах, где
требования заранее определяются, но в зависимости от различных условий
могут быть изменены.
В итерационной модели, аналогичной каскадной модели, процесс
разработки делится на итерации. В каждой итерации участвуют все этапы
разработки: анализ, проектирование, разработка и тестирование. Сначала
создаётся «набросок» будущей системы, а после с каждой итерацией в неё
добавляется функционал (рис.11).
Следовательно, итерационная модель имеет преимущество перед
каскадной за счет возвратов на предыдущие этапы
К преимуществам итерационной модели можно отнести возможность
изменения входных на каждом из этапов, надежность и простота данной
модели. Кроме того, первая версия продукта может быть выпущена очень
быстро.
60
Однако при частых возвратах увеличивается время реализации проекта,
в результате могут возникнуть расхождения между входными данными и
выходными из-за того, что изменяются требования.
Рисунок 11. Итерационная модель.
Такая модель используется в больших проектах. Также эта модель, как
и предыдущая, позволяет выпускать не полностью готовый продукты
добавлять функционал, который изначально оговорен не был.
Спиральная модель может быть представлена в виде спирали (рис.12).
Она сочетает в себе идеи итеративной и каскадной моделей. Главной
особенностью данной модели является наличие этапа анализа рисков, на
котором происходит анализ возможных рисков. Примером могут служить:
нехватка специалистов для выполнения поставленных задач, нереалистичные
бюджет и сроки выполнения, частые изменения требований и т.д.
Преимущества и недостатки схожи с итерационной моделью. Так
можно выделить следующие преимущества:
61
1) первая версия продукта может быть выпущена очень быстро. Далее
постепенно можно наращивать функционал, вводя новые итерации в виде
обновлений;
2) сокращается количество итераций
3) предсказуемость работ
4) сокращаются сроки разработки.
Рисунок 12.Спиральная модель.
К недостаткам относятся следующие:
1) Сроки определяются примерно и могут изменяться.
2) Стоимость разработки также зависит от времени разработки.
3) Может быть весьма дорогой в использовании и требовать
привлечение высококлассных специалистов.
62
Данная модель, как правило, используется в крупных проектах, где
отсутствуют чёткие требования к системе, или они часто меняются. Для
подведения итогов предлагаем рассмотреть следующее сравнение методов
(табл.13):
Таблица 13.
Сравнение методов.
Критерии
Каскадная
модель
V модель
Инкрементна
я модель
Итерат
ивная
модель
Спиральная
модель
Размер
проекта
Крупный
-
-
+
+
+
Средний
-
+
+
-
+
Мелкий
+
+
-
-
-
Требования
к системе
Заранее чётко определены
+
+
+
-
-
Заранее чётко не определены
-
-
-
+
+
Фиксированы
+
+
-
-
-
Могут меняться
-
-
+
+
+
Стоимость
Фиксированная
+
-
-
-
-
Меняющаяся
-
+
+
+
+
Способ
выпуска
Готовый продукт
+
+
-
-
-
Частями
-
-
+
+
+
Сроки
Фиксированные
+
+
-
-
-
Меняющиеся
-
-
+
+
+
Ориентация на тестирование
-
+
-
-
-
Ориентация на анализ рисков
-
-
-
-
+
Рассматривая приведённую таблицу 13, можно подвести итог:
1. Каскадную модель лучше использовать для мелких проектов, при
этом заранее определив конечный вид и характеристики этого проекта. Эта
модель позволит получить готовый продукт без дополнительных затрат, и
точно к сроку.
2. V-модель стоит использовать, если проект должен быть надёжным и
хорошо протестированным, но для крупных проектов это может вылиться в
большую стоимость и длительные сроки.
3. Инкрементная модель подходит для крупных и средних проектов,
для которых есть заранее определённые требования, что позволяет сразу
63
начать разработку, и выпускать продукт порциями, а далее по необходимости
добавлять ранее неоговоренные функции.
4. Итеративную модель стоит использовать в крупных проектах, где
неизвестен будущий функционал, но есть представление конечного вида
продукта. Это позволит во время разработки добавлять любой функционал и
вводить его в продукт порциями.
5. Спиральная модель подходит для крупных и средних проектов, когда
мы не готовы просто так рисковать, добавляя какой-либо функционал и
тратить на него время, а сначала хотим убедиться, что это нужно, проведя
анализ рисков.
По результатам проведенного анализа для автоматизации учета готовой
продукции будет выбрана V-образная модель, т.к. объектом внедрения
является малое предприятие, а модель позволяет быстро разработать
программу.
Опустим первоначальные 3 фазы (анализ, проектирование, реализация)
и перейдем к рассмотрению этапов внедрения программного продукта.
Этапы внедрения:
Исследование
Написание ТЗ
Настройка системы (программного продукта)
Проверка системы
Правильная эксплуатация системы
Эксплуатация на предприятии
Первый этап проекта – исследование на предприятии всех
протекающих процессов, которые будет охватывать система. Сроки
исследования на предприятии зависят от масштабов работ, а также
непосредственно от разрабатываемой системы. При автоматизации
небольшого предприятия сроки исследования могут быть увеличены. Время
64
отводимое на исследование небольшого предприятия примерно составляет от
одной до трех недель.
Второй этап проекта – написание технического задания. Техническое
задание включает в себя различные требования и пожелания заказчика, а
также основные моменты разрабатываемого продукта в виде справочников,
алгоритмов расчета, отчетных форм, разграничение прав доступа
пользователей.
Написание технического задания занимает от двух до четырех недель
Третий этап проекта – настройка системы (автоматизация). Под
настройкой системы подразумевается формирование справочников, отчетных
форм, разграничение прав доступа для пользователей. Время отводимое на
настройку системы от двух до трех недель.
Четвертый этап проекта – проверка системы. Проверка системы
включает в себя демонстрационный вариант программного продукта, а также
корректировку обнаруженных ошибок. Среднее время отводимое на
проверку системы 2 недели.
Пятый этап проекта – опытная эксплуатация системы. Опытная
эксплуатация системы включает в себя работу с реальными данными, но при
этом параллельно используется прежняя старая система либо те электронные
таблицы, в которых предприятия до настоящего момента осуществляла свою
работу. Этот этап необходим для того, чтобы можно было сопоставить
результаты работы в новой системе с результатами, которые получены были
прежним способом (вручную или с применением старых программных
продуктов или электронных таблиц). В среднем на этап опытной
эксплуатации занимает отчетный период равный 1-му месяцу.
После окончания вышеописанных этапов работ, мы можем говорить о
том, что внедрение программного продукта завершено и идет его
эксплуатация. Однако часто, на этапе промышленной эксплуатации, когда
пользователь работает с реальными данными и в «боевом» режиме, все же
65
приходится производить работы по доработке системы и исправлению
найденных ошибок.
Шестой этап проекта – промышленная эксплуатация системы.
Промышленная эксплуатация системы подразумевает переход предприятия
на новый программный продукт и отказ от всех альтернативных способов
работы за рамками данной системы. Этап промышленной эксплуатации
системы подразумевает организацию службы технической поддержки
системы либо получение данных услуг от сторонних организаций. В рамках
проекта этап промышленной эксплуатации системы обычно занимает около 1
месяца.
Следующей фазой будет эксплуатация и сопровождение проекта, она
включает в себя следующие этапы.
эксплуатация проекта;
сопровождение и модернизация проекта.
На этапе Эксплуатация проекта получают информацию о работе всей
системы в целом и отдельных ее компонентов и собирают статистику о сбоях
системы в виде замечаний, которые накапливаются для выполнения
следующего этапа.
На этапе Сопровождение проекта выполняются два вида работ:
ликвидируются последствия сбоев в работе системы и
исправляются ошибки, не выявленные при внедрении проекта,
осуществляется модернизация проекта. В процессе модернизации
проект либо дорабатывается, т.е. расширяется по составу подсистем и задач,
либо производится перенос системы на другую программную или
техническую платформу с целью адаптации ее к изменяющимся внешним и
внутренним условиям функционирования, в результате чего получают
модернизированные документы.
66
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На практике в процессе ЖЦ ИС исходные требования поэтапно
уточняются, модифицируются, расширяются и детализируются по
согласованию между заказчиком и разработчиком. Базой таких уточнений
являются неформализованные представления и знания специалистов-
заказчиков и разработчиков, а также результаты промежуточных этапов
проектирования. Однако установить некорректность таких эталонов еще
труднее, чем обнаружить дефекты в сопровождаемых программах, так как
принципиально отсутствуют формализованные данные, которые можно
использовать как исходные. Важной особенностью процесса выявления
ошибок в программах является отсутствие полностью определенной
программы - эталона, которой должны соответствовать текст и результаты
функционирования разрабатываемой программы. Поэтому установить
наличие и локализовать дефект непосредственным сравнением с программой
без ошибок в большинстве случаев невозможно.
При отладке и тестировании обычно сначала обнаруживаются
вторичные ошибки и риски, т.е. последствия и результаты проявления
некоторых внутренних дефектов или некорректностей программ (рис. 13).
67
Рисунок 13. Классификация ошибок и рисков.
Потери эффективности и риски программ за счет неполной
корректности в первом приближении можно считать прямо
пропорциональными (с коэффициентом) вторичным ошибкам в выходных
результатах.
Причинами возникновения и проявления рисков могут быть:
злоумышленные, активные воздействия заинтересованных лиц;
случайные негативные проявления дефектов внешней среды,
системы или пользователей.
В первом случае риски могут быть обусловлены искажениями
программ и информационных ресурсов и их уязвимостью от
предумышленных, внешних воздействий (атак) с целью незаконного
использования или искажения информации и программ, которые по своему