Как нам организовать проект?

Оценка рисков

Классификация Контроля

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

Кто виноват в провале проекта?

Закон Мэрфи гласит: «Если неприятность может произойти, она случается». Бороться с этим можно, если заранее оценить все возможные неприятности - риски и, соответственно, попытаться застраховаться от них. Перечислим наиболее опасных виновников неприятностей.

Заказчики. Две наиболее типичные формулировки задания звучат так.

• «Пойди туда, не знаю куда, и принеси то, не знаю что».
• «Мне такую же, но с перламутровыми пуговичками».

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

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

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

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

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

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

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

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

Обобщать оценки риска имеет смысл по разделам, которых может быть достаточно много (10-20). Целесообразно сопоставлять отдельным категориям риска соответствующие действия. Например, если намечаются проблемы с заказчиком, стоит четче продумать регламент взаимодействия (включая, в частности, гарантированную систему реакций - согласований, регулярность совещаний, тщательную подготовку критериев приемки, включение стадии быстрого прототипирования и пр.).

Что делать для успеха проекта?

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

Мы тоже работаем, в основном, с документами (программа - это документ). Законы их подготовки и продвижения схожи, так давайте также использовать опробованные элементы технологии: наличие шаблонов и реквизитов, нормоконтроль, аппарат согласования и утверждения, отслеживание прохождения.

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

Рассмотрим некоторые элементы «правильных» технологий. Их выбор продиктован двумя соображениями: с одной стороны, они иллюстрируют основные подходы, с другой, являются иллюстративно-показательными, приближенными к практике «простого» программиста. О них многие наслышаны, однако сведения об их практическом использовании на отечественных предприятиях отсутствуют. Опыт автора подтверждает возможность их внедрения при небольших трудозатратах.

Основными направлениями улучшения организации программных проектов являются упорядочение и контроль - нужно навести порядок в документах, ресурсах и процессах, отслеживать их состояния и оперативно принимать решения по коррекции документов/ресурсов/процессов (или соответствующих порядков).

Навести порядок в документах

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

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

#include «c:/MyProg/MyInclude.h»

вполне допустима в программе индивидуальной разработки, однако для проекта, выполняемого коллективом разработчиков, указание явного пути к файлу чревато проблемами (у соисполнителя этот файл может лежать на d:/MyProg).

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

Один из таких вопросов - дисциплина именования. Безусловно, роза пахнет розой, как ее не назови, но если у нас десятки сортов роз и десятки видов других цветов, а в автоматизации флористики принимают участие несколько разработчиков, и мы хотим, чтобы они быстро друг друга понимали, а при случае и взаимозаменяли, приходится идти на жесткие ограничения. Не все из предлагаемых подходов в именовании бесспорны. Рационально, например, включать в имя переменной сведения о ее категории. Например, член класса начинается с «m_». Однако очень хотелось бы, чтобы статический член класса назывался бы по-другому. Весьма дискуссионной представляется практика включения в имя сведений о физическом представлении данных. В частности, широко разошедшийся с легкой руки Microsoft DWORD, в виде приставки имен переменных dw, только путает - Word уже давно не равно 16 разрядам, а DWORD все еще 32.

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

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

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

Легко обеспечить порядок в документе, если создавать его путем заполнения стандартной формы. Еще лучше, если имеется образец (рыба). В простейшем случае можно отработать шаблон (template) документа, где по его реквизитам формируются заголовок и колонтитул. Далее следуют стили заголовков структурных частей (с обязательной иерархической идентификацией/нумерацией). Наконец, чрезвычайно удобно работать с текстовыми заготовками («Требования к пользовательскому интерфейсу»).

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

Навести порядок в процессах

Также как и для документов, порядок для конкретного вида процесса должен определять некоторый документ (правила, нормы, стандарт), его регламентирующий. Но прежде чем регламентировать отдельные виды работ, необходимо представить всю их совокупность. Наиболее полно и последовательно номенклатура процессов программного проекта представлена в стандарте ISO 12207. Один из возможных вариантов обобщенного представления процессов (работ) программного проекта можно найти в [4]. Здесь мы остановимся только на нескольких существенных факторах, влияющих на упорядоченность большинства процессов.

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

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

Контроль. Говоря о любом виде работы, необходимо представлять, как она будет контролироваться

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

Обратим внимание на один из наиболее эффективных для программного проекта видов контроля - формальные инспекции [6], представляющие собой формализованную экспертизу документов (в частности, кодов программы), суть которой состоит в том, что документ читается профессионалом (не автором программы) с целью выявления дефектов. Специальные правила обеспечивают эффективность и психологический комфорт процедуры. В частности, инспектируемый документ необходимо сопоставлять с правилами его составления (например, с тем же «Стандартом кодирования»). Зарубежный опыт (в IBM и на крупных предприятиях военно-промышленного комплекса США инспекции применяются более 20 лет, а сегодня ими все больше пользуются средние и небольшие предприятия) доказывает эффективность инспекций. Как показывает личный опыт автора, эффективность может быть еще повышена за счет применения средств автоматизации.

Заключение

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

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

Об авторе

Наталья Маркова - независимый автор. С ней можно связаться по электронной почте по адресу: markova@amsd.com

Литература

[1] Perry W. Effective Methods for Software Testing. // NY.: A Willey-QED, 1995.

[2] Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационных системах. // М.: РФФИ, 1997.

[3] Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. // М.: Символ Плюс. 1999.

[4] Маркова Н.А. Модель программного проекта. Электронный журнал «Исследовано в России», 14, 1999 г. http://zhurnal.mipt.rssi.ru/articles/1999/014.pdf

[5] Маркова Н.А. Контроль программных проектов. В сб. Системы и средства информатики. Выпуск 10, М.: Наука, 2000.

[6] Адамович И.М., Маркова Н.А. Формальные Инспекции - метод обеспечения качественного программирования. В сб. «Системы и средства информатики». Выпуск 9, М.: Наука, 1999.

Фрагмент стандарта кодирования

C1 Константы должны определяться const или enum; а не #define.

C2 Используйте символические, а не численные значения в коде.

const int Magic = 1066;

Special specialInit[Magic];