Как избежать корпоративных приложений с коротким сроком службы?

Question

Некоторое время назад другой вопрос касался (возможно, городской сказки) статистики, которая

... средняя продолжительность жизни программного обеспечения составляет около 3 лет

В то время я придумал следующие причины (и я уверен, что есть, возможно, более лучшие):

1. Реализована новая основная система (ERP, CRM и т. Д.), Которая имеет «интегрированный» модуль для замены старого приложения.

2. То же самое, но без интегрированного приложения - но существующее приложение не адаптируется (люди ушли, технологии изменились, текущие ИТ-политики изменились, пользователям не нравится существующее приложение.)

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

4. Или вы больше не ладите с ними.

5. Технология для существующего приложения "устарела" (согласно поставщику фреймворка / Microsoft / консультант / эксперт в отрасли / новый ИТ-менеджер, у которого есть руководство.)

6. «Мы постепенно отказываемся (Windows 95 / Windows 98 / Windows 2000 / Windows XP / NT), и нам нужны соответствующие технологии в наших приложениях».

7. «Мы многому научились (Версия приложения n), и мы сделаем намного лучше во второй / третий / четвертый / n + 1-й раз».

8. Обоснование работы для разработчиков / IT-менеджер / Подразделение VP / консалтинговая компания.

9. Пользователи ненавидят его.

10. Мы объединили / приобрели конкурента / были приобретены конкурентом, и их лучше.

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

Answer 1

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

Если у вас есть надежный базовый код, большинство умных слов связаны с пользовательским интерфейсом (Vista Controls, Ajax, .net, ASP.net 3.5) ...

Вы могли бы запустить COBOL в бэк-энде (я бы не стал).

1. Внедрена новая основная система - вы ничего не можете сделать.
2. текущие ИТ-политики изменились, - приложение должно быть адаптируемым.
3. пользователям не нравится / не нравится существующее приложение - почему? косметические изменения в пользовательском интерфейсе могут исправить это большую часть времени.
4. Компания, у которой вы приобрели базовое приложение, чтобы настроить его для своих нужд, исчезла. - Я бы этого не делал, я бы предпочел написать это сам.
5. Технология для существующего приложения «устарела» (согласно поставщику фреймворка / Microsoft / консультант / эксперт в отрасли / новый ИТ-менеджер, у которого есть руководство.) - то же, что и выше, если внутренняя часть надежна, Вы должны следовать за этим в переднем конце.
6. «Мы постепенно отказываемся (Windows 95 / Windows 98 / Windows 2000 / Windows XP / NT), и нам нужны соответствующие технологии в наших приложениях». - простой тест совместимости и второстепенные элементы пользовательского интерфейса решают эту проблему.

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

Answer 2

Средний срок службы программного обеспечения, которое я пишу в данный момент, вероятно, составляет несколько дней. (Я пишу много сценариев, так что я могу быть отклонением от нормы. ;-) Но основной системе, с которой я работаю, сейчас, вероятно, 15-20 лет. Базовой ОС около 30 лет. Нет ничего плохого в старом или молодом программном обеспечении. На самом деле, программное обеспечение стареет лучше всего, когда его можно адаптировать к новым применениям.

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

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

Answer 3

Большинство компаний не делают это в течение 5 лет. Их реализация программного обеспечения не должна длиться так долго.

Answer 4

Когда собираются требования, и кто-то говорит: «Ситуация Х всегда будет, без исключений», сделайте ее настраиваемой. Он всегда будет меняться, без исключений.

Answer 5

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