Разработка программного обеспечения согласно заранее составленному графику и требуемого уровня качества — весьма сложная задача. Очередным доказательством этого стали исследования The Standish Group, результаты которых изложены в отчете Extreme Chaos. Они свидетельствуют, что в 2000 году 23% проектов закончились неудачей, 49% реализовались с проблемами и лишь 28% оказались успешными. Основные показатели неуспешных проектов таковы: 45% — превышение стоимости, 63% — превышение сроков, 67% — функциональность реализована не в полном объеме.

Повысить уровень предсказуемости проектов позволяют различные методологии, стандарты и инструменты. Существуют даже специализированные организации, такие как Project Management Institute, занимающиеся подготовкой проектных менеджеров проектов. Недавно своими рецептами решили поделиться в Microsoft. В соответствии с рекомендациями корпорации для достижения успеха при разработке программного обеспечения нужно совсем немного. Необходимо освоить несколько простых правил, собранных в новую версию методологии управления жизненным циклом разработки приложений MSF 4.0 (Microsoft Solution Framework) и воспользоваться специализированным инструментарием, который обеспечивает снижение уровня сложности разработки, повышение отдачи от деятельности команды разработчиков, наконец, возможность постоянного прогнозирования результатов разработки.

Правила разработки, применяемые в Microsoft (они использовались, в частности, при создании Visual C++), собраны воедино в статье Джима Маккарти «21 отличное правило своевременной поставки замечательного программного обеспечения».

MSF 4.0

По сути, MSF является документом, основанным на правилах разработки от Microsoft. При его создании были использованы знания и опыт самой корпорации, ее партнеров и других ведущих игроков на рынке разработки программного обеспечения. В MSF 3.0 включены две модели организации (проектная группа и процесс разработки) и три дисциплины управления (проект, проектные риски и готовность). MSF 4.0 функционально будет разделена на две части.

  • Быстрые процессы (MSF for Agile Software Development, MSF Agile). Слабо формализованная версия MSF, которая предназначена для проектов, опирающихся на высококвалифицированные кадры и разработку с постепенным развитием прототипов будущей системы. Данная модель идеальна в условиях сильной конкуренции и быстрой разработки в изменяющихся условиях, однако результат использования MSF Agile менее предсказуем, чем в случае применения формальных процессов.
  • Формальные процессы (MSF for CMMI Process Improvement). Строго документированный процесс, в котором большое внимание уделено планированию, верификации и аудиту. Модель ориентирована на большие команды и длительные проекты. Ее главное достоинство — высокая управляемость и предсказуемость результата. Кроме того, формальные процессы являются основой для выполнения требований стандарта CMMI Level 3.

MSF — не только теория, но и набор конкретных инструментов; в качестве такового выступает программный продукт Visual Studio 2005 Team System (VSTS).

Visual Studio 2005 Team System

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

VSTS — единый инструмент всех членов команды, но отчетами о ходе разработки системы вполне может пользоваться и заказчик, чтобы в любой момент знать о степени готовности системы. Планируется выпускать VSTS в нескольких редакциях. Одна из них, Visual Studio Team Suite, будет состоять из следующих компонентов: Visual Studio Team Edition for Architects (VSTA) — инструменты для архитектора; Visual Studio Team Edition for Developers (VSTD) — инструменты для разработчика; Visual Studio Team Edition for Testers (VSTT) — инструменты для инженера по качеству, выполняющего тестирование.

Редакция Visual Studio Team Foundation (VSTF) — это серверный компонент на основе SQL Server 2005. Его функциональность доступна в виде ряда Web-сервисов: сбор и управление требованиями; аналитические отчеты; управление задачами (Work Items); поддержка портала проекта; средства управления проектом; средства управления исходным кодом (Team Foundation Version Control); сервер для сборки продукта (Team Build).

Рассмотрим пример проекта, реализуемый при помощи VSTS. Инструментарий используется на каждом этапе проекта.

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

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

Сбором и анализом требований занимается бизнес-аналитик, который вполне может обходиться без VSTS. Тем не менее VSTS предлагает удобную среду для консолидации собранных требований, их анализа и последующей связи с другими артефактами проекта, такими как задачи, исходный код, тестовые случаи и т.п. Для сбора данных и планирования можно пользоваться как VSTS, так и Microsoft Excel и Microsoft Project.

Создание сайта проекта и библиотеки документов. На этом этапе члены команды наполняют сайт проекта, который создается на основе технологии Windows SharePoint Services. Сайт (рис. 1) содержит шаблоны типовых документов, рабочие документы (сценарии, план проекта, описание тестов) и описания выбранной методологии ведения проекта.

Рис. 1. Пример сайта проекта

