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

Введение

Термин «научно-технический проект» обычно интерпретируют как ограниченную во времени техническую деятельность коллектива специалистов по созданию научно-технического или научно-образовательного произведения (НТП/НОП). Однако на практике, при более конкретном рассмотрении, оказывается, что в проект также необходимо включать юридические (нормативно-правовые), финансовые, материально-технические и другие административные соображения. Иными словами, реальный проект представляет как административную, так и техническую деятельность, где административная деятельность (планирование работ, обеспечение и распределение кадров и ресурсов, учет и контроль) является такой же важной, как и непосредственно инженерно-техническая деятельность. Административная деятельность, как и техническая деятельность, базируется на соответствующем инструментарии — практиках (методиках) и инструментах, которые представляют инфраструктуру поддержки/сопровождения инженерно-технической деятельности, которая является ядром проекта.

Общая схема предлагаемой модели разработки программных комплексов приведена на иллюстрации (рис.1) и отражает конфигурацию документации проекта в виде «дерева», которое сначала формируется «сверху-вниз» в виде проектных спецификаций (декомпозиция системы на компоненты/модули), а затем, собирается «снизу-вверх» в форме программных реализаций (композиция системы из компонент/модулей). Для накопления/хранения рабочей документации проекта используется база данных/документов, в которой, например, структура административной части проектной документации также является деревом, узлы которого унифицированы и содержат техническое задание (ТЗ) компонент/модулей проектируемой целевой системы («что делать») и табель учета работ (ТУР) с информацией об исполнителях («кто делает»), плане работ («когда делает») и оценке (качества) работы и ссылками на узлы базы данных «ТЗ-ТУР» суб-компонент/модулей системы.

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

Научная новизна исследования состоит в разработке модели конфигурации проектной документации программных систем отвечающих указанной выше дисциплине разработки. Консолидированная проектная рабочая документация гарантирует ее целостность, а использование базы данных для накопления и хранения рабочей документации проекта («work_doc») позволяет автоматически составлять как текущие и сводные административные отчеты («admin_report»), так и технологическую («know-how») и эксплуатационную («user_manual») документацию программных комплексов.

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

(Источник: составлено автором)

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

Простая трехуровневая информационная модель наукоемкого микропредприятия (технологического стартапа) рассмотрена в работах [2, 3]. В настоящее время информационные системы наукоемких предприятий строятся на базе платформенных решений и предоставляют готовое программное обеспечение конечным пользователям в интернет-браузере «как услугу», т. е. по модели «SaaS» (программное обеспечение как сервис) [4, 5].

На сегодняшний день большую популярность в мире имеют как методики разработки и управления проектами «RUP» и «ХР», которые ориентированы на инженерно-технический («производственный») аспект процесса разработки, так и «SCRUM» и «KANBAN», которые акцентируют внимание на административном («управленческом») аспекте процесса разработки, т. е. на планировании, распределении, учете и контроле текущего потока задач выполняемых командой проекта. Ниже приводится краткий обзор данных методик управления проектами.

Краткий обзор моделей управления проектами

В процессе развития проекта создается проектная документация, которая вначале проекта может представлять листок бумаги с изложением идеи научно-технического или научно-образовательного произведения (НТП/НОП), а в конце проекта — огромную базу данных артефактов проекта, включающую административную, технологическую и эксплуатационную документацию. В курсе программной инженерии обычно рассматривают две основные модели разработки: последовательную или каскадную модель разработки, широко известным представителем которой является методология Waterfall (WF) и итеративную модель разработки, которую представляет методология Agile. В дисциплине разработки Waterfall все этапы процесса разработки системы — анализ, проектирование, реализация/кодирование и тестирование идут в строгой последовательности, один за другим. Эта методология характеризуется чётко прописанным планом разработки системы, что отражает организационная структура предприятия, подразделения которого представляют отделы специалистов указанных видов деятельности, т. е. группы аналитиков, проектировщиков, программистов и тестеров.

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

В ИТ-сфере на практике чаще используется итеративный подход к разработке ПО, суть которого состоит в выполнении указанных выше этапов проекта «небольшими частями», циклически. Вначале разрабатывается архитектура и общий каркас программной системы, а на последующих циклах добавляются функциональные компоненты в соответствии с определенным приоритетом. Данную дисциплину разработки ПО также называют инкрементной моделью процесса разработки.

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

