МЕТОДОЛОГИЯ И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ДЛЯ ПОДГОТОВКИ КУРСОВЫХ И ДИПЛОМНЫХ ИТ-ПРОЕКТОВ В СОСТАВЕ КОМАНДЫ

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

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

Осознавая эту потребность, компания Microsoft представила новейший пакет инструментальных средств - Microsoft Visual Studio Team System. Данный пакет тесно интегрирован с другими программными продуктами этой компании, такими как Microsoft Office, Windows SharePoint и др.

Необходимость создания единого хранилища и управляющего инструментария для всей информации касаемо разрабатываемого проекта назревала давно. Иначе, в ситуации какого-либо сбоя у одного из участников проекта неизбежны потери информации, ценной для всей команды. В новом продукте Microsoft роль хранилища и автоматизированного координатора играет Team Foundation Server. Сервер визуализирует всю информацию посредством интерактивного web-сайта использующего Windows SharePoint Server (рис 1).

Ключевыми членами проектной команды являются: руководитель проекта, архитектор, разработчик и тестировщик. Каждую из этих ролей может исполнять как один человек, так и несколько. Второстепенные участники проекта, являющиеся профессионалами в области информационных технологии, также по достоинству оценят использование Team System, так как эта система облегчит им взаимодействие с остальными членами команды (рис 2).

Итак, при использовании Visual Studio Team System решаются следующие задачи:

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

Теперь об основных частям Visual Studio Team System и их ролях в проекте.

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

Другими задачами, для решения которых служит Team Explorer являются:

• Подключение к выбранному серверу Team Foundation Server;
• Настройка Team Foundation Server, в том числе определение групп, параметров безопасности, шаблонов процессов и типов файлов, на которые распространяется действие системы управления версиями;
• Создание новых командных проектов;
• Настройка параметров проекта;
• Добавление в проект рабочих элементов, библиотек документов и отдельных документов, а так же управление этими объектами;
• Создание и выполнение сборок.

Руководитель проекта осуществляет планирование с помощью Microsoft Excel либо Microsoft Project. Эти приложения способны напрямую подключаться к Team Foundation Server и редактировать его содержимое, после чего измененная информация сразу же становится доступной всем участникам проекта.

Несмотря на то, что в Team System роль архитектора не делима, оптимальным будет разделение ее на две категории: одна будет отвечать за web-сервисы, web-приложения и приложения Windows, а другая - за порты, сетевое окружение, брандмауэры, защиту и конфигурацию серверов. В целом, роль архитектора необходима для того чтобы облегчить труд разработчиков во многих задачах, таких как оформление технической документации и присутствие на совещаниях. Архитекторам необходимы средства конструирования с интуитивным интерфейсом, обладающие при этом определенной эффективностью, например, автоматически генерирующие программный код. Такие средства, называемые конструкторами распределенных систем входят в состав Visual Studio Team Edition for Architects. Диаграммы, сгенерированные с помощью инструментальных средств архитектора предоставляют остальным членам команды (не обладающим знаниями архитектора) всю необходимую информацию.

Visual Studio Team System предоставляет разработчику богатый инструментарий, с помощью которого в кратчайшие сроки можно эффективный и свободный от ошибок код. К числу средств Team System предназначенных для разработчиков относится: конструктор классов, позволяющий строить диаграммы классов с помощью которых автоматически генерируется код, инструменты модульного тестирования, средства анализа покрытия кода, статического анализа и профилирования. Работа, выполняемая при помощи этих средств, может отслеживаться и координироваться с помощью рабочих элементов. Главным элементом с которым имеют дело все члены команды, является задача. Задача используется для назначения задания тому или иному члену команды. Такой элемент снабжается комментариями, система отслеживает изменение его состояния, информация из него включается в отчеты, а когда задание выполнено, элемент закрывается.

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

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

В семействе программ Microsoft Visual Studio специализированные средства для тестировщиков появились только в Team System. Эти средства используются на протяжении всего цикла разработки и сопровождения программного продукта. Раньше для создания и выполнения тестов использовались средства сторонних производителей, а для управления процессами отслеживания и устранения дефектов приходилось разрабатывать собственные решения.

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

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

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

Методология фирмы Микрософт при разработке ИТ проектов

MICROSOFT SOLUTION FRAMEWORK

Visual Studio Team System является не только средой разработки, содержащей необходимый инструментарий для каждого из членов команды разработчиков. VSTS - инструментальное воплощение Microsoft Solution Framework.

