Схема этапов проектирования согласования и строительства объектов

Проектирование (от латинского projectus , что означает «брошенный вперед») — это процесс составления описания, необходимого для создания в заданных условиях еще не существующего объекта по первичному описанию путем детализации, дополнения, расчетов и оптимизации.

Проектная процедура – это взаимосвязанная, взаимообусловленная совокупность действий, направленных на получение проектных решений.

Проектное решение – промежуточное или окончательное описание объекта проектирования, необходимое и достаточное для продолжения или окончания проектирования или вариант проекта, удовлетворяющий требованиям технического задания (ТЗ) (промежуточное или конечное описание объекта проектирования).

В этих определениях практически не оговариваются требования по качеству результатов проектирования.

Эффективное проектное решение – описание объекта, принципиально выполняющего требуемые функции или проектное решение, принципиально отвечающее требованиям ТЗ.

Оптимальное проектное решение – описание объекта, наилучшим образом выполняющего требуемые функции или проектное решение, наилучшим образом отвечающее требованиям ТЗ.

Лекция «Этапы и стадии проектирования зданий и сооружений»

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

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

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

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

Принятие проектного решения – выбор варианта проекта из имеющихся альтернативных вариантов по результатам анализа или выбор варианта проекта с учётом требований ТЗ на основе результатов анализа.

Термин «принятие проектного решения» имеет и другой смысл: часто под ним понимают общий процесс определения множества вариантов проекта, задания принципа оптимальности и выбор лучшего варианта.

Моделирование или создание модели объекта проектирования является проектной операцией, связанной с каждой из двух других проектных операций: синтезом и анализом. Поэтому далее моделирование или создание модели объекта будет рассмотрено подробно.

Процесс получения проектного решения имеет явно выраженный итерационный характер, иллюстрируемый блок-схемой на рис.1.

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

«Российская система управления жизненным циклом объектов проектирования и строительства КАПСТРОЙ»

Рис.1. Итерационный процесс получения проектного решения

Процесс проектирования во времени разделяется на стадии и этапы.

В соответствии с системным подходом к проектированию принято укрупнённо выделять следующие стадии проектирования:
1) Внешнее проектирование – конкретизация целей и задач объекта проектирования и определение требований к его функционированию.
2) Формирование облика будущего объекта – корректное согласование требований внешнего проектирования с возможностями внутреннего проектирования.
3) Внутреннее проектирование – реализация проектируемого объекта с заданными свойствами.

При более детальном рассмотрении выделяют следующие стадий проектных работ:
1) Предпроектные исследования (изыскания).
2) ТЗ.
3) Техническое предложение.
4) Эскизное проектирование (эскизный проект).
5) Техническое проектирование (технический проект).
6) Рабочее проектирование (рабочий проект).

Первый этап проектирования – этап НИР в который входят первые три стадии (иногда вместе с четвёртой). На этапе НИР проводятся исследования по поиску новых принципов работы и конструкций объектов проектирования, новой элементной базы и пр.

Второй этап проектирования – этап опытно-конструкторских работ (ОКР) – включает техническое проектирование (иногда вместе с эскизным проектированием). На этапе ОКР осуществляется детальная конструкторская проработка объекта проектирования.

Третий этап проектирования – этап технологической подготовки производства – совпадает с шестой стадией – рабочее проектирование.

Четвёртый этап проектирования – изготовление опытного образца – совпадает с седьмой стадией проектирования.
Пятый этап проектирования – отладка, испытание и ввод в эксплуатацию (в действие) – включает восьмую и девятую стадии проектирования.

Укрупнённо в логической схеме проектирования выделяются этапы:
• формирования ТЗ,
• предварительного,
• эскизного,
• и рабочего проектирования.

На этих этапах развивается описание объекта проектирования, фиксируемое в комплекте документации.

В качестве примера можно выделить следующие виды проектной деятельности:

• Проектирование технических систем, в том числе

• техническое проектирование (технические устройства и оборудование);
• электротехническое проектирование (электротехника и электроснабжение);
• проектирование инженерных систем (вентиляции, газопроводов, электросетей и др. инфраструктуры);

• архитектурно-строительное проектирование;
• проектирование инженерных сетей и систем;
• экологическое проектирование;
• Проектирование объектов хранения и перевалки нефтепродуктов;
• градостроительное проектирование;
• технологическое проектирование и др.

• дизайн интерьера;
• промышленный дизайн;
• ландшафтный дизайн;

