Чи варто слухати свого роботодавця і користуватися інструментами 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 в спритному середовищі та їх можливі переваги / недоліки: 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 / хмара.

Справа повторно

У 90-х інструменти CASE можуть мати форму набору інструментів від Rational, які, ймовірно, включали Requisite Pro, Rational Rose, Clear Case, Rational Robot (тестовий запуск), очищення, чистого покриття та кількісного визначення та декілька інших інструментів які були об'єднані разом. Якщо ви були магазином MAD (Медицина, Авіоніка, Захист), ви можете використовувати оновлені версії цих інструментів для створення обширної та відстежуваної документації та артефактів, які часто потрібні клієнтам на цих ринках.

Зверніться до IBM і зв’яжіться з продавцем, щоб дати пропозицію про п'ять ліцензій (або лише одну плаваючу ліцензію). Додайте в якийсь тренінг теж. Поділитися цитатою з вашим менеджером може закінчити розмову про інструменти CASE. Але не зрозумій мене неправильно Мені подобаються Rational, їхні головні вчені та їх продукція, але в основному зверталися до них через ліцензії на університетські сайти, оскільки їхня ціна була занадто високою для компаній, де я працював. Якщо ви отримаєте схвалення, принаймні з мого досвіду, вони будуть ставитись до вашого права з хорошою підтримкою, якісною підготовкою (як правило, на найкращому курорті із чудовою їжею).

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

У вас ще є чудова можливість відвідати покупки інструментів. Швидким розробникам потрібні також інструменти. Ви можете придбати набір, який надає документальну підтримку для онлайнових карт розповідей, випадків використання, використання корпусу та інших типів діаграм UML. Atlassian має, на мій погляд, приємний набір інструментів - Джира для відстеження завдань та помилок, Зелений бункер для того, що вони описують як Agile управління проектами, Злиття для інтранет-вікі, Тигель для огляду онлайн-коду та Бамбук для сервера постійної інтеграції. Існує програмне забезпечення як ліцензія на обслуговування цих та інших наборів інструментів, орієнтованих на ваші потреби, якщо ви Agile.

Інтеграція IDE - це ще одна можливість отримання еквіваленту CASE у 2012 році. Якщо ви - будинок розвитку Microsoft, у Visual Team Studio є інструменти, які мають аналогічні масштаби, ніж створені Rational. У них є інженерія програмного забезпечення в зворотному напрямку, генерація блок-тестів з класів, інтеграція із системами управління джерелами та купа інструментів для спільної роботи в команді.

Інструменти з відкритим кодом

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

Ітераційне інкрементальне прийняття інструменту

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

Хмарні інструментальні рішення

Для багатьох перелічених рішень можуть знадобитися сервери та відносно складна установка. На ринок з'являється багато варіантів, які базуються на хмарі та пропонують програмне забезпечення як послугу, що приймається постачальником за щомісячну плату. Це може мати сенс для вашої команди, або коротко-, або довгостроково. Деякі можуть мати розроблене рішення, яке ви можете використовувати для швидкого запуску, з можливістю придбання ліцензій згодом.

Жодна з цих пропозицій не є дорогою та легкою дорогою до миттєвого підвищення продуктивності, але якщо ви можете спробувати деякі інструменти, незамінні, як тільки ви спробуєте їх.

Одне, що я хотів би додати до відмінних відповідей тут, - це те, що ви можете отримати користь від розуміння того, як ви хочете "покращити свій процес розвитку".

Переважаючою тенденцією протягом останніх 20 років є оптимізація розробки програмного забезпечення на час виходу на ринок. "Agile", "lean", DevOps, TDD, BDD - все це полягає в тому, щоб якомога швидше вивести якісне програмне забезпечення у двері.

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

Тож, можливо, запитайте свого начальника, що саме він намагається оптимізувати.

З досвіду роботи з інструментами CASE швидко стає складніше, ніж робота з кодом - особливо при роботі з проблемними доменами, які є більш ніж в середньому складними. Проект перестає бути "банківським" проектом, а натомість стає проектом "вставити-ім'я-CASE-інструмент-тут".