Должен ли я слушать своего работодателя и использовать инструменты CASE?

Мой работодатель (не разработчик) считает, что инструменты CASE помогут нам улучшить процесс разработки и документацию. Я не уверен в этом, мы небольшая команда из 5 разработчиков, которые разрабатывают решения для мобильного банкинга для местных клиентов. Я думаю, что инструменты CASE будут пустой тратой времени и денег, так как их нужно покупать, и нам потребуется некоторое время, чтобы привыкнуть к ним и эффективно работать с ними для моделирования и прочего. Генерация кода - это еще одна проблема, я действительно думаю, что код, сгенерированный CASE, будет не так хорош, как код, написанный хорошими разработчиками.

Я думаю, что если мы будем придерживаться гибких принципов, шаблонов проектирования, использовать TDD и поддерживать наш код в чистоте. мы должны быть хорошими Что касается анализа и проектирования, я думаю, что простые диаграммы UML на доске должны помочь. Документация хороша и важна, но должна быть сделана как можно меньше, и мы не должны сосредотачиваться на Документах и ​​забывать код. Это то, что я думаю.

Я прав? или я должен выслушать моего работодателя и начать поиск подходящего инструмента CASE?

Ситуация требует аналитического подхода к решению. Суть в том, что «Инструмент CASE обеспечивает ценность для бизнеса?» Часто руководство будет хотеть, чтобы разработчики приняли методологию или инструмент, потому что они слышали о нем хорошие вещи, независимо от того, насколько хорошо они вписываются в текущие процессы и культуру организации.

Если ваш работодатель попросил вас изучить инструменты CASE, как указывает ChrisF, вы должны сделать это (это проблема на рабочем месте, а не программирование). Некоторые факторы, которые могут повлиять на принятие инструмента CASE, включают:

• Для каких ваших процессов доступны инструменты CASE,
• Оценка количества человеко-часов, необходимых для принятия нового инструмента (ов),
• Как изменится процесс (ы) с принятием нового инструмента (ов),
• или Какого рода положительное (или отрицательное) воздействие было бы измеримо от принятия нового инструмента (ов)

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

Да, вы должны начать исследовать инструменты CASE.

1. Потому что вам нужны доказательства, подтверждающие ваше утверждение, что они не помогут. Вы никогда не знаете, вы можете обнаружить, что они помогут.
2. Потому что твой работодатель сказал тебе.

Я не буду повторять пункты, изложенные Дэвидом Качиньским в его превосходном ответе, так как именно они должны следовать.

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

Из того, что вы описываете, то, что нужно вашему работодателю, легко понять:

• Лучшая документация, чтобы избежать потери знаний, если разработчик должен был покинуть команду.
• Более быстрый процесс разработки.

Как профессионал в области программного обеспечения, вы определенно можете (и должны) рассказать ему о своих сомнениях относительно способности подхода CASE соответствовать этим ожиданиям. Это также ваша обязанность начать смотреть на инструменты CASE, если он этого требует. Попытка одного из них не означает 1 /, что результаты будут удовлетворительными (я особенно думаю о потенциально больших затратах на генерацию кода, которые противоречат необходимости разработки быстрее) и 2 /, что вы не можете найдите компромисс, в котором некоторые функции инструмента CASE (диаграммы, генерация документации) будут использоваться при сохранении существующего гибкого контекста.

Вот интересная статья об инструментах CASE в Agile-среде и их возможных преимуществах / недостатках: http://www.agilemodeling.com/essays/simpleTools.htm

Мой работодатель (а не разработчик) считает, что инструменты CASE помогут нам улучшить процесс разработки и документирование ».

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

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

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

В частности, с инструментами CASE, я работал в трех разных местах, которым принадлежали эти пакеты. В каждом из них это было так:

1. Модель была тщательно разработана в инструменте. Это заняло намного больше времени, чем обычно, и полезные результаты не были произведены до тех пор, пока усилия не стали слишком поздними.
2. Модель должна быть дополнена бизнес-логикой. Модель была неправильной, и ее пришлось настраивать вручную на поздних стадиях проекта, потому что усилия были слишком запоздалыми.
3. Повторная синхронизация модели и кода была настолько непозволительной, что инструмент CASE был отложен, чтобы никогда не использовать его снова.

Одним словом, это был 100% полный провал и пустая трата денег в каждом случае. Когда я говорил с другими людьми, которые использовали инструменты CASE в других организациях, история всегда о том же. Я не использовал все эти инструменты, и возможно, что некоторые люди хорошо их использовали, но я совершенно уверен, что большинство команд, которые их использовали, давно перестали их использовать.

Одно из преимуществ, которое вы получите от изучения / внедрения инструментов CASE, заключается в том, что вы приобретете более востребованный набор навыков для будущей работы. Я думаю, что многие из ваших проблем заслуживают внимания, но, как отметил Дэвид Качиньский, это не столько вопрос программирования, сколько вопрос взаимоотношений работодателя и работника. Еще одним преимуществом инструментов CASE является то, что после изучения ваша компания сможет приступить к более широкому кругу проектов более сложной сложности. Вполне может быть, что контракт, который ваш работодатель ожидает получить, требует или отдает предпочтение использованию инструментов CASE.

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

Что касается конкретного предложения по использованию инструментов CASE, я думаю, что вы должны выбрать его правильно, чтобы достичь своей цели, не перегружая свою команду дополнительной работой. Если документация - это то, что вы хотите улучшить, у вас может быть достаточно инструмента, способного генерировать диаграммы из кода, а не обязательно генерировать код из графической диаграммы. Примером такого инструмента является Codelogic . Я использовал несколько лет назад, чтобы убедиться, что наши проекты были чистыми и понятными, и их было довольно легко использовать. Если, когда вы выражаете деньги, есть другая проблема, вы, вероятно, можете посмотреть в открытом коде (я не могу здесь помочь, но был бы заинтересован в результате любого исследования).

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

