Как написать техническое задание образец. Требования к совместимости со смежными системами

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

Техническое задание (далее - ТЗ) - это результат анализа процессов организации и концептуальных предложений по автоматизации этих процессов. До начала создания ТЗ необходимо провести информационное обследование процессов, оформляемое в виде отчета об обследовании, и разработать концепцию автоматизации, которая содержит саму идею автоматизации и раскрывает цели автоматизации, а также дает основные предложения по архитектуре и составу системы. При этом отчет об информационных процессах и концепция должны быть составлены в двух парадигмах: «как есть» и «как должно быть». Очень полезным дополнением к этим отчетам будет графическое отображение процессов (так называемое моделирование процессов) в любой выбранной методологии. Самыми распространенными методологиями на сегодня в российской практике являются нотации ARIS * с одноименным инструментарием и UML **. Разработка СЭД - это всегда проектная деятельность, у которой есть начало и конец. Разработка заканчивается передачей системы в промышленную эксплуатацию и началом процесса сопровождения СЭД.

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

1. Каскадная модель.

Каскадная, или классическая модель разработки (англ. waterfall model - модель водопада) - модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

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

2. Итерационная модель.

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

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

Какой из этих подходов правильный - зависит от конкретного проекта (объема задач проекта) и от пожеланий заказчика.

Тем не менее, независимо от выбранной модели разработки, в каждой из них есть стадия формирования требований к создаваемой СЭД. Эта стадия и правила создания самого ТЗ описаны в российском законодательстве, а именно в ГОСТах 34-й серии. Основные документы - ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание авто­матизированной системы и РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

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

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

Согласно ГОСТ 34.602-89, основными разделами ТЗ являются:

1. Общие сведения.

2. Назначение и цели создания (развития) системы.

3. Характеристика объектов автоматизации.

4. Требования к системе.

5. Состав и содержание работ по созданию системы.

6. Порядок контроля и приемки системы.

7. Требования к составу и содержанию работ по подготов­ке объекта автоматизации к вводу системы в действие.

8. Требования к документированию.

9. Источники разработки.

Все эти разделы могут быть разбиты на подразделы и могут включать приложения, которые приводятся в конце документа и оформляются как приложения к ТЗ. Такой же состав имеет и ЧТЗ, которое может создаваться при итерационном подходе в больших проектах для уточнения требований. ТЗ на СЭД должно оформляться на листах формата А4 по ГОСТ 2.301-68* без рамки, основной надписи и дополнительных граф к ней.

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

Титульный лист ТЗ содержит следующие реквизиты:

Гриф «Утверждаю»;

Полное наименование СЭД;

Наименование документа (в нашем случае - «Техническое задание» и «Частное техническое задание»);

Код документа;

Количество листов;

Место составления документа.

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

Код ТЗ на СЭД - это обозначение конструкторского документа, которое присваивается заказчиком или разработчиком документа согласно ГОСТ 2.201-80**. Код состоит из следующих частей: первые 4 символа - код организации-разработчика, следующие 6 символов - код классификационной характери­стики, следующие 3 цифры - порядковый регистрационный номер. Например, номер ТЗ может выглядеть так:

ЦНТП. 425180.048.

Особенности написания некоторых разделов ТЗ

Раздел «Общие сведения » должен включать сведения о заказчике и возможном исполнителе работ, о способе определения исполнителя, бюджете, из которого финансируется создание СЭД, и примерных сроках и этапах проведения работ по созданию СЭД.

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

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

Например, целью внедрения СЭД может быть сокращение сроков согласования договоров до 1 рабочего дня по всем филиалам компании.

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

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

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

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

2. Требования к функциям (задачам), выполняемым систе­мой, должны содержать описание функционала подсистем (модулей) СЭД.

3. Требования к взаимодействию подсистем (модулей) СЭД должны описывать механизмы взаимодействия подсистем (модулей).

4. Требования к взаимосвязи со смежными системами организации должны описывать, какие системы являются смежными и как они могут быть связаны с СЭД.

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

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

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

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

Раздел «Состав и содержание работ по созданию системы» целесообразно делать в виде таблицы с указанием наименования этапов работ по созданию СЭД, примерных сроков начала и окончания этапов, а также результатов окончания этих этапов.

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

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

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

Раздел «Требования к документированию» описывает общие правила составления рабочей документации к системе и может ссылаться на корпоративные стандарты или ГОСТы.

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

При этом в тексте ТЗ должны быть проставлены ссылки на все источники разработки. Указание того или иного источника должно быть обоснованным и подтверждаться в тексте ТЗ.

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

* ARIS (англ. Architecture of Integrated Information Systems) – принадлежащие компании Software AG методология и тиражируемый программный продукт
для моделирования бизнес-процессов организаций.
** UML (англ. Unifi ed Modeling Language) – язык графического описания для объектного моделирования в области разработки программного обеспечения; был создан для определения, визуализации, проектирования и документирования в основном программных систем.

Глоссарий

