1с сппр что это

Обновлено: 07.07.2024


В чём содержание определения «СППР многими используется неправильно»?

Во-первых, абсолютное большинство использующих СППР взваливают её на разработчиков.

В таких случаях разработчики отвечают за описание функциональности учётных систем в СППР и за составление задач на разработку.

Вот это и есть неправильно.

С такими задачами справится и JIRA и ей подобные бесплатные продукты.

Работа разработчика в СППР не предусмотрена. СППР должна выдавать разработчику задачи на разработку.

Разработчик от СППР, а значит от совсем других участников проекта, должен получать готовые, детально описанные ТЗ.

Во-вторых, даже работа только системного архитектора в СППР недостаточна.

СППР будет эффективна только тогда, когда в ней будет сделано описание бизнес-процессов организации и, отдельно, описание функциональности программного продукта (разрабатываемого или внедряемого).

А архитектор должен связать каждый бизнес-процесс с функцией системы.

Если чего-то не хватает, то либо делается вывод, что система не подходит под процессы клиента, либо функциональность системы дорабатывается (проектируется в СППР!).

image

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

Вывод — любой проект по внедрению СППР обречён на провал, если он вешается на разработчиков.

СППР должна начинать работу гораздо раньше — при сборе требований и описании бизнес-процессов.

P.S. Модная тема СППР+Vanessa…

Если в СППР делать описание процессов (шагов процессов) по операциям пользователей, то,

фактически, можно получить последовательность операндов языка Геркин для Ванессы.

Т.е. почти готовый сценарий.

Опять вывод, из посткриптума — сценарии должны писать не тестировщики, а те, кто описывает процессы.

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

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

СППР представляет собой конфигурацию, предназначенную для использования с платформой "1С:Предприятие 8.3".

Использование "1С:Предприятие 8. Система проектирования прикладных решений" (СППР) позволяет
  • Организовать централизованный учет требований и пожеланий к информационной системе.
  • Выстроить целостную модель системы, отталкиваясь от автоматизируемых процессов, с возможностью проверки корректности модели.
  • Управлять изменениями в проекте.
  • Формировать план выполнения проекта.
  • Анализировать завершенность проекта (выполнение необходимых задач, отсутствие ошибок).
  • Упростить подготовку справочной информации в едином стиле, с учетом структуры конфигурации и взаимосвязей различных объектов конфигурации.
  • Использовать проектные материалы при подготовке документации и других материалов.
  • Получить доступ к проектным материалам, описывающим тестируемый функционал.
  • Обеспечить регистрацию и отслеживание ошибок.
  • Разобраться в типовом решении, используя проектную документацию.
  • Соотнести реальные процессы предприятия с моделью системы, проанализировав покрытие процессов функционалом и выявив необходимость доработок.
  • Органично внести собственные доработки в типовой функционал с выверкой полученной модели.
  • Упростить освоение конфигурации пользователями, формировать инструкции по работе с конкретным функционалом.


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

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

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

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

Наличие формальных правил проверки дает возможность выявить и устранить ошибки и несоответствия в проекте.

Система включает механизмы регистрации и отслеживания ошибок с учетом включаемых конфигураций-библиотек.

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

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

Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем?». Достаточно популярным, особенно в среде 1С специалистов, является мнение что проектирование системы - это лишние трудозатраты. Я бы сказал, оно не безосновательно. Многие из задач при внедрении систем являются довольно стандартными и требуют лишь трудозатрат на разработку. Очень часто не создается новых механизмов и инструментов, а лишь «дотачиваются» существующие, притом под нужды заказчика, которые регулярно меняются.

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

А когда проектирование имеет смысл:

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


Собственно, все начинается со стратегии. Инструментарий для создания стратегии компании редко бывает специализированным. Это скорее нечто, что должно быть в голове у топ менеджера. Далее строится модель бизнес процессов (которая должна присутствовать для достижения стратегических целей). Здесь уже в ход идут инструменты моделирования – ARIS , Business Studio . И только после этого речь заходит о модели ИТ процессов. У «продвинутых» западных вендоров для этого есть специализированные средства – У SAP интегрированный ARIS , у IBM – RUP , у Microsoft – MSF , интегрированная в Visual Studio . Вот и у 1С появился собственный инструмент – 1С:СППР.

Теперь возникает второй вопрос: «А как на практике используется 1С:СППР»? В данном случае могу рассказать только о своей личной практике. К сожалению, она может не совпадать с тем, для чего в 1С планировали 1С:СППР. В моей практике 1С:СППР использовался для следующих задач:

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

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


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

В итоге, все функции, которые, на мой взгляд, должны лечь на 1С:СППР можно разбить на следующие 4 части:

1) Функции моделирования

a. Модель системы, связь с моделью БП (в разных нотациях)

b. Связь модели системы с метаданными и алгоритмами 1С

c. Интеграция со средами моделирования

2) Функции коллективной работы

a. Работа с требованиям

b. Работа с ошибками

3) Функции документирования

a. Связь документации с моделью

b. Экспорт документации в 1С и Word

4) Функции организации разработки и тестирования