Одной из моделей итеративного подхода к разработке ПО является методология «RUP» (Rational Unified Process). На рис.2 показана общая иллюстрация процесса разработки ПО по модели «RUP» [6]. По горизонтальной оси отражаются динамические аспекты, которые представляют развитие процесса во времени и оперируют такими понятиями, как стадии, итерации и контрольные точки. По вертикальной оси отражаются статические аспекты процесса, которые оперируют такими понятиями, как виды деятельности (технологические операции), рабочие продукты, исполнители и дисциплины (технологические процессы).

Рис.2. Иллюстрация итеративного процесса разработки по модели RUP

(Источник: [6])

Другой популярной моделью итеративного подхода к разработке ПО является методология экстремального программирования «ХР» (Extreme Programming). Иллюстрация процесса разработки ПО по модели «ХР» показана на рис.3. Дисциплина разработки «ХР» больше подходит для небольших команд и венчурных проектов с высокой степенью неопределенности в процессе достижения цели [7]. Выбор дисциплины разработки «ХР» отражается на организационной структуре венчурного предприятия, где выделяется «заказчик» или автор бизнес-идеи (концепции) системы, который представляет группу/пару с аналитиком/архитектором ИТ-системы и пул групп/пар разработчиков, каждая из которых обычно состоит из проектировщика спецификаций программных модулей компонента разрабатываемой системы и программиста, реализующего данные спецификации модулей.

«Заказчик» проекта, кроме подготовки архитектурных спецификаций компонент («метафор»), также проводит апробацию или испытание (т. е. оценку качества/адекватности — ОК/А) рабочей версии системы, которую реализовали и собрали на текущий момент. В случае обнаружения дефектов, вносятся изменения в соответствующие спецификации (скоуп), которые затем передаются на реализацию разработчикам. В методологии «ХР» планом работы команды является перечень рабочих задач, расположенных в порядке важности (бэклог). Заказчик системы видит весь процесс разработки и принимает в нем активное участие. Он оценивает функциональность текущей версии системы после каждой итерации. Дисциплина разработка «ХР» хорошо подходит для ИТ-проектов, где заказчик активно участвует в планировании и выполнении работы. При этом исходные требования проекта могут изменяться в результате оценки качества/адекватности системы в процессе ее реализации.

Рис.3. Иллюстрация итеративного процесса разработки по модели «XP»

(Источник: [7])

Приемы разработки методологии «ХР» легли в основу общего подхода к разработке ПО, который называется гибкой методологией разработки (Agile software development) и представляет целое семейство подходов и практик, основанных на ценностях и 12 принципах лежащих в основе манифеста гибкой разработки программного обеспечения [8]. Используя данную дисциплину разработки, члены команды постоянно взаимодействуют друг с другом и на основании полученной информации также могут принимать конкретные самостоятельные решения. Методология Agile предполагает открытое планирование и совершенствование процессов на регулярной основе с участием всей или большей части команды. Благодаря ежедневным кратким встречам (митапам), членам команды известно, кто, когда и над чем работает. Заказчик и менеджер проекта имеют возможность отслеживать текущий процесс работы по итогам спринтов — еженедельных или двухнедельных встреч с разработчиками, на которых обсуждаются результаты работы по проекту и планы на будущее.

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

На уровне предприятия/организации, который расположен над «производственным» уровнем, наиболее популярными методиками управления проектами, т. е. мониторинга и администрирования текущего пула задач, являются методики «SCRUM» и «KANBAN», которые также соответствуют принципам Agile [9]. Эти методики предполагают полную прозрачность, учет, контроль и обсуждение хода рабочего процесса в реальном времени. В методике «SCRUM» определяются следующие роли или лица проекта:

n заказчик – ответственное лицо, заинтересованных в распространении и эффективном использовании результатов НИОКР (разрабатываемой системы, технологии);

n администратор/менеджер проекта – ответственное лицо, заинтересованное в эффективной разработке системы. Реализует функции организации, совместного с разработчиками планирования (декомпозиции и координации) работ, мониторинга (учета и контроля) и обеспечения деятельности команды;

n разработчики – высококвалифицированные специалисты предметных областей знаний (аналитики и системные архитекторы, проектировщики, программисты и инженеры-системотехники, тестеры и испытатели, технические писатели), которые разрабатывают артефакты научно-технических произведений (ПО).

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

Рис.4. Сравнение методик управления проектами «SCRUM» и «KANBAN»

(Источник: [9])

Заметим, что рассмотренные выше методики «RUP» и «ХР» больше ориентированы на инженерно-технологический (производственный) аспект процесса разработки, тогда как методики «SCRUM» и «KANBAN» акцентируют внимание на административном/ управленческом аспекте процесса разработки, т. е. на планировании, распределении, учете и контроле текущего потока задач выполняемых командой проекта. Сравнение (перечень различий) методик разработки «SCRUM» и «KANBAN» приводится на иллюстрации показанной на рис. 4.

