Дипломная работа: Автоматизация учета посещений клиентов в ООО "Bagira"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
42
создается техническая документация. В результате этапа кодирования появляется
рабочая версия продукта.
4. Тестирование и отладка
Тестирование ПО тесно связано с этапами проектирования и реализации. В
систему встраиваются специальные механизмы, которые дают возможность
производить тестирование программного обеспечения на соответствие требований
к нему, проверку оформления и наличие необходимого пакета документации.
Результатом тестирования является устранение всех недостатков
программного продукта и заключение о её качестве.
5. Эксплуатация и сопровождение
Ввод в эксплуатацию ПО предусматривают установку программной
системы, обучение пользователей, документирование. Поддержка
функционирования ПО должна осуществляться группой технической поддержки
разработчика.
Сопровождение – это процесс адаптации поставляемого ПО к новым
условиям, внесения изменений в ПО и соответствующую документацию,
вызванных возникшими проблемами или потребностями в модификации при
сохранении неизменными его основных функций.
Вывод из эксплуатации программного обеспечения осуществляется в
результате его морального, прихода на смену более совершенных продуктов или по
иным объективным или субъективным причинам.
Модели ЖЦ ПО
Существуют три вида моделей ЖЦ ПО: каскадная (водопадная),
эволюционная, спиральная, итерактивная модель.
Классический жизненный цикл. Каскадная модель проста и понятна, но не
так практична как раньше. В условиях динамично изменяющихся требований,
строго структурированный процесс может из преимущества превратиться в помеху
на пути успешного завершения разработки системы. Поэтому сегодня водопадная
модель применяется преимущественно крупными компаниями для больших и
сложных проектов, которые предполагают всеобъемлющий контроль рисков.
Плюсы каскадной модели:
Полное документирование каждого этапа;
43
Четкое планирование сроков и затрат;
Прозрачность процессов для заказчика;
Минусы каскадной модели:
Необходимость утверждения полного объема требований к системе
еще на первом этапе;
В случае необходимости внесения изменений требований позднее –
возврат к первой стадии и переделка заново всей проделанной работы;
Увеличение затрат средств и времени в случае необходимости
изменения требований.
Несмотря на то, что каскадная модель все еще используется, она уже
утратила былые позиции. Сегодня ей на смену приходят более продвинутые
модели и методологии разработки программного обеспечения [8, c. 253].
Спиральная модель представляет шаблон процесса разработки ПО,
который сочетает идеи итеративной и каскадной моделей. Суть ее в том, что весь
процесс создания конечного продукта представлен в виде условной плоскости,
разбитой на 4 сектора, каждый из которых представляет отдельные этапы его
разработки: определение целей, оценка рисков, разработка и тестирование,
планирование новой итерации.
В спиральной модели жизненный путь разрабатываемого продукта
изображается в виде спирали, которая, начавшись на этапе планирования,
раскручивается с прохождением каждого следующего шага. Таким образом, на
выходе из очередного витка мы должны получить готовый протестированный
прототип, который дополняет существующий билд. Прототип, удовлетворяющий
всем требованиям – готов к релизу.
Главная особенность спиральной модели – концентрация на возможных
рисках. Для их оценки даже выделена соответствующая стадия. Основные типы
рисков, которые могут возникнуть в процессе разработки ПО:
Нереалистичный бюджет и сроки;
Дефицит специалистов;
Частые изменения требований;
Чрезмерная оптимизация;
Низкая производительность системы;
44
Несоответствие уровня квалификации специалистов разных отделов.
Плюсы спиральной модели:
улучшенный анализ рисков;
хорошая документация процесса разработки;
гибкость – возможность внесения изменений и добавления новой
функциональности даже на относительно поздних этапах;
раннее создание рабочих прототипов.
Минусы спиральной модели:
может быть достаточно дорогой в использовании;
управление рисками требует привлечения высококлассных
специалистов;
успех процесса в большой степени зависит от стадии анализа рисков;
не подходит для небольших проектов.
Итерактивная модель ЖЦ ПО. Не все модели жизненного цикла
последовательны. Существуют также итеративные (или инкрементальные) модели,
в которых используется другой подход. Вместо одной продолжительной
последовательности действий здесь весь жизненный цикл продукта разбит на ряд
отдельных мини-циклов. Причем каждый из них состоит из все тех же базовых
стадий модели жизненного цикла. Эти мини-циклы называются итерациями. В
каждой из итераций происходит разработка отдельного компонента системы, после
чего этот компонент добавляется к уже ранее разработанному функционалу.
Итеративная модель не предполагает полного объема требований для начала
работ над продуктом. Разработка программы может начинаться с требований к
части функционала, которые могут впоследствии дополняться и изменяться.
Процесс повторяется, обеспечивая создание новой версии продукта для каждого
цикла.
В несколько упрощенном виде, итеративная модель состоит из четырех
основных стадий, которые повторяются в каждой из итераций:
определение и анализ требований;
дизайн и проектирование – согласно требованиями. Причем дизайн
может как разрабатываться отдельно для данной функциональности, так и
дополнять уже существующий;
45
разработка и тестирование – кодирование, интеграция и тестирование
нового компонента;
фаза ревью – оценка, пересмотр текущих требований и предложения
дополнений к ним.
По результатам каждой итерации принимается решение – будут ли
использованы ее результаты для дополнения существующей функциональности в
качестве входной точки для начала следующей итерации (т.н. инкрементальное
прототипирование). В конечном итоге, достигается точка, в которой все требования
были воплощены в продукте – происходит релиз.
В математических терминах, итеративная модель представляет реализацию
методики последовательной аппроксимации – то есть, постепенное приближение к
образу готового продукта:
Ключ к успешному использованию этой модели – строгая валидация
требований и тщательная верификация разрабатываемой функциональности в
каждой из итераций.
Основные стадии процесса разработки в итеративной модели фактически
повторяют модель водопада. В каждой итерации создается программное
обеспечение, требующее тестирования на всех уровнях.
Плюсы итеративной модели:
раннее создание работающего ПО;
гибкость – готовность к изменению требований на любом этапе
разработки;
каждая итерация – маленький этап, для которого тестирование и
анализ рисков обеспечить проще, чем для всего жизненного цикла продукта.
Минусы итеративной модели:
каждая фаза – самостоятельна, отдельные итерации не накладываются;
могут возникнуть проблемы с реализацией общей архитектуры
системы, поскольку не все требования известны к началу проектирования.
V-модельэто улучшенная версия классической каскадной модели. Здесь
на каждом этапе происходит контроль текущего процесса, для того чтобы убедится
в возможности перехода на следующий уровень. В этой модели тестирование
46
начинается еще со стадии написания требований, причем для каждого
последующего этапа предусмотрен свой уровень тестового покрытия.
Для каждого уровня тестирования разрабатывается отдельный тест-план, то
есть во время тестирования текущего уровня, мы также занимаемся разработкой
стратегии тестирования следующего. Создавая тест-планы, мы также определяем
ожидаемые результаты тестирования и указываем критерии входа и выхода для
каждого этапа.
В V-модели каждому этапу проектирования и разработки системы
соответствует отдельный уровень тестирования. Здесь процесс разработки
представлен нисходящей последовательностью в левой части условной буквы V, а
стадии тестирования – на ее правом ребре. Соответствие этапов разработки и
тестирования показано горизонтальными линиями.
Плюсы V-модели:
строгая этапизация;
планирование тестирования и верификация системы производятся на
ранних этапах;
улучшенный, по сравнению с каскадной моделью, тайм-менеджмент;
промежуточное тестирование.
Минусы V-модели:
недостаточная гибкость модели;
собственно создание программы происходит на этапе написания кода,
то есть уже в середине процесса разработки;
недостаточный анализ рисков;
нет работы с параллельными событиями и возможности
динамического внесения изменений.
Для создания ИС для учета клиентов салона красоты должна использоваться
каскадная модель, так как задание было хорошо специфицировано
формулировано) и будущий программный продукт получится достаточно
простой.
Стандарты и модели ЖЦ ПО.
В теории и практике для разработки ИС применяются следующие стандарты:
Источник: https://baza.diplomsite.ru/previewfile/2401