Установка политик изменения кода и сборка. Для успешной работы команды следует настроить политики помещения (Check-In) кода в базу исходного кода Team Foundation Source Control (TFSC). Эта база основана на SQL Server 2005 и позволяет решать многие проблемы, присущие Visual SourceSafe (такие как ограничение числа пользователей или использование файловой системы как основы для хранения информации). Кроме того, TFSC предлагает новые функции, такие как возможность помещения кода в базу без выполнения Check-In (в таком случае код не становится частью последующей сборки).

Поскольку политики задают правила помещения кода в базу, можно требовать от разработчиков выполнения формальных условий (таких как именование кода), а также выполнять на помещаемом коде модульное тестирование. Выдаваемый средой Visual Studio 2005 (VS05) список предупреждений, связанных с несоблюдением заданных политик, приведен на рис. 2.

На данном этапе специалист, ответственный за сборку решения, настраивает параметры сервера сборки. Этот сервер, называемый Team Build, позволяет подготовить систему к выпуску на самом раннем этапе разработки. Результатом сборки становится отчет о ее выполнении, сохраняемый в VSTF.

Рис. 2. Список предупреждений, связанных с политиками

Создание логической структуры решения и его развертывания. В составе редакции VSTA поставляются инструменты для архитектора, позволяющие создавать три типа диаграмм: архитектура компонентов решения Application Diagram (рис. 3); инфраструктура развертывания Logical Datacenter Diagram; описание размещения компонентов на серверах инфраструктуры Deployment Diagram. На данном этапе архитектор создает диаграмму сервисов, составляющих решение, и связей между ними. Для описания архитектуры используются крупные блоки, такие как база данных, настольное приложение, Web-приложение или Web-сервис. Кроме того, архитектор описывает условия работы будущего приложения, например требования к версии операционной системы.

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

Рис. 3. Пример Application Diagram

На данном этапе проводится проверка на готовность системы к развертыванию компонентов. Связь Application Diagram с Logical Datacenter Diagram позволяет верифицировать соответствие существующей инфраструктуры развертывания проекта требованиям архитектуры проектируемой системы.

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

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

Статический анализ кода и профилирование. Сейчас сборка исходного кода приложения состоит из процесса компиляции, в результате которой создается исполняемый код приложения. VSTT позволяет расширить этот процесс, выполняя после компиляции статический анализ. Например, для анализа кода программ на C/C++ используется утилита PREfast, а для проверки формальных правил разработки классов .NET — утилита FxCop. Кроме того, анализ эффективности работы приложения может быть выполнен средствами профилирования — мониторинга с помощью отбора проб и с помощью измерений. Их применение позволяет значительно повысить качество и производительность кода.

В состав VSTT входят средства для управления сценариями тестирования. Отдельные тесты можно объединять в коллекции, создавая наборы как для полного, так и для регрессионного тестирования. Поддерживаются ручные тесты, описание которых хранится в виде текстового файла, а запуск осуществляется инженером по качеству вручную и Web-тесты, которые служат для проверки Web-страниц или HTTP-запросов. Для управления тестами используется среда VS05. Созданные тесты вместе с кодом помещаются в Team Foundation Version Control.

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

Любая проектная деятельность, выполняемая под контролем VSTF, может быть проанализирована при помощи автоматически создаваемых отчетов. В качестве сервера отчетов используется SQL Server 2005 Reporting Services, а все типы отчетов зафиксированы в методологии. Например, для MSF Agile такими отчетами являются оставшаяся работа (Remaining Work), производительность работы команды (Velocity), незапланированная работа (Unplanned Work), показатели качества (Quality Indicators), сходимость тестирования (Bug Rates), анализ возвратов (Reactivations), ошибки в соответствии с приоритетом (Bugs by Priority), качество против производительности (Actual Quality versus Planned Velocity).

VSTS, по сути, — это большой конструктор, который каждая рабочая группа настраивает для своих нужд. Например, можно создавать собственные методологии, расширять атрибуты рабочих продуктов, интегрировать правила и политики, а также инструменты для профилирования, настраивать внешний вид портала проекта и типы тестов. Кроме того, любая компания может расширить возможности как VSTS, так и VS05; свои расширения представили, в частности, Borland, Business Objects, IBM и Oracle.

Антон Смольянинов (askrd@digdes.com) — начальник отдела компании Digital Design (Санкт-Петербург), Александр Ложечкин (allo@microsoft.com) — Developer Evangelist/MVP Lead компании Microsoft (Москва).

21 правило от Джима Маккарти

Свод правил, составленный Джимjv Маккарти, разделен на три раздела: «Выпустить», «Лучший продукт» и «Вовремя».

