Требования к исполнителю проектных работ

Требования к исполнителю на разработку проектной документации

Вопрос-ответ по теме

Какие требования нужно устанавливать в соответствии со ст. 31 ч 1 к исполнителю на разработку проектной документации на строительство нмцк менее 3 млн. рублей и более 3 млн. рублей?

Как работать с электронными торговыми площадками

Оксана Баландина, шеф-редактор Системы Госзаказ

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

Что требовать от участников при закупке строительных и ремонтных работ

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

При любой закупке заказчик обязан установить к участникам закупки единые требования из Закона № 44-ФЗ. Какие единые требования установить, когда закупаете строительные и ремонтные работы, и как подтвердить, что участник отвечает требованиям, смотрите в таблице:

Постановление Арбитражного суда Северо-Западного округа от 30 января 2015 г. N Ф07-812/14 по делу N А21-548/2014 (ключевые темы: технические условия — градостроительный план земельного участка — инженерные изыскания — договор подряда на выполнение проектных и изыскательских работ — техническое задание)

Постановление Арбитражного суда Северо-Западного округа от 30 января 2015 г. N Ф07-812/14 по делу N А21-548/2014

30 января 2015 г.

Дело N А21-548/2014

Арбитражный суд Северо-Западного округа в составе

председательствующего Малышевой Н.Н.,

судей Константинова П.Ю., Шпачевой Т.В.,

при участии от общества с ограниченной ответственностью «Стиль-проект» генерального директора Тимофеева В.В. (решение учредителя от 17.01.2014),

рассмотрев 26.01.2015 в открытом судебном заседании кассационную жалобу общества с ограниченной ответственностью «Стиль-проект» на решение Арбитражного суда Калининградской области от 17.04.2014 (судья Ершова Ю.А.) и постановление Тринадцатого арбитражного апелляционного суда от 01.10.2014 (судьи Жиляева Е.В., Барканова Я.В., Тимухина И.А.) по делу N А21-548/2014,

Общество с ограниченной ответственностью «Стиль-проект», место нахождения: Калининград, улица Александра Невского, дом 36, литера В, ОГРН 1043902804000, ИНН 3906118543 (далее — Общество), обратилось в Арбитражный суд Калининградской области с иском (с учетом уточнения предмета спора в порядке, предусмотренном статьей 49 Арбитражного процессуального кодекса Российской Федерации; далее — АПК РФ) к государственному бюджетному учреждению культуры «Научно-производственный центр по охране, учету и регистрации памятников истории и культуры Калининградской области», место нахождения: Калининград, Советский проспект, дом 13, ОГРН 1023900596444, ИНН 3904015912 (далее — Учреждение), о признании недействительным абзаца второго пункта 4.2.1 договора от 02.04.2013 N 0135200000513000005 (далее — Договор) следующего содержания: «Вышеперечисленный перечень документов считать исчерпывающим».

Решением суда от 17.04.2014, оставленным без изменения постановлением апелляционной инстанции от 01.10.2014, в удовлетворении иска отказано.

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

Как утверждает податель жалобы, суд первой инстанции вышел за пределы заявленных требований и дал оценку пункту 4.2.1 Договора в целом, что не соответствует уточненным исковым требованиям Общества; апелляционная инстанция, оставляя решение суда в силе, сослалась на пункт 3 Договора ошибочно, поскольку данное условие касается лишь стоимости работ и порядка расчетов; Договором, а также Техническим заданием не предусмотрена обязанность Общества по получению градостроительного плана земельного участка, результатов инженерных изысканий и технических условий.

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

В судебном заседании представитель Общества поддержал доводы кассационной жалобы.

Жалоба рассмотрена кассационным судом без участия представителей Учреждения, извещенного надлежащим образом о месте и времени слушания дела.

Законность обжалуемых судебных актов проверена в кассационном порядке.

