Введение в программную инженерию

2-е издание, исправленное

Кознов Д.В.

Национальный Открытый Университет "ИНТУИТ"

2016
Введение в программную инженерию/ Д.В. Кознов - М.: Национальный Открытый
Университет "ИНТУИ!’", 201G

Цель данного курса - представить программную инженерию в виде целостного
изложения, концентрируясь на концепции процесса, различных методологиях
разработки ПО (CMMI, MSF. Scrum), отдельных видах деятельности процесса -
разработке архитектуры, конфигурационном управлении, работе с требованиями,
тестировании. В стороне умышленно оставлены вопросы, собственно,
программирования, поскольку в рамках общего курса их невозможно эффективно
рассмотреть. В качестве программных средств, поддерживающих целостный процесс
разработки ПО, рассматривается технология компании Microsoft - Visual Studio Team
System (VSTS)c акцентом на Team Foundation Server (TFS). Показывается, как
изложенный выше теоретический материал можно реализовать на практике, с
поддержкой программных средств разработки. Представлено также описание
практикума по MS VSTS, организованного на принципах Scrum.

Несколько слов о практикумах и семинарах, прилагаемых к данному курсу. Их задача -
«прокрутить» лекционный материал через «сито» обсуждений, докладов и
упражнений, основанных на картах памяти для лучшего усвоения. Серия таких
экспериментов уже была проведена в прошлом году, на их основе была создана
методика (опубликована в [1]) по активизации collaborative learning процессов и
повышении активности студентов в изучении лекционного материала. Подобного рода
поддержка лекционного курса крайне необходима, как показывает наш опыт,
поскольку курс состоит в обсуждении проблем и способов их решений, с которыми
студенты еще не сталкивались на практике. Мы юте л и бы также дополнительно
поддержать данный курс практикумами по средствам поддержки жизненного цикла
разработки ПО на основе TFS и процессам разработки.

(с) ООО "ИНТУИТ.РУ", 2009-2016

(с) Кознов Д.В., 2009-2016
Д.В. Кознов	Введение в программную инженерию

О предмете изучения

Понятие программной инженерии. Основные определения:
информатика, Системотехника, Ьизнес-реинжиниринг. Программное
обеспечение: определение, свойства.

Программная инженерия

Чем программирование отличается от программной инженерии? Гем,
что первое является некоторой абстрактной деятельностью и может
происходить во многих различных контекстах. Можно программировать
для удовольствия, для того, чтобы научиться (например, на уроках, на
семинарах в университете), можно программировать в рамках научных
разработок. А можно заниматься промышленным программированием.
Как правило, это происходит в команде, и совершенно точно - для
заказчика, который платит за работу деньги. При этом необходимо точно
понимать, что нужно заказчику; выполнить работу в определенные
сроки и результат должен быть нужного качества - того, которое
удовлетворит заказчика и за которое он заплатит. Чтобы удовлетворить
этим дополнительным требованиям, программирование "обрастает"
различными дополнительными видами деятельности: разработкой
требований, планированием, тестированием, конфигурационным
управлением, проектным менеджментом, созданием различной
документации (проектной, пользовательской и пр.).

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

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

управления ходом разработки. Однако эта общая модель имеет
множество модификаций и вариантов.

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

Все эти и другие дополнительные виды деятельности, выполняемые в
процессе промышленного программирования и необходимые для
успешного выполнения заказов и будем называть программной
инженерией (software engineering)—1. Получается, что так мы обозначаем,
во-первых, некоторую практическую деятельность, а во-вторых,
специальную область знания. Или другими словами, научную
дисциплину Ведь для облегчения выполнения каждого отдельного
проекта, для возможности использовать разнообразный
положительный опыт, достигнутый другими командами и
разработчиками, этот самый опыт подвергается осмыслению,
обобщению и надлежащему оформлению. Гак появляются различные
методы и практики (best practices) - тестирования, проектирования,
работы над требованиями и пр., архитектурных шаблонов и пр А также
стандарты и методологии, касающиеся всего процесса в целом
(например, MSF, RLfP. CMMI, Scmm). Вот эти-то обобщения и входят в
программную инженерию как в область знания.

Необходимость в программной инженерии как в специальной области
знаний была осознана мировым сообществом в конце 60-х годов
прошлого века, более чем на 20 лет позже рождения самого
программирования, если считать таковым знаменитый отчет фон
Неймана "First Draft of a Report on the EDVAC", обнародованный им в
1945 году. Рождением программной инженерии является 1968 год -
конференция NATO Software Engineering, г. Гармнш (ФРГ), которая
целикам была посвящена рассмотрению этих вопросов. В сферу
программной инженерии попадают все вопросы и темы, связанные с
организацией и улучшением процесса разработки ПО. управлением
коллективом разработчиков, разработкой и внедрением программных
средств поддержки жизненного цикла разработки ПО. Программная
инженерия использует достижения информатики, тесно связана с
системотехникой, часто предваряется бизнес-реинжинирингом.
Немного подробнее об этом контексте программной инженерии.

Информатика (computer science) - это свод теоретических наук,
основанных на математике и посвященных формальным основам
вычислимости. Сюда относят математическую логику, теорию
грамматик, методы построения компиляторов, математические
формальные методы, используемые в верификации и модельном
тестировании и т.д. Трудно строго отделить программную инженерию
от информатики, но в целом направленность этих дисциплин различна.
Программная инженерия нацелена на решение проблем производства,
информатика - на разработку формальных, математизированных
подходов к программированию.

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

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

Связь программной инженерии (как области практической
деятельности) с информатикой, системотехникой и бизнес-
реинжинирингом показана на рис. 1.1.

Испопьзует
т

Информатика

Рис. 1.1.

Программное обеспечение

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

Это определение, данное Харальдом Милсом, известным специалистом
в области программной инженерии из компании IBM, заключает в себе
следующее.

1.	Логические предписания - это не только сами программы, но и
различная документация (например, по эксплуатации программ) и
шире - определенная система отношений между людьми,

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

2.	Современное ПО предназначено. как правило, для
одновременной работы со многими пользователями, которые
могут быть значительно удалены друг от друга в физическом
пространстве. Таким образом, вычислительная среда
(персональные компьютеры, сервера и т.д.), в которой ПО
Д.В. Кознов	Введение в программную инженерию

функционирует, оказывается распределенной.

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

4.	ПО развивается во времени - исправляются ошибки, добавляются
новые функции, выпускаются новые версии, меняется его
аппаратная база.

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

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

2.	Согласованность - ПО основывается не на объективных посылках
(подобно тому, как различные системы в классической науке
основываются на постулатах и аксиомах), а должно быть
согласовано с большим количеством интерфейсов, с которыми
Д.В. Кознов	Введение в программную инженерию

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

3.	Изменяемость - ПО легко изменить и, как следствие, требования к
нему постоянно меняются в процессе разработки. Это создает
много дополнительных трудностей при его разработке и
эволюции.

4.	Нематериальность1^ - ПО невозможно увидеть, оно виртуально.
Поэтому, например, трудно воспользоваться технологиями,
основанными на предварительном создании чертежей, успешно
используемыми в других промышленных областях (например, в
строительстве, машиностроении). Там на чертежах в схематичном
виде воспроизводятся геометрические формы создаваемых
объектов. Когда объект создан, эти формы можно увидеть. А на
чем мы основываемся, когда изображаем ПО?

В 70-х годах академиком А.П.Ершовым термин software engineering,
переводился на расский язык как ’'технология программирования".
Программная инженерия - более современный, но менее
традиционный перевод этого же термина, предложенный в конце 90-х
И.В.Поттосиным. В рамках данного курса будем пользоваться именно
этим вариантом перевода.

21 Здесь мы немного поправили классика - у него была незримость...
Д.В. Кознов	Введение в программную инженерию

Процесс разработки программного обеспечения

Понятие процесса разработки ПО. Универсальный процесс. Текущий
процесс. Конкретный процесс. Стандартный процесс.
Совершенствование процесса. Pull/Pibh стратегии. Классические модели
процесса: водопадная модель, спиральная модель. Фазы и виды
деятельности.

Без процесса не понять....

Из деловой переписки менеджера программного проекта.

Процесс

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

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

Однако на сегодняшний день не существует универсального процесса
разработки ПО - набора методик, правил и предписаний, подходящих
для ПО любого вида, для любых компаний, для команд любой
национальности. Каждый текущий процесс разработки,
осуществляемый некоторой командой в рамках определенного проекта,
имеет большое количество особенностей и индивидуальностей. Однако
целесообразно перед началом проекта спланировать процесс работы,
определив роли и обязанности в команде, рабочие продукты
(промежуточные и финальные), порядок участия в их разработке членов
команды и т.д. Будем называть это предварительное описание
конкретным процессом, отличая его от плана работ, проектных
спецификаций и пр. Например, в системе Microsoft Visual Team System
оказывается шаблон процесса, создаваемый или адаптируемый (в
случае использования стандартного) перед началом разработки. В VSTS
существуют заготовки для конкретных процессов на базе CMMI, Scrum и
ДР-

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

•	информацию, правила использования, документацию и
инсталляционные пакеты средств разработки, используемых в
проектах компании (систем версионного контроля, средств
контроля ошибок, средств программирования - различных IDE,
СУБД и т.д.);

•	описание практик разработки - проектного менеджмента, правил
работы с заказчиком и т.д.;

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

Также возможна стандартизация процедуры разработки конкретного
процесса как "вырезки" из стандартного. Основная идея стандартного
процесса - курсирование внутри компании передового опыта, а также
унификация средств разработки. Очень уж часто в компаниях
различные департаменты и проекты сильно отличаются по зрелости
процесса разработки, а также затруднено повторное использование
передового опыта. Кроме того, случается, что компания использует
несколько средств параллельных инструментов разработки, например,
СУБД средства версионного контроля. Иногда это бывает оправдано
(например, таковы требования заказчика), часто это необходимо -
например, Java, .NET (большая компетентность оффшорной компании
позволяет ей брать более широкий спектр заказов). Но очень часто это
произвольный выбор самих разработчиков. В любом случае, такая
множественность существенно затрудняет миграцию специалистов из
проекта в проект, использование результатов одного проекта в другом и
т.д. Однако при организации стандартного процесса необходимо
следить, чтобы стандартный процесс не оказался всего лишь
формальным, бюрократическим аппаратом. Понятие стандартного
Д.В. Кознов	Введение в программную инженерию

процесса введено и подробно описано в подходе CMMI.

Необходимо отметить. что наличие стандартного процесса
свидетельствует о наличии "единой воли" в организации,
существующей именно на уровне процесса. На уровне продаж,
бухгалтерии и др. привычных для всех компаний процессов и активов
единство осуществить не труцно. Л вот на уровне процессов разработки
очень часто каждый проект оказывается сам по себе (особенно в
оффшорных проектах) - ’Текучка" захватывает и изолирует проекты друг
от друга очень прочно.

Совершенствование процесса

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

1.	Происходит быстрая смена технологий разработки ПО, требуются
изучение и внедрение новых средств разработки.

2.	Наблюдается быстрый рост компаний и их выход на новые рынки,
что требует новой организации работ.

3.	Имеет место высокая конкуренция, которая требует поиска более
эффективных, более экономичных способов разработки.

Что и каким образом можно улучшать.

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

2.	Улучшение отдельных управленческих и инженерных практик -
тестирования, управления требованиями и пр

3.	Полная, комплексная перестройка всех процессов в проекте,
департаменте, компании (в соответствии, например, с CMMI).

4.	Сертификация компании (CMM/CMMI, ISO 9000 и пр.).
Мы отделили п. 3 от п. 4 потому, что на практике 4 далеко не всегда
означает действительную созидательную работу по улучшению
процессов разработки ПО, а часто сводится к поддержанию
соответствующего документооборота, необходимого для получения
сертификации. Сертификат потом используется как средство, козырь в
борьбе за заказы.

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

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

Pull/Push стратегии. В контексте внедрения инноваций в
производственные процессы бизнес-компаний (не обязательно
компаний по созданию ПО} существуют две следующие парадигмы.

1.	Organization pull - инновации нацелены на решение конкретных
проблем компании.

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

Пример использования стратегии organization pull - внедрение новых
средств тестирования в ситуации, когда высоки требования по качеству
в проекте, либо когда качество программной системы не удовлетворяет
заказчика.
Пример использования стратегии technology push - переход компании со
средств структурной разработки на объектно-ориентрованные. Еще
один пример использования той же стратегии - внедрение стандартов
качества ISO 9000 или CMML В обоих этих случаях компания не решает
какую-то одну проблему или ряд проблем - она хочет радикально
изменить ситуацию, выйти на новые рубежи и т.д.

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

Использование стратегии organization pull менее рискованно, вносимые
ею изменения в процесс менее глобальны, более локальны. Но и выгод
такие инновации приносят меньше, по сравнению с удачными
внедрениями в соответствии со стратегией technology' push.

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

Еще одно различие обеих стратегий: в случае с organization pull, как
правило, возврат инвестиций от внедрения происходит быстрее, чем в
случае с technology push.

Классические модели процесса

Определение модели процесса. Процесс создания программного
обеспечения не является однородным. Тот или иной метод разработки
Д.В. Кознов	Введение в программную инженерию

ПО, как правило, определяет некоторую динамику развертывания тех
или иных видов деятельности, то есть, определяет модель процесса
(process model).

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

Фазы и виды деятельности. Говоря о моделях процессов, необходимо
различать фазы и виды деятельности.

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

Редко какой заказчик согласится первый раз увидеть результаты только
после завершения проекта. С другой стороны, подрядчики
предпочитают получать деньги постепенно, по мере того, как
выполняются отдельные части работы. Таким образом, появляются
фазы, позволяющие создавать и предъявлять промежуточные результаты
проекта. Фазы полезны также безотносительно взаимодействия с
заказчиком - с их помощью можно синхронизировать деятельность
разных рабочих грутгп, а также отслеживать продвижение проекта.
Примерами фаз может служить согласование с заказчиком технического
задания, реализация определенной функциональное! и ПО, этап
разработки, оканчивающийся сдачей системы на тестирование или
выпуском альфа-версии.

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

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

Виды деятельности, фактически, присутствуют, под разными
названиями, в каждом методе разработки ПО. В RUP они называются
рабочими процессами (work flow), в СММ - ключевыми областями
процесса (key process area). Мы будем сохранять традиционные
названия, принятые в том или ином методе, чтобы не создавать
путаницы.

Водопадная модель была предложена в 1970 году Винстоном Ройсом.
Фактически, впервые в процессе разработки ПО были выделены
различные шаги разработки и поколеблены примитивные
представления о разработке НО в виде анализа системы и ее
кодирования.

Были определены следующие шага: разработка системных требований,
разработка требований к ПО, анализ, проектирование, кодирование,
тестирование, использование - см. рис. 2.1.

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

Разработка
системных
требований

Рис. 2.1.

Наконец, в рамках этой модели было введено прототипирование, то
есть предлагалось разрабатывать систему дважды, чтобы уменьшить
риски разработки. Первая версия - прототип - позволяет увидеть
основные риски и обосновано принять главные архитектурные
решения. На создание прототипа отводилось до одной трети времени
всей разработки.
В 70-80 годах прошлого века эта модель прочно укоренилась в
разработке ПО в силу своей простоты и сходности с моделями
разработки иных, не программных систем. В дальнейшем, в связи с
развитием программной инженерии и осознанием итеративного
характера процесса разработки ПО эта модель активно критиковалась,
практически, каждым автором соответствующих статей и учебников
Стало общепринятым мнение, что она не отражает особенностей
разработки ПО. Недостатками водопадной модели являются:

•	отождествление фаз и видов деятельности, что влечет потерю
гибкости разработки, в частности, трудности поддержки
итеративного процесса разработки:

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

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

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

•	модель неустойчива к сбоям в финансировании проекта или
перераспределению денежных средств, начатая разработка,
фактически, не имеет альтернатив "по ходу дела".

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

тр\да. Водопадная модель вошла в качестве составной части в другие
модели и методологии, например, в MSF.

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

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

Каждый виток имеет следующую структуру (секторы):

•	определение целей, ограничений и альтернатив проекта;

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

•	разработка и тестирование - здесь возможна водопадная модель
или использование иных моделей и методов разработки ПО:

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

Отдельная спираль может соответствовать разработке некоторой
Д.В. Кознов	Введение в программную инженерию

программной компоненты или внесению очередных изменений в
продукт. Таким образом, у модели может появиться третье измерение.

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

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

1-> От английского offshore - вне берега, в расширенном толковании -
вне одной страны
Д.В. Кознов	Введение в программную инженерию

Рабочий продукт, дисциплина обязательств, проект

Рабочий продукт. Дисциплина обязательств Проект. Управление
проектами.

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

Рабочий продукт

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

Таким результатом является рабочий продукт (work product) - любой
артефакт, произведенный в процессе разработки ПО, например, файл
или набор файлов, документы, составные части продукта, сервисы,
процессы, спецификации, счета и т.д.
Часть итоговой
поставки

Промежуточный

Например

Т

Рис. 3.1.

Ключевая разница между рабочим продуктом и компонентой ПО
заключается в том, что первый необязательно материален и осязаем (not
to be engineered), хотя может быть таковым. Нематериальный рабочий
продукт - это, как правило, некоторый налаженный процесс -
промышленный процесс производства какой-либо продукции, учебный
процесс в университете (на факультете, на кафедре) и т.д.

Важно отметить, что рабочий продукт совсем не обязательно является
составной частью итоговой поставки. Например, налаженный процесс
тестирования системы не поставляется заказчику вместе с самой
системой. Умение управлять проектами (не только в области
программирования) во многом связано с искусством определять
нужные рабочие продукты, настаивать на их создании и в их терминах
вести приемку промежуточных этапов работы, организовывать
синхронизацию различных рабочих групп и отдельных специалистов.

Многие методологии включают в себя описание специфичных рабочих
продуктов, используемых в процессе - CMMI, MSF, RUP и др.
Например, в MSF это программный код, диаграммы приложений и
Д.В. Кознов	Введение в программную инженерию

классов (application diagrams и class diagrams), план итераций (iteration
plan), модульный тест (unit test) и др. Для каждого из них точно описано
содержание, ответственные за разработку, место в процессе и др,
аспекты.

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

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

Контроля
разработки

Рис. 3.2.

Дисциплина обязательств

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

Основой этой фзрмы отношений являются обязательства, которые:

•	даются добровольно;

•	не даются легко - работа, ресурсы, расписание должны быть
тщательно учтены;
Д.В. Кознов	Введение в программную инженерию

•	между сторонами включает в себя то, что будет сделано, кем и в
какие сроки ;

•	открыто и публично сформулированы (то есть это не 'тайное
знание").

Кроме того:

•	ответственная сторона стремится выполнить обязательства, даже
если нужна помощь;

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

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

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

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

Дисциплине обязательств уделяется много внимания в рамках MSF,
поскольку там в модели команды нет лидера, начальника. Эта
дисциплина реализована также в Scrum: Scrum-команда имеет много
Д.В. Кознов	Введение в программную инженерию

свобод, и в силу этого - большую ответственность. Регламентируются
также правила действий, когда обязательства не могут быть выполнены
такой командой.

Проект

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

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

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

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

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

Творческие проекты характеризуются абсолютной новизной идеи -
новый сервис, абсолютно новый программный продукт, какого еще не
было на рынке, проекты в области искусства и науки. Любой
начинающий бизнес, как правило, является таким вот творческим
проектом. Причем новизна в подобных проектах не только абсолютная
- такого еще не было. Такое, может, уже и было, но только не с нами,
командой проекта. То есть присутствует огромный объем
относительной новизны для самих людей, которые воплощают этот
проект.

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

Управление проектами (project management) - область деятельности, в
ходе которой, в рамках определенных проектов, определяются и
достигаются четкие цели при нахождении компромисса между объемом
работ, ресурсами (такими как время, деньги, труд, материалы, энергия,
пространство и др.), временем, качеством и рисками.

Отметим несколько важных аспектов управления проектами.

•	Stakeholders - это люди со стороны, которые не участвуют
непосредственно в проекте, но влияют на него и/или
заинтересованы в его результатах. Это могут быть будущие
пользователи системы (например, в ситуации, когда они и
заказчик - это не одно и то же), высшее руководство компании-
разработчика и т.д. Идентификация всех stakeholders и грамотная
работа с ними - важная составляющая успешного проектного
менеджмента

•	Project scope - это границы проекта. Это очень важное понятие
для программных проектов в виду изменчивости требований.
Часто бывает, что разработчики начинают создавать одну систему,
а после, постепенно, она превращается в другую. Причем для
менеджеров по продажам, а также заказчика, ничего радикально
не произошло, а с точки зрения внутреннего устройства ПО,
технологий, алгоритмов реализации, архитектуры - все
радикально меняется. За подобными тенденциями должен
следить и грамотно с ними разбираться проектный менеджмент.

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

При разработке программных проектов, следуя MSF 3.1, важны
следующие области управления.

Область
управления
проектами

Описание

Планирование и
мониторинг
проекта, контроль Интеграция и синхронизация планов проекта;
за изменениями в организация процедур и систем управления и
проекте (Project мониторинга проектных изменений
planning / Tracking /
Change Control)

Управление
рамками проекта
(Scope
Management)

Определение и распределение объема работы
(рамок проекта); управление компромиссными
решениями в проекте
Д.В. Кознов	Введение в программную инженерию
Управление календарным графиком проекта (Schedule Management)	Составление календарного графика исходя из оценок трудозатрат, упорядочивание задач, соотнесение доступных ресурсов с задачами, применение статистических методов, поддержка календарного графика
Управление стоимостью (Cost Management)	Оценки стоимости исходя из оценок временных затрат; отчетность о ходе проекта и его анализ; анализ затратных рисков; функционально- стоимостной анализ (value analysis)
Управление персоналом (Staff Resource Management)	Планирование ресурсов; формирование проектной команды; разрешение конфликтов; планирование и управление подготовкой
Управление коммуникацией (С ommunications Management)	Коммуникационное планирование (между проектной группой, заказчиком/спонсором. потребителями/пользивателями, др. заинтересованными лицами); отчетность о ходе проекта
Управление рисками (Risk Management)	Организация процесса управления рисками в команде и содействие ему; обеспечение документооборота управления рисками  Анализ цен поставщиков услуг и/или аппаратного/ программного обеспечения; подготовка документов
Управление снабжением (Procurement)	об инициировании предложений (requests tor proposals - RFPs), выбор поставщиков и субподрядчиков; составление контрактов и переговоры об их условиях, договора; заказы на поставку и платежные требования
Управление качеством (Quality Management)	Планирование качества, определение применяемых стандартов, документирование критериев качества и процессов его измерения
Д.В. Кознов	Введение в программную инженерию

Архитектура ПО

Понятие архитектуры ПО. Точка зрения и характеристики точек зрения.
Множественность точек зрения при разработке ПО.

Обсуждение

Как-то раз один менеджер объяснял основные идеи одного достаточно
крупного проекта, которым он руководил. Он начертил на доске три
кубика: frontend, backend, tools. И сказал, что это и есть главное строение
проекта. И в смысле внутреннего устройства продукта, и в смысле
распределения работ в команде по трем дистанционно разнесенным
центрам разработки. Задачи hackend сложные, ресурсоемкие,
выполняются пакетно. Они отделены от графического интерфейса
продукта (frontend), который также непросто устроен. Frontend - это
пользовательский интерфейс: сложный, параметризуемый, с рядом
встроенных пользовательских сервисов (в частности, браузер
информации), а также настраиваемый. Обе эти подсистемы
взаимодействуют друг с другом через хорошо определенный и детально
описанный программный интерфейс: алгоритмы backend разбиты на
методы, которые frontend может вызывать по особым правилам, с
параметрами, выстраивая в цепочку для достижения своих задач.
"Сбоку'' от всего этого находятся дополнительные tools. Они
интегрируются во frontend, но не пользуются методами backend, а
реализуют свои задачи самостоятельно. Эти задачи не требуют сложной
пакетной обработки, а нацелены на интерактивное взаимодействие с
пользователем. При их реализации особенно много внимания уделялось
usability.

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

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

В результате выполнения проекта (а он развивался более 15 лет,
достигая в апогее до 150 человек, одновременно занятых в нем) такая
четкая структура несколько сместилась - так географически интерфейс
почти "переехал'' в тот центр, где разрабатывался backend. Но в целом
такое сквозное разделение проекта на части оставалось много лет и
было основным скелетом всей разработки. Это и есть пример
архитектуры программного проекта.

Определение

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

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

Итак, архитектура продукта оказывается инвариантом проекта,
встречается и неожиданно возникает в ого разных частях. Это и есть
аналог "простым" естественно-научным постулатам и законам,
отсутствие которых в разработке ПО, по мнению Брукса, является
причиной сложности ПО (в смысле хаоса, то есть "плохой" сложности).
Создавать такие структуры - непростое дело, требующее большого
искусства. Но именно это путь к управлению хаосом, увеличивающейся
энтропией в виде изменяющихся требований к системе, потере
разработчиками ясного понимания, какую же именно систему они
создают. И именно разработка таких структур доставляет истинное
творческое наслаждение при разработке программных систем. Хорошо
"работают" простые модели, которые не просто создавать. Они
оказываются путеводной нитью проекта, ведущей его через пучины
хаоса. Эти модели имеют такое свойство, что показывая или упоминая о
них можно рассказывать о проекте очень долго, их можно красиво
оформить и повесить на стенку а можно этого и не делать.

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

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

Множественность точек зрения

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

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

разнородной и сложной информации. Посмотрим на разработку ПО и
то, почему там востребованы разные взгляды на процесс, систему и т.д.

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

Разработч1лк

Рис. 4.1. Разные виды деятельности - разные взгляды на систему

Далее, в разработку/использование ПО вовлечено большое количество
очень разных специалистов: программисты, инженеры, тестеры,
технические писатели, менеджеры, заказчик, пользователи, продавцы-
маркетологи и т. д. (см. рис. 4.2). Для всех этих специалистов нужна
разная информация о программной системе. Представьте, что
произойдет, если, например, продавцу или заказчику-непрограммисту в
ответ на просьбу получше ознакомиться с ПО вы дадите почитать
программные коды...
Менеджер

Продавец

Заказчик

Разработчик

Рис. 4.2. Разные специалисты - разные взгляды на систему

Множественность точек зрения происходит также от того, что нет
единых стандартов и норм разработки ПО. То есть разработка ПО во
многом "state of art". Часто приходится изобретать новую точку зрения
моделирования прямо по ситуации - чтобы именно этот эксперт тебя
понял, чтобы именно эти особенности системы были отражены. Часто
здесь - как в лотерее: создается несколько описаний системы с разных
точек зрения, какое-то оказывается уцачным и его все используют в
дальнейшем.
Итак, разные виды деятельности при разработке ПО. разные категории
специалистов, задействованные в программном проекте, и
уникальность каждой конкретной ситуации при разработке — все это
приводит к созданию и использованию различных моделей,
выполненных с разных точек зрения

Точка зрения (viewpoint) — это определенный взгляд на систему,
который осуществляется для выполнения какой-то определенной задачи
кем-либо из участников проекта. Точку зрения нужно ясно осознавать
при создании визуальных моделей, например, варианты использования,
Важно понимать, что она может быть в каждом конкретном случае своя,
Важнейшими характеристиками точки зрения моделирования является
цель (зачем создается модель) и целевая аудитория (то есть, для кого она
предназначается).

Важным вопросом, на который нужно честно себе ответить в самом
начале моделирования — это зачем вы используете диаграммы (в
частности, UML). Это и есть определение цели моделирования. Потому,
что так создавать модели правильно? И все проблемы (даже те, о
которых ничего еще не известно) волшебным образом исчезнут? Очень
часто, например, при создании модели случаев использования
присутствует именно такая "цель" моделирования. А потом оказывается,
что никакие проблемы не "вылечились", а наоборот, возникли новые
(например, созданные нами диаграммы никто не понимает и не
принимает). Да и сам аналитик чувствует, что диаграммы получились
какие-то странные....

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

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

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

Кроме того, важно, чтобы точка зрения была "живая", а не
выдумывалась аналитиком или бездумно копировалась из книжек и
тренингов, посвященных UML. Незаметно для себя аналитик может
придумать свой собственный проект, своих собственных пользователей
системы, заказчика и т.д. То есть аналитик исподволь, навязывает
самому себе определенное восприятие реально существующих людей,
задач, сильно искажая реальное положение дел. И именно в контексте
этой воображаемой ситуации он создает свои модели. Но ведь реальные
люди, реальные ситуации обладают своеобразием, большим
диапазоном вариативности. Соответственно, аналитик должен
обладать гибкостью сознания, большим диапазоном техник, а также
чуткостью и искренним стремлением к тому чтобы сделать каждый
конкретный проект, где он участвует, более гармоничным, более
адекватным.

Язык U ML

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

описание основных, важных аспектов ПО, создаваемых, например,
архитектором при разработке дизайна системы. Для этих целей
используется язык моделирования UML (Unified Modeling Language).

Этот язык является итогом развития средств схематического описания
программных систем, которые развивались с блок-схем, предложенных
еще фон Нейманом в конце 40-х годов Он предполагал, что эти схемы
станут высокоуровневым языком ввода алгоритмов в вычислительные
машины, но эволюция языков программирования пошла по пути
текстовых языков. Тем не менее блок-схемы получили распространение
при спецификации и документировании ПО, были стандартизованы,
однако широкого практического применения не получили. В конце G0 х
годов, в связи с поиском новых средств разработки ПО, рождением
программной инженерии и общими следованиями в области
проектирования и разработки искусственных систем появился термин
структурный анализ (structured analysis) систем. Термин был введен
ученым из MIT, Дугласом Россом, который также предложил
диаграммный метод анализа и проектирования больших искусственных
систем. Метод назывался SADT (Structured Analisys and Design Technique),
стал основой серии военных стандартов США серии 1DEF и широко
распространился в индустрии. Однако диаграммный язык в SADT был
очень скромным - набор блоков и связей между ними, с поддержкой
декомпозиции блоков В 70-х годах, в связи с массовым выходом ПО на
свободный рынок (то есть программные системы стали создаваться не
только в военной области, для крупного бизнеса, но также для среднего
и малого бизнеса) структурный анализ стал бурно эволюционизировать
- набор диаграмм обогатился диаграммами состояний и переходов,
сущность-связь, потоков данных и т.д. С развитием объектно-
ориентированных средств разработки (конец 80-х - середина 90-х)
структурный анализ превратился в объектно-ориентированный анализ
и проектирование. Появилось большое количество методологай, и
постепенно сложился единый язык моделирования, который и был
закреплен в стандарте UML. Произошло это в 1997 году.

С тех пор вышло несколько версий стандарта UML. Текущая версия
UML2.1.

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

•	Структурные диаграммы:

° диаграммы ктассов (class diagrams) предназначены для
моделирования структуры объектно-ориентированных
приложений классов, их атрибутов и заголовков методов,
наследования, а также связей классов друг с другом;

о диаграммы компонент (component diagrams) используются
при моделировании компонентной структуры
распределенных приложений; внутри каждая компонента
может быть реализована с помощью множества классов;

° диаграммы объектов (object diagrams) применяются для
моделирования фрагментов работающей системы,
отображая реально существующие в runtime экземпляры
классов и значения их атрибутов:

° диаграммы композитных структур (composite structure
diagrams) используются для моделирования составных
структурных элементов моделей - коопераций, композитных
компонент и т.д.;

о диаграммы развертывания (deployment diagrams)
предназначены для моделирования аппаратной части
системы, с которой ПО непосредственно связано
(размещено или взаимодействует);

о диаграммы пакетов (package diagrams) служат для разбиения
объемных моделей на составные части, а также
(традиционно) для группировки классов моделируемого ПО.
когда их слишком много.

•	Поведенческие диаграммы:

° диаграммы активностей (activity diagrams) используются для
спецификации бизнес-процессов, которые должно
автоматизировать разрабатываемое ПО, а также для задания
сложных алгоритмов;

о диаграммы случаев использования (use case diagrams)
Д.В. Кознов	Введение в программную инженерию

предназначены для "вытягивания" требований из
пользователей, заказчика и экспертов предметной области;

° диаграммы конечных автоматов (state machine diagram)
применяются для задания поведения реактивных систем;

о диаграммы взаимодействий (interaction diagram):

	диаграммы последовательностей (sequence diagram)
используются для моделирования временных аспектов
внутренних и внешних протоколов ПО;

	диаграммы схем взаимодействия (interaction overview
diagram) служат для организации иерархии диаграмм
последовательностей;

	диаграммы коммуникаций (communication diagrams)
являются аналогом диаграмм последовательностей, но
по-другому изображаются (в привычной, графовой
манере);

° временные диаграммы (timing diagrams) являются
разновидностью диаграмм последовательностей и
позволяют в наглядной форме показывать внутреннюю
динамику взаимодействия некоторого набора компонент
системы

Примеры. Центральным видом диаграмм являются диаграммы классов.
Пример представлен на рис. 4,3.

Рис. 4.3. Пример диаграмм классов

Еще один вид структурных диаграмм - диаграммы развертывания,
пример представлен ниже.
Рис. 4.4. Пример диаграмм размещений

Отметим также еще один важный вид диаграмм UML - диаграммы
компонент (пример представлен на рис. 4.5).

Рис. 4.5. Пример диаграмм компонент

Интересен также вариант диаграмм композитных структур - сложные
компоненты для систем реального времени и телекоммуникаций.
Д.В. Кознов

Пример представлен ниже.

СистемныиблокТРС

---------□----------

:МатеринскаяПлагаТРС

:СетеваяКарга

винчестер

ПамягьТРС
Микросхемы
Памяти [2, 8]

ПроцессорТРС Pentiunr4

□Ю220В

:СО-устройство
[0..1]

БидеоКарга

Рис. 4.6. Пример диаграмм композитных структур

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

Еще один важный вид диаграмм - диаграммы последовательностей.
Они позволяют задавать главные ветки сложных
телекоммуникационных алгоритмов, а также рисовать цепочки вызовов
для объектно-ориентированных приложений, которые
программируются в терминах объектов, но проектируются часто в
терминах цепочек вызовов. Пример представлен ниже.
Рис. 4.8. Пример диаграмм последовательностей
Д.В. Кознов	Введение в программную инженерию

Управление требованиями

Виды требований: функциональные требования, нефункциональные
требования. Свойства требований: ясность и недвусмысленность,
полнота и непротиворечивость, необходимый уровень детализации,
прослеживаемость, тестируемость и проверяемость, модифицируемость.
Формализация требований. Цикл работы с требованиями.

Проблема

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

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

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

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

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

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

Ошибки и разночтения, которые возникают при выявлении требований
к системе, оказываются одними из самых дорогих. Требования - это то
исходное понимание задачи разработчиками, которое является основой
всей разработки.

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

Теперь чудь подробнее об изменчивости ПО и ее причинах.

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

•	В ходе разработки возникают проблемы и трудности, в силу
Д.В. Кознов	Введение в программную инженерию

которых итоговая функциональность меняется (видоизменяется,
урезается).

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

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

Виды и свойства требований

Разделим требования на две большие группы - функциональные и
нефункциональные.

Функциональные требования являются детальным описанием
поведения и сервисов системы, ее функционала. Они определяют то,
что система должна уметь делать.

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

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

•	Полнота и непротиворечивость.

•	Необходимый уровень детализации. Требования должны обладать
ясно осознаваемым уровнем детализации, стилем описания,
способом формализации: либо это описание свойств предметной
области, для которой предназначается ПО, либо это техническое
задание, которое прилагается к контракту, либо это проектная
спецификация, которая должна быть уточнена в дальнейшем, при
детальном проектировании. Либо это еще что-нибудь. Важно
также ясно видеть и понимать тех, для кого данное описание
требований предназначено, иначе не избежать недопонимания и
последующих за этим трудностей. Ведь в разработке ПО
задействовано много различных специалистов - инженеров,
программистов. тестировщиков, представителей заказчика,
возможно, будущих пользователей - и все они имеют разное
образование, профессиональные навыки и специализацию, часто
говорят на разных языках. Здесь также важно, чтобы требования
были максимально абстрактны и независимы от реализации.

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

прослеживаемости необходимо, разумно совмещая формальные и
неформальные подходы.

•	Тестируемость и проверяемость — необходимо, чтобы
существовали способы оттестировать и проверить данное
требование. Причем, важны оба аспекта, поскольку часто
проверить-го заказчик может, а вот тестировать данное
требование очень трудно или невозможно в виду ограниченности
доступа (например, по соображениям безопасности) к окружению
системы для команды разработчика. Итак, необходимы процедуры
проверки -выполнение тестов, проведение инспекций,
проведение формальной верификации части требований и пр.
Нужно также определять ''планку" качества (чем выше качество,
тем оно дороже стоит!), а также критерии полноты проверок,
чтобы выполняющие их и руководители проекта четко
осознавали, что именно проверено, а что еще нет.

