RICEFS-классификация разработок и настроек для оценки трудозатрат

Подробности

Опубликовано: 31.12.2023 14:25

Автор: Катасонова Наталья Сергеевна

Просмотров: 1329

Аннотация: в работе предлагается подход к оценке трудозатрат разработок и настроек ERP-систем. Способ оценивания включает такие шаги, как: формирование оценщика плановых трудозатрат, анализ бизнес-требований, идентификация функциональных требований, проведение Fit/Gap-анализа, группировка и разгруппировка потребностей, RICEFS-классификация и финальный расчет трудозатрат. Предлагаемый подход применим как для проектов реализации кастомных разработок, так и коробочных решений.
Скачать: PDF (статья), PDF (выпуск №24).
Ключевые слова: ricef, классификация прикладных программ, виды программного обеспечения компьютеров, метод оценки трудозатрат, методики оценки трудозатрат, оценка трудозатрат на тестирование, оценка трудозатрат на разработку по, оценка трудозатрат, рабочие человеко дни, расчет трудозатрат на разработку программы, методика расчета трудозатрат, классификация ricefw, ricef классификация, функциональный дефицит.

Внедрение практически любой ERP-системы требует как ее донастройки, так и доработки. Важное место в ходе имплементации имеют именно программные доработки, занимающие львиную долю проекта по сравнению с активностями кастомизации. От того, как правильно вы подойдете к вопросу планирования и реализации доработок, зависит успех ERP-проекта. Согласно статистике проектов внедрения, более 40% бизнес-потребностей пользователей требуют программной доработки, следовательно качественное планирование работ на проекте немыслимо без унифицированного подхода к оценке плановых трудозатрат на реализацию [1]. В связи с этим, в этой статье хотелось бы затронуть вопрос плановой оценки трудозатрат доработок и донастроек корпоративной информационной системы.

Начнем с основ: потребности заказчика в информационной системе покрываются или ее доработкой, или ее донастройкой, или уже реализованы и не требуют дополнительных усилий. Первые два исхода задают Gap-область, последняя – Fit (рис. 1). Все доделки Gap-области можно классифицировать согласно RICEFS подходу [2], что представляет собой сокращение от англоязычных слов: Report, Interface, Conversion, Enhancement, Form и S (отчет, интерфейс, программа обработки данных, расширение, печатная форма и настройка). Введя термин сложности (низкая, средняя, высокая и очень высокая), можно построить элементарный Оценщик (от английского Estimate, оценивать) [3]. В нем для каждой пары «Тип разработки – сложность» эмпирически задаются плановые трудозатраты для этапов проектирования и разработки, то есть ресурсы функциональных консультантов на фазе дизайна и разработчиков для этапа разработки (табл. 2). Более сложные формы оценщика включают дополнительные параметры: новая разработка или модификация имеющейся, %-переиспользования, а также оценку трудозатрат не только для фаз проектирования и реализации, но и этапов анализа, теста и перехода.

Рис. 1. Fit и Gap области

В проект внедрения может быть вовлечено не одно, а несколько юридических лиц или других организационных сущностей, в разрезе которых ведется донастройка и доработка информационной системы. Назовем их организационными уровнями. Влияет ли число оргуровней на разработку и как это учесть в оценке? Давайте разберемся. В случае, если несколько оргуровней предъявляют одинаковые требования к разработке, то на оценке последней это никак не сказывается. В противном случае мы можем апеллировать сложностью доработки: или повышаем ее для реализации общего для всех оргуровней требования или группируем схожие требования для набора оргуровней, а далее ведем оценку каждой группы отдельно (см. табл. 3, требований 3.1-3.2). Если с оценкой доработок все достаточно прозрачно, то с настройками придется повозиться.

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

Трудозатраты = Трудозатраты(сложность) * (1 + (N-1)*%– переиспользования),

где Трудозатраты(сложность) – затраты в зависимости от сложности согласно Оценщику, N – число оргуровней, %-переиспользования аналогичен схожему параметру при оценке разработок и принимает значение 50% по умолчанию (см. табл. 3, требование 14). Если сложность для разных оргуровней сильно отличается, то предлагается поступить так же, как и в случае с разработками: разбить группы настроек по оргуровням в разрезе сложности и оценить их по формуле выше независимо (см. табл. 3, требований 3.1-3.2).

Оценке трудозатрат по указанной схеме подлежат как пользовательские требования из технического задания (ТЗ), так и функциональные потребности, которые могут отсутствовать в документе ТЗ. Функциональные требования, представляют собой обязательные технические требования, без реализации которых программное решение попросту не заработает. Например, в ТЗ явно прописана необходимость согласования документов заказов на закупку, что представляет собой пользовательское требование, однако явно не указана потребность в создании, изменении и удалении подобных документов. Тогда функционал ведения заказов есть ни что иное как функциональное требование, над которым будет настраиваться схема подтверждения (см. табл. 2).

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

Для полноценной работы предложенной схемы для расчета плановых трудозатрат требуется предварительное формирование Оценщика (см. табл. 1). Кроме того, найденные значения трудозатрат следует дополнить: так трудозатраты, оцененные для реализации, относятся только к разработчикам, следовательно схожий по трудозатратам объем работ необходимо запланировать для функциональных консультантов и/или тестировщиков, которые будут участвовать в модульном или системном тестировании, для чего возможно воспользоваться методом построения ресурсного плана на основе бенчмаркинга этапов [3].

Теперь рассмотрим практический пример. В компанию интегратора приходит техническое задание (ТЗ) на реализацию проекта по внедрению модуля ММ в программной системе SAP ERP. Тендерное задание содержит 10-ть пользовательских требований (табл. 2). Оценка трудозатрат будет включать нижеприведенные шаги.

1-й шаг: формирование Оценщика. Для оценки трудозатрат реализации требований из ТЗ интегратор создает Оценщик, согласно RICEFS-классификации, обогащенный данными, применимыми не только для разработок, но индивидуальных и групповых настроек (табл. 1). В оценку включаются плановые затраты консультантов для подготовки документов настроек, спецификаций на разработку и проектных решений на этапе проектирования, а также на разработку программ, ведение настроек и функционально-модульное испытание SAP ERP на фазе реализации.

Таблица 1. Оценщик трудозатрат проектирования и реализации

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

Таблица 2. Пользовательские и уточненные функциональные требования

3-й шаг: группировка и разгруппировка требований, Fit/Gap-анализ, RICEFS-классификация и оценка. Применим Оценщик для нахождения трудозатрат. Для этого над каждым требованием из табл. 2 проводится экспертный анализ реализовано ли оно в стандартном пакете SAP ERP или необходима доработка, донастройка: проставляется индикация Fit или Gap. Далее для Gap-записей задается пара «Тип – сложность», предварительно сгруппировав настройки и разработки согласно ранее описанному алгоритму. Завершающим шагом служит указание %–переиспользования для требований, зависящих от числа организационных уровней. Финальные расчеты приведены в табл. 3, следуя данным которой, трудозатраты функциональных консультантов на этапе проектирования составляют 53 чел.дн., в то время как разработчиков и консультантов для реализации доработок и настроек – 93 чел.дн.

Таблица 3. Матрица отслеживания требований с результатами Fit/Gap-анализа и оценкой трудозатрат

Получение результатов табл. 3 требует времени и усилий: анализ бизнес-требований, идентификация функциональных требований, проведение Fit/Gap-анализа и др., что немыслимо без участия экспертов в области ERP-систем. Однако трудозатраты, получаемые в этом случае, достаточно обоснованы и подкреплены конкретными потребностями заказчика, что соответствует расчету «Снизу вверх». Не хотите тратить столько времени, то доступна менее формализованная опция по расчету трудозатрат экспертным образом: «Сверху вниз».

Литература

1. Калянов Г.Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. – М.: Горячая линия – Телеком, 2014. – 210 с.
2. Степанов Д.Ю. Подготовка функциональных спецификаций для разработки корпоративных информационных систем на примере SAP ERP (часть 1) // Корпоративные информационные системы. – 2019. – №3(7). – С. 29-52. – URL: https://corpinfosys.ru/29-archive/2019-7/66-2019-7-functionalspec.
3. Степанов Д.Ю. Метод формирования ресурсного плана в проектах внедрения ERP-систем на основе бенчмаркинга и оценщика // Высокопроизводительные вычислительные системы и технологии. – 2022. – Т.4, № 1. – c.1-6. – URL: http://stepanovd.com/science/article/135-2022-1-resourceplan.

Выходные данные статьи

Катасонова Н.С. RICEFS-классификация разработок и настроек для оценки трудозатрат // Корпоративные информационные системы. – 2023. – №4 (24) – С. 26-37. – URL: https://corpinfosys.ru/archive/2023/issue-24/230-2023-24-ricefclassification. 

Об авторе

Катасонова Наталья Сергеевна – выпускник кафедры оптических и биотехнических систем и технологий физико-технологического института РТУ МИРЭА. Тема выпускной квалификационной работы магистра «Применение каскадной, итерационной и спиралевидной моделей внедрения информационных систем для автоматизации городской больницы». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №24

1. Жизненный цикл корпоративных информационных систем (часть 1);
2. Каскадная методология для разработки мобильных приложений (часть 2);
3. О системах налогообложения в РФ в 2024 году;
4. RICEFS-классификация разработок и настроек.