Каждая из рассмотренных выше методик разработки программных систем представляет дорожную карту или дисциплину развития проекта и сопровождается инструментами поддержки проектной деятельности. Однако, инструменты поддержки вышеуказанных методик обычно ориентированы либо на поддержку инженерного (производственного) аспекта проекта, либо на поддержку административного (управленческого) аспекта. Классификация рассмотренных методик управления разработкой программных систем приведена на диаграмме (рис.5), где методики «RUP» и «XP» отнесены к методикам поддержки инженерного (производственного) аспекта, а методики «SCRUM» и «KANBAN» отнесены к методикам поддержки административного (управленческого) аспекта процесса разработки.

На этой диаграмме также представлена консолидированная модель управления проектом «ХР++» («Extreme Planning») или «экстремального планирования», которая в значительной степени объединяет административный и инженерный аспекты проекта и рассматривается ниже в настоящей статье.

Рис.5. Классификация моделей разработки программных систем

(Источник: составлено автором)

Модель управления и документирования проектов «ХР++»

Предлагаемая модель «ХР++» является комплексным решением по управлению проектами разработки ПО и поддерживает более высокий уровень унификации/стандартизации конфигурации проектной документации по сравнению с рассмотренными выше методиками. Модель «ХР++» включает общую схему процесса разработки, структуру и шаблоны пакета проектной документации программных систем и обуславливает разработку соответствующих инструментов документирования и управления проектом. Роль и место модели управления проектом «ХР++» разработки ПО в архитектуре наукоемкого предприятия приведена на иллюстрации (рис.6). Модель «ХР++» представляет одну из гибких методик разработки ПО и хорошо сочетается с инструментами командной работы, управления производственным процессом и управления наукоемким венчурным предприятием.

Рис.6. Роль и место моделей управления проектом разработки ПО

в архитектуре наукоемкого венчурного предприятия

(Источник: составлено автором)

Рис.7. Схема жизненного цикла наукоемкого венчурного предприятия (технологического стартапа)

(а). Административный уровень предприятия (BizOrg и BizOps), (б). Уровень НИОКР/ОКР (Dev)

(Источник: составлено автором)

Общую схему жизненного цикла наукоемкого венчурного предприятия иллюстрирует рис.7. На этом рисунке также приведена схема жизненного цикла этапа разработки системы, т. е. процесса НИОКР/ОКР (Development), который подробно рассматривается ниже. Проекты разработки наукоемких программных систем (software development) кратко называют проектами НИОКР/ОКР. Административный уровень наукоемкого венчурного предприятия (BizOrg и BizOps) рассмотрен в работах [2, 3], а в данной работе рассматривается «производственный» уровень НИОКР/ОКР (Dev), т. е. уровень непосредственного управления разработкой программных систем.

Очевидно, что проект (НИОКР/ОКР) включает, как минимум, два параллельных процесса — это, во-первых, непосредственно процесс разработки научно-технических/научно-образовательных произведений (НТП/НОП) и, во-вторых, административный процесс обеспечения/поддержки (команды) процесса разработки НТП/НОП. Общая схема жизненного цикла НИОКР/ОКР (Dev) соответствующая рассматриваемой итеративной модели процесса разработки «ХР++» приведена на иллюстрации (рис.8.)

Рис.8. Схема жизненного цикла итеративного процесса разработки по модели «ХР++»

(Источник: составлено автором)

Целью проекта НИОКР/ОКР является разработка научно-технической системы (изделия), иными словами, команда проекта в процессе коллективной трудовой деятельности должна создать научно-техническое или научно-образовательное произведение (НТП/НОП), которое включает экземпляр технической системы/изделия и научно-техническую документацию, т. е. технологическую и эксплуатационную документацию разработанной системы/изделия. Важно отметить, что технологическая документация («know-how») часто имеет значительно большую финансовую и интеллектуальную ценность, чем непосредственно сам экземпляр технического изделия или (прототип) программной системы.

В отличие от инструментов сопровождения вышеуказанных методик «ХР» (extreme programming) или «RUP» (Rational Unified Process), предназначенных для создания артефактов программного обеспечения (реализаций целевых программных модулей и модульных тестов), инструменты сопровождения методики «ХР++» (extreme planning) поддерживают создание более широкой номенклатуры артефактов проекта, а именно текущих итеративных планов проектирования, реализации и испытания системы, архитектурных и технологических спецификаций, эксплуатационной документации, административных форм учета и контроля работ.

