С развитием комплексных программных решений для управления корпоративными ресурсами, взаимоотношениями с клиентами, цепочками поставок и персоналом многие ключевые бизнес-операции получили более или менее надежную ИТ-поддержку. Но по-прежнему остается большое поле для приложения усилий разработчиков. Как свидетельствуют аналитики, свыше половины бюджетов компаний, выделяемых на программное обеспечение, продолжают расходоваться на модернизацию, адаптацию и разработку программ «с нуля», а не на покупку «коробочных» продуктов. И о чем бы ни шла речь (о преобразовании унаследованных приложений в компоненты современных сервис-ориентированных архитектур, о настройке готовых программных пакетов в соответствии с потребностями заказчика или о создании собственных систем), бизнес требует, чтобы в рамках оговоренных ресурсов достигалось надлежащее качество разработки.
От кустарного производства к индустрии
На протяжении полувека разработка программного обеспечения трансформировалась из искусства одиночек в технологический процесс, выполняемый по определенным правилам и подразумевающий применение средств автоматизации. В 60-е и 70-е годы доминировал неупорядоченный подход к разработке, что означало плохое взаимодействие членов команды, использование языков программирования низкого уровня, слабый уровень автоматизации этапов разработки, отсутствие интеграции между ними, сильную зависимость успеха проекта от продуктивности работы отдельных специалистов. Как в свое время отмечали исследователи из компании Rational [1], из-за всего этого требования к стоимости, срокам выполнения и качеству программных проектов чаще всего не выполнялись.
Ситуация стала изменяться под влиянием все более активного использования программного обеспечения для поддержки важных процессов в самых разных отраслях промышленности и государственного управления. В 80-е и 90-е годы началось формирование новой дисциплины — программной инженерии. Разработка программного обеспечения из «шаманства», деятельности для избранных постепенно превращалась в более-менее строгий процесс, в котором используются готовые средства автоматизации, ориентированные на языки программирования высокого уровня и стандартные системные платформы. Одновременно увеличивалась зависимость бизнеса от программных систем, и, как следствие, появлялись новые, все более серьезные проблемы разработки. В компании Borland выделяют четыре основных фактора, определяющих круг таких проблем [2].
- Организационная разобщенность. Слабый уровень развития коммуникаций и отсутствие инструментов согласования требований между бизнес-подразделениями, группами разработчиков и службой эксплуатации ИТ-инфраструктуры влияют на эффективность труда разработчиков, поскольку они не имеют возможности оперативно реагировать на изменения требований бизнеса. Из-за отсутствия средств постоянной, в том числе автоматизированной, связи между разработчиками и службой оперативной поддержки ИТ-инфраструктуры не учитываются возможные проблемы развертывания программных систем. А это отрицательно сказывается на реализации информационных сервисов для конечных бизнес-пользователей.
- Разобщенность между функциональными ролями членов проектной группы, отвечающих за разные этапы разработки, бизнес-руководителей и специалистов по поддержке приложений. Отсутствие интеграции инструментальных средств усложняет проблемы, связанные с недостатком единого видения при управлении процессом разработки и развертывании прикладных систем.
- Технические сложности. Разработка программных продуктов, особенно в масштабных проектах, часто осуществляется в неоднородной среде, требующей знания особенностей разных платформ и средств их интеграции. Положение усугубляется тем, что среды разработки не обеспечивают достаточную инструментальную поддержку неоднородности и отсутствует строгий архитектурный подход к построению прикладных систем.
- Распределенная разработка. При создании больших сложных систем распределенными коллективами и при аутсорсинге разработки приложений усложняются проблемы коммуникаций между членами команды.
Естественно, продолжают довлеть незрелость процессов разработки и организационная слабость проектов. Все это обуславливает неудовлетворенность результатами разработки, большое количество переделок, чрезмерные затраты на разработку и сопровождение программного обеспечения, срыв сроков или даже полный провал проекта. А причиной таких проблем, как правило, является неэффективность разработки как бизнес-процесса.
Проблемы распределенной разработки
Что предлагает индустрия для решения всех этих проблем? Прежде всего, рекомендуется искать комплексные решения, позволяющие одновременно уменьшать сложность, совершенствовать процесс и методы командной работы, интегрировать этапы разработки с использованием соответствующего инструментария. Снизить сложность и переориентировать процесс разработки на достижение результата в заданные сроки и с заданным качеством можно с помощью перехода от традиционного («водопадного») метода к итеративному.
Метод «водопада» подразумевает последовательное прохождение этапов разработки — от определения требований до тестирования и развертывания. Он не дает возможности выявлять ошибки проекта до его полного завершения, когда устранение таких ошибок становится слишком сложным и дорогостоящим. В итеративном процессе каждая итерация включает в себя основные этапы разработки, тесно интегрированные между собой, и нацелена на достижение определенного промежуточного результата. Его анализ на соответствие исходным требованиям позволяет вносить коррективы по ходу разработки, благодаря чему снижается стоимость ошибок, сокращаются затраты на переделку кода, а результат разработки становится более предсказуемым.
Итеративная разработка позволяет уменьшить присущие проекту риски, поскольку наиболее сложные аспекты программы могут быть реализованы и верифицированы на самых ранних итерациях. Возможность постепенного наращивания функциональности упрощает разработку: очередная итерация затрагивает не все возможные задачи системы, а лишь очередную их группу, наиболее значимую на данном этапе. Преимущества итеративности по достоинству оценены в ведущих методологиях разработки, таких как RUP и «скорые» (agile) методики.
Важнейшим способом снижения сложности программных проектов стал архитектурный подход. Архитектура программной системы на базе компонентов позволяет уже на ранних этапах разработки получить представление об основных функциях и особенностях интеграции составных частей системы. При совмещении архитектурного подхода и итеративных принципов можно строить и верифицировать прототипы полностью интегрированных систем уже на фазе проектирования, выявляя возможные ошибки проекта и архитектурные несогласованности. Результат каждой итерации — работающее решение. На основе его анализа, который проводят все заинтересованные стороны, удается достигать компромиссов в требованиях, дизайне, используемых технологиях и др.
Логическим развитием компонентной архитектуры стала сервис-ориентированная архитектура (service-oriented architecture, SOA), позволяющая представлять элементы программного решения как высокоуровневые взаимодействующие сервисы. В качестве таковых могут выступать целые приложения, в том числе унаследованные корпоративные решения и внешние системы.
Архитектурный подход к разработке крайне затруднителен без средств моделирования, позволяющих описывать и визуально представлять структуру и поведение системы. Архитектура приложения, созданная с помощью стандартных средств моделирования (таких как UML), — это еще и средство коммуникаций в рамках проекта. Такая архитектура обеспечивает понятное всем участникам разработки представление системы и возможность вносить в него согласованные изменения. Компонентная архитектура вместе с визуальным моделированием дают возможность реализовать определенные этапы проекта на достаточно высоком уровне абстракции, что упрощает разработку и делает ее более управляемой.
Ряд производителей инструментария разработки активно включились в инициированное консорциумом OMG создание архитектур на базе моделей (model driven architecture, MDA). Подобные архитектуры позволяют полностью проводить разработку на уровне модели системы и пользоваться автоматической генерацией кода в соответствии с этой моделью, обеспечивающей учет особенностей как общей архитектуры, так и реализации на определенных платформах. Еще одна тенденция — моделирование не только архитектуры программной системы, но и инфраструктуры, в которой она будет разворачиваться. Сопоставление таких моделей позволяет уже на этапе проектирования учитывать особенности конфигурации и эксплуатации приложения в определенной ИТ-среде.
Процесс разработки программной системы включает в себя несколько этапов, общих для большинства проектов: определение требований, проектирование, кодирование, тестирование и развертывание. В реальных проектах эти этапы охватывают множество последовательных и параллельных действий. Часть из них нацелены на «продвижение» проекта к конечному результату (создание прототипов, моделирование, кодирование, интеграция, отладка, подготовка пользовательской документации). Другие действия (планирование проекта, управление требованиями, документирование, мониторинг хода выполнения проекта, оценка рисков, финансовая оценка проекта, управление конфигурациями и изменениями, оценка качества, общее управление проектом и др.) создают условия для повышения эффективности процесса разработки. Как правило, чем больше затрат приходится на такие действия, тем более экономными и продуктивными оказываются базовые операции и тем более качественный результат они обеспечивают.
Эффективность процесса разработки повышается за счет интеграции инструментария, предназначенного для выполнения разных шагов и функциональных ролей. Если в среде разработки реализован и механизм управления потоками работ, поддерживающий логику процесса, то это — уже шаг к автоматизации управления разработкой как бизнес-процессом. Как правило, такие механизмы базируются на системе управления конфигурациями и изменениями (software configuration management, SCM). Она поддерживает единый репозитарий метаданных об основных артефактах разработки (требования, проектные модели, исходные коды, тесты и исполняемые модули готовой программы), отслеживает их изменения от этапа к этапу и от итерации к итерации, обеспечивает синхронизацию работы членов распределенных проектных команд.
Платформа разработки IBM
В 2003 году компания Rational, один из ведущих производителей инструментальных средств разработки, вошла в состав корпорации IBM. С этого момента началась интеграция продуктов Rational со средствами разработки из семейства WebSphere и другими линейками IBM. Кроме того, разрабатывались новые системы моделирования и проектирования, позволяющие учитывать последние тенденции в области программных архитектур. Результатом этих усилий стала представленная совсем недавно платформа разработки Software Development Platform, или SDP (рис. 1). Кроме того, IBM провела ребрендеринг своих средств разработки. Теперь все они, включая продукты из линейки WebSphere Studio, объединены под маркой Rational.
Рис. 1. Платформа разработки Software Development Platform
В SDP продукты для разных этапов разработки соотнесены с разными функциональными ролями. Они интегрируются с помощью платформы разработки с открытым кодом Eclipse [3], которая ориентирована преимущественно на создание программ для J2EE, но поддерживает и другие языки программирования. Eclipse предоставляет базовые функции среды разработки и механизмы интеграции дополнительных средств в виде подключаемых модулей (plug-in). Функциональность Eclipse можно расширять не только за счет продуктов IBM, но и с помощью решений партнеров и многочисленных участников Java-сообщества, которое заинтересовано в развитии этой платформы.
Eclipse создает в SDP технологический фундамент для автоматизации полного жизненного цикла разработки. Интеграционные механизмы Eclipse обеспечивают более тесные взаимосвязи между инструментами, выходящие за рамки простой интеграции на базе программных интерфейсов, которая практиковалась ранее для продуктов Rational. При этом Eclipse предоставляет SDP интерфейсную платформу, которая поддерживает согласованность графических интерфейсов пользователей для разных ролей в разработке; общие модели разработки для разных ролей и этапов жизненного цикла (Eclipse Modeling Framework, EMF); согласованный набор средств создания инфраструктуры коллективной разработки (интеграция с Team Unifying Platform).
Наиболее значимой в плане интеграции является возможность разделения информации между этапами и ролями с помощью общих моделей. Такую возможность предоставляет технология EMF, которая является реализацией спецификации OMG MOF (Meta Object Facility) для описания метаданных и обеспечивает семантическую интеграцию инструментария SDP. Для модели, определенной с помощью языка UML, XML-схемы или интерфейса на Java EMF генерирует соответствующие классы реализации. Тем самым обеспечивается механизм унифицированного представления структур данных, используемых инструментальными средствами для разных ролей в разработке.
Team Unifying Platform включает в себя системы поддержки совместной работы из других программных семейств IBM и общий репозитарий артефактов разработки для управления процессом. Компоненты Team Unifying Platform интегрируются в SDP как подключаемые модули Eclipse. Организация итеративного процесса разработки, контроль над версиями продукта, управление потоком заданий между ролями, синхронизация работы распределенных команд базируются на инструментах управления конфигурациями и изменениями, входящих в состав Rational ClearCase и ClearQuest. По версии IBM, определяющую роль в управлении процессом разработки играет методология RUP. Она является компонентом платформы Team Unifying Platform, конфигурируемым для поддержки ролей разработки.
Инструментарий в SDP поддерживает ряд выделенных ролей.
Аналитик отвечает за моделирование бизнес-процесса и определение требований к программному продукту. На соответствующем этапе могут использоваться новая система Software Modeler на базе UML2 (для визуального моделирования бизнес-аспектов программного проекта), RequisitePro (для документирования требований), а также WebSphere Business Integration Modeler (для описания бизнес-процесса с помощью языка BPEL4WS).
Архитектор моделирует логику приложения и данных. В портфеле IBM Rational на первый план выходит новая система Software Architect. Она реализует основные принципы разработки на базе моделей и соответствует спецификациям, которые OMG развивает как будущие стандарты MDA.
Разработчик занимается визуальным конструированием модулей приложения, трансформацией унаследованных систем, интеграцией компонентов и генерацией кода. Для этапа разработки IBM предлагает целый ряд продуктов, в том числе перешедших «под крышу» Rational из линейки WebSphere Studio.
Тестировщик отвечает за создание тестов и играет ключевую роль в обеспечении качества продукта. Для этапа тестирования в семействе Rational предусмотрены продукты, обеспечивающие функциональное, регрессионное и нагрузочное тестирование и проверку производительности.
Менеджер по развертыванию обеспечивает установку, конфигурирование, настройку и мониторинг готового приложения. На этапе развертывания предусмотрено использование программных средств из семейства IBM Tivoli.
Менеджер проекта отвечает за общее управление программным проектом, управление качеством, отслеживание хода процесса разработки и координацию работы распределенных команд. Он использует средства Team Unifying Platform.
Последнее дополнение SDP — роль руководителя высшего звена, который выполняет стратегическое управление портфелем программных проектов. Для автоматизации этой задачи IBM предложила систему Rational Portfolio Manager (реализованную на основе продуктов компании SystemCorp). Portfolio Manager помогает при оценке рисков и финансовом анализе проектов, при оптимизации выделения ресурсов, планировании и анализе возможного влияния проекта на бизнес предприятия. По сути, эта система позволяет «наводить автоматизированные мосты» между бизнесом и разработкой.
Кроме того, IBM работает над интеграцией процесса разработки с оперативным мониторингом действующих приложений. Первые шаги уже сделаны: в мае 2005 года были представлены программные средства, которые обеспечивают интеграцию систем разработки (Application Developer) и тестирования (Performance Tester) с инструментом мониторинга производительности транзакций (Tivoli Monitoring Transaction Performance). Теперь разработчики получают информацию о проблемах, возникающих в приложениях на этапе эксплуатации, и могут решать их на уровне исходных кодов программы. А тестировщики используют средства мониторинга и самоуправления, чтобы уже на этапе тестирования находить возможные причины проблем и варианты их устранения.
Рис. 2. Разработка, определяемая бизнесом |
В представлении IBM, жизненный цикл разработки вместе с руководством таким циклом и деятельностью оперативной службы — это замкнутый цикл, в котором к традиционным этапам разработки добавляются бизнес-анализ программных проектов и эксплуатация готового программного продукта (рис.2). Этот цикл в IBM называют процессом разработки, определяемым бизнесом (business-driven development, BDD). Для воплощения в жизнь полной автоматизированной поддержки BDD компании предстоит решить все проблемы интеграции средств разработки — и между собой, и, что особенно важно, с другими программными семействами (WebSphere для моделирования и управления бизнес-процессом разработки, Lotus для оптимизации коллективной работы в распределенных командах, Tivoli для связи разработки и эксплуатации).
Оптимизация создания программ: версия Borland
Надо признать, что изобретателем кольцевой диаграммы жизненного цикла разработки является компания Borland. Еще в 2003 году она предложила концепцию и технологии управления жизненным циклом приложений (application lifecycle management, ALM), замкнув в кольцо этапы определения требований, анализа, проектирования, разработки, тестирования, развертывания и сопровождения [4]. В центре этого кольца находится процесс управления изменениями, который играет координирующую и контролирующую роль в организации командной работы от итерации к итерации.
Три года назад, после множества приобретений, Borland предоставила продукты для реализации каждой фазы ALM, а сегодня предлагает глобальное видение масштабных проектов разработки в распределенных коллективах. Недавно сформулированная этой компанией стратегия развития и интеграции программных инструментов и сервисов, названная оптимизацией создания программного обеспечения (software delivery optimization, SDO), направлена на превращение разработки из неконтролируемой совокупности хаотических действий в управляемый бизнес-процесс.
Замахнуться на столь глобальную задачу Borland позволяют как собственный опыт создания инструментальных средств и организации взаимодействия с коллективами разработчиков по всему миру, так и новые приобретения. В прошлом году была куплена компания TeraQuest, специализировавшаяся на консалтинге по моделям зрелости CMM/CMMI. Это дало Borland возможность дополнить технологии, поддерживающие разработку как хорошо организованный итеративный процесс, сервисом постановки и совершенствования такого процесса.
SDO — стратегия Borland, которая будет реализовываться поэтапно в технологиях и сервисных предложениях компании. Первым этапом стал выпуск платформы Core SDP (Software Delivery Platform), обеспечивающей настраиваемые клиентские среды для четырех основных ролей в жизненном цикле разработки — аналитика, архитектора, разработчика и тестировщика (рис. 3). Соответствующую функциональность реализуют продукты Borland, предназначенные для поддержки разных этапов ALM — управления требованиями (CaliberRM), моделирования (Together), разработки (JBuilder), тестирования (Optimizeit). Однако Core SDP не является новой маркетинговой «шапкой» старого набора технологий. Здесь компоненты ALM интегрируются более тесно, а вместо парной интеграции отдельных продуктов рабочая среда каждой роли поддерживает встроенный доступ ко всем необходимым инструментам и разделение общей информации между ролями. В основе этой интеграции — единый репозитарий требований, изменения в котором отображаются в моделях, разрабатываемом коде и тестовых спецификациях.
Рис. 3. Платформа Core SDP
Единый репозитарий и ряд общих сервисов образуют базовую серверную инфраструктуру для всех клиентов-ролей в Core SDP, обеспечивают организацию потока задач и коммуникации между участниками разработки. Управление разработкой как процессом основано на механизмах управления конфигурациями системы StarTeam. Реализуется и ряд интересных сервисов для поддержки совместной работы в больших распределенных командах, например средства поиска ресурсов в репозитариях разных проектов, многоадресная рассылка для синхронизации оперативной информации между участниками проекта и др. Технологической платформой ролей Core SDP может служить J2EE-среда разработки Jbuilder или Eclipse, но для отдельных ролей возможна также интеграция с .NET, что позволяет говорить о поддержке гетерогенной инфраструктуры коллективной разработки. Важно отметить все возрастающую ориентацию продуктов Borland на платформу Eclipse. Пример IBM показывает, что это может дать серьезные преимущества при интеграции инструментов для разных ролей.
Одним из элементов стратегии SDO является поддержка разработки на базе моделей в соответствии со спецификациями, создаваемыми в OMG MDA. Вслед за анонсом Core SDP компания представила обновление одного из ее ключевых элементов — программного пакета Together. Новая версия Together 2006 на базе платформы Eclipse реализует функции моделирования для архитектора, проектировщика и разработчика, а также поддерживает основные принципы MDA. Кроме того, Together 2006 предоставляет возможность описания бизнес-процессов, но не на основе языка BPEL (как делается на платформе Rational SDP), а с помощью стандартной графической нотации Business Process Modeling Notation (BPMN), которую развивает OMG.
Еще одним направлением, в котором предполагается развивать процессы разработки в соответствии со стратегией SDO, является включение в их жизненный цикл этапов бизнес-планирования и эксплуатации приложений. Неудивительно, что Borland повторяет идеи IBM, связанные с автоматизацией связи разработки с бизнес-руководством и оперативной ИТ-службой. Действительно, реализация этих идей в условиях прямой зависимости бизнес-процессов от качества разработки приложений становится насущной необходимостью. До недавнего времени такие возможности оставались лишь планами, но осенью 2005 года Borland купила компанию Legadero, получив систему управления портфелем программных проектов. До сих пор этот компонент управления разработкой с точки зрения бизнеса не использовался в структуре жизненного цикла приложений Borland. Решение Borland Tempo станет частью Core SDP.
Командная разработка от Microsoft
В 2005 году Microsoft выпустила Visual Studio 2005 Team System (VSTS) — новую версию популярной среды разработки Visual Studio. В этой системе корпорация воплотила несколько прорывов в ее подходах к автоматизации разработки, хотя все они находятся в русле основных тенденций развития соответствующих инструментов. Как отмечают в Microsoft, «с выходом новой версии среда Visual Studio перестает быть просто удобной интегрированной средой для индивидуальных разработчиков; Team System превращает ее в мощный инструмент, объединяющий команду разработчиков со всеми доступными решениями на протяжении всего жизненного цикла разработки» [5]. Кроме поддержки ролей отметим в Team System такие нововведения, как интеграция методологии разработки Microsoft Solutions Framework (MSF) и первая реализация модели определения систем (System Definition Model, SDM) — одного из ключевых технологических элементов стратегии Dynamic System Initiative (DSI).
VSTS выпускается в редакциях для архитектора, разработчика и тестировщика (роль аналитика, обязательная для жизненного цикла разработки от IBM и Borland, в продуктах Microsoft пока отсутствует). Интеграция инструментария, предназначенного для разных ролей, базируется на еще одной редакции системы — Team Foundation Server. В ее задачи входит также автоматизация операций для роли менеджера проекта.
Team Foundation Server выполняет функции «движка» при организации и поддержке процесса разработки. Обеспечиваются создание проекта и управление им путем интеграции с Microsoft Project и Excel, управление изменениями ресурсов проекта, генерация отчетов, организация потока заданий между участниками разработки на разных этапах, их коммуникации между собой и т. д. При создании проекта Team Foundation Server позволяет определить, в соответствии с какой методикой будет выполняться разработка. Система интегрирована с MSF 4.0, представляющей собой совокупность описаний процессов, принципов и лучших практик разработки. Она впервые выпущена в двух редакциях — для команд, придерживающихся принципов «скорой» разработки (MSF for Agile Software Development), и для организации более формальных процессов в соответствии с принципами CMMI (MSF for CMMI Process Improvement).
Редакция Visual Studio 2005 Team Edition for Software Architects предоставляет инструменты для проектирования не только приложения, но и инфраструктуры его развертывания. Предполагаются две «подроли»: архитектор программного решения и архитектор соответствующей ИТ-инфраструктуры. Первый мыслит в терминах Windows- и Web-приложений, Web-сервисов, а второй работает с такими категориями, как порты, периметр сети, сетевые экраны, параметры защиты, конфигурация серверов и т. д.
Так Microsoft реализует связь между разработкой и эксплуатацией программных систем. В системе предусмотрены четыре дизайнера распределенных систем (Distributed System Designer): создание диаграмм приложений, диаграмм логического центра данных для описания настроек и ограничений распределенной инфраструктуры, диаграмм систем для конфигурирования сложных программных систем из диаграмм приложений, а также диаграмм развертывания, которые визуализируют привязку элементов системы к инфраструктуре.
Следующим шагом развития инструментальной среды VSTS станет задание архитектуры программ и инфраструктуры с помощью моделей определения систем. SDM — средство описания метаданных обо всех требованиях, которые предъявляются к системе на этапах проектирования, разработки, развертывания и эксплуатации. По замыслу Microsoft, SDM — средство передачи знаний о системе. Оно позволит не только проводить разработку с учетом особенностей ИТ-среды, но и опираться на информацию о приложении в ходе его развертывания и оперативного управления.
SDM предлагает технологию реализации основной идеи DSI — снизить сложность информационной среды за счет совершенствования взаимосвязей между фазами создания, развертывания и сопровождения распределенных систем. Такие взаимосвязи можно строить на базе четко определенных XML-схем — моделей SDM. В ходе разработки с помощью SDM будет описываться комплексная модель системы, объединяющая программные и аппаратные ресурсы. Эта модель определит действия операционной системы, нацеленные на динамическое распределение и конфигурирование заданных ресурсов на этапе развертывания. Наконец, специальный компонент времени выполнения SDM Service обеспечит управление готовым решением на основе все той же модели.
SDM воплощает собственный подход Microsoft к идее разработки на базе моделей (model-driven development), несовместимый с предложениями OMG. Для описания SDM-моделей используется не UML, а специальный язык Domain-Specific Language (DSL), который позволяет учитывать специфику среды .Net.
Первая реализация SDM — дизайнеры распределенных систем в VSTS. Дальнейшая интеграция принципов DSI в средства разработки ожидается в будущей версии Visual Studio, которая фигурирует под кодовым названием Orcas. Кроме того, поддержка моделей SDM будет реализована в следующих версиях ОС и управляющих системах Microsoft Operations Manager (MOM) и Systems Management Server (SMS).
Литература
- Walker Royce. Improving Software Development Economics. The Rational Edge, 2001.
- Software Delivery Optimization. Borland vision and solution strategy paper, 2005.
- Наталья Дубова, Платформа разработки Eclipse. // Открытые системы, 2005, № 3.
- Наталья Дубова. В круге разработки // Открытые системы, -- 2003, -- № 9.
- Richard Hundhausen, Introducing Microsoft Visual Studio 2005 Team System. Microsoft Press, 2005.