учебники, программирование, основы, введение в,

 

Результативность программистской проектной деятельности

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

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

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

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

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

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

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

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

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

Уровни зрелости процессов разработки программного обеспечения
В организациях, претендующих на то, что их процессы разработки программного обеспечения гарантируют результативность выполнения проектов, должна быть предусмотрена возможность убедиться в этом. Иными словами, на уровень рабочих продуктов обязательно выносятся не только целевая группа, но и описания процессов в разных формах, доступных для независимого от проектной деятельности изучения.
Этот аспект замечен и зафиксирован в модели зрелости процессов разработки программного обеспечения SW-CMM (см. лекцию 5). Поскольку одной из основных целей модели является построение организационной процедуры сертификации организаций, разрабатывающих программное обеспечение, она исходит из стандартизованной классификации организаций, распределения их по нескольким уровням. На каждом из уровней в принципе может достигаться определенная результативность проектов, отслеживание которой - задача специальной деятельности, обеспечивающей процедуру сертификации достоверной информацией. Исходным материалом для этой деятельности являются все рабочие продукты проектов, в частности документы, отражающие процесс развития и контроля реализации проекта. Ее основной сертификационный результат - отнесение организации к одному из пяти уровней зрелости:

  1. Начальный (initial) уровень. Находясь на начальном уровне, организация обычно не может обеспечить устойчивый процесс разработки и сопровождения программного обеспечения. В организации отсутствует культура управления, из-за неэффективного планирования и плохого согласования работ продуктивность производственного процесса непредсказуема. Успешные проекты возможны, но как рабочие продукты оформляются лишь результаты целевой группы.
  2. Повторяемый (repeatable) уровень. На этом уровне планирование и управление новым проектом базируются на опыте работы с подобными проектами. Характерным качеством ведения проектов на повторяемом уровне является возможность воспроизведения успешных практик прежних проектов. Если в организации как рабочие продукты оформляются лишь результаты целевой группы, то единственная возможность для такого воспроизведения - это назначение на новые проекты менеджеров, которые уже хорошо зарекомендовали себя в предыдущих проектах. Это тот случай, когда процессы развития проекта и наблюдения группы не отражаются в рабочих продуктах, а представлены лишь в фольклорном варианте. Осознание неустойчивости такого положения приводит к стремлению все более точно фиксировать опыт документально. Иными словами, повторяемый уровень диктует необходимость формирования рабочих продуктов для каждой группы.
  3. Определенный (defined) уровень, или уровень становления. На этом уровне в организации принят стандарт проведения разработки и сопровождения программного обеспечения, в рамках которого обеспечена интеграция процессов построения и управления. Разработка и сопровождение полностью документированы, что позволяет организовать наблюдение и контроль выполнения проектов. В материалах CMM такой стандарт называется стандартным производственным процессом организации. Для конкретных проектов стандартный производственный процесс адаптируется с целью учета его особенностей, в результате чего определяются критерии готовности, качества и т.д., а также механизмы контроля. За счет ясной определенности процессов руководство организации получает точную картину развития проектов. Продуктивность производственного процесса на определенном уровне характеризуется как стандартная и согласованная. На этом уровне к рабочим продуктам каждой из групп предъявляются дополнительные требования: они должны быть представлены таким образом, чтобы специфика проекта явно отделялась от стандартизованного содержания, то есть чтобы при производстве рабочих продуктов максимально повышалась возможность их независимого от проекта применения.
  4. Управляемый (managed) уровень. Согласно CMM, этот уровень характеризуется внедрением в организацию количественных показателей качества как для программных продуктов, так и для процессов их разработки. Производственные процессы управляемого уровня оснащены средствами для проведения четко определенных и согласованных измерений. Продуктивность производственного процесса на управляемом уровне характеризуется как предсказуемая, так как процесс функционирует в заданных и измеряемых пределах. Иначе говоря, предполагается, что за счет количественных показателей качества удается организовать наблюдение за любой проектной деятельностью, которое позволяет удерживать траекторию в области допустимости. Дополнительные требования к рабочим продуктам этого уровня заключаются в том, что конкретизируется и получает статус обязательного стандарта группа продуктов, отражающих измерения и наблюдение за проектом.
  5. Оптимизирующий (optimizing) уровень. Работа над проектами ведется как на управляемом уровне, но организация в целом сосредоточена на усовершенствовании производственного процесса. Она обладает средствами выявления слабых мест процесса и его улучшения с целью предотвращения дефектов. Внедряются новшества, использующие передовые методы программной инженерии, которые распространяются для улучшения качества разработок всех проектов. В рамках оптимизационного уровня налажены механизмы оценки не только выполненных проектов (это идет от предыдущего уровня), но и возможных новаций во всех аспектах проектирования. Таким образом, ассортимент используемых рабочих продуктов не ограничивается тем, что появляется по ходу выполнения целевых проектов. Необходимые для оптимизирующего уровня продукты могут разрабатываться специально. Несколько иронично оптимизирующий уровень иногда называют "нирваной проектной деятельности".

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

  • Искушение распространения удачного опыта за пределы его области применимости.

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

  • Многие методы просто противоречивы и при их объединении в одной методике вместо ожидаемого дополнения достоинств происходит их нейтрализация и пышным цветом расцветают недостатки объединяемых методов.

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

  • Третья проблема может быть охарактеризована как груз стандартов.

Суть ее в том, что по мере развития методических предложений и рекомендаций и превращения их в стандартизованные предписания, которые нужно выполнять неукоснительно, появляется все больше обязательных требований к процессу ведения проекта.
Если бы программирование можно было рассматривать как императивную деятельность, то обязательность требований к процессу была бы вполне мотивирована. Однако, как мы уже отмечали в разделе "Жесткие и гибкие стратегии в методологиях программирования" лекции 5, креативность процесса разработки программ делает эту мотивацию несостоятельной. Обязательные требования к процессу не дают преимуществ, а лишь усложняют его, делая "монументальным", громоздким и негибким. Естественная реакция на такое положение - отказ от тяжеловесных стандартов - отражена в концепциях быстрых методологий, зафиксированных в Agile Manifesto .
Движение по лестнице уровней зрелости при беглом взгляде выглядит замечательно: на каждом шаге результативность проектов повышается, за счет внедрения регулярных методов растут управляемость и качество производственного процесса. Однако какая результативность здесь имеется в виду? Не оказывается ли стремление к CMM-овской зрелости самоцелью, уводящей в сторону от основного предназначения программистской деятельности, т.е. от максимально полного обеспечения пользователей средствами автоматизации для решения их проблем? В самом деле, все продукты, не относящиеся к целевой группе, не имеют прямого отношения к этому предназначению, а потому говорить о росте результативности за счет механического роста числа подготавливаемых рабочих продуктов по меньшей мере наивно. Но даже если предположить, что при использовании "прогрессивных" методологий растет качество целевых продуктов, необходимо ответить на вопрос, какой ценой достигается такой рост? Не слишком ли расточи тельно для организации расходовать средства лишь на то, чтобы соответствовать какому-то формальному уровню? По-видимому, сферой адекватного применения обсуждаемого подхода является серийное производство однотипных продуктов, когда накладные расходы на инфраструктуру поддержки методологии раскладываются по целевым продуктам серии, разработка каждого из которых, быть может, оказывается и более качественной, и более скорой.