• прогнозное социальное проектирование (социальная технология, ориентированная на выработку образцов решений перспективных социальных проблем с учётом доступных ресурсов и намеченных целей социально-экономического развития. Его цель — предплановое научное обоснование управленческих решений.

Существуют следующие стадии проектирования:
— технико-экономическое обоснование (ТЭО);
— технико-экономический расчет (ТЭР);
— эскизный проект (ЭП);
— проект (П);
— рабочая документация (Р)

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

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

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

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

Литература:

1. Сидоров А.И. Основные принципы проектирования и конструирования машин. — М .: Макиз, 1929. — 428 с.

2. Орлов П.И. Основы конструирования: Справочник: В 2-х книгах. — М .: Машиностроение, 1988.

3. Хорошев А.Н. Введение в управление проектированием механических систем: Учебное пособие. — Белгород, 1999. — 372 с.

Источник: cosmozz.info

Проектирование программного обеспечения

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

За 13 лет опыта компании «Эдисон» в аутсорс-разработке для средних и крупных компаний из России, США, Европы и Австралии мы выработали собственную схему проектирования ПО, о которой в этом посте и расскажем.

Зачем нужно проектирование программного обеспечения

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

Проектируя ПО заранее, разработчик получает возможность:

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

Подготовительный этап

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

При подготовке к проектированию решаются организационные вопросы:

• что клиент может предоставить (ТЗ, макеты, дизайн), насколько достаточны исходники и какие этапы закрывают — таким образом определяется состав работ,
• бюджет и сроки: на основе имеющихся материалов утверждается примерная стоимость, срок всего проекта, а также срок и точная стоимость ближайшего этапа.

Этапы и результаты проектирования

1. Описание: совместная работа заказчика (говорит о пользе продукта, требованиях к работоспособности и внешнему виду) и EDISON (предлагает технические и алгоритмические решения).
2. Архитектура: утверждается язык программирования, база данных, серверы и фреймворки.
3. Техническое задание: составляется архитектором на основании описания и ответов заказчика на вопросы, согласовывается с менеджером проекта, затем передается клиенту, производятся правки.
4. Макеты (добавляются к техзаданию): интерфейсов, принципиальные схемы устройства, диаграммы структуры базы данных, схемы взаимодействия компонентов.
5. Контроль: архитектор устраняет замечания менеджера проектов.
6. Утверждение: заказчик проверяет и меняет ТЗ самостоятельно или сообщает список правок проект-менеджеру, замечания устраняются, ТЗ утверждается и прилагается к контракту.

1. Что делаем (описание продукта, функционала, пользователей)?
2. Как делаем (архитектура)?
3. Как проверить, что цель достигнута (тестирование, критерии оценки)?

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

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

Минимально достаточное ТЗ должно:

• полностью, чётко (инструкционно, без воды, возможности разночтения) и структурировано описывать будущий программный продукт (как должен выглядеть, как и с чем работать, каким требованиям отвечать) и процесс его разработки, чтобы у архитектора не возникало вопросов по реализации,
• исключать противоречивые сведения,
• быть юридически точным (следовать ГОСТ 34.602-89), поскольку вместе с контрактом и прочими документами ТЗ приобретает юридическую силу.

• общие данные о проекте (название продукта, кем и для чего будет использоваться);
• общие требования к ПО (к структуре, функциям, в частности приложить схему архитектуры и описать связь подсистем, виды интерфейсов всех составляющих для каждой из ролей пользователей — готовый дизайн или его концепцию);
• подробный план работ (перечень этапов, сроки по ним);
• порядок тестирования и приемки (виды и состав испытаний продукта в целом и отдельных частей);
• перечень действий для запуска продукта;
• требования к документированию процесса и результата разработки.

1. детaлей:
2. пользователи программного продукта: роли, права и функции,
3. описание алгоритмов обработки данных,
4. перечень открытых и закрытых протоколов,
5. требования к безопасности данных на всем жизненном цикле,
6. список компонентов (платных, свободных), которые будут использоваться в разработке,
7. примеров:
8. при наличии аналогов, интегрируемых систем указываются ссылки на них,
9. в описании работы системы приводится описание типичных сценариев взаимодействия с ней пользователей,
10. примеры входящих данных и формат данных взаимодействия подсистем (таблицы, базы, страницы и др.),
11. примеры исходящих данных (виды отчетов и экспортируемых файлов),
12. производительности и надежности:
13. указание уровней нагрузки системы (день, месяц, максимальный),
14. требования к производительности, сохранности,
15. обоснование выбора оборудования запуска программного обеспечения,
16. указание хостинга серверной части.

Примеры техзаданий на разработку ПО

Естественно, чем сложнее проект, тем дольше и дороже подготовка к нему. Проектирование небольших проектов занимает от недели до месяца. Чтобы процесс шёл быстрее и стоил меньше, мы предоставляем заказчикам по запросу инструкцию по составлению ТЗ и примеры готовых технических заданий. Приведем примеры и тут.

ТЗ на программное обеспечение Protector

Объект ТЗ: разработка и интеграция с существующей системой модульного ПО для мониторинга удаленных устройств охраны
Заказчик: ООО «ВТИМБ»

Сценарии использования образовательной системы

Объект ТЗ: создание образовательной системы

ТЗ на разработку ПО SMPP-шлюз

Объект ТЗ: разработка программного обеспечения SMPP-шлюза
Заказчик: IMT

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

Проектирование — для больших парней

За годы работы нами написаны сотни техзаданий на разработку программного обеспечения различной степени сложности, и мы понимаем, что роль разработки подробного ТЗ сложно переоценить. Бывало, работали с ТЗ на более чем 1000 страниц, и для крупных проектов — это оправдано и необходимо. Тем не менее не стоит забывать о принципе целесообразности — нет смысла писать ТЗ на 20 страниц для двухдневной разработки продукта.

Есть замечания по нашей методологии или вы хотите поделиться своим опытом? Рады будем пообщаться в комментариях, в нашей группе в Фейсбуке или во Вконтакте.

Источник: habr.com