UML лихорадка – диагностика и лечение

Предисловие автора

Прежде чем обвинять автора в демонстрации вопиющей бесчувственности по отношению к тем, кто борется с UML лихорадкой или в том, что программа 12 шагов, является насмешкой над ними, хочется заметить, что автору хорошо известны проблемы и боли связанные с избавлением от токсикомании. Эта статья не является панацеей призванной окончательно решить проблему избавления зависимости от UML. В то время как некоторые параллели с симптомами зависимости от психотропных веществ у UML лихорадки имеются, их последствия не сравнимы.

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

1

Исследование показало, что проблема в распознавании или действий против UML лихорадки кроется в отрицании, безрассудстве и плохом понимании ее симптомов. Одна из важнейших целей этой статьи – помочь преодолеть эту проблему. Для этого здесь приводится описание всех симптомов болезни на индивидуальном и организационном уровнях. Очень важно не забывать о тех, кто игнорирует симптомы и не пытается лечиться.  Это нужно понимать людям на руководящих позициях, которые в первую очередь ответственны за разрушающий эффект UML лихорадки.

В конце приводится описание программы «12 шагов» по восстановлению здорового образа жизни компании.

Симптомы UML лихорадки.

Любая надежда на выздоровление должна быть подкреплена описанием симптомов болезни для тех, кто хотя бы принимает возможность возникновения проблемы. Симптомы лихорадок описаны в статье «Смерть от UML» . Нужно понимать, что все эти симптомы должны пересмотреться в соответствии с состоянием именно Вашей компании.

Программа боевой подготовки UML.

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

Рисунок 1. Первая диаграмма «Вани» в UML.

Рисунок 1. Первая диаграмма «Вани» в UML.

Может вместо UML, лучше инвестировать в образование малоопытных разработчиков, где они научатся объектно-ориентированному анализу, разработке и абстрактному мышлению? Нужно также взвесить UML и курсы по разработке интерфейса и БД – не важнее  ли на данном этапе развивать базовые навыки? Не стоит думать, что UML не нужен, просто он должен применяться тогда, когда это действительно необходимо. Проверьте Вашу организацию на симптомы лихорадки и подумайте, нужен ли Вам UML именно сейчас.

Мозговая атака. UML синтаксис доступен для всех.

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

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

Особое внимание на статическое проектирование ПО.

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

Отсутствие информации о клиенте в создаваемых UML диаграммах.

Отличительной особенностью UML лихорадки является отсутствие четкого понимания кто является конечным пользователем и его ожиданий. Хотя зараженные могут утверждать, что их диаграммы «помогают разработчикам» или «облегчают реализацию», эти пустые замечания еще раз доказывают плохое понимание вопроса.

2

Хорошей проверкой будет являться попытка спросить у парочки UML роботов для кого конкретно (поименно) создаются диаграммы, и как он их будет использовать. Если четкого ответа не последует – симптомы лихорадки налицо.

Неквалифицированные сотрудники на ключевых позициях.

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

Как может быть, что прекрасные UML модели не поют разработчикам как ангелы, вдохновляя на проектирование благословенного ПО, полностью удовлетворяющего требованиям заказчика? Классический пример этого симптома, когда предполагаемые заказчики бессмысленных моделей получают оценку их негативную оценку со уполномоченных ими на это лиц, после чего обвиняют их в неправильной точке зрения. Что является вашими личными предпочтениями в . Каковы принципы, которыми руководствуется «запевала» вашего UML проекта? Руководит ли вами принцип «Нарисуй как можно больше моделей!», когда все деньги проекта тратятся на создание множества UML диаграмм еще до того, как проект превратиться в готовый продукт?

Превращение UML модели в конечный продукт.

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

Преобладание UML-ориентированной деятельности в организации является индикатором проникновения UML лихорадки в ее производственную культуру и уводит компанию далеко от цели простой и гибкой разработки программного обеспечения. Каково процентное отношение этапов связанных с разработкой UML диаграмм и непосредственно программирования в вашем проекте?

Неоправданные ожидания от UML моделей

Диагноз легко поставить, если организация решает, что она будет анализировать UML модели для определения отказоустойчивости, производительности и безопасности сложных систем, вместо того, чтобы просто написать соответствующие программы, налицо «зверская» UML лихорадка. Хотя для отдельных уровней системы такой анализ возможен, но нужно понимать, что для системы в целом, возможно не стоит использовать даже специальные инструменты моделирования.

Зараженные «зверской» лихорадкой часто пропагандируют UML, как решение  комплекса всех проблем, но, к сожалению, вследствие своей наивности, не понимают, почему так делать нельзя. Ответьте на вопрос: Способна ли ваша UML модель доказать, что в ее реализации нет ни единой логической ошибки? Если ваш ответ «Да», то вы потенциально инфицированы.

Использование UML не по назначению.