Как следует из материалов дела, в соответствии с Договором Общество (проектировщик) обязалось по заданию Учреждения (заказчика) разработать проектную и рабочую документацию по реконструкции объекта культурного наследия «Мемориальный комплекс, связанный с жизнью и деятельностью классика литовской литературы Кристионаса Донелайтиса» в поселке Чистые Пруды муниципального образования Нестеровский район Калининградской области (далее — Объект), передать заказчику разработанную проектную и рабочую документацию с положительным заключением органов государственной экспертизы и положительным заключением проверки достоверности сметной стоимости.

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

— охранное обязательство на объект культурного наследия (ОКН) от 2006 года,

— акт осмотра технического состояния ОКН от 26.01.2012 г.,

— кадастровый план земельного участка,

— техническую документацию (два паспорта БТИ) на ОКН.

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

Указанные документы по акту приема-передачи от 04.04.2013 переданы проектировщику.

В ходе выполнения обязательств по Договору проектировщик неоднократно: письмами от 26.02.2014 N 216, от 05.03.2014 N 219, от 11.04.2013 N 139, от 17.05.2013 N 149, от 02.08.2013 N 172 — сообщал заказчику о невозможности дальнейшего исполнения условий Договора ввиду отсутствия дизайн-проекта внутренних помещений кирхи с проектом выставочной экспозиции.

На этом основании Общество просило представить дизайн-проект, сведения о вновь создаваемой музейной экспозиции.

Учреждение отклонило требования Общества, утверждая, что все документы, предусмотренные Договором, были переданы проектировщику.

Данное обстоятельство послужило основанием для обращения Общества в арбитражный суд со ссылкой на несоответствие условий Договора требованиям законодательства — части 6 статьи 48 Градостроительного кодекса Российской Федерации (далее — ГрК РФ).

Суд первой инстанции, посчитав, что содержание пункта 4.2.1 Договора соответствует требованиям законодательства и не нарушает прав Общества, в удовлетворении иска отказал.

Апелляционный суд согласился с приведенными в решении оценкой доказательств и выводами.

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

Статьей 166 Гражданского кодекса Российской Федерации (далее — ГК РФ) определено, что сделка недействительна по основаниям, установленным названным Кодексом , в силу признания ее таковой судом (оспоримая сделка) либо независимо от такого признания (ничтожная сделка).

Пунктом 1 статьи 168 ГК РФ предусмотрено, что сделка, нарушающая требования закона или иного правового акта, является оспоримой, если из закона не следует, что должны применяться другие последствия нарушения, не связанные с недействительностью сделки.

Статья 180 ГК РФ устанавливает, что недействительность части сделки не влечет недействительности прочих ее частей, если можно предположить, что сделка была бы совершена и без включения недействительной ее части.

Согласно статье 758 ГК РФ по договору подряда на выполнение проектных и изыскательских работ подрядчик (проектировщик, изыскатель) обязуется по заданию заказчика разработать техническую документацию и (или) выполнить изыскательские работы, а заказчик обязуется принять и оплатить их результат.

Подрядчик по договору подряда на выполнение проектных и изыскательских работ обязан выполнить работы в соответствии с заданием и с исходными данными на проектирование и с договором ( статья 760 ГК РФ).

В соответствии с частью 6 статьи 48 ГрК РФ в случае, если подготовка проектной документации осуществляется физическим или юридическим лицом на основании договора с застройщиком или заказчиком, застройщик или заказчик обязан предоставить такому лицу: градостроительный план земельного участка; результаты инженерных изысканий (в случае, если они отсутствуют, договором должно быть предусмотрено задание на выполнение инженерных изысканий); технические условия (в случае, если функционирование проектируемого объекта капитального строительства невозможно обеспечить без подключения такого объекта к сетям инженерно-технического обеспечения).

В силу части 11 статьи 48 ГрК РФ подготовка проектной документации осуществляется на основании задания застройщика или заказчика (при подготовке проектной документации на основании договора), результатов инженерных изысканий, градостроительного плана земельного участка в соответствии с требованиями технических регламентов, техническими условиями, разрешением на отклонение от предельных параметров разрешенного строительства, реконструкции объектов капитального строительства.

