1С: СППР и оценка сроков и стоимости проектов методом COCOMO II

06.01.20

Архитектура

Статья рассматривает способ использования 1С СППР (Системы Проектирования Прикладных Решений) для оценки длительности и стоимости проектов по методу COCOMOII. Как обосновать заказчику, что данная вами оценка сроков исполнения проекта объективна? Как измерить маржинальность проекта до его начала, на этапе пресейла? Каким способом оценить диапазон торга по цене проекта, чтобы предотвратить выход в убыток? Как объективно рассчитать потребность на проекте в членах команды, которые не являются разработчиками (бизнес-аналитики, методологи, технические писатели и т.п.)? Как формализовать результат их работы наиболее простым и доступным способом?

Оглавление

Вступление

Основная проблема использования 1С СППР в настоящее время

Почему COCOMOII?

Почему 1С СППР?

Кратчайший курс COCOMOII

Переход от оценки труда разработчиков к оценке труда аналитиков и методологов

Псевдокод

1С СППР и псевдокод

Резюме

 

Вступление

 

1С Система Проектирования Прикладных Решений выпущена на рынок 6 лет назад и в июле 2019 доросла до версии 2. Основана на технологиях SADT и каскадной модели разработки. Впрочем, позволяет вести Scrum/Agile разработку на отдельных этапах.

Предназначена для сложных, длительных проектов, исполняемых многосоставной командой с частым кадровым замещением. Включает в себя функционал управления проектами, описания бизнес-процессов,  проектирования архитектуры и функциональности информационных систем, разработки ПО и сопровождения ИС, а также автотестирования на базе Vanessa / Gherkin.                

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

Основная проблема использования 1С СППР в настоящее время

 

Основной проблемой использования 1С СППР в настоящее время (в основном используется версия 1) является крайне некорректное использование 1С СППР как технологии.  

1С СППР чаще всего используется на уровне функционала, предназначенного для разработчиков, в лучшем случае для архитекторов. Её роль часто сводится к описанию и разработке «Функций» системы и формированию задач программистам. В этом и заключается ошибка подхода к работе с СППР.

С постановкой задач программистам и обработкой тикетов пользователей прекрасно справляются существующие на рынке системы (JIRA и т.п.). При таком использовании на разработчиков СППР ложится ещё одна времяёмкая бюрократическая надстройка, отнимающая время от «чистого» кодинга. Р

Разработчик становится обязанным описывать функциональность внедряемой/дорабатываемой системы, дабы обеспечить постановку задач программистам со ссылками на объекты метаданных («общий язык» в терминах  Эрика Эванса в его работе «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем»).

При этом, задачи другой половины команды проекта – руководителей проекта, бизнес-аналитиков, методологов практически полностью игнорируются. С огорчением можно сказать, что даже сама 1С в версии 2.0 СППР сильно урезала функционал для этой категории участников, существенно изменив модель СППР по сравнению с версией 1.0 в сторону разработчиков и тестировщиков (например: убраны в явном виде требования и объекты данных).

Тем не менее, вопрос полноценного и полнофункционального использования СППР стоит остро. В этой статье, в частности, рассмотрим, как в 1С СППР может быть использована технология оценки сроков и стоимости проектов по методике COCOMOII.

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

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

А самое главное, как объективно рассчитать потребность на проекте в членах команды, которые не являются разработчиками (бизнес-аналитики, методологи, технические писатели и т.п.), как формализовать результат их работы наиболее простым и доступным способом?

Почему COCOMOII?

 

Заказчики в любой отрасли предпочитают иметь объективную, обоснованную и общепризнанную оценку стоимости и сроков проекта. Им хотелось бы видеть связь своего проекта с опытом системного интегратора на предыдущих проектах. При этом, редкий заказчик имеет чёткое представление о конечном результате проекта, а в проектах с разработкой концептуальной модели точно не имеет. И системный интегратор не имеет.

Как же оценить сроки и стоимость на этапе пресейла в условиях недостатка информации? А по ходу проекта с учётом изменений (бич всех проектов)?