Термин	Описание
	Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных HTML-страниц
World wide web (WWW, web, веб)	Единое информационное пространство на базе сети Internet, состоящее из совокупности сайтов. Приставка "веб-" может использоваться для обозначения объектов, ориентированных на использование в WWW или использующих типичные для WWW технологии (например, веб-интерфейс - интерфейс на базе веб-страниц)
HTML-страница (веб-страница, страница)	Основной носитель информации в World ide Web. Особым образом сформатированный файл (набор файлов), просматриваемый с помощью www-браузера как единое целое (без перехода по гиперссылкам)
HTML-теги (теги)	Управляющие коды, посредством которых осуществляется форматирование HTML-страницы
	Активный элемент HTML-страницы, задаваемый специальным тегом. Выделенный фрагмент текста или изображения, позволяющий загрузить другую страницу или выполнить определенное действие
WWW-браузер (браузер)	Клиентская программа, поставляемая третьими сторонами и позволяющая просматривать содержимое HTML-страниц
HTML-форма (форма)	Часть HTML-страницы, предназначенная для взаимодействия с посетителем сайта. Представляет собой набор элементов (текстовых полей, селекторов, выпадающих списков), посредством которых пользователь может ввести какую-либо информацию и отправить ее для обработки на сервере
Поле (поле БД, поле формы)	Структурный элемент, содержащий однотипную информацию, например, текст, дату, числовые значения и т.п.
	Особое поле данных, могущее содержать только одно из двух допустимых значений. Позволяет указать на наличие или отсутствие какого-либо события или свойства объекта
Справочник	Вспомогательная структура данных, содержащая список допустимых значений для какого-либо поля основных форм или БД. Справочники подразделяются на фиксированные (неизменяемые и поставляемые Исполнителем вместе с готовым сайтом) и редактируемые (состав которых может изменяться администратором)
Администратор (менеджер, редактор) сайта	Лицо, осуществляющее от имени Заказчика информационную поддержку сайта
Дизайн-шаблон страниц
Дизайн веб-сайта	Уникальные для конкретного веб-сайта структура, графическое оформление и способы представления информации
Информационные материалы	Информация о деятельности Заказчика. Может включать графические, текстовые, аудио или видео материалы. Предоставляется Заказчиком
Наполнение (контент)	Совокупность информационного наполнения веб-сайта. Включает тексты, изображения, файлы и т.п. предназначенные для пользователей системы
Элемент наполнения (контента)	Отдельная запись в базе данных, внешнее представление которой зависит от управляющего ей программного модуля (например, в модуле «новостная лента» элементом наполнения является отдельная новость)
Система динамического управления наполнением (контентом) сайта
	Совокупность объектов базы данных, представленная в виде файлов, позволяющая восстановить точную копию структуры исходной базы данных в аналогичной системе управления базами данных
Веб-интерфейс	Совокупность экранов и элементов управления системы, позволяющих пользователю, осуществляющему доступ к системе через веб-браузер, осуществлять поддержку и управление системой.
Шаблона раздела	Ссобым образом размеченный ASCII-файл, определяющий как графическое оформление страниц раздела, так и их макет (раскладку) - взаимное расположение блоков с наполнением раздела
WYSIWYG редактор	Редактор языка HTML, имеющий возможности по работе в текстовом режиме и в режиме WYSIWYG (What You See Is What You Get). В режиме WYSIWYG элементы HTML страницы при редактировании представляются в том же виде, что и при просмотре
	Класс пользователей системы, обладающих определенным набором прав доступа

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

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

Предмет разработки

Предметом разработки является Интернет-сайт компании ООО «…», с системой динамического управления наполнением на базе веб-интерфейса.
Назначение сайта:
- предоставление информации о компании ООО «…»;
- предоставление информации о деятельности компании ООО «…»;
- т.д.;
- пр.

Цель создания сайта: ... .

Назначение документа

В настоящем документе приводится полный набор требований к реализации сайта компании ООО "".
Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:
1. Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание, который содержит перечень требований к выполняемым работам.
2. Заказчик согласен со всеми положениями настоящего Технического Задания.
3. Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем Техническом Задании.
4. Исполнитель обязуется выполнить работы в объёме, указанном в настоящем Техническом Задании.
5. Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем Техническом Задании.
6. Все неоднозначности, выявленные в настоящем Техническом задании после его подписания, подлежат двухстороннему согласованию между Сторонами. В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и соответствующим образом оцениваются.

Требования к графическому дизайну сайта

Требования к дизайну сайта

При разработке сайта должны быть использованы преимущественно светлые стили.
Основные разделы сайта должны быть доступны с первой страницы.
На первой странице не должно быть большого объема текстовой информации.

В дизайне сайта не должны присутствовать:
- мелькающие баннеры;
- много сливающегося текста;
- т.д.;
- пр.

Порядок утверждения дизайн-концепции

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

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

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

Требования к представлению главной страницы сайта Главная страница сайта должна содержать графическую часть, навигационное меню сайта, а также контентную область для того, чтобы посетитель сайта с первой страницы мог получить вводную информацию о компании, а также ознакомиться с последними новостями компании.
Контентная область первой страницы должна делиться на следующие разделы:
- вступительная статья о компании со ссылкой «подробнее», ведущей на раздел «О компании»;
- новости - содержит 3 последние новости (анонсы) в формате: дата, заголовок, краткое содержание;
- краткая контактная информация - телефон и e-mail компании;
- вверху страницы отображаются облегченная навигационная панель, которая обеспечивает переход к основным пунктам меню сайта (О компании, Новости и т.д.);


- счетчики и ссылка на страницу обмена ссылками.

Рис. 1. Пример размещения элементов главной страницы.

Графическая оболочка внутренних страниц (общая для всех подразделов)
Графическая оболочка внутренних страниц должна делиться на следующие разделы:
- графическая шапка
- навигационное меню сайта (навигационная панель 2 обеспечивает переход к основным пунктам меню сайта);
- поле поиска - предназначено для выполнения полнотекстового поиска по сайту;
- поле выбора языка - русский\английский;
- ссылка «На главную»;
- навигационная панель по подразделам выбранного раздела сайта;
- поле для отображения контента выбранной страницы сайта;
- внизу страницы - краткая контактная информация - телефон и e-mail компании;
- кнопка «Для печати» - обеспечивает вывод контентной области в виде, отверстанном для печати на листах формата А4;
- кнопка «Задать вопрос» - обеспечивает переход к форме «Задать вопрос».

Рис. 2. Пример размещения элементов внутренних страниц сайта.

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

a. История компании
b. Дипломы и сертификаты
c. Наши партнеры
d. Наши клиенты
e. Наши координаты
f. ...

2. Новости
3. т.д.
4. пр.

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

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

О компании
- Новости
- т.д.;

Рис. 3. Макет формы главной страницы административной части сайта.

Требования к управлению разделами сайта
Для управления разделами сайта должны быть предусмотрены следующие функции:
- создание подраздела 1 уровня;
- создание подраздела 2 (и далее) уровня;
- редактирование контента страницы;
- удаление раздела;
- перемещение раздела вверх в списке;
- перемещение раздела вниз в списке;
- признак показа (show) или не показа (hide) страницы в клиентской части сайта;
- отображение списка подразделов выбранного уровня.

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

Рис. 4. Поля элемента контента.

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

Рис. 5. Редактор многострочного текста в административной части.

Для каждого элемента контента должен определяться требуемый набор полей. Например, для элемента «Новость» определяется следующий набор полей контента:

Рис. 6. Пример представления элемента контента «Новость» в административной части.

Список элементов контента должен позволять:
. перейти к редактированию полей элемента списка;
. удалить элемент списка;
. определить порядок элементов списка вывода в клиентской части;
. указать признак hide\show.

Рис. 7. Пример представления списка элементов контента в административной части и их отображения в клиентской части.

В списке элементов должны выводиться все поля элемента, кроме полей вида «Многострочный текст».

Управление настройками сайта
В состав настроек сайта должны входить:
- e-mail для …;
- т.д.;
- пр.

Дополнительные функции административной части
В состав дополнительных функций административной части должны входить:
- …;

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

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

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

Требования к информационному обеспечению

Требования к хранению данных
Все данные сайта должны храниться в структурированном виде под управлением реляционной СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания (изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД размещаются ссылки на них.
Наполнение различных сайтов, функционирование которых поддерживается одной и той же инсталляцией системы, должно храниться под управлением единой СУБД.
Требования к языкам программирования
Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS. Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).
Для реализации интерактивных элементов клиентской части должны использоваться языки JavaScript и DHTML.
Для реализации динамических страниц должен использоваться язык PHP.
Требования к организации гиперссылок
Все ссылки на сайте должны быть относительными (за исключением внешних).

Требования к иллюстрациям
Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.
Требования к объему одной страницы
Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.
Объем flash-заставки не должен превышать 300 Kb.

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