Согласно пункту 1 статьи 759 ГК РФ по договору подряда на выполнение проектных и изыскательских работ заказчик обязан передать подрядчику задание на проектирование, а также иные исходные данные, необходимые для составления технической документации. Задание на выполнение проектных работ может быть по поручению заказчика подготовлено подрядчиком. В этом случае задание становится обязательным для сторон с момента его утверждения заказчиком.

Таким образом, получение ряда документов, предусмотренных частью 6 статьи 48 ГрК РФ (с учетом положений статьи 759 ГК РФ), стороны вправе самостоятельно предусмотреть в договоре. Следовательно, в зависимости от условий Договора обязанность по получению исходных материалов может быть возложена на заказчика либо их создает или получает исполнитель при содействии заказчика.

Согласно пункту 2.1 Договора первый этап выполнения проектировщиком работ (разработка проектной и рабочей документации) включает в себя необходимость совершения проектировщиком следующих действий: сбор исходных данных, включая дополнительные технические условия, необходимость в которых возникла в процессе проектирования; выполнение инженерно-геодезических изысканий; разработка проектной документации; согласование проектировщиком проектной документации в службах, выдавших технические условия и государственных организациях.

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

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

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

В связи с этим в удовлетворении иска отказано правомерно.

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

В соответствии с пунктом 7 технического задания в состав работ входила именно разработка дизайн-проекта внутренних помещений кирхи с учетом создания новой музейной экспозиции.

Из условий Договора и технического задания не следует, что обязанность по предоставлению сведений об объектах лежит на Учреждении, однако последнее передавало их разработчику проекта, в частности по письму от 11.04.2013 и решению совещания 24.05.2013 в отношении создаваемой музейной экспозиции, здания кирхи, дома пастора и территории мемориального комплекса о чем свидетельствуют письма от 13.06.2013 N 273, от 17.04.2013 N 151, от 28.05.2013 N 254.

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

Руководствуясь статьями 286 , 287 и 289 Арбитражного процессуального кодекса Российской Федерации, Арбитражный суд Северо-Западного округа

решение Арбитражного суда Калининградской области от 17.04.2014 и постановление Тринадцатого арбитражного апелляционного суда от 01.10.2014 по делу N А21-548/2014 оставить без изменения, а кассационную жалобу общества с ограниченной ответственностью «Стиль-проект» — без удовлетворения.

Новости отрасли

Требовать от исполнителя госконтракта членства в двух СРО неправомерно

20.07.2018 в 10:26

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

Несмотря на разъяснения, данные в письме Минстроя России от 31.01.2018 № 2890-ХМ-08, антимонопольная служба в подобном случае в очередной раз вынесла решение не в пользу организатора аукциона на право проведения проектных работ. Напомним, что в письме за подписью замминистра говорилось о том, что исполнитель (юридическое лицо или ИП) должен быть одновременно членом и проектной, и изыскательской СРО, если предметом договора является выполнение работ по инженерным изысканиям и подготовке проектной документации.

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

Как поясняется в постановлении УФАС по делу об административном правонарушении № 04-16/53-2018, подрядчику необходимо иметь членство одновременно на отдельные виды работ только в том случае, если он будет исполнять контракт только своими силами. Если в предмет закупки включены работы, для осуществления которых требуются различные СРО, заказчик вправе установить требование о наличии СРО у исполнителя данных работ, но не вправе устанавливать требования к участнику закупки о наличии у него всех указанных СРО. К выполнению указанных работ исполнитель вправе привлечь субподрядчиков.

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

Техническое задание

Техни́ческое зада́ние (ТЗ, техзада́ние) — исходный документ для разработки и испытания изделия. [1]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Академик А. Н. Крылов рассказывал. На одной фабрике установили новую машину, но никак не могли её запустить. Тогда обратились за помощью к профессору университета. Приехав на фабрику, он долго ходил вокруг машины, внимательно что-то высматривая и к чему-то прислушиваясь. Затем, взяв молоток, ударил по её корпусу. И машина заработала. За свою помощь профессор запросил у правления фабрики 100 рублей (дело было в начале 20 века). Но правление фабрики посчитало, что за один удар молотком это слишком большая плата. На что профессор ответил, что сам удар стоит один рубль, а вот то, куда ударить — 99 рублей. [4] Замечено, что если стоимость исправления проектной ошибки, допущенной на этапе технического проектирования принять за 1, то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и ТЗ!

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

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

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

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

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

