Калькулятор обновления Directum RX
Как это было
Наверное любая статья про разработку чего-нибудь, или какое-то новое решение может начинаться с фразы "мне надоело, что...". Так вот, однажды мне надоели вопросы "а как, а почему" и самый главный вопрос - оценка разработки. Несмотря на то, что точные оценки давать достаточно непросто, и они сильно зависят от контекста инфраструктуры клиента и существующей разработки, однако, примерную минимальную планку оценить в автоматизированном режиме все же можно. Результатом изысканий на эту тему стало следующее решение:
В решении постарался учесть все основные переменные, применяемые в расчёте. Оценка блока "разработка" вариативна и зависит от коэффициента "Степень сложности".
Также имеется возможность скопировать ссылку на расчет (с помощью кнопки Ссылка), и передать коллегам.
Решение выполнено в виде PWA, что позволяет в том числе устанавливать приложение на смартфон\ПК. Открыв приложение с помощью браузера Google Chrome вы можете установить его через меню.
И оно отобразится у вас на рабочем столе.
Disclamer
Цель приложения - предоставить возможности примерную оценку обновления для людей, незнакомых с нюансами (РП\аналитики\консультанты и пр.). Любая оценка должна подтверждаться специалистом, выполняющим конвертацию.
После копирования ссылки на расчет, кстати, появляется предупреждение о том, что оценка не является окончательной, и должна быть пересмотрена в соответствии с ситуацией.
Ссылки
Калькулятор размещен на сайте ООО "Центр внедрения документооборота" DirectumRX Update Calculator
Исходник - GitHub
[Прим. ред. Компания Directum ответственности за авторский контент не несет.]
Дмитрий, очень интересный калькулятор.
Возникли вопросы по его использованию:
1. В списке ТР указаны не все ТР, например, нет WebAPI, который обычно требует дополнительных работ при обновлении. Почему указан именно этот список ТР?
2. В разделе "Разработка" есть признаки "Есть заказная разработка от вендора", "Дорабатывалась задача на согласование по регламенту", "Дорабатывались типы документов". Если в заказной разработке от вендора дорабатывались задача и типы документов, то признаки нужно проставлять все или только признак по заказной разработке от вендора?
Гузель,
1. Спасибо что обратили внимание, как раз собираюсь актуализировать список ТР.
2. Надо проставлять все, т.к. идея была в том, что с задачами\документами обычно делаются более сложные доработки, чем, например со справочниками.
Мне показались интересными градации степени сложности доработок. По каким критериям можно отличать друг от друга, например, "Доработки, местами носящие непродуманный характер" и "Существенные изменения, противоречащие коробочным механизмам"? Формулировки вроде бы друг другу не противоречат, но находятся на разном уровне
Александра,
1. Доработки, местами носящие непродуманный характер - а-ля "нам заказчик так сказал сделать". Когда нет вменяемого анализа, и реализация "да тут дел на 5 минут".
2. Мое любимое. Есть некий коробочный механизм. Заказчик просит распилить его пополам вдоль, повернуть половинки на 180 и так склеить.
Лучше поясню на примере:
Ситуация 1. "Нам нужно из карточки входящего счёта убрать поля и добавить новые". Делаем новый тип документа.
Ситуация 2. "Нам нужно чтобы согласующие не могли менять документы и карточки на всех этапах согласования" (актуально для <=3.6). Делаем фоновый процесс который отбирает права. Задача выдает, процесс отбирает, и так до бесконечности.
Дмитрий, т.е. "местами носящие непродуманный характер" - это про точечные доработки без исследований, а "противоречащие коробочным механизмам" - это когда действительно перекроили коробку. Спасибо, по формулировкам стало понятнее. Правильно понимаю, что при наличии доработок обоих типов нужно выбирать более "тяжёлую" градацию?
КМК, в обоих случаях масштаб доработок и требуемых при обновлении изменений может очень сильно варьироваться. Банально от того же статуса "Оплачен" для входящих счетов (точечная доработка в заказной) до вхождения в коробку целых решений, как это было, например, с интеллектуальной обработкой или с сервисом интеграции. Мы у себя для оценки используем немного другой шаблон, и сейчас, сравнивая его с вашим решением, осознали, насколько сложный на самом деле процесс происходит у разработчика в голове при оценке обновления.
Александра, >> Правильно понимаю, что при наличии доработок обоих типов нужно выбирать более "тяжёлую" градацию?
Конечно, да.
>> в обоих случаях масштаб доработок и требуемых при обновлении изменений может очень сильно варьироваться
Оно в т.ч. зависит от того, что в целевой версии, какие новые механизмы, ограничения, и т.д.
Повторюсь, что цели дать КП в финале - нет. Цель - приблизительно понять масштаб бедствия, и сделать из этого выводы.
>> Мы у себя для оценки используем немного другой шаблон
Поделитесь? Будет интересно.
Дмитрий, спасибо за ответ!
Дмитрий, не подсчитывали еще на 4.2?
Наталья, пока еще нет, вы можете сами добавить в исходниках и у себя захостить
Авторизуйтесь, чтобы написать комментарий