Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Организация совместной разработки программного обеспечения между заказчиком и подрядчиком с использованием IBM Rational ClearCase

 В статье описана проблематика работы с подрядчиками в сфере разработки заказного программного обеспечения. Представлены способы построения совместной работы и даются практические советы по организации и использованию инструментария версионного контроля IBM Rational ClearCase для работы с подрядной организацией. Рассматривается применение других инструментальных средств, позволяющих повысить качество и эффективность совместной работы.
Соломаха Евгений, главный специалист отдела конфигурационного управления, Новичков Александр, руководитель отдела внедрения и консалтинга, СМ-Консалт
Cтатья опубликована на сайте IBM.

Организация совместной разработки программного обеспечения между заказчиком и подрядчиком с использованием IBM Rational ClearCase

Введение

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

Проблематика заказчика

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

Заказчик зачастую обращается на рынок в поиске подрядчика (аутсорсера), но в конечном случае не в состоянии полноценно оценить и правильно выбрать исполнителя. Как правило выбор осуществляется по весьма субъективным факторам, что впоследствии негативно скажется на конечном результате.

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

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

В случае, если совместная разработка ведется с применением IBM Rational ClearCase, необходимо позаботиться об организации разделения полномочий доступа к исходному коду в связи с возникающими требованиями по линии безопасности, защиты от посторонних глаз уникальных областей кода, являющихся элементами защиты, и других вариантов реализации «ноу-хау».

Также возникает необходимость в выполнении проверки кода на наличие уязвимостей и «закладок». Так, например, по данным аналитической группы Quocirca, 90% организаций, пострадавших от действий киберпреступников, отдавали в разработку с привлечением сторонних разработчиков более 40% своих систем. По мнению экспертов, если вопросам безопасности не уделяется должного внимания, зачастую за скорость и дешевизну разработки приходится платить. Согласно результатам исследования, 60% заказчиков не проверяют безопасность решений на наличие уязвимостей, а еще 20% вообще не занимаются вопросами безопасности.

Так или иначе, данные подвержены уязвимости или разглашению. Несмотря на все договоры и обещания, реальные данные заказчика «утекают» именно из компании, берущей на себя аутсорсинг и тестирование. Количество баз данных на «черном рынке» говорит как раз об этом. Вариантов выхода из подобной ситуации не так много. Заказчику необходимо уделять пристальное внимание вопросам безопасности: нельзя просто «на слово» отдавать разработку без последующего контроля. Заказывающим организациям необходимо сохранить в какой-то мере собственные отделы разработки и тестирования, которые могли бы проводить приемочное тестирование на соответствие функционалу (тестировщики) и тестирование кода на наличие уязвимостей (разработчики).

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

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

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

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

Список можно продолжить, в каждом конкретном случае он может быть свой, но в любом случае придется сталкиваться с решением этих вопросов. У нашей компании есть подобного рода опыт, и в данной статье мы попробуем им поделиться, и как ни прагматично это звучит, многое реализуется в рамках практик IBM Rational Unified Process (RUP) и дисциплин, автоматизированных с помощью инструментария IBM Rational (ClearCase, ClearQuest, RequisitePro, средства тестирования, Portfolio Manager и т. д.).

Практика и реализация

Рассмотрим, что же все-таки необходимо сделать для организации:

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

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

Рассмотрим вариант, когда подрядчик (организация-подрядчик) работает в части проекта заказывающей организации (организация-заказчик), и при этом не использует в своей работе инструментарий управления конфигурациями IBM Rational ClearCase, а пользуется другим инструментарием.

Процесс взаимодействия может быть определен следующим образом (рисунок 1).

Рисунок 1. Схема взаимодействия с подрядчиком

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

Для реализации прозрачного процесса разработки можно использовать принцип параллельных потоков в организации работы в среде версионного контроля под управлением IBM Rational ClearCase (ClearCase). Для каждой группы определяются свой поток разработки и общий интеграционный, в котором объединяются (merge) и собираются релизы будущего программного продукта (ПП). Один из вариантов организации ветвления в ClearCase показан на рисунке 2.

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

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

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

• CheckStyle – один из самых известных модулей расширения Eclipse для контроля кода на соответствие определенным стандартам. Он инспектирует код в соответствии с набором правил, которые могут определяться для конкретного проекта, и позволяет работать над разными проектами с различными стандартами. Модуль выводит информационные подсказки на несоответствие кода стандартам.
• FxCop – модуль проверки кода на соответствие правилам. Он предоставляет средства автоматической проверки .NET-сборок на предмет соответствия правилам Microsoft .NET Framework Design Guidelines. Откомпилированный код проверяется с помощью механизмов рефлексии, парсинга MSIL и анализа графа вызовов. В результате FxCop способен обнаружить более 200 недочетов (или ошибок) в следующих областях: архитектура библиотеки, локализация, правила именования, производительность, безопасность. Модуль может работать как в графическом интерфейсе, так и в командной строке.
• В зависимости от языка и средства разработки модули могут варьироваться.

После того как подрядчиком выполнена определенная итерация разработки, программный код и документация передаются заказчику для контроля, объединения всех изменений, сборки и тестирования промежуточного релиза. Переданные исходные данные при импорте, при помещении под версионный контроль системы управления конфигурациями (УК) IBM Rational ClearCase, должны пройти проверку на соблюдение стандарта оформления и правил кодирования.

