ВЗАИМОДЕЙСТВИЕ ПРАКТИК ИТЕРАЦИОННОЙ РАЗРАБОТКИ В РАМКАХ МОДЕЛИ OMG ESSENCE
|
АННОТАЦИЯ 3
ОГЛАВЛЕНИЕ 4
ВВЕДЕНИЕ 5
1 ТЕОРЕТИЧЕСКИЕ ОСНОВЫ СТАНДАРТА OMG ESSENCE 9
1.1 Основные положения стандарта 9
1.2 Ядро стандарта 10
1.3 Язык стандарта 18
2 АНАЛИЗ ПРОБЛЕМ ПРИ ФОРМАЛИЗАЦИИ ПРОЦЕССА РАЗРАБОТКИ 23
2.1 Составление метода из практик для формализации процесса разработки 23
2.2 Сложности, возникающие при применении стандарта OMG Essence 24
2.3 Выделение практик для анализа влияния Рабочих продуктов 25
2.4 Изучение описания практик 26
2.4.1 Изучение описания практики “Use-Case” на Языке Essence 26
2.4.2 Изучение описания практики “User Story” на Языке Essence 29
2.4.3 Изучение описания практики “Scrum” на Языке Essence 31
2.4.4 Изучение описания практики “Microservices” на Языке Essence 33
2.5 Систематизация результатов изучения практик 35
3 УЛУЧШЕНИЕ МОДЕЛИ СТАНДАРТА ДЛЯ ОПИСАНИЯ
ВЗАИМОДЕЙСТВИЯ ПРАКТИК 37
3.1 Предлагаемая классификация Рабочих продуктов 37
3.2 Представление метода разработки через композицию Рабочих продуктов 41
4 ФОРМАЛИЗАЦИЯ СУЩЕСТВУЮЩЕГО ПРОЦЕССА РАЗРАБОТКИ 44
4.1 Описание рассматриваемого проекта 44
4.2 Выделение используемых на проекте практик 45
4.3 Пример составления описания практики в терминах Essence 45
4.4 Выделение Рабочих продуктов в рамках практик 51
4.5 Составление ориентированного ациклического графа между Рабочими
продуктами 54
4.6 Анализ ключевых показателей эффективности проекта после внедрения
улучшений 60
ЗАКЛЮЧЕНИЕ 64
ЛИТЕРАТУРА 66
СПИСОК ИЛЛЮСТРАЦИЙ И ТАБЛИЦ 69
ОГЛАВЛЕНИЕ 4
ВВЕДЕНИЕ 5
1 ТЕОРЕТИЧЕСКИЕ ОСНОВЫ СТАНДАРТА OMG ESSENCE 9
1.1 Основные положения стандарта 9
1.2 Ядро стандарта 10
1.3 Язык стандарта 18
2 АНАЛИЗ ПРОБЛЕМ ПРИ ФОРМАЛИЗАЦИИ ПРОЦЕССА РАЗРАБОТКИ 23
2.1 Составление метода из практик для формализации процесса разработки 23
2.2 Сложности, возникающие при применении стандарта OMG Essence 24
2.3 Выделение практик для анализа влияния Рабочих продуктов 25
2.4 Изучение описания практик 26
2.4.1 Изучение описания практики “Use-Case” на Языке Essence 26
2.4.2 Изучение описания практики “User Story” на Языке Essence 29
2.4.3 Изучение описания практики “Scrum” на Языке Essence 31
2.4.4 Изучение описания практики “Microservices” на Языке Essence 33
2.5 Систематизация результатов изучения практик 35
3 УЛУЧШЕНИЕ МОДЕЛИ СТАНДАРТА ДЛЯ ОПИСАНИЯ
ВЗАИМОДЕЙСТВИЯ ПРАКТИК 37
3.1 Предлагаемая классификация Рабочих продуктов 37
3.2 Представление метода разработки через композицию Рабочих продуктов 41
4 ФОРМАЛИЗАЦИЯ СУЩЕСТВУЮЩЕГО ПРОЦЕССА РАЗРАБОТКИ 44
4.1 Описание рассматриваемого проекта 44
4.2 Выделение используемых на проекте практик 45
4.3 Пример составления описания практики в терминах Essence 45
4.4 Выделение Рабочих продуктов в рамках практик 51
4.5 Составление ориентированного ациклического графа между Рабочими
продуктами 54
4.6 Анализ ключевых показателей эффективности проекта после внедрения
улучшений 60
ЗАКЛЮЧЕНИЕ 64
ЛИТЕРАТУРА 66
СПИСОК ИЛЛЮСТРАЦИЙ И ТАБЛИЦ 69
Современные программные проекты становятся все более сложными и масштабными, что обусловлено такими факторами, как цифровая трансформация, развитие технологий и растущие ожидания пользователей [1-3]. Эти крупномасштабные начинания сопряжены с неотъемлемыми рисками и проблемами, что подчеркивает критическую потребность в эффективном управлении проектами. Быстрый рост рынка разработки программного обеспечения указывает на увеличение объема реализуемых проектов. В условиях, когда уровень неудач остается высоким, актуальность качественного управления проектами становится еще более очевидной для предотвращения неблагоприятных ситуаций и экономических потерь.
Статистические данные о результатах деятельности ИТ-проектов, в первую очередь полученные из отчетов Standish Group, последовательно демонстрируют низкие показатели успеха [4]. В отчетах успешными признаются лишь 16,2% проектов, значительный процент проектов классифицируется как проблемные (52,7%) или неудачные, завершенные с дефектами (31,1%). Особенно неутешительными являются показатели успеха для крупных компаний, где успешными оказываются лишь 9% проектов [5], а для очень крупных проектов этот показатель может быть еще ниже - до 6% [6].
Кроме того, проекты часто сталкиваются с перерасходом средств и времени. Средний перерасход средств составляет 189%, а времени - 222% [5]. Важно отметить, что крупные компании демонстрируют худшие показатели по объему поставленных функций: в среднем реализовано лишь около 42% от первоначально заявленных возможностей.
Эти тенденции подтверждаются и другими источниками, такими как Gartner и McKinsey [7]. Gartner сообщает, что уровень неудач ИТ-проектов составляет 75-80%, а McKinsey указывает, что 17% крупных ИТ-проектов ставят под угрозу существование компании.
Постоянно низкие показатели успеха, наблюдаемые в различных исследованиях на протяжении многих лет, указывают на непреходящую проблему в управлении проектами разработки программного обеспечения, особенно крупномасштабными инициативами. Заметный контраст в уровнях успеха между малыми и крупными проектами и компаниями убедительно свидетельствует о том, что сложности, присущие более крупным проектам, требуют более изощренных и надежных подходов к управлению.
Эффективные методы управления проектами способствуют улучшению планирования и принятия решений в проекте, повышают производительность и взаимодействие в команде, улучшают управление рисками, повышают удовлетворенность заинтересованных сторон, обеспечивают более высокое качество программных продуктов, улучшают коммуникацию, обеспечивают более четкие цели и задачи, реалистичные сроки, надлежащее управление границами проекта, а также контроль затрат и соблюдение бюджета [8].
При этом стоит внимательно отнестись к понятию эффективности, поскольку каждый проект по-своему уникален, и каждая команда формирует собственный подход к тому, как она выстраивает процесс разработки программного обеспечения, поэтому результат от внедрения общеизвестных методов управления на проекте может значительно отличается от предполагаемого. В таком случае, команду будет интересовать управление проекта только в рамках действующих способах организации работ.
В работе рассматривается проект, посвященный открытию новых кредитных продуктов в крупной финансовой организации. На проекте:
• Активно используются устоявшиеся практики для каждой из фаз разработки.
• Проблемная область покрыта документацией.
• Существует описанный процесс поставки ценностей.
• Система функционирует предсказуемо и успешно поставляет бизнес- ценность.
Компания готова пробовать новое и охотно проводит эксперименты направленные на улучшение работы команды. Одной из таких идей является возможность формализовать процесс разработки, что, предполагаемо, позволит:
• Снизить количество принимаемых ошибок в управлении.
• Повысить прозрачность процесса.
• Предоставить единое понимание процесса поставки ценностей.
Поэтому было предложено представить работу на рассматриваемом проекте в общем виде при помощи стандарта OMG Essence.
В 2014 г. Object Management Group - объединение, занимающееся разработкой и продвижением объектно-ориентированных технологий и стандартов, наиболее известными из которых являются UML, XML и BPMN - утвердила документ "Kernel and Language for Software Engineering Methods (Essence)"в качестве своего стандарта [9], который обрел признание международного сообщества.
Стандарт фиксирует высокоуровневую модель, которая закрепляет за собой общие концепции для любого метода разработки программного обеспечения, а также вводит графическую нотацию, которая позволяет фиксировать практики программной инженерии и предусматривает новый подход к формированию методов программной инженерии [10]. В том числе, стандарт позволяет оценивать здоровье проекта, отслеживая прогресс и состояние его ключевых универсальных элементов, а также идентифицировать и отслеживать риски, рассматривая их как угрозы для достижения целевых состояний показателей здоровья прогресса и используя переходы между состояниями и контрольные списки как индикаторы потенциальных проблем.
Именно эти ключевые особенности стандарта стали основополагающими при выборе OMG Essence как инструмента формализации процессов.
Несмотря на заявленную универсальность к применению на проектах по разработке программного обеспечения, способность модели OMG Essence эффективно отражать нюансы взаимодействия между разнообразными практиками итерационной разработки может быть ограничена [11]. Различные итерационные подходы, такие как Scrum [12], Kanban [13], Agile Unified Process [14], Extreme Programming [15] и Lean Software Development [16] имеют свои специфические принципы, артефакты и процессы, взаимодействие между которыми в рамках Essence может быть смоделировано не в полной мере. Это может препятствовать использованию всего потенциала модели для анализа и представления методов итерационной разработки.
Поэтому, целью данной работы является проверка гипотезы об улучшении работы на проекте за счет формализации процесса разработки с помощью описания взаимодействия итерационных практик в рамках модели OMG Essence.
Для достижения цели работы ставятся следующие задачи:
1. Изучение стандарта OMG Essence и итерационных практик.
2. Формализация процесса разработки в рамках модели OMG Essence
3. Анализ проблем при формализации процесса разработки.
4. Улучшение модели стандарта для описания взаимодействия практик.
5. Применение улучшений и анализ результатов.
Магистерская диссертация состоит из четырех глав. В первой главе кратко изложены теоретические основы стандарта OMG Essence. Во второй главе выполнен анализ проблем при формализации процесса разработки. В третьей главе описаны улучшения модели стандарта для описания взаимодействия практик. В четвертой главе приводится проверка и оценка предлагаемых изменений на реальном проекте.
Оригинальным является представление Рабочих продуктов, предложенное для иллюстрации взаимодействия практик и композиции метода при переходе “от практик к теории”.
Практическая ценность работы, по мнению автора, заключается в упрощении использования стандарта OMG Essence при разработке программного обеспечения. Предложенный подход к представлению здоровья проекта может помочь разработчикам и инженерам лучше понимать состояние проекта, обнаруживать и устранять риски, повышать эффективность работы
Статистические данные о результатах деятельности ИТ-проектов, в первую очередь полученные из отчетов Standish Group, последовательно демонстрируют низкие показатели успеха [4]. В отчетах успешными признаются лишь 16,2% проектов, значительный процент проектов классифицируется как проблемные (52,7%) или неудачные, завершенные с дефектами (31,1%). Особенно неутешительными являются показатели успеха для крупных компаний, где успешными оказываются лишь 9% проектов [5], а для очень крупных проектов этот показатель может быть еще ниже - до 6% [6].
Кроме того, проекты часто сталкиваются с перерасходом средств и времени. Средний перерасход средств составляет 189%, а времени - 222% [5]. Важно отметить, что крупные компании демонстрируют худшие показатели по объему поставленных функций: в среднем реализовано лишь около 42% от первоначально заявленных возможностей.
Эти тенденции подтверждаются и другими источниками, такими как Gartner и McKinsey [7]. Gartner сообщает, что уровень неудач ИТ-проектов составляет 75-80%, а McKinsey указывает, что 17% крупных ИТ-проектов ставят под угрозу существование компании.
Постоянно низкие показатели успеха, наблюдаемые в различных исследованиях на протяжении многих лет, указывают на непреходящую проблему в управлении проектами разработки программного обеспечения, особенно крупномасштабными инициативами. Заметный контраст в уровнях успеха между малыми и крупными проектами и компаниями убедительно свидетельствует о том, что сложности, присущие более крупным проектам, требуют более изощренных и надежных подходов к управлению.
Эффективные методы управления проектами способствуют улучшению планирования и принятия решений в проекте, повышают производительность и взаимодействие в команде, улучшают управление рисками, повышают удовлетворенность заинтересованных сторон, обеспечивают более высокое качество программных продуктов, улучшают коммуникацию, обеспечивают более четкие цели и задачи, реалистичные сроки, надлежащее управление границами проекта, а также контроль затрат и соблюдение бюджета [8].
При этом стоит внимательно отнестись к понятию эффективности, поскольку каждый проект по-своему уникален, и каждая команда формирует собственный подход к тому, как она выстраивает процесс разработки программного обеспечения, поэтому результат от внедрения общеизвестных методов управления на проекте может значительно отличается от предполагаемого. В таком случае, команду будет интересовать управление проекта только в рамках действующих способах организации работ.
В работе рассматривается проект, посвященный открытию новых кредитных продуктов в крупной финансовой организации. На проекте:
• Активно используются устоявшиеся практики для каждой из фаз разработки.
• Проблемная область покрыта документацией.
• Существует описанный процесс поставки ценностей.
• Система функционирует предсказуемо и успешно поставляет бизнес- ценность.
Компания готова пробовать новое и охотно проводит эксперименты направленные на улучшение работы команды. Одной из таких идей является возможность формализовать процесс разработки, что, предполагаемо, позволит:
• Снизить количество принимаемых ошибок в управлении.
• Повысить прозрачность процесса.
• Предоставить единое понимание процесса поставки ценностей.
Поэтому было предложено представить работу на рассматриваемом проекте в общем виде при помощи стандарта OMG Essence.
В 2014 г. Object Management Group - объединение, занимающееся разработкой и продвижением объектно-ориентированных технологий и стандартов, наиболее известными из которых являются UML, XML и BPMN - утвердила документ "Kernel and Language for Software Engineering Methods (Essence)"в качестве своего стандарта [9], который обрел признание международного сообщества.
Стандарт фиксирует высокоуровневую модель, которая закрепляет за собой общие концепции для любого метода разработки программного обеспечения, а также вводит графическую нотацию, которая позволяет фиксировать практики программной инженерии и предусматривает новый подход к формированию методов программной инженерии [10]. В том числе, стандарт позволяет оценивать здоровье проекта, отслеживая прогресс и состояние его ключевых универсальных элементов, а также идентифицировать и отслеживать риски, рассматривая их как угрозы для достижения целевых состояний показателей здоровья прогресса и используя переходы между состояниями и контрольные списки как индикаторы потенциальных проблем.
Именно эти ключевые особенности стандарта стали основополагающими при выборе OMG Essence как инструмента формализации процессов.
Несмотря на заявленную универсальность к применению на проектах по разработке программного обеспечения, способность модели OMG Essence эффективно отражать нюансы взаимодействия между разнообразными практиками итерационной разработки может быть ограничена [11]. Различные итерационные подходы, такие как Scrum [12], Kanban [13], Agile Unified Process [14], Extreme Programming [15] и Lean Software Development [16] имеют свои специфические принципы, артефакты и процессы, взаимодействие между которыми в рамках Essence может быть смоделировано не в полной мере. Это может препятствовать использованию всего потенциала модели для анализа и представления методов итерационной разработки.
Поэтому, целью данной работы является проверка гипотезы об улучшении работы на проекте за счет формализации процесса разработки с помощью описания взаимодействия итерационных практик в рамках модели OMG Essence.
Для достижения цели работы ставятся следующие задачи:
1. Изучение стандарта OMG Essence и итерационных практик.
2. Формализация процесса разработки в рамках модели OMG Essence
3. Анализ проблем при формализации процесса разработки.
4. Улучшение модели стандарта для описания взаимодействия практик.
5. Применение улучшений и анализ результатов.
Магистерская диссертация состоит из четырех глав. В первой главе кратко изложены теоретические основы стандарта OMG Essence. Во второй главе выполнен анализ проблем при формализации процесса разработки. В третьей главе описаны улучшения модели стандарта для описания взаимодействия практик. В четвертой главе приводится проверка и оценка предлагаемых изменений на реальном проекте.
Оригинальным является представление Рабочих продуктов, предложенное для иллюстрации взаимодействия практик и композиции метода при переходе “от практик к теории”.
Практическая ценность работы, по мнению автора, заключается в упрощении использования стандарта OMG Essence при разработке программного обеспечения. Предложенный подход к представлению здоровья проекта может помочь разработчикам и инженерам лучше понимать состояние проекта, обнаруживать и устранять риски, повышать эффективность работы
Таким образом, в рамках работы был изучены теоретические основы стандарта OMG Essence и систематизированы основные знания о стандарте. Было получено представление гипотетического метода как композиции практик, выявлены основные проблемы при формализации процесса разработки, после чего был проведен анализ взаимодействия Рабочих продуктов в итеративных практиках на предмет их взаимных связей, а также отношений к Альфам разных уровней. Информация, полученная в рамках анализа, была синтезирована и систематизирована. На основе полученной информации было выдвинуто улучшение, разделяющее Рабочие продукты на два вида. С помощью данного улучшения было представлена возможность формализовать процесс разработки и описать взаимодействие итерационных практик в рамках модели OMG Essence при переходе “от практики к теории”. Предлагаемые улучшения были проверены на реальном проекте: по результатам оценки были получены выводы об увеличении количества завершенных задач и снижении времени работы над задачами, а также был успешно формализован существующий процесс разработки. Это позволяет сказать, что цель работы была успешно достигнута.
Хочется выделить, что представленное улучшение модели не является решением об уходе от Альф и их рассмотрения как неотъемлемой части стандарта OMG Essence и не предполагает обособленного рассмотрения от существующего Языка. Напротив, улучшения формируют дополнительные возможности, которые позволяют взглянуть на стандарт под другим углом, составить имеющиеся о проекте знания несколько иначе, с ориентацией на практический результат, возникающий в рамках деятельности.
Также, не стоит рассматривать применение стандарта как “лекарства от всех болезней” на проекте. В таком случае, правильнее будет охарактеризовать стандарт как “запрос к лечащему врачу” или же “сдачу анализов”. Иначе говоря, вы можете получить информацию о проблемных местах в проекте, однако “излечение”, причем болезни, а не симптомов, будет зависит от дальнейших решений, принимаемых командой по результатам работы со стандартом.
Также, хочется отметить, что предлагаемое представление Рабочих продуктов для отражения взаимодействия между итерационными практиками не претендует на полноту и требует дополнительного математического аппарата для соответствующего подтверждения. Это является дальнейшим заделом на работу.
Результаты данной работы могут быть использованы как основа для дальнейших исследований в области комплексного управления проектами по разработке программного обеспечения, а также в области управления рисками проекта, и будут полезны всем заинтересованным в улучшении качества программных систем и процесса разработки.
Хочется выделить, что представленное улучшение модели не является решением об уходе от Альф и их рассмотрения как неотъемлемой части стандарта OMG Essence и не предполагает обособленного рассмотрения от существующего Языка. Напротив, улучшения формируют дополнительные возможности, которые позволяют взглянуть на стандарт под другим углом, составить имеющиеся о проекте знания несколько иначе, с ориентацией на практический результат, возникающий в рамках деятельности.
Также, не стоит рассматривать применение стандарта как “лекарства от всех болезней” на проекте. В таком случае, правильнее будет охарактеризовать стандарт как “запрос к лечащему врачу” или же “сдачу анализов”. Иначе говоря, вы можете получить информацию о проблемных местах в проекте, однако “излечение”, причем болезни, а не симптомов, будет зависит от дальнейших решений, принимаемых командой по результатам работы со стандартом.
Также, хочется отметить, что предлагаемое представление Рабочих продуктов для отражения взаимодействия между итерационными практиками не претендует на полноту и требует дополнительного математического аппарата для соответствующего подтверждения. Это является дальнейшим заделом на работу.
Результаты данной работы могут быть использованы как основа для дальнейших исследований в области комплексного управления проектами по разработке программного обеспечения, а также в области управления рисками проекта, и будут полезны всем заинтересованным в улучшении качества программных систем и процесса разработки.