Требования к программному обеспечению серверной части
Для функционирования сайта необходимо следующее программное обеспечение:
- Операционная система - Windows XP и Windows Server 2003;
- Веб-сервер - Apache версии не ниже 1.3.26;
- СУБД - MySQL версии не ниже 3.23;
Требования к клиентскому программному обеспечению
Сайт должен быть доступен для полнофункционального просмотра с помощью следующих браузеров:
. MS IE 5.0 и выше;
. Opera 6.0 и выше;
. Mozilla Firefox 1.0;
. Mozilla 1.7.
Сайт должен быть работоспособен (информация, расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и JavaScript.

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

Для функционирования сайта необходимо следующее техническое обеспечение со следующими минимальными характеристиками:
- процессор - Intel Pentium III 1 Ghz;
- оперативная память - 512 Mb RAM;
- жесткий диск - 20 Gb HDD.
- т.д.;
- пр.

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

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

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

Сайт должен быть оптимизирован для просмотра при разрешении 1024*768, 1280*1024 без горизонтальной полосы прокрутки и без пустых (белых) полей для основных типов разрешения.
Элементы управления должны быть сгруппированы однотипно - горизонтально либо вертикально - на всех страницах.
На каждой странице должны отображаться логотип компании и контактная информация.
Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

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

Требования к наполнению информацией

Общие требования к информационному наполнению
В рамках работ по данному проекту Исполнитель обеспечивает наполнение разделов сайта предоставленными Заказчиком материалами в порядке, указанном в п. 6.1.2.
Исполнитель обеспечивает обработку иллюстраций для приведения их в соответствие с техническими требованиями и HTML-верстку подготовленных материалов. Сканирование, набор и правка-вычитка текстов, ретушь, монтаж, перевод и другие работы могут быть выполнены Исполнителем на основании дополнительного соглашения (после просмотра имеющихся у заказчика материалов).
После сдачи системы в эксплуатацию информационное наполнение разделов, осуществляется на основании договора на поддержку сайта.
Объем текста и количество иллюстраций в других типах разделов определяется предусмотренной настоящим ТЗ структурой данных и уточняется на этапе согласования дизайн-концепции.
Порядок предоставления информационного наполнения
Заказчик предоставляет материалы в электронной форме в zip-архиве, содержащем дерево директорий, соответствующих структуре сайта.
В каждой директории размещается набор документов в формате MS Word - по одному документу на каждый информационный модуль, информационные блоки которого опубликованы в соответствующем разделе. Не допускается размещение текста в виде графических изображений или иных нетекстовых элементов.
Изображения могут быть размещены как в тексте внутри файла, так и в виде отдельного изображения. Однако, в последнем случае текст должен содержать ссылку на изображение в виде указания пути и названия файла изображения.
Для каждого информационного модуля структура документа должна соответствовать шаблонам, предоставляемым Исполнителем до начала этапа предоставления материалов.
Материалы для первоначального наполнения разделов должны быть полностью представлены Исполнителю в сроки, установленные планом-графиком работ. Допускается передача материалов частями, в нескольких zip-файлах, соответствующих приведенным требованиям.
Передача материалов в объеме и формате, соответствующем настоящему ТЗ закрепляется подписанием Акта о передаче информационного наполнения.
Любые изменения информационного наполнения силами Исполнителя после подписания данного Акта допускаются только на основании отдельного соглашения за дополнительную плату.
Информационные материалы, не предоставленные Заказчиком в сроки, установленные планом-графиком работ, размещаются Исполнителем по гарантийному письму Исполнителя в течение 2-х недель после сдачи-приемки проекта. На эту часть информационных материалов также накладываются требования к формату предоставления, изложенные выше.

Требования к персоналу

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

Порядок предоставления дистрибутива

По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив системы в составе:
-архив с исходными кодами всех программных модулей и разделов сайта;
- дамп проектной базы данных с актуальной информацией.
Дистрибутив предоставляется на CD-диске в виде файлового архива.

Порядок переноса сайта на технические средства заказчика

После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем производится однократный перенос разработанного программного обеспечения на аппаратные средства Заказчика. Соответствие программно-аппаратной платформы требованиям настоящего документа обеспечивает Заказчик.
Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и доступ к базе данных сайта.

«Сделать хотел грозу, а получил козу…», - думаете вы, принимая от разработчика новенький сайт. Вроде бы исполнителя подбирали по рекомендации. И портфолио у него внушает доверие. И работает не первый год. А сделал всё равно совсем не то, что представляли себе вы. И вот вы уже разочаровались в сайтостроителях и уверены, что вас окружают жулики и дилетанты.

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

Снизить риски и повысить вероятность получить интернет-ресурс вашей мечты поможет правильно составленное техническое задание на создание сайта.

Зачем нужно техзадание?

• Исполнителю грамотное ТЗ на разработку сайта поможет заранее оценить объём работы, её сложность и стоимость. Понять, справится ли он с такой задачей самостоятельно, или стоит взять помощников. А затем сделать именно то, чего от него ждёт заказчик.
• Заказчику техзадание даёт уверенность в том, что он задокументировал свои пожелания к будущему сайту, чётко обозначил сроки, в которые должен уложится исполнитель, прописал требования к работе сайта. И если результат окажется неудовлетворительным, можно предъявить обоснованную претензию: «Не соответствует ТЗ!»

Как выглядит техническое задание на сайт?

Ваше пожелание «блог с бесплатными материалами, страницей обо мне и контактами» исполнитель видит так:

Вы думаете, этого достаточно для создания сайта?

Вы получаете готовый сайт, и тут вдруг оказывается, что вы имели в виду вот это:

Нюансы описания очень важны

Чувствуете разницу? Формально здесь неправы обе стороны: вы не добавили подробности, исполнитель о них не спросил. Но он уже получил оплату и готов пропасть вместе с ней, а у вас недоделанный сайт, непредвиденные расходы и полное разочарование в специалистах по созданию сайтов.

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

О чём пишут в техзадании?

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

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

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

• Для чего и для кого создаётся сайт?
• Чем он будет наполнен?
• Как это всё будет функционировать?
• Кто и как будет работать над проектом, кто за что отвечает?
• Что будет приниматься на выходе?

Основные разделы технического задания на разработку сайта

1. Информация о заказчике, то есть о вас

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

2. Информация о проекте

Что это будет: сайт-визитка, интернет-магазин, корпоративный портал, электронная библиотека?

3. Целевая аудитория сайта

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

Вы решились на собственный сайт, но до сих пор не представляете себе в подробностях, кто ваш клиент? Значит, сейчас самое время составить его детальный портрет.

4. Цели и задачи, которые должен решать сайт для заказчика и для аудитории

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

Указывайте прямое назначение вашего сайта.

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

5. Рамки проекта (основной функционал)

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

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

6. Структура (карта) сайта

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

Структуру удобнее рисовать, чем описывать. В графическом виде легче продумать взаимосвязь областей сайта.

Схема взаимосвязей отдельных частей сайта

У нас в на эту тему есть вебинар «Система контента продающего сайта». И вот о структуре сайта, о взаимосвязи страниц и ссылках между ними мы там подробно рассказываем. Рекомендую! Картинка выше - из материалов этого вебинара.

7. Отдельные страницы

Пока вы рисуете карту сайта, каждая страница - это просто квадратик. Но исполнителю нужно понимать, что и в каком порядке на этом квадратике будет расположено (вспоминаем примеры таблиц в начале статьи). Какие там будут информационные блоки? На каждой ли странице будут меню, сайдбар (отдельный блок с навигацией) , футер (нижний блок) ? Хотите ли вы видеть на странице баннеры, картинки? Будут ли они статичные или движущиеся?

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

По сути на этом этапе создаётся . Об этом мы уже писали, если вам предстоит создание сайта, обязательно почитайте.

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

8. Требования к дизайну сайта

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

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

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

9. Рабочий функционал сайта

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

Какая форма подписки? Как она выглядит? Как работает? Что за календарь? Показывает ли он только сегодняшнее число или весь последний месяц? Можно в нём листать страницы или нельзя? Этих нюансов исполнитель может не угадать, в итоге вы получите совсем не то, чего хотели. Деньги заплачены, проект соответствует ТЗ (вы же написали «календарь» - вот он), а вам придётся довольствоваться тем, что получилось, хотя это вовсе не то, чего хотелось, или переплачивать за изменения.

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

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

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

10. Описание контента

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

11. Технические требования

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

Пример нашёлся на habrahabr.ru/post/140574/

Если не разбираетесь, включайте логику и здравый смысл. Подумайте, что скажет вам о том, что сайт работает корректно?

Например, ваш сайт должен:

• одинаково хорошо смотреться на мониторах разной ширины;
• адекватно отображаться в разных браузерах (каких именно?);
• открываться с мобильных устройств (или вы будете разрабатывать отдельную мобильную версию сайта?);
• уметь противостоять вирусам;
• иметь встроенный seo-функционал и так далее.

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

В остальном придётся полагаться на совесть исполнителя.

Информация, которую я дала в статье, - мой опыт. Мне приходилось заказывать сайты с нуля и дорабатывать существующие. Первая версия сайта аzconsult.ru - один из самых маленьких проектов, с которыми я работала. Для крупных проектов есть нюансы, но не думаю, что они вам понадобятся.

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

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

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

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

Как правило, этапу составления технического задания предшествует проведение обследования предметной области, которое завершается созданием аналитического отчета. Именно аналитический отчет (или аналитическая записка) ложится в основу документа Техническое задание.

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

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

Руководствующими стандартами при написании технического задания являются ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» . Первый стандарт предназначен для разработчиков автоматизированных систем, второй для программных средств (разницу между данными сериями мы обсуждали в статье «Что такое ГОСТ»).

Итак, ниже мы представляем список и описание разделов, которые должно содержать техническое задание согласно ГОСТам.

ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению	ГОСТ 34.602.89 Техническое задание на создание автоматизированной системы
1. Введение	1. Общие сведения
2. Основания для разработки
3. Назначение разработки	2. Назначение и цели создания системы
	3. Характеристика объекта автоматизации
4. Требования к программе или программному изделию	4. Требования к системе
4.1. Требования к функциональным характеристикам	4.2. Требования к функциям (задачам), выполняемым системой
	4.1. Требования к системе в целом
	4.1.1. Требования к структуре и функционированию системы
	4.1.3. Показатели назначения
4.2. Требования к надежности	4.1.4. Требования к надежности
	4. 1.5. Требования к безопасности
	4. 1.6. Требования к эргономике и технической эстетике
4.3. Условия эксплуатации	4.1.2. Требования к численности и квалификации персонала системы и режиму его работы
	4. 1.9. Требования к защите информации от несанкционированного доступа
	4. 1.10. Требования по сохранности информации при авариях
	4. 1.11. Требования к защите от влияния внешних воздействий
	4. 1.12. Требования к патентной чистоте
	4. 1.13. Требования по стандартизации и унификации
4.4. Требования к составу и параметрам технических средств	4. 1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.5. Требования к информационной и программной совместимости
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению	4. 1.7. Требования к транспортабельности для подвижных систем
4.8. Специальные требования	4. 1.14. Дополнительные требования
	4.3. Требования к видам обеспечения
5. Требования к программной документации	8. Требования к документированию
6. Технико-экономические показатели
7. Стадии и этапы разработки	5. Состав и содержание работ по созданию системы
8. Порядок контроля и приемки	6. Порядок контроля и приемки системы
	7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
	9.Источники разработки

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

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

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

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

Пример:

«В данном документе создаваемая информационная система называется «Единое окно доступа к образовательным ресурсам», сокращенно ЕО.
Систему Единое окно доступа к образовательным ресурсам далее в настоящем документе допускается именовать Единое окно или Система.»

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

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

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

Термины и сокращения располагаются в алфавитном порядке. В первую очередь принято давать расшифровку русскоязычным терминам и сокращениям, потом англоязычным.

Назначение и цели создания системы

Данный раздел документа Техническое задание должен содержать назначение и цели создания системы.

Пример:

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

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

Создание информационной системы «Единое окно» должно обеспечить:

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

Создание Системы позволит сократить эксплуатационные затраты в результате повышения эффективности работы ведомства.»

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

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

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

Пример:

«4.1 Бизнес-процесс «Предоставление информации об образовательных учреждениях Российской Федерации

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

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

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

4.1.1 Регистрация образовательного учреждения в Системе

Регистрация образовательного учреждения Российской Федерации осуществляется ответственным сотрудником учреждения («Постановление Правительства …»).

Процесс регистрации образовательного учреждения включает следующие шаги:

• Автор создает запись об организации;
• Автор заносит данные организации;
• Система проверяет наличие лицензии для данной организации

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

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

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

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

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

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

Требования к документированию

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

Данный раздел технического задания также важен, как и описание функциональных требований, поэтому не следует ограничиваться фразой «Заказчику должна быть предоставлена вся документация согласно ГОСТ 34». Это означает, что вы должны предоставить весь пакет документов включая «Формуляр», «Паспорт» и т.п. Большинство документов из списка, указанного в ГОСТ 34.201-89 не нужны ни вам, ни заказчику, поэтому лучше сразу согласовать список на этапе разработки документа Техническое задание.

Минимальный пакет документов обычно включает:

• Техническое задание;
• Ведомость эскизного (технического) проекта;
• Пояснительная записка к Техническому проекту;
• Описание организации информационной базы;
• Руководство пользователя;
• Руководство администратора;
• Программа и методика испытаний;
• Протокол приемочных испытаний;
• Акт выполненных работ

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

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

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

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

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

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

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

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

Техническое задание на разработку программы «______________» к Договору №___ 1. Введение 1.1. Наименование программы 1.2. Назначение и область применения 2. Требования к программе 2.1. Требования к функциональным характеристикам 2.2. Требования к надежности 2.2.1. Требования к обеспечению надежного функционирования программы 2.2.2. Время восстановления после отказа 2.2.3. Отказы из-за некорректных действий пользователей системы 3. Условия эксплуатации 3.1. Климатические условия эксплуатации 3.2. Требования к квалификации и численности персонала 3.3. Требования к составу и параметрам технических средств 3.4. Требования к информационной и программной совместимости 3.4.1. Требования к информационным структурам и методам решения 3.4.2. Требования к исходным кодам и языкам программирования 3.4.3. Требования к программным средствам, используемым программой 3.4.4. Требования к защите информации и программ 3.5. Специальные требования 4. Требования к программной документации 4.1. Предварительный состав программной документации 5. Технико-экономические показатели 5.1. Экономические преимущества разработки 6. Стадии и этапы разработки 6.1. Стадии разработки 6.2. Этапы разработки 6.3. Содержание работ по этапам 7. Порядок контроля и приемки 7.1. Виды испытаний 7.2. Общие требования к приемке работы 1. Введение 1.1. Наименование программы Наименование программы: «АСУ «______________»» 1.2. Назначение и область применения Программа предназначена для автоматизации обработки данных клиентов кафе/бара. Она оперирует следующими данными: возможные персональные данные о клиент; данные по обслуживанию клиента; данные по дисконтной системе; 2.1. Требования к функциональным характеристикам Программа должна обеспечивать возможность выполнения перечисленных ниже функций: возможность вывода данных о клиенте по запросу; возможность расчета скидок; добавление/удаление клиентов; изменение данных о клиенте; возможность изменения дисконтной системы; 2.2.1 Требования к обеспечению надежного функционирования программы Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже: организацией бесперебойного питания технических средств; использованием лицензионного программного обеспечения; регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»; регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов Со стороны разработчика: автоматическое создание резервных копий; система автоматического обновления программы; автоматическое восстановление системы; Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать 30-ти минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств. Отказы программы вследствие некорректных действий пользователя при взаимодействии с программой. 3.1. Требования к квалификации и численности персонала Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 1 штатной единицы - оператор ПК. В перечень задач, выполняемых оператором ПК, должны входить: ведение базы данных по клиентам; задачи установки (инсталляции) и поддержания работоспособности системных программных средств - операционной системы; задача установки (инсталляции) программы; задача создания резервных копий базы данных. 3.2. Требования к составу и параметрам технических средств ^ процессор с тактовой частотой 2.0Hz, не менее; оперативную память объемом, 1Гигабайт, не менее; свободное дисковое пространство не менее 1гб; сетевая карта; 3.3.1. Требования к информационным структурам и методам решения Программное обеспечение представляет из себя самостоятельное исполняемое приложение. Формат базы данных совместим с ADO. Пользователи работают с базой данных через системный интерфейс. 3.3.3. Требования к исходным кодам и языкам программирования Дополнительные требования не предъявляются. Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows XP. Требования к защите информации и программ не предъявляются. 3.5. Специальные требования Специальные требования не предъявляются. ^ 4.1. Предварительный состав программной документации Состав программной документации должен включать в себя: техническое задание; программу и методики испытаний; руководство оператора; 5.1. Экономические преимущества разработки Программа является бесплатным продуктом, финансовые средства не затрачиваются, и преимуществом является ускорение автоматизации обработки данных клиентов кафе/бара 6.1. Стадии разработки Разработка должна быть проведена в три стадии: Разработка технического задания; Рабочее проектирование; Внедрение. На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания. На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ: разработка программы; разработка программной документации; испытания программы. На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы. На этапе разработки технического задания должны быть выполнены перечисленные ниже работы: Постановка задачи; Определение и уточнение требований к техническим средствам; Определение требований к программе; Определение стадий, этапов и сроков разработки программы и документации на неё; Согласование и утверждение технического задания. На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы. На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями к составу документации. На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ: Разработка, согласование и утверждение и методики испытаний; Проведение приемо-сдаточных испытаний; Корректировка программы и программной документации по результатам испытаний. На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика. 7.1. Виды испытаний: тестирование процесса установки; тестированиеэргономики; тестирование способности системы к восстановлению нормальной работы; испытания системы на различных конфигурациях; системное тестирование; 7.2. Требования к приемке работы При приёмке необходимо проверить соблюдение следующих условий: полноты и качества реализации функций при штатных предельных критических значениях параметров объекта автоматизации и в других условиях функционирования данных в ТЗ; выполнению каждого требования относящегося к интерфейсу системы; Работы персонала в диалоговом режиме; Средств и методов восстановления работа способности ПП после отказов; Комплексности и качества эксплуатационной документации.

	Техническое задание на разработку дизайн проекта помещения. Информация		Техническое задание на разработку проектной документации для строительства зоопарка Положения В границах земельного участка ул. Подлесная, шоссе Космонавтов, ул. Малкова, Дзержинского района г. Перми
	Техническое задание на разработку интернет-сайта структура документа Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного…		Техническое задание на разработку веб-сайта «Объединение Российских Художников Аэрографии» Основной html контейнер, в который вставляются информационные блоки, должен быть полностью доступен для редактирования. Желательно…
	Техническое задание на создание автоматизированной системы «Корпоративное хранилище данных» Гост 34. 602-89 Техническое задание на создание автоматизированной системы (пример)		2. Техническое задание на разработку ис В данном курсовом проекте приведен процесс выдачи пенсионного страхового свидетельства. Разработанная система предназначена для упрощения…
	Техническое задание на разработку сайта журнала Настоящее тз представляет… Сайт моделируется с учетом ограничений современных систем контент-менеджмента (открытых WordPress, Joomla, LiveStreet и им подобных…		Программа демонстрации алгоритмов обхода графов Данное техническое задание регламентирует разработку учебного программного продукта предназначенного, для наглядного представления…
	Техническое задание включает в себя: наименование разработки, основание… Технико-рабочий проект: описание предметной области (объектная модель), управление объектами (события, диаграмма взаимодействия),…		Проектирование программных средств Этап проектирования подразумевает разработку архитектуры, разработку данных и процедурную разработку программных средств

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

Технический облик изделия

Теория решения изобретательских задач — это советская методика сильного мышления, получившая широкое как в России, так и в мире. Она позволяет глубоко проанализировать проблему и найти эффективное решение.
Работа над ТРИЗ была начата Генрихом Сауловичем Альшуллером и его соратниками в 1946 году.

Разработка программы: пример технического задания

В 1956 году вышла первая публикация про то, что техника развивается по определенным законам. Чтобы эффективно изобретать, нужно эти законы выявить и эффективно применять
Со временем ТРИЗ развился в большой набор инструментов, помогающие решать ряд актуальных задать:
— создавать новые прорывные продукты,
— повышать потребительские свойства имеющихся решений,
— снижать себестоимость,
— обходить патенты конкурентов.
Ведущие мировые компании, такие как Samsung, Intel, Procter&Gambel, General Electric и другие используют ТРИЗ в своих R&D центрах.

Термины

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

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

Назначение технического задания

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

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

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

Состав типового технического задания

Давайте рассмотрим, что же включает в себя типовое ТЗ.

Техническое задание программного обеспечения оказалось поверхностным?

Итак, техническое задание, вне зависимости от выбранного ГОСТа, всегда включает следующие основные сведения по разрабатываемому ПО:

1) наименование – полное и краткое названия, условное обозначение разрабатываемого ПО;
2) назначение – то, для чего, в какой области и с какой целью разрабатывается ПО;
3) основание для разработки – документы, на основании которых производится разработка ПО;
4) функции – перечень и описание функций разрабатываемого ПО;
5) структура – описание архитектуры и компонентов разрабатываемого ПО;
6) пользовательский интерфейс – в современном мире обязателен;
7) надежность, безопасность, условия эксплуатации и проч. важные требования;
8) документация – какая документация, в каком объеме и в соответствии с какими требованиями ГОСТов будет также разработана;
9) стадии и этапы разработки – что и в какой последовательности разрабатывается;
10) порядок контроля и приемка – как именно будет происходить сдача разработанного ПО Заказчику.

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

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

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

