При создании пакета инструментов для ALM Visual Studio 2010 и Team Foundation Server 2010 в Microsoft опирались на классическое представление об управлении жизненным циклом приложений (Application Lifecycle Management, ALM). Целью управления процессами в ALM является гарантия того, что разрабатываемое приложение полностью удовлетворяет запросам бизнеса, поэтому необходимо уяснить основные задачи проекта до того, как к работе приступят разработчики. После того как цели проекта будут полностью выявлены и задокументированы, можно приступать к созданию кода. С этого момента разрабатываемый проект поступает в группу проектов компании, находящихся в процессе разработки, и управляется наравне с другими. В зависимости от сложности и типа процесса, используемого в компании, данная работа может осуществляться под руководством менеджера, одновременно руководящего несколькими проектами, выделенного управляющего или, как, например, в Scrum, вообще проходить без формально назначенного управляющего. Главное то, что, вне зависимости от бюджета проекта, его размеров и сложности, его управление не должно прерываться.
Важной частью процесса разработки является тестирование, которое обычно проходит параллельно с разработкой, а иногда, как в случае с методологией разработки, ведомой тестированием (test-driven development), и с опережением. Выявленные дефекты должны устраняться в соответствии с их приоритетом, а все исправления подтверждаются повторным тестированием. Причины возникновения дефектов должны быть проанализированы с целью сокращения риска их появления в дальнейшем. По мере увеличения объемов реализованной функциональности должно проводиться повторное (регрессионное) тестирование критических участков кода с целью убедиться, что вновь создаваемый код не нарушил работоспособности уже протестированного. В необходимых случаях, в дополнение к функциональному тестированию должно проводиться нагрузочное и тестирование производительности для выявления "узких" мест в коде на максимально раннем этапе.
По окончании разработки и тестирования, проект переходит в категорию используемых (в случае разработки для внутренних нужд) или поддерживаемых (если проект разрабатывался для третьих лиц) приложений. Процесс управления на этом не заканчивается — как любая инвестиция, программные комплексы являются активами компании, требующими грамотного распоряжения. С развертыванием первой версии процесс разработки, как правило, не заканчивается: выпускаются исправления критических ошибок, добавляется новый функционал. Иногда расходы на такие работы могут сравняться с бюджетом самого проекта или даже превысить его.
Рано или поздно любой проект переходит в следующую стадию – эксплуатацию, подразумевающую его развертывание, управление и мониторинг, которыми также необходимо управлять. Планирование развертывания должно начинаться еще до окончания разработки, а сам процесс развертывания является фундаментальной частью жизненного цикла. Управление и мониторинг приложений должны продолжаться до самого конца их жизненного цикла.
Все три этапа жизненного цикла (проектирование, реализация и эксплуатация) неразрывно связаны между собой и могут накладываться друг на друга во времени. Соответственно и инструменты, поддерживающие эти процессы, должны быть интегрированы между собой и обеспечивать непрерывный и своевременный обмен информацией вне зависимости от того, где географически находятся люди, его использующие и какие методологии разработки они применяют. Главной целью создания набора инструментов семейства Visual Studio 2010 было предоставление каждому участнику процесса понятного и простого инструмента взаимодействия с другими участниками, а также интеграция с такими инструментами, как Microsoft Office, SharePoint и Internet Information Server, применение которых позволяет воспользоваться уже готовой программной инфраструктурой.
Инструменты ALM
Инструменты семейства Visual Studio 2010 делятся на две группы: клиентскую и серверную.
Клиентская предназначается для всех участников процесса — инструменты, входящие в нее, могут быть как универсальными, так и специализированными. К первым относится интегрированная среда разработки Visual Studio, позволяющая создавать код приложения и работать с архитектурными диаграммами на языке UML 2.0, разрабатывать и управлять серверами баз данных, создавать и запускать автоматические тесты, создавать различные артефакты проекта, сохраняемые в Team Foundation Server (TFS) и др. К специализированным можно отнести Test Manager – инструмент инженеров по качеству, позволяющий контролировать процесс тестирования и запускать на выполнение как автоматические тесты, так и пошаговые тесты, выполняемые вручную. Все эти приложения функционируют в общей информационной среде.
Описание клиентской части было бы неполным без упоминания известных, но на первый взгляд не типичных для данной сферы приложений – Microsoft Project и Excel. Эти инструменты, используемые в далеких от ALM задачах, встраиваются в общую систему управления жизненным циклом приложений благодаря тому, что могут напрямую подключаться к TFS. В результате пользователям, которые в своей повседневной работе привыкли иметь дело с приложениями семейства Office, не придется осваивать новые инструменты.
В качестве основной системы отчетности применяется другое известное решение — SQL Reporting Services, благодаря чему набор готовой отчетности может быть настроен под нужды конкретной компании или проекта. Использование уже имеющихся в компании инструментов широкого назначения облегчает и удешевляет развертывание и эксплуатацию приложения.
Отдельную подгруппу клиентских средств образуют многочисленные дополнения, которые благодаря открытой архитектуре Visual Studio (ее интерфейсы и протоколы подробно описаны в библиотеке MSDN) создаются не только компанией Microsoft, но и другими производителями. Использование таких дополнений, как Visual Studio Productivity Tools, позволяют повысить продуктивность работы разработчика, эффективность анализа и создания тестовых заданий, а набор TFS Power Tools облегчит внесение изменений в структуру процесса и рабочие элементы.
К серверной части относится TFS, который, кроме привычных функций контроля версий, автоматической сборки проекта и других задач, обеспечивает взаимодействие между участниками процесса. TFS — это почтовый сервер (рис. 1), оперирующий специализированными информационными артефактами, так называемыми рабочими элементами (Work Item), которые в зависимости от используемой методологии могут передавать информацию о найденных ошибках, архитектурные требования, тестовые задания, задачи на выполнение и многое другое.
Чтобы процесс работы над проектом протекал без неожиданностей, он должен быть понятен всем участникам. TFS управляет этапами проекта в зависимости от выбранной методологии: MSF for Agile, MSF for CMMI и Scrum. Разумеется, ни одна даже самая совершенная методология, не сможет учесть всех особенностей конкретного проекта, но в рамках открытой платформы TFS пользователи могут подстраивать под себя как поставляемые методологии, так и созданные третьими лицами, включая модификацию рабочих элементов процессов, и даже создавать собственные методологии и их рабочие элементы.
Рисунок 1. Инструменты управления ALM в TFS |
Планирование архитектуры
Работа над новым проектом обычно начинается с обсуждения его архитектуры. Из каких модулей должно состоять данное приложение? Какие задачи они должны выполнять? Как эти модули будут взаимодействовать между собой? Однако и с началом работы над кодом вопросов не становится меньше — они просто меняются, например: насколько данный код соответствует той архитектуре, что мы задумывали? Документирование архитектуры посредством UML-диаграмм с последующей верификацией соответствия написанного кода позволяет не только сэкономить ресурсы, но и повысить качество работы. Visual Studio 2010 содержит в себе инструменты как для создания UML-диаграмм с нуля или на основе существующего кода, так и для генерации кода на основе диаграмм. Любые элементы диаграмм могут быть превращены в рабочие элементы TFS и обрести конкретного исполнителя. Обычно элементы диаграмм становятся требованиями, которые в свою очередь связываются логическими ссылками на рабочие элементы типов "Тестовый сценарий" и "Задача для разработки".
С помощью привязки диаграмм слоев (Layer Diagram) к частям приложения (пространствам имен, классам и т. п.) архитектор или разработчик может убедиться в соблюдении правил реализации, которые содержит эта диаграмма. Причем такая проверка может осуществляться автоматически при каждой сборке средствами сервиса Team Build, входящего в TFS, в течение всей разработки приложения. В случае выявления расхождений между кодом и запланированной архитектурой все ответственные за проект будут оповещены: чем раньше подобные проблемы будут обнаружены, тем меньше усилий придется затратить на их устранение.
Для лучшей визуализации созданного кода предусмотрена поддержка диаграмм последовательности (Sequence Diagram), позволяющих разобраться в последовательности вызовов методов с заданной глубиной анализа. Эти диаграммы строятся на основе созданного кода при помощи указания интересующего метода прямо в редакторе. Кроме этого поддерживаются также диаграммы классов (Class Diagrams), диаграммы прецедентов (Use Case Diagram), диаграммы активностей (Activity Diagram) и диаграммы компонентов (Component Diagram).
Управление проектом
На какой бы стадии выполнения ни находился проект, он нуждается в непрерывном контроле, и задача TFS (рис. 2) состоит не только в поддержке безопасного хранилища файлов проекта и в обмене техническими заданиями, информацией о найденных ошибках, но также в анализе всей поступающей информации. Благодаря тому что все данные проекта проходят через TFS, появляется возможность получения моментального "среза" систематизированной информации, что облегчает планирование и управление рисками.
Рассмотрим типичный пример. Один из разработчиков заболел, и в обычной ситуации проект рискует выйти за рамки установленных сроков, поскольку никому, кроме выбывшего программиста, не известно, какие задачи перед ним ставились на ближайшее время и перспективу. Однако если в TFS были своевременно размещены технические задания, включая их приблизительную продолжительность, то можно оценить риски, связанные с временной нетрудоспособностью работника. Поскольку остальные разработчики имеют свой список задач, доступный в TFS, менеджер проекта сможет, в случае чрезвычайной ситуации, либо перераспределить нагрузку между оставшимися работниками, либо сообщить руководству о возникших рисках.
Для быстрого и удобного анализа больших объемов информации требуются соответствующие инструменты, и основной идеей Visual Studio 2010 стало предоставление широкого спектра таких средств, позволяющих работать с данными в TFS.
Кроме штатного инструмента Team Explorer, доступного как часть среды разработки, так и в виде самостоятельного приложения, менеджеров проектов заинтересует возможность работы с TFS из Microsoft Project и Excel. Оба этих инструмента позволяют не только создавать собственные отчеты о текущем состоянии проекта, но и вносить в него изменения при помощи перераспределения нагрузки между исполнителями, формирования новых технических требований и заданий.
Рис. 2. Планирование и отслеживание проектов в TFS |
Штатная отчетность TFS построена на базе SQL Reporting Services (рис. 3), и в зависимости от методологии проекта пользователю предоставляется набор готовых отчетов по всем аспектам проекта, например:
- - ход тестирования (количество пройденных тестов и статистика найденных ошибок);
- - статус автоматической сборки (данные о последних сборках проекта процессом Team Build вне зависимости от их результата);
- - исправление ошибок (статистика процесса исправления ошибок);
- - покрытие кода тестами (процент протестированного кода всеми типами тестов).
Рис. 3. Пример отчета в SQL Reporting Services |
Разработка и тестирование
Это, без сомнения, самый затратный и рискованный этап жизненного цикла приложения, и расходы здесь складываются в основном из оплаты труда и стоимости оборудования. Выбор инструментария для разработки и тестирования может повлиять на продолжительность данного этапа, его стоимость, а также на состав дополнительных расходов на оборудование, в первую очередь для тестирования в различных средах и конфигурациях.
Помимо среды разработки, Visual Studio 2010 поддерживает новые типы автоматизированного тестирования, и в первую очередь кодированное тестирование пользовательского интерфейса (Coded UI Test), благодаря которому рутинные действия по ручному тестированию этого интерфейса производятся лишь один раз. Все действия оператора записываются и впоследствии конвертируются в виде проекта в исходном коде, доступном для дальнейшего редактирования. Данная система способна автоматически найти поле ввода в тестируемом приложении, причем даже если в процессе разработки оно было перемещено. Готовые модули интегрируются в TFS и становятся доступны для запуска, в том числе и автоматически.
В процессе разработки проекта приходится проводить повторное тестирование одних и тех же частей, чтобы убедиться, что вносимые изменения не нанесли ущерба уже имеющейся функциональности (регрессионное тестирование). Использование автоматизированного тестирования существенно облегчает этот процесс, однако остается вопрос оптимизации процесса тестирования: запуск большого количества тестов без оценки их реальной необходимости способен значительно удлинить процесс. С другой стороны, пропуск нужного теста создает риск проникновения ошибок в готовый продукт. Для оптимизации процесса регрессионного тестирования в Visual Studio 2010 применен модуль Test Impact, который благодаря интеграции с TFS позволяет анализировать код на предмет внесенных изменений и наличия тестовых модулей, проверяющих работоспособность данного функционала. Когда Test Impact определяет, что данный участок кода уже был протестирован, но затем в него были внесены изменения, тестовые задания, отвечающие за его проверку, будут внесены в специальный список.
Поиск трудно воспроизводимых ошибок нередко превращается в головную боль как для тестировщика, так и для разработчика, заставляя вновь и вновь возвращаться к проверке одной и той же функциональности. Причина проблемы состоит в отсутствии тождественности тестовой среды и конфигурации компьютера разработчика, а также в человеческом факторе: то, что одному кажется детальным описанием проблемы, для другого может не нести необходимой информации. Поэтому возникает вопрос о сборе объективной информации, четко описывающей как саму проблему, так и параметры среды, в которой она была найдена.
В ходе выполнения тестирования вручную в Visual Studio 2010 осуществляется сбор информации о версии операционной системы, сервисных обновлениях, объеме операционной памяти и др., причем имеется также возможность включения видео захвата экрана, на котором производится тестирование. В случае обнаружения ошибки вся эта информация будет сохранена в TFS и передана разработчику вместе с описанием ошибки. В особо сложных ситуациях можно воспользоваться технологией IntelliTrace, представляющей собой набор системной информации низкого уровня: состояние переменных, стека, строка кода, на которой произошел сбой, параметры возникшего исключения и др. При сравнении этих данных с информацией, полученной во время проведения успешных циклов тестирования, разработчик получит четкую картину изменений, которые и привели к сбою.
Использование виртуальных сред при тестировании способно одновременно решить несколько важных задач. Во-первых, размещение нескольких виртуальных сред на одном компьютере снижает стоимость. Во-вторых, можно производить тестирование на большем количестве операционных систем, различных настроек и физических параметров. И в-третьих, облегчается подготовка к тестированию: "снимок" готовой виртуальной среды сохраняется в TFS, который самостоятельно развернет последние сборки приложения, запустит требуемые автоматические тесты и вернет среду к первоначальному состоянию после их окончания. В случае обнаружения ошибки разработчику будет обеспечен доступ к среде, в которой они были найдены.
Использование виртуальных сред позволяет обеспечить нагрузочное тестирование, при котором тысячи виртуальных пользователей одновременно отправляют запросы к разрабатываемому сервису. Для оснащения виртуальных систем программным обеспечением предлагается несколько видов подписки, благодаря которым разработчики и тестировщики получают доступ к лицензиям и установочным пакетам различных версий операционных систем, серверов баз данных и офисным приложениям. Подписка содержит дистрибутивы среды разработки Visual Studio 2010 и Team Foundation Server 2010, включая клиентскую лицензию доступа к серверу.
***
Всем известна статистика о том, что большинство проектов по разработке программного обеспечения либо значительно затягивают сроки исполнения и превышают первоначальный бюджет, либо вообще никогда не выходят в эксплуатацию. Около 66% неудач вызвано недопониманием между заказчиком и исполнителем, от 60 до 80% неудач вызывает плохой сбор, анализ и управление требованиями, а в 40% случаев заказчик отказывается от проекта из-за большого количества ошибок, найденных в процессе эксплуатации.
Использование инструментов ALM позволяет собирать и систематизировать данные, необходимые для успешного ведения проекта, что дает возможность заранее идентифицировать риски, прогнозировать сроки и ресурсы.
Виталий Зайко (i-vizaik@microsoft.com) – эксперт по продуктам Microsoft для разработчиков (Москва); Дмитрий Андреев (dmitryan@microsoft.com) – эксперт Microsoft по разработке информационных систем (Астрахань).