В части выполнения научно-исследовательских работ ТЗ регламентируется следующими документами:

• ОСТ 95 18-2001. Порядок проведения научно-исследовательских и опытно-конструкторских работ. Основные положения.
• Приложение №3 к Правилам приемки НИОКР, утвержденным Приказом Роспрома16.09.2004 №95. Техническое задание на научно-исследовательскую работу [7] (приложен образец технического задания на разработку в рамках ГОЗ)

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

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

1. Общие сведения
   1. полное наименование системы и ее условное обозначение;
      1. Пример:

Полное наименование системы: Автоматизированная система «Управление» Условное обозначение: АСУ

Договор № ХХХ от ДД.ММ.ГГГГ

1. 1. наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
      1. Пример:

ЗАКАЗЧИК Наименование заказчика: ООО «МИР» Юридический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Почтовый адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Фактический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Телефон: +7 903 456 67 67 Факс: +7 903 453 34 54 Адрес электронной почты: [email protected] ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО «БанкСтрой», г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423 <<[[Шаблон:|]]>> 400000000234

ИСПОЛНИТЕЛЬ Наименование исполнителя: ООО «ДЯТЕЛ» Юридический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Почтовый адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Фактический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Телефон: +7 495 345 63 63 Факс: +7 495 433 34 54 Адрес электронной почты: [email protected] ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО «БанкСтрой», г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423400000000234

1. 1. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
   2. плановые сроки начала и окончания работы по созданию системы;
   3. сведения об источниках и порядке финансирования работ;
   4. порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.
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 кг, применять углеродистые стали;
  • показатели качества (которые преобразуются в критерии оптимизации), задают только перечень характеристик и направление поиска предпочтительного значения (максимальное или минимальное значение, например, вес изделия должен быть минимальным, а удобство обслуживания — максимальным). Конкретное значение показателя становится известным только в конце этапа или всего цикла проектных работ и служит мерой предпочтения в процессе поиска оптимального варианта (основой выбора окончательного варианта).

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

Для конкретизации целей и требований, заданных нечётко либо качественно, применяют метод декомпозиции.

Стоит отметить, что приведённые в условии данные — это номинальные параметры, но было бы более правильно приводить нормированные значения этих параметров, задаваемые своими предельно-допустимыми значениями (например, масса изделия 9,8…10,1 кг). То есть то, что считают условиями, на практике являются ограничениями в виде двусторонних неравенств. Ширина диапазона является следствием величины допуска на этот параметр.

При формировании системы требований обязателен анализ следующих источников:

• Доступность ресурсов, находящихся в распоряжении заказчика и разработчика: финансовые, производственные, людские, временные. Все ресурсы взаимосвязаны, например, за счет увеличения финансирования проекта можно добиться сокращения периода разработки. Следствием степени доступности является введение ограничений на методы и точность решения проектной задачи, что, в свою очередь, влияет на вид выбираемой модели. Так, при ограниченности времени ведут оценочные расчеты упрощенными методами или используют готовое программное обеспечение, стандартные методики, типовое оборудование, стандартные и покупные детали и узлы и т. д. В то же время модель, метод и точность решения должны обеспечивать исполнение требований ТЗ, даже если они и высоки.
• Учет требований надзорных и лицензионных органов при проектировании, например, технологических комплексов (производств). В соответствии с законами Российской Федерации любое производство требует получения региональной лицензии на эксплуатацию. Помимо этого многие производства лицензируются надзорными органами и подлежат с их стороны контролю. Наиболее часто контролирующими являются региональные органы Ростехнадзора, Росстандарта, Минрегион России (бывш. Госстрой), Роспотребнадзора, Росприроднадзора, ГПС, МВД России, Роструда.
• Жизненная среда проектируемой системы. Она задает требования, характеризующие взаимное влияние спроектированной системы и окружающих её живых и неживых объектов и внешней среды. Основные указания на нее приводятся в технических требованиях в условиях потребления будущей продукции. Эти условия могут быть охарактеризованы достаточно обобщенно и нуждаться в конкретизации.