•	Модифицируемость. Определяет процедуры внесения изменений
в требования.

Варианты формализации требований

Вообще говоря, требования как таковые - это некоторая абстракция. В
реальной практике они всегда существуют в виде какого-то
представления - документа, модели, формальной спецификации, списка
и т.д. Требования важны как таковые, потому что оседают в виде
понимания разработчиками нужд заказчика и будущих пользователей
создаваемой системы. Но так как в программном проекте много
различных аспектов, видов деятельности и фаз разработки, то это
понимание может принимать очень разные представления. Каждое
представление требований выполняет определенную задачу, например,
служит "мостом", фиксацией соглашения между разными группами
специалистов, или используется для оперативного управления
проектом (отслеживается, в какой фазе реализации находится то или
иное требование, кто за него отвечает и пр.), или используется для
верификации и модельно-ориентированного тестирования. И в первом,
и во втором, и в третьем примере мы имеем дело с требованиями, но
формализованы они будут по-разному.

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

1.	Неформальная постановка требований в переписке по
электронной почте. Хорошо работает в небольших проектах, при
вовлеченности заказчика в разработку' (например, команда
выполняет субподряд). Хорошо также при таком стиле, когда есть
взаимопонимание между заказчиком и командой, то есть лишние
формальности не требуются. Однако, электронные письма в такой
ситуации часто оказываются важными документами - важно
уметь вести деловую переписку, подводить итоги, хранить важные
письма и пользоваться ими при разногласиях. Важно также
вовремя понять, когда такой способ перестает работать и
необходимы более формальные подходы.

2.	Требования в виде документа - описание предметной области и
ее свойств, техническое задание как приложение к контракту,
функциональная спецификация для разработчиков и т.д.

3.	Требования в виде графа с зависимостями в одном из средств
поддержки требований (IBM Rational RequisitePro, DOORS, Borland
CaliberRM и нек. др.). Такое представление удобно при частом
изменении требований, при отслеживании выполнения
требований, при организации "привязки" к требованиям задач,
людей, тестов, кода. Важно также, чтобы была возможность легко
создавать такие графы из текстовых документов, и наоборот,
создавать презентационные документы по таким графам.

4.	Формальная модель требований для верификации, модельно-
ориентированного тестирования и т.д.

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

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

•	Описание возможных решений вместо требований.

*	Нечеткие требования, которые не допускают однозначную
проверку, оставляют недосказанности, имеют отленок советов,
обсуждений, рекомендаций: 'Возможно, что имеет смысл
реализовать также......", "и т.д.".

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

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

Цикл работы с требованиями

В своде знаний по программной инженерии SWEBOK определяются
следующие виды деятельности при работе с требованиями.

•	Выделение требований (requirements clicitauon), нацеленное на
выявление всех возможных источников требований и
ограничений на работу системы и извлечение требований из этих
источников.

•	Анализ требований (requirements analysis), целью которого является
обнаружение и устранение противоречий и неоднозначностей в
требованиях, их уточнение и систематизация.

•	Описание требований (requirements specification). В результате этой
деятельности требования должны быть оформлены в виде
Д.В. Кознов	Введение в программную инженерию

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

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

Конфигурационное управление

Понятие конфигурационного управления. Управление версиями.
Понятие "ветки" проекта. Управление сборками. Средства версионною
контроля. Единицы конфигурационного управления. Понятие baseline.

Проблема

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

Рассмотрим теперь проект по разработке программного обеспечения.
Что в нем является аналогом материальных активов на обычном
производстве? Определенно, нс столы и стулья, которыми пользуются
разработчики. И даже не компьютеры, запчасти к ним и прочее
оборудование. Учета и контроля, сродни складскому требуют файлы
проекга. В программном проекге их очень много - сотни и тысячи даже
для относительно небольших проектов. Ведь создать новый файл очень
легко. Многие технологии программирования поддерживают стиль,
когда, например, для каждого класса создается свой отдельный файл.
Файл - это виртуальная информационная единица. В чем главное
отличие файла от материальных единиц учета? В том, что у файла
может быть версия, и не одна, и породить эти версии очень легко -
достаточно скопировать данный файл в другое место на диске. В то
время как материальные предметы существуют на складе сами по себе,
и для них нет понятия версии. Да, может быть несколько однотипных
предметов, разных заготовок изделия различной степени готовности.
Но все это не то..Л версия файла - это очень непростой объект. Чем

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

В итоге в программном проекте начинают происходить мистические и
загадочные события.

•	Тщательно оттестированная программа на показательных
испытаниях не работает

•	Функциональность, о которой долго просил заказчик и которая
была, наконец, добавлена в продукт, и новая версия торжественно
отослана заказчику, таинственным образом исчезла из продукта.

•	На компьютере разработчика программа работает, а у заказчика -
нет....

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

Она серьезно тормозит внутреннюю работу. То разработчики и тестеры
работают с разными версиями системы, то итоговая сборка системы
требует специальных усилий всего коллектива. Более того, возможны
неприятности на уровне управления Различные курьезные ситуации,
когда заявленная функциональность отсутствует или не работает (опять
не те файлы послали!), могут сильно портить отношения с заказчиком.
Недовольный заказчик может потребовать даже денежной компенсации
за то, что возникающие ошибки слишком подолгу исправляются. А будет
тут не долго, когда разработчики не могут воспроизвести и исправить
ошибку, так как не могут точно определить, из каких же исходных
текстов была собрана данная версия!

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

Выделим две основные задачи в конфигурационном управлении -
управление версиями и управление сборками. Первое отвечает за
управление версиями файлов и выполняется в проекте на основе
специальных программных пакетов - средств версионного контроля.
Существует большое количество таких средств - Microsoft Visual
SourceSafe, IBM ClearCase, cvn, subversion и др. Управление сборками -
это автоматизированный процесс трансформации исходных текстов ПО
в пакет исполняемых модулей, учитывающий многочисленные
настройки проекта, настройки компиляции, и интегрируемый с
процессом автоматического тестирования. Эта процедура является
мощным средством интеграции проекта, основой итеративной
разработки.

Единицы конфигурационного управления

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

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

принято называть единицами конфигурационного управления
(configuration management items). Вот примеры:

1.	пользовательская документация;

2.	проектная документация;

3.	исходные тексты ПО;

4.	пакеты тестов;

5.	инсталляционные пакеты ПО;

6.	тестовые отчеты.

У каждой единицы конфигурационного управления должно быть
следующее.

1.	Структура - набор файлов. Например, пользовательская
документация в html должна включать индекс-файл и набор hmi]-
файлов, а также набор вынесенных картинок (gif или jpeg-файлы).
Эта структура должна быть хорошо определена и отслеживаться
при конфигурационном управлении - что все файлы не потеряны
и присутствуют, имеют одинаковую версию, корректные ссылки
друг на друга и т.д.

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

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

4.	Автоматическая процедура контроля целостности элемента -
например, сборка для исходных текстов программ. Есть не у всех
элементов, например, может не быть у документации, тестовых
пакетов.
Д.В. Кознов	Введение в программную инженерию

Элементы конфигурационного управления могут образовывать
иерархию. Пример представлен на рис. 6.1.

Рис. 6.1.

Управление версиями

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

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

•	V1.0 - ветвь, соответствующая выпущенному релизу. Внесение
изменений в такие ветви запрещены и они хранят образ кода
системы на момент выпуска релиза.

•	Fix VI.О 1 - ветвь, соответствующая выпущенному пакету
исправлений к определенной версии. Подобные ветви
ответвляются от исходной версии, а не от основной ветви и
замораживаются сразу после выхода пакета исправлений.

•	Upcoming (VI.1) - ветвь, соответствующая релизу, готовящемуся к
выпуск}' и находящемуся в стадии стабилизации. Для таких
ветвей, как правило, действуют более строгие правила и работа в
них ведется более формально.

•	Mainline - ветвь, соответствующая основному направлению
развития проекта. По мере созревания именно от этой ветви
отходят ветви готовящихся релизов.

•	WCF Experiment - ветвь, созданная для проверки некоторого
технического решения, перехода на новую технологию, или
внесения большого пакета изменений, потенциально нарушающих
работоспособность кода на длительное время. Такие ветви, как
правило, делаются доступными только для определенного круга
разработчиков и убиваются по завершению работ после
интеграции с основной веткой.

Управление сборками

Итак, почему же процедура компиляции и создания exe dll файлов по
исходникам проекта - такая важная процедура? Потому что она
многократно в день выполняется каждым разработчиком на его
собственном компьютере, с его собственной версией проекта При этом
отличается:
Д.В. Кознов	Введение в программную инженерию

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

•	отличаются параметры компиляции.

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

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

•	наличие специфических ошибок, возникших из-за того, что
отдельные проекты разрабатывались без учета параметров
компиляции (в частности, переход в Visual Studio с debug на release
версию часто сопровождается появлением многочисленных
проблем).

В связи с этим процедуру сборки проекта часто автоматизируют, то есть
выполняют не из среды разработки, а из специального скирпта - build-
скрипта. Этот скрипт используется тогда, когда разработчику требуется
полная сборка всего проекта. А также он используется в процедуре
непрерывной интеграции (continues integraUon) - то есть регулярной
сборке всего проекта (как правило - каждую ночь). Как правило,
процедура непрерывной интеграции включает в себя и регрессионное
тестирование, и часто - создание инсталляционных пакетов. Общая
схема автоматизированной сборки представлена на рис. 6,2.

Рис. 6.2.

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

оказываются очень востребованы. Кроме того, наличие базовой,
актуальной, целостной версии продукта позволяет организовать
разработку в итеративно-инкрементальном стиле, то есть на основе
внесения изменений. Такой стиль разработки называется baseline-мстод.

Понятие baseline

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

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

Baseline может также поддерживаться непрерывной интеграцией.

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

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

Стандартизация качества. Методы обеспечения качества ПО. Понятие
тестирования. Тестирование черного ящика. Тестирование белого
ящика. Инструменты тестирования Критерии тестирования. Виды
тестирования. Работа с ошибками. Средства контроля ошибок (bug
tracking systems).

Управление качеством

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

1.	1865 год - образован комитет, который ныне называется ITU
(International Telecommunication Union). Сейчас штаб-квартира в
Женеве (Швейцария), a ITU является частью ООН. Его основная
задача - стандартизация телекоммункационных протоколов и
интерфейсов с целью поддержания и развития глобальной
мировой телекоммуникационной сети. Самыми известными
стандартами ГШ являются:

о ISDN	(цифровая телефонная связь, объединяющая

телефонные сервисы и передачу данных),

° ADSL	(широко	известная модемная технология,

позволяющая использовать телефонную линию для выхода в
Интернет, не блокируя при этом обычного телефонного
сервиса),

о OSI (модель открытою 7-уровневого сетевого протокола, на
которой базируются все современные стандартные сетевые
интерфейсы и протоколы; также является стандартом ISO),
ч языки визуального проектирования телекоммуникационных
Д.В. Кознов	Введение в программную инженерию

систем, SDLh MSC, влившиеся позднее в UML.

Многие стандарты ITTJ переводятся на русский язык и
превращаются в российские стандарты н виде ГОСТов.

2.	1946 год - создана организация ISO (International Organization for
Standardization). Цель - содействие развитию стандартизации, а
также смежных видов деятельности в мире с целью обеспечения
международного обмена товарами и услугами, способствование и
развитие сотрудничества в интеллектуальной, научно-
технической и экономической областях. К настоящему времени
создано около 17 000 стандартов в самых разных областях
промышленности - продовольственные и иные товары,
различное оборудование, банковские сервисы и т.д. Вот
некоторые стандарты.

о Серия стандартов ISO 9000. Направлены на
стандартизацию качества товаров и услуг. Определение
качества, определение системы поддержки качества на всех
жизненных фазах изделия, товара, услуги (проектирование,
разработка, коммерциализация, установка и обслуживание),
описание процедур по улучшению деятельности компании,
промышленного производства.

° ISO/IEC 90003:2004 - адаптация стандартов ISO 9000 к
производству ПО в русле обеспечения качества в
жизненном цикле ПО.

о ISO 9126:2001 - определение качественною ПО и
различных атрибутов, описывающих это качество.

Многие стандарты ISO переводятся на русский язык и
превращаются в российские стандарты в виде ГОСТов. Имеется
много стандартов в области информационных технологий, а
также несколько - в области программной инженерии. На
соответствие стандартам ISO существует сертификация В
частности, компании сертифицируются на соответствие
стандартам ISO 9000, то есть на качественный процесс разработки
ПО.

3.	1988 год, образование организации ETSJ (European
Telecommunications Standards Institute), штаб-квартира в г. София
Лнтиполис (Франция). Является независимой, некоммерческой,
организацией по стандартизации в телекоммуникационной
промышленности (изготовители оборудования и операторы сети)
в Европе. Самые известные стандарты - GSM, система
Д.В. Кознов	Введение в программную инженерию

профессиональной мобильной радиосвязи TEIRA.

Остановимся теперь на ряде комитетов, непосредственно связанных с
разработкой НО.

1.	1984 год - создание SEI (Software Engineering Insumte) на базе
университета Карнеги-Меллон в г.Питсбурге (США). Инициатор и
главный спонсор - министерство обороны США. Основная задача
- стандартизация в области программной инженерии, выработка
критериев для сертификации надежных и зрелых компаний (что в
первую очередь интересует Минобороны США для выполнения
его заказов). Самые известные продукты - стандарт СММ, CMMI,
разработки в области семейства программных продуктов (product
lines). Эти продукты шагнули далеко за пределы военных
разработок США, их использование и развитие стало
международной деятельностью. Некоторые продукты SEI
стандартизованы также ISO. На соответствие CMM/CMMI
проводится сертификация.

2.	1963 год - создание IEEE (Institute of Electrical and Electronics
Engineers). Ведет историю с конца XIX века, в контексте
промышленной стандартизацией в США. Сейчас IEEE
международная некоммерческая ассоциация специалистов в
области техники, мировой лидер в области разработки стандартов
по радиоэлектронике и электротехнике. Штаб-квартира в США,
существуют многочисленные подразделения в разных странах,
включая Россию. IEEE издаёт третью часть мировой технической
литературы, касающейся применения радиоэлектроники,
компьютеров, систем управления, электротехники, в том числе
(январь 2008) 102 реферируемых научных журнала и 36
отраслевых журналов для специалистов, проводит в год более 300
крупных конференций, принимала участие в разработке около 900
действующих стандартов.

3.	1989 год - группа американских 1Т-компаний (в том числе Hewlett
Packard, Sun Microsystems, Canon) организовали OMG (Object
Managemenr Group). Сейчас включает около 800 компаний членов.
Основное направление - разработка и продвижение объектно-
ориентированных технологий и стандартов, в том числе для
создания платформо-независимых программных приложений
уровня предприятий. Известные стандарты CORBA, LML, MDA.
Д.В. Кознов	Введение в программную инженерию

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

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

Качество продукта или сервиса, предназначенного потребителю,
определяется в стандарте ISO 9000:2005 как степень соответствия его
характеристик требованиям - обязательным или подразумеваемым.

Методы обеспечения качества ПО. Не претендуя на абсолютную
полноту, перечислим различные способы контроля качества,
используемые на практике при разработке ПО.

•	Наладка качественного процесса, другими словами
совершенствование процесса. Для комплексного улучшения
процессов в компании (подход technology push) компаниями-
разработчиками ПО используются стандарты CMM/CMMI, а
также по стандартам серии ISO 9000 (с последующей
официальной сертификацией). Применяются и локальные
стратегии, менее дорогостоящие и более направленные на
решение отдельных проблем (подход organization pull).

•	Формальные методы— - использование математических
формализмов для доказательства корректности, спецификации,
проверки формального соответствия, автоматической генерации и
т.д.:

о доказательство правильности работы программ,

с проверка на моделях определенных свойств (model cheking),
о статический анализ кода по дереву разбора программы
(например, проверка корректности кода по определенным
критериям - аккуратная работа с памятью, поиск мертвого
кода и пр.),

о модельно-ориентированное тестирование (model-based
testing): автоматическая генерация тестов и тестового
Д.В. Кознов	Введение в программную инженерию

окружения по формальным спецификациям требований к
системе) и т.д.

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

•	Исследование и анализ динамических свойств ПО. Например,
широко используется профилирование - исследование
использования системой памяти, ее быстродействие и др.
характеристик путем запуска и непосредственных наблюдений в
виде графиков, отчетов и пр. В частности, этот подход
используется при распараллеливании программ, при поиске
"узких" мест. Еще пример - область, называемая "моделирование и
анализ производительности" (pertoimance modeling and analysis).
Здесь моделируется нагрузочное окружение системы (число
одновременных пользователей системы, сетевой трафик и пр.) и
наблюдается поведение системы.

•	Обеспечение качества кода. Сюда относится целый комплекс
различных мероприятий и методов. Вот некоторые, самые
известные из них.

о Разработка стандартов оформления кода в проекте и
контроль за соблюдением этих стандартов. Сюда входят
правила на создание идентификаторов переменных,
методов и имен классов, на оформление комментариев,
правила использования стандартных для проекта библиотек
и т.д.

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

методов, в данный момент активно поддерживается
различными средами разработки ПО.

° Различные варианты инспекции кода, например, техника
peer code review. Последняя заключается в том, что код
каждого участника проекта, выборочно, читается и
обсуждается на специальных встречах (code review meetings),
и делается это регулярно. Практика показывает, что в целом
код улучшается.

° Есть еще такой подход, как "вычитка" кода, используемый,
например, при разработке критических систем реального
времени. Ею занимаются также разработчики, но их роль в
данном проекте - вычитка, а не разработка.

•	Тестирование. Самый распространенный способ контроля
качества ПО, представленный, фактически, в каждом
программном проекте.

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

Тестирование - это проверка соответствия между реальным
поведением программы и ее ожидаемым поведением в специально
заданных, искусственных условиях. Разберем это определение по
частям.

Ожидаемое поведение программы Исходной информацией для
тестирования является знание о том, как система должна себя вести, то
есть требования к ней или к ее отдельной части. Самым
распространенным способом тестирования является тестирование
методом черного ящика, то есть когда реализация системы недоступна
тестировщикам, а тестируется только ее интерфейс. Часто это
закрепляется и организацией коллектива - тестеровщики оказываются
отдельными сотрудниками и в некоторых компаниях они даже
принципиально не общаются с разработчиками, чтобы минимально
знать реализационных деталей и максимально полно выступить в роли
проверяющей инстанции. Существует тестирование методом белого
ящика, когда код программ доступен тестеровщикам и используется в
качестве источника информации о системе^. Его схема представлена на
рис. 7,1.
Несоответствия

Рис. 7.1.

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

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

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

Тесты могут быть 'ручными" и автоматизированными. "Ручной" тест -
это последовательность действий тестеровщика, которую он (или
разработчик) может воспроизвести и ошибка произойдет. Как правило,
в средствах контроля ошибками такие последовательности действий
содержатся в описании ошибки. Автоматический тест - это некоторая
программа, которая воздействует на систему и проверяет то или иное ее
свойство. .Автоматический тест, по сравнению с "ручным", можно легко
воспроизводить без участия человека. Можно создавать наборы тестов
и прогонять их часто, например, в режиме регрессионного
тестирования. Кроме того, автоматические тесты можно генерировать
по более высокоуровневым спецификациям, например, по формально
описанным требованиям к системе. Л, например, тесты для
компиляторов можно генерировать по формальному описанию языка
программирования.

Таким образом, преимущества автоматических тестов перед ’'ручными"
очевидны. Поговорим теперь о трудностях автоматического
тестирования.

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

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

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

Во-вторых, часто возникает проблема ресурсов для автоматического
тестирования. Особенно при автоматической генерации тестов: часто
есть возможность автоматически сгенерировать очень большое
количество тестов, так что если их еще выполнять регулярно, в режиме
непрерывной интеграции, то не хватит имеющихся системных
ресурсов. При этом качество тестирования может оказаться
неудовлетворительным - ошибки находятся редко или вообще не
находятся. Дело в том, что количество всех возможных состояний
программной системы очень велико, и тестирование не может покрыть
их все. На практике, в реальных проектах, определяют критерии
тестирования, которые определяют ту "планку" качества, которую
необходимо достичь в этом проекте. Ведь хорошее качество стоит дорого
и очевидно, что разное ПО имеет разное качество, например, система
управления ядерным реактором и текстовый редактор. На практике,
часто, качество ПО определяется бюджетом проекта по его разработке.
Далее, в силу ограниченности ресурсов на тестирование часто
целесообразно бывает определить те аспекты ПО, которые наиболее
важны -как для общей работоспособности системы, так и для заказчика.
Например, при тестировании Web-приложения, предоставляющего
услугу по созданию объявлений о продаже недвижимости, такими
критериями были:

•	правильность переходов сложного мастера - в частности, в связи
с возможностью переходов назад;

•	целостность введенных пользователем данных о создаваемых
объявлениях.

Наконец, кроме ограничения количества тестов их отбора важным
является их прогон на некоторых (нс на всех возможных!) входных
данных. Часто здесь применяют принцип факторизации - множество
всех возможных входных значений разбивают на значимые с точки
зрения тестирования классы и ,тпрогоняют" тесты не на всех возможных
входных значениях, а берут по одному набору значений из каждого
класса. Например, тестируют некоторую функцию системы на ее
граничные значения - очень большие значения параметров, очень
маленькие и пр Часто факторизацию удобно делать, исходя из
требований к данной функции, также бывает полезно посмотреть на ее
реализацию и ''пройтись" тестами по разным ее логическим веткам
(порождаемым, например, условными операторами).

Виды тестирования. Не претендуя на полноту, выделим следующие
виды тестирования.

•	Модульное тестирование - тестируется отдельный модуль, в
отрыве от остальной системы. Самый распространенный случай
применения - тестирования модуля самим разработчиком,
проверка того, что отдельные модули, классы, методы делают
действительно то, что от них ожидается. Различные среды
разработки широко поддерживают средства модульного
тестирования - например, популярная свободно
распространяемая библиотека для Visual Studio NUnii, JUnit для Java
и т.д. Созданные разработчиком модульные тесты часто
включаются в пакет регрессионных тостов и таким образом, могут
запускаться многократно.

•	Интеграционное тестирование - два и более компонентов
тестируются на совместимость. Это очень важный вид
тестирования, поскольку разные компоненты могут создаваться
разными людьми, в разное время, на разных технологиях. Этот
вид тестирования, безустовно, должен применяться самими
программистами, чтобы, как минимум, удостовериться, что все
живет вместе в первом приближении. Далее тонкости интеграции
могут исследовать тестеровщики. Необходимо отметить, что
такого рода ошибки - "ошибки на стыках" - непросто
обнаруживать и устранять. Во время разработки все компоненты
все вместе не готовы, интеграция откладывается, а в конце
обнаруживаются трудные ошибки (в том смысле, что их
устранение требует существенной работы). Здесь выходом
является ранняя интеграция системы и в дальнейшем
использование практики постоянной интеграции.

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

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

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

•	Стрессовое тестирование - тестирование системы на
устойчивость к непредвиденным ситуациям. Этот вид
Д.В Кознов	Введение в npui раммную инженерию

тестирования нужен далеко не для каждой системы, так как
подразумевает высокую планку качества.

•	Приемочное тестирование - тестирование, выполняемое при
приемке системы заказчиков. Более того, различные стандарты
часто включают в себя наборы приемочных тестов Например,
существует большой пакет тестов, поддерживаемых компанией
Sun Microsystems, которые обязательны для прогона для всех
новых реализаций Java-машины. Считается, что только после
того, как все эти тесты успешно проходят, новая реализация
вправе называться Java.

Работа с ошибками

Между программистами и тестеровщиками необходим специальный
интерфейс общения. Ведь ошибок находится много, их исправление
требует времени, и их исправления разработчиками тесгеровщики
должны удостовериться, что они действительно исправлены Кроме
того, менеджерам нужна статистика по найденным и исправленным
ошибкам - эго хороший инструмент контроля проекта. Все это
изображено на рис. 7.2. Чтобы справиться с этим потоком информации
и обеспечить необходимые в работе, удобные сервисы, существует
специальный класс программных средств - средства контроля ошибок
(bug tracking systems).
Менед-
жеры

Рис. 7.2.

Как правило, описание ошибки в системе контроля ошибок имеет
следующие основные атрибуты:

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

•	ответственного за ее исправление - разработчика, которому
ошибка отправляется на исправление;

•	состояние, например, ошибка найдена, ошибка исправлена,
ошибка закрыта, ошибка вновь проявилась и т.д.

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

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

•	базу данных для хранения ошибок;

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

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

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

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

Очень важным при работе с ошибками оказываются различные отчеты,
о чем будет подробно рассказано при обсуждении VSTS.

Формальные методы понимаются в двух смыслах: в узком, как
математизированные подходы к разработке ПО и в широком - как
методы, основывающиеся на четких предписаниях, языкам и пр. Здесь
мы будем рассматриваем формальные методы в узком смысле.

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

Диаграммные техники в работе со знаниями

Случаи использования. Работа с требованиями. Случаи использования
в управлении разработкой. Итеративный цикл автор/рецензент. Карты
памяти.

Метод случаи использования

Описание примера. В качестве примера рассмотрим 'Телефонную
службу приема заявок". Заказчиком данной системы является компания,
владеющая сетью продуктовых магазинов. Эта компания, кроме
обычной розничной торговли и оптовых поставок продуктов
отдельным столовым и ресторанам, хочет предоставлять еще и сервис
по обслуживанию клиентов по телефонным заявкам. Клиент
регистрируется в компании, а потом по телефону, в удобное для себя
время, делает заказ товаров, которые к нему привозят домой, и он
расплачивается. Для этого компания хочет организовать у себя
локальный телефонный центр, состоящий из офисной многоканальной
АТС, плата операторов и соответствующего программного обеспечения.
При этом в компании уже есть информационная система по обработке
заявок от постоянных мелкооптовых клиентов, и заказываемая система
должна быть с ней проинтегрирована.