Затем программный исходный код необходимо проанализировать по отношению к предыдущему варианту. Должны быть также выявлены изменения и проверены на соответствие требованиям безопасности. Анализ кода по факту выявления «закладок» на предмет неустойчивых и критичных алгоритмов, по трудозатратам и по другим показателям может выполняться как вручную, так и с применением программного инструментария. Для автоматизированного варианта могут быть использованы анализаторы кода, в том числе и построенные на основе анализа и просчитанные по коду метрик (например, такие как Analyst4j, FindBugs, RefactorIt и др.). Код может быть проанализирован по следующим группам метрик: метрики размера программ, метрики сложности потока управления программами, метрики сложности потока данных программ и др. К размерно-ориентированным метрикам можно отнести метрики LOC-оценки (Lines of Code – LOC и Source Lines of Code – SLOC). Метрики сложности – это объектно-ориентированные метрики, метрики Холстеда, метрики цикломатической сложности по Мак-Кейбу, метрики Чепина и др.

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

Рисунок 3. Метрики по версиям файла исходного кода

Подробную информацию по практике реализации расчета метрик в ClearCase можно получить также из статьи «Метрики кода и их практическая реализация в IBM Rational ClearCase».

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

Следующим этапом идет сборка проекта, для нее применяется программный инструментарий, позволяющий полностью автоматизировать процесс. К инструментам, позволяющим автоматизировать процесс сборки, относятся: ANT, NANT, MSBuild, CruiseControl, BuildForge и другие широко представленные утилиты и программные комплексы. В сценарий сборки необходимо включать этапы тестирования, позволяющие на самом первом этапе выявить возможные ошибки. Вариант тестирования на этапе сборки выполняется в виде выполнения автоматизированных тестов. Для выполнения этого варианта тестирования применяют, в зависимости от языка программирования и платформы, следующий инструментарий: JUnit, NUnit, Clover, Ncover, IBM Rational Robot и др. В результате проведенного тестирования данные по найденным ошибкам помещаются в базу данных (БД) системы управления изменениями, реализованную на основе IBM Rational ClearQuest, и в дальнейшем могут быть доступны подрядчику и разработчикам заказчика в виде выполненного запроса в системе ClearQuest, WEB-сайта (ClearQuest WEB) или сформированного отчета для дальнейшей работы над ошибками.

Следующим этапом приемки кода, после получения сборки программного продукта, является этап тестирования, который может быть проведен по ходу выполнения нескольких типов тестов (функциональных, нагрузочных, по оценке производительности, удобства использования пользовательского интерфейса и др.), как вручную, так и с помощью средств автоматизации. Подробнее о выполнении тестирования можно узнать в статьях раздела «Тестирование. Инструментальные средства IBM rational Robot, TestManager, PurifyPlus, Functional tester, Performance Tester».

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

Описанные выше итерации повторяются до выпуска финальной версии продукта и сдачи проекта.

Теперь рассмотрим вариант, когда подрядчик, так же как и организация-заказчик, использует в своей работе инструментарий IBM Rational для организации процесса разработки. В данном случае сам процесс по основным этапам не претерпит особых изменений, но будут упрощены варианты взаимодействия. Становится возможным использовать IBM Rational MultiSite и полностью автоматизировать и упростить процесс доставки исходных кодов на удаленные площадки. В связи с этим появится возможность работы с единым репозиторием проекта на территориально разделенных площадках, почти (зависит от выбранного интервала синхронизации) в реальном режиме времени. Также становится возможным работать в единой БД системы управления изменениями на основе инструмента IBM Rational ClearQuest, так как данные проекта разработки (дефекты, задачи, поручения и запросы) тоже можно синхронизировать между удаленными площадками разработки.

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

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Проверка кода на соответствие стандартам и расчет метрик
  • CMT++/CMTJava(EN)
  • Java: CheckStyle, PMD, CDP(EN)
  • .NET: FxCop, DevPartner(EN)
  
  
• Юнит-тесты
  • Java: JUnit(EN)
  • .NET: NUnit(EN)
  • Coverage: Clover, Ncover(EN)
  
  
• Интеграционное и функциональное тестирование
  • Rational Robot(EN)
  
  
• Сборка
  • IBM Rational BuildForge(EN)
  • CruiseControl(EN)
  • Ant(EN)
  • NAnt(EN)

Ресурсы СМ-Консалт

• Практическая реализация автоматизированной системы проектирования и формирования нефтегазовой отчетности с использованием IBM Rational RequisitePro и SoDA
  
• Использование Method Composer при описании сложных и нестандартных процессов. Практика применения
  
• Rational Unified Process. Методология и технология  
• Оценка возврата инвестиций от внедрения процесса управления конфигурациями 
• Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа 
• Роль процесса Управления Требованиями при разработке сложных программных систем. Практика применения методологии IBM RUP и инструмента IBM Rational RequisitePro 
• Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational
• Стратегия и тактика обучения сотрудников в проекте внедрения методологии и технологии работ 
• Как правильно внедрить управление версиями и изменениями в софтверной организации 
• Консалтинг в тестировании
  
•  Инструменты, изменяющие процесс 

05.03.2009

Комментарии

• RWHcqHWzZRmll
  Автор: A good many valaubels you've given me.  ·  21.09.2011 02:58:22
  A good many valaubels you've given me.
• ZSGEpzJvPDjE
  Автор: Kudos! What a neat way of thniikng about it.  ·  20.08.2011 20:10:08
  Kudos! What a neat way of thniikng about it.
• DpamzImfGyhCOpCScPu
  Автор: Articles like this really gaerse the shafts of knowledge.  ·  19.08.2011 16:13:26
  Articles like this really gaerse the shafts of knowledge.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"