Управление жизненным циклом приложений (application lifecycle management - ALM)

1.3 Управление жизненным циклом приложений Управление жизненным циклом приложений (application lifecycle management - ALM) - это концепция управления программным проектом на всех этапах его жизни. Для реализации этой концепции компания Microsoft предлагает решение на основе Visual Studio и Team Foundation Server (TFS). Технологии ALM в Visual Studio позволяют разработчикам контролировать жизненный цикл создания ПО, сокращая время разработки, устраняя издержки и внедряя непрерывный цикл реализации бизнес-ценностей. Управление жизненным циклом приложения в Visual Studio базируется на следующих принципах: • продуктивность (productivity); • интеграция (integration); • расширяемость (extensibility). Продуктивность обеспечивается возможностью совместной работы и управлением сложностью продукта. Все элементы проекта (требования, задачи, тестовые случаи, ошибки, исходный код и построения) и отчеты централизованно управляются через TFS. Инструменты визуального моделирования архитектуры, возможности управления качеством код, инструменты тестирования позволяют управлять сложностью продукта. Интеграция обеспечивается возможностями Visual Studio по предоставлению всем участникам проекта информации о состоянии дел, что упрощает коммуникацию между членами команды и обеспечивает прозрачность хода процесса проектирования. Расширяемость обеспечивается API-интерфейсом служб TFS и интегрированной средой разработки (integrated development environment - IDE). API-интерфейс служб TFS позволяет создавать собственные инструменты и расширять существующие, а IDE - конечным пользователям и сторонним разработчикам добавлять инструменты с дополнительными функциями. При создании программного продукта необходимо в начале спроектировать архитектуру, что возлагается на архитектора программного продукта. На основе архитектуры осуществляется разработка, что является предназначением разработчика программного продукта. Созданный продукт необходимо тестировать на его соответствие требованиям заказчика, что осуществляет тестировщик. Visual Studio и TFS обеспечивают совместную командную работу архитектора, разработчика и тестировщика, предоставляя им необходимый инструментарий и функциональные возможности для выполнения требуемых работ. Архитектурное проектирование В Visual Studio для архитектурного проектирования используются инструменты визуального проектирования на основе языка UML, которые предназначены для следующего: • визуализации архитектурных аспектов проектируемой системы; • создания моделей структуры и поведения системы; • разработки шаблонов для проектирования системы; • документирования принятых решений. Диаграммы UML позволяют визуально описывать приложение, наглядно представлять архитектуру и документировать требования к приложению. Архитектурные инструменты в Visual Studio Ultimate позволяют создавать шесть видов схем и документ ориентированных графов (табл. 1.5): • схема классов UML; • схема последовательностей UML; • схема вариантов использования UML; • схема активности UML; • схема компонентов UML; • схема слоев. Таблица 1.5 – Архитектурные инструменты в Visual Studio Ultimate Схемы (диаграммы) классов UML описывают объекты в прикладной системе. Диаграммы классов отражают иерархию внутри приложения или системы и связи между ними. Схемы (диаграммы) последовательностей UML показывают взаимодействие между различными объектами. Они используются для демонстрации взаимодействия между классами, компонентами, подсистемами или субъектами. Схемы (диаграммы) вариантов использования UML определяют функциональность системы и описывают с точки зрения пользователей их возможные действия с программным продуктом. Данные диаграммы определяют связи между функциональными требованиями, пользователями и основными компонентами системы. Схемы (диаграммы) активности UML описывают бизнес-процесс или программный процесс в виде потока работ через последовательные действия. Диаграммы активности используются для моделирования логики в конкретном варианте использования или для моделирования подробностей бизнес-логики. Схемы (диаграммы) компонентов UML описывают распределение программных составляющих приложения, позволяя наглядно отобразить на высоком уровне структуру компонентов и служб. С помощью этих схем можно визуализировать компоненты и другие системы, показывая связи между ними. В качестве компонентов могут выступать исполнительные модули, DLL-библиотеки и другие системы. Схемы (диаграммы) слоев используются для описания логической архитектуры системы. Диаграммы слоев могут использоваться для проверки того, что разработанный код отвечает высокоуровневому проекту на схеме слоев. Диаграммы позволяют проверять архитектуру приложения на соответствие базе кода. Документ ориентированных графов позволяет создать граф зависимостей, отображающий отношения между компонентами архитектурных артефактов. Графы зависимостей, обеспечивают визуальные способы проверки кода , анализа зависимостей между файлами. Разработка приложения Основным средством разработки в Visual Studio является интегрированная среда разработки (IDE). IDE-среда интегрирована со средствами модульного тестирования и обеспечивает возможности выявления неэффективного, небезопасного или плохо написанного кода, управление изменениями и модульное тестирование как кода, так и базы данных. Важным инструментом разработчика программного обеспечения является модульное тестирование, которое реализуется в среде Unit Test Framework. Назначением модульных тестов является проверка того, что код работает правильно с точки зрения программиста. Модульные тесты формируются на более низком уровне, чем другие виды тестирования, и проверяют работают ли лежащие в их основе функции так, как ожидается. Для модульного тестирования используется метод прозрачного ящика, для которого требуется знание внутренних структур кода. Модульные тесты помогают обнаружить проблемы проектирования и реализации. Кроме того, модульный тест является хорошей документацией по использованию проектируемой системы. Хотя модульное тестирование требует дополнительного программирования, но его применение окупается за счет сокращения затрат на отладку приложения. Модульные тесты являются важным элементом регрессионного тестирования. Регрессионное тестирование представляет собой повторное тестирование части программы после внесения в неё изменений или дополнений. Цель регрессионного тестирования - выявление ошибок, которые могут появиться при внесении изменений в программу В Visual Studio имеется функция "Анализ покрытия кода", которая проводит мониторинг того, какие строки кода исполнялись в ходе модульного тестирования. Результатом анализа покрытия кода является выявление областей кода, которые не покрыты тестами. Важным аспектом создания качественного программного продукта является соблюдение разработчиками правил и стандартов организации в написания кода. В Visual Studio имеются функции анализа кода, которые позволяют проанализировать код, найти типичные ошибки, нарушения стандартов и предложить меры по устранению ошибок и нарушений. Наборы правил анализа кода поставляются с Visual Studio . Разработчики могут настроить свои проекты на определенный набор правил, а также добавить свои специфичные правила анализа кода. В процессе анализа кода используются метрики кода, которые дают количественные оценки различных характеристик кода. Метрики позволяют определить сложность кода и его изолированные области, которые могут привести к проблемам при сопровождении приложения. В Visual Studio используются следующие метрики кода (табл. 1.6): Таблица 1.6. – Метрики кода Visual Studio сложность организации циклов - определяет число разных путей кода; глубина наследования - определяет число уровней в иерархии наследования объектов; объединение классов - определяет число классов, на которые есть ссылки; строки кода - определяет количество строк кода в исполняемом методе; индекс удобства поддержки - оценивает простоту обслуживания кода. Для анализа производительности и эффективности использования ресурсов приложением в Visual Studio имеются инструменты профилирования. Профилирование представляет собой процесс наблюдения и записи показателей о поведении приложения. Инструментарий профилирования (профилировщики) позволяют обнаружить у приложения проблемы с производительностью. Такие проблемы, как правило, связаны с кодом, который выполняется медленно, неэффективно или чрезмерно использует системную память. Профилирование обычно используется для выявления участков кода, которые в ходе выполнения приложения выполняются часто или долгое время. Профилировщики бывают с выборкой и инструментированием. Профилировщики с выборкой делают периодические снимки выполняющегося приложения и записывают его состояние. Профилировщики с инструментированием добавляют маркеры отслеживания в начало и конец каждой исследуемой функции. В процессе работы профилировщика маркеры активизируются, когда поток исполнения программы входит в исследуемые функции и выходит из них. Профилировщик записывает данные о приложении и о том, какие маркеры были затронуты в ходе исполнения приложения. В Visual Studio поддерживается профилирование с выборкой и с инструментированием. Для анализа производительности необходимо: • создать сеанс новый сеанс производительности; • с помощью Обозревателя производительности задать свойства сеансы; • запустить сеанс, выполняя приложение и профилировщик; • проанализировать данные в отчетах по производительности. Большинства корпоративных приложений работает с базами данных, что определяет необходимость разработки и тестировании приложений совместно с базами данных командой проекта. В Visual Studio имеется инструментарий создания баз данных и развертывания изменений в них. Для этого используется автономная разработка схем баз данных, которая позволяет вносить изменения в схемы без подключения к производственной базе данных. После внесения изменений в среду разработки Visual Studio позволяет протестировать их в самой среде разработки и/или выделенной среде тестирования. Кроме того, Visual Studio позволяет сгенерировать псевдореальные данные для проведения тестов. При положительных результатах тестирования Visual Studio позволяет сгенерировать сценарии для обновления производственной базы данных. Цикл разработки базы данных приложения состоит из следующих шагов: • перевод схемы базы данных в автономный режим; • итеративная разработка приложения с базой данных; • тестирование схемы базы данных; • построение и развертывание базы данных и приложения. Для совершенствования процесса отладки приложений в Visual Studio имеется функция интеллектуального отслеживания работы программы Intelli Trace. Функция Intelli Trace конфигурируется с помощью следующих разделов: • Общие (General); • Дополнительно (Advanced); • События Intelli Trace (Intelli Trace Events); • Модули (Modules). Раздел Общие позволяет включить и отключить функцию Intelli Trace и задать запись только событий либо дополнительной информации, включающей события, данные диагностики, вызовы и отслеживание на уровне методов. В разделе Дополнительно задается расположение для генерируемого файла журнала и его максимальный размер. В разделе События Intelli Trace перечисляются все события диагностики, которые будут собираться в ходе отладки приложения. Раздел Модули определяет список модулей, для которых необходимо собирать данные в процессе отладки приложения. При записи событий, происходящих в приложении, происходит их перехват при работе приложения и информация о событиях фиксируется в журнале. При отладке с Intelli Trace можно приостановить интерактивный сеанс отладки и просмотреть события или вызовы. Также имеется возможность остановки выполнения приложения и пошаговое движение назад и вперед в интерактивном сеансе отладки, а также воспроизведение записанного сеанса отладки. Тестирование приложения Тестирование приложения является необходимым этапом управления жизненным циклом приложения. Тестирование выполняет разработчик в процессе создания кода приложения, а также тестировщик при проверке качества разрабатываемого программного продукта. Visual Studio Ultimate предоставляет разработчику инструмент для создания и использования модульных тестов, нагрузочных тестов и Web тестов производительности, а также тестов пользовательского интерфейса. Модульные тесты представляют собой низкоуровневые программные тесты, написанные на языках Visual C#, Visual Basic или Visual C++. Они позволяют быстро проверить наличие логических ошибок в методах классов. Основной их целью является проверка того, что код приложения работает так, как ожидает разработчик. Нагрузочные тесты используются для исследования работоспособности приложения путем моделирования множества пользователей, которые работают с программой одновременно. Система позволяет использовать большое количество виртуальных пользователей на локальных и удаленных компьютерах при выполнении нагрузочного теста. В Visual Studio Ultimate имеется три встроенных шаблона нагрузки: постоянный, пошаговый и с учетом эталона. Выбор шаблона нагрузки определяется целям нагрузочного теста. Тесты пользовательского интерфейса позволяют автоматически сформировать код теста, путем записи действий пользователя при работе с приложением, и впоследствии выполнять эти тесты автоматически. Архитектура средств тестирования в Visual Studio приведена на рис. 1.4. Центральное место занимает платформа модульного-тестирования. Доступ к средствам тестирования может осуществляться из обозревателя тестов, командной строки и при построении приложения через Team Build. Платформа тестирования обеспечивает подключение плагинов тестирования. В составе Visual Studio установлены плагины MS-Test Managed и MS-Test Native. Плагины сторонних разработчиков (NUnit, xUnit.net, MbUnit и другие) можно подключить к платформе юнит-тестирования. Рисунок 1.4 - Архитектура инструментов тестирования Средства модульного тестирования ориентированы на использование разработчиками в процессе написания кода. Для тестировщиков в Visual Studio Ultimate имеется специализированный инструмент - MicrosoftTestManager, который позволяет создавать планы тестирования, формировать, добавлять и удалять тестовые случаи, определять и управлять физическими и виртуальными тестовыми средами, выполнять ручные и автоматические тесты. Создание эффективной среды тестирования сложных приложений выполняется с помощью лаборатории тестирования - LabManagement, которая интегрирована с Team Foundation Server , и представляет собой диспетчер виртуальной среды. Лаборатория тестирования предоставляет следующие возможности: • создание, управление и освобождение сред, состоящих из одной или более виртуальных машин; • автоматическое развертывание построений в виртуальных средах; • выполнение ручных и автоматических тестов в виртуальных средах; • использование снимков, позволяющих быстро вернуть среды к заданному состоянию; • сетевая изоляция виртуальных сред. Администрирование виртуальной среды Lab Management производит диспетчер Microsoft System Center Virtual Machine Manager (SCVMM), с помощью которого производят необходимые настройки виртуальной тестовой лаборатории. В Visual Studio и Team Foundation Server добавлено средство взаимодействия с пользователями разработанных программных продуктов, которое по запросу позволяет сформировать отзыв пользователя в базе данных для последующей обработки командой проекта. 1.4 Архитектура и функциональные возможности Visual Studio Team Foundation Server Microsoft Visual Studio Team Foundation Server (TFS) предназначен для обеспечения совместной работы команд разработчиков программного обеспечения. Team Foundation Server предоставляет следующие функциональные возможности: • управление проектами; • отслеживание рабочих элементов; • контроль версий; • управление тестовыми случаями; • автоматизация построения; • отчетность. Архитектура Team Foundation Server является трехуровневой сервис-ориентированной (рис. 1.5). Уровень приложения поддерживается Web-сервером ASP.NET, размещенном в многосерверной среде IIS. Уровень данных поддерживается сервером баз данных MS SQL Server . Рисунок 1.5 - Архитектура Team Foundation Server Team Foundation Server представляет с логической точки зрения Web-приложение, состоящее из нескольких Web-служб, выполняющихся на уровне приложения. Данные службы реализуют функциональность TFS. В состав Web-служб уровня приложения входят: управление версиями, служба построения, отслеживания рабочих элементов, службы платформы TFS и лаборатории тестирования Lab Management. Серверная объектная модель является интерфейсом прикладного программирования для TFS. При необходимости расширение функциональности TFS целесообразно строить на базе серверной объектной модели. Уровень данных состоит из нескольких реляционных баз данных и хранилища данных: базы данных конфигурации сервера, базы данных аналитики, базы данных коллекции командных проектов и хранилища данных. Информация командных проектов сохраняется в реляционных базах данных, и через запланированные интервалы времени помещается в хранилище данных. Клиентский уровень может реализовываться в оболочке Visual Studio и Web-браузере. Клиентский уровень взаимодействует с уровнем приложений через серверную объектную модель и использует Web-службы. Кроме того, клиентский уровень включает интеграцию с Microsoft Office. Развертывание Team Foundation Server Для Team Foundation Server можно выполнить развертывание несколькими способами: на одном сервере; на нескольких серверах; в одном домене, рабочей группе или в нескольких доменах. В простейшей серверной топологии для размещения компонентов, составляющих логические уровни Team Foundation, используется один физический сервер (рис. 1.6). При установке TFS с одним сервером все компоненты (приложение Team Foundation Server, SQL Server, Reporting Services и Widows Share Point Services) устанавливаются на одном компьютере. Такая конфигурация предполагает выполнение построения (TeamFoundationBuild) и тестирование либо на сервере, либо на клиентских компьютерах. Общее число пользователей для такой конфигурации, как правило, не более 50. Рисунок 1.6 - Простейшая серверная топология TFS В простой серверной топологии для размещения компонентов, составляющих логические уровни Team Foundation, также используется один физический сервер (рис. 1.7). Однако в такой технологии учитывается также дополнительная нагрузка на процессорные мощности, создаваемая программным обеспечением для построения и тестирования. Рисунок 1.7 - Простая серверная топология TFS На данной схеме Web-службы и базы данных для Team Foundation размещаются на одном физическом сервере, но службы построения устанавливаются на отдельный компьютер. К Team Foundation Server можно получить доступ с клиентских компьютеров, принадлежащих к той же рабочей группе или тому же домену. В данной конфигурации контроллер построения для выполнения Team Foundation Build и контроллер тестирования устанавливаются на отдельных компьютерах. Общее число пользователей для такой конфигурации, как правило, не более 100. В серверной топологии средней сложности используются два или больше серверов для размещения логических компонентов на уровне данных и приложений Team Foundation (рис. 1.8). На данной схеме службы уровня приложений для Team Foundation Server развертываются на одном сервере, а базы данных для TFS устанавливаются на отдельном сервере. На отдельных серверах размещаются Web-приложение Share Point и экземпляр служб отчетов SQL Server. Портал для каждого командного проекта размещается в Web-приложении Share Point. Сервер Team Foundation Build и тестовые контроллеры команды развертываются на дополнительных серверах. Общее число пользователей для такой конфигурации, как правило, не более 1000. Рисунок 1.9 - Серверная топология TFS средней сложности Для управления командной разработкой Team Foundation Server содержит одну или несколько коллекций командных проектов, каждая из которых может содержать ноль или более проектов. Шаблоны командных проектов Командный проект представляет коллекцию рабочих элементов, кода, тестов и построений, которые охватывают все артефакты, используемые в жизненном цикле программного проекта. Командный проект строится на основе шаблона, который представляет набор XML-файлов, содержащих детали того, как должен осуществляться процесс. В TFS имеются следующие шаблоны проектов: • MSF for CMM IProcess Improvement 6.0, который предназначен для больших команд со строго формальным подходом к управлению проектами на основе модели CMM/CMMI; • MSF for Agile Software Development 6.0, который определяет гибкий подход к управлению проектами разработки программного обеспечения; • Microsoft Visual Studio Scrum 2.2., который предназначен для небольших команд (до 7 - 10 участников), которые используют гибкую методологию и терминологию Scrum. При создании командного проекта предоставляется возможность настраивания и управления следующими областями проекта: • отслеживание рабочих элементов позволяет определить начальные типы рабочих элементов, общие и пользовательские запросы, создать начальные рабочие элементы; • классификации позволяют определить начальные области и итерации проекта; • Web-сайт на базе SharePoint позволяет управлять библиотекой документов проекта; • система контроля версий позволяет определять начальные группы безопасности, разрешения, правила возврата версий; • отчеты формируются в папки, создаваемые на сайте командного проекта; • группы и разрешения включают группы безопасности TFS и разрешения для каждой группы; • построения включают стандартные процессы построения для создания новых построений; • лаборатория включает стандартные процессы лаборатории для использования, а также разрешения лаборатории для каждой группы; • управление тестированием включает стандартные конфигурации тестирования, переменные, параметры и состояния разрешений. Рабочими элементами в Team Foundation Server являются: пользовательское описание функциональности, задачи, тестовые случаи, ошибки и препятствия. Этими элементами нужно управлять для выполнения программного проекта. Система отслеживания рабочих элементов позволяет создавать рабочие элементы, отслеживать их состояние, формировать историю их изменения. Все данные по рабочим элементам сохраняются в базе данных TFS. Team Foundation Server включает централизованную систему контроля версий. Система контроля версий TFS предоставляет следующие возможности: • атомарные возвраты. Изменения, вносимые в файлы, упаковываются с "набор изменений". Возврат файла в наборе изменений представляет собой неделимую транзакцию. Этим гарантируется согласованность базы кода; • ассоциация операций возврата с рабочими элементам, что позволяет отслеживать требования от начальной функции до задач и возврата в систему контроля версий кода, реализующего эту функцию; • ветвление и объединение при разработке кода; • наборы отложенных изменений позволяют создавать копии кода, не записывая их в главное хранилище системы контроля версий; • использование подписей позволяет пометить набор файлов в определенной версии с помощью текстовой подписи; • одновременное извлечение позволяет нескольким членам команды одновременно редактировать файл с последующим объединением изменений; • отслеживание истории файлов; • политики возврата, которые предоставляют возможность выполнить код для проверки допустимости возврата; • примечания при возврате позволяют формировать метаданные о возврате; • прокси-сервер позволяет оптимизировать работу с региональными центрами разработки. Построение проекта программного продукта в TFS реализует Сервер Team Foundation Build. Он позволяет стандартизировать инфраструктуру построений для команды проекта. Построение может выполняться в следующих режимах: • ручной, при котором построение вручную ставится в очередь построений; • непрерывная интеграция, которая позволяет выполнять построение при каждом возврате в систему контроля версий; • прокрутка построений, при которой возвраты группируются вместе, чтобы в построение включались изменения за определенный период времени; • условный возврат, при котором возвраты принимаются лишь в том случае, если успешно прошли слияния и построения отправленных изменений; • расписание, которое позволяет настроить время построения на определенные дни недели. Разработчик имеет возможность взаимодействовать с ключевыми службами Team Foundation Server посредством: • командного обозревателя (Team Explorer) Visual Studio , который предоставляет доступ к функциям управления жизненным циклом приложений, включая командные проекты, Мои работы, анализ кода, управление версиями и построениями • доступа через Web (Team Web Access), посредством которого предоставляется Web доступ к функциям управления жизненным циклом приложений, включая командные проекты, рабочие группы, управление проектами, управление версиями и построеними; • Microsoft Excel, посредством которого предоставляется возможность определять и изменять рабочие элементы массивом, а также создавать отчеты на основе запроса рабочего элемента; • Microsoft Project, посредством которого предоставляется возможность управлять планом проекта, задачами расписания, ресурсами, формировать календарь проекта, диаграммы Ганта и представления ресурсов; • консоли администрирования Team Foundation Server , посредством которой осуществляется настройка TFS; • инструментов командной строки; • сторонних средств интеграции. 1.5 Организация командной разработки на базе Visual Studio и Team Foundation Server При командной разработке программного обеспечения важными вопросами являются планирование работ, составление расписания, управление областью проекта, коммуникации, составление отчетов, анализ и постоянное совершенствование процесса. Для решения этих вопросов Team Foundation Server предлагает следующие инструменты: • шаблон процесса, который определяет процесс, используемый командным проектом; • руководство по процессу, которое содержит описание шаблонов процесса; • коллекция командных проектов, которая представляет собой контейнер для нескольких командных проектов; • командный проект, который хранит и организует данные о всем жизненном цикле разработки программного обеспечения; • отслеживание рабочих элементов, которое позволяет отслеживать состояние рабочих элементов и другую информацию, связанную с ними; • портал проекта/панели мониторинга, на которых предоставляется информация по проекту для всех членов команды; • элементы планирования для управления списками требований как на уровне проекта, так и на уровне итерации; • отчетность, которая позволяет формировать отчеты в ходе жизненного цикла проекта; • интеграция с Microsoft Project и Microsoft Excel для управления проектами из среды Microsoft Office. Командный проект Разработка программного обеспечения начинается с создания командного проекта. Командный проект содержит информацию о каждом шаге жизненного цикла разработки программного обеспечения, включая требования пользователей, задачи, тестовые случаи, ошибки, препятствия, построения. При создании командного проекта необходимо задать его имя, описание, определиться с шаблоном процесса, требованиями к системе контроля версий и необходимостью создания портала для проекта. В результате создания командного проекта Team Foundation Server формирует следующие папки: Моя работа папка, в которой задаются выполняемая и приостановленная работы, доступные рабочие элементы и активные запрошенные задачи анализа кода; Ожидающие изменения папка, в которой обеспечивается возможность сохранения изменений кода в базе данных TFS и извлечения проектных решений для редактирования пользователем; Рабочие элементы проекта папка, в которой хранятся сгруппированные данные о текущих рабочих элементах проекта; Построения папка, в которой формируются и хранятся определения и результаты построения приложений; Отчеты папка, в которой имеются подпапки с отчетами и ссылки на стандартные отчеты; Документы папка, в которой хранятся документы проекта; Параметры папка, в которой хранятся ссылки для перехода к окнам задания параметров проекта (безопасность, состав групп, система управления версиями, области и итерации рабочих элементов, параметры портала и оповещения проекта). После создания командного проекта руководитель формирует команду. Для каждого члена команды руководитель проекта определяет доступ к проекту в целом и отдельным артефактам, которые важны для работы каждого члена команды. Для структурирования проекта используются области и итерации. Области могут определяться исходя из определенного функционального назначения этапа работ, а итерации - в виде набора работ на заданном временном интервале. Рабочие элементы При планировании командного проекта ключевыми сущностями являются рабочие элементы. В зависимости от шаблона командного проекта набор и наименование рабочих элементов несколько отличаются. Так для гибкой методологии Agile рабочими элементами являются: • Пользовательское описание функциональности (User Story); • Задача (Task); • Ошибка (Bug); • Препятствие (Issue); • Тестовый случай. Рабочий элемент "Пользовательское описание функциональности" представляет собой пользовательское требование, которое необходимо выполнить при реализации проекта. Рабочий элемент "Задача" создается в проекте для назначения и выполнения работы. Задачи предоставляют детали реализации для пользовательских требований. Рабочий элемент "Ошибка" используется для отслеживания и мониторинга проблем в программном продукте. Рабочий элемент"Препятствие" используется для фиксации в проекте событий или объектов, которые создают проблемы в выполнении проекта и должны быть устранены в ходе текущей или будущей итерации. Рабочий элемент "Тестовый случай" описывает условия проверки правильности выполнения программным продуктом требований пользователя. Рабочие элементы могут включать наименование, описание назначения, состояние, кому назначено, ценность для бизнеса, принадлежность к рабочей области. При планировании командного проекта пользовательские требования записываются в «Элемент невыполненная работа по продукту». Данную работу можно проводить с использованием: • Командного обозревателя в Visual Studio; • Microsoft Project; • Microsoft Excel. Пользовательские описания функциональности могут быть связаны между собой, а также с дочерними или родительскими элементами. В качестве дочерних элементов могут быть, например, задачи или ошибки. Разработка программного кода Задачи назначаются разработчикам программного кода. Разработчики проводят кодирование и модульное тестирование задач в среде Visual Studio. Разрабатываемые коды находятся под контролем системы управления версиями в хранилище кода. Работоспособные коды задач собираются в построении с помощью Team Service Build и передаются в систему управления версиями на Team Foundation Server . В процессе работы разработчик проводит извлечение (checkingout) файлов с кодами задач приложения в свою рабочую область на инструментальном компьютере. После выполнения определенного этапа работ разработчик осуществляет возврат (checkingin) в хранилище TFS кода. При возврате кода формируется набор изменений (changeset), который содержит всю информацию, связанную с возвратом (ссылки на рабочие элементы, исправления, примечания, политики и данные о владельце, дате и времени). Это дает возможность разработчикам просматривать различные версии файлов и анализировать вносимые изменения. Тестирование Тестировщики на основе тестовых случаев подготавливают тесты для заданных пользовательских требований. Для тестирования файлы кода извлекаются из хранилища TFS и подвергаются тестированию. В случае выявления ошибки формируется рабочий элемент «Ошибка», который направляется разработчику для исправления. Если тесты проходят, то соответствующее пользовательское требование считается выполненным и для него устанавливают состояние "Готово". Отчеты Team Foundation Server имеет мощную систему сбора информации по ходу проекта и подготовки отчетов. Отчеты предназначены как для руководителей проекта, так и для членов команды. Система отчетности базируется на хранилище данных TFS. Данные могут быть представлены в виде отчетов, которые позволяют просматривать метрики проекта. Система отчетов позволяет отслеживать рабочие элементы, построения, статистику системы контроля версий, результаты тестов, индикаторы качества проекта. Team Foundation Server предоставляет набор отчетов, но имеется возможность создавать и пользовательские отчеты. В TFS имеются три хранилища данных: • операционное хранилище; • хранилище данных; • OLAP-куб. Операционное хранилище TFS представляет собой набор реляционных баз данных для хранения информации такой как исходный код, отчеты построения, результаты тестов и отслеживание рабочих элементов. Хранилище данных TFS предназначено для выполнения запросов и создания отчетов. Хранилище данных получает данные из операционного хранилища через определенные промежутки времени. Хранилище данных концептуально построено по схеме "Звезда". OLAP-куб Team Foundation Server является многомерной базой данных, которая содержит агрегированные данные для подготовки аналитических отчетов. OLAP-куб получает данные из хранилища данных TFS через запланированные интервалы времени. Данные многомерной базы данных могут использоваться различными клиентскими приложениями, включая Microsoft Excel и конструктор SQL-отчетов. Team Foundation Server включает два набора отчетов: отчеты Microsoft Excel Reports и отчеты службы отчетности SQL Reporting services Reports. Microsoft Excel позволяет создавать отчеты из OLAP-куба TFS, либо используя запросы рабочих элементов проекта. Отчеты могут быть опубликованы на SharePoint-портале проекта. 1.6 Обеспечение качества программных продуктов Качество программного продукта определяется по нескольким критериям. Качественный программный продукт должен отвечать функциональным и нефункциональным требованиям, в соответствии с которыми он создавался, иметь ценность для бизнеса, отвечать ожиданиям пользователей. В жизненном цикле управления приложениями качество должно отслеживаться на всех этапах жизненного цикла ПО. Оно начинает формироваться с определения необходимых требований. При задании требований необходимо указывать желаемую функциональность и способы проверки её достижения. Качественный программный продукт должен обладать высоким потребительским качеством, независимо от области применения: внутреннее использование разработчиком, бизнес, наука и образование, медицина, коммерческие продажи, социальная сфера, развлечения, Web и др. Для пользователя программный продукт должен удовлетворять определенному уровню его потребностей. Важным аспектом создания качественного ПО является обеспечение нефункциональных требований, таких как удобство в эксплуатации, надежность, производительность, защищенность, удобство сопровождения. Надежность ПО определяет способность без сбоев выполнять заданные функции в заданных условиях и в течение заданного отрезка времени. Производительность характеризуется временем выполнения заданных транзакций или длительных операций. Защищенность определяет степень безопасности системы от повреждений, утраты, несанкционированного доступа и преступной деятельности. Удобство сопровождения определяет легкость, с которой обслуживается продукт в плане простоты исправления дефектов, внесения корректив для соответствия новым требованиям, управления измененной средой. Управление жизненным циклом программного продукта помогает разработчикам целенаправленно добиваться создания качественного ПО, избегать потерь времени на переделку, повторное проектирования и перепрограммирование ПО. Тестирование программного обеспечения Тестирование программного продукта позволяет на протяжении всего жизненного цикла ПО гарантировать, что программные проекты отвечают заданным параметрам качества. Главная цель тестирования - определить отклонения в реализации функциональных требований, обнаружить ошибки в выполнении программ и исправить их как можно раньше в процессе выполнения проекта. На протяжении всего жизненного цикла разработки ПО применяются различные типы тестирования для гарантии того, что промежуточные версии отвечают заданным показателям качества. При этом применяются автоматические и ручные тесты. Модульное тестирование предназначено для проверки правильности функционирования методов классов ПО. Модульные тесты пишутся и исполняются разработчиками в процессе написания кода. Модульное тестирование применяется как для проверки качества кода приложения, так и для проверки объектов баз данных. Исследовательское тестирование предназначено для тестирования, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки. Интеграционное тестирование используется для проверки корректности совместной работы компонентов программного продукта. Функциональное тестирование предполагает проверку конкретных требований к ПО и проводится после добавление к системе новых функций. Нагрузочное тестирование предназначено для проверки работоспособности программного продукта при предельной входной нагрузке. Регрессионное тестирование применяется при внесении изменений в программное обеспечение с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом. Комплексное тестирование предназначено для тестирования функциональных и нефункциональных требований всей системы программного продукта. Приемочное тестирование представляет собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков. Приемочные тесты пишутся бизнес-аналитиками, специалистами по контролю качества и тестировщиками. Для разработчика программного обеспечения в Visual Studio предоставлена возможность создавать модульные и нагрузочные тесты, а также тесты пользовательского интерфейса. В Visual Studio имеются следующие шаблоны тестовых проектов: • проект модульного теста, который позволяет создавать модульные тесты в процессе разработки; • проект с Web-тестами производительности и нагрузочными тестами; • проект с закодированными тестами пользовательского интерфейса. Инструментарием тестировщика в Visual Studio является Microsoft Test Manager (MTM). MTM предназначен для управления жизненным циклом тестирования программного обеспечения, включая планирование, тестирование и мониторинг. MTM интегрирован с Team Foundation Server. С помощью Microsoft Test Manager тестировщики подготавливают планы тестирования, управляют тестированием. При создании плана тестирования в него добавляются наборы тестов, тестовые случаи и конфигурации, необходимые для тестирования. Конфигурации используются для установления среды, в которой будут исполняться наборы тестов. Microsoft Test Manager позволяет выполнять ручные и автоматические тесты, а также исследовательские тесты. Результаты тестирования сохраняются в базе данных, что позволяет подготавливать различные аналитические отчеты. Ошибки, выявленные в процессе тестирования, фиксируются, документируются и передаются разработчикам для их устранения. При внесении изменений в код программной системы возникает необходимость в регрессионном тестировании, причем MTM автоматически формирует план регрессионного тестирования, выявляя какие тесты должны быть повторно выполнены. Для тестировщиков и разработчиков программного обеспечения Visual Studio включает диспетчер виртуальной среды Lab Management. Инструментарий тестирования Lab Management позволяет создать инфраструктуру, которая максимально близко эмулирует реальную среду планируемого использования программного продукта. Такие среды могут использоваться для выполнения автоматических построений, автоматизации тестов и выполнения разработанного кода. Рефакторинг Качество кода программного продукта во многом определяется тем, насколько трудно или легко вносить изменения в код, а также тем насколько доступен код для понимания. Созданное программное приложение может выполнять требуемые функции, но иметь проблемы с внесением изменений или пониманием созданного кода. В этом случае такое ПО нельзя назвать качественным, так как на этапе его сопровождения могут возникнуть проблемы с его модификацией при изменении пользовательских требований. Для улучшения качества кода программных приложений применяют рефакторинг. По определения Фаулера М. рефакторинг определяется как "процесс изменения программной системы таким образом, что её внешнее поведение не изменяется, а внутренняя структура улучшается". Следовательно, в процессе проектирования для создания высококачественного программного продукта необходимо не только обеспечить выполнение функциональных требований, но и нефункциональных, в частности, удобства сопровождения, что предполагает возможность и простоту внесения изменений в код, а также возможность легкого понимания созданного кода. Некачественный дизайн кода определяется по ряду признаков: • жесткость - характеристика программы, затрудняющая внесение изменений в код; • хрупкость - свойство программы повреждаться во многих местах при внесении единственного изменения; • косность характеризуется тем, что код содержит части, которые могли бы оказаться полезными в других системах, но усилия и риски, сопряженные с попыткой отделить эти части кода от оригинальной системы, слишком велики; • ненужная сложность характеризуется тем, что программа содержит элементы, которые не используются в текущий момент; • ненужные повторения, которые состоят в повторяющихся фрагментах кода в программе; • непрозрачность, которая характеризует трудность кода для понимания. Для создания качественного дизайна кода целесообразно применять некоторые принципы и паттерны проектирования ПО. Принцип единственной обязанности определяет, что у класса должна быть только одна причина для изменения. Из этого принципа следует, что классу целесообразно поручать только одну обязанность. Принцип открытости/закрытости определяет, что программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификации. Принцип подстановки Лисков определяет, что должна быть возможность вместо базового класса подставить любой его подтип. Принцип инверсии зависимостей определяет два положения: • модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций; • абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Принцип разделения интерфейсов определяет, что клиенты должны знать только об абстрактных интерфейсах, обладающих свойством сцепленности. Паттерны проектирования предлагают универсальные, проверенные практикой решения. Среди общего списка паттернов следует выделить те, которые целесообразно применять при гибкой разработке программного обеспечения. Это паттерны Команда, Стратегия, Фасад, Посредник, Одиночка, Фабрика, Компоновщик, Наблюдатель, Абстрактный сервер/адаптер/шлюз, Заместитель и Шлюз, Посетитель и Состояние. Использование паттернов при разработке позволяет создавать программное обеспечение, которое легко модифицировать и сопровождать. Следует отметить, что для проведения рефакторинга необходимо иметь надежные тесты, которые обеспечивают контроль соблюдения функциональных требований при улучшении дизайна кода программного обеспечения.