Концептуальное проектирование
Концептуальное проектирование технических систем — начальная стадия проектирования, на которой принимаются определяющие последующий облик решения, и проводится исследование и согласование параметров созданных технических решений с возможной их организацией. Термин «концепция» применяется для описания принципа действия не только в технических системах, но и в научных, художественных и прочих видов деятельности. «Концепт» (лат.) — содержание понятия, смысл. Таким образом, проектирование на концептуальном уровне — на уровне смысла или содержания понятия систем.
Основной объем задач концептуального проектирования относится к ранним стадиям разработки технических систем (ТС): при постановке задачи на проектирование, выработке массива вариантов технических и оформительских решений и в эскизном проектировании, при создании технического задания.
Автоматизированные системы поддержки этапа концептуального проектирования
Образ объекта или его составных частей может создаваться в воображении человека в результате творческого процесса или генерироваться в соответствии с некоторыми алгоритмами в процессе взаимодействия человека и ЭВМ с помощью автоматизированных систем поддержки этапа концептуального проектирования. Работы по этой тематике велись такими учеными как А. И. Половинкин, М. Ф. Зарипов, В. А. Камаев, Р. Коллер, А. М. Дворянкин, В. А. Глазунов, С. А. Фоменков, В. М. Цуриков и т. д..
Известны несколько подходов, которые легли в основу подобных автоматизированных систем [автоматизированная система]:
ГЛАВА 14 Концептуальный проект
На этой стадии проекта основной задачей является создание Концептуального проекта SAP, в котором формулируются связанные с бизнес-процессами требования компании. Консультанты и члены группы проводят собеседования и семинары в различных подразделениях компании, чтобы составить полную картину требований к бизнес-процессам, демонстрируют функциональные возможности системы SAP R/3 с помощью системы International Demo and Education System (IDES), а также вопросников и диаграмм бизнес-процессов из модуля R/3 Business Engineer. Любые несоответствия функциональным требованиям компании анализируются и устраняются.
Крайне важно использовать в работе оригинальный компакт-диск с документацией по методологии AcceleratedSAP (ASAP). В этой главе представлены только важнейшие аспекты стадии запуска и поддержки AcceleratedSAP, но их нельзя рассматривать как полноценную замену колоссального количества инструкций, указаний, рекомендаций, списков контрольных вопросов, шаблонов, образцов и вопросников, которые предоставляются компанией SAP. Эти инструменты отлично себя зарекомендовали, поэтому настоятельно рекомендуется обратиться к версии ASAP, которая соответствует версии внедряемой системы, и использовать ее на всем протяжении реализации проекта. Читателю может показаться, что содержание некоторых глав этой книги однообразно, и многие фрагменты ее повторяются, однако в результате тщательного изучения станет ясно, что такие виды деятельности, как управление проектом, организационными изменениями, оценка рисков, спонсорство, стратегия обмена информацией и технология внедрения во многом остаются неизменными на протяжении всех этапов внедрения, и упоминаются в начале каждого этапа. Похожим образом многие мероприятия проходят через стадии планирования и исполнения, поэтому они постоянно упоминаются на различных этапах проекта, и это не повторение одного и того же, а всего лишь часть контрольного списка процессов ASAP, рекомендованных компанией SAP.
Результатом деятельности на этом этапе должен стать Концептуальный проект, в котором подробно описаны будущие бизнес-процессы, в том числе текстовое и графическое представление структуры и бизнес-процессов компании. Когда Концептуальный проект проходит стадию окончательного одобрения, он становится основой для всех последующих этапов проекта.
На данном этапе на первый план выходит один из важнейших аспектов методологии ASAP — процесс управления изменениями. Это относится к организационным вопросам и человеческому фактору, что влияет на движущую силу всего проекта внедрения SAP. Процесс управления изменениями нацелен на своевременное завершение проекта в рамках бюджета.
Управление проектом на этапе концептуального планирования
На данном этапе управление проектом в основном подразумевает мониторинг процесса создания Концептуального проекта. После того, как требования новой организационной структуры выяснены и сформулированы, становится гораздо проще определить области, в которых изменения в отношениях между бизнес-процессами и организационной структурой требуют непосредственного управления — это один из самых важных факторов окончательного определения плана проекта внедрения.
Подготовка проекта заключается в оценке и анализе потенциальных рисков, обнаруженных на этапе подготовки проекта, что подразумевает выполнение таких задач, как анализ возможных последствий, оценка основных рисков, стратегия обмена информацией и спонсорства, развитие знаний и профессиональных навыков персонала, процесс организационной оптимизации.
Проведение совещаний по статусу проекта
Эта задача нацелена на выяснение статуса проекта в зонах ответственности различных команд проекта, в том числе:
• Команды управления изменениями
Такие совещания помогают собрать информацию, на основе которой возможно выяснение статуса проекта в целом. При обнаружении любых негативных тенденций (например, отклонений от графика) принимаются корректирующие меры в отношении той или иной команды, причем эффект от этих мер в дальнейшем регулярно отслеживается. Такая деятельность оказывает прямое положительное влияние на соблюдение графика и бюджета проекта и своевременность окончательного запуска системы SAP. Подобным образом необходимо обновлять и пересматривать также и план проекта.
Проведение совещаний управляющего комитета
Проведение совещаний управляющего комитета необходимо для получения последних сведений по статусу проекта, а также для принятия решений по вопросам, которые невозможно решить на уровне менеджмента проекта, в том числе:
• изменение графика проекта
• расширение рамок проекта.
Все решения управляющего комитета записываются, эффект от принятых решений периодически отслеживается и также фиксируется.
Подготовка к этапу Концептуального проектирования
Подготовка к этапу Концептуального проектирования подразумевает создание команд по разработке и проектированию бизнес-процессов, а также определение необходимых конечным пользователям навыков, распределение ролей и областей ответственности. Все это — важнейшие факторы успеха на данном этапе проекта.
Читайте также
Глава 16 Проект, связывающий все воедино
Глава 16 Проект, связывающий все воедино В первой половине этой книги мы довольно аккуратно связали все, что было представлено, рассмотрев V7 ls.c. Однако, нет достаточно небольшой программы, насколько бы это нам хотелось, чтобы связать воедино все концепции и API,
Проект
Проект Средства управления проектами в Geany, как штатные, так и альтернативные,, реализованные в качестве плагинов, будут предметом отдельного
Проект
Проект Является предприятием, которое требует совместных усилий, сосредоточенных на разработке и/или сопровождении конкретного продукта. Продукт может включать в себя оборудование, программное обеспечение и другие компоненты. Обычно проект имеет собственное
Проект MythTV
Проект MythTV Вдохновитель проекта Исаак Ричардс, начавший работу над MythTV в апреле 2002 года, мотивировал свой поступок отсутствием необходимых и удобных программ, которые бы позволяли не только смотреть видео, ТВ, слушать музыку, но и работать с почтой, просматривать новости.
Проект Freevo
Проект Freevo Канадец Кристер Лагерстром был одним из тех, кому не нравилось текущее положение дел в работе с мультимедиа в Linux. Программа, созданная им на языке высокого уровня Python, называается Freevo. На момент выхода первой версии (май 2002 года) это был довольно примитивный
Проект Wine
Проект Wine Wine (http://www.winehq.org/) – это альтернативная реализация Windows API для UNIX-подобных систем. В этих системах она позволяет выполнять многие приложения, написанные для Windows. Название является рекурсивным акронимом от Wine Is Not an Emulator (Wine – не эмулятор). По прошествии 15 лет
Проект Cedega
Проект Cedega Большей популярностью пользуются коммерческие решения, позволяющие запускать многие приложения, написанные для Windows в Linux, построенные на основе исходных кодов Wine. В первое время Wine выходил под лицензией MIT, которая разрешала одностороннее использование
Проект ArCon
Проект ArCon В общем случае проектом в программе называется полностью завершенная, проработанная до мелочей модель дома (коттеджа или общественного здания) или группы домов, включающая внутреннюю обстановку, элементы окружения (рельеф, объекты экстерьера), полностью
Проект русификации PGP 5.0
Проект русификации PGP 5.0 Ряд правительств серьезно наказывает своих граждан за использование шифрованных коммуникаций. В некоторых странах вас даже могут за это расстрелять. Но если вы живете в такой стране, возможно, PGP вам тем более
Проект записи CD-ROM
Проект записи CD-ROM Программа Nero Burning ROM является одной из самых функциональных программ для записи компакт-дисков. Она производится немецкой компанией Аhead. Интерфейс к программе многоязычный, так что пользователь может выбрать язык по своему желанию. Для этого ему
Проект OpenBSD[9]
Проект OpenBSD[9] Уже год, как вы занимаетесь бизнесом в Интернете, и вы только начали получать прибыль. Наконец-то на взлете! Вы счастливы, став одним из первых, поставивших свой бизнес в Сети, который движется и приносит вам прибыль. Вы забрались на новую территорию, которая
8.12. ПРОЕКТ АСУ ПРЕДПРИЯТИЯ
8.12. ПРОЕКТ АСУ ПРЕДПРИЯТИЯ Развивая идею использования контейнеров А. Усова, можно получить идею системы генерации все новых программ с используемыми «кубиками» — готовыми объектами, которые при формировании программы автоматически извлекаются
Интегрированное концептуальное проектирование как инструмент системного инжиниринга
18 Января 2017 В.П. Батрашкин, Р.Р. Исмагилов, Р.А. Панов (ООО «Газпромнефть-Развитие»), А.Ф. Можчиль, Н.З. Гильмутдинова, Д.Е. Дмитриев, Научно-Технический Центр «Газпром нефти» (ООО «Газпромнефть НТЦ»)
Концептуальное проектирование представляет собой начальную стадию жизненного цикла объекта, на которой зарождаются основные идеи и решения по реализации проекта, оказывающие максимальное влияние на проект в целом и позволяющие своевременно оценить его эффективность и риски. Максимальный эффект на этапе концептуального проектирования достигается за счет применения интегрированного подхода, объединяющего в одном проектном процессе выработку взаимосвязанных решений как по разработке, так и по комплексному обустройству месторождения.
В настоящее время в ПАО «Газпром нефть» проявляется интерес к интегрированным подходам в области концептуального инжиниринга, что обусловлено следующими факторами:
— сокращением разведанных запасов и вовлечением в разработку новых участков, характеризующихся высокой степенью сложности и неопределенности;
— разработкой новых месторождений со слаборазвитой инфраструктурой;
— вовлечением в разработку большого числа объектов и необходимостью проведения быстрых инженерных расчетов.
На зрелых месторождениях поддержание уровня добычи требует повышения эффективности разработки и оперативного реагирования на изменения макросреды. Это означает, что для принятия обоснованных технологических решений на каждом этапе проектирования необходимо:
— учитывать взаимосвязь пласта, скважины и наземной инфраструктуры;
— проводить многовариантные расчеты в условиях неопределенностей;
— объективно оценивать затраты на бурение и инфраструктуру.
Внедрение интегрированного подхода осложняется существенным увеличением числа прорабатываемых вариантов, использованием различных подходов и методик для пласта, скважины и поверхностного обустройства с обеспечением их взаимосвязи, различных программных продуктов, необходимостью переноса данных из одних программ в другие.
Для полного соответствия концептуальных решений по разработке и обустройству с целью сокращения трудозатрат на их итерационную оптимизацию и адаптацию в ПАО «Газпром нефть» реализуется проект по разработке информационной системы интегрированного концептуального проектирования разработки и обустройства месторождений.
Оснащение специалистов, занимающихся разработкой месторождений, добычей, строительством скважин, проектированием систем поверхностного обустройства и экономическим расчетами, инструментами проектирования, реализованными на одной общей информационной платформе, позволяет существенно повысить эффективность выполнения работ за счет:
— автоматизации расчетов и реализации оптимизационных алгоритмов;
— выполнения серийных расчетов для исходных данных, задаваемых интервалами неопределенности;
— автоматизации передачи информации между отдельными функциональными блоками.
Развиваемая система является отражением процессов развития инжиниринга как функционального направления в целом.
Концепция инструмента интегрированного проектирования
Разрабатываемый ИТ-продукт позволяет объединять продуктивный пласт, скважины, наземную инфраструктуру, а также финансовые показатели и экономические условия в единую интегрированную модель. Архитектура системы построена по модульному принципу и обеспечивает поэтапное развитие инструментария. Это возводит систему в ранг единой цифровой платформы для инженерных моделей различных систем, рассматриваемых в рамках концептуального инжиниринга.
Каждый модуль программного продукта способен решать локальные задачи для поиска субоптимального решения и представляет собой отдельную дисциплину (область знаний), по которой в рамках интегрированного проектирования выполняются расчеты (рис. 1).
Рис. 1. Модульная структура системы
Интеграция модулей между собой позволяет решать оптимизационные задачи в масштабе проекта. Ключевой модуль программного продукта — интегратор — обеспечивает взаимосвязь модулей и позволяет реализовать итерационный подход к решению оптимизационной задачи снижения суммарных затрат на бурение и инфраструктуру.
Формирование оптимального варианта по разработке и обустройству месторождения Уникальная инжиниринговая технология, реализуемая в программном продукте, основана на выполнении серийного расчета по выбору оптимальных систем разработки и обустройства (рис. 2).
Рис. 2. Блок-схема выполнения интегрированного концептуального проекта
Серийный расчет по выбору оптимальной системы разработки выполняется для одного набора исходных данных для базового варианта системы обустройства. Для определения параметров разработки предусмотрена интеграция с информационной системой компании «Выбор оптимальной системы разработки», который позволяет получить данные по координатам и типу забоев скважин, профилям добычи и закачки по скважинам (рис. 3).
Рис. 3. Результаты расчета системы разработки
Реализуются следующие сценарии расчета системы разработки.
1) параметров сетки скважин;
2) параметров сетки скважин и профилей добычи по скважинам;
3) параметров сетки скважин и профилей добычи по скважинам с учетом карт применимости технологии добычи;
4) профилей добычи с учетом корректировки дат ввода скважин в эксплуатацию.
Серийный расчет по выбору оптимальной системы обустройства выполняется на базе одного рекомендуемого варианта системы разработки.
Для формирования оптимального варианта по обустройству месторождения в рамках реализуемого проекта разрабатываются функциональные модули.
1. Кустование скважин. Проводится с учетом их геологического рейтинга и максимизации темпов добычи на начальном этапе разработки месторождения (рис. 4, 5).
Рис. 4. Ввод параметров скважин для расчета кустования
Рис. 5. Кустование скважин
2. Расчет графика бурения скважин. Выполняются расчеты последовательности ввода кустовых площадок на основе геологического рейтинга скважин, графика бурения и ввода в эксплуатацию скважин, на основе последнего пересчитываются профили добычи и закачки по скважинам.
3. Расчет параметров технологии добычи. Способ эксплуатации определяется на базе применимости технологий в зависимости от дебита жидкости и газа на основе полученных данных по конструкции скважины с учетом граничных условий по давлению на устье или забое скважины.
4. Определение параметров системы обустройства, включая системы сбора и подготовки нефти и газа, внешнего транспорта, утилизации нефтяного газа и энергоснабжения (рис. 6).
Рис. 6. Результаты расчета системы обустройства
Граничными условиями выполнения серийного расчета системы обустройства в автоматическом режиме являются диапазоны значений по следующим параметрам:
— максимальная протяженность скважин;
— число и график работы буровых установок;
— число центров сбора продукции скважин;
— варианты по точкам сдачи товарной нефти;
— варианты по энергоснабжению объектов обустройства;
— варианты по утилизации нефтяного газа.
В итоге выбирается оптимальная система обустройства по результатам расчетов экономического модуля, где проводятся расчеты капитальных вложений и эксплуатационных затрат с использованием расчетных модулей и базы данных разрабатываемых в компании систем Стоимостного инжиниринга, показателей экономической эффективности на основе финансовоэкономической модели, рейтинга экономической эффективности по кустовым площадкам.
Если результат расчетов оптимальной системы обустройства существенно расходится с исходными данными для расчета базового варианта обустройства при расчете оптимальной системы разработки, то предусматривается возможность внесения изменений в исходные данные для расчета базового варианта системы обустройства и повтора расчета по выбору оптимальной системы разработки.
Выводы
1. Развитие технологий и инструментов проектирования позволит снизить затраты по проектам разработки и обустройства, повысить качество выполнения проектов за счет автоматизации расчетов и проработки различных вариантов с выбором оптимального. Ожидается рост экономической эффективности как для новых так и для текущих проектов компании.
2. Повышение уровня интеграции проектной команды и вовлеченности экспертов создает прозрачную модель принятия решений и дает возможность отслеживать эволюцию проекта.
3. Внедрение интегрированного проектировани позволит сократить трудозатраты, что обусловлено оперативностью выполнения в цифровой модели как отдельных расчетных операций, так и всего итерационного цикла. Также снижение трудозатрат будет достигнуто за счет автоматизации хранения, обработки и передачи информации между службами (Геология и разработка, Бурение, Поверхностное обустройство, Стоимостной инжиниринг, Экономика и др.).
4. В перспективе система интегрированного проектирования позволит развивать технологии оптимального трассирования трубопроводов, выполнять генеральное планирование на предпроектных стадиях, создавать инженерно-логистические модели добычи и транспорта нефти.
5. Оптимальные проектные решения по всем системам с учетом их взаимовлияния, повышение глубины проработки оптимального варианта и анализ рисков позволят уверенно принимать инвестиционные решения.
Список литературы
1. Иерархия интегрированных моделей/М.М. Хасанов, И.С. Афанасьев, А.Р. Латыпов и [др.] // SPE 117412. — 2008.
2. Интегрированная модель для комплексного управления разработкой и обустройством месторождений/Р.Р. Исмагилов, Ю.В. Максимов, О.С. Ушмаев [и др.] //Нефтяное хозяйство. — 2014. — № 12. — С.
3. Оптимизация капитальных вложений в строительство скважин при концептуальном проектировании разработки месторождений/В.А. Карсаков, С.В. Третьяков, С.С. Девятьяров, А.Г, Пасынков //Нефтяное хозяйство. — 2013. — № 12. — С.
4. Повышение точности оценки капитальных вложений на ранних стадиях реализации проектов/ М.М. Хасанов, Д.А. Сугаипов, А.В. Жагрин [и др.] //Нефтяное хозяйство. — 2014. — № 12. — С.
5. Развитие кост-инжиниринга в ОАО «Газпром нефть» / М.М. Хасанов, Д.А. Сугаипов, О.С. Ушмаев [и др.]//Нефтяное хозяйство. — 2013. — № 12. — C.
Для чего нужно концептуальное проектирование в разработке?
Коротко: как в Skipp описывают задачу разработчикам
У традиционного ТЗ, даже если это документ на сто страниц по ГОСТу, много проблем. На рынке все пишут ТЗ по-своему, заказчику в принципе сложно написать полное ТЗ самому, а разработчикам сложно однозначно оценить его.
Когда клиент обращается в Skipp, мы не пишем ему ТЗ, а вместе проходим три этапа предпроектной подготовки. Ими можно заниматься параллельно, но общий логический порядок устроен так:
Концептуальное проектирование, которое клиенту поможет сделать продакт-менеджер. Они вместе разберутся, какой нужен продукт, и создадут USM.
Визуальное проектирование, которое поможет сделать UX-дизайнер. Он продумает интерфейсы, набросает базовый дизайн и создаст прототипы разной степени детализации.
Функциональная спецификация, которой займётся руководитель проекта — продакт, проджект или скрам мастер. Он создаст фич-лист: опишет механику и технологии функций, которые придумали в USM, даст ссылку на прототип или приложит скриншоты.
USM, прототип и фич-лист мы отправим на оценку нескольким командам разработки. По опыту мы знаем: с таким ТЗ клиент получает более однородные и точные оценки от команд, а разработчикам проще провести декомпозицию и собрать бэклог.
Концептуальное проектирование: объяснить, что пользователь может сделать
Сначала продакт-менеджер Skipp помогает заказчику разобраться, какие задачи должен решать будущий продукт. Менеджер проводит продуктовое интервью с клиентом, может проанализировать конкурентов или провести глубинные интервью с представителями целевой аудитории. Словом, он погружается в задачу и использует весь свой арсенал, чтобы помочь заказчику понять, какой продукт нужно сделать.
Затем продакт-менеджер вместе с заказчиком определяет, какая функциональность будет в продукте. Они описывают, какие пользователи будут контактировать с ним, что и как смогут сделать. Результаты проектирования можно переложить в текст, визуализировать в схемах или интеллект-картах. На этом этапе дизайн не важен, главное — понять список функций, которые будут в продукте.
Итог концептуального проектирования в Skipp — User Story Map (USM). Это карта ролей пользователей и действий, которые они совершают с ИТ-продуктом. Если мы делаем приложение интернет-магазина, то в USM продакт опишет, как клиент будет его использовать.
Например: «Клиент может авторизоваться, смотреть каталог товаров, добавлять товары в «Избранное», класть в корзину и оплачивать». Последовательный набор действий это и есть User Story, то есть, пользовательская история.
USM — гибкий инструмент, который можно сделать с разным уровнем детализации. Допустим, вы хотите сначала сделать MVP, а затем постепенно добавлять в него новые модули.
Тогда на основе User Stories будет удобно собирать список функций для MVP: нужно взять в первый релиз только критически важные функции, без которых пользователь не сможет пройти путь до конца. Можно детализировать USM ещё сильнее и на основе выбранных функций создать список верхнеуровневых задач для разработчиков.
Заказчик может сам провести концептуальное проектирование. Но ему будет легче, если с ним в связке работает продакт-менеджер или продуктовый дизайнер: как правило, у них больше опыта в проектировании и выше насмотренность. С продактом получится быстрее провести исследование пользователей и найти выигрышные решения.
Почему этап важно сделать
Во время концептуального проектирования вы переходите от абстрактной идеи к описанию функций продукта. Заново проходитесь по проблемам и задачам пользователей, конкретизируете требования.
USM даёт разработчикам возможность провести первичную оценку трудозатрат и сроков. На этом этапе вы определяете, какая функциональность нужна в продукте.
Например, будет ли в приложении модуль авторизации и личный кабинет, будет ли там чат, потребуется ли пользователю загружать файлы. Если концептуальное проектирование провели подробно, по нему уже можно провести декомпозицию на задачи и примерно оценить стоимость.
Концептуальное проектирование помогает провести корректную работу с требованиями. Полный USM, с которым все в согласии — означает что требования ограничены, непротиворечивы и приемлемы. Это значит, вы выяснили, что и зачем создаёте, что будет считаться успехом. Вы обосновали требования, придумали, как их протестировать, согласовали со стейкхолдерами и командой и убедились, что требования не взаимоисключают друг друга, а вся необходимая функциональность учтена. Серафим Бахарев Менеджер продукта, работает со Skipp
Что будет, если не сделать
Если не провести концептуальное проектирование, вырастет риск, что клиент будет ждать одно, а разработчики сделают совсем другое. Например, у заказчика могут быть некорректные ожидания о продукте. Или разработчикам придётся самостоятельно додумать, какие функции нужны каждой группе пользователей.
Вовлечённость заказчика
Максимальная: заказчик передаёт материалы, вместе с нами изучает конкурентов и результаты глубинных интервью, синтезирует идеи.
Артефакт этапа в Skipp
User Story Map в Miro или Figma, результаты анализа в Notion.
Фрагмент USM приложения для изучения иностранного языка