Работа с требованиями. Случаи или варианты использования (use cases)
были предложены в конце 90-х годов Айвером Якобсоном, одним из
главных авторов языка UML, как диаграммный подход для извлечения и
первичной формализации требований к системам. Выше уже
говорилось о сложности по формированию единой и связной картины
требований к ПО. Необходимо извлечь требования из всех возможных
источников, формализовать в некотором виде и обсудить. Этот процесс
- извлечение, формализация, обсуждение - итеративен, то есть все
делается не за один присест. Более того, сам способ формализации
должен быть удобен для обсуждения, и в первую очередь, с
потенциальными пользователями системы, которые могут быть
совершенно не компетентны в II. Их комментарии, одобрения и
несогласия часто яв тяюгся основой итеративного извлечения
требований к системе. Кроме того, этот способ работы с информацией
должен вести к созданию моделей, удобных в дальнейшей реализации
системы. Другими словами, ясно формулировать исходные задачи для
разработки. То есть способ формализации должен быть прост, понятен
и обладать достаточной строгостью. Этим требованиям удовлетворяют
диаграммы случаев использования, являющиеся на сегодняшний день
составной частью стандарта UML.

Пример диаграммы случаев использования представлен на рис. 8.1.

Рис. 8.1. Пример диаграммы случаев использования

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

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

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

Различные пользователи ПО, изображаемые на диаграммах случаев
использования, называются актерами (actors). Актеры могут обозначать:

•	типовых пользователей ("Менеджер", "Оператор", Техническая
поддержка") — работников компании, сгруппированных по
исполняемым обязанностям;

•	другие системы, взаимодействующие с данной ("Система
обработки заявок");

•	выделенного пользователя ("Петров А.Б.").

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

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

Итак, случай использования (use case) — это независимая часть
функциональности системы, обладающая результирующей ценностью
для ее пользователей.

"Независимость" означает, что если случай использования всегда
исполняется вместе с некоторым другим, то, по всей видимости, один
из них нужно включить в другой (какой именно в какой, как назвать
получившийся в итоге случай использования — зависит от
обстоятельств).

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

Случаи использования, соответствующие актерам 'Техническая
поддержка и администрирование" и "Служба обработки заявок"
несколько не вписываются в представленное выше определение.
Прежде всего, сами эти актеры не являются пользователями ПО,
участвующими в основном бизнес-процессе обработки телефонных
заявок. 'Техническая поддержка и администрирование" занята
поддержкой ПО и оборудования системы обслуживания телефонных
заявок, а также ее администрированием (добавлением новых
пользователей, назначением им соответствующих прав и пр.). "Служба
обработки заявок" является уже существующей в компании
информационной системой, имеющей базу данных и ряд сервисов по
обработке заявок. Идентификация этих актеров и соответствующих им
случаев использования важна с точки зрения определения требований к
системе. Для представителей службы технической поддержки
необходим специальный удобный интерфейс с набором
соответствующих функций. А все поступившие по телефону заявки
должны попасть в единую базу данных заявок и пройти единый цикл
обработки. Упущение этих факторов может привести к серьезным
недочетам и проблемам. Кроме того, они ни откуда не следуют
напрямую и поэтому нуждаются в особых начальных вершинах в дереве
требований - то есть мы решили, что целесообразно поместить их на
главную диаграмму случаев использования.

Отметим еще одну интересную деталь. Клиент магазина не является
пользователем данного ПО. Он оказывается бизнсс-пользователем всей
системы в целом (включая соответствующий бизнес-процесс и
оборудование). На рис. 8.2 представлена бизнес-диаграмма случаев
использования.
Задающий
вопросы

Отвечу на
вопросы

Постоянный
клиент

Новый
клиент

Рис. 8.2. Пример диаграммы бизнес-случаев использования

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

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

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

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

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

Итеративный цикл автор/рецензент

Опишем одну интересную и крайне полезную технику использования
визуального моделирования при выявлении знаний о какой-либо
предметной области через общение с экспертами (специалистами в
этой предметной области). Эта техника называется цикл автор/
рецензент (Reader/Ainhor Cycle review process) и может применяться,
например, при работе с диаграммами случаев использования, при
работе как с UML, так и с любым другим языком визуального
моделирования. Эта техника была определена в рамках методологии
SADT.

Активный сотрудник — автор визуальных моделей (author), — изучает
не вполне знакомую ему область знаний. При этом автору постоянно
нужна обратная связь с экспертами в этой предметной области, чтобы
он осознавал, насколько правильно он понял и адекватно формализовал
тот или иной аспект изучаемых знаний.

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

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

*	автор (author) модели — тот, кто ее создает;

•	эксперт (commenter) — это специалист в той предметной области,
для которой строится данная модель; автор интервьюирует
эксперта, получая необходимую для моделирования информацию;
эксперт просматривает и комментирует созданные автором
диаграммы; важно, что эксперт выражает свои комментарии в
письменном виде и разделяет с автором ответственность за
качество создаваемых моделей; эксперт может быть также
архитектором системы, который активно участвует в процессе
разработки модели анализа — но не как автор моделей (у него
хватает других забот), а как активный критик (при разработке
архитектуры системы он будет активно использовать эту модель);

•	читатель (reader) — во всем похож на эксперта, но не обязан
давать письменные комментарии к моделям и не несет
ответственности за качество моделирования.

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

Кроме автора, эксперта и читателя в цикле ''читатель/автор' имеются
также следующие роли:

•	библиотекарь (librarian) — это главный координатор процесса
моделирования; он следит за тем, чтобы все участники процесса
вовремя получали свежие копии моделей, чтобы эти копии не
терялись и вовремя попадали в архив, а последний был бы
доступен; в его компетенцию входит также отслеживать, что все
замечания экспертов и читателей обработаны автором, не
оставлены без внимания: раньше, когда метод SADT только
появился, роль библиотекаря была велика — модели строились на
бумаге; теперь же для этого используют разные графические
пакеты, а для хранения разных версий модели — программные
средства управления версиями;

• комитет технического контроля (technical review committee) — это
группа людей, которая следит за тем, насколько процесс
моделирования отвечает целям проекта, будет ли возможность
использовать в дальнейшей работе создаваемые диаграммы; этот
комитет следит также за тем, когда моделирование нужно
завершить; ведь время людей может стоить существенных денег, у
проекта есть сроки, а процесс моделирования может
продолжаться очень долго — например, автор может увлечься,
изучая новую предметную область

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

Кроме того, цикл ’автор/рецензент" может быть использован и вне
контекста извлечения знаний, когда мы, зачем-либо создавая
визуальные модели, хотим получать регулярную и упорядоченную
обратную связь.

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

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

На рис. 8.3 показана начальная диаграмма, которую нарисовал автор для
первой встречи с экспертом. На ней присутствуют только интерфейсы с
диаграмм компонент UML и комментарии к ним. На рис. 8.4
представлена заключительная диаграмма, получившаяся в итоге
многочисленных итераций. На ней присутвуют мнгочисленные
компоненты системы, сгруппированные по уровням


а гпемм

Г .>1А*),Пв'Ц1Юнно,Ми

з/ос

Для pezionpauuu

JUiS1

Дгъ управления

Для одмовре*<еннсг?
хелате зпеанич
GCrtCat)
ресурса

_______________«

Для завершения
и ес№ени."

CPS П> И
яеееса

Д’-* ^правления
P&M’HNhblM

лазнь,гч)фоно1.|

Управление
прли^ыеанием
плей-Л1>агв

Рис. 8.3. Пример исходной, первой диаграммы.

fins аоспрызее^еьи*
меЗиа-мапериалов

Для имгефэции
еи^еосереера и ..
приложении
Рис. 8.4. Пример итоговой диаграммы.

Карты памяти

Карты памяти (Mind Maps) - техника работы с различными знаниями,
предложенная и развитая английским психологом Тони Ььюзеном в
конце 70-х годов прошлого века. Она очень простая и используется при
работе с информацией любого вида, для ее структурирования,
осмысления, лучшего усвоения и запоминания. На листе бумаги, в
центре, рисуется объект, обозначающий ту тему или предмет, который
мы рассматриваем. Далее рисуются вторичные объекты, которые
поясняют и уточняют данный и соединяются с ним дугами. И так далее.
Д.В. Кознов

Пример представлен на рис, 8.5.

Рис. 8.5.

Дизайн идей. Карты памяти позволяют выполнить "дизайн идей".
Очень часто мы, как следует не подумав, начинаем что-то делать -
писать большой текст, с кем-то встречаться, кем-то руководить и пр. И
оказывается, что понимание по жду дела возникает труцно и
мучительно. Более того, мы вынуждены переделывать то, что уже
сделали без этого понимания. Хорошая иллюстрация - работа над
текстом (диплома, курсовой работы, статьи, книги и пр.). Кардинально
переделывать текст очень тяжело. А если при этом соавторов
несколько? Карты памяти здесь очень жрошо работают, так как
позволяют в компактном виде делать пробы и ошибки, видя всю
картину перед собой. Ее легко также обсуждать в таком виде с другими
людьми. Но здесь не нужно фанатизма. Можно и написать текст, если
он легко "выливается" из вас. И снова вернуться к схеме - многое на ней
может проясниться.

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

Yfj UHL Farrar *	 КкЬмИ Pi—

mm

Ноли Crwte I FrwrtakMi Atbatxad Ормяа

J

•»

4M«



едяхяя



tcaiMnMi

О Who are you?

« You primary projects
tr« эег<е-<»0< * e*» ." ®

Not exactly UML Kist
diffirtent diagrams

Don't like drawing and
don't draw much, but look
at other people drawings

Hew often’

MOW COftKMHM?

Quiz to check UML
usagc/c«pertencc _ .

0 Are you using UMI ?

Ym, I am using UMI

AS A	ItAQtJAQ*

O' DnvniilrnnwIIMI?

Рис. 8.G.

Too»a
OMr#'

No, I am not using UML^

No, but i am using ocner
modelling languages

Mine) map
S*CT

«<



ц.<0о

Реструктуризация. Карты памяти полезны при реструктуризации
знаний. Например, при реструктуризации статьи. У нас был случай,
когда результаты были получены, материал собран и изложен, но
достаточно хаотично. Мы выполнили реструктуризацию статьи с
помощью карт памяти (модель представлена на рис. 8.7) и по этой
модели быстро переписали текст. Исправления прямо по тексту
затянули бы весь процесс. Кроме того, карты памяти позволили
разделить работу между соавторами - один создал новый план, а
второй его реализовал в новой версии текста.
Введение

О Обзор .

Разработке документации
как самостоятельная задача

Контекст

Средстве разработки
докучг—'Тифьи

Семейства программная
3 1раяуктоа

Конференц» по
их «Ратке дочумен-ации

О DOCLine ялык/твдксс/туг

О чем стат ья

Семейства программных
продуктов

ИС1ЙЫМ
Определен™

Виды активов
Про jeer разработки

Средства разработки повторно
используемой документации

ЭосВоок

ГИТА

С FramMaker

Используемы» подходы

фреймы Бассет»
feature angrarrs
OSM. Eclipse GMT

Decide

г Язык

О

Выводы

„ схема

Обзор
е> DRUGF.bDQLFfl

ДАЯ1рамна аеыеАг! ва

Проектирование reuse

Диа) рамы» варивтыноста
t Анаграмма Геродот?

Семен1 ические связи

Реализация reuse

КэмаыЬ hj ПЗДПО.ГГв в' - тзалнзчу
аСдзиу!

Алдгтацип для блочного reuse

д мемозернистый n&ee

ддся лация для
мелкозернистого reuse

Реализация докумен! ации

Идеальный (тяжеловесный)

Рефак Горинг „

-<5

Графический редактор

Текстовый редактор

О Инструментальные средства _ Rourrttrp

Публикации

Диагностика

0 Апробация(видеосервер)

1FMSS II

Biidf одаря GMF вполне иодьемно

Заключение Дальнейшие исслеливания

G (в частности более
серьезная апрооиция>
Рис. 8.7.

Метод реструктуризации широко используется при работе со знаниями,
например, при выявлении и анализе требований. Построить
представление той же информации, но с другой точки зрения - верный
способ найти незамеченные ранее противоречия, '^темные углы",
углубить свое понимание.

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

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

Расскажем про один программный продукт, реализующий карлы памяти
и поддерживающий широкие возможности групповой работы....

ссылка: httpУ/www.comapping.com
Д.В. Кознов	Введение в программную инженерию

MSF

IT решение. Основные принципы MSF. Модель команды: основные
принципы, ролевые кластеры. Масштабирование команды MSF. Модель
процесса. Управление компромиссами.

История и текущий статус

В 90-х годах компания Microsoft, стремясь достичь максимальной отдачи
от реализации заказных IT-решений и в целях улучшения работы с
субподрядчиками обобщила свой опыт по разработке, внедрению,
сопровождению и консалтингу ПО, создав методологию MSF. В 2002
году вышла версия MSF 3.1, состоявшая из пяти документов-руководств:

•	модель процессов {process model),

•	модель команды {team model),

•	модель управления проектами {project management),

•	дисциплина управления рисками (risk management),

•	управление подготовкой (readiness management).

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

Основными новшествами MSF является следующее.

1.	Акцент на внедрении 1Т-решения.

2.	Модели процесса, объединяющая спиральную и водопадную
модели.

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

4.	Техника управления компромиссами.

Ниже мы рассмотрим эти положения более детально.
В 2005 году MSF претерпело значительные изменения. Версия MSF 4.0.
стала составной часть продукта Visual Studio Team System (VSTS) и
разделилась на две ветки - MSF for Agile и MSF tor СММ1. При этом,
если версии до 3.x были именно методологиями (там были изложены
принципы, MSF свободно распространялась в виде Word-документов,
которые были также переведены на русский язык), то теперь MSF
превратилась в шаблоны процесса для VSTS. Эти шаблоны имеют
описание в виде htm/-документов (Word-документов уже нет) и
определяют типы ролей, их ответственности, действия в рамках этих
ответственностей, а также все входные и выходные артефакты этих
деятельностей и другие формализованные атрибуты процесса
разработки. Кроме этого "человеческого’' описания MSF for Agile и MSF
for CMMI имеют ХЛ4Т-настройки, которые позволяют в точности
следовать предложенным выше описаниям, используя VSTS. При этом
на процесс накладываются достаточно жесткие ограничения.
деятельность разработчиков сопровождается набором автоматических
действий - все это задано в шаблонах. Данные шаблоны можно
частично использовать (например, без некоторых ролей), а также
изменять (VSTS предоставляет обширные средства настройки
шаблонов). Версия MSF 4.2 продолжила направление версии MSF 4.0.

Можно считать, что фактически, версии MSF 4.x являются продуктами
другого класса, чем MSF 3.x. MSF 3.x бычи нацелены на разработку
заказных IT-решений, MSF 4.0 - на разработку произвольного ПО.
Формально, документация этих версий не сильно пересекается и
содержит для 3.x в большей степени общие принципы, а для 4.x -
формальные атрибуты в терминах VSTS. В некотором смысле можно
сказать, что MSF 4.x является реализацией MSF 3.x для продукта VSTS.
В этой лекции мы рассмотрим основные принципы MSF. то есть,
фактически, MSF 3.1, а в лекциях, посвященных VSTS будут
рассмотрены MSF for Agile и MSF tor CMMI.

Основные принципы

Перечислим основные принципы MSF.

1.	Единое видение проекта. Успех коллективной работы над
проектом немыслим без наличия у членов проектной группы и
заказчика единого видения (shared vision), т.е. четкого, и, самое
главное, одинакового, понимания целей и задач проекта. Как
проектная группа, так и заказчик изначально имеют собственные
предположения о том, что должно быть достигнуто в ходе работы
над проектом. Лишь наличие единого видения способно внести
ясность и обеспечить движение всех заинтересованных в проекте
сторон к общей цели. Формирование единого видения и
последующее следование ему являются столь важными, что
модель процессов MSF выделяет для этой цели специальную фазу
'Выработка концепции", которая заканчивается
соответствующей вехой.

2.	Гибкость - готовность к переменам. Традиционная дисциплина
управления проектами и каскадная модель исходят из того, что
все требования могут быть четко сформулированы в начале
работы над проектом, и далее они не будут существенно
изменяться. В противоположность этому MSF основывается на
принципе непрерывной изменяемости условий проекта при
неизменной эффективности управленческой деятельности.

3.	Концентрация на бизнес-прииритетах. Независимо от того,
нацелен ли разрабатываемый продукт на организации или
индивидуумов, он должен удовлетворить определенные нужды
потребителей и принести в некоторой форме выгоду или отдачу В
отношении индивидуумов это может означать, например,
эмоциональное удовлетворение - как в случае компьютерных игр.
Что же касается организаций, то неизменным целевым фактором
продукта является бизнес-отдача (business value). Обычно продукт
не может приносить отдачу до того, как он полностью внедрен.
Поэтому модель процессов MSF включает в свой жизненный цикл
не только разработку продукта, но и его внедрение.

4.	Поощрение свободного общения, Исторически многие
организации строили свою деятельность на основе сведения
информированности сотрудников к минимуму, необходимому для
исполнения работы (need-to-know). Зачастую такой подход
приводит к недоразумениям и снижает шансы команды на
достижение успеха. Модель процессов MSF предполагает
открытый и честный обмен информацией как внутри команды, так
и с ключевыми заинтересованными лицами. Свободный обмен
информацией не только сокращает риск возникновения
недоразумений, недопонимания и неоправданных затрат, но и
обеспечивает максимальный вклад всех участников проектной
группы в снижение существующей в проекте неопределенности.
По этой причине модель процессов MSF предлагает проведение
анализа хода работы над проектом в определенных временных
точках. Документирование результатов делает ясным прогресс,
достигнутый в работе над проектом - как для проектной команды,
так и для заказчика и других заинтересованных в проекте сторон.

Модель команды

Основные принципы. Главная особенность модели команды в MSF
является то, что она "п лоская", то есть не имеет официального лидера.
Все отвечают за проект в равной степени, уровень заинтересованности
каждого в результате очень высок, а коммуникации внутри группы
четкие, ясные, дружественные и ответственные. Конечно, далеко не
каждая команда способна так работать - собственно, начальники для
того и нужны, чтобы нести основной груз ответственности за проект и,
во многом, освободить от него других. Демократия в команде возможна
при высоком уровне осознанности и заинтересованности каждого, а
также в ситуации ровности в профессиональном уровне (пусть и в
разных областях - см. различные ролевые кластеры в команде, о
которых речь пойдет ниже). С другой стороны, в реальном проекте, в
рамках данной модели команды, можно варьировать степень
ответственности, в том числе вплоть до выделения, при
необходимости, лидера.

Одной из особенностей отношений внутри команды является высокая
культура дисциплины обязательств:

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

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

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

*	готовность честно и незамедлительно информировать об угрозах
выполнению своих обязательств.

Ролевые кластеры. MSF основан на постулате о семи качественных
целях, достижение которых определяет успешность проекта. Эти цели
обуславливают модель проектной группы и образуют ролевые кластеры
(или просто роли ) в проекте. В каждом ролевом кластере может
присутствовать по одному или несколько специалистов, некоторые роли
можно соединять одному участнику проекта. Каждый ролевой кластер
представляет уникальную точку зрения на проект, и в то же время никто
из членов проектной группы в одиночку не в состоянии успешно
представлять все возможные взгляды, отражающие качественно
различные цели. Для разрешения этой дилеммы команда соратников
(команда равных, team of peers), работающая над проектом, должна
иметь четкую форму отчетности перед заинтересованными сторонами
(stakeholders) при распределенной ответственности за достижение
общего успеха. В MSF следующие ролевые кластеры (часто их
называют ролями) - см. рис. 9.1.

*! ^тге^

Лр) Manager

Piograni
Matiagetiient

Architecture

Рис. 9.1.

Team of
Peers

Developer

 | Release

Manager

• Управление продуктом (product management). Основная задача
этого ролевого кластера - обеспечить, чтобы заказчик остался
довольным в результате выполнения проекта. Этот ролевой
кластер действует по отношению к проектной группе как
представитель заказчика и зачастую формируется из сотрудников
Д.В. Кознов	Введение в программную инженерию

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

•	Управление программой (program management) обеспечивает
управленческие функции - отслеживание планов и их
выполнение, ответственность за бюджет, ресурсы проекта,
разрешение проблем и трудностей процесса, создание условий,
при которых команда может работать эффективно, испытывая
минимум бюрократических преград.

•	Разработка (development). Этот ролевой кластер занимается,
собственно, программированием ПО.

•	Тестирование (test) - отвечает за тестирование ПО.

•	Удовлетворение потребителя (user experience). Дизайн удобного
пользовательского интерфейса и обеспечение удобства
эксплуатации ПО (эргономики), обучение пользователей работе с
ПО, создание пользовательской документации.

•	Управление выпуском (release management). Непосредственно
ответственен за беспрепятственное внедрение проекта и его
функционирование, берет на себя связь между разработкой
решения, его внедрением и последующим сопровождением,
обеспечивая информированность членов проектной группы о
последствиях их решении.

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

Масштабирование команды MSF. Наличие 7 ролевых кластеров не
означает, что команда должна состоять строго из 7 человек. Один
сотрудник может объединять нескотько ролей. При этом некоторые
роли нельзя объединять. В таблице ниже представлены рекомендации
MSF относительно совмещения ролей в рамках одним членом команды.
"+" означает, что совмещение возможно, "+-" - что совмещение
возможно, но нежелательно, означает, что совмещение не
рекомендуется.
Д.В. Кознов  Управление Управление продуктом программой  Управление  продуктом  Управление программой  Разработка	-	-	Введение в программную инженерию Разработка Тестирование ЭДов потр  -	+	+  -	+-	+-
Тестирование +	+-  Удовлетворение потребителя Управление выпуском Архитектура -	+	- +  - +  - + +-  + +- +-

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

Модель проектной группы MSF предлагает разбиение больших команд
(более 10 человек) на малые многопрофильные группы направлений
(feature teams). Эти малые коллективы работают параллельно, регулярно
синхронизируя свои усилия, каждая из которых устроена на основе
модели кластеров. Это компактные мини-команды, образующие
матричную организационную структуру В них входят по одному или
несколько членов из разных ролевых кластеров. Такие команды имеют
четко определенную задачу и ответственны за все относящиеся к ней
вопросы, начиная от проектирования и составления календарного
графика. Например, может быть сформирована специальная группа
проектирования и разработки сервисов печати.

Кроме того, когда ролевому кластеру требуется много ресурсов,
формируются так называемые функциональные группы (functional teams),
которые затем объединяются в ролевые кластеры. Они создаются в
больших проектах, когда необходимо сгруппировать работников внутри
ролевых кластеров по их областям компетенции. Например, в
Майкрософт группа управления продуктом обычно включает
специалистов по планированию продукта и специалистов по
маркетингу Как первая, так и вторая сферы деятельности относятся к
управлению продуктом: одна из них сосредотачивается на выявлении
качеств продукта, действительно интересующих заказчика, а вторая - на
информировании потенциальных потребителей о преимуществах
продукта.

Аналогично, в команде разработчиков возможна группировка
сотрудников в соответствии с назначением разрабатываемых ими
модулей: интерфейс пользователя, бизнес-логика или объекты данных.
Часто программистов разделяют на разработчиков библиотек и
разработчиков решения. Программисты библиотек обычно используют
низкоуровневый язык С и создают повторно используемые компоненты,
которые могут пригодиться всему предприятию. Создатели же решения
обычно соединяют эти компоненты и работают с языками более
высокого уровня, такими как, например Microsoft Visual Basic.

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

Прочие особенности

Модель процесса

Водопадная модель - фазы работ и вехи
Рис. 9.2.

Спиральная модель - постоянное уточнение требований, активное
взаимодействие с заказчиком.

Рис. 9.3.

В MSF объединяются водопадная и спиральная модели: сохраняются
преимущества упорядоченности водопадной модели, не теряя при этом
гибкости и творческой ориентации модели спиральной.
Рис. 9.4.

Итак, процесс MSF ориентирован на "вехи" (milestones) - ключевые
точки проекта, характеризующие достижение в его рамках какого-либо
существенного (промежуточного либо конечного) результата. Этот
результат может быть оценен и проанализирован, что подразумевает
ответы на вопросы: "Пришла ли проектная группа к однозначному
пониманию целей и рамок проекта?", 'В достаточной ли степени готов
план действий?", "Соответствует ли продукт утвержденной
спецификации?", "Удовлетворяет ли решение нужды заказчика?" и т.д. Л
между вехами - итерации, итерации, итерации....

Управление компромиссами. Хорошо известна взаимозависимость
между ресурсами проекта (людскими и финансовыми), его календарным
графиком (временем) и реализуемыми возможностями (рамками). Эти
три переменные образуют треугольник, показанный на рис. 9.5.
Возможности

Рис. 9.5.

После достижения равновесия в этом треугольнике изменение на
любой из его сторон для поддержания баланса требует модификаций на
другой (двух других) сторонах и/и ли на изначально измененной
стороне.
ВОиМОЖНОСТИ

i вы Прививается



Рис. 9.6.

Зафиксировав	, мы согласовываем

принимаем результирующий

и

Этот ролевой кластер появился в версиях MSF 4.x. До этого данная
ответственность входила в ролевой кластер "Управление программой".
Д.В. Кознов	Введение в программную инженерию

CMMI

Понятие CMMI. Уровни зрелости процессов по CMMI. Области
усовершенствования.

Что такое CMMI?

СММ1 является некоторым описанием идеального процесса разработки
ПО, предлагает некоторую модель процесса. То есть в процессе
выделяются и тщательно описываются некоторые составные части,
ключевые с точки зрения CMMI. Эта точка зрения СММ1 -
совершенствование процессов разработки. То есть эти значимые части
процесса - области усовершенствования. В СММ1 различаются
следующие группы областей усовершенствования, управление
процессами, управление проектами, инженерные области, служебные
области. При этом все области задаются в виде требований,
определяющих не то, как они реализованы, а интерфейсные требования
Из этого имеется два следствия.

Следствие 1. CMMI допускает различные реализации и не является
методологией разработки ПО, подобно MSF, Scrum, RUP и пр.
Последние могут использоваться в его реализации. Так, существует,
например, специальный шаблон процесса в VSTS для CMMI под
названием MSF tor CMMI.

Следствие 2. CMMI используется для сертификации компаний на
зрелость их процессов. Изначально, в конце 80-х начале 90-х годов.
СММ (тогда еще не СММГ) создавался именно как средство
сертификации федеральных субподрядчиков. И только позднее, получив
широкое распространение в мире, он начал использоваться, а после и
ориентироваться на совершенствование процессов.

Отметим еще одну важную характеристику СММ1. Он предназначен не
только для разработки программных систем. Многие крупные компании
выпускают не ПО, а целевые изделия, куда ПО входит как составная
часть. Например, авиационная, аэрокосмическая индустрии. То есть
разработка ПО происходит вместе с инженерными работами иных
видов. И часто бывает, что в одном проекте участвует более двух
различных видов инженерии. Задача СММ1 - предоставить таким
Д.В. Кознов	Введение в программную инженерию

проектам и компаниям единую платформу организации процесса
разработки.

Уровни зрелости процессов по CMMI

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

Налажена процедура постоянной, неуклонной
самоогтимизации процессов в компании

о п ти м изиру ющи йся

Управление процессами основывается на
численном, количественном подходе

управляемый количественно

1 Процесса определены на уровне проектов
Зачастую процессы появляются в ответ на
определенные события

g Процессы определены на уровне проектов.
Зачастую процессы появляются в ответ на
определенные события

1 Процессы непредсказуемы, слабо
контролируемы, появляются в ответ на
определенные события

определенный

управляемый

начальный

Рис. 10.1.

Начальный уровень (уровень зрелости 1) - это уровень, на котором, по
определению, находится любая компания. На этом уровне разработка
НО ведется более-менее хаотично.

Управляемый уровень (уровень зрелости 2) - здесь уже появляются
политики и процедуры организации процессов, утвержденные на
уровне компании. Но в полной мере процессы существуют лишь в
рамках отдельных проектов.

Определенный уровень (уровень зрелости 3) - здесь появляется
стандартный процесс на уровне всей кампании в целом. Это большой и
Д.В. Кознов	Введение в программную инженерию

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

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

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

Области усовершенствования

Уровень зрелости	Области усовершенствования  Управление требованиями  Планирование проекта  Наблюдение за проектом и контроль
Уровень зрелости 2	Управление договоренностями с поставщиком  Измерения и анализ  Проверка процессов и продуктов на соответствие стандартам  Конфигурационное управление  Разработка требований  Техническое решение  Сборка и поставка продукта  Проверка продукта на соответствие требованиям (верификация)  Проверка продукта на соответствие предназначению
	(валидация)
Уровень зрелости 3	Фокусирование на процессах организации  Определение процессов организации  Организация обучения  Комплексное управление проектом  Управление рисками  Управление объединенной командой  Комплексное управление работой с поставщиком  Принятие решений: оценка альтернатив  Создание в организации условий для совместной работы  Установление показателей выполнения процессов
Уровень зрелости 4	организации  Управление проектами на основе количественных показателей
Уровень зрелости 5	Отбор и внедрение улучшений в организацию Анализ причин возникновения проблем и предотвращение их появления в будущем
Д.В. Кознов	Введение в программную инженерию

"Гибкие" (agile) методы разработки

Общее описание "гибких" методов разработки ПО. Extreme Progamming:
общее описание, основные принципы организации процесса. Scrum:
общее описание, роли, практики.

Общее

'Гибкие" (agile) методы разработки ПО появились как альтернатива
формальным и 'Тяжеловесным" методологиям, наподобие СММ и RUP.
Талантливые программисты не желают превращения разработки ПО в
рутину, хотят иметь максимум свобод и обещают взамен высокую
эффективность. С другой стороны, практика показывает, что
'Тяжеловесные" методологии в значительном количестве случаев
неэффективны. Основными положениями гибких методов,
закрепленных в Agile Manifesto в 2007 году являются следующее^-*:

•	индивидуалы и взаимодействие вместо процессов и программных
средств;

•	работающее ПО вместо сложной документации;

•	взаимодействие с заказчиком вместо жестких контрактов;

•	реакция на изменения вместо следования плану

Фактически, гибкие методологии говорят о небольших,
самоорганизующихся	командах,	состоящих	из

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

Extreme Programming

Самым известным гибким методом является Extreme Progiamming
(известное сокращенное название - ХР). Он был создан талантливым
специалистом в области программной инженерии Кентом Беком в
результате его работы в 1996-1999 годах над системой контроля
платежей компании 'Крайслер".
Модель процесса по ХР выглядит как частая последовательность
выпусков (releases) продукта, столь частых, сколь это возможно. Но при
этом обязательно, чтобы в выпуск входила новая целиковая
функциональность. Ниже перечислены основные принципы
организации процесса по ХР.

1.	Планирование (Planning Game), основанное на принципе, что
разработка ПО является диалогом между возможностями и
желаниями, при этом изменятся и то и другое.

2.	Простой дизайн (Simple Design) - против избыточного
проектирования.

3.	Метафора (Metaphor) - суть проекта должна умещаться в 1-2 емких
фразах или в некотором образе.

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

5.	Парное программирование (Pair Programming) - один
программирует, другой думает над подходом в целом, о новых
тестах, об упрощении структуры программы и т.д.

6.	Коллективное владение кодом (Collective Ownership).

7.	Участие заказчика в разработке (On-site Customer) - представитель
заказчика входит в команду разработчика.

8.	Создание и использование стандартов кодирования (Coding
Standards) в проекте - при написании кода (создаются и)
используются стандарты на имена идентификаторов, составление
комментариев и т.д.

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

10.	Непрерывная интеграция. Сама разработка представляется как
последовательность выпусков.

И. 40-часовая рабочая неделя.

Однако в полном объеме ХР не была использована даже ее авторами и
является, скорее, философией. Кроме того, известны и внедряются
отдельные практики ХР, как, например, парное программирование,
коллективное владение кодом, и, конечно же, рефакторинг кода. Идея
простого, неизбыточного дизайна проекта также оказала значительное
Д.В. Кознов

влияние на мир разработчиков ПО.

Более практичным "гибким" методом разработки является Scrum.

Scrum

История. В 1986 японские специалисты Hirotaka Takeuchi и Jkujiro
Nonaka опубликовали сообщение о новом подходе к разработке новых
сервисов и продуктов (не обязательно программных). Основу подхода
составляла сплоченная работа небольшой универсальной команды,
которая разрабатывает проект на всех фазах. Приводилась аналогия из
регби, где вся команда двигается к воротам противника как единое
целое, передавая (пасуя) мяч своим игрокам как вперед, так и назад. В
начале 90-х годов данный подход стал применяться в программной
индустрии и обрел название Scium (термин из регби, означающий -
схватка), в 1995 году Jeff Sutherland и Ken Schwaber представили
описание этого подхода на OOPSLA'95 - одной из самых авторитетных
конференций в области программирования С тех пор метод активно
используется в индустрии и многократно описан в литературе. Scrum
активно используется также в России.

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

Создание
требований к
Продукту

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

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

Роли. В Scrum есть всего три вида ролей.

Владелец продукта (Product Owner) - это менеджер проекта, который
представляет в проекте интересы заказчика. В его обязанности входит
разработка начальных требований к продукту (Product Backlog),
своевременное их изменение, назначение приоритетов, дат поставки и
пр. Важно, что он совершенно не участвует в выполнении самой
итерации.

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

Scrum-команда (Scniro Team) - группа, состоящая из пяти-девяти
самостоятельных, инициативных программистов. Первой задачей
команды является постановка для итерации реально достижимых и
приоритетных для проекта в целом задач (на основе Project Backlog и
при активном участии владельца продукта и Scnim-мастера). Второй
задачей является выполнение этой задачи во что бы то ни стало, в
отведенные сроки и с заявленным качеством. Важно, что команда сама
in
Д.В. Кознов	Введение в программную инженерию

участвует в постановке задачи и сама же ее выполняет. Здесь сочетается
свобода и ответственность, подобно тому, как это организовано в MSF.
Здесь же "просвечивает" дисциплина обязательств.

Практики. В Scrum определены следующие практики.

Sprint Planning Meeting. Проводится в начале каждого Sprint Сначала
Product Owner, Scrum-мастер, команда, а также представители заказчика
и пр. заинтересованные лица определяют, какие требования из Project
Backlog наиболее приоритетные и их следует реализовывать в рамках
данного Sprint. Формируется Sprint Backlog. Далее Scrum-мастер и Scrum-
команда определяют то, как именно будут достигнуты определенные
выше цели из Sprint Backlog. Для каждого элемента Sprint Backlog
определяет ся список задач и оценивается их трудоемкость.

Daily Scrum Meeting - пятнадцатиминутное каждодневное совещание,
целью которого является достичь понимания того, что произошло со
времени предыдущего совещания, скорректировать рабочий план
сообразно реалиям сегодняшнего дня и обозначить пути решения
существующих проблем. Каждый участник Scium-ко.манды отвечает на
три вопроса: что я сделал со времени предыдущей встречи, мои
проблемы, что я буду делать до следующей встречи? В этом совещании
может принимать участие любое заинтересованное лицо, но только
участники Scrum-команды имеют право принимать решения. Правило
обосновано тем, что они давали обязательство реализовать цель
итерации, и только это дает уверенность в том, что она будет
достигнута. На них лежит ответственность за их собственные слова, и,
если кто-то со стороны вмешивается и принимает решения за них, тем
самым он снимает ответственность за результат с участников команды.
Такие встречи поддерживают дисциплину обязательств в Scrum-
команде, способствуют удержанию фокуса на целях итерации, помогают
решать проблемы "в зародыше". Обычно такие совещания проводятся
стоя, в течение 15-20 минут.

Sprint Review Meeting. Проводится в конце каждого Sprint. Сначала Scrum-
команда демонстрирует Product Owner сделанную в течение Sprint
работу а тот в свою очередь ведет эту часть митинга и может
пригласить к участию всех заинтересованных представителей заказчика.
Product Owner определяет, какие требования из Sprint Backlog были
выполнены, и обсуждает с командой и заказчиками, как лучше
расставить приоритеты в Sprint Backlog для следующей итерации. Во
второй части митинга производится анализ прошедшего спринта,
который ведет Scrurn-мастер. Scrum-команда анализирует в последнем
Sprint положительные и отрицательные моменты совместной работы,
делает выводы и принимает важные для дальнейшей работы решения,
Scrum-команда также ищет пути для увеличения эффективности
дальнейшей работы. Затем цикл повторяется.

С оздание
Project
Backlog

Рис. 11.2.

Не надо понимать эти положения Agile Manifesto буквально так, что
любая гибкая методология им в точности удовлетворяет. Agile Manifesto
лишь оконтуривает некоторое пространство, обозначает определенное
явление. Отдельные части этого явления - конкретные гибкие
методологии могут иметь разную специфику, могут также являться
пограничными объектами.
Д.В. Кознов	Введение в программную инженерию

Обзор технологии Microsoft Visual Studio Team System
(VSTS)

Состав продукта: обзор, клиентская часть VSTS, серверная часть VSTS.

Правила инсталляции. Пакет Team Explorer.

Обзор

Анализируя собственный опыт разработки программного обеспечения, а
также опыт других компаний, специалисты Microsoft пришли к выводу,
что существенная часть проблем, возникающих при разработке
программного обеспечения, вызвана "человеческим фактором” -
взаимодействием различных специалистов в рамках одной команды.
Это люди разного возраста, разного образования, разных жизненных
принципов и интересов, решающие различные задачи и преследующие
различные цели (хотя одна общая цель у них все же есть - сделать в
конечном итоге качественное ПО), вынужденные работать вместе
волею судьбы или начальства. Не удивительно, что при их
взаимодействии часто возникают накладки и недопонимания, а
истинно слаженные и эффективные команды встречаются не так часто,
как хотелось бы. Для решения этой задачи корпорацией Microsoft
предлагается комплекс Visual Studio Team System (VSTS), который
обеспечивает следующее.

•	'Навязывание'1 процесса разработки. Инструменты VSTS
позволяют задать процесс, который используется в проекте (то
есть создать конкретный процесс, пользуясь нашей
терминологией), и тем самым ограничить действия участников
команды.

•	Доступное описание процесса. VSTS предполагает доступное
описание процесса разработки.

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

Ядром VSTS является средства обеспечения жизненного цикла
Д.В. Кознов	Введение в программную инженерию

элементов работы (work items) - некоторых дискретных характеристик
проекта, вокруг которых организуется вся работа команды (см. рис.
12.1). Вот примеры элементов работ:

*	task - конкретная задача, которую необходимо выполнить в
проекте;

•	bug - ошибка, которая найдена, ждет своего исправления,
исправляется, заново проверяется;

•	risk - риск проекта, у которого тоже может быть разное состояние;
как правило, за рисками их состояниями следят менеджеры
проектов.

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

Кроме поддержки жизненного цикла элементов работы в VS'IS входят
дополнительные средства - контроля версий, поддержки сборки,
средства интеграции с офисными приложениями (Project, Excel, Word),
генераторы различных отчетов, средства тестирования и нек. др.
Кроме того, через открытый программный интерфейс VSTS можно
надстраивать и другим сервисами, необходимыми в процессе
разработки. На рис. . эти возможные сервисы представлены пустыми
кубиками, подобно алтарям неизвестным богам в одном древнем
святилище.
Рис. 12.1.

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

Состав продукта

Обзор. Теперь посмотрим на VSTS как на программный продукт. Он
является сложным, составным продуктом и разделяется на клиентское
ПО и серверное ПО - см. рис. 12.2.
Рис. 12.2. Архитектура VSTS

Рассмотрим подробнее клиентскую часть. Стандартным клиентом от
компании Microsoft является продукт Visual Studio Team Suite Edition.
Этот продукт яв ляется одной из редакций среды разработки Visual Studio
с дополнительным продуктом - Team Explorer. Последний служит для
доступа к сервисам серверной части VSTS и встраивается в Visual
Studio. Кроме того, благодаря открытому программному интерфейсу к
серверной части VSTS - библиотеки TFS Client API - она интегрируется
с различными средами разработки, например, с Eclipse. Также
существует значительное количество различных клиентских продуктов
Д.В. Кознов	Введение в программную инженерию

от сторонних производителей (наиболее успешные из которых Microsoft
пытается ассимилировать)^.

Серверная часть VSTS состоит из US (Team Foundation Server) -
главной серверной компоненты, - а также компоненты Build Agent. TFS
реализует главную функциональность серверной части и использует два
других серверных продукта Microsoft - Share Point (для организации
Web-портала с описанием используемого шаблона процесса
разработки, других документов по процессу) и SQL Server (для хранения
данных TFS). Build Agent - это серверная компонента, которая отвечает
за выполнение сборок проектов. Вынесение сервера сборки в отдельное
серверное приложение позволяет убрать процесс сборки с основной,
серверной машины, где размещен TFS, на дополнительную машину,
отвечающую именно за приведение сборок. Подобное разделение
позволяет значительно снизить нагрузку на основной сервер, особенно
в случае использования подхода непрерывной интеграции-'.

Остановимся на клиентской и серверной частях VSTS более подробно.

Клиентская часть VSTS. Остановимся на стандартном клиентском ПО,
основанном на среде разработки Visual Studio. Последняя выпускается в
нескольких комплектациях (editions'), ориентированных на разных
пользователей. При этом издания, включающие инструменты комплекса
VSTS имеют в своем названии слово "Team". Вот перечень этих
изданий.

•	Microsoft Visual Studio Team System 2008 Architecture Edition
расширен средствами управления повторным использованием,
средствами визуального моделирования с генераторами
конечного кода и нек. др. возможностями.

•	Microsoft Visual Studio Team System 2008 Development EdiUon
предоставление средств анализа кода с целью повышения его
качества, в частности, выявление сложного, трудного в
обслуживании путем оценки отношений между классами,
глубины наследования, цикломагической сложности, строк кода и
индекса удобства обепуживания. Сюда же входят различные
средства профиляции приложений.

•	Microsoft Visual Studio Team System 2008 Database Edition включает в
себя средства управление версиями всех основных объектов баз
Д.В. Кознов	Введение в программную инженерию

данных, модульного тестированиея баз данных, средства
поддержки эволюции схем, поддержка синтаксиса SQL и многое
другое.

•	Microsoft Visual Studio Team System 2008 Test Edition предоставляет
полный набор средств тестирования Web-приложсний и Web-
сервисов, интегрированный в среду Visual Studio. С помощью
данных средств тестеровщики могут создавать, выполнять и
управлять тестами и связанными с ними элементами работ VSTS
непосредственно из среды Visual Studio. В это же издание входят
средства нагрузочного тестирования, управления тестовыми
пакетами и другие возможности.

Помимо четырех "ролевых" изданий, выпускается и издание,
объединяющее функции всех четырех блоков - Microsoft Visual Studio
Team System 2008 Team Suite. Условно взаимосвязь различных изданий
отражена на рис. 12.3.

Edition for

Database
Piofessionals

Ed.tion for
Software
Deveiopers

Edition for
Software
Testers

Edit on tor
Software
Architects

Team Edition Cere

Visual Studio
Professional

Team Explorer

Рис. 12.3. Схема Microsoft Visual Studio Team System 2008 Team Suite

Каждое их четырех "ролевых" изданий серии VS TS расширяет ядро
(Team Edition Core) дополнительными инструментами,
предназначенными для определенной роли (разработчик, тестер,
архитектор или специалист по базам данных), а издание Team Suite
является объединением всех четырех "ролевых" изданий.
Ядро состоит из базовой конфигурации Visual Studio - Visual Studio
Professional,- которая является наиболее распространенным изданием
среды Visual Studio и повсеместно используется для разработки
программного обеспечения. Она дополняется Team Explorer,
предназначенным для интеграции с IT S.

Серверная часть VSTS. Итак, ядром комплекса инструментов VSTS
является TFS, который не яв ляется целостной системой, а представляет
из себя набор стандартных продуктов (в частности, SQL Server и Share
Point), соответствующим образом настроенных и объединенных в
единое целое посредством прослойки Web-сервисов. Архитектура
серверной части VSTS представлена на рис. 12.4, где серыми
прямоугольниками показаны компоненты VSTS, а белыми - компоненты
других продуктов Microsoft. На этом же рисунке схематично обозначена
и клиентская часть VSTS.
Рис. 12.4. Архитектура серверной части VSTS

TFS, основная серверная подсистема VSTS, состоит из двух основных
уровней: уровня приложений и уровня данных. Уровень приложений
TFS включает в себя следующие компоненты.

•	SQL Server Analysis & Reporting - компонента пакета SQL Server,
используемая TFS для построения отчетов анализа статуса
проектов Доступ к этой компоненте с клиентской стороны
осуществляется не через компоненту TFS Client API, а напрямую,
средствами Web-браузера.

•	SharePoint Services - компоненты из пакета Share Point,
Д.В. Кознов	Введение в программную инженерию

используется для хранения общедоступной информации и
описания используемого процесса разработки. Доступ к этой
компоненте с клиентской стороны осуществляется не через TFS
Client API, а напрямую, средствами Web-браузера.

•	Share Point Extensions for TFS - расширение Share Point для TFS,
которое обеспечивает доступ к отчетам и некоторым функция TFS
непосредственно с Web-портала.

•	Team Foundation Server - главная компонента TFS, которая состоит
из набора Web-сервисов, доступных через TFS Client API
клиентскому ПО и реализующих основные сервисные функции
TFS, в частности:

' версионный контроль,

° управление элементами работы,
о работам с шаблонами процесса,
о администрирование и т.д.

•	Team Foundauon Build Service в составе TFS - предназначена для
инициации процесса сборки и передачи соответствующего задания
компоненте Budd Agent. Другой экземпляр этого приложения
находится в Build Agent и выполняет там системные функции.

Уровень приложений реализован на технологии ASP.NET и работает
под управлением IIS (Internet Infromauon Service). I1S является Web-
сервером, то есть средой для работы Web-сервисов TFS, обеспечивая
доступ к функциональности сервера VSTS со стороны его клиентов.

Уровень данных состоит из набора баз данных, где TFS хранит свои
данные. Он реализован на основе продуктов MS SQL Server и Share
Point.

В зависимости от размера компании-разработчика ПО и
предполагаемой нагрузки эти два уровня TFS могут быть установлены
на одном сервере (single-server deployment) или на двух разных серверах
(dual-server deployment). Для очень больших компаний возможно
использование механизмов кластеризации, встроенных в Microsoft SQL
Server и Internet Information Server^.

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

Framework, с помощью стандартной утилиты этого пакета MSBuild,
которая, получив задание на сборку, вызывает соответствующий
компилятор из .NET Framework. Этот же механизм используется и для
сборки проекта, запущенной из Visual Studio.

В случае Build Agent выполнение сборки происходит по следующему
сценарию. Компонента TFS Build Service в составе TFS сообщает такой
же компоненте на компьютере, где расположен Build Agent, что надо
запустить выполнение сборки. А та, в свою очередь, являясь
системным сервисом и будучи запущенной, оказывается тем процессом
Windows, в рамках которого и будет происходит выполнение сборки под
управлением компоненты MSBuild. При этом всю связь с TFS для
выполнения сценария сборки осуществляет компонента Custom tasks. В
сценарии сборки указывается, откуда нужно брать исходные тексты
собираемого приложения, откуда брать регрессионные тесты и как их
запускать, как создавать отчеты по результатам сборок и т.д.

Правила инсталляции

Клиентская часть устанавливается легки, либо как расширению
существующей установки Visual Studio, либо на чистую машину (в этом
случае базовая инфраструктура Visual Studio будет установлена
автоматически). Основная работа при установке VSTS - развертка
серверной части, то есть IT'S. В версии 2008-го года установка TFS
значительно улучшена и упрощена по сравнению с версией 2005-го
года, однако, требования на программное окружение по-прежнему
достаточно жесткие:

•	Microsoft Windows Server 2003 или 200В.

•	Microsoft SQL Server 2005 или 2008^.

•	Internet Information Server 6 (для Windows Server 2003) или 7 (для
Windows Server 2008).

•	Active Directory Domain 5.0 или 2003 (TFS не работает с доменом
4.0). Важно отметить, что нормальное использование TTS вне
домена наладить достаточно сложно - для этого приходится
использовать технологию VPN или Web-клиента, что ведет к
существенному увеличению затрат на администрирования и
накладных расходов при работе.
Д.В. Кознов	Введение в программную инженерию

•	SharePoint Server 3.0 или Microsoft Office SharePoint Server 2007.

При обновлении c TFS 2005 можно остаться на Windows
SharePoint Server 2.0.

Пакет Team Explorer

Данный пакет является самым распространенным клиентским
приложением VSTS. Он встраивается в среду Visual Studio в виде
плавающего окна, а также ряда диалоговых окон и окон-документов. Его
внешний вид представлен на рис. 12.5.
з--- 1

_____л

Рис. 12.5. Внешний вид Team Explorer

Основное дерево Team Explorer содержит:

•	список доступных TFS-серверов, (1); каждый такой сервер
является экземпляром серверной части Team System и, как
правило, располагается на отдельном компьютере-^ ;

•	список доступных проектов для каждого из подключенных
Д.В. Кознов	Введение в программную инженерию

серверов (2);

*	панели инструментов инструментального окна для того, чтобы
подключить/добавить в TFS новый проект (3).

Для каждого из проектов в дереве Team Explorer отображается
следующая информация.

•	Список элементов работы (Work Items) проекта, то есть всех тех
дискретных элементов работы в проекте, которые создают
менеджеры и другие участники проекта для того, чтобы ни о чем
не забыть, а также для коммуникации друг с другом.

•	Список доступных документов (Documents). В этом списке
отображаются документы, хранящиеся на портале проекта. Как,
правило, это нормативные или вспомогательные документы, не
требующие хранения в системе контроля версий.

•	Список доступных отчетов (Reports). В этом списке
представлены доступные для проекта отчеты Результат
выполнения отчета открывается в отдельном окне документе.

•	Список сборок (Builds) проекта - описаний и результатов.

•	Система контроля версий (Source Control). Позволяет получить
доступ к версионному репозиторию с основными артефактами
проекта (открывается в отдельном окне-документе).

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

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

•	поменять настройки сервера или проекта;

•	создать/удалить/изменить запрос на элементы работы;

•	создать/удалить/изменить отчет;

•	создать/уцалить/изменить/запустить процесс сборки;

•	создать/изменить/уцалить документ;

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

Более подробную информацию о различных расширениях и
дополнениях к TFS можно получить на следующих сайтах: ссылка:
httpy/blogs.msdn.c от/mrod/archive/2008/04/28/extemal-team-foundation-
Д.В. Кознов	Введение в программную инженерию

servertools.aspx, ссылка: http v/teamsystemrocks.com.

Выделение Build Agent из TFS является iiin-r/me взглядом.
Структурно, как продукт, TFS включает в себя серверные средства
сборки.

Подобная распределенная архитектура накладывает серьезное
ограничение на схему развертывания TFS - нормальной его работы
можно добиться только в сети с доменом Active Directory.
Использование TFS в других условиях возможно, но сопряжено с
дополнительной существенной нагрузкой по развертыванию и
администрированию.

4)	Установку SQL сервера необходимо производить строго в
соответствии с инструкцией для TFS.

5)	Исключение - это когда инсталляция TFS является кластерной и
развертывается на нескольких компьютерах.
Д.В. Кознов	Введение в программную инженерию

VSTS: управление элементами работ (Work Items)

Опредетение, свойства, жизненный цикл. Реквизиты Средства
использования (на примере элемента работы task). Доступ к элементам
работы. Элементы работы при планировании Элементы работы в
дальнейшей разработке. Элементы работы в отчетах.

Определение, свойства, жизненный цикл

Обзор. Вернемся к элементам работ VSTS - ключевым дискретным
характеристикам проекта, таким как задача (task), ошибка (bug), риск
(risk) и т.д. Эти характеристики выделены в VSTS с целью
конкретизировать объекты управления в проекте, сделать это
управление сквозным в следующих смыслах:

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

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

Благодаря единой среде, включающей в себя средства поддержки
различных видов элементов работы, в VSTS гораздо проще строить
связи между элементами работы различного вида, отслеживать их
изменения, чем при использовании отдельных продуктов поддержания
процесса. Например, не нужно ждать момента, пока информация об
ошибке или задаче будет перенесена из одной системы в другую. Ведь
традиционно программные средства планирования (там, где
определяются задачи), управления ошибками (там, где происходит учет
ошибок), средства версионного контроля - это разные средства. Кроме
того, в силу наличия единого информационного репозитория в VSTS
возможны строгие ссылки на такие объекты, определенная сборка или
тест, и получение, по соответствующему запросу, подробной
информации по разным фильтрам, на разную глубину детализации
Возможно также настроить автоматическую генерацию элементов
работы, например, ошибок при неудачной автоматической сборке или
при автоматическом прогоне тестов.
Рис. 13.1.

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

Реквизиты. Каждый элемент работы принадлежит определенному типу.
Тип элемента работы определяет набор реквизитов, для каждого из
которых можно задать:

•	имя, отображаемое в отчетах и пользовательским интерфейсе
TFS;

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

•	тип - один из предопределенных типов для реквизитов: date, int,
Д.В. Кознов	Введение в программную инженерию

siring, bool; типы могут системными, то есть являться ссылками в
одно из типовых хранилищ TFS; например, тип build results
указывает на информацию о результатах сборки;

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

•	режим использования в отчетах - можно ли использовать этот
реквизит в отчетих и какого следует использовать.

Бывают также системные реквизиты, имена, типы и обработка которых
'прошита'1 в TFS. Это, например, такие реквизиты как состояние (state),
причины (reasons), связи (links).

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

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

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

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

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

Жизненный цикл элемента работы определяется двумя системными
реквизитами: состоянием и причиной.

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

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

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

Для настройки типов рабочих элементов используется продукт Team
Foundation Power ТоокЦ Он является свободно распространяемым
продуктом и содержит, в частности, визуальный редактор,
позволяющий просматривать и редактировать жизненный цикл
элемента работы в визуальном виде - см. рис. 13.2. Па этом рисунке
показан граф жизненного цикла для типа рабочего элемента "ошибка".
Мы можем видеть три состояния - Active (обнаружена ошибка), Resolved
(ошибка исправлена), Closed (ошибка закрыта), - и переходы между
этими состояниями. В каждом переходе имеется прямоугольник
Transition, в котором содержатся параметры перехода - причина,
действия, которые нужно выполнить, список реквизитов, который
должен быть изменен при переходе и некоторую другую информацию.
Д.В. Кознов

| Лапяйол

-	Resolved Date

-	Resolved By

-	Resolved Reason

-	Closec Date

-	Closed By

Active

№

Глз/иЛм

Resolved

-	Closed Date

-	Closed Ey

* Resolved Reason

-	Reasons

Deferred

Duplicate

As Designed

Unable to R..

Obsolete
Fixed





| Тлал^сл

- Actions

Microsoft,?...

- Fields



* Assigned

* Activated..

* Activated
+* * Resolve.

* Resolved

Closed

Рис. 13.2. Жизненный цикл элемента работы типа ’’Ошибка".

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

• базовые ограничения: обязателен для заполнения или нет,
доступен только на чтение, пусто, не может быть сброшено,
может быть только сброшено;

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

• является датой в прошлом или в будущем;

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

* значение должно всегда удовлетворять шаблону некоторого
регулярного выражения;

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

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

Кроме того, можно описать правила, применяемые в разные моменты
времени, в том числе:

•	постоянно действующие ограничения или применяемые при
создании правила;

•	при изменении определенного реквизита, или наоборот, если
реквизит остался неизменен;

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

•	при переходе или во время нахождения элемента работы в
определенном состоянии;

•	при совершении определенного перехода;

•	при совершении определенного перехода по определенной
причине в жизненном цикле элемента работы.

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

Еще один важный механизм настройки реквизитов в VSFS - это
задания способа представления реквизита в экранных формах
редактирования, просмотра в отчетах. Для этой цели в TFS существует
достаточно гибкий диалект XML, включающий предопределенный
набор элементов пользовательского интерфейса, а также позволяющий
группировать их, разбивать по колонкам или размещать на закладках.
Используя вложенность элементов и групп, можно описать строгий,
удобный и красивый пользовательский интерфейс, но иногда для этого
требуется много времени. Некоторые типы элементов
пользовательского интерфейса можно связывать с реквизитами
элемента работы, используя соответствующее имя для ссылок.

Средства использования

Пример: элемент работы task. Кратко опишем пример, который будет
использован в дальнейшем для объяснения средств использования
элементов работы.

Рассмотрим элемент работы типа tusk (задача). Как правило, в начале
проекта некоторый эксперт (как правило, системный архитектор,
ведущий разработчик и т.д.) проводит анализ всей необходимой работы
по проекту и разбивает её на подзадачи, устанавливая ответственных,
сроки и т.д. Эти подзадачи с соответствующими атрибутами и являются
элементами работы типа task.

Затем менеджер проекта, с учетом списка всех задач и их
взаимосвязей, строит календарный план. На этом этапе менеджеру
могут оказаться полезными средства Project и Microsoft Excel - он
пользуется ими на основе соответствующих мостов, имеющихся в TFS.

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

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

Создание элементов работы. Для создания нового элемента работы
можно воспользоваться пунктом меню Team, добавляемым в Visual
Studio вместе с Team Explorer, как показано на рис. 13.3.

। learn Data Tools Test Analyse Window Help

Я[

Bug

Quality of Service Requirement

Risk

Scenario.

I Add bug

Add Work Item

Add Related Work Item

Work Item Templates

Go to Work Item .

►

►

k

Go to Previous Work Item Shift+AII+P

Task

Go to Next Work Item Shift+Ak+fl Г

Рис. 13.3. Создание элемента работы.

После выбора пункта меню Add \Vork Item отобразился список из
существующих в данном проекте типов элементов работы. Далее, после
выбора соответствующего пункта меню будет открыто окно
редактирования нового элемента работы, как показано на рис. 13.4:
New Task 1* MvT«ks[R₽sJts; Short Page

г X

3

! Ne«M Task 1 : TF20012: Feld 'Title :snnot be empty.

Jjtle; pRequ»ed>

Qisciplre; |".1И1ИМ«чЛ

Рис. 13.4. Редактирование элемента работы.

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



панели инструментов. После сохранения элемент работы
автоматически получит уникальный идентификатор и будет сохранен в
системе управления элементами работы.

Для добавления связанных элементов работы можно воспользоваться
командой контекстного меню Add Related Work Item, как показано на рис.
13.5:
Таек 233 Му Tasks [Results] start eage	’ *

Рис. 13.5, Добавление связанного элемента работы.

После добавления связанного элемента работы откроется окно
редактирования для вновь созданного элемента работы, при этом связь
между двумя элементами работы будет добавлена автоматически, как
показано на рис. 13.6.
Рис. 13.6. Список связей.

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

Заметим, что контекстное меню на рис. 13.5 демонстрирует еще одну
полезную при создании элементов работы возможность - шаблоны
элементов работы. Шаблон определяется набором предзаполненных''
атрибутов элемента работы и может сильно облегчить жизнь
участникам проекта, которым приходится создавать много однотипных
элементов.

Доступ к элементам работы. Члены команды, работающие с VSTS через
Team Explorer, имеют доступ к элементам работы, открыв в текущим
проекте вкладку Work Items (см. рис. 13.7). При этом элементы работ
доступны не как огромная куча (легко понять, что их может быть очень
много в каждом проекте - сотни и даже тысячи), а с помощью
специальных фильтров - запросов (queries). Они распределены по
папкам Team Queries и Му Queries. В первой папке располагаются
запросы, видимые и используемые всей командой. Во второй папке
располагаются запросы, созданные конкретным пользователям для себя
лично. Все это можно увидеть на рис. 13.7.
Team Explorer	- Ф х

i«8j	LANDOCS
Э	] My Favorites
FH	ZTa CMMI
Й- 1	□ j DP
Й- 1	MySQL
Э- 1	jjtest
a-1	J7j TestProject

Work Items

_i Work Item Templates

Э- kJ

Pl . Team Queries

_ Active Bugs
. All Issues

’l All Quality of Service Requirements

 All Scenarios

Zj AH Tasks

_j All Work Items

. j My Work Items

My Work Items for All Team Projects

_ Project Checklist
Resolved Bugs

_ j Untriaged Bugs

El - i. . My Queries

- My Tasks

v j Documents

+1 □ Reports

E=J _J Builds

L- AB Build Definitions

• j Night build

j, Alerts

Source Control
Д.В. Кознов	Введение в программную инженерию

Рис. 13.7. Запросы на элементы работы.

Итак, когда разработчику понадобилось получить доступ к
определенной группе элементов работ (например, к ошибкам, которые
ему нужно исправить), он выбирает соответствующий запрос и
выполняет его. В результате в специальном окне будет открыт список
элементов работы, удовлетворяющих данному запросу (рис. 13.8), а при
выборе определенного элемента, в нижней части окна-списка
отобразится детальная информация об этом элементе (а при двойном
щелчке элемент работы будет открыт в отдельном окне).
Query Results: 15 results found (1 currently selected).

Рис. 13.8. Список элементов работы.

Способ отображения списка (набор колонок, сортировка, и т.д.)
настраивается индивидуально для каждого пользователя, а форма
детальной информации об элементе работы настраивается для проекта
в целом для каждого типа элементов работы в отдельности.

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

редактирование, позволяют выбор значений только из определенного
списка и т.д.

Выделенные (selected) элементы работы можно экспортировать в
пакеты Microsoft?reject, Word, Excel, используя соответствующие кнопки
панели инструментов

и

к

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

Элементы работы при планировании. Не сложно заметить, что такая
важная роль как менеджер проекта, не получила собственного издания
Visual Studio. Связано это с тем, что основная платформа Visual Studio
плохо приспособлена для задач, которые приходится решать этой роли.
Гораздо более удачно для этого подходят офисные приложения -
Microsoft Excel и Microsoft Project. Поэтому для более полного
вовлечения менеджера в информационное пространство проекта Team
System предоставляет специальные мосты.

Рассмотрим пример с пакетом Project. В этом пакете, при наличии на
том же компьютере Team Explorer, появляется пункт меню Team. В нем
нужно выбрать необходимый проект в VSTS, как показано на рис. 13.9.
И Microsoft Project - Projectl

.j] Fie Edit View Insert Forma: Tools Project Coiaborate

Team I Window Help

Choose Team Project .