Выпустить

  1. Вы не знаете того, чего вы не знаете. В любом проекте всегда существуют неопределенности, но человеку свойственно отвергать свое незнание, подменяя истинное знание предположениями. Неизвестно, что является ошибкой, поэтому старайтесь быть критичными к себе. Найдите для своей команды мотивацию к тому, чтобы она постаралась обнаружить и понять максимум «белых пятен». Не пытайтесь обмануть себя предположениями.
  2. Старайтесь иметь четкое представление о состоянии проекта. В проекте должны участвовать люди, способные объективно оценить готовность системы. Разработчики всегда более оптимистичны, чем тестировщики. Поощряйте плохие новости, и тогда снизится риск неожиданного провала в самом конце проекта. Самый лучший способ — полагаться на объективные данные, на метрики (степень покрытия функциональности тестами, число активных дефектов, динамика их исправления и т.д.). Состояние осведомленности обязательно должно включать знание о всех составляющих проекта и содержать точную информацию о статусе проекта в определенный период времени.
  3. Помните о треугольнике приоритетов. Существуют три взаимосвязанных компонента любого проекта: ресурсы (люди и деньги), функциональность и сроки. Изменение одного из них всегда влияет на остальные. Можно зафиксировать значения только двух из этих показателей: например, зафиксировать характеристики времени и команды, чтобы получить требуемую функциональность; зафиксировать характеристики команды и функциональности, чтобы получить нужное время; зафиксировать характеристики времени и функциональности, чтобы получить требуемую численность команды разработки. Не забывайте, что не все задачи можно выполнять параллельно.
  4. Старайтесь быть на виду. При планировании надо разбивать задачи на более мелкие, на выполнение которых требуется полдня или день. Тогда о том, что вы начинаете отставать, вы узнаете достаточно рано и сможете предпринять корректирующие шаги. Неделя для проекта разработки — это вечность. Каждый проект, который отстает на месяц, вначале отставал на один день. Узнайте об отставании прежде, чем наступит момент, когда исправить что-то будет уже невозможно. Несомненно, подобный стиль управления весьма опасен и периодически вас будут в нем обвинять. Но если вам удастся довести до участников проекта понимание того, что его цель — предоставить готовый продукт в определенное время, ваши коллеги примут этот стиль.
  5. Используйте контрольные точки с отсутствием дефектов. В каждом приложении можно выделить 20% функциональности, которая будет использоваться 80% времени; в свою очередь, в оставшихся 80% функциональности можно опять выделить 20% и т.д. Реализуйте сначала первые 20% функций, но полностью, а также протестируйте и соберите программу установки с прототипом документации. И только когда все это будет готово, двигайтесь дальше. Этот метод основан на идее выделения контрольных точек, в которых продукт должен содержать некое, небольшое, но четко определенное количество дефектов. Их промежуточный контроль позволяет быстро понять, какие части проекта могут стать причиной проблем, и получить полную картину о проекте, а также дают возможность сфокусироваться на достижении целей каждой контрольной точки.
  6. Бойтесь разработчиков, сидящих в башнях из слоновой кости. Разработчики должны уметь работать в команде, демонстрировать свой прогресс, делиться опытом и проверять то, что уже сделано. Избегайте «примадонн», которые считают себя умнее всех. Несомненно, проект лишь выиграет, если в команде появится пара гениев или просто отличных специалистов, но еще лучше будет, если их талант признает и команда, и все лица, заинтересованные в результатах проекта. Разработка программ осуществляется силами команды, для определения состава которой может пригодиться правило, принятое в Microsoft: шесть разработчиков, три инженера по качеству, один менеджер, два технических писателя. Это правило — результат многочисленных проб и ошибок, через которые прошла корпорация при разработке и масштабных платформ, и совсем небольших утилит.
  7. Плохая дата — не просто плохая дата. Обычно вы заранее знаете, что опоздаете, знают это и все вокруг. Вы настаиваете на смене даты, но с каждой отсрочкой теряете доверие клиента. Вот хорошее правило: перенос даты должен происходить только в тех случаях, когда точно известны все составляющие и причины задержки. Изменение сроков требует ресурсов, поэтому следующая контрольная точка должна быть реалистичной. В противном случае подобный «проект» никогда не закончится.
  8. Сдвинув сроки, не проваливайте их. Перенос срока — это симптом, который свидетельствует о выявлении «белых пятен». Такое случается весьма часто, поскольку разработка ИТ-решений является экспериментальным видом деятельности, в котором используются новые технологии. Все это ведет к неопределенности по поводу сроков проекта. Если сдвиг сроков выполнения проекта стал неожиданностью — значит, используемые методы общения с сотрудниками и управления командой проекта надо менять. В то же время задержка дает возможность переоценить ресурсы и возможности продукта; в итоге это приносит положительный эффект. Поэтому, сдвигая сроки, внимательно анализируйте ошибки и старайтесь их больше не допускать.
  9. Чем проще — тем лучше. Лучше обещать меньше, но сделать больше, чем пообещать больше и не выполнить. Для заказчика важнее результат, а не обещания. А для успеха проекта стоит выбирать максимально простые, но надежные решения.
  10. Время для проектирования — это время для проектирования. Оценивая способы проектирования, всегда учитывайте временной фактор и выбирайте из альтернативных решений наименее рискованное и оптимальное по времени реализации. Часто в погоне за красотой реализации, проектировщик склонен выбрать вариант, совершенно не укладывающийся в сроки проекта. Помните, что время — весьма ограниченный ресурс, который дан для того, чтобы достичь успеха, а не удивить.
  11. Если вы не можете что-то собрать, значит, вы не сможете это выпустить. Продукт должен постоянно собираться (компилироваться вместе со всеми компонентами системы, документацией и программой установки). Это необходимо потому, что с самого начала нужно определить все составляющие будущего продукта и адекватно оценивать степень их готовности. В противном случае вы обязательно что-нибудь забудете, и это станет весьма неприятной неожиданностью, особенно под окончание работ. Пусть на начальном этапе это будут скромные зачатки будущей системы — придет время, и из них вырастет отличный продукт. С другой стороны, промежуточная версия продукта — хороший способ продемонстрировать заказчику факт готовности того или иного фрагмента работы.
  12. Мысли о многоплатформности. Старайтесь не перебарщивать с числом платформ, на которых будет работать система. Держите в голове тот факт, что разработка для каждой из платформ зачастую представляет собой переработку большей части функциональности, а также ее тщательное тестирование и последующее исправление ошибок. Соответственно, это увеличивает как стоимость системы, так и затраты на будущую поддержку. Помните, что пользователям чаще всего нужен продукт, а не его удивительная гибкость.

