Оценка Open Source проекта по CMMI
В последнее время Открытое ПО становится всё популярнее. Правительства многих стран, крупные корпорации стали рассматривать Linux,
OpenOffice.org и другое свободное ПО как достойную альтернативу коммерческим программам. Однако сам процесс создания свободного ПО изучен достаточно плохо. Пожалуй, единственная широко известная работа по данной тематике - «Собор и Базар» Эрика Рэймонда [1].
К сожалению, данная работа была написана 10 лет назад и на сегодняшний день несколько устарела. А другие авторы в основном изучали социальные и экономические аспекты OSS-проектов [2]. И только в последние годы появилось несколько работ, где открытое ПО рассматривается с точки зрения инженерии ПО. В докладе представлены выводы, полученные в процессе написания дипломной работы, направленной на изучение вопроса, насколько возможна оценка проектов Open Source по модели CMMI [3].
что такое CMMI
Модель CMMI (Capability Maturity Model) создана институтом инженерии ПО по заказу Министерства обороны США. Он был призван решить задачу оценки зрелости процессов и повысить их эффективность. На данный момент CMMI является de facto стандартом оптимизации процессов по созданию ПО. Внедрение СMMI позволило организациям добиться значительного улучшения качества, уменьшить количество дефектов и сократить время разработки.
Существует несколько разных моделей – для управления субподрядчиками, закупками (Acquisition) и наиболее интересная с точки зрения разработчика ПО модель процесса разработки систем (CMMI for Development). Модель позволяет описать любой процесс разработки, в том числе и ПО. Для этого весь жизненный цикл разбивается на 4 категории и 22 области процесса.
что такое Agile-методики
Agile [4] стал ответом программистского сообщества на попытку навязать традиционный подход к созданию ПО. По мнению сторонников Agile, попытки устранить из проектов неопределённость заранее обречены на неудачу. Даже в идеальном случае, если клиент получит ту систему, которую он заказывал полгода назад, совершенно необязательно, что она удовлетворит его потребности сегодня и будет пригодна для расширения в нужном для него направлении.
Agile предлагает не устранять неопределённость, а контролировать её путём более коротких итераций, фиксацией сроков, а не функциональности и более тесного контакта с клиентом.
выводы и результаты
В ходе изучения моделей процессов создания свободного ПО в различных проектах был сделан вывод, что единого процесса, характерного для всех проектов Open Source, не существует, так как проекты достаточно сильно отличаются друг от друга размерами, задачами, целевой аудиторией.
Поэтому первой задачей оказалось создание классификации процессов разработки ПО в проектах Open Source. В результате был выделен ряд параметров, на основании которых возможно объединить проекты в эквивалентные классы:
- разработчики: один или команда;
- местоположение команды: централизованно/локально или распределённо/глобально;
- целевая аудитория: конкретный заказчик или массовый потребитель;
- коммерциализация: коммерческий или некоммерческий проект;
- степень сотрудничества: близкое\плотное или слабое.
Охарактеризовав проект свободного ПО по этим параметрам, можно составить его достаточно точный портрет.
Следующей задачей стало оценить проект свободного ПО по CMMI. Однако прямой подход - дословно интерпретировать требования модели -
бесперспективен, так как ряд задач в проектах свободного ПО решается иными способами. Кроме того, часть описываемых практик малополезна для проектов свободного ПО. Поэтому были изучены способы оценки Agile-методик, к которым можно причислить и модель создания открытого ПО.
В качестве эксперимента был оценен проект plone.org. Проект был выбран, как начатый с нуля, достаточно зрелый (развивается с 2001 года), успешный (в тройке наиболее популярных свободных систем управления контентом) и широко распространенный (используется такими организациями, как NASA и FSF). Оценка проекта была выполнена по следующим областям:
- планирование проекта (уровень 0);
- управление проектом (уровень 1);
- управление конфигурацией (уровень 2);
- измерения и анализ (уровень 0);
- определение требований пользователей (уровень 2).
ссылки
1. http://www.catb.org/~esr/writings/cathedral-bazaar/
2. http://opensource.mit.edu/online_papers.php
3. http://www.sei.cmu.edu/cmmi/
4. http://en.wikipedia.org/wiki/Agile_software_development
Василий В. Савин, Вильнюс, Литва, vasilij.savin@gmail.com
OpenOffice.org и другое свободное ПО как достойную альтернативу коммерческим программам. Однако сам процесс создания свободного ПО изучен достаточно плохо. Пожалуй, единственная широко известная работа по данной тематике - «Собор и Базар» Эрика Рэймонда [1].
К сожалению, данная работа была написана 10 лет назад и на сегодняшний день несколько устарела. А другие авторы в основном изучали социальные и экономические аспекты OSS-проектов [2]. И только в последние годы появилось несколько работ, где открытое ПО рассматривается с точки зрения инженерии ПО. В докладе представлены выводы, полученные в процессе написания дипломной работы, направленной на изучение вопроса, насколько возможна оценка проектов Open Source по модели CMMI [3].
что такое CMMI
Модель CMMI (Capability Maturity Model) создана институтом инженерии ПО по заказу Министерства обороны США. Он был призван решить задачу оценки зрелости процессов и повысить их эффективность. На данный момент CMMI является de facto стандартом оптимизации процессов по созданию ПО. Внедрение СMMI позволило организациям добиться значительного улучшения качества, уменьшить количество дефектов и сократить время разработки.
Существует несколько разных моделей – для управления субподрядчиками, закупками (Acquisition) и наиболее интересная с точки зрения разработчика ПО модель процесса разработки систем (CMMI for Development). Модель позволяет описать любой процесс разработки, в том числе и ПО. Для этого весь жизненный цикл разбивается на 4 категории и 22 области процесса.
что такое Agile-методики
Agile [4] стал ответом программистского сообщества на попытку навязать традиционный подход к созданию ПО. По мнению сторонников Agile, попытки устранить из проектов неопределённость заранее обречены на неудачу. Даже в идеальном случае, если клиент получит ту систему, которую он заказывал полгода назад, совершенно необязательно, что она удовлетворит его потребности сегодня и будет пригодна для расширения в нужном для него направлении.
Agile предлагает не устранять неопределённость, а контролировать её путём более коротких итераций, фиксацией сроков, а не функциональности и более тесного контакта с клиентом.
выводы и результаты
В ходе изучения моделей процессов создания свободного ПО в различных проектах был сделан вывод, что единого процесса, характерного для всех проектов Open Source, не существует, так как проекты достаточно сильно отличаются друг от друга размерами, задачами, целевой аудиторией.
Поэтому первой задачей оказалось создание классификации процессов разработки ПО в проектах Open Source. В результате был выделен ряд параметров, на основании которых возможно объединить проекты в эквивалентные классы:
- разработчики: один или команда;
- местоположение команды: централизованно/локально или распределённо/глобально;
- целевая аудитория: конкретный заказчик или массовый потребитель;
- коммерциализация: коммерческий или некоммерческий проект;
- степень сотрудничества: близкое\плотное или слабое.
Охарактеризовав проект свободного ПО по этим параметрам, можно составить его достаточно точный портрет.
Следующей задачей стало оценить проект свободного ПО по CMMI. Однако прямой подход - дословно интерпретировать требования модели -
бесперспективен, так как ряд задач в проектах свободного ПО решается иными способами. Кроме того, часть описываемых практик малополезна для проектов свободного ПО. Поэтому были изучены способы оценки Agile-методик, к которым можно причислить и модель создания открытого ПО.
В качестве эксперимента был оценен проект plone.org. Проект был выбран, как начатый с нуля, достаточно зрелый (развивается с 2001 года), успешный (в тройке наиболее популярных свободных систем управления контентом) и широко распространенный (используется такими организациями, как NASA и FSF). Оценка проекта была выполнена по следующим областям:
- планирование проекта (уровень 0);
- управление проектом (уровень 1);
- управление конфигурацией (уровень 2);
- измерения и анализ (уровень 0);
- определение требований пользователей (уровень 2).
ссылки
1. http://www.catb.org/~esr/writings/cathedral-bazaar/
2. http://opensource.mit.edu/online_papers.php
3. http://www.sei.cmu.edu/cmmi/
4. http://en.wikipedia.org/wiki/Agile_software_development
Василий В. Савин, Вильнюс, Литва, vasilij.savin@gmail.com
Сетевые решения. Статья была опубликована в номере 07 за 2008 год в рубрике бизнес