Составление списка требований ТЗ

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

Сначала приведем рассказ о том, как Эдисон ставил перед собой техническую задачу. [8]

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

Анализ задания заказчика

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

Следует выявлять и стараться избегать решения следующих задач:

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

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

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

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

Противоречие может быть декомпозировано, то есть представлено в виде элементарных проблем.

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

Если прообраз существует, то рекомендуют:

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

Конкретизация целей проектирования

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

В процессе поиска наиболее полной и точной формулировки строится цепочка функций (дерево целей) — от первоначально предложенной до окончательно принятой. Этому помогает ответ на вопрос «Зачем это нужно?» (и другие вопросы метода контрольных вопросов). В большинстве случаев за приведенной в требованиях целью стоит необходимость выполнения (последовательно или одновременно) нескольких функций. Цепочка функций строится для каждой из них.

Наряду с потребностью в каком-то действии может существовать и потребность в несовершении действия или совершении действия с отрицательным эффектом.

Обработка собранной информации

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

Абстрагирование предназначено дать такую формулировку требованиям, чтобы избежать предопределения путей решения задачи (не создавать психологических барьеров). Для получения «сильных» решений рекомендуют проводить усиление системы требований и обострение противоречий путем формулирования ИКР.

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

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

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

4. Параметризация.
Точность суждения и верность выбора зависят от степени конкретности исходных требований, представлены ли они в формализованном или неформализованном виде. Для однозначности выводов все требования должны быть переведены в формализованный вид, то есть указаны характеризующие их параметры, причем такие, которые можно измерить, проконтролировать, рассчитать. Это также позволит выделить дублирующие требования (те, которые характеризуются одними и теми же параметрами) и обобщить их (ввести обобщенные параметры с целью сокращения общего их числа, удельные характеристики).

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

Проблемами оценки качества посредством количественных показателей занимается наука «Квалиметрия».

5. Усечение списка требований.
Большой объем информации хотя и способен дать максимально полное представление о решаемой задаче, но труднее удерживается в голове, усложняет решение задачи. Для сокращения сведений до разумного объема (под способности каждого конкретного разработчика, соответствие его финансовым, организационно-техническим, временным ресурсам) можно воспользоваться их ранжированием или разделением на группы обязательных к учету, желательных и несущественных. К обязательным относятся те, неудовлетворение которых существенным образом влияет на выбор вариантов решений. Это — функциональные параметры, условия взаимосвязи систем и их частей и другие. Желательные требования позволяют различить варианты по степени качества.

Стоит принимать во внимание слова Ли Якокки: «… беда в том, что ты учился в Гарварде, где тебе вбили в голову, что нельзя предпринимать никаких действий, пока не соберёшь все факты. У тебя 95 % информации, а для того, чтобы собрать недостающие 5 %, тебе понадобится ещё шесть месяцев. За это время все факты устареют, потому что рынок развивается гораздо быстрее. Самое главное в жизни — всё делать вовремя. … главная задача состоит в том, чтобы собрать все важные факты и точки зрения, которые вам доступны. Но в какой-то момент надо начинать действовать решительно. Во-первых, потому, что даже самое правильное решение оказывается неверным, если оно принято слишком поздно. Во-вторых, потому, что в большинстве случаев не существует такой вещи, как полная уверенность. Вам никогда не удастся собрать все 100 % информации. К сожалению, жизнь не будет ждать, пока вы оцените все возможные просчеты и потери. Иногда надо просто двинуться вперед наудачу и исправлять ошибки по ходу движения». [9]

6. Сведение требований в единый документ и утверждение его заказчиком.