a. Спецификации и задачи на разработку

b. Результаты тестирования и отработки ошибок

В типовой 1С:СППР очень хорошо реализован блок (1), за исключением того, что хотелось бы конечно иметь возможность представлять модель в разных нотациях. Нам была ближе EPC , в 1С:СППР реализована только IDEF 0.

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

С документированием возникают уже проблемы. Основной функционал, которого не хватает 1С:СППР – экспорт в Word . Ведь итогом работы проектировщика должна быть спецификация на разработку (ТЗ/ЧТЗ – кто как называет). А спецификация - это нечто, что человек должен иметь возможность прочитать; то есть текстовый файл. Опять же, вордовским файлом должна оформляться документация по системе и проектная документация. Но традиционно 1С не сильно любит интегрироваться с продуктами Microsoft Office . Это противоречит принципам кроссплатформенности, делает решение зависимым от внешних приложений и существенно увеличивает сложность разработки.

Функционала для организации разработки и тестирования в 1 C :СППР просто не существует. Хотя не понятно почему. Редко встретишь опытного разработчика, который хоть раз в своей жизни не написал бы систему учета задач. Если ориентироваться на тот же SAP – в Solution Manager есть как функционал проектирования так и полноценный Service Desk .

Собственно, данный функционал относительно СППР был доработан – основные доработки 1С:СППР касались вывода в Word и создания системы учета задач.

Теперь более подробно рассмотрим функционал типовой 1С:СППР новой версии:


Итак, относительно первой версии появилось много чего интересного:

1) Нормальная работа с метаданными – загрузка метаданных непосредственно из конфигурации, представление, дополнительные свойства объектов метаданных. На разработку подобного функционала в первой версии мы потратили значительное количество времени.

2) Моделирование системы в нотации IDEF . 1С много затратили на разработку данного функционала. Действительно существенный шаг вперед, но, как писал выше, для нас оказалась привычнее и удобнее нотация EPC . Она в 1С:СППР, к сожалению, не реализована.

3) Сбор требований. Функционал очень нужный на проектах.

4) ER модель метаданных. Первое впечатление было «мечта студента». Если кто-то писал диплом по 1С это бы существенно помогло. На самом деле функционал очень полезен и в повседневной рабочей практике. Даже просто загрузив в 1С:СППР механизмы типового прикладного решения построив ER диаграмму по нужным объектам можно гораздо быстрее и проще разобраться как работает тот или иной механизм. О пользе подобных диаграмм при составлении спецификаций можно и не говорить. За данную возможность можно сказать «большое спасибо».

5) Работа с ошибками, тоже очень нужный, но достаточно простой механизм системы.

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

Как у нас используется 1С:СППР. Вполне возможно наш случай – не типичный сценарий, как его планировали 1С. Общая схема выглядит примерно следующим образом:


Скорее всего в типовом сценарии использования, предусмотренным 1С, не подразумевается работа в системе тестировщиков и разработчиков. Так же не предусмотрено детальное описание алгоритмов.

Итак, что мы получаем от использования 1С:СППР:

1) Разработчики отделены от проектировщиков. Best Practice из SAP welcome . Наверное, это правильно, но для того, чтобы это было возможно, система просто необходима. В то же время, при наличии такой системы мы можем сказать, что практически любой разработчик способен выполнять работы практически по любой задаче. Это «открывает двери». Например сегодня у вас 3 разработчика, а завтра может стать 30… т.е. варианты для привлечения внешних подрядчиков не ограничены.

2) Генерация проектной документации. В нашем случае ее просто тома. Представьте к примеру задачу описать все метаданные УПП… 1С:СППР просто в десятки раз упрощает данный процесс.

3) Учет задач – когда он интегрирован это очень удобно. Разработчик может сразу видеть все по назначенной задаче. При необходимости может подняться «уровнем выше» чтобы что-то понять/уточнить для себя. Как проектировщик так и разработчик могут оценивать трудозатраты на разработку и согласовывать оценки. Разработчик может писать вопросы к спецификациями и оперативно наблюдать изменения в них

4) Весь проект есть в системе. По каждому объекту метаданных вы можете отследить когда, для чего и зачем он был сделан.

Мы уже пошли в чем то дальше чем 1С:СППР в развитии системы, но есть вещи которых нахватает как в нашей системе так и в типовой 1С:СППР:

1) Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы ее полезность.

2) Связь с хранилищем конфигурации. Конечно последнего этапа в цепочке не хватает немного. Если бы в системе можно было получить информацию по какому заданию/спецификации была эта разработка?

3) Интеграции с ARIS/Business Studio. К сожалению, встроенные средства 1С существенно проигрывают специализированным в плане удобства и функциональности для постраения диаграмм EPC / IDEF .

Итого, 1С:СППР очень функциональный и полезный в практике продукт. Очевидно, что 1С движется в правильном направлении. Может что-то еще не так, чего-то не хватает, поэтому с нетерпением ждем развития системы, ну или дорабатываем сами.

Статья рассматривает способ использования 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.

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

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

Псевдокод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

Читайте также: