Удк 681.5:004.9:65.012 повышение эффективности управления проектами разработки программного обеспечения с открытым исходным кодом
На правах рукописи
ДЫМО АЛЕКСАНДР БОРИСОВИЧ УДК 681.5:004.9:65.012 ПОВЫШЕНИЕ ЭФФЕКТИВНОСТИ УПРАВЛЕНИЯ ПРОЕКТАМИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С ОТКРЫТЫМ ИСХОДНЫМ КОДОМ 05.13.22 – Управление проектами и программами Диссертация на соискание ученой степени кандидата технических наук
Научный руководитель Шевцов Анатолий Павлович, доктор технических наук, профессор Николаев – 2007 СОДЕРЖАНИЕ Введение.............................................................................................................. РАЗДЕЛ 1. АНАЛИЗ МЕТОДОВ И СРЕДСТВ УПРАВЛЕНИЯ ПРОГРАММНЫМИ ПРОЕКТАМИ С ОТКРЫТЫМ КОДОМ.
ПОСТАНОВКА ЗАДАЧ ИССЛЕДОВАНИЯ................................................... 1.1. Современное состояние и проблемы управления программными проектами............................................................................................................ 1.2. Анализ способов усовершенствования процессов управления разработкой программного обеспечения с открытым кодом......................... 1.3. Постановка задач исследования................................................................. РАЗДЕЛ 2. МОДЕЛИРОВАНИЕ ЖИЗНЕННОГО ЦИКЛА И СИСТЕМЫ УПРАВЛЕНИЯ ПРОГРАММНЫХ ПРОЕКТОВ С ОТКРЫТЫМ КОДОМ. 2.1. Разработка модели жизненного цикла проектов с открытым кодом...... 2.2. Разработка модели динамики системы управления проектами с открытым кодом.................................................................................................. 2.3. Основные выводы по разделу 2.................................................................. РАЗДЕЛ 3. ПРИМЕНЕНИЕ ТЕОРИИ ПОДОБИЯ ДЛЯ УПРАВЛЕНИЯ ВРЕМЕНЕМ И СТОИМОСТЬЮ В ПРОГРАММНЫХ ПРОЕКТАХ............ 3.1. Подобие процессов выполнения программных проектов....................... 3.2. Классы и группы подобных процессов выполнения проектов.
Условия подобия................................................................................................. 3.3. Обобщенная методика построения аналоговой модели для оценки времени и стоимости программных проектов................................................. 3.4. Получение абстрактных аналоговых моделей для программных проектов............................................................................................................... 3.5. Модельные критериальные уравнения для основных классов программных проектов...................................................................................... 3.6. Основные выводы по разделу 3.................................................................. РАЗДЕЛ 4. ИССЛЕДОВАНИЕ ПРИМЕНИМОСТИ АНАЛОГОВЫХ МОДЕЛЕЙ ДЛЯ УПРАВЛЕНИЯ ВРЕМЕНЕМ.............................................. 4.1. Описание процесса исследования данных ISBSG.................................... 4.2. Критериальные уравнения оценки времени проектов ISBSG и обоснование их достоверности.......................................................................... 4.3. Критериальные уравнения оценки времени программных проектов с открытым кодом.................................................................................................. 4.4. Основные выводы по разделу 4.................................................................. РАЗДЕЛ 5. МЕТОДИКА УПРАВЛЕНИЯ ПРОГРАММНЫМИ ПРОЕКТАМИ С ОТКРЫТЫМ КОДОМ.......................................................... 5.1. Обоснование выбора открытой модели методом анализа отличительных категорий.................................................................................. 5.2. Анализ риска выбора открытой модели, определение объема планирования и открытости.............................................................................. 5.3. Выбор типа лицензирования продукта...................................................... 5.4. Прототипирование и инициализация среды выполнения проекта......... 5.5. Применение методики для управления программными проектами с открытым кодом.................................................................................................. 5.6. Основные выводы по разделу 5.................................................................. ВЫВОДЫ............................................................................................................ СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ......................................... ПРИЛОЖЕНИЯ.................................................................................................. ВВЕДЕНИЕ Актуальность исследования.
Управление проектами разработки программного обеспечения на настоящий момент стало обширным полем как научной так и практической деятельности. В области производства программного обеспечения задействовано более двух миллионов инженеров по всему миру, 20% которых составляют менеджеры. В Украине по оценкам ассоциации "IT-України" количество инженеров и менеджеров на 2007 год составляет 75 тыс. человек, при чем каждый год учебные заведения выпускают более 13 тыс. человек. При этом приблизительно 38% всех разработчиков участвует в выполнении проектов разработки программного обеспечения с открытым исходным кодом (в дальнейшем, программных проектов с открытым кодом).
Анализ последних исследований в отрасли управления программными проектами показал, что эффективное управление ими является основным способом их успешного завершения в рамках ограничений времени, стоимости и качества. По данным исследовательской группы Standish Group, по состоянию на конец 2004 года [1], из 50000 отслеженных программных проектов из-за неэффективного управления 18% завершились неудачно, 53% потребовали дополнительных затрат времени и финансов и только 29% успешно завершились.
По другим данным [2], более 50% проектов завершаются неудачно. По результатам того же исследования [1], в среднем бюджет проектов превышается на 189%, а затраченное время на 222% превышает оцененное. При этом реализуется в среднем всего 69% заявленной в спецификации функциональности.
Описанная выше ситуация объясняется тем, что, цитируя Р.Л. Гласса [3], “...
разработка программ является концептуально сложным занятием” (курсив мой. – А.Д.). Брукс добавляет [4], что трудность создания программных систем возникает благодаря их “несократимой сущности”, неотъемлемыми свойствами которой являются обусловленная размерами продукта сложность и обусловленная многочисленными связями между участниками проекта согласованность и изменяемость.
Однако, за последнее время появилось много новых моделей управления программными проектами, которые несмотря на невозможность революционного прорыва в дисциплине управления программными проектами, позволяют повысить эффективность управления. Отмечается [5], что в 2004-м году по сравнению с 1994-м, использование новых способов управления привело к повышению процентного отношения успешных проектов на 13%, и снижению количества неудач на 14%. Одним из таких способов стала модель разработки программного обеспечения с открытым кодом, которая появилась в средине 1980 х годов и стала популярной в начале ХХI века.
Программные проекты с открытым кодом известны на практике как успешные проекты, которые завершаются вовремя, с минимальными затратами и в которых производится качественный продукт. Согласно [6] приблизительно 27% всех фирм-разработчиков программного обеспечения выполняют такие проекты. Кроме того, существует более 170 000 некоммерческих открытых проектов в которых участвуют более миллиона человек. Из этих проектов около 7% являются украинскими. В Украине создана Ассоциация пользователей и разработчиков открытого программного обеспечения (UAFOSS), целью которой является распространение знаний об открытом программном обеспечении, поддержка отечественных проектов с открытым кодом и проведение законодательных инициатив, связанных с их использованием в государственных структурах. Так, например, на рассмотрение Верховного Совета Украины внесен проект закона "Про використання Відкритих і Вільних форм інтелектуальної власності, Відкритих форматів даних та Відкритого (Вільного) програмного забезпечення в державних установах і державному секторі економіки". Также UAFOSS совместно с представительством ООН в Украине, Сетью разработчиков открытого программного обеспечения Украины (OSDN) и Комитетом по вопросам науки и образования Верховного Совета Украины проводят круглые столы по проблемам распространения открытого программного обеспечения я других объектов открытой интеллектуальной собственности в Украине, материалы которых используются во время парламентских слушаний по вопросам развития информационного общества в Украине.
В связи с такой популярностью программных проектов с открытым кодом и их значением для индустрии разработки программного обеспечения Украины, возникает необходимость владеть знаниями по их управлению. Однако отмечается [7], что последние исследования были направлены лишь на описание модели и на исследование конкретных случаев ее использования. Вследствие этого вопросы изучения жизненного цикла и системы управления, которые обеспечивают основу знаний для эффективного управления проектами остаются открытыми. Неизученность существующих методов выполнения процессов управления, в особенности управления временем и стоимостью, также мешает эффективному управлению и успешному завершению проектов в рамках заданных ограничений времени, стоимости и качества.
Все это приводит к необходимости решения научной задачи: изучению способов повышения эффективности управления программными проектами с открытым кодом путем разработки моделей жизненного цикла и системы управления, новых моделей оценки стоимости и времени, новой методики управления.
Работа, решающая эти задачи, является актуальной и позволит усовершенствовать выполнение процессов управления и успешно завершать программные проекты с открытым кодом в рамках заданных ограничений времени, стоимости и качества.
Связь работы с научными программами, планами, темами.
Диссертационная работа виполнена в рамках научно-исследовательских работ, которые производились на кафедре Информационных управляющих систем и технологий Национального университета кораблестроения имени адмирала Макарова совместно с ГП НПКГ «Заря-Машпроект» на тему «Анализ перспектив и возможностей использования открытого программного обеспечения на предприятиях машиностроительной отрасли» и совместно с ОАО НИИ «Центр» на тему «Усовершенствование методов оценки стоимости и времени разработки программного обеспечения». Модели системы управления и жизненного цикла разработаны согласно заданиям, указанным в статуте Украинской ассоциации разработчиков и пользователей свободного программного обеспечения UAFOSS. Разработка методики управления проведена во время выполнения программного проекта с открытым кодом "KDE-Eclipse" в рамках гранта программы "Google Summer of Code", где Дымо А.Б. выступал менеджером и ответственным исполнителем проекта.
Целью научного исследования является повышение эффективности управления программных проектов с открытым исходным кодом.
Основные задачи
научного исследования:
1. Разработка модели жизненного цикла проектов с открытым исходным кодом, выделение фаз модели и установление перечня действий, выполняемых в цикле.
2. Разработка математической модели динамики системы управления программными проектами с открытым исходным кодом и исследование устойчивости и самоорганизации системы.
3. Разработка модели оценки времени и стоимости программных проектов с открытым исходным кодом.
4. Проведение эмпирических исследований моделей оценки времени и стоимости для подтверждения их точности и применимости.
5. Разработка методики управления программными проектами с открытым кодом.
Объектом исследования являются процессы управления программными проектами с открытым исходным кодом.
Предметом исследования являются модели жизненного цикла и системы управления программными проектами с открытым кодом.
Методы исследований. Проведенные исследования базируются на методах теории систем, теории подобия, математической статистики, математического моделирования, использования компьютерных систем и современных программных комплексов.
Научная новизна полученных результатов. Основным научным результатом диссертационной работы является множество знаний по управлению программными проектами с открытым кодом, которое позволяет повысить эффективность управления благодаря учету специфики этих проектов.
Научная новизна результатов исследования, которые выносятся на защиту:
Впервые:
разработана модель жизненного цикла программных проектов с открытым кодом на основе анализа существующих проектов, которая учитывает специфический для проектов с открытым кодом процесс обработки и управления внешними изменениями и дополнительные действия по выбору схемы лицензирования и распределенной разработки;
и которая может быть использована для обоснования принятия решений по управлению проектом и как эффективный способ контроля реализации проекта;
разработана математическая модель анализа динамики системы управления программными проектами с открытым кодом на основании обобщенной структурной схемы модели динамики программных проектов, которая учитывает дополнительные переменные состояния и обратные связи между параметрами системы и среды и позволяет исследовать устойчивость и самоорганизацию в проектах с открытым кодом;
получены аналоговые модели оценки времени выполнения программных проектов на основе принципа подобия программных проектов и использования метода анализа размерностей теории подобия, которые учитывают существенные закономерности между определяющими время параметрами и точность которых превышает точность существующих моделей.
Усовершенствованы:
способы и критерии обоснования выбора модели разработки программного обеспечения с открытым кодом на основе адаптированных методов анализа различительных категорий и рисков, которые обеспечивают возможность принять решение о выполнимости проекта уже в начале его жизненного цикла.
Получило дальнейшее развитие:
исследование явления самоорганизации с использованием теории сверхустойчивых систем, на основе которого определяются механизмы обеспечения и управления самоорганизацией;
подход к исследованию проектов с открытым кодом как к аналогам быстрых проектов, на основе чего становится возможным применение уже известных методов и способов управления быстрыми проектами для случая проектов с открытым кодом.
Обоснованность и достоверность полученных результатов, выводов и рекомендаций обеспечена соответствием разработанной модели жизненного цикла стандартам ISO 12207 и ДСТУ 3918-1999;
удовлетворительным согласованием результатов оценки стоимости и времени разработанными моделями с реальными данными проектов из базы данных ISBSG;
успешным выполнением проектов с открытым кодом согласно с предлагаемой методикой управления.
Практическая ценность результатов работы и их практическое использование определяется применением разработанных моделей и методик как основы знаний в управлении программными проектами с открытым кодом;
выполнением оценок времени и стоимости разработки программного обеспечения с большей на 55% точностью чем у модели COCOMO. Выполнены проекты с открытым кодом MediaCloth, KDevelop, ActiveReCpp, KDE Eclipse в рамках заданных ограничений времени, стоимости и качества с использованием предложенной методики управления. При этом практически подтверждается точность оценок времени и ценность рекомендаций по обоснованию открытости кода и выбора типа лицензирования. Результаты диссертационной работы использовались при выполнении свободного проекта с открытым кодом KDE, были внедрены на предприятиях Pluron и UkrInvent, в Национальном университете кораблестроения имени адмирала Макарова.
Апробация работы.
Основные положения и результаты диссертационной работы докладывались на:
конференциях разработчиков KDE «Kastle» (Novi Hrady, Czech Rep., 2003), «Akademy 2004» (Ludwigsburg, Germany, 2004), «Akademy 2005» (Malaga, Spain, 2005), "Akademy 2006" (Dublin, Ireland, 2006), "Akademy 2007" (Glasgow, Unighted Kingdom, 2007).
конференции “Сучасні інформаційні технології та інноваційні методики навчання в підготовці фахівців: методологія, теорія, досвід, проблеми” Винницкого государственного педагогического университета (Винница, 2004);
конференции “Информационные технологии в XXI веке” (Днепропетровск, 2004);
конференции “Інноваційний розвиток на основі технологічної зрілості в управлінні проектами” КНУБА (Киев, 2004);
конференции “Автоматизация: проблемы, идеи, решения” (Севастополь, 2004);
конференции “Світ інформації та телекомунікацій-2005” ГУИКТ (Киев, 2005);
конференции FOSDEM – Free and Open Source Developers Meeting (Brussels, Belgium, 2005);
конференции Linux Desktop Summit (Ottawa, Canada, 2005);
конференциях LinuxSymposium (Ottawa, Canada, 2005, 2007);
конференции Open Source Security (Warsaw, Poland, 2005);
II Open Source World Conference (Malaga, Spain, 2006);
II Международной научно-практической конференции "Управление проектами: состояние и перспективы (Николаев, 2006);
IX Научно-практической международной конференции «Информационные технологии в образовании и управлении» (Новая Каховка, 2007) Личный вклад автора. Основные научные разработки и выводы диссертационной работы, получены автором самостоятельно. Вклад автора в коллективно опубликованные работы конкретизирован в списке публикаций.
Публикации.
1. Дымо А.Б., Морозова А.С. Открытая модель жизненного цикла программных проектов. // Збірник наукових праць НУК. - Миколаїв: НУК, 2005. - №5 (404). - С.134-141.
Личный вклад автора: разработана модель жизненного цикла программных проектов з открытым кодом и определен перечень фаз, которые составляют жизненный цикл.
2. Дымо А.Б. Применение теории подобия для оценки стоимости разработки программных продуктов. // Збірник наукових праць НУК. - Миколаїв: НУК, 2006. - №3 (408). - С.162-167.
3. Дымо А.Б. Модели оценок времени выполнения программных проектов на основе базы данных метрик проектов ISBSG // Збірник наукових праць НУК. - Миколаїв: НУК, 2006. - № 5 (410). - С.53-56.
4. Дымо А.Б., Олейник А.И. Определение объема открытости исходного кода в программном проекте методом анализа рисков // Вестник ХНТУ. Херсон: ХНТУ, 2007. - №4(27). - С. 248 - 251.
Личный вклад автора: идентифицированы риски открытости кода программного проекта и адаптирован алгоритм выполнения анализа рисков для проектов з открытым кодом.
5. Дымо А.Б. Исследование динамики системы управления программными проектами с открытым кодом // Збірник наукових праць НУК. - Миколаїв:
НУК, 2007. - № 3 (414). - С.174-179.
6. Дымо А.Б., Кошкин К.В. Организация работы студентов в рамках проекта автоматизации деятельности университетов при выполнении дипломного проектирования // Сучасні інформаційні технології та інноваційні методики навчання в підготовці фахівців: методологія, теорія, досвід, проблеми. Київ-Вінниця: ДОВ Вінниця, 2004. - №6. - С. 343 - 349.
Личный вклад автора: обоснована применимость программного обеспечения с открытым кодом для разработки систем автоматизации деятельности университетов и предложен перечень программных средств с открытым кодом, которые можно применять при разработке.
7. Дымо А.Б. CASE средства создания програмного обеспечения автоматизации деятельности университетов // Международная научно техническая конференция “Автоматизация: проблемы, идеи, решения”:
Материалы конференции. - Севастополь: СевНТУ, 2004. - С. 58 - 59.
8. Дымо А.Б. Инструменты поддержки жизненного цикла разработки програмного обеспечения автоматизации деятельности университетов // “Информационные технологии в XXI веке”: Материалы конференции. Днепропетровск: ИПК ИнКомЦентра УГХТУ, 2004. - C. 67-68.
9. Дымо А.Б. Интенсификация разработки програмного проекта: открытая модель // “Світ інформації та телекомунікацій-2005”: Матеріали конференції. - Київ: ДУІКТ, 2005. - с. 132.
10.Дымо А.Б. Аналоговое моделирование: инновация в области оценки показателей програмных проектов // “Світ інформації та телекомунікацій 2005”: Матеріали конференції. - Київ: ДУІКТ, 2005. - с. 133.
11.Dymo А. KDevelop – the Comprehensive Tool for Development Tasks // Linux Symposium 2005: Programme. - Ottawa, Canada, 2005. - p. 56.
12.Dymo А. Rapid Linux Desktop Development with KDE and KDevelop // Desktop Developers' Conference: Programme. - Ottawa, Canada, 2005. - p. 24.
13.Dymo А. Automated search for security problems inside the C++ code // Open Source Security conference: Conference Proceedings. - Warsaw, Poland, 2005. pp. 21-36.
14.Dymo A. Open Source Software Engineering. // II Open Source World Conference: Proceedings Book. - Malaga, Spain, 2006. - pp. 59-63.
15.Dymo A. Accomplishments And Challenges of The KDevelop Team. // "aKademy 2006" KDE Contributors Conference: Proceedings of the Conference.
- Dublin, Ireland, 2007. - p. 9.
16.Dymo А. Ruby on Rails Application Development with KDevelop and RadRails // Linux Symposium: Event Programme. - Ottawa, Canada, 2007. - p. 16.
Структура и объем работы.
Диссертация состоит из введения, 5 разделов, выводов и приложений.
Включает 158 страниц основного текста, 29 иллюстраций, 45 таблиц. Список литературы включает 121 наименование на 9 страницах. 5 приложений размещено на 59 страницах.
Автор выражает благодарность профессору Кошкину К.В., оказавшему поддержку при выполнении предоставляемого диссертационного исследования.
РАЗДЕЛ 1.
АНАЛИЗ МЕТОДОВ И СРЕДСТВ УПРАВЛЕНИЯ ПРОГРАММНЫМИ ПРОЕКТАМИ С ОТКРЫТЫМ КОДОМ.
ПОСТАНОВКА ЗАДАЧ ИССЛЕДОВАНИЯ 1.1. Современное состояние и проблемы управления программными проектами Управление программными проектами с момента своего становления как инженерной дисциплины на конференции NATO Software Engineering Conference в 1968 году всегда считалось концептуально сложным занятием [3]. Ф. Брукс, один из пионеров инженерии программного обеспечения указывал на следующие существенные трудности в управлении программными проектами [4]:
сложность управления, обусловленная размерами создаваемого продукта;
сложность задачи отображения (моделирования) процессов и явлений реального мира в программном продукте;
проблема изменяемости и согласования обусловленная многочисленными связями между участниками проекта.
Ройс отмечает в [8] еще несколько причин возникновения трудностей в управлении программными проектами:
гибкость создаваемого продукта, возможность запрограммировать "практически все что угодно", затрудняющая планирование, мониторинг и управление разработкой;
непредсказуемость процесса управления, малая доля проектов с успешным завершением без превышения первоначальных бюджетных и временных ограничений;
большая степень влияния качества управления на успех или неудачу;
незрелость процессов разработки, большая доля незаконченного, неиспользованного и переделанного программного обеспечения, производимого в рамках проекта.
Согласно данным исследовательской группы Standish Group, по состоянию на конец 2004 года [1], из 50000 отслеженных программных проектов 18% завершились неудачно, 53% потребовали дополнительных затрат времени и финансов и только 29% успешно завершились. По другим данным [2], более 50% проектов завершаются неудачно. По результатам того же исследования [Standish], в среднем бюджет проектов превышается на 189%, а затраченное время на 222% превышает оцененное. При этом реализуется в среднем всего 69% заявленной в спецификации функциональности а общая сумма потерь из-за неудачного управления проектами составляет 78 млрд. долларов в год. Графически приведенные данные иллюстрируются на рис. 1.1.
18,00% 53,00% 29,00% Рис. 1.1. Трудности управления программными проектами согласно исследованию Standish Group проекты испытывали трудности проекты завершились удачно проекты завершились неудачно На протяжении многих лет предпринимались попытки изменить эту ситуацию и решить некоторые из проблем управления программными проектами.
Ройс [8] приводит следующий перечень направлений в совершенствовании процессов управления:
1. уменьшение размера или сложности того, что предстоит разрабатывать;
2. усовершенствование процесса разработки;
3. использование более квалифицированного персонала или хороших команд;
4. использование лучшей среды (инструментария для автоматизации процесса);
5. достижение уступок и компромиссов для пороговых значений качества.
За последние 25 лет были созданы и получили свое развитие большое количество моделей и методов управления программными проектами, каждый из которых по разному решал пять вышеперечисленных задач. Наиболее часто используемые подходы к решению этих задач в современной практике управления программными проектами следующие.
Уменьшение размера или сложности того, что предстоит разрабатывать.
В рамках классической водопадной а также спиральной модели разработки предполагается два способа решения этой задачи, предложенные Боэмом [9, 10, 11]:
декомпозиция задач, составление детализированных WBS (Work Breakdown Structure, иерархическая структура работ) и распределение этих задач между участниками проекта;
использование COTS (Common Off The Shelf, готовых к использованию) компонентов, покупаемых специально для решения определенных задач из WBS.
Группа исследователей, создавшая быструю (agile) модель разработки [12, 13, 14] акцентирует внимание на сохранении "простоты" при разработке программного обеспечения. Под этим они подразумевают "...искусство максимизации объема невыполняемых работ" при сохранении соответствия разрабатываемого продукта поставленным требованиям. Согласно такому подходу, проектная команда должна прилагать все усилия по сохранению простоты и расширяемости реализуемых моделей и архитектуры.
Усовершенствование процесса разработки.
Основное внимание при решении этой задачи уделяется вопросам количественного предсказания и анализа параметров процесса разработки.
Наиболее важными признаются:
Вопросы оценки размера создаваемого продукта, для чего наиболее часто применяемыми методами являются метод аналогий Вайнберга и Шульмана [15], метод PERT Путнама и Фитцсиммонса [16], метод функциональных точек [17, 18, 19, 20] а также многие другие методы, основанные на оценке тех или иных характеристик процесса и продукта [21].
Вопросы оценки стоимости, трудоемкости и времени выполнения программного проекта, для которых наиболее часто используемым методом является метод COCOMO [9] и его развитие COCOMO2000 [11]. Самой популярной альтернативой COCOMO является метод экспертных оценок Wideband Delphi [22, 23, 24]. Менее распространенными – методы оценки сверху вниз и снизу вверх, метод задача-модуль, описанные Боэмом [9].
Использование более квалифицированного персонала или хороших команд.
Эта задача достаточно долго не привлекала к себе внимания несмотря на ряд исследований в этой области, выполненных ДеМарко [25] и Константином [26].
Однако с увеличением интереса к быстрым способам разработки увеличилось и внимание ко всему в процессе выполнения программных проектов, что связано с человеческими факторами. Прежде всего это качество и продуктивность, работа в команде, динамика поведения коллектива, личность и программирование, руководство проектом и организационные вопросы, разработка интерфейса и взаимодействие между человеком и машиной, познавательная деятельность, психология, процессы мышления. В быстрых моделях разработки решение проблем, связанных с человеческим фактором, предполагается увеличением внутрикомандного взаимодействия, ускорением обмена информацией и самоорганизацией команд [12].
Использование лучшей среды (инструментария для автоматизации процесса).
В настоящее время этот вопрос не стоит столь остро, как это было 10-15 лет назад. Были созданы языки программирования 4-го поколения, быстрые и эффективные компиляторы, библиотеки компонентов, редакторы, интегрированные среды разработки. Вопрос использования лучшей среды сводится сейчас в основном к вопросу о политике компании и размеру средств, вкладываемых в среду разработки [26].
Достижение уступок и компромиссов для пороговых значений качества.
Проекты по разработке программного обеспечения, как и любые другие проекты представляет собой компромисс между соответствием требованиям, стоимостью и временем [27]. Поэтому в управлении программными проектами всегда остро стоит вопрос достижения максимального качества в условиях поставленных ограничений по стоимости и времени. Классическим подходом к решению этой задачи является метод GOALS (Goal Oriented Approach to Life-cycle Software, подход к разработке программного обеспечения ориентированный на цели), предложенный Боэмом [9] и основанный на декомпозиции целей, выделения наиболее важных и первостепенных целей, а также количественной оценки и выделении ресурсов для достижения конкретных подцелей. Для быстрой разработки программного обеспечения используется подход к выполнению программных проектов с точки зрения теории игр. Так Коберн рассматривает проект как кооперативную игру изобретения и коммуникации [12] и основное внимание уделяет достижению баланса в архитектуре разрабатываемого продукта, достижению эффективности в процессах проекта на основании критерия достаточности, называемого им YAGNI (You Aren't Going to Need It, вам это не потребуется).
Как видно из вышеприведенного обзора, для программных проектов выполняемых согласно разным моделям, используются разные методы и способы совершенствования процессов управления решения. Очевидно, что для каждой модели разработки будет применимым только ограниченный набор методов.
Кроме того, может возникнуть ситуация, когда существующие методы окажутся и вовсе неприменимыми.
Модель разработки программного обеспечения с открытым кодом.
Программное обеспечение с открытыми исходными кодами существовало на протяжении всего периода развития программной индустрии. Однако как отдельное явление оно начало формироваться когда Ричард Столлмэн объявил о начале проекта GNU (Gnu Not Unix) в январе 1984 г. – проекта по созданию "свободной" UNIX-подобной операционной системы с открытым исходным кодом. Под понятием "свобода" подразумевалась:
свобода запуска программ для любых целей;
свобода модификации программ;
свобода распространения копий программ (как платного так и бесплатного);
свобода распространения модифицированных версий программы.
Еще одной характеристикой этого проекта стала невозможность закрытия исходного кода, обеспечиваемая лицензией GNU GPL (General Public License, публичная лицензия). При этом не подразумевалось наличие инвестиций в проект, так как все работы по проекту выполнялись на добровольной основе.
Несмотря на первичную установку на декоммерциализацию, модель также нашла свое применение и для коммерческих программных проектов. Началу ее использования положила фирма Netscape в 1998 году открыв исходный код интернет-коммуникатора Netscape Navigator и начав один из наиболее успешных проектов с открытым кодом – проект Mozilla (по состоянию на 2007 год браузер Firefox, произведенный в рамках проекта Mozilla согласно различным исследованиям занимает от 14% [28] до 31% [29] рынка браузеров). Вслед за этим была основана организация OSI (Open Source Initiative), задачами которой стали продвижения идей открытого программного обеспечения. OSI в 1997 г.
опубликовала определение открытого программного обеспечения [30, 31], которое перечисляет следующие основные критерии открытости:
1. Свободное повторное распространение продукта.
Лицензия не должна ограничивать право какого-либо субъекта на продажу или бесплатное распространение программного обеспечения как компонента совокупного набора программ, полученных из разных источников. Лицензия не должна требовать отчислений или других выплат за подобное распространение.
Обязательность требования свободного распространения устраняет соблазн кратковременного дохода за счет продаж в ущерб многим долговременным выгодам. При отсутствии этого требования стала бы невозможной эффективная кооперация участников проекта (как индивидуумов, так и компаний).
2. Исходный код.
Программа с открытым кодом должна включать исходный код, и должно допускаться ее распространение как в виде исходного кода, так и в откомпилированном виде. В тех случаях, когда какой-либо вид продукта распространяется без исходного кода, должны существовать широко оглашенные способы получения исходного кода, стоимость которых не превышает обоснованных расходов на воспроизведение;
предпочтительным способом является бесплатное получение из Internet. Исходный код должен быть предпочтительной формой, в которой программисты могли бы модифицировать программу. Преднамеренное запутывание исходного кода не допускается. Распространение промежуточных форм представления программ, такие как результаты вывода препроцессора или транслятора, не допускаются.
Требуется доступ к оригинальному исходному коду, потому что невозможно совершенствовать программы без их модификации. Поскольку цель открытого подхода состоит в облегчении процесса совершенствования программ, требуется, чтобы модификация кода производилась простым образом.
3. Производные продукты.
Лицензия должна допускать создание модифицированных и производных продуктов и должна разрешать их распространение на таких же условиях, что и оригинального программного продукта.
Возможность только чтения исходного кода не является достаточной для проведения независимой экспертизы и быстрого эволюционного отбора.
Для обеспечения быстрой эволюции требуется возможность проведения экспериментов с исходным кодом и распространения его модифицированных вариантов.
4. Сохранность авторского исходного кода.
Лицензия может ограничивать распространение исходного кода в модифицированной форме, только если лицензия допускает распространение вместе с исходным кодом «файлов-патчей» для модификации программы во время создания исполняемой системы.
Лицензия должна явным образом разрешать распространение программного обеспечения, созданного на основе модифицированного исходного кода.
Лицензия может требовать, чтобы названия или номера версий производных продуктов отличались от тех, которые имелись у исходного программного обеспечения.
Пользователи имеют право знать, кто отвечает за используемое ими программное обеспечение. Разработчики и люди, поддерживающие код, имеют право знать, за поддержку чего они отвечают, и защищать свою репутацию и авторское право. Соответственно, лицензия программного обеспечения с открытым кодом должна гарантировать простую доступность исходного кода, но может требовать его распространения в виде изначального исходного кода плюс патчи. При этом можно производить «неофициальные» изменения, но они легко отличимы от базового исходного кода.
5. Отсутствие пристрастий по отношению к отдельным лицам или группам лиц.
Для получения максимальной пользы от процесса разработки программного обеспечения с открытым кодом у как можно большего числа людей и групп должны иметься одинаковые права на свой вклад в проект. Поэтому запрещается наличие в любой лицензии на программное обеспечение с открытым кодом условий, не допускающих кого бы то ни было к участию в этом процессе. В некоторых странах, включая США, имеются экспортные ограничения на некоторые типы программного обеспечения. В лицензиях, соответствующих данному определению концепции, могут содержаться предупреждения о применимых ограничениях и напоминания об обязанности соблюдения закона;
однако в них самих не должны содержаться подобные ограничения.
6. Отсутствие пристрастий к областям применения и деятельности.
Лицензия не должна накладывать ограничения на применение программы какой-либо области применения. Например, лицензия не может ограничивать использование в области бизнеса или в области генетических исследований.
Основной смысл этого пункта состоит в запрете лицензионных ловушек, которые препятствуют коммерческому использованию программного обеспечения с открытым кодом.
7. Распространение лицензии.
Права, приписанные данной программе, должны распространяться на всех ее получателей без потребности оформления ими какой-либо дополнительной лицензии.
Смысл этого пункта состоит в запрете закрытия программного обеспечения косвенными способами, такими как требование соглашения о неразглашении.
8. Лицензия не должна специализироваться для каких-либо продуктов.
Права, приписываемые данной программе, не должны зависеть от того, является ли эта программа частью какого-либо специального набора программ. Если программа извлекается из этого набора и используется или распространяется в соответствии с условиями ее лицензии, то все субъекты, которым распространяется данная программа, должны иметь такие же права, как и те, которые предоставляются вместе с исходным набором программ.
9. Лицензия не должна ограничивать другое программное обеспечение.
В лицензии не должны присутствовать ограничения на другое программное обеспечение, распространяемое вместе с лицензируемым программным обеспечением. Например, в лицензии не должно требоваться, чтобы все остальные программы, распространяемые на том же носителе, что и данная программа, представляли собой программное обеспечение с открытым кодом.
Дистрибьюторы программного обеспечения с открытым кодом имеют право собственного выбора по отношению к своему собственному программному обеспечению.
10.Лицензия должна быть нейтральной по отношению к технологии.
Ни одно из положений лицензии не должно основываться на какой-либо индивидуальной технологии или стиле интерфейса.
Этот пункт в особенности затрагивает лицензии, в которых требуется явные действия для установления контакта между лицензиатом и лицензиатом.
Методы, в которых принятие лицензии подтверждается нажатием «согласительной» кнопки (click-wrap), могут конфликтовать с такими важными методами распространения программного обеспечения, как получение по FTP, антологии CD-ROM и зеркалирование Web-сайтов;
такие методы могут также затруднять повторное использование кода. Лицензии, соответствующие данному определению, должны допускать возможность того, что (a) распределение программного обеспечения может производиться через каналы, отличные от Web, не поддерживающие методы click-wrap, и (b) защищенный лицензией код (или его повторно используемая часть) может выполняться в среде без графического пользовательского интерфейса, в которой невозможна поддержка диалоговых окон.
Такая модель разработки стала неожиданно популярной. С 1984 года возникло множество таких проектов, поставивших перед собой самые различные цели.
Из наиболее успешных некоммерческих проектов следует отметить:
1. Linux – проект разработки ядра операционной системы. Разработка начата в 1991 году. Согласно отчетам IDC [32] 27% серверов по всему миру к ноябрю 2006 г. работали под управлением Linux. Доля Linux на рабочих столах пользователей составила 2% в Северной Америке и 5% в Европе.
46% всех государственных учреждений Европы использует Linux на своих компьютерах.
2. KDE – проект разработки графической среды пользователя. Разработка начата в 1996 году. В настоящее время занимает 64.9% рынка графических сред для операционных систем UNIX.
3. Apache – проект разработки веб-сервера. Разработка начата в 1995 г.
Согласно отчетам Netcraft [33] по состоянию на май 2005 г. 70% из более чем 63 миллионов веб-серверов в Internet обслуживались Apache.
Наиболее успешными коммерческими проектами являются:
1. Eclipse – проект платформы для создания интегрированных сред разработчика и сред разработки на языках Java, C++ и др. Разработка началась в 2001 г. На сегодняшний день в рамках проекта ведется разработка более 50 подпроектов, разрабатываемых более 115 компаний.
Этот проект является беспрецедентным примером кооперации производителей коммерческого программного обеспечения в рамках одного проекта.
2. OpenOffice – проект разработки пакета офисных приложений – текстового, табличного и графического редакторов. Разработка начата в 2000г. на основании кода StarOffice, открытого компанией Sun Microsystems.
Вышеперечисленные проекты являются только малой долей среди успешных проектов с открытым кодом. Важно отметить также и успех коммерческих проектов несмотря на их сравнительно небольшое количество. Так по состоянию на декабрь 2006 года доля коммерческих проектов составила 15% всего количества открытых проектов [34]. Еще 20% разрабатываются университетами и другими образовательными учреждениями. Остальная часть является некоммерческими проектами.
Примерная оценка количества проектов с открытым кодом и количества разработчиков в этих проектах по состоянию на январь 2007 г. [35] приведена в диаграмме на рис. 1.2. Были использованы данные крупнейшего репозитария открытых проектов Sourceforge и других репозитариев – Google Code, Berlios, RubyForge, Savannah.
692356 650000 600000 450000 300000 250000 100000 50000 10000 Другие репозитарии Sourceforge Другие репозитарии Sourceforge a) б) Рис. 1.2. Данных репозитариев проектов с открытым кодом:
а) о количестве разработчиков б) о количестве проектов Таким образом, согласно данным репозитариев общее количество проектов с открытым кодом превышает 170 000, а общее количество людей, участвующих в них – 700 000. В то же время согласно данным корпорации Evans [36], количество участников проектов с открытым кодом по всему миру превышает 1 100 человек.
Рис. 1.3. Количество разработчиков проектов с открытым кодом на один миллион населения страны Согласно данным портала Berlios [37] количество разработчиков из Украины составляет 0.6% от всего количества участников проектов с открытым кодом.
Исследования, проводившиеся университетом UNI-MERIT (Нидерланды) по контракту с Еврокомиссией в 2006 г. утверждают [34], что количество участников из Украины составляет до 3х человек на 1 миллион населения страны (рис. 1.3).
Эти данные позволяют оценить количество участников из Украины в диапазоне от 150 до 7 000 человек. Такая сравнительно небольшая цифра тем не менее является неплохим показателем если соотнести ее со средним уровнем дохода (рис. 1.4) или с количеством подключенных пользователей Internet (рис.
1.5). Из отчета UNI-MERIT известно, что наибольшее распространение проекты с открытым кодом получили в странах Евросоюза (45% от общего количества участников) и США (27%), т.е. в странах с высоким уровнем дохода и доступом населения в Internet.
Рис. 1.4. Количество разработчиков проектов с открытым кодом на один миллион подключенного к Internet населения Данные рис. 1.4 и 1.5 позволяют оценить количество украинских разработчиков в 1500 – 3600 чел. на основании ВВП на душу населения (из расчета 6000$ согласно данным Всемирного Банка [38]) или 1800 – 3200 чел. (из оценки 3-6 млн. пользователей Internet в Украине [39]).
Рис. 1.5. Количество разработчиков проектов с открытым кодом на 1000$ валового внутреннего продукта на душу населения.
37,93% 62,07% Рис. 1.6. Занятость разработчиков в программных проектах согласно исследованию Evans Data Corporation:
в проектах с открытым кодом;
в проектах с закрытым кодом.
Учитывая данные исследования Evans Data Corporation [36], которые показывают, что более 35% разработчиков по всему миру задействованы в проектах с открытым кодом (рис. 1.6) и эта цифра растет на 2-5% в год, а также учитывая огромное количество и успешность как коммерческих так и некоммерческих выполняемых проектов, следует признать важность открытой модели разработки программного обеспечения и необходимость исследований как самой модели так и способов повышения эффективности управления программными проектами, выполняемыми в этой модели. Однако следует обратить внимание на сравнительно небольшую долю коммерческих проектов (15%), что объясняется многими аналитиками [40, 41] отсутствием теоретического обоснования основных принципов выполнения таких проектов.
Как отмечается в [41], "самая большая проблема индустрии открытых исходников, препятствующая ее дальнейшему развитию, сегодня состоит в том, что даже сторонники открытого кода в большинстве своем еще не понимают, что открытая модель является действительно самостоятельной. Никто из сторонников открытого кода не понимает, какой инструмент оказался у них в руках. А отсюда уже вытекает физическая невозможность использовать его эффективно". Это подтверждается и многочисленными опасениями, высказываемыми менеджерами и руководством компаний. Так, например, в Sun Microsystems несмотря на положительный опыт открытия исходного кода OpenOffice и 6-ти летний опыт его дальнейшей разработки в открытой модели более 2х лет принимали решение об открытии исходного кода Java и перевода проекта Java на открытую модель [42, 43, 44, 45].
Исходя из вышесказанного, очевидно, что задача по изучению модели разработки открытого программного обеспечения является важной и своевременной. Решением такой задачи будет являться формальное описание модели открытых исходников, составляющих ее фаз и действий, а также формулирование основных принципов управления открытых проектов. Иными словами необходима модель процессов разработки (модель жизненного цикла) и модель системы управления. Все это предоставит необходимую основу знания для организаций, планирующих или разрабатывающих программные проекты с открытым кодом.
1.2 Анализ способов усовершенствования процессов управления разработкой программного обеспечения с открытым кодом Как было отмечено в разделе 1.1 перед менеджерами программных проектов стоит пять существенных проблем и каждая известная модель разработки по своему подходит к их разрешению. Поэтому ниже для проектов с открытым кодом приведен анализ решения их специфических задач с целью повышения эффективности управления этими проектами.
Уменьшение размера или сложности того, что предстоит разрабатывать.
За счет открытости кода и гибких правил его распространения количество повторно используемого кода доходит до 40% от размера создаваемого продукта.
Это подтверждается, например, данными исследования MERIT [34], приведенными в таблице 1.1.
Таблица 1. Объем повторно используемого кода на основании анализа программ из дистрибутива Debian 3.1 (2006г.) Параметры кода Значения для Debian 3. A – количество строк исходного кода 247 809 Б – количество строк повторно использованного кода 157 434 Степень повторного использования (А / Б) 1. Доля повторного использования ((А – Б) / А) 36% Такая высокая степень повторного использования позволяет говорить о модели разработки программного обеспечения с открытым кодом как о способе избежать затрат на исследование несвязанных с производимым продуктом технологий для разработчиков и компаний, выполняющих проекты. Повторное использование готовых компонентов позволяет привлечь ресурсы к осуществлению инноваций только в необходимых областях. Так, например, Университет Нью-Йорка (NYU) получил грант от Министерства Обороны США в размере 3 000 000$ и разработал нового компилятора языка Ada (GNAT),. В тоже время аналогичные проекты затратили более 20 000 000$. Целенаправленность инвестиций обусловлена тем, что компилятор создавался на базе уже имеющихся компиляторов GNU C и GNU C++. В дальнейшем компилятор разрабатывался по открытой модели с периодическим дофинансированием. По оценкам на 2006 г. трудоемкость его разработки составила 4764 человеко-месяцев а оцененная стоимость – 45 000 000$.
Еще одной положительной характеристикой модели является четкое определение правил совместной работы над проектом, что позволяет увеличивать эффективность вложений в исследование и разработку коммерческим компаниям а также обеспечить надежные пути взаимодействия коммерческих и некоммерческих участников проекта. Примерами такой совместной работы являются проекты Eclipse и Maemo. Maemo – операционная система нового поколения для мобильных телефонов и интернет-коммуникаторов Nokia.
Произведенный в рамках этого проекта продукт является результатом совместных усилий 8 коммерческих компаний и 6 некоммерческих организаций, что иллюстрирует таблица 1.2.
Таблица 1. Распределение объема кода созданного в проекте Maemo по участникам проекта Участник проекта Объем кода, строк Процент кода Коммерческие компании RedHat Corporation 415 000 8.6% Silicon Graphics Corporation 275 000 5.7% IBM Corporation 220 000 4.6% Nokia Corporation 200 000 4.1% Intel Corporation 160 000 3.3% Sun Microsystems 130 000 2.7% Digital Equipment Corporation 130 000 2.7% Hewlet-Packard Corporation 115 000 2.4% Некоммерческие организации Free Software Foundation 2 785 000 58.3% The Open Group 200 000 4.1% The OpenSSL Project 75 000 1.6% The Purdue Research Foundation 55 000 1.1% XFree 22 000 0.5% The Python Foundation 15 000 0.3% Итого: 4 797 000 Из вышесказанного следует, что задача уменьшения размера и сложности разрабатываемого продукта в рамках модели разработки программного обеспечения с открытым кодом решена успешно и эффективность модели доказана.
Совершенствование процесса разработки.
Совершенствование процесса разработки невозможно без количественного анализа процесса. Для проектов с открытым кодом оценка размера создаваемого продукта не представляет значительных трудностей и может быть выполнена с помощью известных методов [11]. Одновременно оценки стоимости, трудоемкости и времени разработки вызывают трудности. Источником трудностей в оценке являются:
приток и отток участников проекта, в том числе индивидуумов и некоммерческих организаций, что затрудняет оценку стоимости ввиду неопределенности размера проектной команды;
неадекватность трудоемкости реальных проектов ее оценкам по существующим моделям.
Одним из подтверждений отсутствия надежных оценок стоимости проектов является проект разработки компилятора Ada, потребовавший в 10 раз меньше инвестиций чем другие подобные проекты.
Другим подтверждением являться результат сравнения реальных затрат для двух проектов с открытым кодом Quanta и KDevelop с их оценкой согласно модели COCOMO [46]. Результаты сравнения приведены на рис. 1.7.
Приведенные выше данные о существенной погрешности (до 80%) имеющихся моделей оценки времени, трудоемкости и стоимости подтверждают необходимость исследований в области оценок этих процессов разработки.
Оценка трудоемкости (количества труда, использованного при выполнении программного проекта), длительности и стоимости выполняется на ранних стадиях планирования проекта, непосредственно после оценки размера создаваемого в проекте продукта (программы).
800 750 32, 27, 22, 500 Действ.
450 Оценка Действит.
COCOMO 17, Оценка 350 COCOMO 300 12, 250 7, 2, Quanta KDevelop Quanta KDevelop б) а) 22, 17, Действ.
Оценка COCOMO 50 Quanta 12,5 KDevelop 7, 2,5 Трудозатр. Время Размер команды Quanta KDevelop г) в) Рис. 1.7. Сравнительный анализ оценкок модели COCOMO и реальных проектных данных для проектов с открытым кодом:
а) Оценка трудоемкости (чел*мес);
б) Оценка времени (мес);
в) Оценка размера команды, чел;
г) Средняя ошибка оценок COCOMO, %.
Место выполнения оценок можно увидеть на рис. 1.8. Такая оценка выполняется на фазах исследования концепции, изучения системы, а также на фазе формирования требований. Результаты оценки трудоемкости кладутся в основу процесса дальнейшего менеджмента ресурсов, а именно, составления графика и планирования остальных затрат программного проекта. Очевидно, что точность планирования будет напрямую зависеть от точности выполнения оценок трудоемкости, длительности и стоимости.
Рис. 1.8. Место оценок стоимости и длительности при выполнении программного проекта На длительность и стоимость выполнения программного проекта будет влиять огромное количество факторов. Так, например, в [77] перечисляются следующие типичные факторы (полный список привести практически невозможно):
сложность выполняемых задач, включенных в WBS (Work Breakdown Structure, структура работ проекта), а именно задач по разработке ПО (проект, код, тестирование), дополнительных задач по разработке (требования, система), задач поддержки (CM, QA, менеджмент), задач, требующих дополнительных трудозатрат (документы);
объем сопутствующих и дополнительных затрат (поездки, оборудование и т.д.);
размер программного продукта;
хронологические данные по затратам и производительности;
график высокого уровня (обобщенный предварительный график разработки);
процесс и методы разработки;
язык программирования;
платформа для целевой системы;
используемые инструменты;
уровень профессионального опыта.
Иными словами, как длительность, так и стоимость создания программного продукта будут результатов воздействия огромного количества эффектов, причем многие из них зачастую сложно измерить количественно.
Подытоживая, можно очертить проблематику выполнения оценок следующими двумя положениями:
1. необходимость учета воздействия огромного количества факторов;
2. трудность определения количественной меры тех или иных эффектов.
Естественно предположить, что задача установления связи между величинами, выбранными в качестве количественной меры воздействующих эффектов будет не только сложна, но и трудновыполнима на научном уровне. И действительно, в рекомендациях по применению методов оценки [62] говорится, что оценка размера и затрат не относится к области точных наук.
В настоящее время для оценки трудозатрат применяются эмпирические, регрессионные (COCOMO [9, 11]) и математические модели (SLIM [78]), а также экспертные оценки (Delphi [79], Wideband Delphi [80]).
Эмпирические зависимости как в дисциплине управления проектами, так и в других областях науки, представляющие собой отношения по сути случайного характера, не являются основой изучения процесса. Так, они могут достоверно охарактеризовать уже завершенный процесс разработки какой-либо программного продукта, но не могут предвидеть все эффекты, влияющие на новый процесс. Степень тяжести недостатков эмпирических методов косвенно подтверждается тем фактом, что в современной практике управления программными проектами они не находят применения.
Регрессионные модели, предоставляющие экспоненциальные уравнения для создания количественного прогноза, в отличие от эмпирических предоставляют механизмы калибровки и подгонки моделей под процессы в конкретной организации, выполняющей разработку. Здесь стоит отметить, что процесс калибровки носит, во первых, характер преодоления частных трудностей применения моделей, нежели концептуальных, потому как поиск взаимосвязи между факторами производится путем всего-лишь статистической интерпретации хронологических данных, а не путем выявления существенных закономерностей.
Кроме того, не делается различий между типами (классами) разрабатываемых продуктов.
Имеющиеся математические модели отличают общие трудности при преодолении уже упомянутой проблемы определения количественной меры эффектов, влияющих на оцениваемые параметры. В результате чего, математические модели становятся усложненными, одновременно не отражая адекватно изучаемые процессы. В [62], например, отмечается, что при использовании модели часто получается так, что общая сумма трудозатрат при выполнении группы малых проектов будет меньшей, чем трудозатраты при выполнении большого проекта, вследствие чего приводится рекомендация проявлять осторожность при применении математических моделей при разбиении больших проектов на меньшие структурные единицы. Йордон в [102] также указывает на преимущества экспертных оценок перед математическими.
Общей проблемой для всех трех вышеперечисленных типов моделей является точность моделирования на ранних (и наиболее важных с точки зрения планирования) фазах выполнения проектов, ошибка которых может доходить до 400%, что иллюстрирует график из [9] приведенный на рис. 1.9. Как видно, в каждой новой фазе жизненного цикла степень достоверности оценки повышается, но наиболее важные предварительные оценки будут тем не менее иметь невысокую степень достоверности.
4х 1х Спецификация Спецификация Спецификация детализиров.
Концепция Продукт требований архитектуры архитектуры 0.25х Возможность Требования Архитектура Детализиров. Разработка и архитектура тестирование Рис. 1.9. Точность оценок модели COCOMO в зависимости от фазы, в которой производится оценка Также модели построены и калиброваны в допущении, что основным фактором, влияющим на стоимость, является размер разрабатываемого программного продукта [9]. Влияние других параметров учитывается только поправочными коэффициентами, определенными с помощью методов статистического анализа.
Как видно из вышеизложенного, используемая методология оценивания показателей процессов выполнения программных проектов обладает следующими существенными недостатками:
не учитывается влияние класса (типа) разрабатываемого программного продукта на значение оцениваемых показателей;
точность моделирования на ранних этапах выполнения проектов является невысокой.
В то же время, математические модели обладают существенными достоинствами [9], такими как повторяемость, легкость анализа, простота применения и др., которые не присущи методам экспертных оценок, поэтому вопрос преодоления вышеозначенных методологических трудностей является весьма важным. Иными словами, должен быть предложен способ оценки показателей процессов выполнения программных проектов, преодолевающий указанные выше существенные недостатки.
В [81] указывается, что идея аналогии как основы исследования есть весьма плодотворной ввиду возможности охватить в одном количественном представлении закономерности поведения системы. Иными словами, необходимо обратиться к аналоговому моделированию, как к аппарату обобщения "опытных данных". Руководство PMBOK [27] также указывает на преимущества оценок по аналогии, хотя и не предлагает конкретных методов, а в [9] описывается простой метод оценок по аналогии. Однако, наиболее совершенный и проверенный на практике аппарат аналогового моделирования представляет теория подобия, основные положения которой были разработаны еще в начале прошлого века и наиболее полно обобщены А.А. Гухманом [82].
Как указано в [83], теория подобия является научной базой постановки экспериментов и аналитической обработки их результатов, позволяя обобщать полученные данные в пределах классов и групп процессов, систем или явлений.
Таким образом, применение теории подобия для оценки показателей процессов выполнения программных проектов позволяет решить один из существенных недостатков имеющихся методологий оценки: разделение на классы и обобщение опыта выполнения похожих проектов.
Основная идея теории подобия заключается в том, что в пределах некоторого класса явлений или процессов выделяются группы, в которых возможно обобщение данных единичного опыта [82].
Иными словами, обобщение опыта выполнения программного проекта можно выполнить путем создания аналоговой модели процесса выполнения, т.е.
системы, отражающей и воспроизводящей структуру, свойства, взаимосвязи и отношения оригинала [83]. Теория подобия в данном случае выступает как математический механизм аналогового моделирования, который предполагает определение множества безразмерных признаков (критериев подобия), характеризующих свойства системы и определение соотношения между этими признаками (критериями) в форме произведения их степеней на постоянные множители [82].
Такое соотношение будет иметь следующий общий вид:
определяемый критерий= f определяющие критерии.
Эти модели имеют следующие основные преимущества, решающие проблемы оценки времени и стоимости программных проектов:
каждому классу подобных проектов будет соответствовать критериальное уравнение с одинаковыми критериями и коэффициентами пропорциональности;
внутри каждого класса для группы подобных проектов численные значения критериев будут одинаковы, что позволит делать оценку времени новых проектов используя значения критериев старых аналогичных проектов;
критерии группируют определяющие время параметры, упрощая эмпирическое определение функции отношения между ними и одновременно позволяя учесть в моделях оценки большее количество определяющих параметров.
Использование более квалифицированного персонала или хороших команд.
В проектах с открытым кодом согласно многим исследованиям никогда не наблюдался недостаток квалифицированного персонала. Так, например, результаты опроса разработчиков, проведенного Boston Consulting Group в 2002 г.
показывают, что профессиональные программисты со средним стажем 11 лет составляют большинство участников проектов с открытым кодом (см. рис. 1.10).
При этом подавляющее их большинство рассматривает эти проекты как стимулирующие интеллектуальную деятельность и приводящие к повышению профессионализма (рис. 1.11).
ч.
. ер ст нт я ин га ми ми де дж у дм Др де ту не ам.а а С е гр с Ак Си М ро П Рис. 1.10. Профессия разработчиков программного обеспечения с открытым кодом согласно опроса BCG.
Интеллектуально стимулирует Увеличивает опыт Связано с работой Код должен быть открыт Не связано с работой Вследствие использования Работа с командой Профессиональный статус Другое Репутация Опередить закрытое ПО Лицензия требует 0 5 10 15 20 25 30 35 40 Рис. 1.11. Мотивация участников проектов с открытым кодом согласно опроса BCG.
Таким образом, профессионализм команды, выполняющей проект с открытым кодом, является существенным фактором для успешного завершения проекта.
Другим существенным фактором успеха команд является "самоорганизация" или адаптивное поведение [47, 48, 49, 50]. Под самоорганизацией подразумевается как особые способы реакции на изменения в среде выполнения проекта [48], так и самоорганизация внутренней структуры команды, выполняющий проект [49].
В проведенных исследованиях основной внимание уделено изучению последствий самоорганизации, а не причинам ее возникновения или механизмам ее обеспечения. Как основные последствия самоорганизации выделяются:
отсутствие формального менеджмента многих проектов с открытым кодом не вызывающее тем не менее существенных проблем в коммуникации целей;
отсутствие формального способа назначения задач участникам проекта в условиях постоянного увеличения количества выполняемых и выполненных задач;
отсутствие специально выделенных команд для коммуникаций с внешним миром при сохранении как объема так и качества этой коммуникации;
"выживаемость" команды проекта даже при радикальных изменениях условий, позволяющая продолжать выполнение проекта в критической обстановке.
Таким образом, последствия самоорганизации понятны и довольно хорошо изучены, чего нельзя сказать о механизмах. Единственным исследованием механизмов самоорганизации в проектах с открытым кодом является работа Валверде и др. [48], в которой рассматривается самоорганизация в социальных сетях и проводится аналогия между самоорганизацией в пчелином улье и проектной команде.
Валверде предлагает модель социальной сети с положительной обратной связью (рис. 1.12), где в узлах сети располагаются индивидуумы, реакция которых определяется взвешенным произведением входных воздействий, причем вес связи определяется как wi, j = ki k j, где wi,j – вес связи между узлами сети i и j, ki, kj – реакции узлов i и j, – показатель степени, определяемый экспериментально для каждой сети.
а) б) Рис. 1.12. Социальная сеть:
а) пчел в колонии из 13 особей;
б) разработчиков программного обеспечения.
Такая сеть будет самоорганизующейся если 0. В проведенных Валверде эмпирических исследованиях значение показателя степени было 0.39 – 0.5, что доказывало гипотезу про самоорганизацию.
Вышеприведенные исследования позволяют делать выводы о самоорганизации внутри проектной команды, однако не помогают установить причины выживаемости команды при резких изменениях внешних условий.
Модель социальной сети, указывая на участников проекта как на источники возникновения самоорганизации, не делает заключения о самом механизме самоорганизации – о его надежности, о параметрах, влияющих на него, и, что наиболее важно для проектного менеджмента, о способах управления этим механизмом.
В связи с этим модель социальной сети нельзя признать удовлетворительной и задачу изучения самоорганизации решенной. Поэтому необходимо разработать такую модель, которая бы объективно отвечала на вопросы о возникновении самоорганизации и ее управлении. То есть необходима такая модель системы управления проектами, которая бы позволила изучить систему в динамике и выделить набор параметров, управляющих механизмом самоорганизации.
Такая модель может быть построена на основании описания принципа самоорганизации Эшби [57]. Эшби показал, что самоорганизация (адаптация) присуща сверхустойчивым системам. Сверхустойчивой Эшби называет систему из двух систем с непрерывно изменяющимися переменными (среды и реагирующей части), взаимодействующих таким образом, что между ними существует первичная обратная связь и, одновременно, вторичная обратная связь действующая ступенчато и со скоростью более низкого порядка чем первичная.
Эта вторая обратная связь идет от среды к некоторым “существенным” переменным, которые влияют на некоторые ступенчатые функции таким образом, что эти функции меняют свои значения тогда и только тогда, когда существенные переменные выходят из заданных пределов. Ступенчатые механизмы воздействуют на реагирующую часть, определяя с помощью ее параметров реакцию на среду.
Под существенными переменными подразумеваются такие переменные, выход которых из границ может привести к прекращению существования реагирующей части системы. Адаптацией будет такое поведение системы, при котором система будет вырабатывать и сохранять реакцию на изменение существенных параметров.
Для количественного анализа сверхустойчивости Эшби предложил в [57] математическую модель сверхустойчивой системы, состоящей из переменных состояния x и ступенчатых функций w, причем целое представляет собой систему, определяемую состоянием:
x = Cx + Dw, w = Fx + Gw где x – вектор переменных состояния, w – вектор ступенчатых функций (параметров системы), C, D, F, G – матрицы коэффициентов взаимного влияния переменных состояния и параметров системы.
Такое представление позволяет исследовать систему управления программным проектом не только как изолированную систему или систему с постоянным входом, но и как систему, на которую влияют внешние воздействия или на вход которых подаются изменения.
Эти изменения, представленные в модели ступенчатыми функциями w, Эшби называет параметрами системы. До настоящего времени ни модели динамики процессов управления программными проектами ни сами эти процессы не учитывали влияние параметров на систему. Это подразумевало, что любое изменение параметров или входных сигналов приводило к необходимости проведения повторных моделирования и исследования системы на устойчивость и внесения коррекций в систему. Применительно к программным проектам это подразумевало выполнение программных проектов при допущении, что среда проекта остается неизменной.
Наличие же сверхустойчивости подразумевает что система сама сможет находить новые поля (области устойчивости) при изменении каких-либо параметров. Эшби обосновал, что такие возможности предоставляет ступенчатое случайное изменение других параметров с целью найти новое устойчивое поле.
Из вышесказанного следует, что применение теории Эшби позволит получить математическую модель системы управления и с использованием известных методов теории систем исследовать устойчивость и самоорганизацию.
Использование лучшей среды (инструментария для автоматизации процесса).
Как уже было сказано в разделе 1.1, по состоянию на 2007г. вопрос среды и инструментария не стоит столь остро и, соответственно, не требует особого внимания. Однако, факт, что более 170 000 проектов с открытым кодом (97% от всего количества проектов) используют услуги репозитария Sourceforge (рис. 1.2) для построения инфраструктуры процесса и создания среды выполнения проекта, требует изучения. В настоящее время разработано огромное количество инструментальных средств. Правильный их выбор будет влиять на успех или неудачу проекта. Это в особенности касается проектов с открытым кодом и объясняется их сильной зависимостью от эффективности распространения информации [49] и коммуникаций.
Очевидно, задачей такого изучения будет обобщение опыта успешных проектов и его формализация в виде части методики управления, которая отвечает за построение инфраструктуры выполнения процессов проекта.
Достижение уступок и компромиссов для пороговых значений качества.
Программные проекты с открытым кодом отличаются повышенными соотношениями качества к стоимости по сравнению с аналогичными проектами с закрытым кодом. Требуемый уровень качества достигается в проектах с открытым кодом при меньших вложениях средств. Исследования MERIT, проводимые для Еврокомиссии, показывают что в среднем соотношение качество/стоимость для проектов с открытым кодом на 10% выше [34]. Однако, отклонения значений этого соотношения весьма значительны и составляют от 200% до 1000%. В отчете MERIT отмечается, что на величину этого соотношения влияет не столько качество управления проектом, сколько применимость модели открытых кодов вообще, что полностью соответствует тезису Брукса о том, что не существует одного универсального способа решения всех проблем управления программными проектами. В настоящее время четкого способа определения применимости модели не существует. Имеющиеся публикации противоречивы.
Одни говорят об универсальной применимости модели [51] другие - о ее полном несоответствии [52, 53].
Таким образом, для решения проблемы достижения максимального качества в условиях поставленных ограничений по стоимости и времени применительно к программным проектам с открытым кодом необходима разработка методики управления, которая бы объективно оценивала применимость модели к конкретному проекту.
1.3. Постановка задач исследования Целью настоящей работы является улучшение повышение эффективности управления программными проектами с открытым исходным кодом. Как было показано в разделах 1.1 и 1.2 для этого необходимо решить следующие задачи:
1. Разработать модель жизненного цикла программных проектов с открытым кодом, выделить фазы модели и установить перечень действий, которые выполняются в цикле.
2. Разработать математическую модель системы управления программными проектами с открытым кодом и выполнить исследования устойчивости и самоорганизации в системе.
3. Разработать модель оценки времени и стоимости проектов разработки программного обеспечения с открытым кодом.
4. Провести эмпирическое исследование модели оценки времени и стоимости для подтверждения их точности и применимости.
5. Разработать методику управления программными проектами с открытым исходным кодом.
РАЗДЕЛ 2. МОДЕЛИРОВАНИЕ ЖИЗНЕННОГО ЦИКЛА И СИСТЕМЫ УПРАВЛЕНИЯ ПРОГРАММНЫХ ПРОЕКТОВ С ОТКРЫТЫМ КОДОМ 2.1. Разработка модели жизненного цикла проектов с открытым кодом Описание модели жизненного цикла и ее составляющих необходимо для успешного управления проектами [27]. Формальное описание такой модели состоит из:
схематического описания для определения фаз и их последовательности;
диаграмм распределения работ по фазам проекта;
таблиц идентификации задач и действий, выполняемых в жизненном цикле, служащие для последующего распределения ресурсов проекта.
Детальное формальное описание в таком виде определяет методологию управления проектами, которая обязана выполнять все процессы жизненного цикла согласно стандартам ISO/IEC 12207 [54] и ДСТУ 3918-1999 [55].
Модель жизненного цикла программных проектов с открытым кодом, далее открытая модель, определяется совокупностью общих и специфических признаков. Общие признаки модели определяются как:
множество фаз выполнения проекта;
содержание технических работ по каждой фазе;
распределение инженерных и технических ресурсов по фазам;
последовательность выполнения обозначенных фаз;
переходные процессы между фазами.
Специфические признаки открытой модели следующие:
фазы выполнения проекта организованы в спиралевидной повторяющейся последовательности;
среда выполнения открытого проекта значительно шире, чем у любых других программных проектов;
нормальной практикой выполнения проекта является постоянное привлечение сторонних ресурсов как материальных, так и трудовых;
множество исполнителей проекта не является ни фиксированным ни четко определенным.
2.1.1. Определение открытой модели. Определение фаз открытой модели и их последовательности произведено путем анализа хода выполнения уже завершенных проектов.
Для анализа были выбраны наиболее характерные проекты, представляющие все типы открытых проектов:
чистые: GNOME, KDE, Linux (ядро);
конверсионные: Mozilla, Blender, OpenOffice;
управляемые: Qt, Eclipse, OpenSolaris.
Анализ проводился с помощью:
хронологических данных о проектах из электронной энциклопедии Wikipedia;
информации из списков рассылки и веб-сайтов проектов;
планов выпуска и анонсов.
Результаты анализа приведены в таблице 2.1, где собраны аннотированные хронологические данные об управленческих действиях в проекте KDE. Данные о других проектах показывают во многом аналогичную картину, поэтому приводятся в приложении А.
Аннотацией служила краткая характеристика действия, классифицирующая его как веху (начало либо завершение) определенной фазы жизненного цикла.
Аннотирование выполнялось с целью определения фаз жизненного цикла.
Таблица 2. Хронологические данные об управленческих действиях в открытом проекте KDE Дата Действие Аннотация Письмо [67] основателя проекта Mattias Определение проекта 14.10. Ettrich с сообщением о начале проекта, перечнем выполняемых задач и целей.
Октябрь 1996 Создан список рассылки [email protected] для Прототипирование и разработчиков и пользователей проекта, реализация веб-сайт проекта. Опробована, а затем инфраструктуры запущена система управления версиями макропроцесса кода для хранения кода проекта.
Ноябрь 1996 Начальной группой разработчиков Обзор существующих используя список рассылки выполнен аналогичных и похожих анализ и обзор существующих альтернатив. программных систем Ноябрь 1996 Определены первостепенные цели проекта. Определение структуры целей и задач проекта Завершена разработка первой версии Прототипирование и 12.07. продукта KDE 1.0. разработка Начало 1999 Введение в действие системы управления Пользовательская оценка, запросами на внесение изменений (Bugzilla) усовершенствование как ответ на пожелания пользователей макропроцесса как оценки. внедрение целей Доработка выпущенной версии продукта в Внедрение и улучшение 1998- соответствии с требованиями пользователей, выпуск обновлений.
Продолж. табл. 2. Дата Действие Аннотация Завершено прототипирование следующей Прототипирование новой 15.12. версии продукта. версии Завершена разработка следующей версии Разработка новой версии 23.10. продукта.
Каждая фаза разработки из тех, что аннотированы в таблице 2.1, исходя из данных системы управления версиями и планов выпуска новых версий (приведенных, например, в документах [58, 59, 60]) разделяется на 3 основных этапа. Первый этап – выполнение одновременного прототипирования, кодирования и документирования с целью выпуска нестабильной и не полностью функциональной "" версии продукта. Следующий этап после выпуска "" версии включает в себя одновременное кодирование, документирование и модульное тестирование с целью выпуска более стабильной и полнофункциональной "" версии продукта. И, наконец, в последний этап входит интеграция и квалификационное тестирование продукта с целью выпуска стабильной и полнофункциональной следующей версии продукта (с промежуточными опциональными выпусками версий вида "release candidate", т.е. "почти готовых к выпуску" версий).
По результатам проведенного выше анализа и содержанию проектной информации, представленной в Приложении А, выполнено схематическое представление фаз жизненного цикла открытой модели и определено содержание процессов, выполняемых в каждой из фаз. Такое представление показано на рис. 2.1.
Визуальный анализ модели показывает, что она имеет процессы, присущие каскадной [61] и спиральной [9] модели. Как и в спиральной модели, в нее включены процессы анализа и управления рисками и поддержки менеджмента.
Предусмотрена разработка программного продукта при использовании метода прототипирования или быстрой разработки приложений посредством применения языков программирования и средств разработки четвертого и выше поколения.
Одновременно, каждый цикл модели отображает базовую концепцию, которая заключается в том, что цикл представляет собой набор операций, которому соответствует такое же количество стадий, что и в каскадной модели.