Метод COCOMOII позволяет сделать такую оценку с учётом накопленного опыта системного интегратора, причем наиболее простым способом, при этом оперативно, по ходу проекта делать уточнения цены/сроков и обосновывать для согласования с заказчиком.

Почему 1С СППР?

 

Всё дело в том, что 1С СППР основана на технологиях SADT и «общего языка» (более подробно это изложено в отдельной моей статье). Именно SADT интегрирует  процесс моделирования с процессом разработки на основе «общего языка». А «общий язык» позволяет иметь базис для расчёта оценочных показателей сроков.

Кратчайший курс COCOMOII

 

Методика COCOMO возникла в 1963 году в ответ на потребность для быстрой и несложной оценки трудоёмкости и сроков разработки программных продуктов в предстоящих проектах. Базисом модели COCOMO и её следующего этапа COCOMOII является число строк программного кода (KSLOC – тысяча строк логического кода, т.е. строки кода выражающей операцию). Этот базис имеет как результат любой проект по разработке ПО, это своего рода квинтэссенция проекта.

(Далее будем иметь в виду, что COCOMO отличается от COCOMOII тем, что скалярные параметры формулы COCOMO заменены на таблицу параметров COCOMOII, но суть метода осталась прежней).

Таким образом, имея накопленный багаж проектов, любой разработчик может иметь рамочную базовую оценку каждого следующего проекта. Разумеется это весьма приблизительная оценка, но на этапе пресейла и такая оценка лучше, чем ничего. Для её уточнения базис KSLOC по определённой формуле корректируется на уточняющие коэффициенты. Мы не будем приводить формулу, она несложна и доступна в интернете. Суть в том, что коэффициенты этой формулы  каждый разработчик может разработать сам на основе статистики прежних проектов и сравнивать с каноничными параметрами формулы или… не сравнивать и использовать только свою формулу.

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

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

Детализацию параметров проектов можно проводить на своё усмотрение и возможности. Чем больше детализации, тем точнее оцениваются сроки и стоимость будущего проекта.

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

Вот и вся суть метода COCOMO.

Переход от оценки труда разработчиков к оценке труда аналитиков и методологов

 

Внимательные и опытные читатели воскликнут:

«Ну, ладно! При всех плюсах и минусах метода COCOMO, он предназначен для оценки проектов по созданию программного обеспечения. Труд разработчиков, программистов можно оцифровать в условных KSLOC. Но как быть с аналитиками и методологами, руководителями и менеджерами проектов? А уж при чём тут 1С СППР»

Верно!

Значит, задача состоит в том, чтобы подобрать для перечисленных членов команды  аналогичный базис, который позволит использовать методику COCOMOII. Вот тут на сцену и выходит он.

Псевдокод

 

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

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

Если проект сдаётся по ГОСТовским требованиям, то структура проектных документов задаётся этими стандартами, в ином случае, она создаётся на усмотрение исполнителя или по требованиям договора с заказчиком.

Интересный момент, если проектная команда и заказчик решат идти в ногу со временем и будут оформлять результаты проекта исключительно по безбумажной технологии как с этим будет связана 1С СППР?

Ответ - самым прямым образом – СППР и содержимое её справочников, заполненных по проекту, будет сама структурированным объектом данных и результатом работы. Который очень удобно передавать заказчику. Все создаваемые в ходе проекта документы будут являться вложенными документами к объектам конфигурации СППР.

                Упрощенно выходные проектные документы делятся на следующие группы псевдокода:

  1. Структура (оглавление) документа;
  2. Тест документа;
  3. Строка таблицы документа (таблица);
  4. Рисунок (графический объект).

 

В самых простых случаях, для базиса COCOMO достаточно структуры выходных документов. Её сложность (число уровней вложенности), число строк оглавления могут служить основанием для применения формул метода оценки сроков и стоимости проекта через аналогичную статистику прежних проектов и структуры участников команд проектов (не программистов). Разумеется, включение в базис всех видов псевдокода повысит точность оценки.

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

 

1С СППР и псевдокод

 