В целом, составление ТЗ – это достаточно сложная и ответственная задача, но грамотно составленное техническое задание – это уже половина успеха разрабатываемого проекта. Поэтому в процессе разработки ТЗ на ПО вы должны проявить максимальную внимательность и осведомленность в технических и организационных вопросах. Либо можете заказать у нас ​разработку технического задания «под ключ» прямо сейчас.

Возможно, вас также заинтересует:

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

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

Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document). Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.

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

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

Структура технического задания

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

Class="fs-13">

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

В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте. Ранее менеджеры компании использовали другую, отличную от нашей, систему размещения баннерной рекламы. В противном случае — анализ ролей и прав доступа был бы скорее всего вынесен в отдельную главу.

class="fs-13">

7. Система размещения баннеров
8.

Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine

class="fs-13">

Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами.

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

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

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

Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.

class="fs-13">

Бизнес vs Функциональные требования

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

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

— Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в системе. На этапе разработки технического задания функциональные требования обычно фиксируются только для наиболее сложных блоков проекта.

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

Пример бизнес-требования:

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

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

Обычно мы включаем

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

Правильное техническое задание на разработку программного обеспечения – секрет успешного проекта

Роль: Администратор

Пример функционального требования:

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

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

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

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

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

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

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.

Основные принципы

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

У руководителей предприятий обычно нет времени на изучение многостраничных технических требований. Просмотр изображений даёт наглядное представление об основных характеристиках разрабатываемой системы. Как следствие, улучшается коммуникация между бизнес-пользователем и нами и растет качество самих требований.

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

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

Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.

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

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

