18 лекция

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

Стратегии автоматизации методологий

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

В истории развития вычислительной техники и программирования всегда уделялось внимание средствам автоматизации, с помощью кото­рых можно заменить рутинные или просто трудные виды деятельности разработчиков использованием программных инструментов. На их разра­ботку выделялись значительные ресурсы. И существенный прогресс в этой области нельзя не заметить. Применительно к обсуждаемой темати­ке мы рассмотрим, насколько этот прогресс затронул автоматизацию де­ятельности по производству программного обеспечения, или, как это можно понять из предыдущего обсуждения, в какой мере автоматизация используется для поддержки методологий. Речь идет о так называемых CASE-системах (Computer Added Software Engineering — компьютерная поддержка разработки программ), которым начиная с конца 80-х годов посвящено достаточно много публикаций (см., например, [17, 9]).

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

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

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

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

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

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

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

Замечено, что наиболее удачным оказалось использование CASE-систем в тех специальных областях, в которых уже имелся опыт техноло­гичной практической работы, пусть даже лишь на организационном уровне, а также в тех случаях, когда специальная область уже была обес­печена надежной теоретической базой. В первую очередь здесь следует упомянуть о CAS Е-системах разработки баз данных в развитых реляцион ных СУБД (к примеру, Oracle Designer 2000 в системе Oracle [20]). Успехи CASE-систем общего назначения скромнее, скорее всего, по причине от­сутствия универсальных методов, пригодных для развития любых проек­тов. Поскольку представление о модели жизненного цикла всегда являет­ся основой методологии, это еще раз подтверждает правомерность по­строения разнообразных моделей.

Сегодня универсальные CASE-системы строятся из расчета не все­общего назначения, а в рамках применения развитых, но все-таки специ­альных методологий. Несомненный прогресс в данной сфере достигнут для проектирования, ориентированного на моделирование на этапах ана­лиза и конструирования. В рамках объектно-ориентированного подхода разработан специальный унифицированный язык моделирования UML (Unified Modeling Language) [19], который рассматривается как основа проектирования в методологии итеративного наращивания возможно­стей объектно-ориентированных программных систем. На базе этого языка построен ряд CASE-систем общего назначения с весьма развитыми средствами. Наиболее заметной из них является Ration Rose фирмы Ration Software, предложившей не только инструментарий для использо­вания UML, но и, как утверждают авторы, комплексную методологию производства систем — Ration Unified Processing [50]. Данная методоло­гия претендует на охват всех аспектов современного программирования. Не уточняя, насколько эти претензии обоснованы, уместно отметить, что в качестве CASE-системы Ration Rose обладает множеством средств, очень полезных для поддержки связи первых этапов проектирования с этапом составления программ (кодирования), а также с этапом оценки. В частности, система позволяет убедиться, что моделирование на разных этапах согласовано, что модельные соглашения, определения классов, других элементов моделей и их взаимосвязи непротиворечивы. Уровень автоматического анализа высок настолько, что позволяет строить по мо­делям так называемые реализации по умолчанию. Это заготовки про­граммного кода, включающие в себя описания классов и их методов в том виде, который можно извлечь из моделей. Программист дополняет заго­товки фрагментами, детализирующими конкретную реализацию.

Построение реализации по умолчанию — не нововведение Ration Rose. Ранее оно активно применялось и в рамках систем визуального программирования, а до этого — в специализированных CASE-систе-мах, используемых, например, в развитых СУБД. Последнее примеча­тельно: именно для СУБД удалось связать реализацию по умолчанию с графическими моделями информационных систем (ER-диаграммы ~-см. [14]). В Ration Rose и других UML CASE-системах поддерживается построение реализаций по умолчанию по моделям общего, а не специ­ального назначения.

Реализация по умолчанию является лишь одним из приемов под­держки связей между этапами жизненного цикла разработки программ­ного обеспечения с использованием Ration Rose. Именно идея комп­лексной поддержки связанности рабочих продуктов разных этапов, а не отдельные приемы, которые появлялись и ранее, — главное для данной CASE-системы. Программное воплощение этой идеи, пусть даже с суще­ственными недоработками, следует отнести к явным достоинствам дан­ного инструментария. Что же касается претензий RUP на охват «всех ра­циональных технологий», то в ней больше рекламы, чем фактического результата. Предпринята попытка механического объединения средств, инструментов и методов довольно многих «рациональных» подходов, но это приводит к эклектике, а для пользователя — к нефиксированной ме­тодологии, что по сути своей означает одно — отсутствие методологии. Применяя данную систему, пользователь обязан выстроить свои регла­менты: когда, как и в каком качестве будут применяться те или иные средства, инструменты и методы. Если эти регламенты окажутся техно­логичными, то можно рассчитывать на поддержку Ration Rose, но, к со­жалению, не в части проверки принимаемых для формируемой методо­логии соглашений.

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

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

* В этом отношении есть все основания смотреть на RUP с опимизмом. После того как эта разработка стала собственностью компании IBM, потребишь в агрессивной рекламе резко снизилась. В частности по этой причине сократился поток заверений об универсальности данной методологии. Стали появляться содержательные специальные предложения о стандартизованном использовании RUP. Многие из них можно найти на сайте Rational Edge [58].

В данном курсе представлено лишь начало изучения менеджмента программных проектов, его основы. Чтобы действительно стать специа­листом в этой области, требуется еще очень многое. В [27] обсуждается обширный список навыков, необходимых для достижения компетентно­сти при управлении программными проектами, который можно рассмат­ривать как план повышения квалификации. Но и этого недостаточно. Нужно осваивать конкретные методы, методики и методологии, приме­нять их в управленческой работе в реальных проектах. Наконец, необхо­димо научиться адаптировать уже известные подходы к условиям и спе­цифике конкретных проектов, предлагать и развивать свои методики.

Хочется верить, что наш курс послужит читателю надежным ориен­тиром для уверенного движения по этому пути.

Успехов!