Система автоматизированного проектирования и контроля разработки: как мы «докрутили» СППР
В этой статье расскажем,
почему решили сделать собственную систему проектирования прикладных решений
при живой «1С:СППР»
Проектом занималась команда из пяти человек: директор проекта, три архитектора и разработчик.
Кратко суть
- в ИБС исторически использовали Конфлюэнс+Джира
- но передать результаты по проекту клиенту даже если у клиента есть Конфлюэнс было проблемой
- решили прикрутить СВОЮ СППР2 на основе СППР, где сделали интеграцию с Конфлюэнс, Документооборотом
(и вроде бы, не уверен, с конфигурациями 1С - для интеграционных проектов)
- ни один ИИ при этом проекте
Обратите внимание на тот кусок, который про "Запрос на изменения" - там прям просится вставить ИИ,
чтобы он на основе спецификации на изменения уже сам создавал объекты прямо в конфигурации 1С.
Но почему-то не сделали.
А там неслабо можно было сэкономить на работе программиста.
Да и мэппинг интеграции уже мог бы ИИ сам писать им, а не спрашивать его разок на обобщённом уровне.
Авторы пишут в конце статьи про эффект от внедрения своей СППР - сокращение трудозатрат на 25-40%.
Если это правда, то проекты от ИБС должны подешеветь на те же цифры и они должны сметать всех конкурентов в корпоративном секторе.
Верим?
Почему остаётся ощущение что задача не доделана, а планы в на развитие (тоже есть в статье) ведут не туда?
А посмотрите, а как в этой разработке будет решаться проблема существенного изменения
во входных требованиях или появлении новых внутренних требований по ходу проекта?
Как в этом случае буду массово корректироваться множественные связи между объектами СППР?
Вот тот-то и оно.
То что построили такую систему молодцы, но работать хорошо она будет при "прямом" ходе работ по проекту.
А вот как переживёт массивные изменения уже зафиксированных связей и объектов - очень большой вопрос.