Стратегии автоматизации методологий
Утверждение о принципиальной невозможности построения технологий для креативных видов деятельности не следует рассматривать как отказ от разработки для них технологической поддержки. Более того, она просто необходима, чтобы избавить разработчиков от рутинных операций и обеспечить им комфортные условия для творчества. Иными словами, необходима автоматизация методологий программирования, что следует понимать лишь как применение инструментов поддержки проектной деятельности без претензий на технологию проектирования. Тем самым мы просто указываем, какое место должны занимать инструменты, и лишаем иллюзий тех, кто считает, что с помощью некой "совершенной" системы поддержки можно решить "все проблемы".
В истории развития вычислительной техники и программирования всегда уделялось внимание средствам автоматизации, с помощью которых можно заменить рутинные или просто трудные виды деятельности разработчиков использованием программных инструментов. На их разработку выделялись значительные ресурсы. И существенный прогресс в этой области нельзя не заметить. Применительно к обсуждаемой тематике мы рассмотрим, насколько этот прогресс затронул автоматизацию деятельности по производству программного обеспечения, или, как это можно понять из предыдущего обсуждения, в какой мере автоматизация используется для поддержки методологий. Речь идет о так называемых CASE-системах (Computer Added Software Engineering - компьютерная поддержка разработки программ), которым начиная с конца 80-х годов посвящено достаточно много публикаций .
Сначала мы дадим эскиз процесса формирования произвольного автоматизированного технологичного производства, а затем спроецируем его на процесс технологизации производства программного обеспечения (но не технологии этого производства!). Заметим, что в этой области есть своя специфика, но она не столь значительна, чтобы считать данное производство чем-то исключительным.
Первый шаг на пути автоматизации любого производства, и в частности производства программ, - систематизация. Следующие шаги - определение операционных маршрутов деятельности работников производства, выявление узких мест, доступных для автоматизации, и разработка инструментов для них. Далее процесс развивается вширь и вглубь: охватываются автоматизацией другие части операционных маршрутов, совершенствуются ранее созданные инструменты, разрабатываются методы их эффективного применения. Последнее означает формирование новых методик, и, как следствие, появляется потребность в автоматизации новых видов деятельности, обусловленных ими. Наконец, наступает момент, когда совокупность потребностей в автоматизации разного рода деятельностей, связанных, хотя и не обязательно напрямую, с первоначальной систематизацией, формирует качественно иную потребность в комплексной автоматизации. Это время появления стандартов и стандартных решений, интеграции сложившихся методик и доработка того, что не вписывается в интегра льную схему.
Первая стадия автоматизации программирования связана с поддержкой этапа программирования жизненного цикла. Здесь проявляется и специфика: систематизация работ по производству программного обеспечения осуществлялась после осознания того, что поддержка кодирования, хотя и способствует росту производительности труда, не является достаточной для промышленного конструирования программ. Появление на этой стадии систем программирования и всевозможных средств помощи в наборе текстов предшествовало периоду, когда начинали внедряться разного рода отладочные средства. Именно в это время (к концу шестидесятых годов) в ответ на потребность в разработке больших и сложных программ было сформулировано понятие жизненного цикла.
Сразу же обнаружилось узкое место программирования как производства: неразвитость методологий этапа конструирования, с одной стороны, а с другой - невозможность сведения оценочных работ к тестированию. По существу, это две стороны одной медали: нечеткость постановок задач для программирования влечет за собой большую часть трудностей этапа проверки. В результате сформулированной потребности в строгих спецификациях проекта появилось осознание того, что этап конструирования может быть регламентирован вполне технологично. И удачные организационные методологии стали появляться. Чаще это были специализированные методологии, предназначенные для разработки программ особого рода, но иногда и общие методологии, некоторые из них впоследствии стали автоматизированными (в качестве конкретного примера из этого ряда уместно указать на IDEF-технологию ). Позднее стали формироваться регламентирующие методики работы с требованиями на этапе анализа. И хотя формализованных технологических процедур, допускающих полные автоматические проверки, в аналитической части добиться так и не удалось (что косвенно свидетельствует об утопичности такой постановки задачи), прогресс налицо: сегодня можно говорить о поддержке накопления первичных требований и их систематизации, об отслеживании связей между требованиями и их реализациями в проекте и т.д.
Понятно, что описанный процесс не столь прямолинеен. В огромной мере на него повлияли языкотворчество и тщетные надежды на то, что появление очередного "самого хорошего" языка приведет к "решению всех проблем". Для становления регулярных процессов производственного программирования наиболее заметными оказались методологии структурного и объектно-ориентированного программирования. Первая из них позволила осознать ограниченность способностей человека, необходимых при составлении больших программ, вторая дала толчок к разработке методов декомпозиции, приспособленных для преодоления сложности. Объектно-ориентированное программирование привело к необходимости модернизации основополагающих принципов проектирования программ, и в частности к новому толкованию понятия жизненного цикла (см. лекцию 9).
Но несмотря на это, стадия комплексной автоматизации методологий программирования стала возможной только при соответствующем уровне развития техники, который позволил эффективно применять выразительные графические возможности при выполнении процедур конструирования программного обеспечения. Немаловажным обстоятельством, позволившим перейти к комплексной автоматизации, стало осознание того, что нельзя говорить о промышленном программировании без поддержки производственных функций на всех этапах жизненного цикла программ. Примерно в начале девяностых годов появился термин "CASE-технологии", которым стали обозначать использование систем, обладающих комплексными автоматизированными средствами поддержки разработки и сопровождения программ.
Замечено, что наиболее удачным оказалось использование CASE-систем в тех специальных областях, в которых уже имелся опыт технологичной практической работы, пусть даже лишь на организационном уровне, а также в тех случаях, когда специальная область уже была обеспечена надежной теоретической базой. В первую очередь здесь следует упомянуть о CASE-системах разработки баз данных в развитых реляционных СУБД (к примеру, Oracle Designer 2000 в системе Oracle ). Успехи CASE-систем общего назначения скромнее, скорее всего, по причине отсутствия универсальных методов, пригодных для развития любых проектов. Поскольку представление о модели жизненного цикла всегда является основой методологии, это еще раз подтверждает правомерность построения разнообразных моделей.
Сегодня универсальные CASE-системы строятся из расчета не всеобщего назначения, а в рамках применения развитых, но все-таки специальных методологий. Несомненный прогресс в данной сфере достигнут для проектирования, ориентированного на моделирование на этапах анализа и конструирования. В рамках объектно-ориентированного подхода разработан специальный унифицированный язык моделирования UML (Unified Modeling Language) который рассматривается как основа проектирования в методологии итеративного наращивания возможностей объектно-ориентированных программных систем. На базе этого языка построен ряд CASE-систем общего назначения с весьма развитыми средствами. Наиболее заметной из них является Ration Rose фирмы Ration Software, предложившей не только инструментарий для использования UML, но и, как утверждают авторы, комплексную методологию производства систем - Ration Unified Processing . Данная методология претендует на охват всех аспектов современного программирования. Не уточняя, насколько эти претензии обоснованы, уместно отметить, что в качестве CASE-системы Ration Rose обладает множеством средств, очень полезных для поддержки связи первых этапов проектирования с этапом составления программ (кодирования), а также с этапом оценки. В частности, система позволяет убедиться, что моделирование на разных этапах согласовано, что модельные соглашения, определения классов, других элементов моделей и их взаимосвязи непротиворечивы. Уровень автоматического анализа высок настолько, что позволяет строить по моделям так называемые реализации по умолчанию. Это заготовки программного кода, включающие в себя описания классов и их методов в том виде, который можно извлечь из моделей. Программист дополняет заготовки фрагментами, детализирующими конкретную реализацию.
Построение реализации по умолчанию - не нововведение Ration Rose. Ранее оно активно применялось и в рамках систем визуального программирования, а до этого - в специализированных CASE-системах, используемых, например, в развитых СУБД. Последнее примечательно: именно для СУБД удалось связать реализацию по умолчанию с графическими моделями информационных систем (ER-диаграммы - см. ). В Ration Rose и других UML CASE-системах поддерживается построение реализаций по умолчанию по моделям общего, а не специального назначения.
Реализация по умолчанию является лишь одним из приемов поддержки связей между этапами жизненного цикла разработки программного обеспечения с использованием Ration Rose. Именно идея комплексной поддержки связанности рабочих продуктов разных этапов, а не отдельные приемы, которые появлялись и ранее, - главное для данной CASE-системы. Программное воплощение этой идеи, пусть даже с существенными недоработками, следует отнести к явным достоинствам данного инструментария. Что же касается претензий RUP на охват "всех рациональных технологий", то в ней больше рекламы, чем фактического результата. Предпринята попытка механического объединения средств, инструментов и методов довольно многих "рациональных" подходов, но это приводит к эклектике, а для пользователя - к нефиксированной методологии, что по сути своей означает одно - отсутствие методологии. Применяя данную систему, пользователь обязан выстроить свои регламенты: когда, как и в каком качестве будут применяться те или иные средства, инструменты и методы. Если эти регламенты окажутся технологичными, то можно рассчитывать на поддержку Ration Rose, но, к сожалению, не в части проверки принимаемых для формируемой методологии соглашений.
Претензии на всеобщность RUP не следует рассматривать как предложение универсальной технологии, которая, как было показано, недостижима. Но собрание рациональных приемов и методов да еще с основательной автоматизированной поддержкой само по себе представляет ценность: возможно построение с помощью этого решения конкретных методологий, ориентированных на наиболее подходящие для них представления о жизненном цикле. Будут ли определены вследствие таких построений стандарты и стандартные решения в области промышленного производства программного обеспечения, не столь существенно по сравнению с пользой от автоматизированного инструментария.
Вернемся к тезису о том, что результативность связывает все стороны деятельности менеджера проекта, целью которой можно считать повышение результативности выполнения проекта. Действительно, менеджер заинтересован в том, чтобы выполняемый им проект выглядел со всех сторон привлекательным. Поэтому он должен заботиться и о выпуске рабочих продуктов, представляющих все результаты проектной деятельности для внешнего использования, и о получении сертификатов для команды, удостоверяющих ее квалификацию, и о повышении уровня автоматизации проектной деятельности во всех ее аспектах. Но все это требует затрат, которые нельзя, да и невозможно, перекладывать на плечи заказчика. Соответствующие затраты вполне может взять на себя организация, которая, как и менеджер, а быть может, и в большей степени, заинтересована в хорошей репутации. Однако погоня за репутацией может стать и, как показывает практика, часто становится самоцелью. Чтобы этого избежать, необходимо как минимум соблюдать баланс между основными и соп утствующими целями проектной деятельности. Но для действительно рационального баланса необходимы знания и опыт менеджера как специалиста. Он должен уметь оценивать и взвешивать варианты, отсекать не относящиеся к делу наслоения от действительно ценного.
В данном курсе представлено лишь начало изучения менеджмента программных проектов, его основы. Чтобы действительно стать специалистом в этой области, требуется еще очень многое. В обсуждается обширный список навыков, необходимых для достижения компетентности при управлении программными проектами, который можно рассматривать как план повышения квалификации. Но и этого недостаточно. Нужно осваивать конкретные методы, методики и методологии, применять их в управленческой работе в реальных проектах. Наконец, необходимо научиться адаптировать уже известные подходы к условиям и специфике конкретных проектов, предлагать и развивать свои методики.
Хочется верить, что наш курс послужит читателю надежным ориентиром для уверенного движения по этому пути.
Успехов!

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика