| 19 февраля 2013 |
- Название анти-паттерна: Аналитический паралич
- Также известен как: Каскад, Несогласованный процесс
- Уровень, на котором чаще всего встречается: Системный
- Название решения, направленного на улучшение: Итеративный инкрементный подход к разработке ПО
- Тип решения, направленного на улучшение: Программное обеспечение
- Основные причины: Гордыня, ограниченность
- Неуравновешенные силы: Управление сложностью
- Примеры из жизни:
"Нам необходимо переделать объектно-ориентированный анализ, чтобы сделать его более объектно-ориентированным, уделив больше внимания наследованию". "Нам необходимо завершить объектно-ориентированный анализ и дизайн, прежде чем мы вообще начнем кодировать". "Хорошо, а если пользователю захочется создать список сотрудников на основе четвертых и пятых букв их имени, в сочетании с проектами, которым они уделили больше всего рабочих часов между Днем благодарения и Днем памяти за четыре предыдущих года?" "Если вы будете относиться к каждому атрибуту объекта как к объекту, вы можете повторно использовать форматирование поля между неродственными классами".
Предпосылки
Аналитический Паралич - один из классических анти-паттернов объектно-ориентированной разработки программного обеспечения. Объектно-ориентированный анализ направлен на то, чтобы разложить проблему на составляющие. Но нет прямого метода для определения точного уровня детализации, необходимого для разработки системы. Зачастую основное внимание переключается с разложения на составляющие до того уровня, на котором проблему легко поймут разработчики, на применение этого метода, чтобы достичь мифической "полноты освещения вопроса".
Системные разработчики также нередко становятся жертвами Аналитического Паралича, потому что "решение никогда не бывает неудачным, неудачным бывает только его воплощение". Продлевая периоды анализа и разработки, они избегают риска нести ответственность за результаты. Конечно, эта стратегия обречена на неудачу, потому что обычно все-таки наступает такой момент, когда необходимо предъявить работающую разработку.
Общая форма
Аналитический Паралич случается в тех случаях, когда цель состоит в достижении совершенства и полной завершенности периода анализа. Этот анти-паттерн характеризуется хождением по кругу, пересмотром моделей и созданием детальных моделей, что мешает рабочему процессу.
Многие разработчики, впервые столкнувшиеся с объектно-ориентированными методами, уделяют слишком много времени предварительному анализу и проектному решению. Иногда они используют аналитическое моделирование как тренировку, чтобы почувствовать себе уверенно в незнакомой им сфере деятельности. Одна из полезных сторон объектно-ориентированных методов состоит в разработке аналитических моделей с участием специалистов. Иначе было бы так легко увязнуть в процессе анализа, пытаясь создать всеобъемлющую модель.
Аналитический Паралич обычно подразумевает следующее:
- Детальный анализ может быть успешно завершен до начала кодирования.
- О проблеме все известно наперед, заведомо.
- Во время разработки аналитические модели нельзя ее ни расширить, ни заново рассмотреть. Объектно-ориентированное программирование плохо сочетается с каскадным анализом, процессами разработки и внедрения. Эффективное объектно-ориентированное программирование - это пошаговый процесс, во время которого результаты инкрементального и итеративного анализа подтверждаются с помощью разработки и внедрения, и используются позже для системного анализа.
Основной признак Аналитического Паралича - аналитические документы больше не имеют смысла для специалиста этой области. С прогрессирование Аналитического Паралича аналитические модели все сильнее охватывают детали, которые неинтересны специалистам. Например, модель домена системы медицинского обслуживания для больницы должна быть понятна администрации и персоналу этой больницы.
Если модель домена затрагивает непредусмотренные программные концепции, категории и специализации, то, скорее всего, аналитическое моделирование зашло слишком далеко. Если значение этих новых классов необходимо тщательно объяснять людям, хорошо знакомым с действующей системой, вероятно, проблема подверглась слишком глубокому анализу.
Симптомы и последствия
- Из-за кадровых перестановок и изменений в направлении проекта неоднократно происходит повторный старт проекта и множественные переделки модели.
- Вопросы разработки и внедрения постоянно оправляются на доработку на стадии анализа.
- Затраты на анализ превысили предварительные расчеты, но конца анализу не видно.
- На стадии анализа больше не требуется взаимодействия с пользователем. Большая часть анализа имеет умозрительный характер.
- В результате сложности аналитических моделей разработка усложняется, становится сложно разрабатывать, документировать и тестировать.
- Решения по разработке и внедрению сделаны на стадии анализа.
Стандартные причины
- Процесс управления предполагает каскадную последовательность стадий. В действительности, все системы построены на инкрементальных принципах, даже если это не осознается в формальных процессах.
- Руководство больше уверено в своей способности анализировать и раскладывать на составляющие, чем разрабатывать и внедрять.
- Руководство настаивает на полном завершении анализа до начала стадии разработки.
- Цели стадии анализа плохо определены.
- При возвращении к завершенной стадии анализа планирование и руководящая роль переходят в другие руки.
- Руководство неохотно принимает твердое решение, когда части домена уже описаны.
- Представление клиента о проекте, его целях и конечном результате весьма размыты. Анализ не обеспечивает какую-либо значимую пользу.
Что можно противопоставить
Аналитическому Параличу ничего противопоставить нельзя.
Решение для улучшения
Ключ к успеху объектно-ориентированной разработки лежит в инкрементальной разработке. Каскадный процесс подразумевает заведомое знание задачи, процессы инкрементальной разработки предполагают, что детали задачи и ее решение будут изучаться в процессе разработки.
В инкрементальной разработке все стадии объектно-ориентированного процесса возникают с каждым шагом цикла - анализ, разработка, кодирование, тестирование и проверка. Предварительный анализ включает в себя общий анализ системы, поэтому цели и общий функционал могут быть согласованы с пользователями. Каждое расширение представляет собой часть системы.
Существует два вида расширений: внутреннее и внешнее. Внутреннее расширение создает программное обеспечение, которое имеет значение для инфраструктуры разработки. Например, трехуровневая база данных или уровень доступа к данным, скорее всего, будут охватывать внутреннее расширение. Внутреннее расширение создает типичную инфраструктуру, которая используется во множестве случаев. В общем, внутренние расширения сводят исправления и доработки к минимуму. Внешнее расширение охватывает видимый пользователю функционал.
Внешние расширения важны для достижения соглашений по проекту, потому что демонстрируют прогресс. Внешние расширения также важны для оценки пользователем. Они обычно предполагают временное кодирование, чтобы воспроизвести отсутствующие части инфраструктуры и серверов баз данных. Это право менеджера проекта - выбирать расширения, чтобы сохранить равновесие между выживанием проекта, оценкой пользователя и минимальными затратами. Посмотрите анти-паттерн Неправильное Управление Проектом, а именно планирование расширений с учетом рисков.
Часто во время выполнения объектно-ориентированного анализа легче продолжить анализ, чем завершить его и перейти к разработке программы. Хотя многие методы анализа также в какой-то мере применимы к разработке, легче использовать стадию анализа, чтобы управлять деталями всего проекта.
Иногда это происходит в результате мнения, что некоторый анализ необходимо проводить одновременно с дизайном, и что можно начать дизайн, а затем вернуться назад. Обычно в результате получается продукт, которые не похож ни на модель домена, которую может понять пользователь, ни на желаемую разработку реализуемой системы.
Аналитический Паралич может также проявиться и на уровне архитектуры, приняв форму, сходную с анти-паттерном уровня разработки. Конечно, архитектура должна быть конкретизирована намного сильнее, это необходимо для разработчиков, чтобы придерживаться структурных принципов и компонентов.
Например, конкретизация известных и возможных подклассов, используемых структурными компонентами, разработанных исключительно для выполнения ряда операций в интерфейсе базового класса объекта - это уже перебор. В то же время лучше конкретизировать необходимые ограничения в базовом классе, на основе которого действует структурный компонент, и доверить разработчикам обеспечение ограничения в подклассах.
На уровне управления Аналитический Паралич проявляется в виде чрезмерного контроля подчиненных, управления всеми деталями процесса, и выявляется тогда, когда руководители предъявляют завышенные требования к заданиям и чрезмерно контролирует выполнение заданий, переданных другим исполнителям.
|