Честно говоря, я думаю, что если вы считаете, что инструменты CASE не помогают, ваш босс должен это знать. Если он хороший начальник, он оценит ваше мнение. Мне никогда не нравился сотрудник, который просто делает то, что ему говорят, без критического анализа. Но, конечно, как предполагает Дэвид, любая дискуссия должна проводиться на основе сильных и объективных аргументов.

Я бы попытался заставить вашего работодателя понять, что он / она получил вещи назад. Если для группы разработчиков программного обеспечения есть место для инвестиций, вам следует определить, в чем заключаются ваши узкие места или проблемы с качеством. Если окажется, что у вас больше возможностей для совершенствования в области документации и процессов разработки, вам следует определить, какие изменения имеют наибольшую рентабельность инвестиций в отношении улучшения этих областей. Это может или не может начать использовать инструменты CASE.

Помоги своему боссу, помоги себе

Вы можете реагировать или действовать по этому запросу.

Помните все вопросы о "Переместить гору Фудзи"? Если бы вы проходили собеседование на работу, которую действительно хотели, вы бы не сказали интервьюеру, насколько глупым был этот вопрос, но продолжали бы задавать вопросы и высказывать свои лучшие идеи по ее решению. В некоторых культурах вы бы никогда не сказали «нет» боссу, который фактически попросил вас перенести гору Фудзи, но нашли бы для вас способ сохранить лицо.

Переосмысление вопроса

Если бы вы перефразировали вопрос в нечто вроде

«Могу ли я купить или иным образом приобрести набор инструментов, которые автоматизируют как можно больше задач с низкой производительностью, связанных с программным обеспечением?»

это назначение становится намного более приемлемым. Помогите своему боссу (и себе), предоставив ему опцию с четким отслеживанием CASE и один или два варианта Agile / open source / cloud.

Дело вновь

В 90-х годах инструменты CASE могли принимать форму набора инструментов от Rational, который, вероятно, включал Requisite Pro, Rational Rose, Clear Case, Rational Robot (тестовый прогон), Purify, Pure Coverage и Quantify, а также несколько других инструментов. которые были объединены вместе. Если бы вы были магазином MAD (Medical, Avionics, Defense), вы могли бы использовать обновленные версии этих инструментов для создания обширной и прослеживаемой документации и артефактов, которые часто требуются покупателям на этих рынках.

Свяжитесь с IBM и обратитесь к продавцу, чтобы оценить стоимость пяти лицензий (или только одной плавающей лицензии). Добавьте немного обучения тоже. Разделение этой цитаты с вашим менеджером может закончить разговор об инструментах CASE. Но не поймите меня неправильно. Мне нравятся Rational, их главные ученые и их продукты, но я в основном обращался к ним через лицензии на университетские сайты, потому что их цена была слишком высока для компаний, где я работал. Если вы будете одобрены, по крайней мере, исходя из моего опыта, они будут относиться к вашим правам с хорошей поддержкой, качественным обучением (обычно на курорте с отличной едой).

Инструменты для продажи

У вас все еще есть прекрасная возможность отправиться за покупками. Гибким разработчикам тоже нужны инструменты. Вы можете купить пакет, который обеспечивает поддержку документации для карточек онлайн-историй, сценариев использования, сценариев использования и других типов диаграмм UML. У Atlassian есть то, что я считаю хорошим набором инструментов - Jira для задач и отслеживания ошибок, Green Hopper для того, что они называют гибким управлением проектами, Confluence для вики интрасети, Crucible для онлайн-анализа кода и Bamboo для сервера непрерывной интеграции. Существуют лицензии на программное обеспечение для этих и других наборов инструментов, предназначенные для ваших нужд, если вы работаете в Agile.

Интеграция IDE - это еще один способ получить эквивалент 2012 года по CASE. Если вы являетесь разработчиком Microsoft, у Visual Team Studio есть инструменты, схожие с теми, которые создал Rational. У них есть несколько вариантов разработки программного обеспечения, создание окурков модульных тестов из классов, интеграция с системами контроля версий и набор инструментов для совместной работы в команде.

Инструменты с открытым исходным кодом

Со стороны открытого исходного кода, Eclipse и его многочисленные плагины пытаются интегрировать набор инструментов с открытым исходным кодом. Я не уверен, является ли Eclipse Modeling Framework зрелым или есть другие инструменты, которые дают эффективный инженер-программист, но в прошлый раз, когда я смотрел, это было не очень легко достичь. Среда Qt Creator интегрируется с системой контроля версий и имеет некоторые возможности, помогающие в выборочной проверке по охвату кода изменениями, пока вы находитесь в редакторе.

Итеративное Инкрементное Принятие Инструмента

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

Решения для облачных инструментов

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

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

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

В течение последних 20 лет преобладающей тенденцией была оптимизация разработки программного обеспечения для выхода на рынок. «Agile», «Lean», DevOps, TDD, BDD - все они направлены на то, чтобы как можно быстрее получить качественное программное обеспечение.

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

Так что, возможно, спросите своего босса, что именно он пытается оптимизировать.

По опыту, работа с инструментами CASE быстро становится более сложной, чем работа с кодом - особенно при работе с проблемными доменами, которые более чем в среднем сложны. Проект перестает быть "банковским" проектом, а вместо этого становится проектом "insert-name-of-CASE-tool-here".