Определение потребностей проекта перед проведением автоматизации

А.В. Юрченко
ЗАО «ЕС-лизинг»,
г. Тула

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

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

- Почему все эти инструменты очень редко применяются?

- Насколько они сложны в использовании?

- Действительно ли они позволяют делать все то, что декларируют?

- Действительно ли организация готова применять такие инструменты?

- Достаточным ли образом подготовлен персонал, чтобы использовать данные инструменты?

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

Когда планируется автоматизация, необходимо ответить на следующие вопросы:

1. Насколько регулярно выполняются сборки ПО?

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

3. Отслеживаются ли дефекты на этапах идентификации, исправления, тестирования, закрытия, сборки и контроля?

4. Если используются методы ветвления, достаточно ли часто используются слияния?

5. Используется ли параллельная разработка?

6. Используются ли политики для потоков кода?

7. Достаточно ли используется «дымовое» тестирование, модульное тестирование, комплексное тестирование?

8. Используются ли хорошо документируемые процессы конфигурационного управления?

9. Если не используются, то почему?

10. Если используются, то достаточно ли долго, чтобы показать свою работоспособность и пригодность на практике?

11. Если нет, то рекомендуется использовать данные процессы как минимум 12 месяцев. Обычно этого времени достаточно, чтобы получить какой-либо существенный результат.

12. Все ли члены команды согласны с использованием данных процессов конфигурационного управления? Имеется в виду – следует ли внести еще больше изменений в процессы конфигурационного управления, чтобы улучшить их работу?

13. Если требуются изменения, то необходимо внести их во все требуемые места, и позволить поработать достаточное время (см. 10 шаг).

14. Если изменения не требуются, то текущие процессы конфигурационного управления можно считать рабочими, и можно рассматривать вопрос об автоматизации, но только в том случае, если конкретный процесс замедляет работу и является узким местом («бутылочным горлышком»).

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

Что требуется? Без чего можно обойтись? Каков бюджет? Существуют ли планы увеличивать команду разработчиков? Нужно ли решение для географически удаленных групп разработчиков?

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

Глоссарий

Ветвление (Branching) – в дисциплине конфигурационного управления программного обеспечения представляет собой контролируемое дублирование объектов (таких, как файл исходного кода, или дерево каталогов) таким образом, чтобы модификации могли происходить параллельно в обеих ветвях.

Дымовое тестирование (Smoke Test) – в тестировании ПО представляет собой минимальный набор тестов на явные ошибки кода. Такое тестирование обычно выполняется самим разработчиком. Не проходящую этот тест программу не имеет смысла отдавать на дальнейшее тестирование.

Конфигурационное управление программного обеспечения (Softwareconfigurationmanagement) – дисциплина отслеживания и управления изменениями в программном обеспечении.

Поток Кода (Codeline) – множество логических изменений, связанных между собой и выполняемых в течение промежутка времени для файла, группы файлов, либо для всего программного проекта в целом.

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

Слияние, объединение (Merging) (так же называется интеграцией) – операция, которая согласовывает множество изменений, сделанных для разных версий одних и тех же файлов. Необходима, когда версии файла менялись разными людьми в одно и тоже время.

Список литературы

1. Anne Mette Jonassen Hass, Configuration Management Principles and Practice, Addison Wesley, 2003, ISBN 0321117662

2. Dick Carlson, Making SCM Agile, CM Crossroads, April 2003

Назад к списку