Встаёт вопрос, как разместить в 1С СППР псевдокод.

Это можно сделать через справочник «Объекты данных». Создаётся отдельная группа «ВЫХОДНЫЕ ДОКУМЕНТЫ», внутри неё подгруппы под каждый вид документов, далее ещё подгруппы под каждый отдельный документ, а внутри уже этих подгрупп как элементы справочника строки оглавления проектного документа. 

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

Текст самого проектного документа можно набирать по абзацам как текстовое поле элемента справочника «Объекты данных»

К чему следует стремиться при описании структуры выходных проектных документов в справочнике «Объекты данных»?

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

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

При увязке каждого элемента или группы справочника «Объекты данных» с Требованиями  (как сформулированные заказчиком, так и членами проектной команды, детализированными до метаданных),  то в итоге можно получить сквозную связку Требования – Объекты метаданных – Выходные проектные документы. В СППР 2.0 аналогом «Требований» выступают «Идеи».

По мере накопления опыта исполнения проектов в 1С СППР будет выкристаллизовываться такая структура справочника, которая будет одинаковой на всех однотипных проектах. Следовательно, для нового проекта её достаточно просто скопировать. А для идентичных по выходным результатам проектов можно скопировать и текст (таблицу).

Резюме

 

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

Это должно существенно облегчить А) торг с заказчиком Б) оценку ожидаемой прибыли.

проектирование архитектура сппр оценка проекты

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1423    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1642    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3829    0    ivanov660    10    

29

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1824    0    user1754524    15    

15

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    2860    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9590    0    1c-izhtc    37    

21

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1384    0    Ingraf    0    

15
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. o.nikolaev 211 07.01.20 13:49 Сейчас в теме
Который очень удобно передавать заказчику.
+Личная просьба: сфоткайте тайком выражение лица заказчика, особенно госа, когда будете передавать ему СППР вот с этим всем.

Текст самого проектного документа можно набирать по абзацам как текстовое поле элемента справочника «Объекты данных»
+Эмм.. а если захотите массово что-то поискать или изменить? Будете бегать по абзацам?

когда необходимо заново пересоздавать выходные документы, но при этом сохранить связанность объектов и их описаний.
+Никакого запоможения от системы СППР в этой части нет. При изменении вы руками понесетесь по абзацам и именам метаданных. Естественно - это вопрос времени когда состояние СППР разъедется с состоянием метаданных информационной базы (тут еще вопрос интересный - а если решение состоит не из одной конфигурации а из нескольких? СППР позволяет структурировать кухню в рамках только одной конфигурации). 1С-ка может себе такое позволить - ибо она монополист. На проектах внедрения если сей подход будет замедлять работу - пошлю и выкинут очень быстро. Ибо - вот Таня - бизнес-аналитеГ (хорошо если бывший бухгалтер), вот Word - фперде!

то в итоге можно получить сквозную связку Требования – Объекты метаданных – Выходные проектные документы.
+Есть у вас уже практический опыт подобного? Расскажите подробнее.

проведя ревизию материалов прежних проектов,
+Слон конечно 2 ведра моркови зъисть, но хто ш иму дасть.

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

Но + за поднятие вопроса.
3. acanta 07.01.20 16:17 Сейчас в теме
(1) классно. А может как то совместить конвертацию 3 с сппр? И волки сыты и так сказать заказчик удовлетворен. К тому же формат ed позиционируется как универсальный кроссплатформеный механизм интеграции.
Иначе не совсем понятно как поддерживать актуальность нескольких связанных вспомогательных конфигураций, которые в основном бизнес-процессе не нужны.
4. roman72 379 07.01.20 17:18 Сейчас в теме
(3) О том что в СППР нужна конвертация для построения таблиц мэппинга - давно задумываюсь.
gortol; acanta; +2 Ответить
2. vittol 29 07.01.20 16:10 Сейчас в теме
Использование псевдокода для оценки
"...результатов работы «непрограммистских» членов команды проекта – аналитиков, методологов, технических писателей, менеджмента проекта, архитектора, проектировщиков и аналогичных участников"
, это интересно, но предложенная реализация в 1С:СППР, сомнительна.

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

