Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/04h4180.shtml

Глава 18. Синергическое заключение

Идеи правят миром, так же как деньги, власть и секс,
Джон Форбс Нэш мл., математик
и лауреат Нобелевской премии по экономике,
из его биографии “A Beautiful Mind”,
написанной Сильвией Наса

       Пытаясь создать целостный образ из различных граней творчества в программировании, освещаемых в этой книге, я вдруг заметил нечто удивительное. Я начал ощущать синергию: образ стал превращаться в нечто большее, чем просто сумма отдельных частей книги.
       Когда я пересматривал материал, у меня в голове зазвучало несколько тем. Вот тема Джеффа Оффута, который запирает свою лабораторию, забывает все формальные методы, которым только что учил студентов, и выбирает вместо этого творческие решения ad hoc.
       Вот тема Дэвида Парнаса, признающегося в том, что нисходящая разработка на самом деле просто невозможна, и призывающего “подделывать” итоговую документацию.
       Вот тема Билла Кертиса, предполагающего найти в разработке сбалансированное и управляемое развитие и в конце концов приходящего к противоположному выводу о том, что разработка является оппортунистическим процессом.
       Вот тема Дугласа Кинга, цитирующего слова Херба Саймона о том, что решать хорошо понятые задачи с помощью формальных методов — совсем не то же самое, что решать малопонятные задачи с помощью слабо структурированных эвристических методов.
       Вот тема Брюса Блюма, сообщившего нам, что оптимизировать процесс ради удовольствия можно было тогда, когда задачи были маленькими, а стремление к качеству основывалось на личных представлениях, и что оптимизировать процесс для совместимости с поэтапной моделью допустимо только при наличии твердых и устойчивых требований.
       Среди всех этих тем я начинаю различать одну общую. По некотором размышлении я готов описать ее следующим образом.
       В нашем академическом мире создание программного обеспечения воспринимают как некий монолит. Мы придумываем и пропагандируем методы, языки, компьютеры и инструменты, которые должны быть пригодны на все случаи жизни. От каждой новой методологии мы ждем решения задач всех типов. Мы создаем модель проверки процесса, ожидая, что она будет применима для всех программных проектов.
       Думаю, все эти темы дают основания для вывода о том, что поиск универсального подхода — это ошибка. Даже еще хуже. Это ОШИБКА! Нам необходимо начать учитывать в программных разработках их индивидуальную природу, соответственно управляя разработкой и решая задачу.
       Эта мысль не была для меня совершенно новой. Ранее я уже несколько раз исследовал зависимость методов решения от предметной области и понял, что разные области требуют различных методов — в значительно большей степени, чем мы это себе представляем. Но все эти мысли хранились в моей голове отдельно как тема другой серии очерков и статей, и я не сразу заметил их близость к проблеме творчества в программировании.
       Я также провел некоторое исследование таких аспектов программных проектов, как размер и критичность. Например, в приложениях моей книги “Building Quality Software” (Разработка качественного программного обеспечения), Prentice-Hall приведены рекомендации по методам создания качественных решений исходя из размера и критичности конкретного проекта.
       Однако из этих творческих тем возникает целый новый аспект — “новизна решаемой задачи”. Один умный автор за другим, каждый по-своему, говорят о том, что “чем более новаторские задачи встают перед нами, тем менее эффективны формальные методы” и что “строгие методы нужно хотя бы дополнять творческими, когда задачи требуют больших умственных усилий”.
       Я стал искать какой-нибудь важный критерий для представления программных проектов. Ясно, скажем, что размер проекта играет важную роль при выборе технологий для решения. Точно так же ясно, что критичность проекта играет такую же роль. Короче говоря, методы, применяемые для решения задач в программировании, зависят от множества аспектов.
       Нужно учесть, что мои поиски начались как раз в то время, когда институт SEI стал пропагандировать модель зрелости процесса (СММ) и пятиуровневую систему оценки зрелости управления, которые предлагались для всех программных проектов без разбора. В это же самое время для применения во всех проектах рекламировались все новые формальные методы и методологии, предлагаемые компьютерными науками или коммерческими организациями.
       Думаю, что через несколько лет выстраданные догадки, о которых я сейчас пишу, будут восприниматься как нечто очевидное. Но в ту эпоху, когда я извлекал эти идеи из комментариев своих коллег, они, конечно, выглядели радикальными.
       Что я пытаюсь сказать? То, что при оценке пригодности каждого нового метода разработки программного обеспечения должны учитываться несколько аспектов проекта:
       — Характер и требования предметной области
       — Масштабы проекта
       — Критичность решения
       — Новизна задачи
       Возможно, есть и другие аспекты — вопрос не закрыт. Например, кандидатами на включение в список могут быть знания/стиль руководителей проекта или качество/возможности технических сотрудников.
       Интересно отметить, что эти кандидаты возникают при выборе методов, ориентированных на организацию, а не на проект. Эта мысль интересно разработана в [Constantine 1993], где предлагаются организационные парадигмы для разных типов проектов:
       — Замкнутый (традиционная иерархическая организация — Константин говорит, что такой подход хорош для “стандартных, тактических проектов”)
       — Случайный (на основе независимой новаторской инициативы — Константин считает этот подход лучшим для проектов, требующих “творческого прорыва”)
       — Открытый (адаптивный, совместный — лучше всего для “решения сложных задач”)
       — Синхронный (эффективное гармоничное регулирование — лучше всего для “повторяющегося, критического исполнения”)
       [Hyman 1993] содержит прекрасные конкретные случаи применения некоторых из этих концепций.
       Но задержимся на некоторое время на тех подходах к проекту, которые учитывают его особенности.
       Попробуем оценить разные темы из части I книги по каждому из следующих аспектов.
       Дисциплина. Строгая дисциплина необходима для сверхкрупных или сверхкритичных проектов. В других проектах ее значение меньше.
       Формальные методы. Формализм уместен в малых проектах (возможно, что и в крупных, но нужны дополнительные исследования); мы не знаем пока, важен ли он для критичных проектов, хотя многие в этом уверены; главное, что он применим только в проектах, новизна задач в которых невелика. Для сложных проектов более эффективными оказываются эвристические методы. (К примеру, Реттиг и Саймоне придерживаются мнения, что для сложных задач лучше всего подходит “итеративная стратегия”, включающая в себя методы “разделяй и властвуй”, спиральный жизненный цикл, объектную технологию, быстрое создание прототипов и инкрементное тестирование [Rettig and Simons 1993].)
       Оптимизирующие решения. Оптимизация возможна только в малых проектах. Она относительно независима от критичности проекта (хотелось бы получать оптимальные решения для критичных проектов, но это невозможно) или с новизной задач.
       Количественные рассуждения. Несмотря на то что количественные методы желательны, по всей видимости, они применимы только в относительно небольших и не отличающихся новизной проектах.
       Процесс. Вероятно, процесс должен идти рука об руку с дисциплиной. То есть, чем больше потребность в дисциплине, тем большая необходимость определить процесс, для которого будет установлена дисциплина. См. выше обсуждение дисциплины.
       Интеллектуальные, творческие задачи. Потребность в интеллектуальных и творческих методах пропорциональна размеру проекта, критичности решения и в особенности новизне задачи.
       Увлекательность. Значение увлекательности, видимо, обратно значению дисциплины. То есть чаще всего оно ощущается в небольших проектах, которые не критичны, но содержат задачи, отличающиеся хоть какой-то степенью новизны.
       Тут у нас возникает проблема. Все перечисленное потребовало многих слов для описания. А слова могут затуманить простоту основной идеи. Я попытался изобразить взаимодействие этих аспектов и проблем творчества простым графиком, но мне это не удалось. Поэтому, прежде чем идти дальше, хочу еще раз подчеркнуть основную мысль:
       Подход с одной меркой ко всем задачам и решениям в программировании мешает заметить некоторые важные вещи. Эти важные вещи помогают определить, когда определенные методы решения действуют хорошо, а когда — плохо. Такие разрекламированные подходы, как дисциплина, формализм и установленный процесс, предлагаемые для всех проектов без учета их специфики, могут применяться только для определенной группы задач. Необходимо начать обсуждение того, в каких случаях применим (а еще важнее — когда не применим) каждый подход. Данный раздел может послужить началом такой дискуссии.
       В области человеческих отношений, особенно когда речь заходит о гражданских правах, часто “восхваляются различия” между людьми. Имеется в виду, что расовые, половые, религиозные и некоторые другие важные различия должны уважаться и изучаться, а не вызывать страх или отторжение. Пора и в компьютерном сообществе начать уважать различия. И обсуждавшиеся выше аспекты — предметная область, размер проекта, критичность решения, оригинальность задачи — устанавливают те типы различий, которые в области компьютеров и программирования нужно начать понимать — и уважать.

Ссылки
       CONSTANTINE 1993—-“Work Organization: Paradigms for Project Management and Organization”, Communications of the ACM, Oct. 1993; Larry L. Constantine.
       Hyman 1993—“Creative Chaos in High-Performance Teams: An Experience Report”, Communication of the ACM, Oct. 1993; Risa B.Hyman.
       Rettig and Simons 1993—“A Project Planning and Development Process for Small Teams”, Communications of the ACM, Oct. 1993; Marc Rettig and Gary Simons.




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/04h4180.shtml