Система управления проектами DEVPROM позволяет разработчикам ПО готовить справочную документацию к программным продуктам без использования дополнительных инструментов, например, Author-It или RoboHelp, предоставляя следующие ключевые возможности:

Относительно недавно появилось русскоязычное издание книги Мэри и Тома Поппендик, посвященное практическим аспектам внедрения "бережливого" (lean) подхода в разработке программного обеспечения. В оригинале название книги звучит так: Implementing Lean Software Development.

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

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

Основные возможности

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

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

"The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits."

Процесс управления конфигурацией программных продуктов заключается в следующем:

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

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

• Идентификация версий разрабатываемого продукта, где номер версии и является основой (baseline) для конфигураций.
• Управление скоупом будущих версий, то есть фиксация бизнес требований в рамках некоторой версии продукта.
• Производство исполняемого кода на основе исходного кода, что достигается использованием сборочных станций или серверов.
• Тестирование работы исполняемого кода (программ) с целью выявления согласованности с исходными функциональными требованиями и различными критериями качества (нефункциональными требованиями).
• Подготовка заметок к релизу (release notes), которые описывают состав некоторой версии продукта, с указанием реализованных требований, выполненных доработок, исправленных ошибок, проверенных тестовых сценариев, места расположения исполняемых файлов и т.д.
• Трассировка одних артефактов в другие: доработок в требования, требований в тестовую и пользовательскую документацию, доработок и дефектов в исходный код, исходный код в исполняемый код и т.д. Тем самым обеспечивается возможность аудита и контроля за целостностью конфигурации некоторой версии продукта.
• Сохранение истории изменений и контроль версий каждого артефакта, например, требований, исходного кода, исполняемого кода. Типичные системы контроля версий как раз реализуют данную часть процесса управления конфигурацией.

DEVPROM совместно с системой контроля версий, инфраструктурами автотестирования и выпуска сборок, реализует полноценную систему управления конфигурацией:

• Все артефакты, создаваемые при разработке продукта, имеют свой уникальный идентификатор в системе, позволяя тем самым идентифицировать конфигурационные элементы.
• Этапы разработки программного продукта неразрывно связаны с версиями продукта, к которым привязываются все артефакты: пожелания, требования, тестовая и пользовательская документация, тесты, файлы и т.д.
• Журналы пожеланий, управление требованиями, тестовой и пользовательской документацией позволяют создавать весь необходимый набор артефактов для заданной версии продукта, то есть определять конфигурацию для заданного baseline.
• Автоматическое создание связей между пожеланиями, задачами, требованиями, тестовой и пользовательской документацией, позволяет организовать согласованную конфигурацию программного продукта и выполнять аудит с целью выявления рассогласований. DEVPROM автоматически отслеживает неактуальные связи и предлагает выполнить согласование (приведение в соответствие) артефактов между собой.
• Все изменения в системе протоколируются, что позволяет контролировать любые изменения в конфигурации, выполненные участниками проекта.
• Формирование заметок к релизу (release notes) для определенной версии продукта, включающих в себя список реализованных доработок и исправленных ошибок.