Обучение работе в группе

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

Сегодня в рамках многих программ ИТ-обучения предлагаются курсы по ведению программных проектов [1]. Методики этих курсов во многом отличаются друг от друга и единого представления о том, какие темы должны такие курсы освещать, практически не существует. Большинство университетских программ включают по крайней мере один вводный курс по программной инженерии, и очень немногие предлагают несколько разных курсов по этой теме.

Студенты Авиационного университета Эмбри-Риддла на первом курсе изучают процесс персональной разработки программного обеспечения (Personal Software Process, PSP) [2, 3], а в последующие два года — вводный курс, посвященный групповой разработке программного обеспечения (Introductory Team Software Process, TSPi) [4]. В курсе PSP преподавание фундаментальных практических методов опирается на парадигму поэтапной разработки. Курс TSPi, посвященный изучению методов работы в группе, дает студентам представление о практических вопросах и проблемах, возникающих в процессе разработки продуктов в команде. Многие учебные заведения проповедуют аналогичный подход [5]. В статье рассказывается об опыте преподавания TSPi.

Курсы по ведению программных проектов

В соответствии с рекомендациями, сформулированными рабочей группой CC2001 Task Force все академические программы по ИТ должны включать:

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

Курсы варьируются от ситуации, когда группа из двух-трех студентов-первокурсников работает над краткосрочным (несколько недель) проектом, до годичной программы для старшекурсников, когда группа студентов работает с реальными или с «почти реальными» пользователями. В ряде университетов студенты включаются в проекты, которые ведутся в лабораториях или студиях этих учебных заведений и часто предусматривают разработку и поддержку ПО [7-9].

Один из самых горячо обсуждаемых — вопрос о том, должны ли и в каком объеме курсы по ведению проектов включать в себя работу в реальных условиях. Одни считают, что целесообразно заставлять студентов принимать участие в реальных проектах с их неопределенными требованиями и нереальными или трудно поддающимися контролю сроками, следуя принципу «либо научатся плавать, либо утонут». Другие являются сторонниками выполнения искусственных проектов со стабильными требованиями и реалистичными сроками в знакомой среде разработки. Большинство учебных курсов занимают промежуточное положение.

Подготовка учебного курса

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

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

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

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

Вводный курс групповой разработки

В Институте инженерии программного обеспечения разработана серия методов по совершенствованию процесса создания программного обеспечения, ориентированная на работу отдельных программистов, групп и организаций. PSP помогает программистам организовывать и планировать свою работу, следить за тем, как продвигается разработка, контролировать качество разрабатываемого программного продукта, а также анализировать и повышать производительность труда [2,3]. Его изучение закладывает необходимую основу для последующих курсов, посвященных освоению работы в группе. Сейчас вводные и специализированные курсы по PSP предлагают свыше 30 вузов.

После изучения PSP студентам предлагается учебный курс по разработке программных проектов с помощью TSPi, «академической» версии Team Software Process, который применяется отраслевыми группами разработчиков программного обеспечения. Материалы по TSPi включают в себя учебник, руководство преподавателя, вспомогательный инструментарий и набор сценариев, форм, стандартов и методов, необходимых для разработки качественных программных продуктов [4]. В соответствии с TSPi проект по созданию программного обеспечения разделяется на циклы разработки, и по окончанию каждого из них группа предоставляет часть готового продукта. На рис. 1 показана циклическая структура процессов TSPi. Студенты выполняют два или три цикла за один семестр. На последнем цикле студенты интегрируют и тестируют законченную систему.

Рис. 1. Структура и диаграмма процесса Introductory Team Software Process. Группа создает продукт за несколько циклов, интегрируя и тестируя законченную систему на последнем цикле

Описание процесса

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

• Цель группы - создать качественный продукт.
• Первый критерий достижения цели - свыше 80% ошибок найдено перед первой компиляцией.
• Второй критерий - при тестировании системы не найдено ни одной ошибки.
• Третий критерий - по завершении проекта все требования к продукту корректным образом реализованы.

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

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

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

На этапе планирования группа создает развернутый план, включающий:

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

Мнения студентов и преподавателей

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

Прежде всего, возникали проблемы, связанные с ошибками в первой версии инструментария TSPi, а также с его размером (слишком объемен для использования в группе). Кроме того, важную роль играл и уровень подготовки студентов по PSP. Чем лучше эта подготовка, тем вероятнее, что студенты смогут оценить и корректно использовать процесс TSPi. Вот некоторые отзывы преподавателей о процессе и курсе TSPi.

• "Дает очень хороший материал для того, чтобы помочь студентам формировать группу: определение ролей, четкие обязательства, организация взаимодействия друг с другом, планирование и так далее".
• "Очень хорошее средство обучения разработке проектов, при условии, что студенты уже изучили PSP. Он предоставляет множество полезных методик, которые студенты могут взять, опробовать и перенести из процесса обучения на свою реальную работу".
• "Никогда больше не буду вести курс по групповой разработке без TSP!"

Общий итог — наиболее положительную оценку новым программам давали студенты, которые изучали PSP на первом курсе, а затем использовали его. Там, где преподаватели включали PSP и TSPi в конец учебного плана, возрастало число студентов, которые выражали недовольство требуемой от них дисциплины. Кроме того, студенты, уже являющиеся квалифицированными программистами и никогда не сталкивавшиеся с проблемами управления и обеспечения качества, которые решают PSP и TSP, демонстрировали определенный скепсис.

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

Анализ полученных данных

Программа Авиационного университета Эмбри-Риддла предусматривает изучение TSPi в рамках проводимого на втором или третьем году вводного курса по групповой разработке. Обязательным требованием является знание языка объектно-ориентированного программирования (например, Ada, C++ или Java) и PSP.

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

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

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

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

Группы достаточно точно оценили трудозатраты для первого цикла, но переоценили их для второго. Это объясняется тем, что группы при подготовке плана второго цикла опирались на данные первого цикла, но их средняя производительность ко второму циклу выросла на 66%. Если бы курс состоял из трех циклов, студенты имели бы возможность понять это и внести необходимые коррективы. Рис. 2 показывает распределение трудозатрат по этапам разработки.

Рис. 2. Трудозатраты по этапам (в %). Раздел «Разное и анализ» включает этапы старта и анализа по завершении цикла, а также подготовку окончательного отчета и презентации проекта. К «Планированию» относятся этапы планирования и разработки стратегии

Если учесть объем задачи и ее сложность, то 15,6% трудозатрат на определение требований — вполне приемлемый результат. Но 13% трудозатрат на проектирование — слишком мало и, вероятно, является одной из причин высокой плотности ошибок на этапе тестирования. В курсе объясняется простая методология объектно-ориентированного проектирования, но практического опыта проектирования у студентов недостаточно, пока они не изучат вводный курс анализа и проектирования программного обеспечения. Рис. 3 показывает среднее число ошибок, привнесенных и устраненных на каждом этапе проекта. Видно, что группы находят и устраняют около 80% ошибок еще до начала тестирования. Это очень неплохо для младшекурсников.

Рис. 3. Число ошибок по этапам. Студенты выявили и устранили большинство ошибок еще до начала тестирования

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

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

Рекомендации

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

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

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

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

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

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

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

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

Литература

Уоттс Хэмпфри — сотрудник Института программной инженерии Университета Карнеги-Меллона; Томас Хилбурн — сотрудник Авиационного университета Эмбри-Риддла.

Летний семинар для преподавателей по PSP и TSPi

В течение последних шести лет Институт программной инженерии (www.sei.cmu.edu/tsp/workshop.html) проводит летний семинар по PSP и TSPi. Семинар был призван научить преподавателей:

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

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