Л [Tasks | ▼ Resources * Track ▼ | Report ▼

Choose Team Project j Get Work Items Publish Й Refresh IH

Get V'ork Items

Publish Charges

Getting Started

Microsoft Office Online

Connect to Microsoft Office

Task Name

fa

H

Refresh

Lnks and Attache

lumii Mappings...

Edit Areas and Iterations...

J

X

О

Рис. 13.9. Меню Team в Microsoft Project.

После этого появится возможность использовать другие пункты меню
Team, в частности - пункт меню Get Work Items, позволяющий считать
необходимые элементы работы с сервера. При выборе этого пункта
меню появится диалог, показанный на рис. 13.10. Поиск нужных
элементов работы можно осуществлять в соответствии с существующим
запросом, по заданным идентификаторам или по названию элемента
работы.
Get Work Items

RB

Select items to add to the work item list:

	1 к-	1 Туре	Title	| State	
0	202	Task	Set up: Set Permissions	Active	
□	203	Task	bet up Migration of bource ^ods	Active	
0	204	Task	5et up; Migration of Work Items	Active	—
0	205	Task	Set up: Set Check-in Policies	Active	
0	206	Task	bet up. Configure Bu«d	Active	
0	207	Task	Set up: Send Mail to Users for Installation and Getting started	Active	
И	208  ->лп	Task  T vb	Г reate Vision Skatemenr «m« Г” гл'.Гл	TГ1л»1 -J	Active	J

17 workitem(s) found

Select All

Unselect All

Reset

OK

Cancel

Рис. 13.10. Форма поиска элементов работы.

После того, как нужные элементы выбраны, они будут автоматически
импортированы в Project - см. рис. 13.11:
ИмкгоэюП Project Project 1

gjLxj ‘ ted

Fte Edt £ev« Insert Format loots protect ^elaborate team Window чеф	Txpeaquestu-ifwhelp - fl *

J 2^ J iJ A -J £ *0 £ I *• I $ No Groce - «I g * > J" 3»*’ Arial	• a ’ В I Д j,

3 |lasks | ’ j Resources » Track » Report • L ^Ctu. hi Protect j Get Work Items *jPubtsh ij Refresh	and Attachments a.

	о	Work ttem С	Title	tkiartion	Start	Fnsh
1J	I	Iх-'	Setup Set	0 days?	Sim 18.11 06	Sun 16 11 06
2	да	Setup Migr	Odays?	Sunibii oe	Sun 1611 08
	204	Setup M*£i	Delays?	Sim 16.1108	Sun 1611 08
	205	Setup Set	Odays?	Sim 16.11 08	Sun 16 11 06
5	206	Setup Con	Odays?	Sun 16 406	Sun 1611 08
6	207	setup sen	Odays?	SUn 16 4 08	Sun 16 11 08
7]	208	Create vis*	Odays?	sun ie.ii об	Sun 1611 06
8	209	Setup Cre-	0 days?	Sun 16.11 06	Sun 16 11 06
8	210	Create Pers	Odays?	Sun 1611 06	Sun 1611 08
10	211	Deline tera	Odays?	Sim 16.11 08	Sun 1611 08
11	212	Create Test	0 days?	Sun 16.11 08	Sun 16 11 08
12	213	Brainstorm	0 days?	Sun 1611 OB	Sun 1611 08
13	214	Brainstorm	Odays’	Sim 1611 08	Sun 1611 OS
'«	215	Setup Cre	Odays?	Sun 16.1108	Sun IB 11 08
1S	218	Create Iler®	Odays?	Sunl6.11 06	Sun 16 11 06
16	233	Implements	Odays?	Sim 1611 06	Sun 1611 08
	234	Implement a	0 days?	Sun 16.1108	Sun 18 11 08

Nov 06	,i7MW08	24 Nov'08	nil*