Лучший продукт

  1. Заказчик — это ваше все. Старайтесь в следующих версиях учитывать даже весьма странные, нечетко выраженные пожелания клиентов. Часто в этих требованиях скрывается то, что делает продукт уникальным и неотличимым от других, добавляет ему маркетинговой привлекательности и заставляет пользователей использовать его долгие годы. Помните, что заказчик лучше вас знает, что ему нужно.
  2. Самое главное — единство и интеграция. Единство причины и единство исполнения должны стать девизами команды разработчиков.
  3. Двигайтесь правильным курсом. Цель — основная идея вашей разработки. Все оценки продукта основываются именно на ней, поэтому она должна быть очень четкой. Старайтесь как можно раньше наметить цель и сохранить веру в нее вплоть до конца проекта.
  4. Будьте гибким. Часто по ходу проекта требования к системе могут изменяться — будьте готовы к этому. Старайтесь постоянно проверять, насколько мнение пользователя соответствует поставленной цели. Используйте для этого промежуточные версии продукта, вовлекая заказчика в процесс работы с системой как можно раньше. Однако, собираясь менять курс, помните: цель должна остаться прежней.
  5. Соблюдайте баланс. Правильно расставьте акценты на разных составляющих проекта. Ни в коем случае не увлекайтесь наращиванием свойств какой-либо из возможностей продукта, это станет причиной дискомфорта пользователей и может привести к серьезным проблемам со сроками реализации продукта.
  6. Развивайте продукт постепенно. Правильное развитие выглядит так: ранние стадии разработки определяют более поздние, ошибки не повторяются, а результат отвечает потребностям конечного пользователя. Плавное развитие вселяет в вас ощущение предсказуемости и стабильности процесса разработки.
  7. Продукт — это иерархия компонентов. Следуя этому принципу, элементам проекта уделяют внимание пропорционально их важности, что обеспечивает стабильность и сбалансированное развитие. Иерархию очень удобно использовать как скелет для постепенного расширения системы, сначала вы реализуете основу, а затем наполняете ее будущим содержимым; новые компоненты опираются на уже разработанные.
  8. Все должны разделять общее видение продукта. Все члены команды должны знать, какие цели должны быть достигнуты, как продукт должен выглядеть, какова стратегия его разработки. Если в команде появляются противники текущей цели — постарайтесь дать им слово и аргументировать свое видение, быть может, оно лишь улучшит будущую систему. Все противоречия должны быть разрешены, а видение предмета приведено к единству.

 

Выпустить вовремя


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

Выпуск продукта должен стать целью каждого члена команды, самым ожидаемым событием для всех!