РАБОЧИЕ ПРОДУКТЫ, ИСПОЛЬЗУЕМЫЕ НА ПРАКТИКЕ

РАБОЧИЕ ПРОДУКТЫ, ИСПОЛЬЗУЕМЫЕ НА ПРАКТИКЕ

Традиционный подход, при котором разработка документации являлась определяющей, приводил к пустой трате невероятного количества рабочего времени на создание, редактирование, чтение, обновление и распространение документов. Почему? Есть несколько причин, обуславливающих важность таких документов для процесса. Во-первых, не существовало строгих методов разработки и языков для спецификации требований и проектирования. Следовательно, стандартным форматом являлся бумажный документ со специализированным текстом и графическими схемами. Во-вторых, традиционные языки, использовавшиеся на этапах реализации и внедрения, были малопонятны и плохо структурированы. Для того чтобы передать подробную структуру и поведение ПО другим заинтересованным сторонам (тем, кто тестирует, сопровождает, управляет), требовался формат, более пригодный для чтения человеком. Возможно, наиболее важной была необходимость «заслуживающей доверия» оценки достижений в области ПО. Документы являли собой осязаемый, но порождающий ошибки механизм демонстрации достижений.
В некоторых областях подходы с преобладающей разработкой документации за последние 30 лет превратились в основное препятствие на пути совершенствования процесса. Качество документов стало более важным, чем качество представляемых ими результатов, А оценка качества человеком, читающим абстрактные описания, — процесс весьма субъективный. Много усилий тратилось на оценку одномерных проблем, лежащих на поверхности, и мало внимания уделялось многомерным проблемам, которые определяют такие качества архитектуры, как производительность и адаптируемость.
Циклы создания документов, их анализа и обновления приводили к появлению зримых и формальных свидетельств движения по графику, создавая тем самым зависимость от графика работ и числа точек синхронизации. Например, следующий сценарий являлся не таким уж необычным для больших оборонных проектов: сначала тратился месяц на подготовку проектного документа, потом документ передавался заказчику и приходилось ждать еще месяц, чтобы получить комментарии к этому документу, после чего еще месяц тратился на написание ответа на эти комментарии и на внесение изменений. При наличии большого числа многомесячных циклов по работе с документами, которыми приходилось управлять и которые приходилось расписывать и синхронизировать, нет.
ничего удивительного в том, что жизненный цикл разработки проектов растягивался на пять лет. Длинные и очень подробные документы, которые обычно воспринимались как средство демонстрации очередных достижений, приводили к преждевременному рассмотрению деталей работы и к увеличению числа отбраковок и переделок на более поздних стадиях жизненного цикла.
Более эффективным подходом является переориентация усилий, направленных на работу с документами, на увеличение строгости и понятности источников информации и на обеспечение просмотра в онлайновом режиме естественного источника информации посредством использования более совершенных поисковых и навигационных инструментов. Такой подход приводит к исключению из процесса огромного числа непродуктивных отбраковок и переделок и позволяет постоянно участвовать в работе всем тем, кто имеет непосредственное отношение к рабочим продуктам.
Эта философия приводит к возникновению следующих проблем:.
■ Люди заинтересованы в анализе информации, но не понимают языка рабочих продуктов. Многие из заинтересованных лиц будут сопротивляться необходимости изучения того профессионального языка, на котором изложены продукты. Нередко можно встретить людей (например, менеджеров-ветеранов, опытных специалистов в области качества или проверяющих из регулирующего органа), чья реакция будет следующей: «Я не собираюсь учить UML, но я хочу познакомиться с проектом этого ПО, поэтому подготовьте мне отдельное описание в виде диаграмм и текста, которое будет мне понятно». Будем ли мы реагировать на аналогичное требование того, кто изучает чертежи здания? Нет. Мы потребуем, чтобы тот, кто изучает чертежи, был знаком с инженерной системой обозначений. Точно так же мы должны прекратить опекать публику, которая отказывается рассматривать программирование как инженерную дисциплину. Такие заинтересованные стороны обычно приводят к повышению стоимости и сроков проекта, не увеличивая его ценности.
■ Люди хотят ознакомиться с информацией, но не имеют доступа к необходимым инструментам. Нередко бывает так, что организация-разработчик не обеспечена всеми необходимыми инструментами; еще реже заинтересованные стороны имеют какую-либо возможность для знакомства с материалами в онлайновом режиме. Следовательно, организации вынуждены обмениваться бумажными документами. Стандартные форматы (такие, как UML, электронные таблицы, Visual Basic, C++ и Ada 95), инструментарий для визуализации и Web делают электронный обмен информации между всеми участниками экономически оправданным. Подход к рабочим продуктам — это единственная область, в которой оптимальный процесс разработки ПО может быть нарушен в том случае, если философия процесса принимается не всеми его участниками.
■ Рабочие продукты, предназначенные для просмотра человеком, должны использовать строгие нотации, которые являются полными, непротиворечивыми и самодокументируемыми. Для всех идентификаторов и определений должны использоваться правильные английские слова. Акронимы и аббревиатуры следует применять только там, где этот жаргон является общепринятым в контексте использования компонентов. Независимо от того, какие применяются языки и инструменты, нет смысла сокращать или зашифровывать исходные идентификаторы языков программирования и моделирования. Уменьшение числа нажатий клавиш за счет использования сокращений может, конечно, упростить труд автора рабочих продуктов, но приведет к появлению ошибок на остальных стадиях жизненного цикла. Запрещение такой практики даст выигрыш и в производительности, и в качестве. ПО пишется только один раз, но читается много раз. Следовательно, необходимо уделять особое внимание удобочитаемости и требовать использования правильных английских слов во всех рабочих продуктах. Такая практика позволяет получать понятные представления, удобные для просмотра форматы («безбумажное» рассмотрение), нотации повышенной строгости и снижение количества ошибок.
■ Полезная документация самодостаточна: это документация, которая используется. Кроме всего прочего, создание самодокументируемых рабочих продуктов дает организации-разработчику «право» работать исключительно со строгими нотациями и избегать создания отдельных документов для описания всех деталей модели, компонента или процедуры тестирования. Если обнаружится, что некоторая информация, в частности какой-либо документ, создается, но не используется, следует отказаться от нее в пользу той, что реально применяется для достижения желаемой цели. Старайтесь улучшить ее самодокументируемость.
■ Бумага осязаема; электронные материалы слишком легко изменить. Одна из причин, по которой некоторые участники предпочитают бумажные документы, заключается в том, что после того, как бумаги получены, они становятся осязаемыми, постоянными и неизменными. Рабочие продукты, доступные в онлайновом режиме и в Web, могут быть легко изменены и потому рассматриваются с большим скептицизмом. Электронные материалы должны и будут приветствоваться многими участниками проекта, переход всего мира на такую работу — вопрос времени. Преимущества оказываются существенными и глубокими во многих областях. Все смогут убедиться, что инструментарий и среда будут развиваться в направлении поддержки управления изменениями, системных журналов, электронных подписей и других преимуществ групповой работы, так что электронный обмен информацией заменит бумажный.
Чрезвычайно важно, чтобы основное внимание уделялось информации, содержащейся в рабочих продуктах, а не бумаге. Краткие документы обычно более полезны, чем длинные. Главный продукт — это ПО; документация является всего лишь вспомогательным материалом.
Архитектура ПО является центральной проблемой при разработке сложных программных систем точно так же, как архитектура здания является центральной проблемой для небоскреба. Однако архитектура ПО имеет несколько дополнительных параметров сложности. В отличие от архитектуры большого здания, критичные параметры производительности и функциональные возможности сложной программной системы не могут быть описаны с помощью устоявшихся физических законов. Они не описываются и какими бы то ни было общепринятыми математическими формулами. Таким образом, у архитекторов ПО отсутствуют основные неопровержимые принципы. Существует много эвристических подходов и расплывчатых указаний, однако фундаментальные единицы измерения того, что такое хорошо, сильно зависят от конкретной ситуации. Поскольку устоявшейся теории нет, архитекторы ПО вынуждены полагаться на проведение всякого рода экспериментов при попытке сформулировать архитектуру ПО. Это является одной из причин перехода к итерационному процессу, при котором на ранних стадиях уделяется особое внимание и стимулируется эволюция архитектуры посредством создания прототипов и демонстраций.
Ключевые моменты.
▲ Архитектура — это проект программной системы.
А Единственной целью стадии разработки является получение устойчивой базовой архитектуры.
А. Базовая архитектура — не бумажный документ; это некоторая совокупность информации, пронизывающая всю разработку системы.
А. Архитектура описывается посредством извлечения существенной информации из проектных моделей.
В предыдущих главах содержится много рассуждений по поводу архитектуры, но не дано определение этого термина. В индустрии ПО общепринятое определение архитектуры также отсутствует. В настоящей главе собраны некоторые точки зрения на архитектуру и строится контекст, в котором могли бы стать понятными принципы управления процессом с упреждающей разработкой архитектуры.
Поскольку ранние программные системы были менее мощными, чем современные системы, их архитектуры были намного проще и для них было достаточно неформального представления. В системе, состоящей из одной программы, выполняющейся на одном компьютере, соответствие между объектами разработки, объектами реализации и объектами внедрения было тривиальным. В современных сложных программных системах нам приходится применять множество различных моделей и представлений для того, чтобы иметь возможность воспользоваться преимуществами современных технологий, таких как коммерческие компоненты, объектно-ориентированные методы, открытые системы, распределенные системы, среда разработки и среда выполнения, современные языки. Модель — это относительно независимое абстрактное представление системы. Представление (view) — это часть модели, которая позволяет описать какую-либо конкретную, относящуюся к делу точку зрения.

Популярные статьи

Свежие статьи