Техническое задание носит характер. Этапы составления технического задания

Подготовка к лабораторной работе

Ознакомиться с лекционным материалом по теме «Модели ЖЦ ПО. Этапы ЖЦ в соответствии с ГОСТ 19.102-77. Постановка задачи» учебной дисциплины «Разработка и стандартизация ПС и ИТ».

1.Изучить соответствующие разделы в изданиях .

Теоретическая часть. Разработка технического задания

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

Порядок разработки технического задания

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

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

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

1. Общие положения

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата А4 и A3 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннота­цию и содержание), лист регистрации изменений допускается в документ не включать.

1.3. Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или про­граммного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.

1.4. Техническое задание должно содержать следующие разделы:

Введение;

Наименование и область применения;

Основание для разработки;

Назначение разработки;

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

Технико-экономические показатели;

Стадии и этапы разработки;

Порядок контроля и приемки;

Приложения.

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

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

2.2.В разделе «Наименование и область применения» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

2.3.В разделе «Основание для разработки» должны быть указаны:

Документ (документы), на основании которых ведется разработка. Таким документом может служить план, приказ, договор и т. п.;

Организация, утвердившая этот документ, и дата его утверждения;

Наименование и (или) условное обозначение темы разработки.

2.4. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

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

Требования к функциональным характеристикам;

Требования к надежности;

Условия эксплуатации;

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

Требования к информационной и программной совместимости;

Требования к маркировке и упаковке;

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

Специальные требования.

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

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

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

2.5.4.В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их технических характеристик.

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

2.5.6.В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

2.5.7.В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

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

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

2.7.В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

2.8.В приложениях к техническому заданию при необходимости приводят:

Перечень научно-исследовательских и других работ, обосновывающих разработку;

Схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;

Другие источники разработки.

В случаях, если какие-либо требования, предусмотренные техническим заданием, заказчик не предъявляет, следует в соответствующем месте указать «Требования не предъявляются».

Примеры разработки технического задания приведены в приложениях Б и В.

Контрольные вопросы

1.Дайте понятие модели жизненного цикла ПО.

2.Приведите этапы разработки программного обеспечения.

3. Что включает в себя постановка задачи и предпроектные исследования?

4. Перечислите функциональные и эксплуатационные требования к программному продукту.

5. Перечислите правила разработки технического задания.

6. Назовите основные разделы технического задания.

Приложение А

Варианты заданий

Лабораторные работы № 1-5 выполняются для одного и того же варианта.

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

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

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

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

5. Разработать приложение Windows «Органайзер». Приложение предназначено для записи, хранения и поиска адресов и телефонов физических лиц и организаций, а также расписания, встреч и др. Приложение предназначено для любых пользователей компьютера.

6. Разработать приложение Windows «Калькулятор». Приложение предназначено для любых пользователей и должно содержать все арифметические операции (с соблюдением приоритетов) и желательно (но не обязательно) несколько математических функций.

7. Разработать программный модуль «Кафедра», содержащий сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль предназначен для использования сотрудниками отдела кадров и деканата.

8. Разработать программный модуль «Лаборатория», содержащий сведения о сотрудниках лаборатории (ФИО, пол, возраст, семейное положение, наличие детей, должность, ученая степень). Модуль предназначен для использования сотрудниками профкома и отдела кадров.

9. Разработать программный модуль «Химчистка». При записи на обслуживание заполняется заявка, в которой указываются ФИО владельца, описание изделия, вид услуги, дата приема заказа и стоимость услуги. После выполнения работ распечатывается квитанция.

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

11. Разработать программный модуль «Картотека автомагазина», предназначенный для использования работниками агентства. В базе содержатся сведения об автомобилях (марка, объем двигателя, дата выпуска и др.). При поступлении заявки на покупку производится поиск подходящего варианта. Если такого нет, клиент заносится в клиентскую базу и оповещается, когда вариант появляется.

12. Разработать программный модуль «Картотека абонентов АТС». Картотека содержит сведения о телефонах и их владельцах. Фиксирует задолженности по оплате (абонентской и повременной). Считается, что повременная оплата местных телефонных разговоров уже введена.

13. Разработать программный модуль «Автокасса», содержащий сведения о наличии свободных мест на автобусные маршруты. В базе должны содержаться сведения о номере рейса, маршруте, водителе, типе автобуса, дате и времени отправления, а также стоимости билетов. При поступлении заявки на билеты программа производит поиск подходящего рейса.

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

15. Разработать программный модуль «Автостоянка». В программе содержится информация о марке автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др.

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс , найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения
5. Алфавитный указатель

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

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

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
• (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из

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

В соответствии с п. 10 ст. 4 Закона № 223-ФЗ в документации о закупке должны быть указаны установленные заказчиком требования к качеству, техническим характеристикам товара, работы, услуги, к их безопасности, к функциональным характеристикам (потребительским свойствам) товара, к размерам, упаковке, отгрузке товара, к результатам работы и иные требования, связанные с определением соответствия поставляемого товара, выполняемой работы, оказываемой услуги потребностям заказчика.

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

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

1. Согласно п. 2 ч. 1 ст. 3 Закона № 223-ФЗ при закупке ТРУ заказчики должны руководствоваться следующими принципами: равноправие, справедливость, отсутствие дискриминации и необоснованных ограничений конкуренции по отношению к участникам закупки.

2. Закон № 135-ФЗ «О защите конкуренции» (п. 2, ч. 1, ст. 17) гласит, что при проведении торгов запрещаются действия, которые приводят или могут привести к недопущению, ограничению или устранению конкуренции, в том числе запрещено создавать участнику торгов или нескольким участникам торгов преимущественные условия участия в торгах, в том числе путем доступа к информации, если иное не установлено законодательством.

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

Лучше, чтобы техническое задание формировал именно инициатор закупки, то есть тот, кто будет использовать предмет закупки. При этом специалисты по закупке обязательно контролируют и проверяют техническое задание на его соответствие антимонопольному законодательству (ст. 17 Закон № 135-ФЗ).

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

В техническом задании обязательно нужно указывать в качестве одного из требований, что товар должен быть новый. Поскольку Законом № 223-ФЗ это никак не регламентируется (в отличие от Закона № 94-ФЗ), то участники закупки вправе будут поставить бывший в употреблении товар в случае, если заказчик не укажет конкретно, что он должен быть новый.

Правильное техническое задание содержит:

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

Формируем лоты правильно.

В один лот лучше не включать:

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

Правила формирования лота.

1. Должно быть предусмотрено право участия по любому количеству лотов.

Если поставщик победил в одном лоте, то неправомерно ограничивать его участие в других лотах. Это будет признано ограничением конкуренции.

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

3. Победа в одном лоте не может быть обусловлена победой в другом лоте.

4. Договоры заключаются по всем лотам отдельно, или если один победитель - 1 договор на все лоты.

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

Популярные способы ограничения количества участников.

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

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

2. Включение в лот разнородной продукции.

3. Включение в лот кроме прочей продукции продукцию, подлежащую лицензированию.

4. Включение в лот «разнолицензируемой» продукции.

5. Требования по нескольким местам поставки.

6. Нереальные сроки.

7. Установление трудновыполнимых требований по предоставлению документов.

Правила определения качества продукции согласно ст. 469, 721 ГК РФ:

1. Поставщик обязан передать заказчику товар, качество которого соответствует договору.

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

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

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

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

Последствия некорректного составления технического задания:

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

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

Примеры требований в техническом задании:

Неправильно	Правильно
Обеспеченность кадровыми ресурсами	Наличие в штате не менее 5 сотрудников, имеющих профессиональное образование.
Клей канцелярский	Клей-карандаш «ErichKrause». Вес не менее 15 гр. Не токсичный, содержащий глицерин для легкого скольжения, без запаха, легко смываемый водой. Прозрачный. Для склеивания бумаги.
Наличие опыта	Наличие опыта оказания аналогичных услуг за последние 3 года в объеме не менее 3 договоров с общей суммой не меньше начальной цены.
	Линейка прозрачная, длина 30 см, пластиковая, устойчивая к деформациям, гладкая полированная поверхность, ровная, четкая миллиметровая шкала делений.

Техническое задание на закупку ГСМ

Прежде, чем проводить закупку, нужно определить код по ОКДП, чтобы знать в какой форме нужно проводить закупку - в электронной или нет. В данном случае код номер 2320000, в постановление Правительства № 616 этот код не входит. Значит обязанности проводить закупку электронно нет. Тем не менее это очень удобно и можно это делать в том числе в электронной форме.

Предмет договора: поставка ГСМ или нефтепродуктов.

В техническом задании указываем:

• наименование;
• характеристики;
• количество;
• выборка по заявкам;
• место поставки;
• способ поставки (оптом, по талонам или картам, за наличный расчет).

В договоре указать пункты заправки, примерную схему проезда, режим работы и прочее.

Способы поставки ГСМ:

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

Не забывайте при этом закупки свыше 100 тыс. руб. у единственного поставщика публиковать на сайте.

Оплата за ГСМ:

2. Окончательный расчет:

• по факту передачи талонов;
• по факту зачисления на смарт-карту;
• по фактической поставке.

ТЗ на закупку транспортных услуг.

Объем транспортных услуг измеряется:

• в километрах пробега;
• в часах оказания услуг;
• количеством человек, которых надо перевезти;
• количеством транспортных средств;
• количеством часов налета по видам судов.

Это зависит от специфики организации и поставленных задач.

В техническом задании указываем такие условия:

• наличие ОСАГО и страхования пассажиров;
• медицинский осмотр водителей перед началом работы, требования к поведению и внешнему виду водителей;
• виды транспортных средств;
• количество транспортных средств, необходимых заказчику одновременно;
• место оказания услуг - конкретный маршрут, либо указание на то, что маршрут определяется заказчиком непосредственно в ходе оказания транспортных услуг.

ТЗ на закупки услуг страхования

ОСАГО - одинаковая цена у всех участников, определена законодательно. Значит при проведении закупки следует ориентироваться не на стоимость, а на другие факторы. Например, количество дней, необходимых для принятия решения о признании или не признании события страховым случаем. В Положении о закупке должны быть прописаны действия в ситуации, когда у всех поставщиков одинаковая цена и, возможно, другие условия поставки тоже схожи.

КАСКО - цена разная у разных поставщиков. Есть возможность оценивать этот фактор наряду с другими важными показателями.

В техническое задание включаем:

• количество объектов страхования;
• их наименования и точные характеристики;
• срок страхования;
• страховую сумму.

ОСАГО. Оценка заявок.

Цена договора - страховая премия, которая не подлежит изменению участниками закупки.

Качество услуг и квалификация участников:

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

КАСКО. Оценка заявок.

Критерии оценки: цена договора, качество услуг и (или) квалификация исполнителя.

Возможные показатели:

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

ТЗ на закупки услуг по охране

Специальные требования к участникам:

• юридическое лицо, которое в соответствии со своим уставом занимается оказанием охранных услуг, обязано иметь на это лицензию;
• охранная деятельность организаций не распространяется на объекты, подлежащие государственной охране (перечень утвержденпостановлением Правительства РФ от 14.08.1992 № 587).
• Законом РФ от 11.03.1992 № 2487-1 «О частной детективной и охранной деятельности в РФ» охрана имущества собственников отнесена к оказанию услуг лицами, осуществляющими частную детективную и охранную деятельность. Этот вид услуг не относится к исключительным полномочиям органов внутренних дел.

Охрана. Оценка заявок.

Можно установить следующие критерии оценки заявок:

Цена договора;

Опыт выполнения аналогичных услуг (не в годах, а в сумме договора), подтверждение этого опыта;

Квалификация (наличие группы быстрого реагирования, специального вооружения и т.д.).

ТЗ на закупки в сфере строительства

• Главным способом осуществления закупки является проведение конкурса (или запроса предложений).
• Авторский надзор лучше закупать у единственного поставщика.
• Лицензирование строительства заменено на допуск от СРО.
• Начальная цена договора определяется по сметным нормативам.
• ПСД должна быть в документации.
• Цена договора определяется путем пропорционального снижения всех позиций сметы на сделанную в ходе процедуры скидку.
• Смета в документации, договоре и актах должна совпадать по составу и объему работ.

Формирование лотов

Возможно ли совмещать изыскательские, проектные, строительные работы в одном лоте?

Согласно ст. 17 Закона № 135-ФЗ при проведении электронных торгов запрещаются действия, которые приводят или могут привести к недопущению, ограничению или устранению конкуренции, в том числе запрещено создавать участнику торгов или нескольким участникам торгов преимущественных условий участия в торгах.

• Проектные и изыскательские работы можно объединять в один лот.
• Не следует объединять в один лот строительные и проектные работы.
• Без ПСД невозможно определить окончательный объем строительных работ.
• При неизвестном объеме работ невозможно определить начальную цену.
• Требуются свидетельства о допуске от разных СРО.

Виды СРО (ст. 55.2 ГрК РФ)

1. Подготовка проектной документации объектов капитального строительства.

2. Строительство, реконструкция, капитальный ремонт объектов капитального строительства.

3. Инженерные изыскания объектов капитального строительства.

По всем трем видам ведутся отдельные реестры СРО, посмотреть их можно на сайте:www.gosnadzor.ru .

Перечень видов работ, требующих допуск СРО, определен приказом Минрегиона России от 30.12.2009г. № 624. Он вступил в силу с 01.07.2010 (до 01.07.2010 г. такой перечень был определен приказом Минрегиона России от 09.12.2008 № 274). Перечень содержит отдельные виды работ - только для особо опасных, технически сложных и уникальных объектов (ст. 48.1 ГрК РФ) и не включает в себя виды работ по подготовке проектной документации, по строительству, реконструкции, капитальному ремонту в отношении объектов, для которых не требуется выдача разрешения на строительство (ч. 17, ст. 51 ГрК РФ), а также в отношении ряда других объектов (п. 2 приказа Минрегиона России от 30.12.2009г. № 624).

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

Требования к участникам электронных торгов

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

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

• Основу - проектную документацию с положительным заключением экспертизы.
• Особенности порядка приемки работ. Применение СниП 3.01.04-87 «Приемка в эксплуатацию законченных строительством объектов. Основные положения».
• Обязанность передать копии документов на применяемые материалы (сертификаты соответствия или декларации о соответствии).
• Обязанность обеспечить авторский надзор, строительный контроль, государственный строительный надзор.
• Перечни специального монтируемого оборудования.
• Если закупается текущий ремонт, тотехническое задание на строительство должно содержать:
• Основу - дефектные ведомости, ведомости объемов работ, локальные сметные расчеты (ЛСР), которые могут прикладываться к документации о закупке.
• Особенности приемки работ.
• Обязанность передать копии документов на применяемые материалы (сертификаты соответствия или декларации о соответствии. См. постановление Правительства № 982 от 01.12.2009 «Единые перечни продукции, подлежащей сертификации...»).

Кроме того, техническое задание на строительство может содержать:

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

Вопросы слушателей

Вопрос: Как быть если товар по санитарным правилам должен быть произведен в России?

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

Вопрос: Можно ли включить в техническое задание условие оплаты товара в рассрочку?

Ответ: Это не совсем относится непосредственно к техническому заданию. В документации о закупке это условие можно включить в информационную карту, например в пункт, который называется «Порядок оплаты».

Вопрос: Можем ли мы устанавливать преференции поставщикам, предлагающим товары российского производства?

Ответ: Нет, на это вы права не имеете. Нельзя устанавливать ни преференции по стране производства, ни субъектам малого, среднего бизнеса. Это не ваша прерогатива. Это относится к компетенции Правительства РФ.

Вопрос: Можно ли АИ-92, АИ-80 и дизельное топливо закупать одним лотом?

Ответ: В случае, если вы уверены, что на рынке существует достаточное количество поставщиков, которые могут одновременно поставить все эти продукты, и вы таким образом не ограничите конкуренцию, то можно.

Вопрос: Указанные в законе суммы 100 тыс. руб. и 500 тыс. руб. - это считать с НДС или без?

Ответ: Согласно указанной в договоре стоимости, которая обычно указывается с НДС.

Вопрос: Можно ли продлить поставки ГСМ дополнительным соглашением на 2014 год?

Ответ: С юридической точки зрения все дополнительные соглашения, согласно которым увеличивается объем поставляемых товаров, работ, услуг, являются новой сделкой. Вы можете заключить это дополнительное соглашение на поставку ГСМ в 2014 году. При этом нужно быть уверенными, что в вашем Положении о закупке прописаны основания для заключения этой сделки.

Вопрос: Что делать если водители заправляются на заправках за наличные по мере необходимости и у разных поставщиков?

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

Вопрос: При закупке ГСМ нет цены договора и количества закупаемого топлива, можно ли указывать лишь цену 1 литра топлива?

Ответ: Нельзя.

Вопрос: Если платежи одному и тому же поставщику ГСМ проходят регулярно 1-2 раза в месяц и суммы платежей менее 100 тысяч рублей, то можно ли расценивать эту закупку как закупку до 100 тыс. руб.?

Ответ: Лучше провести конкурентную процедуру и заключить договор на поставку большого количества топлива некоторыми партиями. Тогда ни у кого не возникнет вопросов к вам относительно соблюдения законодательства.

Вопрос: Можно ли сделать закупку ГСМ по количеству литров?

Ответ: Можно.

Вопрос: Например, договор заключен 1 января, где-нибудь в середине года заказчик проводит закупку на тот же товар (услугу) и его выигрывает тот же поставщик, нужно ли подписывать новый договор, опубликованный в составе документации, или можно работать по ранее заключенному договору, определяя новые условия спецификацией?

Ответ: В этом случае необходимо заключать новый договор.

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

Ответ: Закупку у единственного поставщика правильно оформлять следующим образом. Если закупка больше 100 000 руб. или 500 000 руб., то нужно публиковать на сайте извещение, документацию и проект договора с указанием всех условий, предусмотренных Законом №223-ФЗ.

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

Рекомендуем прочитать:

Я, автор данной статьи, в своей жизни успел побывать как заказчиком нескольких крупных проектов на десятки тысяч долларов, так и исполнителем не менее дорогих заказов. До того, как выйти на серьезный уровень, мне пришлось перечитать сотни «ТЗ», и составить с несколько десятков своих пояснений для исполнителя. С каждым разом технические задания были все четче и четче, что позволило получать финальный вариант работы такой, какой я себе и представлял. В данной статье хотелось бы поговорить о том, как написать техническое задание, на что обратить внимание в первую очередь. Также я расскажу, почему заказчику и исполнителю желательно не работать на добром слове, а все оформлять документально.

Для чего ТЗ заказчику?

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

Рекомендуем прочитать:

Для чего ТЗ исполнителю?

В первую очередь, это ваш ориентир на то, что нужно сделать. Часто заказчики что-то додумывают в процессе разработки, стараясь навязать Вам выполнение лишних задач. Вы хотите работать бесплатно? Уверен, что нет. Уточняйте, что сумма, оговорена в самом начале, касалась исключительно объема работ указанного в техническом задании. Все что более – оплачивается отдельно. Также при сдаче проекта вы сможете отчитаться по поставленным задачам и их выполнению. Я не раз сталкивался с моментами, когда заказчик не хотел принимать работу, аргументируя неполным ее выполнением. Но поднимания первоначальное ТЗ оказывалось, что тех задач, о которых шла речь, вообще никто не ставил. Еще раз акцентирую внимание – не работайте без ТЗ, ведь мнение заказчика может менять чаще чем погода, и Вам придется все десятки раз переделывать тратя свое время, и не получая за это дополнительную оплату.

С чего начать составление грамотного технического задания

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

• Общие положения технического задания

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

Рекомендуем прочитать:

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

• Цели проекта

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

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

• Функциональные требования

Все требования к заказчику можно разделить на два типа: функциональные и специальные. Функциональные требование – это те варианты исполнения, которые вы хотите видеть у себя. Если говорить на примере интернет сайта, то вы должны предоставить исполнителю примеры функциональных решений с других проектов, которые Вам нравятся, и которые вы хотите видеть у себя. Например, увидели технически понравившейся элементы, описали его, и сразу дали ссылку, чтоб человек наглядно понимал, о чем речь, и мог взять это за основу.

Рекомендуем прочитать:

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

• Сроки

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

• Отчетность

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

Также должен быть отчет по факту выполненных работ. Что было сделано, сколько на это потрачено времени, с какими трудностями столкнулся исполнитель и т.д.

• Ответственность

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

Рекомендуем прочитать:

И в конце это статьи, хотелось бы дать несколько советов исходя из собственного опыта составления и получения технических заданий.

1. Техническое задание должно быть детальное. Не бойтесь описывать каждый элемент, каждый пункт, каждую кнопку. Все-все-все максимально детально пишите. Не бойтесь показаться дотошным. Уж лучше что-то несколько раз повторить и разжевать, нежели потом доделывать, доплачивать, дорабатывать. Последнее техническое задание, которое я писал, касалось разработки сайта. Это был большой информационный проект. Сначала разработали дизайн, а потом на его основе описывал функциональное задание для программистов. Так вот, все ТЗ получилось на 54 страницы А4 11 шрифтом. Техническое задание шло как дополнение к основному договору, который тоже был на 7 страниц. Но хочу сказать, что даже в таком детальном ТЗ не все смог учесть, ведь в процессе разработки подписывали еще три дополнительных соглашения, которыми я вносил определенные корректировки в первоначальный вариант задания.
2. Техническое задание должно быть четкое. Не нужно никакой воды. Все по делу. Если пишите о срока, то конкретную цифру, если о функционале, то перечень нужных вам функциональных решений и т.д.
3. Ваше техническое задание – это не догма, а лишь один из возможных вариантов исполнения задач. Скажу честно, я не специалист в программировании. Да, я могу продумать структуру проекта, его функционал, какие-то технические решения, но всегда, составляя окончательный вариант ТЗ, советуюсь с исполнителями. Они могут что-то увидеть, высказать свое мнение, подсказать оптимальное решение исполнение.

Вот, пожалуй, и все, что я хотел рассказать в этой статье. Составить техническое задание не так уж и сложно, если четко понимать чего вы хотите от исполнителя. Можете еще раз перечитать мои советы, и применить их к конкретно вашему случаю. Удачи!

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

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

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

На основании ТЗ принимаются или отклоняются претензии Заказчика к качеству работы Исполнителя, оплачивается готовая работа, оформляется акт приема-передачи.

bikeriderlondon / Shutterstock.com

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

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

Заказчик и Исполнитель соглашаются

Подпись Заказчика и Исполнителя в настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:

1. Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание (ТЗ), который содержит перечень требований к выполняемым работам.
2. Заказчик согласен со всеми положениями настоящего ТЗ.
3. После утверждения ТЗ все предыдущие договоренности теряют силу и действуют только пункты данного ТЗ.
4. Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем ТЗ.
5. Исполнитель выполняет только работы, указанные в данном ТЗ.
6. Все что выходит за рамки пунктов данного ТЗ, Заказчиком оплачивается дополнительно, на основании утвержденных сторонами дополнений к данному ТЗ.
7. Исполнитель приступает к выполнению работ по ТЗ, после: письменного утверждения ТЗ, получения всей необходимой информации указанной в ТЗ, получения необходимых материалов заказчика и выполнения пунктов оплаты.
8. Заказчик берет на себя обязательства, по завершению принять работу в течении 3-5 рабочих дней, оплатить работы по данному ТЗ в указанные в нем сроки, в случае если работы выполнены в полном объеме и в соответствии с ТЗ.
9. Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем ТЗ.
10. Все работы по созданию сайта ведется на собственном хостинге Исполнителя. После завершения всех работ, переносится на реальный сервер для тестирования.
11. По окончанию работ, Исполнитель предоставляет консультации по администрированию в течение 5 рабочих дней, но не более получаса в день. Дополнительное время оплачивается отдельно, согласно действующих тарифов Исполнителя.
12. Все неоднозначности, выявленные в настоящем ТЗ после его подписания, подлежат двухстороннему согласованию между Сторонами. В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и оцениваются соответствующим образом.
13. Положения данного документа являются обязательными для разработчиков после его утверждения в установленном порядке.
14. ТЗ является средством верификации выполненных работ.

Статья по теме: 10 полезных советов при создании сайта

Совместимость с браузерами

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

• Internet Explorer (версия 8 и выше);
• Mozilla Firefox (версия 3 и выше);
• Google Chrome (версия 4 и выше);
• Opera (версия 10 и выше).

Требования к компоновке страниц сайта

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

Сайт также должен иметь ограничения и на максимальный размер, чтобы хорошо выглядеть на мониторах с высоким разрешением. Поэтому максимальная ширина сайта будет 1280×1024.

Требования к изменению содержимого сайта

Для удаленного администрирования (добавления, редактирования и удаления текстовой и графической информации) может использоваться бесплатная система управления контентом сайта (CMS), например WordPress. Но можно использовать и UMI.CMS (она более удобна пользователю для редактирования сайта, но сложнее для разработчика). Поэтому, если Заказчик пожелает использовать UMI.CMS, стоимость внедрения оговаривается отдельно, после утверждения дизайна. Ориентировочно она будет дороже на 50% от стоимости программирования.

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

Резюме

От того насколько подробно вы опишите задачи, стоящие перед разработчиком сайта, настолько проще будет сдавать проект. Вплоть до того что написать как открывается картинка во всплывающем окне, в какой она будет рамочке и будет ли она открываться с каим-то дополнительным эффектом. Так как очень часто заказчики, еще при создании сайта норовят вносить правки в текст, картинки и тому подобное, что собственно относится к совершенно другому этапу, который называется «Наполнение сайта» или «Обновление сайта».