На этапе тестирования решают две основные задачи:
- Тестирование решения – выполняются планы тестирования, созданные на этапе планирования и расширенные и опробованные на этапе разработки;
- Пилотная эксплуатация – развертывание решения в тестовой среде и тестирование с привлечением будущих пользователей и реализацией реальных сценариев использования системы. Эта задача выполняется до начала этапа развёртывания.
Цель этапа тестирования – снижение риска, возникающего при вводе решения в промышленную эксплуатацию.
Для успеха этапа тестирования необходимо, чтобы произошла смена отношения к проекту и разработчик переключился с разработки новых функций на обеспечение должного качества решения.
На данной стадии разработки информационной системы необходимо провести следующие типы тестирования:
- Базовое тестирование – низкоуровневое техническое тестирование. Проводится самим разработчиком в процессе написания программного кода. Применяется метод «белого ящика», высокий риск ошибок.
- Тестирование на пригодность к использованию – высокоуровневое тестирование, выполняется тестировщиком и будущими пользователями продукта. Применяется метод «чёрного ящика».
- Альфа- и бета-тестирование – в терминах MSF альфа-код – это в основном все исходные тексты, созданные на этапе разработки модели процессов MSF, а бета-код – код, прошедший тестирование на этапе тестирования. Поэтому на этапе разработки модели процесса MSF тестируется альфа-код, а на этапе тестирования – бета-код.
- Тестирование совместимости – от разрабатываемого решения требуется возможность интеграции и способность к взаимодействию с существующими системами и программными решениями. Данная форма тестирования ориентирована на проверку интегрируемости и способности разрабатываемого решения взаимодействовать с существующими системами. В данном конкретном случае будет проверятся корректность работы приложения на оборудовании пользователя и используемым пользователем программным обеспечением.
- Тестирование производительности – ориентировано на проверку того, удовлетворяет ли приложение требованиям по производительности и уровню комфортности работы по скорости.
- Тестирование документации и справочной системы – тестируются все разработанные сопровождающие документы и справочные системы.
Пилотная эксплуатация – это тестирование решения в промышленной среде. Основная задача пилотной эксплуатации – продемонстрировать, что решение способно стабильно работать условиях промышленной эксплуатации и удовлетворяет требованиям бизнеса. В процессе пилотной эксплуатации решение испытывается в реальных условиях. Пилотная эксплуатация дает возможность пользователям высказать свое мнение о работе продукта. Руководствуясь этим мнением разработчиком устраняются все возможные неполадки или создается план действий на случай непредвиденных обстоятельств. В конечном итоге, пилотная эксплуатация позволяет принять решение, стоит ли начинать полномасштабное развертывание или отложить до устранения неполадок, способных сорвать развертывание.
План процесса пилотной эксплуатации для разрабатываемой информационной системы приведен в таблице 3.2.
Таблица 3.2 – План пилотной эксплуатации
Действие | Описание | ||
1. Выбор критериев успеха | Разработчик и участники опытного тестирования определяют критерии успешности и согласовывают их | ||
2. Выбор пользователей и места установки | Формируется команда участников опытного тестирования со стороны пользователей и разработчиков. Определяется место развертывания пилотного процесса. | ||
3. Подготовка пользователей и места установки | Проводится обучение пользователей – участников испытания. Подготавливается место установки. | ||
4. Развёртывание опытной версии | Устанавливается опытная версия и включается в работу. | ||
5. Поддержка и мониторинг опытной версии | Контроль работы пользователей и системы, оказание помощи в эксплуатации, сбор сведений о работе системы | ||
6. Обратная связь с пользователями и оценка результатов | Пользователи высказывают своё мнение о работе системы, указывают на недочёты и ошибки. | ||
7. Внесение изменений и дополнений | Исправляются обнаруженные ошибки, вносятся изменения в дизайн или процесс. Исправленные результаты предоставляются для работы и оценки пользователям. | ||
8. Решения о развертывании | Если результаты работы опытного тестирования удовлетворяют пользователей принимается решение о развертывании системы. |
На этом этапе разработчик (или команда) развёртывает необходимые для решения технологии и компоненты, проект переходит на стадию сопровождения и поддержки, а заказчик окончательно утверждает его. После развертывания команда проводит оценку проекта и опрос пользователей, чтобы выяснить степень их удовлетворенности.
Цели этапа развертывания:
¾ перенести решение в промышленную среду;
¾ признание заказчиком факта завершения проекта.
Развертывание компонентов, характерных для конкретного места установки, состоит из нескольких стадий: подготовки, установки, обучения и формального одобрения.
Результатами этапа развертывания системы являются системы сопровождения и поддержки, хранилище документов, где размещаются все версии документов и кода, разработанных в течение проекта.
Для развертывания разрабатываемой системы был составлен план действий, который приведен в таблице 3.1.
Таблица 3.1 – План развертывания приложения
Действие | Описание действия |
1. Резервное копирование | Производится резервное копирование данных пользователя при его участии и согласовании путем переноса информации на сменные носители (СD, DVD) |
2. Установка базовых компонентов решения | Применение технологий, обеспечивающих работу решения. В данном случае – установка компонента Visual FoxPro |
3. Установка клиентского приложения | Перенос на компьютер пользователя и установка окончательного варианта разработанной ИС и базы данных |
4. Обучение | Производится обучение пользователей по работе с системой, разработчик убеждается в правильности и понимании работы ИС клиентами |
5. Передача базы знаний проекта клиенту | Заказчику передаётся вся проектная документация |
6. Закрытие проекта | Составляется отчёт о закрытии проекта. Заказчик подписывает акт приёмки. |
Для нормального функционирования АРМ требуется операционная система Microsoft WindowsXP.
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization – Международная организация по стандартизации, IEC - International Electro technical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Под моделью ЖЦ можно понимать структуру, определяющую последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых создается и функционирует.
На сегодняшний день существует много моделей жизненного цикла программного обеспечения, но наиболее популярны и распространены две модели это:
- спиральная модель (смотри рисунок 4.1);
- итерационная модель.
Рисунок 4.1 – Спиральная модель ЖЦ ПО
Для создания информационной системы, т.е. «Автоматизированное рабочее место сотрудника склада оптовая база», была выбрана итерационная. Отличительным свойством итерационной модели можно назвать то, что она представляет собой формальный метод, она состоит из независимых фаз, выполняемых последовательно, и подвержена частому обзору (рисунок 4.2). Итерационный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.
Преимущества итерационной модели:
модель хорошо известна потребителям, не имеющим отношения к разработки ПО, и конечным пользователям.
- удобность и простота применения, т.к. все работы выполняются поэтапно (по фазам модели);
- стабильность требований;
- модель доступна для понимания;
- структурой модели может руководствоваться даже слабо подготовленный в техническом плане персонал (неопытный пользователь);
- модель упорядоченно справляется со сложностями и хорошо срабатывает для тех проектов, которые достаточно понятны;