СМ-Консалт
 

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

Статьи Управление конфигурациями и изменениями (ALM)

 В статье описана проблематика работы с подрядчиками в сфере разработки заказного программного обеспечения. Представлены способы построения совместной работы и даются практические советы по организации и использованию инструментария версионного контроля 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. Схема взаимодействия с подрядчиком
Рисунок 1. Схема взаимодействия с подрядчиком

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

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


Рисунок 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. Метрики по версиям файла исходного кода
Рисунок 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, так как данные проекта разработки (дефекты, задачи, поручения и запросы) тоже можно синхронизировать между удаленными площадками разработки.

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



Ресурсы

 

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

05.03.2009

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

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

Новости СМ-Консалт

Вышла версия BIPULSE 6.2

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Новые статьи в библиотеке

Мифы про ГОСТ 34

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2017.
Карта сайта