Microsoft Solution Framework представляет собой методологию разработанную Microsoft c учетом как собственного опыта разработки программного обеспечения так и опыта других ведущих корпораций.

Функционально методология MSF 4.0 разделена на следующие части:

• MSF for agile software development - представляет собой слабо формализованную версию MSF, предназначенную для использования в разработке, опирающейся на опытные кадры; ориентирована на использование в условиях конкуренции и меняющихся условий разработки;
• MSF for CMMI Process Improvement - в данной версии процесс разработки является строго документированным, уделяется большое внимание процессу планирования. Основное и главное отличие от MSF Agile заключается в высокой управляемости проекта и предсказуемости результата. Модель ориентирована на большие команды и процессы.

MSF состоит из двух моделей и трех дисциплин.

• Модели MSF

  Модель процессов (Process Model) представляет собой общую методологию разработки и внедрения IT - решений. Данная модель процессов являет собой сочетание двух классических моделей: каскадной (waterfall) и спиральной (spiral).

  Фазы разработки согласно MSF Process Model:

  • Фаза выработки концепции(Envisioning). Цели фазы: создание проектной группы, выработка единого видения проекта;
  • Фаза планирования (Planning). На данном этапе создаются функциональные спецификации, дизайны и рабочие планы, оцениваются проектные затраты и сроки разработки;
  • Фаза разработки (Development). На данной фазе создаются компоненты решения и документация, также ведется разработка инфраструктуры;
  • Фаза стабилизации (Stabilizing). Проводится тестирование созданного решения. Решение эксплуатируется в созданной модели рабочей среды. Выявляются и устраняются ошибки, решение готовится к выпуску;
  • Фаза внедрения (Deployment). Решение внедряется в рабочую среду и стабилизируется. Работы в рамках данного решения передаются службе поддержки. В завершении фазы - анализ проделанной работы;

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

  Ролевые кластеры:

  • Управление продуктом
    Основная цель - удовлетворение заказчика.
    Функции :
    1. Данный ролевой кластер является представителем заказчика в команде;
    2. Формирует у команды общее видение проекта;
    3. Организует маркетинг и PR;
    4. Разрабатывает и поддерживает план коммуникаций.
  • Архитектура
    Основная цель - разработка архитектуры проекта, удовлетворяющей требованиям проекта.
    Функции:
    1. Разрабатывает архитектуру приложений;
    2. Разрабатывает архитектуру логической среды, в которой будет использоваться приложение;
    3. Сопоставляет архитектуры приложений и логической среды для выяснения возможности реализации приложения в обозначенных рамках среды.
  • Управление программой
    Основная цель - достижения результата в рамках проекта.
    Функции:
    1. Управляет процессом разработки;
    2. Формирует спецификацию продукта;
    3. Регулирует коммуникации внутри проектной группы;
    4. Организует управление рисками.
  • Разработка
    Основная цель - создание продукта в соответствии со спецификацией.
    Функции:
    1. Определяет детали физического дизайна;
    2. Оценивает необходимые время и ресурсы на создание каждого отдельного элемента дизайна;
    3. Разрабатывает элементы приложения, либо контролирует их разработку;
    4. Подготавливает продукт к внедрению;
    5. Консультирует команды по технологическим вопросам.
  • Тестирование
    Основная цель - добиться соответствия продукта поставленным требованиям, выявить все дефекты.
    Функция:
    1. Обнаружение дефектов;
    2. Разработка стратегии и планов тестирования
    3. Осуществление тестирования
  • Удовлетворение потребителя
    Основная цель -увеличение потребительской ценности приложения.
    Функции:
    1. Представляет интересы потребителя в команде;
    2. Организует работу с требованиями заказчика;
    3. Определяет требования к системе помощи и ее содержание;
    4. Разрабатывает учебные материалы и осуществляет обучение пользователей.
  • Управление выпуском
    Основная цель - внедрение и сопровождение продукта.
    Функции:
    1. Представляет интересы отделов обслуживания продукта;
    2. Организует снабжение проектной группы;
    3. Организует внедрение продукта.

• Дисциплины MSF

  Дисциплина управления проектами (Project Management). Сюда входят следующие области:
  • Планирование и мониторинг проекта, контроль за изменениями в проекте (Project planning / Tracking / Change Control);
  • Управление рамками проекта (Scope Management);
  • Управление календарным графиком проекта (Schedule Management);
  • Управление стоимостью (Cost Management);
  • Управление персоналом (Staff Resource Management);
  • Управление коммуникацией (Communications Management);
  • Управление рисками (Risk Management);
  • Управление снабжением (Procurement);
  • Управление качеством (Quality Management).

  Дисциплина управления рисками (Risk Management). Данная дисциплина отстаивает следующие поло-жения: превентивное управление рисками, непрерывная оценка имеющихся рисков, интеграция этих процессов в общую деятельность.
  Этапы процесса управления рисками:

  • Выявление. Члены проектной группы выносят на обсуждение факты наличия рисков;
  • Анализ и приоритезация. Во время анализа факты из предыдущей фазы перерабатываются в форму, позволяющую произвести дальнейшую приоритезацию. Приоритезация рисков позволя-ет проектной группе управлять наиболее важными из них;
  • Планирование. Цель - выработка конкретных стратегии, планов и шагов управления рисками;
  • Мониторинг. Выполняется наблюдение за конкретными рисками и прогрессом осуществления составленных планов;
  • Корректирование. Процесс исполнения принятых в отношении рисков планов;
  • Извлечение уроков. Перевод полученного опыта в форму, доступную для использования внутри проектной группы и на уровне предприятия.

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

VISUAL STUDIO TEAM SYSTEM И MSF

Рассмотрим более подробно, каким образом методология MSF находит свое отражение в инструмента-рии 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 может быть достигнут сочетанием вышеперечисленных редакций.

Так каждая из компонент Visual Studio Team Suite содержит соответствующий инструментарий для кластерных ролей: управления проектом, архитектура, разработка, тестирование. VSTF обеспечивает: с одной стороны, централизованное хранение всех документов, относящихся к проекту, средствами VSTF определяются политики внесения изменений в проект, отслеживается деятельность каждого из команды, поддерживается хранение различных версий и ветвей создаваемого решения. С другой стороны, VSTF служит для организации коммуникаций средствами Microsoft SharePoint Services 2.0: создается портал проекта, где хранится все необходимая информация, во-первых, для самих разработчиков, во-вторых, для заказчика. Средствами данного портала могут назначаться задания и определяться сроки. Сам портал спроектирован таким образом, чтобы сделать эффективным взаимодействие между территориально удаленными членами команды.

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

На этапе создания команды выбирается методология (MSF Agile или MSF for CMMI Process Improvement), описываются роли участников проекта, создается портал, определяются этапы проекта. Портал создается автоматически при создании проекта средствами VSTS на основе технологии Microsoft SharePoint Services 2.0

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

Инструменты архитектора позволяют ему создавать три типа диаграмм: Application Diagram (архитектура компонентов решения), Logical Datacenter Diagram (логическая среда развертывания), Deployment Diagram (размещение компонентов решения на логических серверах).

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

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

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

Особенности прохождение производственной практики и разработки курсовых, а также дипломных проектов в составе команды, в ВУЗах.

1. Подготовка технических заданий на проекты.
   Подготовка технических заданий на дипломное и курсовое проектирование, а также выдача заданий на производственную практику в составе команды требует от руководителя знание методологии и инструментальных средств коллективной разработки. Желательно повышение квалификации на специализированных курсах. Наличие аппаратно-программных средств для разработки проекта. Личный состав команды должен быть хорошо известен преподавателю или он должен иметь подробную характеристику на каждого члена команды. Технические задания составляются с учётом успеваемости и наклонностей членов команды. Сам текст технического задания должен содержать требования к каждой роли из состава команды и пункты ТЗ, за которые он отвечает лично.
2. Методика выполнения проектов и заданий.
   Из описания технологии определяется роль каждого члена команды и он начинает выполнять свою часть работы, но в условиях ВУЗа данная практика не срабатывает по следующим причинам: Если заранее распределить роли то каждый член команды будет знать только свою роль, совершенно не изучив другие роли сценария, что чревато пробелами в подготовке. Во вторых образуется разрыв по времени реализации проекта членами команды. Например, тестер не может начать реализацию проекта только после программиста и архитектора. В, данном случаи авторы статьи поступают следующим образом - все участники команды на первом этапе имеют одинаковый статус, например архитектора и менеджера, разработав план и архитектуру проекта каждый выносит свою реализацию на семинар где определяется лучший архитектурный проект, далее все участвуют в разработке кода. При разработке кода каждый участник получает задание на свою часть проекта и реализует её, результаты идут в проект. Затем весь коллектив начинает тестировать проект, лучшие результаты в тестировании архитектурного решения и фрагментов программы позволяют определить роль и степень участия каждого члена команды в разработке проекта. Данный метод позволяет всем участникам проекта освоить все роли а команде.