Система принятия решения для формирования команды разработчиков программного обеспечения с использованием компьютерного моделирования

Статья впервые опубликована в блоге blog.vityasev.ru.

Автор: Ярослав М. Витязев.

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

Как и другие традиционные инженерные дисциплины создание программного обес­печения имеет дело с проблемами стоимости и надёжности. На протяжении нескольких деся­тилетий стоит задача поиска повторяемого, предсказуемого процесса или методологии, кото­рая бы улучшила продуктивность и качество создаваемого ПО [1, 2, 3, 4]. Без четкого управления разработка ПО выходит из-под контроля, съедая лишнее время и средства. Управление и планирование должно позволять сокращать затраты на разработку и поддержку ПО, позволять завершать ее в срок и с учетом выдвигаемых к ней требований каче­ства.

Существует ряд подходов к процессу создания программного обеспечения, описывае­мых некоторыми моделями [5]. В рамках статьи мы рассмотрим лишь две из них: модель водопада и итеративный процесс (включающий экстремальное про­граммирование и гибкие методологии). На основе этих подходов в дальнейшем будут построены базовые модели процесса разработки ПО - модели структуры задач проек­та.

В каскадной модели каждая из процессных областей представляет собой отдельную фазу проекта [5]. Фазы выполняются строго последовательно, т. е. анализ и дизайн начинаются после написания требований, началу реализации предшествует завершение ди­зайна и т. д. Этот метод хорошо работает в проектах, где требования могут быть четко опреде­лены и зафиксированы. В таких проектах каскадная модель позволяет обеспечить заданный уровень качества (который может быть весьма высоким) и соблюдать бюджетные и времен­ные ограничения. Благодаря этому она часто используется в больших организациях при строгих требованиях к надежности создаваемого ПО.

Процесс итеративной (или инкрементальной) разработки стал эволюционным развити­ем модели водопада [5, 8]. Процесс состоит из серии повторяющихся итераций (их число зависит от конкретного проекта), каждая из которых фактически является полноценным мини-проек­том с фазами определения требований, анализа, дизайна и т. д. В результате очередной итера­ции продукт приобретает новую функциональность или улучшения в существующей функцио­нальности. Полный набор требований, зафиксированный границами проекта, оказывается реализованным после завершения финальной итерации. Итеративная модель используется во многих процессах разработки, включая RUP и гибкие методологии [3, 5].

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

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

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

Для реализации такой моделирующей системы необходимы следующие модели: общая модель проекта, субмодели задачи, структуры (или последовательности) задач, ресурсов, а также субмодель специалиста как частный случай субмодели ресурса. Для каждой из этих субмоделей должен быть определен ряд показателей - количественно измери­мых переменных, которые могут быть применены для последующего анализа эффективности проектной команды.

Модель задачи (MPT) в рамках моделирующей системы должна отражать параметры, необходимые для вычисления показателей эффективности. При моделировании разумно ис­пользовать схему «план-модель-факт», при помощи которой впоследствии можно будет срав­нить плановые, модельные и фактические показатели стоимости и сроков выполнения зада­чи. Каждая задача уникальна, поэтому могут потребоваться дополнительные параметры и по­казатели эффективности, кроме общих для всех задач, таких как: вероятность завершения за­дачи в срок, вероятность завершения задачи в рамках бюджета и т. п.

Как правило, проект по разработке ПО состоит из нескольких задач, ко­торые далеко не всегда выполняются по принципу обыкновенной очереди. В этом случае в моделирующей системе должна быть предусмотрена модель для построения структуры за­дач (MPTS). Такая модель может иметь множество воплощений, например, реализовывать стандартные структуры процессного подхода к управлению задачами в виде WBS-связей; она может использовать сети Петри или же основываться на цикле Деминга PDCA [5]. Для последо­вательности задач также формируются показатели эффективности, при помощи которых можно при анализе определить вероятности осуществления перехода от одной задачи к дру­гой, задержки между задачами (которые могут возникнуть, например, при определенных па­раметрах исполнителей), стоимость и продолжительность выполнения всех задач проекта.