Очень распространенный симптом этого заболевания – использование UML для моделирования самый высоких уровней детализации. Некоторые делают так, потому что верят, что качество кода в результате этого возрастет, другие просто думают, что следуют последовательному процессу разработки. Расширением этого симптома является ситуация, когда люди заявляют, что им не нужно усложнять себе жизнь созданием моделей разработки ПО, т.к. процесс обратного проектирования их реализации позволяет не делать этого.

Системные инженеры виновные в неправильном использовании UML применяют его как инструмент, помогающий определить и распределить требования путем создания диаграмм вариантов использования. Лихорадка находится в особо опасной форме, если армия специалистов по моделированию занимается декомпозицией вариантов использования на еще более мелкие куски, хотя требования могли бы быть определены на ранних этапах. Этот симптом свойственен компаниям, где «UML» является ответом на любой вопрос. Ответьте себе на вопрос: Ваша организация использует UML, чтобы существовать или она существует, чтобы использовать UML?

Эта статья – нападка на UML.

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

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

Лихорадочное бормотание.

В дополнение к описанным симптомам поведения больных хочется привести еще ряд стандартных и часто употребляемых ими изречений – это отличная основа для установки диагноза:

  • «У меня нет UML лихорадки» 3
  • «Я не могу перестать рисовать UML диаграммы»
  • «Нам нужно нанять больше специалистов по моделированию»
  • «Мы должны устроить курсы по UML»
  • «Алекс Белл – UML еретик»
  • «Нам нужно это смоделировать!»
  • «Если я не буду создавать диаграммы, я буду заниматься ерундой»
  • «Сейчас не время отходить от моделирования»
  • «Не удаляйте эту диаграмму»
  • «Я использую UML лишь на 95%»
  • «Мы спроектируем модель разработки из кода»
  • «Я не хочу отставать: сейчас все рисуют диаграммы!»
  • «Инструментарий UML – основа нашего подхода к процессу разработки и моделированию»

Остерегайтесь заниматься самолечением.

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

Не угрожайте заболевшим.

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

Не отключайте сервера с лицензионными средствами моделирования

.

Такая тактика, вместо того чтобы вылечить его, оказывает мало влияния на пострадавшего. В интернете доступны не только поддельные лицензии, но имеется достаточно много свободно-распространяемых средств и демо-версий различных UML-средств, которые могут быть загружены заболевшим, для того, чтобы преодолеть временные трудности в создании диаграмм.

Используйте UML-вмешательство только как крайнее средство.

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

Не пытайтесь контролировать коллег больного.

 

Любая попытка контролировать тех коллег, с которыми больной общается или проводит свое время, является контрпродуктивной для процесса его выздоровления. Заявление о том, что UML-активисты будут изолированы на своих рабочих местах приведет только к еще большей тяге к общению зараженных со своими коллегами.

Не форсируйте выполнение программы «12 шагов».

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

Программа восстановления «12 шагов».