Во вторых , в 1С:СППР 2 "Справочник.ОбъектыДанных" не используется (и если я не ошибаюсь, вскоре будет удален из системы).
5. ashvik 08.01.20 17:24 Сейчас в теме
Для оценки сроков проектов, я бы рекомендовал изучить эту статью https://vc.ru/hr/95754-razvitie-i-proval-regulyarnogo-menedzhmenta-v-it
6. serw040 10.01.20 16:39 Сейчас в теме
(5) Скорее приведенная вами ссылка на статью более верно отражает практическую сторону вопроса :-) Присоединюсь также и к "+Есть у вас уже практический опыт подобного? Расскажите подробнее." С интересом бы послушал о такой практике (если она есть у автора)

А совсем из своей практики судебных экспертиз по "внедрению", развивая тему оценки и теоретически существующих методов, с существующей в природе практикой их применения (+- 100 мильенов долларов для оценки кораблей, бороздящих просторы...) могу только сказать:

Оценка стоимости проекта (работ-услуг-консультаций и их объема при заключении договора, а особенно в Суде) отдельная большая Песня. Методы: «Среднерыночной стоимости»; «Аналога»; «Затратный»; «Доходный» «Функциональных точек»; «Кол-ва строк кода»; «СOCOMO»; «IFPUG»; «FPA mkII»; «Оценка трудоемкости разработки ПС» и прочие наукообразные и не очень…. И все они скорее из области теорий, чем практически применимы.
8. roman72 379 15.01.20 20:05 Сейчас в теме
(6) Касаемо практического опыта, в телеграмме есть канал и чат по сппр, можете спрашивать там.
7. serw040 10.01.20 16:54 Сейчас в теме
Добавлю еще 3 копейки:
COCOMO разработана в конце 70х годов, а затем усовершенствована. Анализ ряда проектов, выполненных в основном в интересах Министерства Обороны США для разработки системного ПО,
https://swehb.nasa.gov/pages/viewpage.action?pageId=16449930
https://www.theverge.com/2018/2/2/16954582/spacex-falcon-heavy-rocket-launch-impact-nasa-deep-space-travel
показывает, что стоимость запуска собственной сверхтяжелой ракеты SLS (Space Launch System) NASA обходится свыше 1 млрд долларов.
А запуск Falcon Heavy SpaceX от компании Space X стоит для НАСА 90 млн долларов.
Таким образом NASA использующая в своих программных разработках и оценках методику COCOMO-II тратит в 10 раз больше финансовых средств, чем коммерческая компания Space X при создании аналогичного продукта. Что еще раз подтверждает на практике разницу в затратах в 10 и более раз при создании продукта различными компаниями и различными факторами.
9. roman72 379 01.02.20 00:08 Сейчас в теме
(7)
Falcon Heavy SpaceX


Подмена понятий.
COCOMOII - это не технология по производству ракет.
Это технология подсчёта затрат времени работы людей и оценки стоимости их работы исходя из накопленной статистики каждой конкретной компании и истории исполнения проектов этой компанией.
NASA исполняла свои проекты по производству ракет в среднем за столько-то времени и труд людей стоил столько-то. И это далеко не 1 млрд. долларов за, включая, материалы на ракету, ноу-хау, налоги и прочее.
COCOMOII - это не технология подсчёта коммерческой стоимости конечного результата.
Вам заказчик поручил разработать программный продукт, вы сделали оценку времени и стоимости ВАШИХ работ, т.е. труда сотрудников и создали программный продукт за 1 млн. долларов. Заказчик потом тиражируя его и продавая права мог вообще выручить за продукт 1 млрд. долларов.
При чём тут COCOMOII ?
Space X молодцы. Но кто знает их реальную кухню?
Вот если бы можно было сравнить построчно расчёт времени на проект от NASA и SpaceX......
Мне кажется, что много интересного всплыло бы про Space X.
Оставьте свое сообщение