Элементы проектных работ

Автор: Пользователь скрыл имя, 06 Апреля 2012 в 16:45, реферат

Краткое описание

В соответствии с Гражданским кодексом, проектирование — это один из видов подрядных работ, результатом которых является продукция (проект), то есть комплект проектной документации на другой продукт (объект проектирования). Проект предназначен для создания объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых этот объект был разработан.

Оглавление

1. Понятие ТЗ 3
2. Место ТЗ в структуре проектирования 3
3. Частные технические задания 4
4. Необходимость ТЗ 4
5. Содержание ТЗ 1
6. Регламентированное ТЗ 1
7. Разделы ТЗ по ГОСТ 34.602-89 (пример) 1
8. Вид и состав требований ТЗ 1
9. Состав проектных работ 1
10. Предпроектная подготовка 1
11. Здание на проектирование 1
12. Проектные работы 1
13. Технологическое проектирование 1
14. Проект организации строительства 1
15. Содержание ПОС 2
16. Проект производства работ 15
17. Технико-экономическая оценка ПОС и ППР 16
18. Согласование проектно-сметной документации 17
19. Экспертиза проектно-сметной документации 17
20. Список литературы………………

Файлы: 1 файл

Понятие ТЗ - копия.docx

— 51.57 Кб (Скачать)

Оглавление

1. Понятие ТЗ 3

2. Место ТЗ в структуре проектирования 3

3. Частные технические задания 4

4. Необходимость ТЗ 4

5. Содержание ТЗ 1

6. Регламентированное ТЗ 1

7. Разделы ТЗ по ГОСТ 34.602-89 (пример) 1

8. Вид и состав требований ТЗ 1

9. Состав проектных работ 1

10. Предпроектная подготовка 1

11. Здание на проектирование 1

12. Проектные работы 1

13. Технологическое проектирование 1

14. Проект организации строительства 1

15. Содержание ПОС 2

16. Проект производства работ 15

17. Технико-экономическая оценка ПОС и ППР 16

18. Согласование проектно-сметной документации 17

19. Экспертиза проектно-сметной документации 17

20. Список литературы…………………………………………………….……..………………..19

 

 

 

 

 

 

 

 

 

 

 

Понятие ТЗ

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

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

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

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

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

Место ТЗ в структуре  проектирования

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

Стадии проектирования регламентированы стандартами. Это следующая последовательность:

  • Техническое задание (по ГОСТ 2.103-68 к стадиям разработки не относится),
  • Техническое предложение,
  • Эскизный проект,
  • Технический проект,
  • Стадии рабочего проекта.

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

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

Частные технические  задания

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

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

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

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

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

Необходимость ТЗ

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

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

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

Специалисты считают, что  грамотное ТЗ — это более 50 % успеха в решении задачи, а время, затраченное на подготовку ТЗ, — одно из лучших вложений, которые фирма может сделать в период проектирования. Недаром составление ТЗ поручается ведущим специалистам — главным конструкторам, руководителям проектов и работ и т. п.

Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:

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

Содержание ТЗ

Регламентированное  ТЗ

Не смотря на свою важность, содержание ТЗ практически не регламентировано нормативными документами (ГОСТ). Существуют только три стандарта на ТЗ:

  • ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению (кратко изложено содержание ТЗ);
  • ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы (достаточно подробно изложены состав и содержание ТЗ);
  • ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления (приведен порядок построения ТЗ).

Разделы ТЗ по ГОСТ 34.602-89 (пример)

Согласно ГОСТ 34.602-89 ТЗ должно содержать следующие разделы (приведены  в сокращенном виде):

  1. Общие сведения
    1. полное наименование системы и ее условное обозначение;
    2. шифр темы или шифр (номер) договора;
    3. наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
    4. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
    5. плановые сроки начала и окончания работы по созданию системы;
    6. сведения об источниках и порядке финансирования работ;
    7. порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.
  2. Назначение и цели создания системы
  3. Характеристика объекта автоматизации
    1. краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
    2. сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
  4. Требования к системе
    1. Требования к системе в целом;
    2. Требования к функциям (задачам), выполняемым системой;
    3. Требования к видам обеспечения.
  5. Состав и содержание работ по созданию системы
    1. перечень документов по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;
    2. вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);
    3. программа работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
    4. перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организации-исполнителей (при необходимости).
  6. Порядок контроля и приемки системы
    1. виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
    2. общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
    3. статус приемочной комиссии (государственная, межведомственная, ведомственная).
  7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
    1. приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
    2. изменения, которые необходимо осуществить в объекте автоматизации;
    3. создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
    4. создание необходимых для функционирования системы подразделений и служб;
    5. сроки и порядок комплектования штатов и обучения персонала.
  8. Требования к документированию
    1. согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и научно-технической документации отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;
    2. требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
    3. при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.
  9. Источники разработки: документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

Вид и состав требований ТЗ

Часто содержание ТЗ устанавливается  внутренними документами предприятия  либо соглашением заказчика и  исполнителя проектных работ.

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

  • Цели в функциональном виде. Изделие является лишь материальным носителем определенных функций, выполнение которых и позволяет достигать заданные цели (удовлетворять потребности). Но одну и ту же функцию могут выполнять разные устройства. Поэтому функциональное, а не предметное указание цели расширяет область возможных решений, что необходимо для поиска оптимального решения. Также, функция — более четкий термин для описания сути назначения устройства. Уточнение целей и назначение соответствующих им функций — наиболее важная часть работы по составлению ТЗ;
  • Выполнение функций, реализующих заданные потребности, всегда увязывается с удовлетворением определенных требований (см. перечень типовых требований к техническим устройствам), которые делают изделия более привлекательными, учитывают и конкретизируют особенности производства и эксплуатации и т. п. Для удобства требования по виду подразделяют на три группы:
    • условия, характеризуются конкретными значениями данных (формально их можно представить в виде равенств). Например, масса изделия должна составлять 10 кг, применять сталь 40Х, место эксплуатации — тундра. Важную часть условий формирует оценка доступных ресурсов;
    • ограничения, задают допустимую область данных (формально их можно представить в виде односторонних или двусторонних неравенств). Например, вес изделия не должен превышать 10 кг, применять углеродистые стали;
    • показатели качества (которые преобразуются в критерии оптимизации), задают только перечень характеристик и направление поиска предпочтительного значения (максимальное или минимальное значение, например, вес изделия должен быть минимальным, а удобство обслуживания — максимальным). Конкретное значение показателя становится известным только в конце этапа или всего цикла проектных работ и служит мерой предпочтения в процессе поиска оптимального варианта (основой выбора окончательного варианта).

Как и процесс проектирования, работа с требованиями также подлежит управлению. Эти процедуры хорошо отработаны, например, в управлении требованиями к программному обеспечению.

Информация о работе Элементы проектных работ