В соответствии с дисциплиной разработки «ХР++» проект НИОКР/ОКР разделяют на три крупные стадии (рис.8):

· эскизный проект (проектирование архитектуры системы),

· детальный/технический проект (проектирование компонент/модулей, реализация и тестирование (сборка) компонент/модулей и текущих реализаций системы/изделия),

· апробация системы (проект испытаний), т. е. проект оценки качества/адекватности системы, создания эксплуатационной документации, оформления и выпуска системы (изделия).

На стадии эскизного проектирования системы, творческий замысел автора, представленный ранее в виде концепции будущей системы, преобразуется аналитиками и архитекторами в документ описывающий конкретную архитектуру системы. Архитектура программной системы представляет часть проектной документации, в которой формулируются определенные задачи, которые должны быть выполнены командой разработчиков на последующих стадиях разработки системы. Архитектура программной системы включает фундаментальную структуру программного обеспечения, модель функционирования — модель обработки/хранения данных и модель управления системой. Фундаментальная структура системы представляет описание функций компонентов программного обеспечения высокого уровня, а также их свойства. Кроме перечня функциональных требований к будущей программной системе, также формулируется набор не функциональных требований, среди которых часто выбирают следующие [10, 11]:

· fault tolerance (reliability) / отказоустойчивость (надёжность) системы,

· speed of development / скорость разработки,

· ease deployed / простота развертывания,

· scalability by the number of people in the project / масштабируемость по количеству человек в проекте,

· scalability in terms of requests per second / масштабируемость по количеству запросов в секунду,

· fast entry/exit to resolution / быстрый вход/выход в разработку,

· application deployment speed / скорость развертывания приложения.

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

Задача детального проектирования – декомпозиция определенных в эскизном проекте архитектурных высокоуровневых компонентов системы на более мелкие, минимально связанные между собой блоки — компоненты/модули. Для этого формируется иерархическая структура работ (work breakdown structure) – сокращенно ИСР (WBS). ИСР – ориентированная на результат иерархическая декомпозиция работ, выполняемых командой проекта, где каждый следующий более низкий уровень иерархии отражает более конкретное/детальное определение проектируемых компонент/модулей системы. Проект целевой системы обычно включает как самостоятельные, так и сторонние решения компонент/модулей разрабатываемой системы.

На схеме жизненного цикла итеративного процесса разработки (рис.8) центральный узел соответствует роли «администратора/диспетчера» детального/технического проекта, где разработчики определяют иерархическую декомпозицию работ и планируют последовательность проектирования, реализации и тестирования компонент/модулей программной системы. Отметим, что если разработчики приняли решение — сначала полностью спроектировать дерево компонент/модулей целевой программной системы («сверху-вниз»), а затем реализовать целевую систему в обратной последовательности («снизу-вверх»), то такая дисциплина разработки соответствует модели «Waterfall», которая была рассмотрена выше. В настоящее время, однако, обычно используется итеративная модель разработки, которая подразумевает по-компонентную разработку системы, т. е. следующую последовательность действий:

· выбор/определение одного из компонент/модулей высокого уровня,

· проектирование компонента (нисходящая декомпозиция до терминальных модулей),

· сборка компонента (восходящая реализация, интеграция и тестирование), включая тестирование обновленной текущей реализации целевой системы,

· [новый цикл].

Проектирование системы — это процесс декомпозиции и разработки программных спецификаций компонент/модулей системы. Общая схема процесса проектирования компонент/модулей целевой системы приведена на рис.9. Исходным документом, в котором определен ожидаемый результат проектирования системы, является спецификация архитектуры системы. В процессе проектирования системы разработчиками создается база данных технической документации, которая представляет структуру типа «дерева», каждый узел которого представляет артефакт документации проекта, включающий:

· техническое задание (ТЗ) и табель учета работ — календарный план работ по проектированию компонента системы (ТУР-КПР),

· спецификации разрабатываемых компонент и ссылки на используемые компоненты и терминальные модули,

· спецификации разрабатываемых модульных, интеграционных и системных тестов и ссылки на используемые модульные, интеграционные и системные тесты,

· промежуточный плановый отчет — фактический учет и контроль работ по проектированию компонента системы (ТУР-ФУК).

Рис.9. Проектирование системы: процесс декомпозиции — разработки технических спецификаций компонент/модулей системы

(Источник: составлено автором)

Сборка системы — процесс программирования, интеграции и тестирования программных компонент/модулей целевой системы. Общая схема процесса сборки компонент/модулей целевой системы приведена на рис.10. Техническая документация, созданная в процессе проектирования и содержащая спецификации компонент/модулей системы, а также набор сценариев тестов, является исходным документом, в котором определен ожидаемый результат работы по реализации и тестирования системы.

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

· техническое задание (ТЗ) и табель учета работ — календарный план работ по реализации компонента/модуля системы (ТУР-КПР),

· реализацию (реплику) исходного кода и ссылки на используемые спецификации модульных, интеграционных или системных тестов,

· реализацию (реплику) исходного кода и ссылки на используемые спецификации компонент/модулей целевой системы,

· плановый отчет, т. е. фактический учет и контроль работ по реализации компонента/модуля системы (ТУР-ФУК).

Рис.10. Сборка системы: процесс композиции — разработки, интеграции и тестирования программных компонент/модулей системы

(Источник: составлено автором)

На иллюстрации (рис.11) приведена схема рабочего цикла детального/технического проекта системы. Кроме технической документации, т. е. пакета технических артефактов (спецификаций и реализаций) компонентов/модулей системы, документация проекта также содержит административную документацию, т. е. базу данных технических заданий и табелей учета работ (ТЗ-ТУР):

· название технического задания/работы по разработке компонента системы (ТЗ: имя компонента системы и краткий комментарий),

· календарный план работы — прогноз затрат рабочего времени на разработку компонента системы (ТУР-КПР),

· плановый отчет, т. е. фактический учет и контроль выполненной работы (ТУР-ФУК).

Рис.11. Рабочий цикл детального/технического проекта

(Источник: составлено автором)

База данных рабочей документации детального/технического проекта имеет иерархическую структуру (рис.12) и обычно содержит большое количество различных артефактов/документов. В соответствии с методологическим принципом «Бритвы Оккама» и практической рекомендацией YAGNI («You aren't gonna need it» — «Вам это не понадобится»), необходимо избегать излишней бюрократизации процесса разработки и не плодить бесполезные сущности/артефакты [12,13]. Например для простых тестов, в частности, проверки корректности работы программы при граничных значениях параметров, вместо отдельных документов представляющих тестовые сценарии, вполне достаточно кратких комментариев в программах реализации модульных тестов.

Рис.12. Схема базы данных рабочей документации детального/технического проекта

(Источник: составлено автором)

Рис.13. Схема ЖЦ итеративного процесса разработки наукоемкой программной системы

(Источник: составлено автором)

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

Рис.14. Схема апробации целевой системы (изделия)

(Источник: составлено автором)

Заметим, что во многих случаях при разработке наукоемких программных систем часто отсутствуют стандартные средства оценки качества/адекватности (ОК/А) создаваемой целевой системы. Поэтому параллельно с разработкой целевой системы, требуется также разработать отдельную систему ОК/А целевой системы (рис.13). В этом случае общая схема жизненного цикла итеративного процесса апробации наукоемких программных систем приведена на иллюстрации (рис.14).

Очень часто научно-технические проекты реализуются технологическими стартапами — независимыми или автономными наукоемкими предприятиями, субъектами научно-технической и образовательной сферы (НТО-сферы). Документация наукоемкого предприятия содержит, по крайней мере, два существенно различных вида документов. Это, во-первых, документы относящиеся к предпринимательской или экономической сфере деятельности предприятия и, во-вторых, документы относящиеся к научно-технической («производственной») сфере деятельности. Аналогично, документацию научно-технического проекта также можно представить в виде структуры, где два типа документов разделены на документы относящиеся к административной деятельности и документы относящиеся непосредственно к производственной деятельности («Development»). Подготовка плана «производственной» деятельности предприятия является важной частью общего предпринимательского процесса и обусловлена кадровыми и бюджетными ограничениями. Один из вариантов общей конфигурации документации наукоемкого микропредприятия (схемы Банка Данных) приведен на рис.15.

Рис.15. Общая конфигурация документации наукоемкого микропредприятия и

конфигурации документации НИОКР/ОКР

(Источник: составлено автором)

Заключение

В работе предложена и рассмотрена одна из моделей управления проектами — модель экстремального планирования процесса разработки «ХР++» («Extreme Planning»). Предложенная схема документации разработки ПО развивает и дополняет известную практику разработки ПО экстремального программирования («ХР»), но также может использоваться совместно с другими методиками разработки программных систем. В совокупности с методикой экстремального программирования «ХР» («Extreme Programming»), данная консолидированная модель представляет методику управления проектами разработки ПО, которая логически и информационно связывает между собой технологические и административные артефакты проекта.