It ,w(t [р~яГГв гм^т Jw|t If i s |SiMi|t iwit ;f is|s|m|_I
• iG.li

< 16.11

«. 16.11
» «-<1
♦ 1M1
♦ 16-<1
« 16.11
< 16.11
+ 16.11
♦ 1611
о 16.11
о 16.11
< 16.11
о 16.11
♦ 16-11
<► 16.11
о 16.11

Ready

Рис. 13.11. Элементы работы в Microsoft Project.

После импорта элементов работы менеджер может проводить с ними
все действия, которые он привык выполнять в Project. В данном случае
он создает полноценный план работ, как показано на рис. 13.12.
IK Microsoft Ptoject Projcctl

Fie Edt View Insert Fermat Tools Project Collaborate ream Window Hefc>

^Ergiish (Unted 51а

Type a question for Нэ'р

В X



Jdrid	Ф ^Ь«|ЁЗФ NoGroup

Show • Anal

Resource*:

паск

Repcrt ’	PicHT I	Get Wcrk Items ^jPublsh al Refresh Qflink

10

Wirk tom ID

202

203

204

205

206

200

200

210

21

Title

Setup Set
Setup Hiji
Set up Migi
Set up Sat
Setup Con

setup sen

Create ‘'isn

Set up: Cub

Great» Pers

Define itera

f!

12

15

212

213

214

216

233

Create Test

BranMcrn

Branstcrm

Set up Ore

Create Hera

Ы Implemen

Read?

1 day
2 days
Sdays

4 days
4 days

Durst on

Мап 24 11 38

Tue 25 11 08

Wed 26 11 03

Mon 17 11 33

Fn 21.1133

Fn20.l1 DO

Thu 20 11 08

Wed 26 11.08

5 days rhu 27 11 зз wed oo 12 oo

Sdoys Mon1711.C0 Wed 18 11 00

amanort

1MW 'os	T v NOV '06______24 MOV 33___ 01 L±J

T W|T |F;S|5|m|T |w[T If |S|5|M 'T |WlT,F IsIs'mI —J

arnancel

4 days

2 days

2 days

4 days

5 day®

Thu 20 1133

Tue 25.11.08

Wed 26 11 33

Mun 17 11 33

Mon 01 1233

Mon 24 11 33

6 days Mon 17.11 33

Thu 27 11 08

Tueia it do

Thu 04 12 08

Fr 28.11 08

1 08У Mun 24 11 33 Mtn 24 11.00

5 day® Tue 25 11 33 Mon 01 12 00

8 days Men 17.11.08 Wed 19.11.88

3days МЙП17 1133 weens ное

•rhongd

arhangei

arnancel

FTTm агЬаяце1

orhangel

11 i ' дБ num'

О





8

Рис. 13.12. Редактирование элементов работы в Miciosoft Project.

Отображение реквизитов элементов работы task на атрибуты задач
Project изначально задается в шаблоне процесса разработки. Кроме того,
менеджер может получить доступ из Project ко всем остальным
атрибутам задачи как к расширенным полям, как показано на рис. 13.13.
Task Information

General | Predecessors | Resources 1 Advanred ' Notes Custom beds

Duration pd -ri I- Estimated

isan.g | Set up Configure Build
Custocir F«>ds

| Workitem ID (TextlCn

Custom Field Name	i Value
Iwork Item ID (TextlO)	206
State (TextlS)	Active
Reason ITextH)	New
Issue (Text 15)	No
Rank (Text 16)	
Discipline (Text 17)	
Work Item Priority (Text 19)	
Exit Criteria (TextZO)	Yes
Quality of Service Type (Text21>	
Rough Order of Magnitude (Text22)	
Rev (Text23)	1
T. ——  нар 1	T-.-L	L  OK | Cancel

Рис. 13.13. Доступ к реквизитам элемента работы.

После того, как все действия в Project выполнены, для внесения их в
VSTS воспользоваться командой Publish, а для получения обновлений -
командой Refresh. Криме того, сам файл с планом можно сохранить на
диске или портале SharePoint. При этом информация о связи с сервером
TFS так же сохранится.

Элементы работы в дальнейшей разработке. После того, как был
построен план и назначены исполнители определенным задачам,
ответственные исполнители увидят их в результатах соответствующих
запросов (типа Му Tasks). И начнут выполнять соответствующую работу.
При этом придется вносить некоторые изменения в систему контроля
версий, и в этот момент у них появляется возможность указать
связанные с данными изменениями элементы работы - ошибки,
которые исправляются и задачи, которые выполняются в данном
изменении кода и т.д.

Элементы работы в отчетах. Одной из основных задач подсистемы
работы с отчетами является отражения реального актуального статуса
проекта и анализ его истории. Большинство отчетов в TFS базируются
именно на элементах работы и отражают динамику их изменения. В
частности, отчет Project Velocity представленный на рис. 13.14,
отражает количество закрытых задач в соответствии с днями (неделями
или месяцами) и позволяет судить о том, насколько эффективно
двигается проект.

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

Project Velocity - Report viewer Project Vebcfcv - Resqtt Mewer Unplanned Wcrk - Report Waver Rerrarrg Work - Report tfewer

URL; http.//londocsjRcpoftSsrvei	.aspx?%2fMySQL%2ffvo)xt+VdcctY€4S%3aCcrrinard~Rencfer

Iteration iNjSQL	* Area	|W‘SQL	0 

Work Item т^ре |ДН (По Filter)	v Tine Measure [Daily	*J

Присшгр отчета

Start Dab |16 00.2606	3 End Data |1C.O9 2006	3

----------------------------------------------------------------------------------------------------------------------------------------------

н d Г из 1 t> H 1100%	jrj |	Найти |Дгпм?	| дыб рать формат	V[ =зюлирт itl	£

Project vebcity	_

Rep a I Generaed. 16.11.2000 И.16 06 b? 1ДГЮОС5*а4мад1; Last Warehouse Update; 24 00.2006 10.0556

How do the receive and dose rates compare?

- Pesoksd I Dail/)

—* dosad (Daly)

——a Average Resolved

Рис. 13.14. Отчет Project Velocity.
Его можно скачать отсюда ссылка: htrp>/msdn.microsoft.com/en-
us/tfs2008/bb980963.aspx
Д.В. Кознов	Введение в программную инженерию

VSTS: конфигурационное управление

Система контроля версий. Отслеживание изменений отдельных
файлов. Правила внесения изменений. Управление ветками.
Сохранение без внесения Автоматические сборки.

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

•	интеграция с системой управления элементами работы (а через
нее и с системой отчетов) позволяют эффективнее отслеживать
процесс разработки и управлять им;

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

Система контроля версий

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

•	отслеживание изменений отдельных файлов и их "провязка" с
элементами работы;

•	правила внесения изменений (check-in policies);
Д.В. Кознов

•	средства управления 'ветками'';

*	сохранение изменений без внесения.

Отслеживание изменений отдельных файлов. Основным
отличительным свойством системы контроля версий в TFS является
интеграция его с другими подсистемами TFS, а также более тесная
интеграция с Visual Studio, чем во многих других системах контроля
версий. Большая часть этих возможностей наглядно демонстрируется
самим внешнем вида check-in диалога, представленным на рис. 14,1.

Рис. 14.1. Check-in диалог

На первый взгляд диалог выгляди достаточно стандартно - список
файлов и поля для внесения комментариев к вносимым файлам. Однако
в глаза бросается панель с дополнительными закладками в левой части
окна. Именно эта панель и позволяет получить доступ к специфической
функциональности.

Наиболее востребованной является поддержка в TFS возможности
связи вносимых изменений с элементами работы, которую можно
выполнить на закладке Work Items, показанной на рис. 14.2.
Рис. 14.2. Закладка Work kerns

Разработчик, который вносит изменения в файлы с исходными
текстами, может найти соответствующие этим изменениям элементы
работы (ведь он либо исправлял какую-нибудь ошибку, либо выполнял
задачу и т.п.), используя любой из доступных запросов, а также
текстовый поиск. Запрос задается в секции Query - см. рис. 14.2.
Результат его выполнения отобразится в главном окне диалога на этом
рисунке. Для того, чтобы связать конкретный элемент работы из этого
запросы с данным изменением исходников, надо выбрать галочку в
первом столбце. На рис. 14.2 она выбрана для последнего элемента в
списке - элемента работы Task 107. Далее, бывает так, что это
изменение исходников "закрывает" данный элемент работ. Тогда в
столбце Check-inAction нужно выбрать действие Resolve - это действие,
на равне с другими, определяется в шаблоне процесса для всех
элементов работы данного типа. Если же данное изменение не
"закрывает" данный элемент работы, то в этом столбце нужно
проставить действие Associate, и оно просто установит связь этого
изменения с данным элементом работы.
Рис. 14.3. Закладка Check-in Notes

В момент внесения изменений или после к нему могут быть
присоединены дополнительные комментарии людей,
проинспектировавших данное изменение (рис. 14.3). По умолчанию
TFS предполагает три вида инспекций - инспекцию кода, инспекцию
безопасности и инспекцию производительности. Инспекции являются
эффективным способом повышения качества кода и предполагают
изучение написанного кода другим человеком. К сожалению,
реализация поддержки инспекций в этом виде не даст возможность
указать, кто именно производил инспекцию, что часто является важной
информацией.
Рис. 14.4. Закладка Ройсу Warnings

Интересным нововведение TFS как системы контроля версий является
гибкая система задания правил внесения изменений (check-in policies'), о
которой будет подробнее рассказано позже. На зактадкс Policy Warnings
(рис. 14.4) разработчику показывается список правил, с которыми
вошло в конфликт его изменение (или процедура внесения изменений).
Рис. 14.5. Свойства набора изменений

Большинство свойств пакета изменений можно изменить в дальнейшем
в окне редактирования пакета изменений (рис. 14,5). Единственное
свойство, которое нельзя изменить из этого окна - ассоциации с
элементами работы. Для установки ассоциаций элемента работы и
пакета изменений необходимо обратится к редактору элемента работы.

Правила внесения изменений. Одним из наиболее существенных
преимуществ TES как системы контроля версий является возможность
задания правил внесения изменений. Эти правила применяются
непосредственно перед внесением изменений на компьютере
разработчика и в том случае, если правила не выполняются,
разработчику отказывается во внесении изменений.

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

в Интернет можно найти огромное количество информации о
написании собственных правил.

В стандартную поставку TFS входят следующие правила:

•	Work Items - предполагает, что каждый пакет изменений кроме
файлов должен иметь ассоциацию с элементом работы;

•	Builds - проверяет, что перед внесением изменений разработчик
убедился в собираемости проекта;

*	Testing - проверяет, что перед внесением изменений
разработчиком были исполнены тесты. К сожалению, правило не
может определить какие именно тесты надо запускать для
проверки данного изменения, поэтому данное правило не всегда
эффективно;

*	Code Analysis - выполняет статический анализ кода перед
внесением изменений.

В пакете Team Foundation Power Tools имеются следующие
дополнительные правила:

•	Правило Forbidden Patterns позволяет запретить добавление
файлов с определёнными шаблонами в именах, например,
Forml.cs.

•	Правило Custom Path позволяет увеличить гранулярность
применения правил в проекте сконфигурировав правила только
для определённых частей структуры папок системы контроля
версий.

•	Правило Changeset Comments проверяет, что изменения
сопровождаются комментариями.

*	Правило Work Item Query проверяет, что все элементы работы,
возвращаемые в результате определённого запроса,
ассоциированы с файлами (более продвинутый вариант правила
Work Items).

Среди правил, доступных в открытом доступе можно выделить:

•	Правило Code Comment Checking проверяет код на наличие
комментариев перед внесением изменений (работает для кода на
Д.В. Кознов	Введение в программную инженерию

Cff.'VB.NETj.

*	Правило Code Review \Vorkflow проверяет, что каждый пакет
изменений ассоциирован с элементом работы, являющимся
заданием на инспекцию кода в состоянии 'Выполнено". Это
правило позволяет проводить процесс инспекции вносимых
изменений в более формальном виде.

•	Правило Merge/Branch Only удостоверяет, что все изменения
происходят в результате объединения с другой веткой либо
ответвления. Представляет особый интерес с точки зрения
процесса конфигурационного управления. Позволяет, например,
запретить вносить изменения напрямую в одну из ветвей
(например, ветвь релиза). Вносить изменения в ветвь,
защищенную таким правилом, можно только через интеграцию
изменений из других ветвей.

Выбрать список правил, применяемых для командного проекта можно с
помощью окна настройки системы контроля версий (рис. 14.6).

Рис. 14.6. Редактирование правил вноса изменений
Следует заметить, что достаточно часто при разработке случаются
ситуации, когда изменение необходимо срочно внести и на
удовлетворение всех правил времени нет, либо конкретное правило не
может быть выполнено по объективным причинам. В этом случае
разработчик имеет право отменить правила для своего пакета
изменений, написав при этом комментарий с объяснением причин
отмены (рис. 14.7).

Рис. 14.7. Диалог Policy Failure

Управление ветками. Для поддержки конфигурационного управления в
системе контроля версий IT’S реализовано две команды: создание ветви
( Branch ) и интеграция ветвей ( Meige ). Эти команды доступны на
файлах и папках в системе контроля версий. При выборе команды
создания ветви открывается диалог (рис. 14.8), позволяющий выбрать
путь, куда следует скопировать (ответвить) выбранные файлы. После
выполнения этой команды в системе контроля версий по указанному
пути создастся полная копия выбранных файлов.
Рис. 14.8. Создание новой ветви

Заметим, что после создания ветви она не попадает автоматически на
сервер. Чтобы ветвь попала на сервер и стала доступна всем,
необходимо выпотнить операцию внесения изменений (рис. 14.9).


Check In Source Files Workspace: LANDOCS

Comment:

Source files

Wort’- Items

CheiA-in
Notes

Name	| change | Folder ______________________________________________

□tJjDP.vsmdi	edit	E\Jsers\arl-iangeI\DP

El iT^iTestFiles-branch	branch	E \Jsers\arhangeI\TfsTestProject

0 Test.txt	branch	E:\Jsers\arhangeATfsTesiProject\TestFile5-branch

Policy

Warmrgs

Рис. 14.9. Внесение изменений ответвления

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

На первом шаге (рис. 14.10) разработчик задает откуда ( source branch ) и
куда ( target branch ), а также изменения из какой области он хочет
перенести (все вплоть до определенной версии, или только выбранные
пакеты изменений).
Рис. 14.11. Версия для интеграции

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

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

Так же каки при создании новых ветвей, при выполнении интеграции
необходимо в явном виде внести пакет изменений, применив к нему все
настроенные правила и ассоциировав с соответствующим элементом
работы.
Рис. 14.13. Список конфликтов

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

Разработчик может выбрать автоматический способ разрешения,
который сработает только для тех файлов, в которых были изменены
разные части. В случае, если автоматическое разрешение невозможно,
система откроет диалог ручного разрешения - см. рис. 14,14.
Рис. 14.14. Разрешение конфликта

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

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

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

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

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

Рис. 14.16. Сохранение без внесения

Для сохранения изменений служит команда Shelve, открывающая
диалог, представленный на рис. 14.16, аналогичный диалогу внесения
изменений за исключением поля для введения имени сохраненного
пакета в верхней части и двух следующих дополнительных опций в
нижней части.
•	Сохранить локальные изменения. Если эта опция включена, то
изменения останутся локально в рабочем пространстве
пользователя (рекомендуется при временной остановки работы).
Если же нет, то локальные изменения откатываются и остаются
только в виде сохраненного на сервер пакета (рекомендуется при
смене рабочей машины).

•	Применить правила перед сохранением - позволяет
проанализировать пакет, применив все те правила, которые
действуют при внесении.

। Eiror List j^Pendng Changes] [ Output]

Рис. 14.17. Список текущих изменений

Для того, чтобы восстановить сохраненные изменения необходимо
воспольюваться командой Unshelve, доступной для файлов и папок, а
также в глобальном контексте (из окна со списком невнесенных
изменений - см. рис. 14.17). Зга команда открывает диалог
восстановления изменений (рис. 14.18), позволяющий выбрать один из
сохраненных пакетов для восстановления. Из этого же диалога пакеты
можно удалить, если они потеряют актуальность.
Рис. 14.18. Диалог восстановления изменений

Автоматические сборки

Общее. Одним из существенных преимуществ TFS по сравнению с
другими системами управления сборками является простота, с которой
он позволяет создавать и настраивать процесс автоматической сборки.
Несмотря на то, что в основе сборок TFS лежит давно и широко
известная технология MsBuild, именно TFS позволяет вывести её на
принципиально новый уровень благодаря следующим улучшениям.

• TFS поставляется вместе с набором MsBuild-задач, позволяющих
значительно упростить и ускорить настройку процесса сборки.
Среди наиболее важных задач следует отметить следующие:

о сборка проекта (при этом исходные тексты программ
автоматически берутся из системы контроля версий),

° автоматический запуск тестовых пакетов (как созданных в
ручную, таки идентифицированных автоматически),

° применение статического анализ кода,
Д.В. Кознов	Введение в программную инженерию

о размещение результатов сборки в сетевой папке,

° автоматическое поддержание уникального идентификатора
сборки и его регистрация,

° выявление присоединенных элементов работы и т.д.

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

*	Возможность автоматического запуска процесса сборки как в
режиме непрерывной интеграции, таки по расписанию.

•	Визуальное представление хода процесса сборки, результатов, а
также истории более ранее отработавших сборок.

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

Создание описания сборки. Для создания описания новой сборки
проекта необходимо выбрать команду New Build Definition в
соответствующем узле Team Explorer, и после этого откроется окно с
несколькими закладками (рис. 14.19).
Рис. 14.19. Общие настройки описания сборки

На первой закладке ( General) находится общая информация - название
и описание назначения этого сценария сборки,
Build Definition -

Рис. 14.20. Настройка рабочего пространства

На второй закпадке ( Workspace ) - см. рис. 14.20 - описывается то,
какие исходные тексты необходимо взять из системы контроля версий
для сборки, а также то, как эти коды разместить на машине, где будет
сборка происходить Кроме того, эти настройки влияют на поведение
при непрерывной интеграции - внесение изменений именно в
выбранные области в средстве контроля версий будет явтяться
сигналом для запуска данного процесса сборки.
Рис. 14.21. Выбор или создание MsBnild-проекта

Наиболее интересной является третья закладка Project File (рис. 14,21),
где разработчик может выбрать один из существующих MsBuikl-
сценариев сборки или создать новый.
Рис. 14.22. Правила сохранения

В TPS 2008, в связи с реализацией функциональности по непрерывной
интеграции, возникла проблема большого числа описаний сборок и
результатов, сохраненных в системе и на диске. Для устранения
проблемы был реализован механизм автоматической очистки,
получившей название Retention Policy (см. рис. 14.22), позволяющий
задать, сколько последних результатов нужно хранить. При этом для
каждого из типов результат (неудачный, остановленный, частично
успешный, успешный) можно задать свое число.

Полезной функцией является то, что политику уничтожения результатов
можно отключить для конкретной сборки используя опцию Retain
Indefinitely. Результаты, помеченные этой опцией, сохраняются в системе
навсегда (или пока опция не будет снята).
Guild Definition - Night build

пв

Gene-al

Workspace

Ji Project ₽ile
Retention Policy

Specify the build agent and staging location for this build definition. These selections may
be modified by tne person Queuing the build

Build agent:

A Build Defaults

Trigger

New...

Descrinuon:

Builds wil be sieged tu tffc following share (fur example, \\server\share):

J_ This icor indicates that the tab requires input.

Рис. 14.23. Выбор агента

На закладке Build Defaults (см. рис. 14.23) мы задаем свойства окружения,
которое будет использовано для автоматического запуска процесса
сборки. Главным здесь является сборочный агент - процесс, в рамках
которого будет выполняться процесс сборки.

Кроме того, именно на этой закладке можно задать сетевую
разделяем},™ папку, в которой буцут храниться результаты процесса
сборки. При выборе папки нужно убедиться, что сборочный агент
имеет к ней доступ на запись.
Рис. 14.24. Задание триггера

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

•	не запускать процесс сборки автоматически (то есть только
"вручную"),

•	запускать после каждого внесения изменений,

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

•	запускать процесс сборки только по расписанию, даже в том
случае, если ничего не менялось.

Создание проекта MsBuild. Проект MsBuild, не смотря ни на что, все-
таки составляет основу системы автоматических сборок TFS. Однако
специалистами Майкрософт потрачено немало усилий на то, чтобы мы
могли забыть о необходимости поддерживать большие и сложные XML-
файлы с описанием сборок. В TFS для создания проектов MsBuild
реализован достаточно удобный мастер (рис. 14.25 - J 4,27).

Рис. 14.25. Выбор решений

На первом шаге (рис. 14.25) мы выбираем в системе контроля версий те
решения, которые должны собираться в данной сборке.
Рис. 14.26. Выбор конфигураций

На втором шаге (см. рис. 14.26) мы выбираем те конфигурации в этих
решениях, которые нужно собирать.
Рис. 14.27. Выбор тестов и правил анализа

И, наконец, на третьем шаге (рис. 14.27) мы выбираем те тесты, которые
мы хотим запустить и отмечаем, хотим ли мы проводить статический
анализ кода. В отличии от TFS 2005, где при выборе тестов можно было
использовать толью заранее подготовленные тестовые пакеты, в TFS
2008 появилась такая востребованная возможность как автоматическое
подключение пакетов тестов по метке имени (обычно сборки
начинающиеся или заканчивающиеся на Test). Эта возможность
позволяет без дополнительных затрат включить выполнение модальных
тестов в автоматическую сборку.

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

виде сервера или консольного приложения-'.

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

Несмотря на сложность описанного процесса, настройка его достаточно
проста и производится, в основном, с помощью окна свойств агента
(см. рис. 14.28).

Рис. 14.28. Свойства сборочного агента

Запуск процесса сборки и анализ результатов. Итак, после того как
описание сборки создано и инфраструктура выполнения настроена, мы
можем запустить процесс сборки с помощью команды Queue New Build,
вызывающей окно, показанное на рис. 14.29.

Рис. 14.29. Запуск новой сборки

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

Рис. 14.30. Список описаний сборок

После того, как сборка помещена в очередь, она отображается в списке
сборок (рис. 14.30), откуда можно перейти к окну с детальной
информацией о сборке (рис. 14,31). В этом окне отображается ход
сборки, или её результаты, если она завершена.

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

/S'Release.txt ' Night build_20080831.4 [Budd Explorer - restProject ]x

l₽r

Рис. 14.31. Результаты сборки

Управление процессом сборки. Все продемонстрированные нами
средства визуального описания сборок доступны не толью при
создании такого описания, но и для любого из существующих описаний
сборок (команда Edit Build Definition ). Единственным исключением
является файл MsBuild. который, будучи однажды сгенерирован с
помощью мастера, далее поддерживается вручную.

Этот файл можно найти в системе контроля версий (рис. 14.32) в той
Д.В. Кознов	Введение в программную инженерию

папке, которая была выбрана при его создании. Эта папка содержит два
файла:

•	PROJ-файл - основной файл, описывающий задачи MsBuild, Этот
файл содержит достаточное количество сгенерированных
комментариев, позволяющих производить простую настройку
(добавить или удалить решение, включить или отключить
статический анализ и т.д.) достаточно легко, однако для более
сложных изменений необходимо знакомство как с принципами
работы MsBuild, так и со спецификой MsBuild- задач, используемых
в TFS.

•	RSP-файл, который содержит параметры командной строки для
передачи при запуске MsBuild.

Source Control Explorer

№ -J *s) X jfe i 3	И1 ”	1 "0 Workspace: LANDOCS

Source location: [; j $/TestFroject/TeamBuildTypes/Night build

^TFSBuild.rsp

Yes

И GJ DP

E GJ MySQL

s Gi te5t

□a TestProject

El fer TeamBuildTypes

 Qj Night build
S□ TestFiles
E TestFiles-branih

E Ca Testsolution

Рис. 14.32. Файл определения проекта

Заметим, что для большинства простых проектов обычно хватает
настроек, доступных через визуальные редакторы, и изменять эти
файлы приходится относительно редко.

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

VSTS: тестирование

Система отслеживания ошибок. Создание описания ошибки. Связь
изменений исходных текстов ПО и ошибок. Система оповещений.
Модульные тесты. Пакеты тестов Автоматические тестирование Web-
приложений.

Выделим следующие возможности VSTS по тестированию:

•	интегрированная система отслеживания ошибок;

•	средства разработки модульных тестов;

•	средства организации тестовых пакетов;

•	автоматическое тестирование Web-приложений (в том числе и
нагрузочное).

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

Система отслеживания ошибок

Общее. Система отслеживания ошибок в VSTS реализована на базе
системы управления элементами работ. Ведь ошибки (bugs) - особый
тип элементов работ. По сравнению с другими системами
отслеживания ошибок, интегрированная система на основе системы
управления элементами работы обладает рядом следующих серьезных
преимуществ.

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

значительной регрессии.

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

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

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

На рис. 15.1 представлено описание жизненного цикла элемента работы
"ошибка" (Вис/) из шаблона процесса VSTS под названием MSF for Agile
4.2. У этого типа элемента работы определено три состояния.

•	Active - ошибка нуждается в исправлении,

•	Resolve - ошибка исправлена,

*	Close - ошибка проверена и исправление принято.

На стрелках-переходах указаны причины, в силу которых ошибка
перешла в данное состояние. Опишем некоторые, самые часто
встречаемые переходы.

В состояние Active ошибка попадает, во-первых, после своего создания
- то есть тестировщик нашел новую ошибку и создал соответствующий
элемент работы (это начальное действие на картинке не показано).
Далее, в это состояние ошибка может попасть из состояние Resolved,
после того, как тестировщик проверил исправление программиста и
обнаружил, что тесты все равно падают" (причина Test failed). Если
исправление ошибки было проведено некорректно (поведение системы
не соответствует желаемому), то ошибка переходит в состояние Active
по причине Wrong Fix. Если же способ закрытия ошибки является
неприемлемым (например, тестер не согласен, что данная ошибка
является дубликатом другой), то используется причина Resolution Denied.
Наконец, ошибка может перейти в состояние Active, если она вновь
стала появляться - причины Reactivation и Regression. При этом для
тестировщика важно не создавать новую ошибку, а понять, что это
старая, закрытая, вновь проявилась Эта информация поможет
разработчикам быстрее разобраться с исправлениями - проглядеть те
изменения исходных текстов, которые закрывали эту ошибку и
исправить их. При этом может очень эффективно работать связь,
которую обеспечивает VSTS для элементов работ и изменениями в
средстве контроля версий - что подробно обсуждалось в лекции о
поддержке в TFS конфигурационного управления.

Active

Fixed,
As Designed,
Deferred,
Duplicate,
Obsolete,
Unable to Reproduce

Regression,
Reactivation

Resolution Denied,
Wrong fix,
Test failed

Resolved

Fixed,
As Designed,
Deferred,
Duplicate,
Obsolete,

Fixed,
As Designed,
Deferred,
Duplicate,
Obsolete,
Unable to Reproduce

Unable to Reproduce

Closed
Д.В. Кознов	Введение в программную инженерию

Рис. 15.1. Жизненный цикл.

В состояние Resolve ошибка переходит, во-первых, после того, как
разработчик ее исправил. В это состояние разработчик может перевести
ошибку еще и по тому, что это не ошибка, а свойство (тестировщик
неправильно понял требования к системе или проектную
спецификацию) - причина As Designed. Л также потому что ошибка
повторяет другую, найденную ранее ошибку7 (Duplicate), ошибка не
воспроизводится у разработчика (Unable ю reproduce) и т.д.

В состояние Close ошибка переходит, во-первых, когда тестировщик
принял ее исправление (причина Fixed). Во-вторых, когда он согласился
с мнением разработчика, что она повторная (Duplicated), не
воспроизводится (Unable to reproduce) и пр. По этим же причинам сам
разработчик может перевести ошибку в состояние Close прямо из
состояния Active. Правда, это может быть не любой разработчик, а,
например, технический руководитель проекта или архитектор. Все
остальные разработчики могут не иметь прав переводить ошибки
самостоятельно в состояние Close, а обязаны действовать через
тестировщиков.

Как создастся описание ошибки. Создание новой ошибки может
происходить либо с помощью пункта меню в learn Explorer "7eam/Add
Bug...", либо посредством добавления связанных элементов работы для
задач, при реализации которых ошибки были обнаружены. Кроме того,
провал автоматической сборки или прогона тестов может служить
триггером для автоматического создания ошибки. Окно для описания
ошибки показано на рис. 15.2.
Д.В. Кознов	Введение в программную инженерию

у вид 235 д| Work Items [Results]*	Night buid 20081123.1	lest List Editor j Programlest cs S~| в M

Рис. 13.2. Автоматически созданная ошибка.

Связь изменений исходных текстов ПО и ошибок. В лекции про
конфигурационное управление мы подробно рассмотрели связь
изменения исходников кода с элементами работы. Теперь посмотрим на
то, как ошибка связана с этими изменениями (то есть мы смотрим на ту
же задачу, но с другой стороны - со стороны элементов работы, и
выбираем один специфический тип элемента работы - ошибку). Все
изменения в коде, связанные с исправлением определенной ошибки,
легко можно отследить используя закладку "Links" в диалоге описания
ошибки. Так, на рис. 15.3 показано, что ошибка связана с пакетом
изменений, внесенным в систему контроля версий.
Bug 235	д|| Work ItemsJResufcs]	Night buid„20081123,1	Test List Edbor PrqgramTest.es a	w x

Рис. 15.3. Отслеживание изменений по ошибке.

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

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

В IT’S, как показано на рис. 15.5, поддержаны следующие типы
автоматических оповещений.

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

•	Внесение изменений в систему контроля версий. Как правило,
этот тип оповещения используется архитекторами или
техническими лидерами команды для контроля качества
вносимого кода посредством регулярной проверки вносимых
изменений.

•	При автоматическом или ручном изменении атрибута "качество' в
описании результатов автоматической сборки-^. Этот тип
оповещений позволяет руководителям проекта узнавать об
изменении состояния проекта.

•	При завершении процесса автоматической сборки, не зависимо от
результатов Данный тип оповещений полезен для всех
участников проекта.
Рис. 15.5. Настройка получателей оповещений.

Оповещения, рассылаемые TFS, содержат только базовую информацию
о произошедшем событии и ссылку, позволяющую просмотреть детали
о событии через Internet Explorer, на Share Point портале проекта. В
частности, информация о результатах автоматической сборки и о тех
ошибках, исправления которых вошли в соответствующую ей версию
исходных кодов проекта, представлена на рис. ] 5.6.
Build Night build.20081123.2

Summary	^Partially Succeeded

Build name:	Night build 20081123.2
Requested by:	LAN DOCS lorbanqel
Team project:	TestProject
Definition name:	Niqht build
Aqent name:	TestProject

Command-line arguments:

Started on:	23.11.2008 17:36:56
Completed on:	23.11.20CS 17:38:24
Last changed by:	LANDOCSJFSblJild
Last changed on:	23.11.20CS 17:33.24

Quality:

Work items opened:  Source control version:	Not available  C1479
Loq:	\\landocs\TestProiectBuild\Night budd 20081123.2\BuildLog.txt

Associated work items

ID Title	S'-ate

10/ Use Visual Studio core editor for SQL editing	C osed

135 Build failure in ouild: N got bu ld_20081123.1	Resolved

Assigned To
arhangel
TFGBuild

Note: all dates and times are shown n Rjss.an Standard Tme (GMT +01:00:001.

Provided by: Microsoft Visual St-dio3> Team System 2008.

Рис. 15.6. Результаты автоматической сборки.

Модульные тесты

Модульные тесты как средство повышения качества программного
обеспечения появились достаточно давно, однаки они долго оставались
не поддержанными продуктами Microsoft. Впервые поддержка
модульных тестов появилась в Visual Sutdio 2005 и доступна в изданиях
Professional и выше (в том числе, и во всех изданиях группы Team).

Основная идея модульных тестов заключается в том. что
работоспособность кода можно проверить автоматически с помощью
написания дополнительного кода, вызывающего тестируемое и
анализирующего результаты. При этом, если для системы в целом такой
подход достаточно затруднителен в виду сложности системы, то для
отдельных частей системы (модулей), этот метод применим и дает
хорошие результаты. Как правило, основной единицей для модульного
тестирования являются классы и методы классов.
Исторически одним из первых популярных инструментов,
ориентированных на организацию модульного тестирования, был jUnit
для Java-приложений, клонированный затем под многие другие
платформы. Для платформы .NET пионером здесь являлся nUnit,
который до сих пор занимает лидирующую позицию в этой нише.
Однако, лидерство nUnit серьезно пошатнулось с появлением поддержки
модульных тестов в Visual Studio. По сравнению с классическими
системами Visual Studio обладает рядом следующих преимуществ.

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

•	Реализованы возможности для легкой интеграции в средства
автоматической сборки (только для TFS Team Build).

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

•	Имеются средства автоматической генерации сигнатур тестов и
средств доступа к приватным частям тестируемых классов.

•	Поддержано управление тестовыми данными, а также тестами,
использующими данные на уровне платформы,

В версии Visual Studio 2008 поддержка модульного тестирования была
перенесена из изданий семейства Team в издание Professional, что было
вполне логичным шагом, так как модульное тестирование является
общей практикой, применяемой как в личной, так и в командной
разработке. Так как модульное тестирования более не является чем-то
специфичным для Visual Studio Team System, а его реализация
соответствует большинству стандартных пакетов в этой области, мы не
будем останавливаться на этой возможности более подробно

Пакеты тестов

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

имеющем расширение vsmdi. Этот файп находится в системе контроля
версий и может быть включен в решение как отдельный элемент - см.
рис. 15.7.
Test Solution - Microsoft Visual Studio

ИИВ

File Edit View Project Build Team Debug Data

Tools Test Analyze Window Help

D * > *> Й1.3 «И З IE1 I' * й

।_3 Error List ^Fending Changes pM Output	f *« hstor

Changeset 1483 successfully checked n.

Properties-

Рис. 15.7. Пакет с иерархией тестов.
Для создания тестового пакета можно воспользоваться меню "Create
New Test List", как показано на рис. 15.8, и после этого откроется окно
для задания имени нового пакета и определения его места в иерархии
тестовых пакетов (см. рис. 15.9). В том случае, если для решения уже
создан файл метаданных, пакет тестов будет добавлен к нему, если же
файла метаданных еще создано не было, он будет создан
автоматически.

Test Analyze Window Help

New Test..,

*j Load Metadata File...

W Create New Test List,..

Run	►

Debug	►

, 3 Administer Test Controllers..,

Select Active Test Run Configuration ►

Edit Test Run Configurations	►

Windows	►

Рис. 15.8 Создание списка тестов
Рис. 15.9. Свойства нового списка тестов.

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

Test List Editor >g ,t Loud.: W И Т . "BC'd E .plorer - TesProject

*d 4l Group By: [None] » [All Columns] » <Type keyword> » J

J} Item(s) checked; 1		
В	Lists of Tests	Test Name	Project
Ё fe.Jj ВАТ	1/1 , JMamTest	Testproject 1
И,, ' Маю flow  =••• □ Tests Not in a List M /Т All Loaded Tests		

Рис. 15.10. Редактор список тестов.

1естовые пакеты могут использоваться как для ручного прогона тестов
определенной тематики (команда "Run checked", рис. 15.11), так и для
автоматического прогона в рамках автоматической сборки.
Test List Editoi-

\|> -	^1	Group By:

r Run Checked Tests

p J) Debug Checked tests

E bfl =^1 НШ-----------------

Рис. 15.11. "Ручной" запуск пакета тестов.

Указать тесты, которые будут запускаться при определенной сборке
можно при создании файла с описанием сборки MsBuild, или в
последствии через модификацию проекта MsBuild. В первом случае
достаточно на соответствующем шаге мастера выбрать файл
метаданных и отметить галочками интересующие пакеты тестов (рис.
рис. 15.12). Во втором случае необходимо открыть проект MsBuild в
редакторе XML, найти элемент MetaDataFile, или вписать необходимые
пакеты вручную:

<MetaDataFile

lnclude-"$(BuildProjectFoldeiPaih)/../../TestSolutioii/TestSolunon.vsmdi">

<TestList>BAT/Main flow</TestList>

</MetaDataFile>
MSBuild Project File Creation Wizard

Select build options

Selections

Configurations

The buld process wil include the Following build options.

Which build options would you like to include in the build process?

I* Run test (e g run BVTs, etc.)

Test metadata file:______________________________________________

[t/Te^Project/Test 5olutbn/Test Solution, vsmdi

Test list to run: _______________________________________________

a □ Ji bat

0Ji Mam flow

Automatlcaly detect and run tests in the following assembles
Semi-colon deimrted list of file specifications:

Perform code analysis according to project settings

< Previous [ Next >

Cancel

Рис. 15.12. Выбор пакета тестов при автоматической сборке.

Автоматическое тестирование Web-приложений

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

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

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

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

То, насколько успешно для конкретного приложения можно применить
данный подход, определяется несколькими факторами. Основным
является то, какая используется платформа (например, Java Swing, AWT,
Windows Forms. WPF, etc.) и дополнительные библиотеки с элементами
пользовательского интерфейса. Наиболее зрелой платформой с этой
точки зрения на данный момент является MS W'indows Forms.

Capture & Playback при тестировании Web-ингерфейсов. В случае с
тестированием Web-интсрфсйса ситуация с точностью распознавания
элементов управления (interface controls) значительно проще, чем при
тестировании произвольного пользовательского интерфейса.
Взаимодействие с сервером происходит по строго описанному
протоколу HTTP, что позволяет при записи перехватить отправляемые и
получаемые сообщения. Кроме того, визуальное представление
страницы задано в структурированном формате HTML, что позволяет
легко опознать отдельные элементы на странице.

В издание Visual Studio Тейт Edition lor Software Testers включен
дополнительный пакет, облегчающий автоматизацию тестирования
Web-приложений методом Capture & Playback. Он позволяет, как
автоматически генерировать простые тестовые сценарии на основе
записи действия пользователя, так и писать более точные тесты на
любом языке платформы .NET.

Добавить новый Web-тест к решению можно с помощью команды
'Test/New Test", выбрав в возникшем диалоге (рис. 15.13) тип теста Web
Test.

Рис. 15.13. Создание Web-теста.

После создания нового теста автоматически буцет запущена процедура
записи сценария теста в браузере (см. рис. 15.14). На этом этапе
достаточно ввести www-адрес приложения, которое следует
протестировать, после чего выполнить тестовый "проход" по Web-
Д.В. Кознов

интерфейсу непосредственно в браузере.

Рис. 15.14. Запись шагов тестировщика Web-приложения в Internet
Explorer.

После окончания записи будет автоматически сгенерирован тест,
включаклций все отправленные на сервер Ьпр-запросы и все
полученные ответы (см. рис. 15.15). При этом генератор автоматически
добавит некоторые правила, по которым будет проверяться
корректность работы теста.
Рис. 15.15. Редактор Web-теста.

Для каждого из шагов теста можно, с помощью визуального редактора,
добавить дополнительные проверки или опции, управляющие ходом
выполнения: поиск подстроки в ответе сервера (тексте полученного
HTML), валидацию HTML через задание регулярного выражения,
проверка наличия или отсутствия определенных тегов или атрибутов на
странице и т.д. Допускается также возможность разработки
собственных правил на любом .NET языке. В тех же случаях, когда
гибкости редактора недостаточно, можно сгенерировать C# код для
данного теста и реализовать необходимую логику вручную".

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

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

11 'Качество'1 является атрибутом сборки, устанавливаемым вручную
тестером после проведения тестирования. На основании значения этого
атрибута может быть принято решение о готовности или нет
определенной сборки к выпуску или переводу на дальнейшие этапы
тестирования.
Д.В. Кознов	Введение в программную инженерию

VSTS: поддержка различных моделей процесса

Поддержка шаблонов процесса. Инструменты настройки. Обзор
существующих шаблонов. MSF for Agile Software Development. Scrum.

Поддержка шаблонов процесса

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

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

Шаблон процесса содержит шесть основных разделов, в рамках которых
можно осуществлять настройку работы TFS.

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

2.	Отслеживание элементов работы (Work Item Tracing) - описание
типов элементов работы, включая задание их жизненного цикла,
определение набора элементов работы и запросов, создаваемых
по умолчанию для нового проекта.

3.	Отчеты (Reports) - описание отчетов проекта на специальном
XML-языке RDL (Report Definition Language). Имеющиеся в
шаблоне отчеты по умолчанию можно использовать "as is", а
также исправлять и дополнять. Создание полностью нового вида
Д.В. Кознов	Введение в программную инженерию

отчетов является довольно трудоемкой работой.

4.	Портал (Portal) - настройка шаблона портала в SharePoint с
тестовым описанием процесса разработки, а также набором
рабочих документов проекта (планов, дизайн-спецификаций и
пр.). На основании этого шаблона будет автоматически
формироваться портал для каждого нового проекта.

5.	Группы и права доступа (Groups & Permissions) настраиваются
для использования системы управления версиями, а также для
различных правил жизненного цикла элементов работы.

6.	Контроль версий (Source Control) - набор настроек для системы
контроля версий, включая набор политик внесения изменения,
позволения или запрещения множественного взятия файлов на
редактирование и т.д.

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

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

Инструменты настройки. Для управления шаблонами процесса
разработки используется утилита Process Template Manager (рис. 16.1),
доступная из меню TFS Settings (эта утилита устанавливается вместе с
Team Explorer). Этот менеджер позволяет загружать и выгружать
шаблоны, а также определять шаблон, используемый для новых
проектов по умолчанию.

L ANDOC5 Setting? Process Template Manager



Precess templates-

M5F for Agile Software Development  v4.2 i.default

MSF far Agile Software Development - v4,0

MSF for CMMI Process Improvement  v4.0

MSF for CMMI Process Improvement - v4.2

L ownload additional Process lemplates online

Process templates summary:

Choose the MSF for Agiie Software Development process for projects * *.
with short lifecycles and delivery-oriented teams who car work without
lots of intermediate documentation. MSF for Agile Software
Development is an iterative, scenario-driven development process for ____

building (JET, Web, Web Service, and other object-oriented
applications. It directly incorporates practices for handling quality of
service requirements such as performance and security, utilizes a
context-driven approach (context-based) to determine how to operate
rhe project, explicitly calls out pi oject risk as a success criteria for the

Close

Рис. 16.1. Менеджер шаблонов

С точки зрения реализации шаблон процесса разработки является
набором AML-файлов, которые, пожалуй, никому не захочется
редактировать "вручную". К счастью, существует инструменты,
позволяющие значительно упростить этот процесс^. Эти инструменты
входят в уже упоминавшийся нами выше пакет Power loots. Эти
инструменты доступны из меню Took/Process Editor (см. рис. 16.2).
Кратко перечислим и охарактеризуем их.

• Редактор типов элементов работы, который позволяет
редактировать определения типов элементов работы, включая
наборы реквизитов и жизненный цикл. Может быть использован
как для редактирования файлов с описанием типов элементов
работы, экспортированных с помощью Process Template Manager,
так и для редактирования типов, находящихся внутри одного
шаблона процесса. Кроме того, этот редактор может быть
использован для импорта/экспорта типов элементов работы в/из
шаблон процесса, что особенно полезно при распространении
сделанных изменений по разным проектам. Более подробно этот
редактор уже рассматривался выше.

•	Редактор шаблона процесса разработки позволяет редактировать
остальные аспекты шаблона процесса разработки. Может быть
использован только для редактирования шаблона, выгруженного
из TFS в файловую систему

•	Редактор глобальных списков позволяет определить списковые
типы для реквизитов элементов работы, а также управлять
множеством значений в них. По умолчанию TES автоматически
поддерживает глобальный список сборок, однако пользователь
может определить и другие списки^.

•	Просмоторшик реквизитов элементов работы - это небольшая
утилита, позволяющая просмотреть все используемые реквизиты
всех типов элементов работы
Tocls 1 Test Analyze Window Help				
[	Process Editor	»				Work Item Types	t
&  ST 4  S 3'		Attach to Process. .	Ctrl+Alt+P		Process Templates	►
		Device Security Manager,..  Connect to Device.,,		Global List	►  Work Item Field Explorer
		Device Emulator Manager		
		Connect to Database.  Connect to Server..		
		Connect to Team Foundation Server. .		
			Views	Index	
		Code Snippets Manager,.. Ctrl+K. Ctrl+B		
				

Choose Toolbox Items.

Add-ш Manager

Macros	►

Partner Products Catalog

Create GUID

Dotfuscator Community Edition

WCF Service Configuration Editor

External Tools .

import and Export Settings..,,

Customise...

Options...

iam Foundation uses to track the
work tem database and metrics

Indiv

Work I

Рис. 16.2. Инструменты редактирования шаблона процесса

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

постепенная настройка необходимых параметров.

Обзор существующих шаблонов

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

•	MSF for Agile Software Development - один из двух шаблонов,
входящих в поставку TFS. Описывает достаточно простой вариант
методологии MSF, используемый для разработки небольших
проектов. Входит в стандартную комплектацию TFS.

•	MSF for CMMI - шаблон, используемый для более компаний,
подразумевающий большее число типов элементов работы, а
также больше формальных процедур разработки. Входит в
стандартную комплектацию TFS.

•	Conchango SCRUM - шаблон, описывающий широко известную
гибкую методологию SCRUM. Не входит в стандартную
комплектацию TFS.

MSF for Agile Software Development

В этом шаблоне используются стандартные роли MSF, которые
подробно обсуждались выше. В рамках поддержки процесса MSF tor
Agile соответствующий шаблон объявляет следующие основные типы
элементов работы.

•	Сценарий (scenario) - функциональное требование к системе в
виде некоторого сценария взаимодействия пользователя и
системы, описанное на естественном языке как
последовательность действий. Сценарий описывает только
линейный путь развития событий, а для описания различных
ветвлений используются дополнительные сценарии.

•	Требование к качеству сервиса (Quality of Service Requirement, QoS)
- описание нефункционального требования к системе (то есть
требования, которое не может быть выражено в терминах
Д.В. Кознов	Введение в программную инженерию

сценария взаимодействия), например. быстродействие и
эффективность использования памяти.

•	Задача (Tusk) - задание на выполнение некоторой ограниченной
по объему работы в проекте. Для каждой роли задачи могут иметь
свою специфику: для разработчика это написание кода,
реализующего часть сценария или направленного на достижение
определенного качества, а для тестера - написание тестовых
сценариев.

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

•	Риск (Risk) - некоторый аспект управления проектом, который
может оказать влияние на ход проекта (как правило, негативное).

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

•	План разработки в Microsoft Project, настроенный на импорт
элементов работы, относящихся к области работы 'Разработка".
Испотьзуется для планирования работы разработчиков.

•	План разработки тестов - то же самое, только направленно на
планирования работы тестеров.

•	Список проблем - список выявленных проблем, которые
необходимо отслеживать (элементов работы с проставленным
флагом 'Is Issue").

•	Список (Check List) основных требований к проекту и их текущий
статус.

•	Список неупорядоченных элементов работы, которые нужно
приоритизировать и запланировать.

Кроме того, для поддержки процесса используются следующие
отчеты.

•	Ошибки по приоритету - показывает процентное соотношение в
проекте ошибок разной степени серьезности и, таким образом,
позволяет оценить степень эффективности тестирования.

•	Рейтинг ошибок - показывает соотношение вновь открытых
ошибок к закрытым и оставшихся открытых. Позволяет судить о
Д.В. Кознов	Введение в программную инженерию

"здоровье" продукта.

•	Сборки - позволяет оценивать изменение качества сборок.

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

•	Индикаторы качества - объединяет несколько индикаторов,
включая количество дефектов, уровень тестового покрытия и т.д.

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

•	Регрессия - показывает тесты, которые проходили раньше, но
теперь стали падать,

•	Реактивация - показывает то, сколько элементов работы заново
переходит в активное состояния после исправления.

•	Связанные элементы работы - еще один способ просмотра связей
элементов работы друг с другом.

•	Оставшаяся работа - показывает количество элементов работы,
которые закрываются, а которые остаются и появляются с
течением времени.

•	Незапланированная работа - показывает соотношение сделанного
к запланированному и к незапланированному

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

Scrum

Шаблон для работы в методологии Scram был разработан сообществом
разработчиков, в настоящий момент поддерживается компанией
Conchagp и доступен здесь ссылка: httpjVscrurnforteamsystcrn.corn. В этом
шаблоне используются стандартные роли Scrum, которые подробно
обсуждались выше. Определяются следующие элементы работы.

•	Product Backlog Item - высокоуровневое описание определенной
функционального или нефункционального требования. Содержит
описание, приоритет, установленный Product Owner, а также
предварительную оценку трудоемкости. Во многом аналогичен
сценарию MSF for Agile.
Д.В. Кознов	Введение в программную инженерию

•	Sprint - содержит информацию о текущем или запланированном
Sprint, включая текущее состояние и объем доступных для спринта
ресурсов.

•	Sprint Backlog Item - более низкоуровневое описание задачи,
сформированное самой командой. Аналогична задаче MSF.

•	Вид - ошибка, обнаруженная при тестировании. Ошибки
становятся частью Product Backlog и получают приоритеты от
Product Owner.

•	Sprint Retrospective - описание некоторого элемента (например,
проблемы, удачного нововведения), идентифицированного в
рамках Sprint Review Meeting и требующего дальнейшего изучения
или выполнения некоторых действий.

•	Impediment - нечто, реально или потенциально мешающее
эффективной работе команды. Во многом аналогично риску из
MSF.

Следует отметить, что описание элементов работы в шаблоне Scrum
выгодно отличается от MSF отсутствием большого количества
дополнительных, в большинстве случаев ненужных реквизитов, что
позволяет сконцентрироваться на наиболее важной информации. Но, с
другой стороны, в шаблоне для Scrum фактически не используются ни
причины переходов (для каждого перехода определена ровно одна
причина), ни правила, ограничивающие переходы. Таким образом, этот
шаблон использует лишь часть возможностей, предоставленных'IT’S.

Среди поставляемых с шаблоном отчетов следует выделить
следующие.

	Bugs Count - показывает количество ошибок, отсортированных по
состоянию и степени влияния на процесс тестирования.

•	Bugs Fixed and Found - соотношение найденных ошибок к
закрытым.

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

•	Вид Priority - показывает распределение ошибок по отношению их
влияния на процесс тестирования.

•	Вид Resolution lime показывает насколько быстро исправляются
найденные ошибки.
Д.В. Кознов	Введение в программную инженерию

•	Development То Test cycle time - демонстрирует, сколько проходит
времени между выполнением работы и началом тестирования по
этой работе.

•	Product Bumdown - отчет, демонстрирующий, как быстро
снижается количество работы, которую нужно сделать в контексте
Product Backlog. Может показывать прогресс по дням или
спринтам, а также позволяет увидеть общую тенденцию и
предсказать дату завершения работ.

•	Product Cumulative Flow - показывает общее состояние Product
Backlog в виде соотношения открытых и закрытых элементов, а
также их изменения со временем.

•	Sprint Burndown и Cumulative Flow - тоже самое, только для Sprint
Backlog.

Отдельного упоминания заслуживает система Task Board for Team
System, которая позволяет визуализировать представления основного
средства управления и мониторинга в Scrum - доски с задачами. Эта
система получает информацию о всех элементах Sprint Backlog с сервера
и визуализирует их в виде стикеров на доске, позволяя изменять их
состояния путем перетаскивания, см. рис. 16.3. Этот продукт можно
бесплатно	скачать	по	ссылке	ссылка:

httpy/wwyi'.scnimfoneamsystem.com'en/TaskBoard/defauit.aspx.
□аИ7

Task B<iird for Team System (SfTS Edition)

Рис. 16.3. Доска задач

ссылка: ht^://iTbdn.nbcrosofLcorn/en-us/vsrs2008,'aa718802.aspx

Заметим, что помимо настраиваемых глобальных списков в TFS
существуют и встроенные системные списки, связанные с различными
аспектами деятельности: группы и пользователи, состояния элементов
работы и причины перехода, списки итераций и областей работы и т.д.
3) ссылка: http://nisdn.nuciosoft.conVru-ru/tearnsystern/aa7188C)l(en-us).aspx
Д.В. Кознов	Введение в программную инженерию

Практикум

Требования к техническому оснащению. Организация процесса.
Модельная задача. Требования к студентам. Масштабируемость
практикума. Обзор тем и задач. Тема 1. Знакомство и создание проекта.
Тема 2. Работа с системой отслеживания ошибок. Тема 3. Работа с
системой контроля версий. Тема 4. Разработка модульных тестов Тема
5. Создание и конфигурация автоматической сборки. Тема 6. Настройка
шаблона процесса.

Общее

Практикум предназначен для практического усвоения ряда положений
программной инженерии и использует в качестве инструментария
продукт Microsoft Visual Studio Team System, поддерживающий многие
практики командной разработки ПО. В рамках практикума
предполагается освоение планирования, конфигурационного управления
(средства контроля версий и управление сборками), автоматического
тестирования и командной работы в рамках формально определенного
процесса разработки. Такой выбор обуславливается с, одной стороны,
важностью этих практик в реальном промышленном производстве, с
другой стороны, возможностями, предоставляемыми продуктом MS
VSTS. Ряд важных аспектов - проектирование, разработка требований и
т.д. не вишли в данный п ракли кум по причине ограниченности времени
- он рассчитывается на один университетский семестр. Мы старались
предложить максимально эффективный способ обучения основам
программной инженерии в рамках университетского процесса обучения,
прекрасно понимая, что полное освоение практик включенных в
данный практик™, а также и иных, равно как и продукта MS VSTS,
возможно при погружении в реальный индустриальный процесс.

Особо отметим, что нашей задачей является не столько обучение
продукту MS VSTS, сколько использование его в качестве основы для
практического освоения программной инженерии В современном
производстве без подобных инструментов уже не работают, и в
принципе, для обучения годится любой продукт такого класса.
Достоинство продукта MS VSTS заключается в его доступности для
целей обучения. Компания Microsoft ведет широкую работу по
бесплатному распространению своих продуктов в образовательных
целях в российских университетах, поэтому и данный продукт не
составляет труда получить Однако для его включения в учебный
процесс от преподавателей требуется индустриальный опыт
использования среды разработки Microsoft Visual Studio - важной
составной части MS VSTS - и существенная поддержка в области
администрирования (либо собственный опыт, либо поддержка
опытного сетевого администратора). При этих условиях ознакомление
с TFS (серверной компонентой VSTS) и рядом удобных клиентских
приложений (инструменты пакетов Visual Studio Team Suite и Team
Foundation Server Power Tools) не составит существенного труда, но
потребует значительной работы Мы надеемся, что данные
методические материалы помогут ее сократить и облегчить.

Требования к техническому оснащению

Занятие по данному курсу должны проводиться в компьютерных
классах, удовлетворяющих следующим условиям.

•	Все компьютеры должны находиться в домене Active Directory под
управлением доменного контроллера версии 2003.

•	Все учащиеся должны иметь логин и пароль для входа в этот
домен.

*	В рамках этого домена должен быть развернут Team Foundation
Server 2003 со всеми необходимыми компонентами (Microsoft SQL
2005, Sharepoint Server 3.0, Internet Information Server 6,0-^ ).

•	В рамках этого домена должен быть развернут Team Foundation
Build и настроен для работы с Team Foundation Server.

•	На всех компьютерах класса должна быть установлена Visual
Studio Team Suite 2008 и Team Foundation Power To о Is A

•	Ha сервере TFS должен быть импортирован шаблон процесса
разработки Scrum tor TF S-1.

Каждый участник практикума должен иметь по компьютеру Также
целесообразно, чтобы в классе была доска, проектор. Ио ходу
практикума могут всплывать различные общие вопросы, пробелы и пр
- и тогда на некоторое время занятия превращаются в лекции.
Занятия предполагается проводить со студентами, разбитыми на группы
в 5-6 человек. Общее количество одновременно обучающихся команд
может составлять 2-4 в одном классе. Возможен также запуск
нескольких параллельных команд в разных классах, по разному
расписанию и пр. Более крупные группы нежелательны, поскольку
существуют разовые, общие для всей группы действия - создание
проекта, изменение параметров процесса и пр. - и они потеряются в
более крупной группе.

В качестве методологии процесса разработки ПО мы предлагаем
использовать Scrum. Эта методология очень проста и хорошо
проецируется на учебные команды. Кроме того, Scrum получил в
последнее время значительное распространение в мире и в России.
Наконец, имеется и легко доступен Scum-шаблон для MS VSTS.

Теперь о проекциях Scum на наш учебный процесс. Product Owner - это
преподаватель, в роли Scrum-мастера может выступать один из
студентов - самый активный, самый заинтересованный. При этом
данная роль может допускать широкие вариации по активностям и
ответственностям - от простого слежения за временем и некоторых
формальностей (именно Scium-мастер будет выполнять некоторые
общие, единые для всех действия, а остальные будут наблюдать за тем,
как он это делает), до некоторых функций project manager. Здесь многое
зависит от самих студентов - найдется ли в группе один, которому
предмет будет интереснее всех, кто будет самым активным. Часто такие
студенты находятся, но иногда и нет В последнем случае большинство
обязанностей Scum-мастера возьмет на себя преподаватель. Ну и
наконец, вся группа учащихся будет являться scrum-командой,
работающей над реализацией некоторого проекта в рамках одного sprint.
Начальные требования к модельной задаче предоставляются в виде
backlog, из которого студенты изготовляют sprint backlog.

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

Модельная задача

Данный практикум проводится на основе некоторой практической
задачи, которую st nini-команда учащихся реализует в рамках практикума.
Требования к этой задаче следующие.

•	Она не должна быть очень трудной и допускать реализацию
студентами за 6-8 часов.

•	Задача должна быть распределенная, разные ее части, розданные
разным участникам, должны быть зависимы друг от друга.

•	Задача должна иметь более широкий контекст, чтобы ее можно
было выделить из более объемлющего backlog.

•	Задача должна хорошо подходить для написания модульных
тестов.

•	Задача НЕ должна содержать сложного пользовательского
интерфейса или других технических сложностей.

В качестве своего варианта мы предлагаем предлагаем реализацию
игры "балда" на компьютере. Правила игры можно найти здесь: ссылка:
httpy/ru.wikipedia.org/wiki/%rX)%91%D0%B0%D0%BB%D0%B4%D0%B0_(<

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

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

Требования к студентам

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

•	Они должны быть знакомы с курсом 'Введение в программную
инженерию"

•	Они должны владеть практическими навыками работы с языком
C# и средой разработки MS Visual Studio

О масштабируемости практикума

Практикум состоит из пяти занятий. По это не означает, что это ровно 5
встреч преподавателя со студентами. Одно занятие может выполняться
на нескольких встречах. Кроме того, в рамках нескольких встреч должна
происходить разработка модельной задачи. В зависимости от
подготовленности студентов может также потребоваться
дополнительная информация, дополнительные детали по тем или иным
основам MS VSTS, в частности по модульному тестированию. Этот
целесообразно оформлять как отдельную лекцию. В целом мы не
старались создать полный guideline оставляя значительную свободу для
импровизаций, имея также в виду различную подготовленность и
активность студентов и, кстати, преподавателей.

Обзор тем и задач

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

Тема 2. Па второй серии занятий студенты практикуются в
планировании работ на основе методологии Scrum, а также изучают
способы использования системы отслеживания задач TFS. Студентам
необходимо импортировать список пользовательских историй их файла
Excel в TFS, а затем детально спланировать будущий спринт и
распределить задачи.

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

в создании ветвей и интеграции изменений.

Тема 4. На занятиях четвертой серии студенты практикуются в
разработки модульных тестов средствами Visual Studio Team Developer.
На этих занятиях студенты должны освоить средства автоматической
генерации тестов, наполнить сгенерированные тесты содержимым, а
также научится изменять конфигурацию запуска модульных тестов и
считать тестовое покрытие.

Тема 5. Пятая серия занятий посвящена системе автоматических сборок
TFS. На этих занятиях студенты должны создать несколько определений
для автоматической сборки (build definitions) в разных случаях - с
тестами и без, с анализом кода и без и т.д. кроме того, студенты должны
настроить параметры непрерывной интеграции и рассылки
уведомлений.

Тема 6. На заключительной, шестой, серии занятий студенты должны
повести ретроспективный анализ выполненного Scium sprint, выявить
потенциальные способы оптимизации, а затем и применить их,
используя средства настройки процесса разработки TFS. На этих
занятиях студенты должны освоить изменение настроек системы
остлеживания задач средствами Team Foundation Server Power Tools.

Тема 1. Знакомство и создание проекта

Целями данного занятия является следующее.

1.	Разделить студентов на scrum-команды, определить и обсудить
Scrum-роли.

2.	Провести начальное знакомство с модельной задачей, которую
предстоит реализовать.

3.	Прояснить открытые вопросы по модельной задаче с Prodcut
Owner.

4.	Создать командный проект на TFS и добавить в него
пользователей.

Для разделения студентов на scrum-команды и выделения Scrum-
мастеров можно прибегнуть к жеребьевке, после чего перейти к
знакомству с задачей. Для этого руководитель курса должен заранее
приготовить следующие документы:

• Краткое описание основной концепции разрабатываемого
приложения.

* Список задач в формате product backlog.

Команды получают эти документы и в течение 20-30 минут обсуждают
их в рамках команды, готовя вопросы к хозяину продукта. Затем, в
течение 20-30 минут хозяин продукта отвечает на подготовленные
командами вопросы.

После того, как команды получили представление о разрабатываемом
продукте (модельной задаче), им необходимо создать командный проект
в MS VSTS и занести всех участников проекта в список пользователей.

Шаг 1. Создание проекта

Создание командного проекта осуществляется лидером команды по
следующему сценарию;

1.	Открыть Visual Studio Team Suite и окно Team Explorer в ней:
2.	Нажать кнопку соединится с сервером

5а

3.	Задать имя и порт сервера в открывшееся диалоге:
4.	После того, как соединение с сервером установлено, запустить
процедуру создания проекта, используя соответствующую команду
контекстного меню ( New learn Project... ):

Add Existing Team Project...

New Team Project.,.

Disconnect

Refresh

Team Foundation Server Settings r

Properties

5.	В качестве имени проекта необходимо указать TFSCourse<rofl>-
<имя команды>:
6. В качестве шаблона процесса разработки выбрать Scrum:
7.	Создать новый пустой раздел в системе контроля версий для
данного проекта:
New Team Project on 10.0.2.69

ИС

Select: a Process Г enolate

The process template oehnes key aspects of how the team project is managed The process template
may indude work item types, work products, reports, quei res, and precess guidance for youi team
project.

Which process template should be used to create the team project?

Agile Software Development with Scrum - V2.2.14165.003

Downlead additional Process Templates online

The foltowing describes the piocess template in тэге detail

Scrum is an aqile, light weight process that tan эе used tc manage and control software ano pioduct ~|
development usng iterative, incremental practices. Wrapping existing engineering practices,
including Extreme Programni ig end PUP, Scrum generates tile benefits of agile develop nent with
the advantages of a smnple implementation. Scrum signf icantty increases productivity and reduces
time to benefits while facilitating adaot '-e, empirical systems de 'elcpmen1

< Erevtous text > finish Zancel

8.	После выбора всех настроек, создать проект.

Шаг 2. Настройка прав

После того, как проект был создан лидеру необходимо выделить права
остальным участникам команды для работы с этим проектом. Для этого
ему нужно:

1.	Выбрать в свойствах проекта раздел Group membership:
А Show Project Portal...

Project Alerts ..

X Remove

D Refresh

Team Project bettings >

, Properties

Security,..

Group Membership...

Areas and Iterations...

Source Control

2.	В открывшемся диалоге включить всех участников в группы
Readers и Conrribuiors:
Project Groups on lestProject

Team Foundation Server: 10.0.2.69

Team project:	TestProject

Groups:

Name	____” Description

. (TestProject]\Peaders	Members of ths group have access to

[TestPro)ect]\Ptoject Administrators Members of this group can perform all

H> [TestProject]\Contributors Members of this group can add, modif

/j, [TestProject]\Build Services Members of this group have build serv

Show global groups	New... Remove Pioperties,,.

In order for team project users and groups to view reports or manage the
team project portal, you must also set security permissions in SQL Server
Reporting Services and in Windows SharePoint Services Site Administration.
For more information about setting permissions in Team Foundation Serves
see Managing Permissions.

Close

Шаг 3. Подключение проекта остальными участниками
команды

После того, как вес получили права на работу с проектом, каждый
участник команды должен на своей машине открыть Visual Studio и
добавить соединение с этим проектом. Выполняется это аналогично
пунктам 1-4 первого шага занятия.

Тема 2. Работа с системой отслеживания ошибок

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

1.	Создание элементов работы средствами Visual Studio и Team
Explorer.

2.	Импорт и экспорт элементов работы из/в Mcrosoft Excel.

3.	Назначение ответственных за элементы работы.

4.	Отслеживание текущего статуса посредством отчетов.

В рамках данного занятия предполагается провести планирование
работы команды по методологии Scrum. Команды уже провели
предварительное знакомство с проектов, а на данном этапе от них
требуется следующее.

1.	Импортировать содержимое списка требований в TFS, используя
средства импорта из Excel.

2.	Подробно рассмотреть )0 наиболее приоритетных
пользовательских историй.

3.	Обсудить возникшие вопросы с хозяином продукта.

4.	Провести детальное планирование и разбить пользовательские
истории на мелкие подзадачи.

5.	Распределить подзадачи среди участников проекта.

6.	Отчитаться перед хозяином продукта о том, какие
пользовательские истории были запланированы. При отчете
использовать отчеты TFS.

Шаг 1. Импорт списка пользовательских историй

Для того, чтобы загрузить пользовательские истории из Ехсе/-файла,
полученного командами на прошлом занятии нужно:

1. Выбрать команды Add work kerns using Microsoft Excel в
контекстном меню:
1 Add Product Backlog Item...

Add Work Item

Go to Work Item...

Add Query

SI

Add Work Items with Microsoft Excel,..

Add Work Items with Microsoft Project. ,

Team Project Process Guidance

Refresh

2. В открывшемся окне Excel настроить колонки таким образом,
чтобы они совпадали порядком и смыслом с колонками в
исходном Excel документе (для этого можно использовать
команды Choose columns ):

3. После того, как колонки настроены, скопировать значения из
Д.В. Кознов	Введение в программную инженерию

исходного Excel в редактируемый.

4.	Показать колонку с именем Work Item Туре и задать для все строчек
значение Product backlog item.

5.	Нажать кнопку

Publish

6.	Убедится, что при выполнении запроса АД pioduct backlog items,
видны все вновь загруженные пользовательские истории:
X All Product Backlog Items [Results] Microsoft visual studio

№□1

Elle Edit flew project Edd TeaQ ^ebug Data look Te$t Analyze Vfindcx^ ttet

J и i0i J 42 J[	= Д a 13 S ® и 	3 =

~Я|а д

X

&
5

(/?
I
з

Li

о
?

m

All Product Ba...Items (Results] j	▼ X

|	Error List |i^ Fencing Changes] [O Output | | 4$ History |	Test Results ।

Item(s) Saved

'jCToolbOi. I I^Propertes

Шаг 2. Создание sprint

После импорта списка пользовательских историй команда должна
создать элемент работы, соответствующий начинающемуся sprint.
Некоторое количество sprints уже создано по умолчанию при создании
проекта:
All Sprints [Results] Sprnt Burndow.. - Report Viewer । Al Product Ba...Items [Results] ж x

Query Results. 12 results found (1 currently selected).

./ Iteration Path_____________________________________

5crumProject\Release l\5prirt 1

Descnpbon | Capa... Sprint Start (Scrum} Sprint End

22.12.2009 21:42:42	02.01.200*

ScrumProject\Release l\Sprint 2

5crumProject\Release l\Sprlnt 3
5cnjmProject\Relea5e l\5print 4

ScrjmProject\Release l\Sprint 5

ScrumProject\Release l\5print 6

ScrumProject\Release 2\Sprint 1

5crumProject\Release Z\5print 2

ScrumProject\Release 2\Sprint 3

ScnjmProject\Retease 3^Sprint 1
5crjmProject\Release 3\5print 2

ScrjmProject\Release 3\Sprirt 3

Для активации первого спринта ему необходимо установить дату
начала, дат}' окончания и количество часов, которые команда может
потратить в этом спринте.

Шаг 3. Формирование Sprint backlog

После обсуждения открытых вопросов по 10 наиболее приоритетным
пользовательским историям команда должна приступить к
планированию текущего sprint и формированию sprint backlog. Для этого
ей необходимо рассмотреть список всех пользовательских историй и
разбить его на список более мелких задач. При этом для каждой задачи
необходимо создать элемент работы типа sprint backlog item и проставить
следующие атрибуты:

1.	В качестве sprint указать Releasel/Spnntl.

2.	Добавить связь с соответствующим элементом product backlog, а
также со всеми связанными элементами работы.

3.	Установить Estimated efforts и Work remaining в соответствии с
оценкой команды.

4.	Задать ответственного за задачу ( Owned By).

Выполнить все операции нужно средствами Visual Studio и Team
Explorer.
Д.В. Кознов	Введение в программную инженерию

После создания и распределения задач каждый член команды должен на
своей машине убедиться, что выданные ему задачи отображаются в
результатах запроса Му Sprint Backlog Items.

Тема 3. Работа с системой контроля версий

Основной целью данного занятая является освоение системы контроля
версий Team Foundation Server и её интеграции с системой
отслеживания задач. Занятие предполагает выполнение следующих
действий.

1.	Разработка кода модельной задачи средствами Visual Studio и
внесение его в систему управления версиями.

2.	Проставление связей между вносимыми изменениями и
элементами системы отслеживания задач.

3.	Создание параллельно поддерживаемых веток кода.

4.	Интеграция изменений, сделанных параллельно в одном файле
или в разных ветках кода.

Шаг 1. Разработка кода

Перед началом работы команде необходимо создать решение ( solution )
средствами Visual Studio, включив опцию Add to Source Control:
Sew Project

ПЕ

Project types:

lennpiates:

Ы visual С*

Wndows

Web

Smart Devte

0 Office

Database

Reporting

 Test

WCF

Workflow
И Database Projects
0 Other Languages

Distributed Systems
0 Other Project Types
0 Test Projects

Visual Studio installed templates

75] Windews Forms Application

A5P.NET Web Appkation

JjWPF Application

Д Consde Application

'•/ Outlook 2007 Add-n

Word 2007 Document

My Templates

jj Search Online Templates...

Class Library

A5P.NET Web Service Application
flfr WPF Browser Application
j Excel 2007 Workbook
3$ WCF Service Application
^Windows Forms Control Library

A project for creathg an appication with a Windtows Forms user interface ( NET Framework 3.5)

Name.	I WindowsFormsAppkcatlon3

Location	| E:\User s\arhar)gel\ScrumTcst	Browse ..

Spkition:	(create new Solution	=	” p Create directory for solution

Solution Name: | Window$FormsApplicdhon3	P Addto ^rceCor^di

OK I Cancel

В открывшемся после создания проекта окне необходимо выбрать
командный проект, в систему контроля версий которого нужно добавить
данное решение:
Затем необходимо внести все данные в систему контроля версий,
используя команду Check-in, открывающую диалог:
Check In Source Files Workspace: My Workspace

HE

J

Source Files

J

Work Items

ChecN-in
ryotes

-3

Polity

Waring:

Cominent:

1	d  ▼		
Name	I Change	wider
0 Lj^WindowsFormsAppiicationS.sIn	add	E: \Users\arhangel\5crumTest^ Windows Form..
2] WindowsFormsAp|xcation2.vc,	. aac	E: ^Users\arhangel\ScrumT est^ WindowsForm..
3 ^jporml cs	ado	E: \Users\a' hangel\Scr ur.1T asH Whdo-vsForri ।,
0	Form 1 Designer.es	add	E: \Users\arhangel\ScrumT est^ WindowsForm..
3 program.es	add	E: 'Use. s\arhangelt.crum lesrl WndoAisPorm,
PI ]Windo"rsFomsApp>ication2.C'	add	E: \Users\arhangelVic. umlestlWirdo-jsForm.
0 WindowsFormsflppiication2.cs.	adc	E: ^Users\arhangel\5crumT est^ WndowsForm..
3 IAsseinolyInfo.es	add	E: \Users\a-hanoel\5cr umT est.'. Windo-4SForm.
0 ^Resources. Designer.es	add	E: ^Users\arhangel\ScrumT est^ WindowsForm...
И iResourcas.resy	aac	EnUsersl.arhanQeli.Vruml esr|WndomsForm.
3 Settings, Oesigncrcs	Odd	E: \User s\a"hangel\5cr umT es0 Windo-racorm,
0 _J Settings, settings	add	E: ,|Users\arhangel\Scr umT est^ WindowsForm..

Checkin I Cancel

В этом диалоге необходимо внести комментарии к вносимому коду а
также, на вкладке Work items, связать вносимое изменение с элементами
работы:
Шаг 2. Создание ветки кода

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

1.	Открыть Source control explorer:
X WindowsFormsApplication2 - Microsoft Visual Studio

□Тх

hie Edit View Project Build Team Debug Data Tools Test Analyse Window Help

a и e * u < и ’ о- ’	► Debus

= S । |э $	< uo± s Её » Ж К 551 4 41 IEB ffi Г

с*

(Л



2

s
з
m
£
S’
<5

Error List j*Pending Changes) i3 Output^	1f*)History | ?=| Test Resuts|

Ready

Я
e
CD
И

xoqooi

2.	Выбрать нужный проект и в контекстном меню команду Branch:
Н-ГД 5crumProject

Ё га TestPro

а»	Get Latest Version  Get Specific Version...	
S3	Check Out for Edit...  Lock....  Unlock  Delete  Rename  Undo Pending Changes...	
£-3  *п 1	Check In Pending Changes.,, Shelve Pending Changes...	
£	View History  Compare...  Find in Source Control  Windows Explorer  Alert on Change...	►
	Branch...  Merge. .  Move. .  Apply Label...  Quick Label...	
	Properties...	
	Refresh	
3.	В открывшемся окне задать целевую папку куца необходимо
скопировать данные для новой ветви:

Branch

4.	Внести изменения с помощью команды Check-in

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

Шаг 3. Объединение изменений

После того, как в отдельные ветви было внесено некоторое количество
изменений, необходимо перенести изменения из отделенной ветви в
основную, используя команду Merge:
WindowsFormsApplication2

IF WindowsFormsApplicat

Й □ Properties

a TestProject

	Get Latest Version  Get Specific Version...
	4/	L_»+|  -3	A	Checkout for Edit...  Lock...  Unlock  Delete  Rename  Undo Pending Changes...
	Check In Pending Changes....  Shelve Pending Changes...
	View History  Compare...  Find in Source Control	t  Windows Explorer  Alert on Change...
	Branch...

Merge...

Move...

Apply Label.

Quick Label,..

Properties...

Refresh

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

Все конфликты необходимо разрешить, используя команду Resolve и
утилиту для объединения результатов.

После разрешения конфликтов все изменения внести в систему
контроля версий посредством операции Check-in.

Тема 4. Разработка модульных тестов

На данном занятии команды должны разработать набор модульных
тестов, покрывающих функциональность, разработанную на занятии
предыдущем. В рамках данного занятие предполагается освоить
следующие возможности MS VSTS.

1.

2.

з.

4.

Автоматическая генерация тестов.
Наполнение тестов содержимым.
Запуск тестов и просмотр результатом.
Изменение конфигурации работы тестов.

Шаг 1. Авгоматическая генерация гестов
Д.В. Кознов	Введение в программную инженерию

Для ускорения разработки тестов команды могут воспользоваться
возможность Visual Studio по автоматической генерации тестов. Для
этого необходимо воспользоваться командой Test/New Test и выбрать
Unit Test wizard в открывшиеся окне:

После создания тестового проекта, будет предложен выбор из тех типов
и методов, для тестирования которых необходимо создать заглушки:
В этом диалоге команда должна выбрать все основные классы и
методы, которые планируется покрыть модульными тестами.

Шаг 2. Наполнение тестов содержимым

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

/// < summary 

///A test for Multiply

///«/summary’'-

[TestMethod()l

public void MultiplyTestQ

{

// TODO: Initialize to an appropriate value

Calculator target = new Calculator!);
Д.В. Кознов	Введение в программную инженерию

int а = 0; // TODO: Initialize to an appropriate value

int b = 0; // TO ЕЮ: Initialize to an appropriate value

int expected = 0; //TODO: Initialize to an appropriate value

int actual;

actual = target.Multiply^, b);

Assert.AreEqualfexpected, actual);

AsserLlnconclusive("Veriiy the correctness of this test
method.");

}

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

Шаг 3. Запуск тестов

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

Шаг 4. Изменение конфигурации тестов

Для того, чтобы проанализировать качество разработанных тестов,
команда должна вычислить тестовое покрытие. Для этого её
необходимо:

1. Открыть файл конфигурации запуска тестов, автоматически
добавленный к решению при создании тестов:
X WindowsFormsApplication2 - Microsoft Visual Studio

Ые Bew Protect fcuid lean bebuj Data Tools left flQaiyae Wnd04 belt

JO ’ J 0 *^а|-?’0-’4Э’СЯ|к Debug

i t) •> *> W I 5 S3 3S =3 £ i i2 JS b i 3 % к. « I« «I 3 §

