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

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

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

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

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

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

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

MSF

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

• модель процессов (process model),
• модель команды (team model),
• модель управления проектами (project management),
• дисциплина управления рисками (risk management),
• управление подготовкой (readiness management).

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

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

1. Акцент на внедрении IT-решения.
2. Модель процесса, объединяющая спиральную и водопадную модели.
3. Особая организация команды – не иерархическая, а как группа равных, но выполняющих разные функции (роли) работников.
4. Техника управления компромиссами.

Ниже мы рассмотрим эти положения более детально.

В 2005 году MSF претерпело значительные изменения. Верcия MSF 4.0. стала составной часть продукта Visual Studio Team System (VSTS) и разделилась на две ветки – MSF for Agile и MSF for CMMI. При этом, если версии до 3.х были именно методологиями (там были изложены принципы, MSF свободно распространялась в виде Word-документов, которые были также переведены на русский язык), то теперь MSF превратилась в шаблоны процесса для VSTS. Эти шаблоны имеют описание в виде html -документов (Word-документов уже нет) и определяют типы ролей, их ответственности, действия в рамках этих ответственностей, а также все входные и выходные артефакты этих деятельностей и другие формализованные атрибуты процесса разработки. Кроме этого "человеческого" описания MSF for Agile и MSF for CMMI имеют XML -настройки, которые позволяют в точности следовать предложенным выше описаниям, используя VSTS. При этом на процесс накладываются достаточно жесткие ограничения, деятельность разработчиков сопровождается набором автоматических действий – все это задано в шаблонах. Данные шаблоны можно частично использовать (например, без некоторых ролей), а также изменять (VSTS предоставляет обширные средства настройки шаблонов). Версия MSF 4.2 продолжила направление версии MSF 4.0.

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