· Требования к конечной системе заранее четко определены и понятны.
· Проект большой или очень большой.
· Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
7. «Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
· планирование;
· анализ рисков;
· конструирование;
· оценка результата и при удовлетворительном качестве переход к новому витку.
Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование.
Подготовка предварительного плана работ
Цель предварительного плана работ – дать возможность для оценки трудозатрат, состава проектной команды, необходимого программного и аппаратного обеспечения для среды разработки и тестирования, сроков привлечения специалистов и ресурсов.
План основывается на концепции проекта, техническом решении и выбранной методологии. Если подготовлено несколько технических решений, то план нужно подготовить для каждого решения отдельно.
План должен готовить специалист или группа специалистов, хорошо понимающих деятельность команды на каждом этапе процесса разработки в рамках принятой для проекта методологии.
Разумно не только определить список задач, но и указать их примерную длительность, зависимости и исполнителей, а также требуемую инфраструктуру.
Длительность задачи должна учитывать время, реально затрачиваемое на её решение, а не «идеальные» часы. Хорошие результаты даёт использование фокус-фактора при получении реальных оценок.
Ещё один значимый положительный эффект плана – возможность разбить весь объём работ на несколько небольших этапов поставки и тем самым сделать проект более гибким и предсказуемым. Выпуская на каждом этапе поставки готовый продукт с определённым набором функций, можно своевременно получить отзыв заказчика, что очень важно при работе в сложных предметных областях.
Реализация
При реализации проекта важно координировать группу (группы) разработчиков. Все разработчики должны подчиняться жестким правилам контроля исходных тестов. Группа разработчиков, получив технический проект, начинает писать код модулей. Основная их задача состоит в том, чтобы уяснить спецификацию: проектировщик написал, что надо сделать, разработчик определяет, как это сделать.
На этапе разработки осуществляется тесное взаимодействие проектировщиков, разработчиков и групп тестировщиков. В случае интенсивной разработки тестировщик буквально неразлучен с разработчиком, фактически становясь членом группы разработки.
Проектировщик на этапе разработки выполняет функцию «ходячего справочника», поскольку должен постоянно отвечать на вопросы разработчиков, касающиеся технической спецификации.
Чаще всего на этапе разработки меняются интерфейсы пользователя. Это обусловлено, наряду с прочим, периодической демонстрацией модулей заказчику. Также могут существенно изменяться запросы к данным.
Следует отметить необходимость существования выделенного рабочего места, где происходит сборка всего проекта. Именно эти модули передаются на тестирование. Взаимодействие тестировщика и разработчика без централизованной передачи допустимо только в том случае, если срочно требуется проверить какую-то правку. Очень часто этап разработки сопряжен с этапом тестирования, и оба процесса идут параллельно. Синхронизирует действия тестеров и разработчиков система bug tracking.
Кроме того, должны быть организованы хранилища готовых модулей проекта и библиотек, которые используются при сборке модулей. Это хранилище постоянно обновляется. Контролировать процесс обновления должен один человек. Одно хранилище создается для модулей, прошедших функциональное тестирование, второе — для модулей, прошедших тестирование связей. Первое — это черновики, второе — то, из чего уже можно собирать дистрибутив системы и демонстрировать его заказчику для проведения контрольных испытаний или для сдачи каких-либо этапов работ.
Следует отметить исключительную важность обмена информацией между проектировщиками, разработчиками, тестировщиками: ошибки должны быть классифицированы согласно приоритетам; для каждого класса ошибок должна быть определена четкая структура действий: «что делать», «как срочно», «кто ответственен за результат»; каждая проблема должна отслеживаться проектировщиком/разработчиком/тестировщиком, отвечающим за ее устранение. То же самое касается ситуаций, когда нарушаются запланированные сроки разработки, передачи модулей на тестирование. Все проблемы при взаимодействии между группами могут стоить достаточно дорого.
Тестирование
Группы тестирования могут привлекаться к сотрудничеству уже на ранних стадиях разработки проекта. Строго говоря, комплексное тестирование следует выделить в отдельный этап разработки. В зависимости от сложности проекта тестирование и исправление ошибок может занимать треть, половину общего времени работы над проектом и даже больше.
Чем сложнее проект, тем больше будет потребность в автоматизации системы хранения ошибок — bug tracking, которая обеспечивает следующие функции:
• хранение сообщения об ошибке (к какому компоненту системы относится ошибка, кто ее нашел, как ее воспроизвести, кто отвечает за ее исправление, когда она должна быть исправлена);
• система уведомления о появлении новых ошибок, об изменении статуса известных в системе ошибок (уведомления по электронной почте);
• отчеты об актуальных ошибках по компонентам системы;
• информация об ошибке и ее история;
• правила доступа к ошибкам тех или иных категорий;
• интерфейс ограниченного доступа к системе bug tracking для конечного пользователя.
Подобные системы берут на себя множество организационных проблем, в частности вопросы автоматического уведомления об ошибках.
Собственно тесты систем можно разделить на несколько категорий:
• автономные тесты модулей; они используются уже на этапе разработки компонентов системы и позволяют отслеживать ошибки отдельных компонентов;
• тесты связей компонентов системы; эти тесты также используются и на этапе разработки, и на этапе тестирования, они позволяют отслеживать правильность взаимодействия и обмена информацией компонентов системы;
• системный тест; он является основным критерием приемки системы; как правило, это группа тестов, включающая и автономные тесты, и тесты связей и модели; данный тест должен воспроизводить работу всех компонентов и функций системы; основная цель данного теста — внутренняя приемка системы и оценка ее качества;
• приемосдаточный тест; основное его назначение — сдать систему заказчику; здесь разработчики часто занижают требования к системе по сравнению с системным тестом, и причины этого вполне очевидны;
• тесты производительности и нагрузки; данная группа тестов входит в системный тест, но достойна отдельного упоминания, поскольку именно эта группа тестов является основной для оценки надежности системы.
В тесты каждой группы обязательно входят тесты моделирования отказов. Здесь проверяется реакция компонента, группы компонентов, системы в целом на отказы вида:
• отказ отдельного компонента информационной системы;
• отказ группы компонентов информационной системы;
• отказ основных модулей информационной системы;
• отказ операционной системы;
• жесткий сбой (отказ питания, жестких дисков).
Эти тесты позволяют оценить качество подсистемы восстановления корректного состояния информационной системы и служат основным источником информации для разработки стратегий предотвращения негативных последствий сбоев при промышленной эксплуатации. Как правило, этим классом тестов разработчики традиционно пренебрегают, а затем вынуждены «лечить» последствия сбоев на промышленной системе.
Еще одним важным аспектом программы тестирования информационных систем является наличие генераторов тестовых данных. Они используются для проведения тестов функциональности системы, тестов надежности системы и тестов производительности системы. Задачу оценки характеристик зависимости производительности информационной системы от роста объемов обрабатываемой информации без генераторов данных решить невозможно.
Внедрение
Опытная эксплуатация перекрывает процесс тестирования. Система редко вводится полностью. Как правило, это процесс постепенный или итерационный — в случае циклического жизненного цикла.
Ввод в эксплуатацию проходит как минимум три стадии:
• первоначальная загрузка информации;
• накопление информации;
• выход на проектную мощность (то есть собственно переход к этапу эксплуатации).
Первоначальная загрузка информации инициирует довольно узкий спектр ошибок: в основном речь идет о проблемах рассогласования данных при загрузке и о собственных ошибках загрузчиков. Здесь требуется применить методы контроля качества данных (в противном случае в дальнейшем наведенные ошибки обойдутся намного дороже). Это то, чего не было или не могло быть отслежено на тестовых данных. Такие ошибки должны быть исправлены как можно быстрее. Не поленитесь поставить отладочную версию системы (если, конечно, вам позволят развернуть весь комплекс сопровождающего отладку информационной системы ПО на месте). Если отладку «на живых» данных произвести невозможно, вам придется моделировать ситуацию, и как можно быстрее. В этом случае требуются очень квалифицированные тестировщики.
В период накопления информации из информационной системы выявляется наибольшее количество ошибок, связанных с многопользовательским доступом. Часто на этапе тестирования им не уделяется должного внимания — из-за сложности моделирования и дороговизны средств автоматизации процесса. Вторая категория исправлений связана с тем, что пользователя не устраивает интерфейс. Здесь не всегда нужно выполнять абсолютно все пожелания пользователя, иначе процесс ввода в эксплуатацию будет бесконечным. В данный момент циклические модели и модели с обратной связью этапов также позволяют снизить затраты.
Этот этап является также наиболее серьезным тестом — тестом одобрения пользователем (customer acceptance tests). Если этого не было сделано на этапе тестирования, то на этапе внедрения это непременно произойдет, и вашим тестировщиком фактически будет ваш собственный заказчик, что не всегда приемлемо, особенно если для последнего это будет несколько неожиданно.
Выход системы на проектную мощность в хорошем варианте — это доводка мелких ошибок и редкие серьезные ошибки.
