Опубликован: 24.11.2006 | Доступ: свободный | Студентов: 716 / 33 | Оценка: 4.46 / 4.54 | Длительность: 17:18:00
Лекция 6:

Процесс разработки программы и методология построения приложений для интернета

Тестирование решения

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

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

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

Таблица 6.5. Обзор промежуточных результатов этапа тестирования
Порядок выполнения Промежуточный результат Ответственная сторона
1 Выполнение сценария тестирования Контроль качества.
2 Описание ошибки Тестировщик.
3 Устранение ошибки Разработчики.

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

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

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

Реализация решения

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

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

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

После завершения проекта

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

Анализ должен ответить на следующие вопросы.

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