Управление конфигурациями

Лекция 10

Управление документацией

1. Введение

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

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

2. Согласованность и целостность документации

Ключ к поддержке заключается в том, что в документации каждая спецификация должна располагаться только в одном месте. Такую документацию мы называем целостной документация (single source documentation).

Для примера представим себе некоторое научное приложение с таким требованием: «счетчик числа бактерий есть целочисленной переменной, которая принимает значение от 1 до 100 000 000; эта переменная должна быть всегда доступная». Это требование документируется в SRS, и, на первый взгляд, выглядит привлекательным повторить его разных других местах — скажем, в начальном коде (в заглавии соответствующей функции) и в руководстве пользователя. Однако прежде чем так сделать, полезно оценить те проблемы, к которым приводят подобные требований. А проблемы эти возникают из неминуемых изменений, которым поддается проект на протяжении всего своего жизненного цикла и которые нужно отображать в документации. Если нужно было изменить наше требование, которое касается счетчика числа бактерий, это изменение нужно отразить везде, где оно повторяется. Отразить все изменения в спецификациях с отслеживанием всех мест, где эти спецификации повторяются, практически нереально, особенно если принять во внимание, что обычное это придется делать в условиях сжатых сроков выполнения проекта. Поэтому подобные повторения являются источником противоречия в документации, а противоречия ведут к неудаче проекта. Понятно, мы не можем избежать необходимости ссылаться из разных мест на один и тот же факт, но делать это нужно, не в нарушение целостности документации, например, используя механизм гиперссылок.

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

Рис. 1. Пример набора документации с гиперссылками

Динамические компоненты, отмеченные на рис. 1 — это те части документов, которые должны обновляться и (или) дополняться в ходе работы над проектом. Другими словами, большинство документов — «живые» объекты, о которых необходимо заботиться. Пример потому — SCMP План управления конфигурациями ПО (SCMP) SCMP (Software Configuration Management Plan) Software Configuration Management Plan (SCMP), который описывает версии конкретного документа. При внесении дополнений и изменений в ходе итеративной разработки проекта часто проводится обновление SRS.

Иногда встречаются ситуации, в которых просто необходимо переопределить требование (представить его в другом виде). Например, руководство пользователя руководство пользователя пишутся в несколько другой манере, чем документация разработки. К тому же иногда нужна многоуровневая структура документации. Да, на одном уровне нужен только короткий обзор, тогда как на другом — все к малейшим деталям. Осложнение структуры документации может привести к несогласованности ее ведения. Решением проблемы с несогласованностью в документации могут стать при условии поддержки перекрестных ссылок. Например, некоторый обзорный раздел может ссылаться на соответствующие разделы с подробными описаниями или требование из SRS может ссылаться на соответствующий раздел в руководстве пользователя. Это не лишает от повторного изложения одного материала, но облегчает поддержку целостности документации, поскольку обе версии виртуально находятся «рядом».

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

Управление конфигурациями

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

Незавершенное строительство дорогие — хороший пример инженерного проекта, который идет. Его легко увидеть, и уже обычно невозможно потерять! Мы же должны быть намного аккуратнее во время работы над программным продуктом, поскольку он или какая-то из частей как раз могут быть потеряны. Говоря о потере продукта или его части, мы имеем в виду не столько потерю самих файлов, сколько несоответствие их версий. Важнейшим требованием к ведению проекта является знание точного местонахождения частей проекта и связей, установленных между ними. Части проекта включают не только начальный текст программ, но и всю документацию, в частности план проекта. По этой причине мы так рано начинаем говорить в этой книге об управлении конфигурациями документация; управление конфигурациями. Мы должны уметь отслеживать изменения в документах еще до того, как разработан SPMP План управления программным проектом (SPMP) Software Project Management Plan (SPMP) SPMP (Software Project Management Plan).

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

Элементы конфигурации

Для отслеживания частей проекта сначала мы должны определить их пределы. Элементы конфигурации (CIs CI (Configuration Item) — это части проекта, отслеживаемые системой управления конфигурациями. Например, как показано на рис. 2, шестая версия метода расчета социальных отчислений для модуля подготовки платежных сведений какой-то бухгалтерской системы может быть названа элементом конфигурации S6.

Элемент конфигурации может состоять из других элементов конфигурации. Да, на рис. 2 элемент «Платежная ведомость версии 0.3.4.2» — модуль подготовки платежных сведений бухгалтерской системы — состоит из версии 6 частей S, версии 1 части A, версии 3 части Е и так далее В первом примере метод расчета выплат S обновляется с S6 до S7. Во втором к системе добавляется новый метод F1. Система конфигураций должна уметь различать все эти версии. На рис. 2 видно, что для этого изменяется номер версии модуля. Обычно классы — это отдельные элементы конфигураций. Отдельные функции могут быть элементами конфигураций, хотя это и не типичный случай. Мы не будем использовать элементы конфигураций мельче, чем функции, поскольку отслеживание составляющих частей функции практически неосуществимо. Значимые наборы данных, такие как глобальные таблицы, тоже могут быть элементами конфигураций.

Рис. 2. Элементы конфигурации

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

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

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

Разработчики программного обеспечения Абель и Берил взяли копии класса Заказчик, чтобы модифицировать его. Абель завершает работу и замещает старый класс Заказчик новым. Берил завершает работу и замещает старый класс Заказчик своим новым, теряя при этом все изменения, внесенные Абелем.

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

Обычно системы управления конфигурациями удовлетворяют следующим минимальным требованиям.

Деятельность по определению элементов конфигурации.

Отказ в праве на модификацию — для предотвращения одновременной работы больше чем одного человека над элементом конфигурации.

Авторизация доступа с правом модификации — дополнительно (не обязательно).

Процедура включения в проект:

• процесс авторизации;

• привлечение тестирования и так далее

Запись о предыдущих группировках элементов конфигурации, которые согласуются.

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

План управления конфигурациями (SCMP) : стандарт IEEE 828-1990

стандарты IEEE;SCMP (Software Configuration Management Plan) разработал стандарт по планированию управления конфигурациями документация; управление конфигурациями, IEEE 828-1990. Этот стандарт может быть очень полезный в процессе управления конфигурациями при проверке того, охвачены ли все основные положения. Содержание стандарта представлено дальше.

Введение

Управление конфигурациями

2.1. Организация

2.2. Ответственность за управление конфигурациями

2.3. Употребляемые политики, директивы и процедуры

Виды деятельности

3.1. Определение конфигурации

3.1.1. Определение элементов конфигурации

3.1.2. Именование элементов конфигурации

3.1.3. Получение элементов конфигурации

3.2. Контроль конфигурации

3.2.1. Запрос на изменения

3.2.2. Оценка изменений

3.2.3. Одобрение или неодобрение изменений

3.2.4. Реализация изменений

3.3. Определение статуса конфигурации

3.4. Аудиты и обзоры конфигурации

3.5. Контроль интерфейса

3.6. Контроль поставщиков и субподрядчиков

Расписание

Ресурсы

Сопровождение

В разделе 3.3 SCMP задокументировано, каким образом определяется статус управления конфигурациями (например: в письменном виде, раз в неделю). Раздел 3.6 присутствующий, если используется специальный инструментарий для управления конфигурациями или если управление конфигурациями выполняется субподрядчиком. Стандарт IEEE детально описывает назначение каждого из приведенных разделов. Мы пользуемся IEEE 828-1990 в примере в конце этого раздела.

Широко используются коммерческие системы управления конфигурациями, такие как SourceSafeSourceSafe компании Micrоsoft.

ОДИН Из СПОСОБОВ ПЛАНИРОВАНИЯ УПРАВЛЕНИЯ КОНФИГУРАЦИЯМИ

Сложите набросок вашего SCMP :

установите порядок действий при внесении изменений;

не указывайте ссылки на инструменты, если они еще не определены;

обратитесь например в конце этого раздела.

Определитесь с тем, которые из инструментов управления конфигурациями вам необходимы.

В учебных заданиях достаточно блокирования и резервного копирования.

Оцените инструменты с точки зрения ваших потребностей и бюджета :

широко используются коммерческие инструменты;

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

Завершите ваш SCMP.

Для учебных команд полностью подойдут веб-сайты, такие как www.egroups.com, документация, которая обеспечивает хранение. Одним из простых способов систематизации доступа для модификации есть изменение типа документа. Например, когда Джо берет SQAP на модификацию, то имя файла меняется из SQAP.txt на SQAP.joe. Хотя управление конфигурациями относится и к документации, и к начальному коду, соглашение об именовании файлов обычно планируется отдельно. Например, мы не можем заменить myClass.java на myClass.joe, не нарушив при этом порядок компиляции. Некоторые группы поддерживают два комплекта файлов. В одном комплекте содержится текущая версия, которая является основой, которая может быть изменена только в ходе формального процесса. Другой комплект содержит версии, которые находятся в разработке.

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

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: