МОДЕЛЬ ПРОГРАММНОГО ПРОЕКТА

Маркова Н.А. (markova@amsd.com) Институт Проблем Информатики РАН

Abstract

Modern programming needs revising of base organizational principles. The old life circle model is not able to represent essential problems of program project management. A key insight of the framework presented in this paper is that a Program Project can be seen as the composition of Activities with common characteristics. They have Input and Output need Resources and are executed by Rules. Consideration of Activities surrounding dynamic and their integration in world wide computer realm is the base of a Program Project Model. It defines approaches for successful management and control of program projects.

Введение

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

Мир информатики интегрирован в единое целое - мировое информационно-вычислительное пространство, связанное общей Сетью. Он, с одной стороны, полон программными продуктами, с другой, чрезвычайно динамично эволюционирует (вернее, наверное, было бы сказать революционирует ). По новому летоисчислению год (WEB-year) - это 3 календарных месяца. Причем работать надо не только быстро, но и по другой схеме - нужно как можно раньше выпускать на рынок прототипы, бета-версии продукта, чтобы, с одной стороны, приручать потенциального пользователя, с другой, - выявлять и учитывать его потребности. В этих условиях старые представления об этапах разработки программ (обоснование требований, спецификация, кодирование, тестирование, внедрение, сопровождение), составляющих жизненный цикл , работают плохо. И дело не только в том, что во многих случаях речь идет о выполнении отдельного этапа, либо об их многократном повторении. Не менее важно то, что рассматриваемые в рамках моделей жизненного цикла работы представляют лишь вершину айсберга, под которым даже не обозначен массив обеспечивающих работ, которые в реальности требуют немалых ресурсов и времени. В реальных проектах фазы существенно перекрываются, часто возникают обратные потоки, например, от кодирования к новой спецификации. 4 тому же использование современного инструментария размывает границы между фазами, в частности, если спецификация использует формальный язык, трудно определить, где кончается спецификация и начинается кодирование. Если и в более неспешные времена, программирование было трудно втиснуть в рамки сколько-нибудь упорядоченного технологического процесса, то сегодня это сделать еще труднее. Но необходимо. Потому что

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

Программный проект

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

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

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

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

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

Общая характеристика проектных работ

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

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

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

Помимо Входных и Выходных в Проекте используются также Служебные материалы - в той или иной степени, зафиксированные и оформленные формулировки проблем, идей, вопросов, решений.

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

Помимо иерархического отношения между Работами (Работа входит в Работу), проектные Работы могут быть также связаны

- связью поставщик-потребитель - Выход одной Работы является Входом другой либо одна из Работ состоит в подготовке (разработке) Ресурса или Правила (метода) для другой

- связями по разделению Ресурсов

Координация Работ - регламентация отношений между ними задача Управления Проект может идти стихийно, либо быть в той или иной степени управляем. Под Управлением понимается соответственно:

- декомпозиция Работ

- планирование Работ

- распределение Ресурсов

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

В программных Проектах все сопряженные с Работой объекты обладают динамикой, то есть, в процессе Работы изменяются не только ее Выходные материалы, но и (вполне вероятно) Входные материалы, Ресурсы и Правила. Ограничение динамики сопряженных объектов является необходимым условием успешности Работы. Если входная информация или Ресурсы меняются непрерывно, трудно ожидать разумных результатов. Для объектов программного Проекта - программ, спецификаций и прочих документов регламентация динамики осуществляется путем идентификации и фиксации Версий. Мы будем применять термин Версионное обеспечение вместо Конфигурационного управления (менеджмента) так как он лучше отражает сущность работы. Заметим, что ISO 9001 (международный стандарт Система Качества - Модель гарантии [для обеспечения] качества при проектировании, разработке, производстве, внедрении и обслуживании ) в версии от 1994 года отказалось от Configuration Management, введя Product Management [1], что в русском переводе было бы совсем не понятно.

Подготовка Ресурсов и Правил, а также поддержка их работоспособности -задачи инструментально-технического и нормативно-методологического обеспечения Проекта.

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

На рисунке 1 отображены отношения Работы с ее окружением, включающим обеспечивающие Работы.

На практике Проекты носят различный характер: от четко определенной технологической цепочки до хаотической деятельности с малопонятным

результатом. Предложенный набор терминов может служить основой анализа степени организованности Проекта.

Рис. 1. Работа и ее окружение

Модель Работы

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

Построение проведем в два этапа. Сначала представим идеализированную картину Проекта без проблем. Затем, рассмотрев ее рассогласование с реальной практикой, попытаемся ее уточнить.

Работа обеспечивает преобразование Входа в Выход с привлечением определенных Ресурсов, по определенным Правилам, в соответствии с некоторым Процессом.

Activity = <Input, Output, Resource, Rules, Process > (1)

Вход (Input) и Выход (Output) для программных Работ - это, как правило, Документы (включая, в частности, Текст программы, в том числе бинарный).

Ресурсы (Resource) - это персонал (исполнители), аппаратура, программный инструментарий.

Правила (Rules) - методы работы, стандарты и нормативы, в частности правила подготовки и оформления выходных Документов.

Процесс (Process) представляет динамику Работы и характеризуется ее составом, планом, и ходом работ.

Process = <Constitution, Plan, Progress> (2)

Состав Работы (Constitution) представляет список включаемых Работ:

Constitution = {Activity j=1,.. } (3)

План Работы (Plan) - последовательность предполагаемых состояний, фиксируемых в начальном промежуточных и конечном моментах времени.

Plan = {State(ti) i=0,.. } (4)

Ход работы (Progress) - это фактически достигнутые состояния в моменты контроля.

Progress = {State(xi) i=0,.. } (5)

Состояние характеризует сопряженные с Работой объекты в определенный момент времени. Для каждого из них выражается либо неформально, либо в той или иной степени формализовано - как совокупность атрибутов, часть из которых номинативные, другие количественные.

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

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

in: Time -- Input out: Time - Output consume: Time - Resource rule: Time - Rules

Состояние Работы в момент времени t есть совокупность состояний всех компонентов ее окружающих:

State(t) = <in(t), out(t), consume(t), rule(t)> (6)

Предложенный формализм несколько расходится с отечественной практикой. Так под планом чаще понимается то, что в модели названо Состав - список подчиненных Работ - в совокупности с соответствующими выходными материалами (их состояниями в нашей терминологии). Заметим, что в зарубежной практике принято разделять содержание работ на некоторой фазе Проекта от плана выпуска (Delivery Schedule) материалов.

Два момента отличают предлагаемую концепцию планирования: разделение уровней планирования и явная фиксация динамики окружения.

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

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

Примеры планируемых изменений в окружении Работы:

- спецификации на сопряженный компонент X заказчик предоставит xx.xx.xx

- рабочая станция Y будет установлена yy.yy.yy

- версия Z Microsoft-ZZZ планируется к выпуску zz.zz.zz

Но никакое планирование не может предусмотреть всего. Возникновение рассогласования между Планом и Ходом работ (рассматриваемой или сопряженной) носит событийный характер. К влияющим на Работу событиям относятся:

- не соблюдение сроков внешних обязательств (заказчик запаздывает с предоставлением спецификаций на X)

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

- возникновение ресурсных проблем (вышло из строя оборудование, уволился исполнитель)

- обнаружение ошибок в планировании (не достаточно ресурсов, плохо подготовлен персонал, задача оказалась сложнее, чем ожидалось, существует угроза срыва сроков) или дефектов во Входных материалах

Отслеживание потока этих событий и принятие адекватных решений -задача Управления. Его реакция на очередное событие может быть различной:

- принять к сведению (решение отложено)

- запланировать обеспечивающую Работу (например, ремонт оборудования)

- изменить план (входные материалы, ресурсы, сроки)

- принять решение об экономической нецелесообразности продолжения Проекта.

Поясним причины откладывания решений. Чтобы завершиться в разумные сроки, Работа должна обладать определенной инерцией по отношению к внешним изменениям. Нельзя моментально реагировать на все изменения окружения. Необходимость изменения Входных материалов или инструментария должна быть обоснована и авторизована Управлением. До принятия такого решения Работа должна опираться на старые версии.

Как совокупность материалов, участвующих в формировании решений (мы их назвали Служебными), так и механизмы их принятия, большей частью плохо формализуются и находятся вне рамок настоящей работы. Управление представляет совокупность процессов, согласованно производимых на разных уровнях иерархии Работ, с учетом связей между поставщиками и потребителями материалов, возможно, в ряде аспектов децентрализовано с привлечением моделей массового обслуживания (например, при выполнении инструментально-технической службой заявок на ремонт оборудования). Интересный обобщающий подход к решению такого рода задач Управления предложен в рамках междисциплинарной теории координаций [2]. В ней рассмотрены все основные виды зависимостей меду Работами: разделение ресурсов, отношения поставщик/потребитель, задача/подзадача.

Отметим несколько аспектов в организации проектных работ, определяющих их успешность:

- формулировки проблем, альтернативных подходов к их решению, аргументации выбора и собственно принятого решения должны фиксироваться, иначе мы имеем типовую ситуацию не убираемых с дороги грабель

- необходима дискретизация потоков изменений посредством фиксации Версий Входных-Выходных материалов, передаваемых между Работами в рамках Проекта, а также между Проектом и окружением

- чем скорее будет обнаружена проблема, тем больше вероятность ее успешного решения, поэтому, отслеживание хода работ - Контроль является залогом реализации Проекта

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

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

Учет перечисленных аспектов требует редакции модели (1) - (6). Не претендуя

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

Прежде всего, мы должны отметить наличие в Проекте и на уровне подчиненных Работ большей частью не формализованных оперативных документов. К ним относятся переписка, служебные и докладные записки, формулирующие проблемы, предлагающие или фиксирующие решения. Совокупность таких документов мы назвали Служебными материалами (Service). Появление служебного материала либо отмечает некоторое событие, либо является следствием рассмотрения другого служебного материала.

План не постоянен, он корректируется в дискретные моменты времени, причем новую редакцию целесообразно рассматривать как некоторую версию документа v - Plan(v). Формирование плана в терминах версий сопряженных объектов и ожидаемых сроков их появления, трансформирует определение (4) в следующую форму

Plan(v) = { <Oi(vi), t> i=0,.., vieVersions(Oi) } (7)

здесь

Oi - состояние сопряженных с Работой объектов vi - их Версии из соответствующих множеств Versions(Oi) tI - момент поступления версии vi в рассматриваемую Работу План фиксирует агрегатное соответствие объектов - каким версиям Входных материалов соответствуют какие версии Выходных материалов.

Новому Плану соответствует, вообще говоря, другая Работа - мы будем говорить о ней как о версии Работы - Activity(v). У нее другой Состав Constitution(v). Тогда всю Работу в целом будем воспринимать как совокупность версий, или, вынося за скобки соответствующие множества документов как

Activity = <Input, Output, Resource, Rules,

{Constitution(v), Plan(v)}, Progress, Service> (8)

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

Заключение

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

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

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

Литература

1. M. Jenner. Software Quality Management and ISO9001. How to Make Them Work for You. NY.: A Willey-QED, 1995

2. T. W. Malone, K. Crowston. The Interdisciplinary Study of Coordination. -ACM Computing Surveys, 1994 (March), 26 (1), 87-119.