Solution Explorer - Sciubon 'WindowsFormsApplicati.

X

i1
£

4

3

В

Solution 'WndowsFormsApplcationZ (2 projects)

Solution Items

[LocalTestRcri.testrunconfig

0^2 WindowsFormsAppBcation2.vsmdi

Й TestProject 1

В	Properties

E	References

•	O Micro soft . VisudSt udio. Quality Took. Unit! e«

•	J System

4J System.Core

•	a System .Data

•	O System.Data .Dat-aSetExtenslons

•	O System. Deployment

•	Q System. Drawing

-	Q System.Windows.Forms
О System.Xml
О System.Xmi.Linq

W^ndowsFormsAppiical:cn2

AuthoringTests.txt

CalcjlatorTest.cs

В i 3 WindowsFormsAppiication2

$-v Properties

:ontextlnstance

t Unit Tests

textInstance;

ntext which provides
nationality for the current

:	Toolbox| 'jffProperties)

Error Ust |Pending Changes, [EJ Output |History |[j=] Test Results |

nstance;

2. На открывшемся диалоге выбрать вкладку Code Coverage и
установить то, какие именно проекты нужно анализировать:
localtestrun.testrunconfig (Modified)



Geneial

-ontrollei and Agent

Code Coverage

Deployment

Hosts

Setup and Cleanup Scripts

Test Timeouts

Web Test

Select artifacts to instrument’

Artifacts to instrument__________| Path________________________________

Q TestProjectl.dll	<Solution Directory >\TestProjectl\t»nV

0 WmdowsFormsApplfcatlcn . <5olutlon Directory >\Windw#$FormsAp

bj______________________________________________I 2d

Add Assembly...

17 Instrument assemblies in Qlace

Re-slgnrg key file:

Code coverage measures what source code Is executed during test
execution. Select the artfact to instrument for code coverage analysis.
Artifacts are assemblies and A5P.NET Web sites.

Appr>

3. После сохранения конфигурации запустить тесты и активировать
опцию Show Code Coverage Coloring:
Тема 5. Создание и конфигурация автоматической
сборки

На данном этапе команда должна создать в своем проекте процедуру
автоматической сборки. При этом должно быть создано несколько
процедур:

1.	Простая процедура, включающая только сборку.

2.	Полная процедура, включающая тесты и анализ кода.

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

1.	Простая сборка должна запускаться после каждого внесенного
изменений, но не чаше чем раз в 5 минут.

2.	Полная сборка должна запускаться каждую ночь.
Все результаты сборки, проведенной TFS, выкладываются в
разделяемую папку, на запись в которую есть права, у пользователя, с
правами которого работает сервер автоматических сборок (обычно -
TFSBuild), а также у пользователя, с правами которого работает сам TFS
(обычно - TFSService). Как правило, учащиеся не обладают
достаточным количеством прав для создания такого рода папок,
поэтому они должны быть заранее подготовлены преподавателем.

Для создания простой сборки необходимо обратится к окну Team
Explorer, после чего в разделе Builds выбрать команду Build Definitions:

Вызов этой команды приведет к открытию мастера, в котором нужно
задать следующие параметры сборки:

1.	Задать имя и описание сборки:
2.	На закладке Project File, создать новое описание сборки используя
кнопку Create, после чего задав проекты и конфигурации для
сборки:

MSBuild Project File Creation Wizard

Select and order solutions to build

Configurations

Opborts

Solutions are listed based on the specified workspace. Selected solutions Wil be built sequentially in
dhe order specified below

Select and order solutions to tuld:

F (Select fill)

0 $/ScrurnProjectpMndowsFarnsAppllcatlon2/wridDw^ormsApplication?.dn

П $/5crumPro]ect/UZncfow5FormsApplication2’branchfWndow5FormsAppicatDn2.5ln

< previews |P Kjext >	|	 Finish | Cancel [
MSBuild Project File Creation Wizard

Select configurations to build

Selections

Options

Solutions will be buft in the listed conhouratons.

< previous || Hext>~

Cancel

3.	На закладке Build Defauks создать определение агент а-сборщика
используя кнопка7 New. Для агента указать имя, описание, и IP
адрес сервера сборок (как правило, совпадает с сервером TFS):
4.	На закладке Build Defaults также необходимо задать имя
разделяемой папки, в которую будут сложены результаты-
После того, как определение сборки было создано, её необходимо
запустить, используя команду Queue new build:
ScrumProject

____। Work Item Templates

i+	J	Work Items

E	~J	Documents

El	J	Reports

F	_.	Builds

All Build Definitions

J Alerts	View Builds

Source Contra

*ihfl Queue New Build...

Edit Build Definition...

Delete

'i Add to My Favorites

Properties

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

Шаг 2. Создание сложной сборки

Создание сложной сборки проходит во многом аналогично созданию
сборки простой, за исключением нескольких шагов:

1. На закладке опций при создании проекта сборки необходимо
включить автоматический запуск модульных тестов и анализ кода:
2. На закладке Build Defaults необходимо задать другую папку для
сбора результатов:
Д.В. Кознов	Введение в программную инженерию

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

Теперь нужно добиться выполнения статического анализа кода во время
ночной сборки. Для этого необходимо активировать анализ кода в
настройках соответствующих проектов:
Следующая же собранная сборка будет содержать большое количество
предупреждений от анализатора:
Шаг 3. Настройка непрерывной интеграции

На данном шаге учащимся необходимо исправить описания сборок
таким образом, чтобы они выполнялись автоматически при
определенных условиях. Простой вариант сборки должен запускаться
автоматически после каждого внесения изменений, но не чаще, чем в
пять минут. Для того, чтобы добиться этого необходимо:

1.	Вызвать команду Edit build definition:
[-1 ScrumProject

__। Work Item Templates

L±l J Work Items

+

+

Documents

Reports

’J All Build Definitions

• Build with test and cede analysis

J Alerts
Source

View Builds

\ D Queue New Build

Edit Build Definition...

X Delete

Add to My Favorites
: j Properties

2.	Задать настройки автоматического запуска на закладке Trigger:
3. Настроить политику очистки сборок на зактадке Retennon Policy.
Это необходимо для того, чтобы избежать быстрого исчезновения
места на машине-сборщике и для удаления из базы TFS
информации о второстепенных сборках:
Д.В. Кознов	Введение в программную инженерию

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

1.

В контекстном меню проекта выбрать команду Project Alerts:

j Show Project Portal..

В 1 w

Project Alerts

S _l Ri

A Bi

P emove

Refresh

u

L

Team Project Settings ►

Properties

2. В списке событий, о которых нужно слать нотификации, выбрать
''a build completes" и задать список адресов электронной почты, на
которые нужно отправить сообщение:
После настройки простой сборки для запуска при внесении изменения
необходимо проверить работу системы - внести некоторое изменение и
дождаться сообщения о сборке.

Аналогичным образом можно настроить и автоматический запуск
сложной сборки каждый день в определенное время.

Тема 6. Настройка шаблона процесса

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

В рамках ретроспективы команда должна предложить некоторые
Д.В. Кознов	Введение в программную инженерию

изменения к элементам работы, вовлеченным в процесс, а затем и
реализовать эти изменения.

Шаг 1. Ретроспектива

На ретроспективе команда в течение 20-30 минут обсуждает то, как
прошел данный спринт, выделяя позитивные и негативные моменты, а
также предложения по изменениям.

Все комментарии должны быть внесены в соответствующий элемент
работы типа Sprint retrospective, а для каждого предложения по
улучшению заведены элементы работы типа Spiint backlog item, а для
каждого идентифицированного негативного момента, требующего
устранения - элемент работы типа Impediment.

Результаты ретроспективы необходимо обсудить с хозяином продукта.

Шаг 2. Изменение элемента работы

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

1.	Открыть тип элемента работы на редактирование с помощью
команды меню Tools:
Window Help

Attach to Process...

Ctrh-Alt+P

Open WIT from File

Process Templates

5ft
da

U

Device Security Manager.

Connect to Device...

Device Emulator Manager. .

Connect to Database,..

Connect to Server...

Connect to Team Foundation Server...

Code Snippets Marlager... Ctrl+K, CtrM-B

Choose Toofcox Rems...

Gobal Lbt

Import WIT

Work Rem Field Explorer

Export WIT

Status

Owned By

Current Status |[bcf Done

Add-m Manager...

Macros

Partner Products Catalog

Create QUID

Dotfuscator Community Edtico

WCF Service Configuration Editor

External Tods...

Import and Export Settings...

Customize...

Options...

2.	Выбрать нужный элемент работы в открывшемся диалоге:
3,	На закладке Fields добавить, удалить или изменить необходимые
поля:
%. WindowsFormsApplicatton2 • Microsoft Visual Studio

File gdt view project Bold Tea® Qebug Data £oUs Tejt Agalyze Window Het-

-£j-4 ► Debug

* Any CPU

Li
(Л
0
£
3
m

feJ

10.0.2.69_Scru...acklog Item.wit

Work Item Type

View XML |

Name

| Product Backlog Item

ЖЕЯИ

ГЕ555ЯЕЯ

Type

Ref Name

State

4

Rev

Iteration Path

Iteration! D

Title

String

System T itle

Name

Changed By

Reason

Dwciirton

Fields Layout | Workflow |

1 New J?' Open X telete

String
Integer
String
String

T reePath

Integer

String
String
DaleTime

Assigned T о

Work Item Type

Created Date

ItenKs) Saved

I System Stale
System Rev
System ChangedBy
System R eason
System IterationPath
System I terationld
SystemAwgnedTo
System WoikltemT ype
System CrealedDate

leaijscloig^ xoqioo'j

.J t J - u J J

3

▼ x

4.	На закладке Layout изменить соответствующим образом
визуальное представление элемента работы
5.	На закладке Workflow внести необходимые изменения в
жизненный цикл элемента работы:
После внесения всех изменений их нужно сохранить, а затем убедиться,
что они применились к существующим и к вновь создаваемым
элементам работы.

При использовании с Windows Server 2008 необходимо использовать
11S 7.0.

21 ссылка: httpy/insdn.microsoft.com/en-us/tfs2008.'bb980963.a5>px

3) ссылка: http^/scrumtorteamsysteni.com/en/default.aspx
Д.В. Кознов	Введение в программную инженерию

Вопросы и задания по курсу "Введение в программную
инженерию"

Методические рекомендации

Рекомендация 1

Задания на основе карт памяти (mind maps) следует использовать
постепенно вот в каком смысле. Учащиеся должны овладеть этой
техникой - оказывается, для этого нужно затратить некоторое время.
Нет необходимости проводить специальный тренинг - достаточно
просто объяснить, что это такое и как этим пользоваться, и сразу же
приступить к использованию. Но ходу депа целесообразно давать
нужные рекомендации. После нескольких карт памяти, составленных
самостоятельно, студенты осваивают эту технику. Первые карты памяти
целесообразно рисовать "вручную". Впоследствии, особенно при
"массовом" процессе использования карт памяти, целесообразно
пользоваться инструментами. Мы рекомендуем продукт Comapping
(ссылка:	http://www.coiTiapping.corn). Дальнейшие детали по

использованию карт памяти в преподавании программной инженерии
можно найти в работах [1-3].

Рекомендация 2

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

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

Рекомендация 4

Часто задания с помощью карт памяти оказываются не совсем картами
памяти. Исчезает центральный объект, вместо него появляется
произвольных "плоский'' гриф. Также полезно оказывается рисовать
имена связям. Мы все равно называем такие графы картами памяти,
чтобы терминологически не усложнять ситуацию.

Литература

1.	Д.В Кознов, Я.А Кириленко. Опыт сочетания теории и практики
в обучении программной инженерии . Труды III Международная
научно-практическая	конференция	"Современные

информационные технологии и ИТ-образование" 201)8 год. ссылка:
hnp 7/2008.itedu.n.vpages/Conference- works.

2.	D.V.Koznov, M.Y. Pliskin. Computer-Supported Collaborative Learning
with Mind-Maps. T. Margaria and B. Stefien (Eds.): ISoLA 2008. CC1S
17, pp. 478-489, 2008. Spiinger-Verlag, Berlin Heidelberg, 2008.

3.	Д.В.Кознов. Методика обучения программной инженерии на
основе карт памяти. Системное программирование. / Вып. 3, под
ред. А.Н.Терехова и Д.Ю Булычева. СПб : Изд. СПбГУ. 2008. С.
121-140. ссылка: http7/www.sysprog.into.

Лекция 1. О предмете изучения

Вопросы
Д.В. Кознов	Введение в программную инженерию

1.	Что такое программная инженерия'?

2.	Назовите дату зарождения программной инженерии как отдельной
науки.

3.	В чем отличие программной инженерии от информатики?

4.	В чем отличие программной инженерии от системотехники?

5.	Приведите примеры дисциплин информатики и программной
инженерии (дисциплины не пугать с учебными предметами).

6.	Что такое ПО?

7.	Перечислите характеристики ПО по Ьруксу и кратко
характеризуйте каждую.

8.	С какими иными видами человеческой деятельности соотносится
создание ПО в данном разделе?

Задания

1.	С помощью карт памяти максимально полно ответе на вопрос -
что такое программная инженерия, учитывая все измерения этого
термина, мелкие и крупные детали.

2.	С помощью карт памяти нарисуйте взаимосвязи характеристик
ПО по Бруксу, пользуясь надписями на дугах.

Лекция 2. Процесс разработки программного
обеспечения

Вопросы

1.	Что такое процесс создания ПО?

2.	Расскажите о причинах отсутствия универсального процесса
разработки ПО.

3.	Почему возможно и целесообразно стандартизировать процесс на
уровне компании?

4.	Что такое стандартный и конкретный процессы и как они
соотносятся?

5.	Чем отличаются между собой текущий и конкретный процессы?
Какие методологии разработки ПО поддерживают понятие
конкретного процесса и какими средствами?
Д.В. Кознов	Введение в программную инженерию

6.	Дайте определение деятельности по совершенствованию
процесса.

7.	В чем главная трудность совершенствования процессов в
компаниях?

8.	Перечислите основные направления улучшения процесса.

9.	Расскажите о стратегии organization pull к внедрению инноваций.
Приведите примеры.

10.	Расскажите о стратегии technology push к внедрению инноваций.
Приведите примеры.

И. Расскажите о достоинствах, недостатках, а также возможных
рисках этих стратегий.

12.	Что такое модель процесса?

13.	Что такое фаза процесса?

14.	Что такое вид деятельности?

15.	Почему нельзя отождествлять фазы и виды деятельности? Когда и
по каким причинам это все таки происходит на практике?

16.	В чем достоинства водопадной модели? В чем ее историческая
роль? В чем ее недостатки?

17.	Как в рамках водопадной модели предполагается работать с
рисками?

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

J9.	Чем виток спиральной модели отличается от фазы в водопадной
модели? Приведите пример последовательности витков
спиральной модели. Опишите условия, при которых спираль
завершается.

20.	Расскажите про второе и третье измерение спиральной модели.
Опишите различные секторы витка спирали.

21.	В чем достоинства и недостатки спиральной модели? Каковы
ограничения этой модели?

22.	Как в рамках этой модели предполагается работать с рисками?

Задания

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

Лекция 3. Рабочий продукт, дисциплина обязательств,
проект

Вопросы

1.	Дайте определение рабочего продукта. Приведите примеры.

2.	Чем отличается рабочий продукт от компоненты ПО?

3.	Расскажите, что такое нематериальный рабочий продукт.

4.	Опишите, как "работает" дисциплина обязательств.

5.	Приведите примеры других видов отношений между людьми.

6.	Расскажите о границах применения дисциплины обязательств.

7.	Что такое проект и чем он отличается от других форм организации
бизнеса и производства?

Задания

1.	Нарисуйте с помощью карт памяти взаимосвязь рабочего
продукта и дисциплины обязательств.

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

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

4.	Соедините в одну карту памяти результаты выполнения заданий
1-3.

Лекция 4. Архитектура ПО

Вопросы

1.	Дайте определение архитектуре ПО. Расскажите, какие аспекты
разработки задействует это понятие.

2.	Расскажите о причинах множественности точек зрения при
Д.В. Кознов	Введение в программную инженерию

разработке ПО.

3.	Как по вашему мнению, множественность точек зрения помогает
или мешает в разработке?

4.	Перечислите и кратко прокомментируйте разные виды диаграмм
U ML.

Лекция 5. Управление требованиями

Вопросы

1.	В чем трудность управления требованиями? При ответе на этот
вопрос имейте в виду другие инженерные области и сферы
бизнеса. Старайтесь отвечать на вопрос с наружи программной
инженерии, а не изнутри.

2.	Перечислите способы формализации требований. Нод
формализацией имеется в виду способ нс промежуточной, а
финальной фиксации.

3.	Расскажите о способах и техниках ''вытягивания" требований.

4.	Перечислите разные виды документов, формализующих
требования.

5.	Расскажите об отличии функциональных и нефункциональных
требований.

6.	Расскажите о типовом цикле работы с требованиями.

7.	Перечислите типовые ошибки при работе с требованиями.

Задания

1.	Нарисуйте на одной карте памяти ответы на вопросы 2-5.

2.	Добавьте к это карте памяти ответ на вопрос 6.

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

Необходимо реализовать программную систему для са//-центра
крупного банка, обслуживающего частных лиц. Банк хочет начать
предоставлять новый вид услуг - по телефону. Кроме того,
система должна уметь учитывать рабочее время операторов
центра (дифференцированно, собирая информацию о том, какой
вид работ, а также простои сколько занимают времени). Система
также должна быть интегрирована с различными электронными
справочниками и базами данных, содержать информацию о
постоянных клиентах, маршрутизировала бы их к "своим''
операторам (которые с ними общались и их помнят). Часть
функций система должны быть доступны через Интернет, так как
менеджеры call- центра должны иметь доступ к текущей
статистики, находясь в любой точке мира, а также в дороге (банк
- сильно распределен, его са//-менеджеры участвуют в большом
количестве международных деловых встреч, конференций и пр.)
Система должна также обеспечивать максимальную
защищенность данных от несанкционированного доступа - ее
данные являются жизненно важными, критичными для банка, так
как содержат информацию о финансах его клиентов, среди
которых есть самые богатые люди мира.

Лекция 6. Конфигурационное управление

Вопросы

1.	Приведите примеры проблем в проектах, где нет хорошего
конфигурационного управления.

2.	Неформально объясните, какие задачи выполняет
конфигурационное управление в проекте.

3.	Дайте формальное определение конфигурационному управлению.

4.	Расскажите об известном противоречии - абсолютной
сохранности и удобного доступа.

5.	Приведите пример артефактов проекта, которые могут
"подпадать" под конфигурационное управление.

6.	Приведите пример артефактов проекта, которые могут не
"подпадать" под конфигурационное управление, подпадающих

7.	Что является главным артефактом конфигурационного управления
и почему.
Д.В. Кознов	Введение в программную инженерию

8.	Перечислите основные функции версионного контроля.

9.	Что такое управление сборками?

10.	Что такое непрерывная интеграция. В каких известных вам
методологиях она используется и почему (на ваш взгляд).

11,	Расскажите о понятии baseline.

Задания

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

2.	Нарисуйте типовой сценарий работы сборщика.

3.	Нарисуйте различные макро-сценарий сборки (ночной, по
запросу, в режиме постоянной интеграции и т.д.)

Лекция 7. Тестирование

Вопросы

1.	Перечислите и кратко охарактеризуйте различные способы
контроля качества ПО.

2.	Дайте определение тестирования и кратко прокомментируйте его.

3.	Что означает в контексте тестирования ожидаемое поведение
программы ?

4.	Что входит в искусственные, специально заданные условия
воздействия на систему, которые имеются в виду в определении
тестирования?

5.	В чем важность концепции теста?

6.	В чем преимущества автоматического тестирования перед
"ручным'?

7.	В чем трудности автоматического тестирования?

8.	Приведите свои собственные примеры проблем с интерфейсами к
тестируемым системам.

9.	Приведите примеры того, как прогон тестов может влиять на
поведение системы.

10.	В чем смыл факторизации входных значений при тестировании?
Д.В. Кознов	Введение в программную инженерию

11.	Расскажите о разных вариантах организации команды
тестировщиков.

12.	Перечислите и кратко охарактеризуете виды тестирования.

Задания

1.	Как на ваш взгляд концепция тестирования системы методом
черного ящика связан с типичной организацией команды
тестеров щи ков и ее взаимодействия с командой разработчиков? В
ответе учтите различные стратегии, принятые в разных известных
вам метооологиях разработки ПО. Ответ нарисуйте в виде карты
памяти.

2.	Нарисуйте в виде карты памяти взаимодействие между
различными видами тестирования

3.	Нарисуйте пример жизненного цикла ошибки.

Лекция 8. Диаграммные техники в работе со знаниями

Вопросы

1.	Какова роль актеров при построении диаграмм случаев
использования?

2.	Что такое случай использования и чем он отличается от
произвольной функции системы.

3.	Какие бывают виды актеров?

4.	Расскажите о бизнес-диаграммах случаев использования.

5.	Расскажите об основном предназначении диаграмм случаев
использования. Попробуйте самостоятельно оценить их
полезность.

6.	Расскажите о разных вариантах применения диаграмм случаев
использования.

7.	Расскажите о применении случаев использования в управлении
разработкой.

8.	Расскажите об основной идее цикла автор/рецензент.

9.	Как этот цикл можно использовать при извлечении знаний из
эксперта? Расскажите о дополнительных особенностях этого
процесса. Примерьте эту технику для собственного использования
и поделитесь возникшими соображениями.

10.	Расскажите об истории карт памяти, а также о том, что это такое.

И. Перечислите и кратко охарактеризуйте основные направления по
практическому использованию карт памяти. Как именно вы
используйте карты памяти? Собираетесь ли вы их использовать?

12.	Расскажите о продукте Comapping и его основных возможностях
по работе с картами памяти

Лекция 9. MSF

Вопросы

1.	Расскажите об истории разработки MSF.

2.	Расскажите об основных принципах MSF.

3.	В чем главные новшества MSF?

4.	Чем отличаются версии MSF 3.x от 4.x?

5.	Что такое 1Т-решение?

6.	Что такое управление компромиссами? Приведите примеры.

7.	Расскажите о модели команды MSF. В чем ее свобода и где она
заканчивается?

Задания

1. Нарисуйте модель команды MSF, изобразив также аспекты
масштабирования команды, в том числе возможность сочетания/
не сочетания различных ролей в одном человеке.

Лекция 10. CMMI

Вопросы

1.	Что такое СММГ? Постарайтесь не описывать CMMI, а в
нескольких предложениях его определить, дать компактное и
точное определение.

2.	Кратко расскажите историю развития стандарта CMMI. Чем СММ]
отличается от СММ?

3.	Перечислите и кратко охарактеризуйте уровни СММ1.

Лекция И. "Гибкие" (agile) методы разработки

Вопросы

1.	Расскажите о принципах "гибких" методов разработки.

2.	Какие, по вашему, существуют ограничения в применении гибких
методов?

3.	Перечислите известные вам "гибкие" .методологии разработки
ПО.

4.	Расскажите о принципах ХР. С чем, на ваш взгляд, могут
возникнуть трудности при практическом внедрении ХР?

5.	Расскажите о главных идеях Scrum. При этом не начинайте
длинный рассказ про всю методологию в целом, а также не
перечисляйте ее сонные артефакты. Дайте качественное
описание из вне.

6.	Расскажите, как устроена самоорганизуемсоть команды в Scrum?
Как методология ограждает свободу команды и какие выгоды из
этого извлекаются для проекта?

7.	Расскажите об обязанностях Scum-матера.

8.	Расскажите об обязанностях Product Owner.

9.	Расскажите о задачах ежедневных встреч.

Лекция 12. Обзор технологии Microsoft Visual Studio
Team System (VSTS)

Вопросы

1.	Расскажите об основных составляющих продукта MS VSTS.

2.	Расскажите о функциональности TFS.

3.	Расскажите о различных клиентских приложениях MS VSTS.
Д.В. Кознов	Введение в программную инженерию

4.	Расскажите о средствах поддержания сборки в MS VSTS.

5.	Расскажите о различных изданиях Visual Studio и их возможностях
относительно MS VSTS.

6.	Расскажите о самом простом клиенте TFS и тех функциональных
возможностях, которые он обеспечивает.

7.	Расскажите о возможностях пакета Team Foundation Power Tools,
Это клиентская или северная компонента?

8.	Расскажите об инсталляции MS VSTS.

Задания

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

Лекция 13. VSTS: управление элементами работ (Work
Items)

Вопросы

1.	Что такое элемент работы? Приведите примеры различных видов
элементов работы.

2.	Какие есть еще артефакты в процессе, развернутом в MS VSTS?
Как они взаимосвязаны с элементами работы?

3.	Что такое тип элемента работы, что в нем определяется?

4.	Расскажите о реквизитах элемента работы.

5.	Как и где задается жизненный цика элемента работы? Какие
программные продукты при этом используются?

6.	Расскажите об импорте/экспорте элементов в MS Excel и Project:
зачем это нужно, какие практические выгоды это дает.

7.	Расскажите о связи элементов работы и отчетов.
Вопросы

1.	Перечислите особенности системы контроля версий TFS,
отсутствующие в других подобных средствах.

2.	Расскажите об Отслеживание изменений отдельных файлов.

3.	Расскажите о правилах внесения изменений.

4.	Расскажите об управлении ветками.

5.	Расскажите о сохранении без внесения.

6.	Расскажите о связи средств управления сборкой TFS и MS Build.

7.	Расскажите об описаниях сборок (build definition).

8.	Расскажите о результатах сборок (build results).

9.	Расскажите о том. как создается проект в MS Build.

10.	Расскажите о запуске процесса сборки.

И. Расскажите об анализе результатов сборки.

12.	Расскажите об управлении процессом сборки.

13.	Расскажите об управлении политикой очистки сборок.

Лекция 15. VSTS: тестирование

Вопросы

1.	Подробно разберите и прокомментируйте жизненный цикл
ошибки в шаблоне процесса MSF tor Agile.

2.	Расскажите о том, как создается описание ошибки.

3.	Опишите связь изменений исходных текстов ПО и ошибок.

4.	Расскажите о системе автоматических оповещений в TFS.

5.	Расскажите о целях и задачах модульного тестирования. Как
модульные тесты, созданные разработчиками, могут
использоваться в дальнейшем?

6.	Какие альтернативы MS VSTS существуют для автоматической
поддержки модульного тестирования для Visual Studio?

7.	Расскажите о поддержке модульного тестирования в MS VSTS.
Какая часть среды реализует эту функциональность?

В.	Расскажите о поддержке работы с пакетами тестов в MS VSTS.
Д.В. Кознов	Введение в программную инженерию

9.	Расскажите о подходе тестирования пользовательского
интерфейса Capture & Playback. В чем его трудности?

10.	Расскажите о том, как эти трудности решаются в случае
тестирования интерфейсов Web-приложений.

11,	Расскажите о поддержке Capture &. Playback тестирования
интерфейсов Web-приложений в MS VSTS.

Лекция 16. VSTS: поддержка различных моделей
процесса

Вопросы

1.	Зачем нужны разные шаблоны процессов в MS VSTS?

2.	Что они определяют, что задают, и как ограничивают
разработчиков. И как им помогают?

3.	Какова на ваш взгляд, трудоемкость создания собственного
шаблона процесса "с нуля”?

4.	С какой темой курса связана шаблоны процессов в MS VSTS?
Найдите термин из курса, который в точности может заменить
термин "шаблон процесса”.

5.	Перечислите и охарактеризуйте разделы описания шаблона
процесса.

6.	Сделайте краткий обзор известных вам шаблонов процесса MS
VSTS.

7.	Опишите шаблон MSF for Agile Software Development.

8.	Опишите шаблон Scrum.

9.	Чем они отличаются?
Д.В. Кознов	Введение в программную инженерию

Тема 2. Работа с системой отслеживания ошибок

Основной целью данного занятия является знакомство участников с
системой отслеживания элементов работы.

1.	Создание элементов работы средствами Visual Studio и Team
Explorer.

2.	Импорт и экспорт элементов работы из;в Mcrosott Excel

3.	Назначение ответственных за элементы работы.

4.	Отслеживание текущего статуса посредством отчетов.

В рамках данного занятия предполагается провести планирование
работы команды по методологии Scrum. Команды уже провели
предварительное знакомство с проектов, а на данном этапе от них
требуется следующее.

1.	Импортировать содержимое списка требований в TFS, используя
средства импорта из Excel

2.	Подробно рассмотреть 10 наиболее приоритетных
пользовательских историй.

3.	Обсудить возникшие вопросы с хозяином продукта.

4.	Провести детальное планирование и разбить пользовательские
истории на мелкие подзадачи.

5.	Распределить подзадачи среди участников проекта.

6.	Отчитаться перед хозяином продукта о том, какие
пользовательские истории были запланированы. При отчете
использовать отчеты TFS.

Шаг 1. Импорт списка пользовательских историй.

Для того, чтобы загрузить пользовательские истории из Excel-файла,
полученного командами на прошлом занятии нужно:

1.	Выбрать команды Add work items using Microsoft Excel в
контекстном меню:

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

исходном Excel документе (для этого можно использовать команды
Choose columns ):

3.	После того, как колонки настроены, скопировать значения из
исходного Excel в редактируемый.

4.	Показать колонку с именем Work Item Туре и задать для все строчек
значение Product backlog кет.

5.	Нажать кнопку

6.	Убедился, что при выполнении запроса АП product backlog items,
видны все вновь загруженные пользовательские истории:

Шат 2. Создание sprint

После импорта списка пользовательских историй команда должна
создать элемент работы, соответствующий начинающемуся sprint.
Некоторое количество sprints уже создано по умолчанию при создании
проекта:

Для активации первого спринта ему необходимо установить дату
начала, дату окончания и количество часов, которые команда может
потратить в этом спринте.

Шаг 3. Формирование Sprint backlog

После обсуждения открытых вопросов по 10 наиболее приоритетным
пользовательским историям команда должна приступить к
планированию текущего sprint и формированию sprint backlog. Для этого
ей необходимо рассмотреть список всех пользовательских историй и
разбить его на список более мелких задач. При этом для каждой задачи
необходимо создать элемент работы типа sprint backlog Кет и проставить
следующие атрибуты:

1.	В качестве sprint указать Release 1/Sprintl.

2.	Добавить связь с соответствующим элементом product backlog, а
также со всеми связанными элементами работы

3.	Установить Estimated efforts и Work remaining в соответствии с
Д.В. Кознов	Введение в программную инженерию

оценкой команды.

4.	Задать ответственного за задачу ( Owned By).

Выполнить все операции нужно средствами Visual Studio и Team
Explorer.

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

Тема 3. Работа с системой контроля версий

Основной целью данного занятия является освоение системы контроля
версий learn Foundation Server и её интеграции с системой
отслеживания задач. Занятие предполагает выполнение следующих
действий.

1.	Разработка кода модельной задачи средствами Visual Studio и
внесение его в систему управления версиями.

2.	Проставление связей между вносимыми изменениями и
элементами системы отслеживания задач.

3.	Создание параллельно поддерживаемых веток кода.

4.	Интеграция изменений, сделанных параллельно в одном файле
или в разных ветках кода.

Ша1 1. Разработка кода.

Перед началом работы команде необходимо создать решение ( solution )
средствами Visual Studio, включив опцию Add to Source Control:

В открывшемся после создания проекта окне необходимо выбрать
командный проект, в систему контроля версий которого нужно добавить
данное решение:

Затем необходимо внести все данные в систему контроля версий,
используя команду Check-in. открывающую диалог:

В этом диалоге необходимо внести комментарии к вносимому коду, а
также, на вкладке Work items, связать вносимое изменение с элементами
работы:

Шаг 2. Создание ветки кода.

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

приведенной ниже инструкции.

1.	Открыть Source control explorer:

2.	Выбрать нужный проект и в кон текстном меню команду Branch:

3.	В открывшемся окне задать целевую папку куца необходимо
скопировать данные для новой ветви:

4.	Внести изменения с помощью команды Check-in

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

Шаг 3. Объединение изменений

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

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

Все конфликты необходимо разрешить, используя команду Resolve и
утилиту для объединения результатов.

После разрешения конфликтов все изменения внести в систему
контроля версий посредством операции Check-m.
Д.В. Кознов

Введение в программную инженерию

Тема 4. Разработка модульных тестов

На данном занятии команды должны разработать набор модульных
тестов, покрывающих функциональность, разработанную на занятии
предыдущем. В рамках данного занятие предполагается освоить
следующие возможности MS VSTS.

1.	Автоматическая генерация тестов.

2.	Наполнение тестов содержимым.

3.	Запуск тестов и просмотр результатом.

4.	Изменение конфигурации работы тестов.

Шаг 1. Автоматическая генерация тестов.

Для ускорения разработки тестов команды могут воспользоваться
возможность Visual Studio по автоматической генерации тестов. Для
этого необходимо воспользоваться командой Test/New Test и выбрать
Unit Test wizard в открывшиеся окне:

После создания тестового проекта, будет предложен выбор из тех типов
и методов, для тестирования которых необходимо создать заглушки:

В этом диалоге команда должна выбрать все основные классы и
методы, которые планируется покрыть модульными тестами.

Шаг 2. Наполнение тестов содержимым.

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

/// < summary >

///A test for Multiply

///</summary>

[TesfMethod()l
Д.В. Кознов	Введение в программную инженерию

public void MultiplyTest()
{

// TODO: Initialize to an appropriate value

Calculator tai get = new Calculator!);

int a = 0; // TODO: Initialize to an appropriate value

int b = 0; // TODO. Initialize to an appropriate value

int expected = 0; //TODO: Initialize to an appropriate value

int actual;

actual = target. Multiply! a, b);

Assert.AreEquaI(expected, actual);

Assert.Inconclusivc("Verify tine correctness of this test
method.");

}

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

Шаг 3. Запуск тестов

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

После этого результаты выполнения тестов будут видны в окне
результатов:

Команды должны добиться того, чтобы все разработанные тесты
проходили успешно.

Шаг 4. Изменение конфшурации тестов.

Для того, чтобы проанализировать качество разработанных тестов,
команда должна вычислить тестовое покрытие. Для этого её
необходимо:

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

добавленный к решению при создании тестов:

2.	На открывшемся диалоге выбрать вкладку Code Coverage и
установить то, какие именно проекты нужно анализировать:

3.	После сохранения конфигурации запустить тесты и активировать
опцию Show Code Coverage Coloring:
Д.В. Кознов	Введение в программную инженерию

Тема 5. Создание и конфигурация автоматической
сборки

На данном этапе команда должна создать в своем проекте процедуру
автоматической сборки. При этом должно быть создано несколько
процедур:

1.	Простая процедура, включающая только сборку

2.	Полная процедура, включающая тесты и анализ кода.

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

1,	Простая сборка должна запускаться после каждого внесенного
изменений, но не чаше чем раз в 5 минут.

2.	Полная сборка должна запускаться каждую ночь.

Шаг 1. Создание простой сборки

Все результаты сборки, проведенной TFS, выкладываются в
разделяемую папку, на запись в которую есть права у пользователя, с
правами которого работает сервер автоматических сборок (обычно -
TFSBtdld), а также у пользователя, с правами которого работает сам TFS
(обычно - TFSService). Как правило, учащиеся не обладают
достаточным количеством прав для создания такого рода папок,
поэтому они должны быть заранее подготовлены преподавателем.

Для создания простой сборки необходимо обратится к окну Team
Explorer, после чего в разделе Builds выбрать команду Build Definitions:

Вызов этой команды приведет к открытию мастера, в котором нужно
задать следующие параметры сборки:

1.	Задать имя и описание сборки:

2.	На закладке Project File, создать новое описание сборки используя
кнопку Create, после чего задав проекты и конфигурации для
Д.В. Кознов	Введение в программную инженерию

сборки:

3.	На закладке Build Defaults создать определение агента-сборщика
используя кнопку New. Для агента указать имя, описание, и IP
адрес сервера сборок (как правило, совпадает с сервером TPS):

4.	На закладке Build Defaults также необходимо задать имя
разделяемой папки, в которую будут сложены результаты:

После того, как определение сборки было создано, её необходимо
запустить, используя команду Queue new build:

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

Шаг 2. Создание сложной сборки.

Создание сложной сборки проходит во многом аналогично созданию
сборки простой, за исключением нескольких шагов:

1.	На закладке опций при создании проекта сборки необходимо
включить автоматический запуск модульных тестов и анализ кода:

2.	На закладке Build Defaults необходимо задать другую папку для
сбора результатов.

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

Теперь нужно добиться выполнения статического анализа кода во время
ночной сборки. Для этого необходимо активировать анализ кода в
настройках соответствующих проектов:

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

1.	Вызвать команду Edu build definition:

2.	Задать настройки автоматического запуска на закладке Trigger:

3.	Настроить политику' очистки сборок на зактадке Retcnnon Policy.
Это необходимо для того, чтобы избежать быстрого исчезновения
места на машине-сборщике и для удаления из базы TFS
информации о второстепенных сборках:

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

1.	В контекстном меню проекта выбрать команду Project Alerts:

2.	В списке событий, о которых нужно слать нотификации, выбрать
"a build completes" и задать список адресов электронной почты, на
которые нужно отправить сообщение:

После настройки простой сборки для запуска при внесении изменения
необходимо проверить работу системы - внести некоторое изменение и
дождаться сообщения о сборке.

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

Тема 6. Настройка шаблона процесса.

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

В рамках ретроспективы команда должна предложить некоторые
изменения к элементам работы, вовлеченным в процесс, а затем и
реализовать эти изменения.

Шаг 1. Ретроспектива

На ретроспективе команда в течение 20-30 минут обсуждает то, как
прошел данный спринт, выделяя позитивные и негативные моменты, а
также предложения по изменениям.

Все комментарии должны быть внесены в соответствующий элемент
работы типа Sprint retrospective, а для каждого предложения по
улучшению заведены элементы работы типа Sprint backlog item, а для
каждого идентифицированного негативного момента, требующего
устранения - элемент работы типа Impediment.

Результаты ретроспективы необходимо обсудить с хозяином продукта.

Шаг 2. Изменение элемента работы

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

1.	Открыть тип элемента работы на редактирование с помощью
команды меню Tools:

2.	Выбрать нужный элемент работы в открывшемся диалоге:
Д.В. Кознов	Введение в программную инженерию

3.	На закладке Fields добавить, удалить или изменить необходимые
поля:

4.	На закладке Layout изменить соответствующим образом
визуальное представление элемента работы

5.	На закладке Workflow внести необходимые изменения в
жизненный цикл элемента работы:

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

1.	H.Miils, The management of software engineering Part I: Principles of software
engineering, IBM System Journal, \bl. 38, No 2&amp;3, 1999, pp. 289-295

2.	F. Brooks, No Silver Bullet, Information Proceeding of the IFIP 10-th World Computing
Conference. 1986. pp. 1069-1076, Русский перевод: Ф. Брукс. Мифический человеко-
месяц или как создаются программные системы. СПб Символ, 2000. 298 с

3.	1.Sommerville, Software Engineering, 6-th edition. Addis on-Wes ley, 2001. 693 p. Русский
перевод: И.Соммервилл. Инженерия программного обеспечения. Издательский дом
&чио1,Ви.1ьямс&цио1;, 2002. 623 с

4.	А.П.Ершов. Технология разработки систем программирования. Избранные труды.
ВО «Наука». Новосибирск. 1994. С. 230-261

5.	Потгосин И.В. Программная инженерия: содержание, мнения и тенденции,
Программирование. 1997 N 4. С. 26-37

6.	Д.В.Кознов, Введение в программную инженерию. Часть I, Изд-во Санкт-
Петербургского ун-та, 2005 г, 43 с

7.	W Humphrey, Managing the Software Process, Addison-Wesley, 1989.494 p

8.	R. W.Zmud, An Examination of 'Push-Pull" Theory Applied to Process Innovation in
Knowledge Work, Management Science, X6L 30(6), 1984, pp. 727-738

9.	B. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer,
vol.21, #5, May 1988. P. 61-72

10.	W. W’. Royce, Managing the Development of Large Software Systems, Proceedings of
IEEE W ESCON, August 1970. P. 1-9. Переиздана: Proceedings of the 9th International
Software Engineering Conference, Computer Society Press, 1987. P. 328-338

11.	Р.Т.Фатрепп, Д.Ф.Шафер, Л.И.Шафер, Управление программными проектами:
достижение оптимального качества при минимуме затрат, Изд. дом "Вильямс".
2003. 1125 с

12.	Д.В.Кознов, Языки визуального моделирования: проектирование и визуализация
программного обеспечения, Изд. СПбГУ, 2004. 170 с

13.	Д.Ахен, А.Клауз, Р.Тернер, CMMI: комплексный подход к совершенствованию
процессов, М.:МФК. 2005. 330 с

14.	CMMI for Development, Version 1.2. CMMI-DEV (Version 1.2, August 2006), URL
http://wwrw.sei.cmu.edu/publications/documents/06.reports , Carnegie Mellon University
Software Engineering Institute (2006). Retrieved on 22 August 2007

15.	Carnegie Mellon University Software Engineering Institute (2006), URL:
http://www.sei.cmu.edu/publications/documcnts/06.reports , Retrieved on 22 August 2007
16. UML 2.1 Infrastructure Specification, URL. http://www.omg.org/, September, 2006

17.	Kruchten P, The 4+1 View Model of Architecture, IEEE Software, 1995, 12(6), P.42-50

18.	Буч Г., Якобсон А., Рамбо Дж, UML. Изд. 2-е, СПб.: Питер, 2006, 735 с

19.	Д. В.Кознов, Основы визуального моделирования. М: Интернет-Университет
Информационных Технологий: БИНОМ. Лаборатория знаний, 2007. - 248 с.: ил. -
(Серия "Основы информационных технологий")

20.	ВВ.Кулямин, Н.В. Пакулин, О.Л. Петренко, А.А. Сортов, А.В. Хорошилов,
Формализация требований на практике, Препринт ИСП РАН 2005. 50 с

21.	Guide to the Software Engineering Body of Knowledge: 2004 Edition. SWEB( )K. IEEE,
2005
Д.В. Кознов	Введение в программную инженерию

22.	Кулямин В.В, Технология программирования. Компонентный подход, М.: Интернет-
Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. 463 с

23.	R.W. Selby, М.А. Cusumano, Microsoft Secrets HarperCollins Business, 1997, 512 p

24.	Marca D.A., McGowan C.L, SADT Structured Analysis and Design Technique, McGraw-
Hill, 1988

25.	Integration Definition For Function Modeling (IDEFO), URL
http://www.idef.com/lDEFO.html , Draft Federal Information Processing Standards
Publication 183, 1993, 79 p

26.	D.VKoznov, M.Pliskin, Computer-Supported Collaborative Learning with Mind-Maps,
T. Margaria and B. Steffen (Eds.): ISoLA 2008, CGIS 17, pp. 478 489. 2008. Springer-Vrlag,
Berlin Heidelberg, 2008

27.	Кознов Д.В, Методика обучения программной инженерии на основе карт памяти,
С. 121-140

28.	Кознов Д.З.Кириленки Я.А, Опыт сочетания теории и практики в обучении
программной инженерии, Труды III всероссийской конференции "Современные
информационные технологии и ИТ-образование", М. 2008

29.	Microsoft	Solutions	Framework,	Process	Model.	Version	3.1,	URL.

http://www.microsoft.com/msf, 2002

30.	Microsoft	Solutions	Framework,	Team	Model,	Version	3.1,	URL.

http://www.microsoft.com/msf, 2002

31.	Microsoft Solutions Framework, Project Management, Version 3.1, URL
http://www.mk rosoft.commsf, 2002

32.	Manifesto for Agile Software Development, URL: http://agilemanifesto.org/

33.	M.Fowler,	The	New	Methodology,	URL:

httpj7www.martinfowler.com/articles/newMethodology.html, 2003

34.	K.Beck, C.Andres, Extreme Programming Explained, 2004. Paperback. 118 p

35.	M.Борисов,	Scrum:	гибкое управление разработкой, URL

http7/www.osp.ru/os/2(X)7/04/4220063/, 30/05/2007 №04

36.	Wikipedia, URL: http://en.wikipedia.org/wiki/Scmm_(development)
Титульная страница	2
Выходные данные	3
Лекция 1. О предмете изучения	4
Лекция 2. Процесс разработки программного обеспечения	10
Лекция 3. Рабочий продукт, дисциплина обязательств,	oi
проект  Лекция 4. Архитектура ПО	30
Лекция 5. Управление требованиями	44
Лекция 6. Конфигурационное управление	52
Лекция 7. Тестирование	61
Лекция 8. Диаграммные техники в работе со знаниями	75
Лекция 9. MSF	92
Лекция 10. СММ1	104
Лекция 11. "Гибкие" (agile) методы разработки	108
Лекция 12. Обзор технологии Microsoft Visual Studio	1 1 д
Team System (VSTS)	1 14-
Лекция 13. VSTS: управление элементами работ (Work Items)	128
Лекция 14. VSTS: конфигурационное управление	151
Лекция 15. VSTS: тестирование	186
Лекция 16. VSTS: поддержка различных моделей	209
процесса  Лекция 17. Практикум	220
Лекция 18. Вопросы и задания по курсу "Введение в программную инженерию"	277
Лекция 19. Тема 2. Работа с системой отслеживания	
ошибок	Zvi
Лекция 20. Тема 3. Работа с системой контроля версий 294

Лекция 21. Тема 4. Разработка модульных тестов 296

Лекция 22. Тема 5. Создание и конфигурация
автоматической сборки

Лекция 23. Тема 6. Настройка шаблона процесса.	302

Список литературы	304