Опыт в предметной области

Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными. Накопленный опыт в области управленческих бизнес-систем, крупных интернет-проектов, финансовых систем, e-commerce систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.

Поиск Лекций

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

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

Техническое задание — это основной исходный документ для разработки продукции, содержащий технико-экономические требования к продукции, определяющие ее потребительские свойства и эффективность применения, перечень документов требующих совместного рассмотрения, порядок сдачи и приемки результатов разработки. Техническое задание на проектирование разрабатывается на основании ГОСТ 15.001-88 и оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-68.

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

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

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

· установить общую цель создания технической системы;

· установить общие требования к проектируемой системе;

· определить этапы создания системы и сроки их выполнения;

· провести предварительный расчет затрат на создание системы.

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

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

2) код изделия;

3) основания для разработки;

4) цель и технико-экономическое обоснование;

5) источники для разработки;

6) этапы разработки и запуска производства;

7) технические требования.

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

В разделе Основание для разработки указывают наименование документа (документов), которым предусмотрена данная разработка, организацию, утвердившую этот документ, и дату его утверждения, наименование и шифр темы разработки.

Основанием для разработки является маркетинговые исследования и выход нового стандарта.

В разделе «Цель и технико-экономическое обоснование разработки» указывают:

1. Конкретное функциональное назначение объекта – для снижения токсичности автомобиля.

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

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

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

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

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

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

Основные этапы разработки: маркетинговые исследование; разработка ТЗ; — проектирование объекта; испытание; подготовка производства; запуск в производство.

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

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

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

1.Технические требования

2. Требования безопасности

3. Требования охраны окружающей среды

4. Правила приемки

5. Методы контроля

6. Транспортирование и хранение

7. Указание по эксплуатации

8. Гарантии изготовителя

9. Утилизация

На основе разработанных документов можно приступать к непосредственному проектированию объекта.