Программа восстановления «12 шагов», описанная далее, разработана специально для тех, кто осознал, что болеет UML лихорадкой, но готов вновь вернуться к здоровому образу жизни нормального разработчика. Этой программе нужно аккуратно следовать, шаг за шагом, чтобы избавиться от губительных симптомов лихорадки как у отдельных людей, так и всей организации. Компании по разработке ПО должны спонсировать создание таких программ для пораженных инфекцией и затраты на них включать в социальные выплаты рабочим.

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

  • Признаться самим себе, в бессилии перед неумением использовать UML – наши проекты вышли из-под контроля из-за того, что много внимания уделялось моделированию и созданию диаграмм. Это первая, самая сложная ступень программы избавления от UML лихорадки. Зараженные должны сами заставить себя встать на ступень выздоровления.
  • Принять решение отдать техническое направление и деятельность по развитию компании в руки опытных архитекторов и разработчиков. Как уже говорилось, проблема большинства зараженных – полное отсутствие настоящего опыта в разработке и создании ПО. Эта ступень важна, т.к. люди, наконец, начинают понимать, что неопытность является причиной неправильного использования ресурсов.
  • Провести исследование и инвентаризацию наших навыков и заставить себя строго следовать обучению и наставлениям, дабы избавиться от своих недостатков. Нужно уметь видеть причину неудачного проекта, в том числе и в своих недостатках.
  • Поверить, что разработка простого, итерационного, пошагового процесса разработки ПО и строгое следование ему приведет вашу деятельность в порядок. UML лихорадка и процесс последовательной разработки ПО часто идут параллельно. Важно понимать, что процесс разработки ПО может осуществляться и без создания огромных UML моделей.
  • Признаться своему руководителю, самому себе и своим коллегам в реальной природе неправильного использования UML. Значимость этого этапа заключается в восстановлении авторитета в технических вопросах, подмоченного UML лихорадкой. Подробное признание в прошлых UML-безобразиях служит свидетельством того, что выздоравливающий действительно осознал свои ошибки в своих старых суждениях.
  • Взять на себя обязательство привлекать к созданию UML диаграмм всех лиц, активно заинтересованных в подтверждении их ценности и определении их содержимого. Те кто болен UML лихорадкой, часто считают, что основные заинтересованные стороны не понимают собственных потребностей, если характеризуют предоставляемые им диаграммы как мало или совсем ничего не значащие. Завершение этого шага программы восстановления означает согласие с тем, что модели и диаграммы не могут создаваться только на основе того, что их создатель считает важным для основных потребителей, а должны создаваться на основе потребностей определяемых заинтересованной стороной.
  • Смиренно просить, чтобы наш прошлый гнев против хорошо спланированной помощи по преодолению UML лихорадки и восстановлению после болезни был забыт. Гнев весьма характерен для тех больных, которые «корчатся в муках» UML лихорадки, самоустранившись от здоровой стороны технического сообщества из-за болезненных диалогов с ней. Этот шаг призван начать восстановление любых восстановимых отношений с той стороной технического сообщества, которая ранее была отвергнута.
  • Составить список всех проектов, которым было причинено зло в результате неправильного руководства или неправильного использования UML и преисполниться желания принести извинения им всем. Дополнением к очистке вашей собственной совести, завершение этого шага, т.е. демонстрация ликвидации принесенного вашим коллегам вреда, улучшит ваши перспективы будущего трудоустройства.
  • Примите соглашение создавать только минимальное количество диаграмм и моделей необходимых для процесса разработки без потери качества конечного продукта. Завершение этого шага должно привести к пониманию того, что UML диаграммы и модели являются только частью процесса разработки, а не самостоятельными ценностями. Это решающий момент в процессе восстановления, когда приходит переключение оценки успешности проекта размером UML модели, на оценку успешности проекта достижением его конечной цели, т.е. разработки конечного программного продукта.
  • Предпринять шаги по технической инвентаризации персонала, находящегося на ключевых позициях, для получения уверенности в том, что их навыки соответствуют занимаемыми ими местам. Это шаг должен быть направлен, в первую очередь, на людей связанных подчиненными отношениями с больным, которые представляют благоприятную почву для распространения заболевания внутри организации. Независимо от того на каком шаге восстановления они находятся, восстановление на уровне организации невозможно, если руководство организации само не в состоянии завершить этот шаг.
  • Стремитесь путем исследований и анализа улучшить свое понимания UML, для определения его сильных сторон и ограничений, таким образом вы сможете разумно и правильно применять его в своих усилиях. Завершение этого шага показывает, что выздоравливающие способны правильно оценить лучший способ применения UML, правильно выбрать уровень детализации UML моделей и способны определить сроки годности для создаваемых UML моделей и диаграмм. Выздоравливающие должны четко осознавать, что вполне приемлемо «выкидывать» UML модели и диаграммы, после того, как они выполнили свое предназначение.
  • Технически проснувшись после выполнения данной программы, вы должны передавать эту программу другим зараженным UML лихорадкой и помогать им в ее выполнении.

Выводы.

Многие из нас знают по собственному опыту, что чрезмерное наслаждение благами приносит непоправимый ущерб. К сожалению, вред наносится не только виновным в несдержанности, но и окружающим, коллегам и родным. Общество старается обеспечить защиту своим членам посредством введения ограничений на курение, употребление алкоголя или разрешенных наркотических веществ. Ограничения существуют разные: возрастные, наличие разрешения государственных органов, прохождение проверок. К большому расстройству многих организаций по разработке ПО на использование UML подобных ограничений не существует. Любой сотрудник способный пользоваться инструментарием UML и не имеющий опыта в вопросах разработки ПО, создания сложных систем или анализа требований, подвержен риску превращения в машину по рисованию диаграмм.

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

UML лихорадка не пропадет благодаря «Молитве святому духу UML» и отчаянной надежде на божественное провидение. для восстановления  необходимо предпринимать определенные действия и нести траты. Сначала, организациям необходимо пересмотреть процессы разработки и построение учебных курсов, а также произвести переоценку кадровой политики. Если предприятие не способно провести самодиагностику, стоит нанять экспертов, которые смогут дать независимую оценку и предложить варианты дальнейшего существования в соответствии с полученными результатами.

О, Великий...

Знакомы ли вам какие-то из симптомов UML лихорадки, которые здесь перечисленны? Если да, в состоянии ли вы провести кампании по избавлению своей организации от UML лихорадки? Или вы считаете, что проблемы разрешаться сами собой? Может, Вам кажется, что UML лихорадкой поражены только другие организации, но не на ваша? До тех пор пока фирмы разработчик ПО не обеспечат свое техническое здоровье с помощью одинаковых средств и инструментов, UML лихорадка будет беспорядочно атаковать ПО во всем мире.

Первоисточник: UML Fever: Diagnosis and Recovery

Alex E. Bell The Boeing company

 

Оставить комментарий