Как правило, с проектом и каждой его задачей связаны различ­ные ресурсы. Это следует отразить в модели ресурса (MPR). В некоторых моделях исполнителей (специалистов) также рассматривают как особый вид ресурса. Ресурсы могут тратиться (например, деньги, сро­ки), быть занятыми (рабочее время специалиста). Такие свойства ресурсов как исчерпаемость и занятость должны быть отражены и обязательно учитываться в модели. Структура парамет­ров варьируется для каждого типа ресурса и определяется требуемыми показателями эффек­тивности, которые будут использованы при последующем анализе. Среди таких показателей можно выделить загруженность ресурса, состояние занятости ресурса, объем ресурса и т. д.

При создании субмодели специалиста (MPRS) по разработке ПО необходимо выде­лить ряд обобщенных параметров, характерных для каждого специалиста и важных при аль­тернативном выборе. Такими параметрами могут быть как простые: оценка стоимости часа работы, возможность поддержания оперативной связи, оценка сроков выполнения работы, возможность выполнения работы, занятость, так и факторы со сложной структурой:

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

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

На рисунке 1 представлена общая схема работы системы. На этапе формирования проектной команды уже должна существовать структура работ, которая может быть опреде­лена как модель MPTS в виде определенной последовательности задач (MPT). Аналогично задаются и ресурсы проекта - в виде модели MPR. Формируются исходные данные в виде массива параметров специалистов, которые могут быть использованы как члены проектной команды. На каждой итерации происходит расчет показателей эффективности для каждой из используемых моделей, при этом на каждой итерации подставляются новые элементы из мас­сива параметров специалистов. Показатели эффективности (E) накапливаются и записывают­ся в специальное хранилище. Таким образом, на выходе мы получаем набор показателей эф­фективности по каждой из описанных выше моделей для всех возможных составов проект­ной команды. Поскольку для каждого состава проектной команды рассчитанные показатели совпадают по структуре, мы можем их сравнить различными способами между собой и сде­лать альтернативный выбор команды разработчиков ПО. Эту задачу должна решать подси­стема анализа и сравнения, описание которой выходит за рамки данной статьи.

Рисунок 1. Общая схема работы системы

(кликните для увеличения; откроется в новом окне)

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

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

В таком ключе имеет смысл разработка и использование так называемого фреймворка (от англ. framework): набора стандартных базовых для каждой мо­дели классов с возможно­стью расширения их функциональных возможностей [6].

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

Framework отличается от библиотеки (library) тем, что выполняет код, написанный для него, а не исполняется сам. Также в отличие от библиотеки, которая объединяет в себе набор близкой функциональности, фреймворк содержит в себе большое число разных по сфере применения библиотек, которые могут использоваться для более простого решения каждой конкретной задачи [6, 7].

Использование фреймворка для реше­ния задачи моделирования является удоб­ным методом и позволяет использовать единую функциональ­ную основу, облегчающую построение каждой модели. В сам фреймворк необходимо заложить основные модели (MPT, MPTS, MPR, MPRS), которые на практике можно применить для решения задачи подбора проектной команды.

Список источников

И. Соммервилл. Инженерия программного обеспечения = Software Engineering. - 6-е изд. - М.: «Вильямс», 2002. - С. 642. - ISBN 5-8459-0330-0
Управление проектами: Пер. С англ. / Паула Мартин, Карен Тейт. - К.: [КПЯ «СИСТЕМИ»], 2005. - 192 с.: ил.
Разработка программного обеспечения [Электронный ресурс] : Википедия, свободная энциклопедия. Режим доступа http://ru.wikipedia.org/wiki/Разработка_программного_обеспечения , свободный.
Brooks, Fred (1995). The Mythical Man-Month, 20th Anniversary Edition, Adison Wesley. ISBN 0-201-83595-9.
Современные процессы разработки программного обеспечения [Электронный ресурс] : Библиотека RSDN. Режим доступа http://rsdn.ru/article/ Methodologies/SoftwareDevelopmentProcesses.xml, свободный.
Framework [Электронный ресурс] : Википедия, свободная энциклопедия. Режим доступа http://ru.wikipedia.org/wiki/Framework , свободный.
Джек Гринфилд, Кит Шорт, Стив Кук, Стюарт Кент, Джон Крупи. Фабрики разработки программ (Software Factories): потоковая сборка типовых приложений, моделирование, структуры и инструменты = Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. - М.: «Диалектика», 2006. - С. 592. - ISBN 978-5-8459-1181-0
Managing the Development of Large Software Systems [Электронный ресурс] : Royce, Winston (1970). Режим доступа http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf , свободный.

Текст статьи доступен в формате PDF (103 Кб).