Как менеджер, не являющийся ИТ-специалистом, должен обеспечить долгосрочное обслуживание и разработку необходимого устаревшего программного обеспечения?

13

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

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

Аппаратное обеспечение не является проблемой - мы можем очень эффективно эмулировать на современных серверах. Если бы COBOL и BASIC были современными языками, мы были бы готовы пойти на риск, что в будущем мы сможем найти замену для наших нынешних консультантов.

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

Короче говоря, как не-ИТ-менеджеры, как мы можем лучше всего управлять этим переходом?

user105977
источник
6
Уч! Бейсик и кобол?!? Я бы попробовал дом престарелых. Вы думали о «модернизации» вашего программного обеспечения?
BЈовић
2
Просто добавлю: продуктивная, полезная карьера, частично на старом несексуальном языке, таком как Бейсик. - ОСНОВНАЯ и продуктивная, полезная карьера не
сочетаются
3
Есть много подрядчиков и консультантов, которые переносят программное обеспечение из устаревших систем. Однако кобол и базовый не являются наследием, они доисторические. Хотя странно, что, вероятно, довольно легко кого-то нанять, так как они, вероятно, крутые хипстерские хакеры.
НимЧимпский
3
Я собираюсь согласиться с @ BЈовић в этом. Вы должны подумать о модернизации своего программного обеспечения, а не пытаться найти жизненную поддержку для чего-то столь древнего, как BASIC и COBOL, по крайней мере, для проверки будущего. На данный момент вы можете найти некоторых старых или хипстерских детей, которые могут писать код для вас, но с годами и смена парадигм, эти таланты станут исчезающим видом, что, в свою очередь, приведет к медленному и устойчивому упадку вашей системы. Тот факт, что вы едва можете найти программистов сейчас, должен быть красным флажком, который пора менять.
Мару
2
@ user105977 - Мой лучший совет - документировать текущую систему (если она еще не задокументирована), чтобы ваши консультанты чувствовали себя комфортно, если они пострадали от автобуса или вышли на пенсию, кто-то мог прийти за ними и управлять проектом. Как только у вас есть документация по проекту (спецификации, требования к проекту и т. Д.), Вы не в таком плохом положении. Я не согласен с большинством комментариев об этих языках, спрос на них все еще существует, и знание этих языков стоит огромных денег. Молодой разработчик должен быстро выучить эти языки.
Ramhound

Ответы:

11

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

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

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

Читайте "Как выжить с нуля переписать без потери здравомыслия"

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

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

Настройка автоматических тестов

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

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

Поскольку вы имеете дело с COBOL и BASIC, набор тестов, вероятно, должен находиться на уровне интеграционных тестов: отрабатывать «фиксированный» набор входных файлов / баз данных и проверять выходные файлы / измененное содержимое базы данных конкретных программ (COBOL) и / или приложения. Для ОСНОВНЫХ частей вашего программного обеспечения это может означать добавление параметров командной строки, чтобы они выполняли определенные функции без вмешательства (G) UI, или получение инструмента автоматического тестирования на основе (G) UI.

Изолировать расчеты и другие алгоритмы

Даже Cobol поддерживает понятие подпрограмм, вызываемых из основной программы. Изолируйте все расчеты импорта и другие алгоритмы в отдельных программах или модулях. Цель состоит в том, чтобы создать библиотеку программ / модулей / чего бы то ни было, выполняющих основную работу, изолированную от всего, что собирает входные данные и создает выходные данные.

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

Запустить новый набор приложений в «текущей» среде

Не конвертируйте свой текущий код. Преобразование одного языка в другой означает наложение ограничений старой среды на новую. Результат, если часто меньше, чем хотелось бы (читай: результат будет ужасным и боль в поддержании). Migrate. Потратьте время на настройку приложений в новой среде таким образом, который считается наилучшим для этой среды.

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

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

Не идите дальше, настраивая приложения и, возможно, устанавливая единственную наиболее важную функцию ввода / вывода, которая использует вычисления из вашей «библиотеки» COBOL / BASIC.

Интегрируйте свою «библиотеку» COBOL / BASIC

Выясните, как назвать вашу библиотеку COBOL / BASIC из новой среды. Это может включать настройку файлов параметров или таблиц базы данных, выполнение программы COBOL / BASIC, которая оборачивает библиотеку COBOL / BASIC, которую вы установили ранее. Если вам повезет, ваша версия BASIC может позволить создавать библиотеки DLL, которые можно вызывать напрямую.

Реализуйте класс в вашей новой среде, которая будет называть COBOL / BASIC «библиотекой», и проверяйте его, используя те же тесты, которые используются в тестах старой среды, но теперь в форме модульных тестов в новой среде. ,

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

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

Уточнение новых приложений в итерациях

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

Миграция основной библиотеки в итерациях

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

Марьян Венема
источник
1
Хотя ваш ответ хорош, когда его видят сами по себе, к сожалению, он на самом деле не фокусируется на вопросе. Аскер - не ИТ-менеджер, который, скорее всего, понятия не имеет, что вы имеете в виду под большинством из того, что вы написали. Ему нужен совет, чтобы найти кого-то, кто делает.
Филипп
1
@ Филипп: Хорошо заметили, хотя я и сказал, что не отвечаю на его настоящий вопрос. Я уверен, что OP знает, как использовать Google, и в моем ответе достаточно поисковых терминов для OP, чтобы начать какое-то исследование - или еще лучше - попросить нынешних программистов сделать это. Не стесняйтесь добавлять свой собственный ответ, касающийся ОП, поскольку вы думаете, что это нужно сделать, хотя. Черт возьми, может быть, даже если бы вы проголосовали ...
Марьян Венема
Ему понадобится бизнес-ИТ-консультант для процесса перехода, который раньше помогал в таких процессах. Консультант не должен выполнять работу, а должен найти людей, выполняющих работу, контролировать их и убедиться, что программа выполняет то, что требуется для бизнеса. Да, это дорого Наличие собственного программного обеспечения всегда есть.
MSalters
@MarjanVenema (я не знаю точно, чего я ожидал, когда я разместил этот вопрос, но я не ожидал, что почти каждый комментарий будет вдумчивым и полезным - многие думают всем.) Я прочитал ваши рекомендации » сообщение «как выжить» Мильштейна и сообщение Спольского, на которое он отвечал, и даже Мильштейну не нравится идея переписать код. Основываясь на нашем опыте, комментарии Спольски об опасностях миграции данных и ценности рабочего кода звучат правдоподобно. Я определенно обеспокоен тем, что поддаюсь желаемому, но я действительно хочу думать, что Рамхунд прав.
user105977
1
@ user105977: я понимаю. Да, переписывание рискованно, но не всегда можно избежать, а иногда - лучший путь вперед, несмотря на риск. Для меня сохранение старых систем, опирающихся на набор навыков, который даже сейчас не совсем доступен, - это бизнес-риск, который может быть больше, чем риск переписывания, и который увеличивается со временем, поскольку пул доступных разработчиков сохраняет уменьшается. Но я не в вашем положении и не могу судить об их относительном риске.
Марьян Венема
2

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

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

Я бы порекомендовал один из двух маршрутов.

  1. Укомплектуйте ИТ-группу разработчиков / менеджеров проектов / QE / операций и постепенно наращивайте свою систему, как отмечено в довольно техническом ответе выше. Это, однако, будет исключительно дорого.
  2. Вместо того, чтобы готовить поставщика, ищите квалифицированного консультанта по разработке. Эта группа будет обрабатывать все ресурсы для создания вашей новой системы, затем вы можете принести ее в дом с небольшим персоналом, чем вариант 1, чтобы продолжить. Этот вариант имеет другой набор рисков, однако, выбор хорошего поставщика может быть очень сложным для нетехнических. Они также могут быть очень рискованными из-за перерасхода средств и т. Д. Чтобы смягчить этот маршрут, используйте свой существующий персонал для составления очень подробного набора требований (с точки зрения пользователя) для вашей ставки. Тогда попросите также предложения с фиксированной ценой.

Удачи, вам предстоит преодолеть около 20 лет наследия. Это не будет дешево, легко или чисто.

Билл Липер
источник
1
К вашему сведению: 20 лет в мире программного обеспечения эквивалентны 2 или 3 поколениям человека. Это очень очень долго. С технологической точки зрения Бейсик и Кобол достаточно
взрослые
Я занимаюсь программированием уже 20 лет, и COBOL предшествует моему опыту.
Билл Липер
-2

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

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

Высокая производительность
источник
1
Во втором абзаце говорится, что они уже сделали то, что вы предлагаете: они определили все три фирмы, которые предоставляют программное обеспечение для администрирования преимуществ. Никто из них не квалифицирован.
MSalters
Я не предлагал им найти фирму, которая бы предоставляла программное обеспечение, а продолжал пользоваться преимуществами системы администрирования .
Высокая производительность Марк