46620 (Автоматизация бизнес-процессов продажи билетов ООО "Зритель"), страница 7

Рис. 2.5. Общая архитектура разрабатываемого проекта

Характеристика структурных единиц информации исходных сообщений, при такой архитектуре, приведена в табл. 2.2.

Таблица 2.2.

Характеристика структурных единиц информации исходных сообщений

1. Характеристика этапа внедрения разрабатываемого проекта

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

Зачем нужно тестировать промежуточные рабочие продукты? Ответ на этот вопрос заключается в двух положениях:

• во-первых, обнаружение ошибок как можно раньше позволяет избавиться от напрасной реализации неправильных решений, от использования неправильных (а потому переделываемых в дальнейшем) компонентов, от обременительных возвратов к уже пройденному;

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

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

• какие результаты тестируются, каким методом и как определяется, что тестирование выполнено;

• как для деятельности данного вида определяется период тестирования — время, отводимое для тестирования в плане итерации;

• какие кадровые и технические ресурсы требуются для каждого из периодов тестирования;

• какие инструменты используются при тестировании данного вида деятельности.

Наиболее просты для планирования тестирования рабочие продукты, связанные с анализом и конструированием: требуется проверка полноты, непротиворечивости и соответствия получаемых результатов исходным положениям (требованиям — для анализа и спецификациям — для конструирования). Период тестирования здесь можно определить довольно точно. Он зависит от размеров рабочего продукта и заранее составляемого перечня вопросов, требующих ответа при изучении материалов, которые рассматриваются как содержание тестировочной работы. Кадровые ресурсы для такого тестирования также вполне определены: как правило, изучение материалов рабочего продукта не может быть поручено нескольким исполнителям, т.е. данный вид тестирования не допускает распараллеливания. Нет проблем и с определением технических ресурсов, а также с тем, что считать окончанием тестирования (получение ответов на весь перечень вопросов). В качестве инструментальной поддержки такого рода тестирования используются обычные средства работы с текстами.

Более сложным для планирования является тестирование программных рабочих продуктов. Главные причины тому — неопределенная сложность программирования как этапа жизненного цикла. Она непосредственно зависит от решаемых на данном этапе задач, от использования инструментария поддержки (в частности, от языка и системы программирования), а также от квалификации исполнителей рабочего продукта. Кроме того, именно на этапе проверки программных рабочих продуктов проявляют себя ошибки более ранних этапов, что вносит существенный вклад в неопределенность планирования тестирования. Эти трудности практически непреодолимы при последовательной стратегии развития проекта. Для возвратно-поступательного итеративного наращивания они во многом сглаживаются за счет обозримости свода задач каждой из итераций.

Конкретные методики, позволяющие планировать процессы тестирования программных рабочих продуктов, связываются с разделением системы тестов на группы, отвечающие за проверку различных аспектов итерации:

• тесты для проверки функциональности;

• тесты для проверки корректности преобразований данных;

• интерфейсные тесты;

• специфичные для данного проекта (итерации) тесты.

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

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

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

• высокий — требует выделения для тестирования времени 95% и более из суммарного времени, отведенного для работ данной итерации;

• средний — для тестирования требуется от 20% до 50% из суммарного времени работ данной итерации;

• низкий — для тестирования отводится порядка 5% суммарного времени работ данной итерации.

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

План тестирования, регламентирующий деятельность тестировщиков и разработчиков на этапе оценки (т.е. когда на данной итерации достигается контрольная точка 6 жизненного цикла «Автономная проверка завершена, комплексное тестирование началось»), предусматривает соответствующий период в ходе оценочных работ, иногда выделяя его в качестве самостоятельного этапа.

Фиксируемые в ходе тестирования ошибки указывают на необходимость их исправления, которое может быть проведено либо в рамках текущей итерации, либо на последующих итерациях. Какой из этих вариантов для конкретной ошибки должен быть принят, определяется в рамках специальной деятельности, называемой диагностикой ошибки. Цели диагностики:

указать причину ошибки;

определить, что надо исправить и оценить ресурсы, которые необходимо выделить на исправление;

установить когда исправление будет сделано.

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

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

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

2. Характеристика этапа эксплуатации разрабатываемого проекта и возможных работ

Основной характеристикой этапа эксплуатации проекта является выпуск релизов по анализу этапа.

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