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

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

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

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

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

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

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

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

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

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

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

Сегодня универсальные CASE-системы строятся из расчета не всеобщего назначения, а в рамках применения развитых, но все-таки специальных методологий. Несомненный прогресс в данной сфере достигнут для проектирования, ориентированного на моделирование на этапах анализа и конструирования. В рамках объектно-ориентированного подхода разработан специальный унифицированный язык моделирования UML (Unified Modeling Language) [19], который рассматривается как основа проектирования в методологии итеративного наращивания возможностей объектно-ориентированных программных систем. На базе этого языка построен ряд CASE-систем общего назначения с весьма развитыми средствами. Наиболее заметной из них является Rational 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 не следует рассматривать как предложение универсальной технологии, которая, как было показано, недостижима. Но собрание рациональных приемов и методов да еще с основательной автоматизированной поддержкой само по себе представляет ценность: возможно построение с помощью этого решения конкретных методологий, ориентированных на наиболее подходящие для них представления о жизненном цикле. Будут ли определены вследствие таких построений стандарты и стандартные решения в области промышленного производства программного обеспечения, не столь существенно по сравнению с пользой от автоматизированного инструментария^{4В этом отношении есть все основания смотреть на RUP с оптимизмом. После того как эта разработка стала собственностью компании IBM, потребость в агрессивной рекламе резко снизилась. В частности, по этой причине сократился поток заверений об универсальности данной методологии. Стали появляться содержательные специальные предложения о стандартизованном использовании RUP. Многие из них можно найти на сайте Rational Edge [58].}.

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

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

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

Успехов!