Как определить окончание срока службы веб-приложения?[закрыто]

Question

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

Мы продаем CMS-систему, с помощью этой системы создаем несколько подпродуктов.

• Веб-сайты
• Создатель предложения
• Трекер маркетинговых кампаний

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

Пожалуйста посоветуй,

Гео

---

Спасибо всем!Я очень ценю ваши комментарии, мнения и мысли по этой теме.

Я отвечу на некоторые вопросы по ответу в списке ниже.

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

Я буду продолжать добавлять ответы, пока читаю вам все ответы.

Answer 1

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

Вот мои предложения:

• Попросите младшего разработчика присоединиться к этому нынешнему разработчику.
• Сбросьте большую часть будущих обновлений младшего разработчика (с помощью SR. Developer)
• Попросите младшего разработчика сделать документацию своей работы
• Попросите разработчика -старшего просмотреть документацию

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

.

Расширение этого решения с помощью предложения Jefferey ниже («Иногда переписывание - хорошая инвестиция».)

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

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

---

Согласно вашим (гео) комментариям

Организация GEO имеет пользовательскую приложение CMS-CMS Custom (с одним и только одним разработчиком контракта), которое реализует приведенные ниже бизнес-требования и платит лицензионную комиссию за поддержку и использование своего кода.

• Бизнес -требования для CMS
• Веб -сайты
• Создатель предложения
• Маркетинговая кампания трекер

Вот мои предложения

• Создайте модуль по модулю подробный документ использования для этого проекта. Ваш разработчик может сделать это или будет идеальным, чтобы иметь отдельного бизнес -аналитика для того же.
• Нанимайте разработчика -старшего, чтобы оценить, может ли CMS с открытым исходным кодом обработать все или большую часть ваших требований (например, Joomla, Drupal и т. Д.).
• Самым важным здесь будет возможность переносить ваши существующие данные в новую систему. Вам может понадобиться помощь от существующего разработчика контракта, чтобы сделать это.
• Возможно, вам придется обновить бизнес -процесс или рабочий процесс для использования новой системы.
• Модули, которые не могут быть реализованы с использованием CMS с открытым исходным кодом, могут быть реализованы с использованием пользовательского веб -сайта.

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

Короче говоря: я в сопоставимой ситуации.

• До тех пор, пока это приложение является чем -то вроде CashCow, но компания не может позволить себе (или намерен) разработать новое приложение, она не умрет, прежде чем клиенты решит купить более свежую систему.

• Переписать без (документированных) требований практически невозможно.

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

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

Answer 6

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

Answer 7

Это те вещи, которые я мог бы рассмотреть при принятии решения о том, может ли система идти "в конце жизни":

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

Написано ли это в технологии, от которой клиенты избегали бы, так как было бы неловко взаимодействовать в свои продукты или требовать от них запуска «устаревших» платформ? Даст ли это потенциальному клиенту впечатление, что ваша компания существенно За время, например, VB6, вероятно, все еще в порядке, даже в 2010 году, но требует совместимости Win16, вероятно, нет.

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

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

Если он поддерживается, заряжают ли вам поставщики за поддержку более старой платформы? Если не сейчас, то сколько времени до того, как они это сделают?

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

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

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

Answer 8

Я прошел аналогичный процесс.У нас было веб-приложение, которое работало почти 8 лет.За это время было проведено большое техническое обслуживание, которое расширилось так, как мы не предполагали.Однако ядро ​​было хорошим, и его еще можно было растянуть.

Что нас смущало, так это стоимость обслуживания.Найти людей с нужным набором навыков было легко 8 лет назад.Сегодня никто не хочет работать в таких условиях;даже не мы :)

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

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

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

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