Тз на модернизацию. Техническое задание тз на модернизацию вентиляции в нии
Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.
В этом гайде я расскажу, что и зачем нужно писать в техзадании. Заодно покажу, как писать не надо, чтобы создание ТЗ не обернулось потраченным впустую временем.
Статья будет полезна:
- Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
- Менеджерам проектов.
- Руководителям диджитал-студий.
- Предпринимателям, которые планируют заказать разработку сайта.
Чтобы материал получился дельный, я собрал комментарии нескольких разработчиков, дизайнеров, проект-менеджеров и владельцев диджитал-студий. Самые ценные добавил в конец статьи. Поехали разбираться.
Что такое техзадание и зачем оно нужно
Техническое задание - это документ, в котором зафиксированы требования к сайту. Чем четче и подробнее расписаны эти требования, тем лучше все участники процесса понимают, каким он должен быть. А значит, растет шанс того, что все останутся довольны результатом.
Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.
Пользы от технического задания много. Для каждой стороны она своя.
Польза для клиента:
- Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
- Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
- Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
- Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
- Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.
Польза для исполнителя:
- Понять, что хочет заказчик. Клиенту задают десятки вопросов, показывают примеры, предлагают решения. Затем записывают все в единый документ и согласовывают. Если все окей - ура, вы поняли правильно.
- Застраховаться от внезапных хотелок клиента. Иногда попадаются заказчики, которые хотят поменять задачу на полпути. Если вы согласовали и подписали ТЗ, вам не страшно подобное. В случае чего, даже суд будет на вашей стороне.
- Показать свою компетентность. Классно подготовленное техзадание покажет клиенту экспертность разработчиков. Если компания сомневалась, доверять ли вам разработку сайта, сомнения с большой вероятностью развеются.
- Заработать деньги. Некоторые студии и разработчики предлагают составление ТЗ как отдельную услугу.
- Облегчить и ускорить процесс разработки . В хорошем ТЗ указаны структура сайта, необходимые функции и элементы на каждой странице. Когда все требования уже перед глазами - остается только задизайнить и написать код.
Теперь давайте разберемся, как составить хорошее техзадание, которое выполняет все эти функции.
Техзадание составляет исполнитель
Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» - это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.
Хорошее ТЗ всегда составляет исполнитель: проект-менеджер или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец кафе или стоматологической клиники. Поэтому описывать проект придется ему.
Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:
Конечно, заказчик может набросать свой вариант ТЗ. Возможно, это ускорит процесс создания конечного техзадания. А возможно, получится мусор, который втихаря выкинут на помойку.
Пишите однозначно и точно
Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».
В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять. У каждого свои понятия красоты и современности.
Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:
То же самое - с невнятными формулировками, которые ничего сами по себе не значат:
- Сайт должен понравиться заказчику. А если у него будет плохое настроение?
- Сайт должен быть удобным. Что это значит? Удобным для чего?
- Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
- Качественный экспертный контент. Ну, вы поняли.
Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите. Ваши формулировки должны быть четкими и точными:
- Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
- Большие нагрузки → 50 тысяч посетителей одновременно.
- На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
- Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.
С формулировками разобрались, давайте пробежимся по структуре.
Укажите общую информацию
Все члены команды должны правильно понимать, чем занимается компания и кто ее целевая аудитория. Чтобы никто не запутался, это лучше прописать в самом начале техзадания.
А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.
Поясните сложные термины
Первое правило техзадания - оно должно быть понятно всем, для кого предназначено. Если вы собираетесь использовать термины, которые может не понять ваша клиентка - владелица магазина детских игрушек - обязательно поясните их. Понятным языком, а не копипастой из «Википедии».
Опишите инструменты и требования к хостингу
Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»
Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.
Перечислите требования к работе сайта
Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать, чтобы защитить клиента от недобросовестно выполненной работы.
Сюда же напишите требования к скорости загрузки сайта , устойчивости к нагрузкам, защите от хакерских атак и подобным вещам.
Укажите структуру сайта
До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.
Пообщайтесь с заказчиком, выясните, что ему надо. Соберите разработчиков, сеошников, маркетологов, главреда - и решите, какие страницы нужны на сайте. Подумайте, как они будут связаны между собой, с какой на какую можно перейти.
Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.
Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.
Объясните, что будет на каждой странице
Клиент должен понять, зачем нужна каждая страница и какие элементы на ней будут. Есть два способа это показать.
Прототип - более наглядный и однозначный способ. Исполнитель рисует эскизы каждой страницы и прилагает их к техзаданию. Клиент видит, как будет выглядеть интерфейс его будущего сайта и говорит, что ему нравится, а что стоит изменить.
Перечисление элементов - ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице, и что они делают.
Распишите сценарии использования сайта
Если вы делаете какой-то нестандартный интерфейс, просто показать структуру и эскизы страниц недостаточно. Важно, чтобы вся команда исполнителей и клиент поняли, как посетители будут пользоваться сайтом. Для этого отлично подходят сценарии. Схема сценария очень простая:
- Действие пользователя.
- Ответное действие сайта.
- Результат.
Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы - очень желательно.
Подробнее о сценариях использования читайте в «Википедии ».
Определите, кто отвечает за контент
Одни разработчики делают сайт сразу с контентом. Другие ставят рыбу. Третьи могут написать тексты, но за дополнительную плату. Договоритесь об этом на берегу и зафиксируйте в техзадании, какой контент вы должны подготовить.
Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.
Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.
Опишите дизайн (если сможете)
Как и в с случае с текстом, объективные критерии оценки дизайна сайта придумать сложно. Если вы с клиентом договорились о цветовой гамме - напишите ее. Если у него есть брендбук, в котором прописаны шрифты, - укажите и их.
Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.
Вместо вывода: структура техзадания
Для разных задач структура ТЗ будет своя. Глупо делать одинаковые технические задания для новой социальной сети и лендинга по оптовой продаже моркови. Но в целом вам нужны такие разделы:
- Информация о компании и целевой аудитории, цели и задачи сайта.
- Глоссарий терминов, которые могут быть непонятны клиенту.
- Технические требования к верстке и работе сайта.
- Описание используемых технологий и список требований к хостингу.
- Подробная структура сайта.
- Прототипы страниц или описания элементов, которые должны на них быть.
- Сценарии использования нестандартного интерфейса (опционально).
- Список контента, который делает разработчик.
- Требования к дизайну (опционально).
- Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
- Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.
Это конец той части, которую писал я. Но есть и другая - комментарии специалистов, которые помогали делать гайд. Почитайте, это тоже интересно.
Комментарии разработчиков
Я пообщался с несколькими разработчиками, чтобы узнать, как они составляют техзадания. Передаю микрофон им.
В первую очередь ТЗ нужно клиенту - чтобы он понял, каким будет его сайт, и на что уходят деньги. Если что-то сделано не так - он может сослаться на ТЗ и попросить переделать.
ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.
Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.
Мы указываем:
- Информацию о компании и цель сайта.
- Требования к дизайну, цветовую гамму.
- Используемые технологии и CMS.
- Кто занимается контентом - мы или клиент.
- Структуру сайта вплоть до каждой страницы.
- Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.
Последние 2 раздела - самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.
Очень важный момент - нельзя просто отдать техзадание разработчикам и надеяться, что они все сделают хорошо. ТЗ - это список требований к сайту, оно не может заменить общение. Важно убедиться, что каждый член команды понимает общую цель, а не просто выполняет задачи на потоке. Если что-то непонятно - надо объяснить, обсудить, дать подробные комментарии.
Наши специалисты помогли заказчику составить ТЗ техническое задание на модернизацию системы вентиляции .
Подробнее под катом..
Техническое задание
на модернизацию технологического оборудования вентиляционных систем корпуса лабораторий №451,452 корпуса 17 по адресу: г. Москва
1. Общие положения
1.1. Настоящее техническое задание предусматривает выполнение работ по модернизации технологического оборудования, систем управления и автоматики вентиляционных установок корпуса, лабораторий №451,452 корпуса 17.
1.2. Для выполнения работ разработать рабочую документацию разделов марок АОВ, ЭМ, ХС, АХС, АК, которую согласовать установленным порядком.
1.3. Работы выполнять с соблюдением требований нормативно-технической документации.
1.4. По окончании работ предъявить исполнительную документацию, выполненную в соответствии с требованиями ГОСТ и СНиП.
1.5. Сдать выполненную работу Заказчику.
1.6. Отдельные положения настоящего Технического Задания могут уточняться в процессе проведения работ по согласованию с Заказчиком.
2. Технические требования
2.1. Модернизация узлов регулирования тепло, холодоснабжения вентиляционных установок.
2.1.1. Узлы регулирования теплоснабжения.
Модернизации подлежат:
· узлы регулирования теплоснабжения первого подогрева вентиляционных установок К1, К2, К2а, К4 корпуса МИК-В, П2, П6 лаборатории №452, П1 лаборатории.
· узлы регулирования теплоснабжения второго подогрева вентиляционных установок К1, К2, К2а корпуса МИК-В.
Существующие узлы регулирования теплоснабжения подлежат демонтажу, при этом, часть оборудования узлов регулирования (циркуляционные насосы, запорная арматура), соответствующие по состоянию и техническим характеристикам, подлежит использованию в монтируемых узлах регулирования.
Состав оборудования монтируемых узлов регулирования, а также.используемое оборудование указано в приложении №1.
Провести гидравлические испытания контуров подогрева и калориферов вентиляционных установок с оформлением акта гидравлических испытаний.
Выполнить покраску трубопроводов и теплоизоляционные работы.
2.1.2.Узлы регулирования холодоснабжения вентиляционных установок.
Модернизации подлежат узлы холодоснабжения вентиляционных установок К1, К2, К2а, К4 корпуса МИК-В, П2, П6 лаборатории «452, П1 лаборатории №451.
Состав работ:
· замена терморегулирующих вентилей узлов регулирования холодоснабжения;
· демонтаж/монтаж вентилятора компрессорно-конденсаторного блока К1;
· демонтаж/монтаж фильтров-осушителей компрессорно-конденсаторных блоков К1, К2;
· демонтаж/монтаж испарителя вентиляционной установки К4;
· опрессовка в среде инертных газов, ваккумирование, заправка фреоном контуров холодоснабжения;
· восстановление теплоизоляции трубопроводов.
2.1.3. Узлы подпитки контуров увлажнения.
На узлах подпитки камер орошения кондиционеров К1, К2, К2а установить фильтры очистки холодной воды.
2.2. Шкафы управления и автоматики вентиляционных установок.
Подлежат демонтажу шкафы управления вентиляционными установками К1, К2, К2а, К4, РУ3, В1, В2, В3, В6, В7, В8 корпуса МИК-В, П2, П6, В1, В2, В3 лаборатории №451, П1, В1 лаборатории № 452.
Компоновка вновь устанавливаемых щитов управления:
ШУА К1 – шкаф управления и автоматики вентиляционной установкой и компрессорно-конденсаторным блоком (ККБ) кондиционера К1 (МИК-В);
ШУА К2 – шкаф управления и автоматики вентиляционной установкой и ККБ кондиционера К2 (МИК-В);
ШУА К2 – шкаф управления и автоматики вентиляционной установкой и ККБ кондиционера К2а (МИК-В);
ШУА К4 – шкаф управления и автоматики вентиляционной установкой и ККБ кондиционера К4 (МИК-В);
ШУВ– шкаф управления вытяжными установками РУ3, В1, В2, В3, В6, В7, В8 (МИК-В);
ШУА П2,П6 – шкаф управления и автоматики вентиляционными установками и компрессорно-конденсаторными блоками П2, П6 (лаборатория №452);
ШУВ– шкаф управления вытяжными установками В1, В2, В3 (лаборатория №452);
ШУА П1,В1 – шкаф управления и автоматики вентиляционными установками П1, В1 (лаборатория №451).
Модернизированные шкафы управления должны обеспечивать:
· выбор, с лицевой панели шкафа, режима управления вентиляционными установками (ручной/автоматический);
· световую сигнализацию штатных и аварийных режимов работы технологического оборудования вентиляционных установок (работа/авария);
· отключения вентиляционных установок при возникновении пожара;
· автоматическое срабатывание защит и блокировку работы оборудования при возникновении аварийных ситуаций.
Преобразователи частоты для управления электродвигателями вентиляторов и насосов подлежат дальнейшему использованию.
2.3. Система автоматизации и диспетчеризации
Система автоматизации и диспетчеризации предназначена для управления и контроля работы вентиляционных установок, а также для сбора, обработки, представления и хранения поступающей информации.
2.3.1. Система автоматики.
Система автоматики должна обеспечивать, в основном, автономное функционирование вентиляционных установок, не требующее вмешательства обслуживающего персонала и переход, при необходимости, на ручной режим управления. При любых вариантах управления и независимо от состояния локального контроллера, должно сохраняться условие автоматического отключения системы общеобменной вентиляции при пожаре. Отключение следует производить индивидуально для каждой системы с сохранением электропитания цепей защиты от замораживания.
Локальная автоматика вентиляционных систем должна предусматривать:
· регулирование температуры приточного воздуха на выходе вентиляционной установки или, при необходимости, температуры вытяжного воздуха из обслуживаемого помещения;
· регулирование влажности приточного воздуха;
· остановку вентиляторов и закрытие воздушных клапанов при срабатывании пожарной сигнализации;
· отключение увлажнения воздуха кондиционера при остановке его вентилятора;
· открытие и закрытие воздушного клапана соответственно при пуске и остановке вентилятора;
· автоматический прогрев калориферов перед запуском систем в зимнем режиме;
· защита от замораживания калориферов по воздуху и по воде (отключение вентилятора, закрытие воздушной заслонки, открытие на 100% клапана подогрева);
· отключение вентилятора при отсутствии перепада давления;
· контроль загрязненности фильтров установок.
Дистанционное воздействие на локальную автоматику с АРМ определяется в следующем объеме:
· изменение уставок регуляторов температуры и влажности;
· включение/отключение установок.
Существующее периферийное оборудование системы автоматики подлежит поверке, очистке и дальнейшему использованию в следующем порядке:
· датчики температуры и влажности вентиляционных установок подлежат поверке;
· датчики реле перепада давления подлежат проверке, очистке;
· термостаты защиты калориферов вентиляционных установок от замораживания подлежат замене.
· приводы регулирующих клапанов узлов регулирования подлежат замене в соответствие с п.2.1.1.
· приводы воздушных клапанов подлежат проверке и дальнейшему использованию;
Для управления рециркуляцией кондиционера К1 заменить двухпозиционные приводы воздушных клапанов на клапана с управляющим сигналом 0..10В.
2.3.2. Система диспетчеризации.
В состав системы диспетчеризации включить следующие компоненты:
· комплекс измерительных устройств, исполнительных механизмов и средств автоматизации на базе программно-технических средств «Honeywell »;
· многофункциональная кабельная система;
· комплекс программно-технических средств диспетчерского пункта.
Для диспетчеризации вентиляционных систем предусмотреть отображение, архивирование и протоколирование следующей информации:
· графическое изображение установок с датчиками температуры и влажности, термостатами от замораживания, реле дифференциального давления, регулирующими клапанами, увлажнителями воздуха, воздушными клапанами;
· номера установок;
· показания датчиков температуры, влажности;
· показания датчиков реле дифференциального давления;
· показания положения регулирующих клапанов 0..100%;
· режим «работа/останов» вентиляторов;
· режим «работа/ останов» насосов;
· положение воздушных клапанов «открыт/закрыт»;
· остановка систем при срабатывании пожарной сигнализации;
· остановка систем при возникновении угрозы замораживания калорифера;
· остановка установки при отсутствии перепада давления на вентиляторе;
· отключение увлажнителя воздуха при остановке вентилятора кондиционера;
· работа систем по заданному временному графику или без него;
· сигнализация аварий и нештатных ситуаций в случае возникновения неисправности оборудования, а также - выхода значений технологических параметров за пределы заданных диапазонов;
· регистрация аварий и нештатных ситуаций в журнале сообщений;
· журнал регистрации параметров на текущее время с указанием наименования контролируемых параметров, единиц измерения, номера контроллера и канала ввода/вывода.
2.3.3. Электропитание системы автоматизации и диспетчеризации должно осуществляться от сети переменного тока напряжением 380/220 В, частотой 50 Гц с использованием источников бесперебойного питания на аккумуляторных батареях и обеспечиваться как питание электроприемников первой категории
Многие сталкиваются с тем, что достаточно сложно объяснить коротко и ясно то, что мы хотим в повседневной жизни. А уж когда надо дать задание специалисту написать программу для организации или ИП с учетом особенностей и собственных пожеланий по функционалу, то можно вообще «зависнуть».
Кто должен писать ТЗ?
Безусловно техзадание должен предоставить заказчик, т. к. он уж точно знает свои потребности и возможности. Но, как показывает практика, подавляющее большинство клиентов не компетентны в области 1С. Вот почему зачастую сам исполнитель вынужден вникнуть в потребности заказчика, понять какой конечный продукт ему нужен, и соответственно оформить все это в письменной форме для программиста.
Для чего необходимо техзадание?
При идеальном раскладе при той или иной доработке в программном продукте 1С необходимо техническое задание. Должны быть прописаны в первую очередь: задачи, сроки и способ исполнения.
Это важный документ, потому как при возникновении каких-либо спорных вопросов грамотная разработка техзадания станет отправной точкой в переговорах.
Составлять ТЗ или нет - решает каждый для себя, но это точно не будет лишним: упростит общение с клиентом и придаст работе деловой и конкретный характер.
Обозначим перечень наиболее важных пунктов, которые должны быть в техническом задании:
1. Цель/Задача. Сформулировать то, что должно быть реализовано в конечном итоге.
2. Описание. Вкратце изложить содержание планируемых доработок.
3. Способ реализации. Детально описать методы, с помощью которых должна быть достигнута цель. Следует прописать все особенности задачи на языке программиста: регистры, справочники (создать их или отредактировать); дизайн интерфейса и т.д. Для тех, кто не знаком и лишь что-то такое слышал про специфический язык программиста, советуем не делать ненужных попыток «заговорить» на техническом языке. Т.к. описание в идеале - это сухая констатация, исключающая неоднозначность и возможность возникновения лишних вопросов. Кроме этого этот пункт может включать в себя пример, как подобное программирование было уже исполнено где-то.
4. Оценка работы. Данный пункт очень важен - в нем нужно описать трудозатраты.
Еще два важных момента: есть утвержденные стандарты к написанию ТЗ - ГОСТы. Сейчас они редко используются, но некоторые клиенты могут по старинке просить использовать и их.
И второе, когда сдается работа может возникнуть и такое - «а мы же вроде как просили Вас сделать то-то и тогда-то...». Есть вероятность, что придется все начать делать с самого начала.
Поэтому, повторимся, что грамотно составленное ТЗ будет полезно как для заказчика, так и для исполнителя.
Пример ТЗ для программиста
Техническое задание 1С на доработку внешней обработки
Цель
Необходимо настроить выгрузку данных из 1С в АРМ банка.
Описание
В связи с переходом организации на конфигурацию 1С «Зарплата и кадры государственного учреждения» требуется разработка других обработок, которые осуществляли бы аналогичный функционал на новой конфигурации.
Выгрузка данных должна основываться на документах «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и «ВедомостьНаВыплатуЗарплатыВБанк».
Исходные данные
Имеющаяся обработка к конфигурации 1С «Зарплата бюджетного учреждения», осуществляющая выгрузку данных из документа «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и других справочников и регистров в файл DBF обмена данными с АРМ банка установленного образца.
Обработка выгружает данные в поля TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN соответствующую информацию из конфигурации 1С, предварительно занесённую в указанный документ и другие учётные таблицы. Выгружаются табельный номер, ФИО сотрудника, его паспортные и адресные данные, день рождения и гражданство.
Способ реализации
Это будут внешние отчёты и обработки с использованием механизма расширений, если текущие параметры совместимости базы и возможности платформы позволят это сделать. При изменении конфигурации базы следует создать: справочники, документы, регистры.
Оценка работы
Потребуется 5 рабочих дней работы программиста.
В жизни очень часто бывает так, что человек не может объяснить, что хочет, даже в бытовых вещах. Когда дело доходит до объяснения программисту своих «хотелок», человек просто впадает в ступор.
В идеале ТЗ должен составлять заказчик — только он знает, что ему нужно. Но на практике из-за низкой компетенции заказчика в сфере 1С часто это приходится делать исполнителю. Заказчик устно озвучивает свои потребности, а программист(консультант) оформляет это в письменной форме.
Зачем нужно техническое задание?
Любые , в идеале, должны сопровождаться техническим заданием. Это, во-первых, четкое определение задачи, сроков и метода выполнения. Во-вторых, это документ, с помощью которого решаются все спорные моменты в будущем. Писать ТЗ или нет — дело, конечно, Ваше, лично мне ТЗ облегчает работу и общение с клиентом.
Получите 267 видеоуроков по 1С бесплатно:
Что должно содержать в себе техническое задание?
Тех. задание обязательно должно содержать в себе:
- цель — задача, которую мы решим, реализуя данное ТЗ;
- описание — краткое изложение предстоящих доработок;
- способ реализации — подробное описание методов решения цели. В этом пункте необходимо описать все нюансы задачи на языке программиста: какие , создаем/редактируем, как должен выглядеть интерфейс и т.д. Если Вы не владеете «языком программиста», но «что-то слышали», лучше не пытаться писать на техническом языке — получается достаточно весело. Описание должно быть однозначным и не вызывать вопросов. Также может содержать в себе пример реализации подобного решения в другой сфере;
- оценка работы — очень важный пункт, описание трудозатрат.
Также существуют государственные стандарты к написанию ТЗ — ГОСТы. На практике мало где применяются, но бывает, заказчик настаивает на этом.
По опыту, при сдаче работ очень часто возникают ситуации вроде «а мы Вам тогда-то говорили же…», что не очень приятно, и зачастую приходится переделывать работу целиком. Поэтому хорошо написанное ТЗ сильно облегчает жизнь обеих сторон.
Примеры и образцы ТЗ для 1С
Небольшая подборка, которую я нашел в свободном доступе в сети. Начиная от самых простых и доступных, заканчивая достаточно сложными документами.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
НА МОДЕРНИЗАЦИЮ САЙТА
Екатеринбург
1. Основания для разработки Сайта. 3
1.1. Полное и краткое наименования информационной Системы.. 3
1.2. Наименование заказчика системы и его реквизиты.. 3
1.3. Перечень документов, на основе которых создается Система. 3
1.4. Плановые сроки начала и окончания работ по созданию Системы.. 3
2. Требования к системе. 4
2.1. Модернизация официального интернет-сайта Следственного комитета при прокуратуре Российской Федерации (далее – Сайт СКП). 4
2.2. Главная страница. 5
2.3. Типовая внутренняя страница. 8
2.4. Требования к модулю размещения новостных сообщений. 9
2.5. Требования к модулю формирования и отображения списка документов. 11
2.6. Требования к модулю отображения списков (каталог) 11
2.7. Блог. 13
2.8. Фотогалерея. 16
2.9. Видеоплеер. 16
2.10. Метки. 16
2.11. Требования к модулю сбора и аналитики данных о статистике посещений интернет-сайта 16
2.12. Требования к модулю поиска. 17
2.13. Требования к модулю «Официальные лица». 18
2.14. Требования к модулю «Карта сайта». 20
2.15. Требования к модулю «Сбор обращений пользователей». 20
2.16. Требования к управлению ресурсом.. 21
2.17. Требования к техническому обеспечению.. 22
2.18. Требования к унификации и стандартизации . 22
2.19. Разработка эксплуатационной документации. 22
2.20. Организация и проведение обучения специалистов Следственного комитета при прокуратуре Российской Федерации. 23
3. Кольцо сайтов. 24
3.1. Общие требования. 24
3.2. Текстовая страница. 25
3.3. Новости. 26
3.4. Вопросы и ответы.. 28
3.5. Архив файлов. 29
3.6. Форма сбора обращений. 30
3.7. Карта сайта. 30
3.8. Требования к механизму создания и удаления сайтов. 31
3.10. Требования к дизайну. 31
3.11. Требования к языковой поддержке. 31
3.12. Развитие единой программной платформы сайта СКП.. 31
3.13. Требования к результатам проведенных работ. 32
1. Основания для разработки Сайта
1.1. Полное и краткое наименования информационной Системы
Полное наименование системы – официальный интернет-сайт Следственного комитета при прокуратуре Российской Федерации.
Краткое наименование системы – «Сайт СКП», «Система», «Сайт».
1.2. Наименование заказчика системы и его реквизиты
Наименование: Следственный комитет при прокуратуре Российской Федерации
Место нахождения: г. Москва, Технический переулок, дом 2
Фактический адрес: А
Контактное лицо Заказчика:
Телефон: (4, (4;
Адрес электронной почты
1.3. Перечень документов, на основе которых создается Система
Государственный контракт №________________ от ___ ___________ 2010 г.
1.4. Плановые сроки начала и окончания работ по созданию Системы
Определяются в соответствии с Договором.
2. Требования к системе
2.1. Модернизация официального интернет-сайта Следственного комитета при прокуратуре Российской Федерации (далее – Сайт СКП)
В рамках модернизации необходимо осуществить:
· Редизайн главной страницы Сайта СКП, в том числе должна быть осуществлена перегруппировка существующих блоков на Главной странице;
· Создание отдельного блока на Главной странице «высказывания представителей власти и СМИ, о работе Следственного комитета». Раздел должен быть реализован в виде датированного списка с возможностью прикрепления картинок;
· Настройку шрифтов предлагаемых Системой по умолчанию для различных типов текста: для заголовков и основного текста;
· Реализацию возможности замены графических элементов соответствующим текстом (в случае отключенной возможности на стороне пользователя загрузки картинок);
· Оптимизация страниц Сайта СКП по объему данных;
· Адаптацию Сайта СКП к новому дизайну;
· Оптимизацию безопасности кода с целью предотвращения возможных внешних атак;
· Актуализацию главного меню, включая следующие изменения:
Создать раздел «О Следственном комитете»;
Данный раздел должен представлять собой отдельную страницу Сайта СКП, с возможностью размещения форматированного текста и картинок.
Создать раздел «Блог Председателя»;
В разделах с большим объемом текста («Интервью», «Публикации» и «Нормативная база») упорядочить информацию по годам.
Структура сайта центрального аппарата
· Главная
· О комитете (текстовая страница)
· Руководство (модуль «Каталог»)
Ø Список руководителей (подраздел каталога)
o Описание должностного лица (текстовая страница)
· Структура (текстовая страница)
· Нормативная база (текстовая страница)
· Новости (модуль «Новости»)
Ø Список новостей (подраздел)
o Описание новости (текстовая страница)
· Правовая информация (текстовая страница)
· Служба в системе (текстовая страница)
· Противодействие коррупции (модуль «Каталог»)
Ø Мероприятия и документы
o Список мероприятий (подраздел)
§ Описание мероприятия (текстовая страница)
Ø Расследование преступлений коррупционной направленности
o Список событий (подраздел)
§ Описание события (текстовая страница)
· Блог (модуль «Блог»)
· Версия для слабовидящих (модуль «Версия для слабовидящих»)
· Порядок рассмотрения обращений и приема граждан (текстовая страница)
· Следственные органы по субъектам РФ (текстовая страница)
· Печатные издания (модуль «Каталог»)
Ø Вестник СКП № 4 (подраздел)
Ø Вестник СКП № 3 (подраздел)
o Описание номера (текстовая страница)
· СМИ о Следственном Комитете (модуль «Новости»)
Ø Список публикаций (подраздел)
o Описание публикации (текстовая страница)
· Взаимодействие со СМИ (модуль «Каталог»)
Ø Список подразделов (подраздел каталога)
o Описание подраздела (текстовая страница)
· Интервью (модуль «Новости»)
Ø Список интервью (подраздел)
o Описание интервью (текстовая страница)
· Карта сайта (модуль «Карта сайта»)
2.2. Главная страница
Помимо идентификационных элементов и элементов дизайна главная страница сайта должна содержать следующие элементы:
· Главное меню
Главное меню сайта - постоянный элемент каждой страницы сайта. Меню должно иметь следующие ссылки:
ü О комитете
ü Руководство
ü Структура
ü Нормативная база
ü Новости
ü Правовая информация
ü Служба в системе
ü Противодействие коррупции
Сетка главной страницы представлена на рис. 1.
Актуально" в системе администрирования, то есть, если этот флаг взведен, то новость поместится в блок "Актуально" и находится там, пока этот флаг не снимут.
· Блок «Высказывания представителей власти и СМИ» - должен представлять собой датированный список с ФИО представителя власти или СМИ, его должности, изображением и цитатой.
· Баннер - должен представлять собой флэш - или фотоизображение, при нажатии ведущее на сайт или раздел, указанный в системе управления сайтом.
· Блок «Следственные органы по субъектам РФ» - должен представлять собой флэш-изображение карты России с разделением по федеральным округам. При нажатии на тот или иной округ должно переходить на страницу с текстовым описанием данного округа.
· Блок «Блог Председателя» - должен представлять собой список из трех последних тем, созданных в блоге в виде названия темы и даты ее публикации. Название темы будет являться ссылкой, при нажатии которой должно перевести на страницу блога с описанием данной темы. Также в данном блоке должно размещаться видео, которое можно воспроизвести, не покидая главную страницу. У видео должна быть ссылка «Комментарии», представляющая собой количество комментариев к данному видеоизображению. Ссылка «Комментарии» должна вести на страницу блога с комментариями к представленному видео.
- Нижний колонтитул
Нижний колонтитул должен содержать поле для поиска, информацию об авторских правах и т. д.
2.3. Типовая внутренняя страница
Сетка типовой внутренней страницы представлена на рис. 2
Рис. 2. Типовая внутренняя страница.
Назначение:
Типовая внутренняя страница должна представлять собой текстовый документ с заголовком и описанием чего-либо. Должна содержать в себе фото - и видеоизображения, а также вложенные файлы для скачивания.
2.4. Требования к модулю размещения новостных сообщений
Модуль размещения сообщений должен обеспечить:
· размещение новостных сообщений на интернет-сайтах, публикуемых в хронологическом порядке (новостных лент);
· вывод на страницах интернет-сайтов список новостей и их полные тексты;
· поиск по архиву новостей;
· экспорт новостей в формат RSS 2.0.
Для работы с элементами новостной ленты должен быть предусмотрен HTML-редактор, позволяющий осуществлять добавление и редактирование новостных сообщений пользователями, не обладающими знаниями специализированных программных языков.
Модуль должен представлять собой двухуровневую архитектуру, представленную в виде списка всех новостей и описание каждой новости.
Список новостей должен быть представлен в виде названия новости и даты ее публикации (рис. 3)
https://pandia.ru/text/78/390/images/image005_109.jpg" width="646" height="525 src=">
Рис. 4. Сетка страницы «описание новости».
2.5. Требования к модулю формирования и отображения списка документов
Модуль формирования и отображения списка документов должен позволять:
· организовывать публикацию документов на страницах сайта в виде списка с возможностью постраничного разбиения и сортировкой по дате публикации;
· администратору и контент-менеджеру интернет-сайтов выполнять следующее:
o просматривать список документов,
o добавлять новые документы,
o редактировать и удалять добавленные документы.
2.6. Требования к модулю отображения списков (каталог)
Модуль отображения списков должен обеспечить:
· отображение на страницах интернет-сайтов форматированных списков (список вакансий , список филиалов, список часто задаваемых вопросов и ответов на них и т. д.) в виде перечня ссылок на страницы элементов списка;
· предоставление администраторам и контент-менеджерам интернет-сайтов следующих функциональных возможностей:
o редактировать, добавлять и удалять элементы списка;
o создавать новые списки элементов;
o удалять существующие списки.
Модуль должен представлять собой многоуровневую архитектуру с разветвленной структурой. Главный раздел каталога должен иметь в себе подразделы, представленные в виде списка тем (рис. 5)
Рис. 5. Сетка подраздела каталога.
При нажатии на название одного из подразделов, должно открываться описание этого подраздела в виде внутренней типовой страницы .
Сетка «описание подраздела» представлена на рис. 6
https://pandia.ru/text/78/390/images/image008_83.jpg" width="625" height="526">
Рис. 7. Сетка страницы «список тем в блоге».
При нажатии на одну из тем должна открываться страница с полным описанием темы и комментариями к ней (рис. 8)
2.8. Фотогалерея
С помощью данного модуля на страницах сайта должны размещаться изображения, должен генерироваться список изображений, при клике на изображении должно происходить увеличение изображения.
2.9. Видеоплеер
С помощью данного модуля на страницах сайта должны размещаться видеоизображения, при клике на видеоизображении должен происходить показ видео.
2.10. Метки
Механизм меток должен быть предназначен для связывания всех новостей, интервью и других материалов сайта через метки. То есть у различных материалов сайта должна быть возможность принадлежать к одному общему элементу.
2.11. Требования к модулю сбора и аналитики данных о статистике посещений интернет-сайта
Модуль сбора и аналитики данных о статистике посещений интернет-сайта должен обеспечивать сбор и отображение администраторам интернет-сайтов информации о посещениях интернет-сайтов пользователями и динамике изменения посещаемости. Должны быть реализованы следующие функциональные возможности модуля:
· ведение учета статистики в режиме онлайн и работу с данными непосредственно на сайте;
· проведение сбора и обсчета статистических данных при открытии посетителем каждой страницы без размещения кнопок, имиджей или дополнительного программного кода в теле страницы;
· выделение потоков посетителей по одному из критериев:
o список ссылающихся сайтов;
o поисковая система;
o страницы, на которые пришли;
o дополнительные параметры: страна, пользователь, IP-сеть и другие.
· анализ путей по сайту с возможностью выбора периода для анализа, количества страниц в пути, первой страницы пути, последней страницы пути, любой страницы пути и других параметров выборки данных с расширенным фильтром;
· анализ посещаемости разделов и страниц с возможностью выбора периода для анализа, раздела и других параметров выборки данных с расширенным фильтром;
· анализ точек входа на сайт с возможностью выбора периода для анализа, раздела и других параметров выборки данных с расширенным фильтром;
· анализ посещаемости сайта на общем графике по дням с представлением данных: хиты, сессии, посетители, хосты, новые посетители, события, избранное;
· анализ сводной статистики сайта, представляющей данные за прошедшие периоды следующих типов:
o события;
o посетители (новых, всего, добавивших в избранное, онлайн);
o Топ 10 наиболее активных типов событий на сайте;
o Топ 10 ссылающихся сайтов;
o Топ 10 наиболее популярных сегодня поисковых фраз;
o Топ 10 наиболее активных поисковых роботов за день.
· анализ ссылающихся сайтов; возможность анализа динамики по дням; учет встроенного модуля поиска как поисковой машины со всеми инструментами анализа;
· автоматическое определение запросов поисковых систем и роботов для пополнения таблицы поисковых машин;
· анализ динамики событий по дням и представление результатов в виде круговой диаграммы;
· анализ динамики событий по дням и представление в виде графика типов событий.
2.12. Требования к модулю поиска
Модуль поиска должен обеспечивать поиск страниц интернет-сайтов, содержащих заданные пользователем ключевые слова. Должно быть реализовано выполнение следующих функций:
· выполнение поиска как на выбранном интернет-сайте, так и по кольцу сайтов с учетом русской морфологии ;
· выполнение поиска одновременно в статическом наполнении сайта и динамической информации (новости, статьи, фотографии)
· использование языка запросов при формировании поискового запроса;
· использование логических операторов для сложных поисковых запросов;
· автоматическая индексация всех документов сайтов, которые публикуются через веб-интерфейс в виде статических HTML-страниц или через модули информационных блоков;
· сортировка результатов поиска.
2.13. Требования к модулю «Официальные лица»
Модуль «официальные лица» должен обеспечивать:
· ведение справочника официальных лиц следственных органов по субъектам Российской Федерации (уровень руководителя и заместителей руководителя территориального органа Следственного комитета при прокуратуре Российской Федерации).
· хранение информации о руководстве следственных органов по субъектам Российской Федерации в составе:
o должность,
o фотография,
o биография,
o датированный список (лента) публикаций и выступлений.
Модуль должен представлять собой иерархическую структуру подчиненности должностных лиц (рис. 9)
https://pandia.ru/text/78/390/images/image011_72.jpg" width="646" height="614 src=">
Рис. 10. Сетка страницы «описание должностного лица».
2.14. Требования к модулю «Карта сайта»
2.15. Требования к модулю «Сбор обращений пользователей»
Модуль должен обеспечивать функциональные возможности по сбору обращений граждан Российской Федерации с помощью специализированной формы, размещаемой на интернет-сайтах следственных органов:
· отправка результатов заполнения формы на e-mail ответственному сотруднику;
· сохранение данных формы в базе данных ;
· обеспечение защиты от автоматического заполнения формы путем ввода контрольного графического кода.
Сетка страницы с формой обращения пользователей представлена на рис. 11
Рис. 11. Сетка страницы «форма обращения».
Страница должна представлять собой форму, с расположенными на ней полями для заполнения «ФИО», «E-mail», «№ телефона», «Адрес» и «Текст сообщения». При заполнении этих полей, защитного кода и нажатии кнопки отправить информация должна отправляться в базу данных, а на E-mail сотрудника, ответственного за прием заявок, должно отправляться соответствующее письмо. Затем на экране в этом же окне пользователю должен представляться номер заявки, которую он отправил.
2.16. Требования к управлению ресурсом
Для управления информационным наполнением интернет-сайтов кольца сайтов, разделами, меню и правами доступа должна использоваться единая система управления контентом (CMS) за счет развития существующей платформы, разработанной в рамках создания официального интернет-сайта Следственного комитета при прокуратуре Российской Федерации, обеспечивающая следующие возможности:
· Единый интерфейс администрирования и управления наполнением интернет-сайтов;
· Редактирование информационного наполнения разделов и страниц выбранного интернет-сайта с помощью графического редактора;
· Управление разделами меню выбранного интернет-сайта;
· Управление структурой выбранного интернет-сайта;
· Ведение интерактивной карты разделов интернет-сайтов;
· Размещение новостных сообщений имеющих четкую привязку по времени;
· Ведение архива новостных сообщений, с возможностью поиска по дате публикации всех интернет-сайтов;
· Поиск информации по интернет-сайтам;
· Публикация документов на интернет-сайтах;
· Помещение для обучения предоставляется Заказчиком.
· Место и время обучения должно быть согласовано с Заказчиком.
Обучение должно проводиться по всей функциональности Системы.
В рамках обучения необходимо осуществить информационное наполнение одного пилотного сайта Кольца сайтов Следственного комитета при прокуратуре Российской Федерации.
3. Кольцо сайтов
Все функциональные возможности системы должны быть реализованы в рамках отдельных программных модулей за счет развития существующей платформы Сайта СКП. Совместное функционирование различных модулей Интернет-сайтов должно обеспечиваться ядром программного компонента «Кольцо сайтов». Модули, обеспечивающие заданные функциональные возможности, должны подключаться отдельно для каждого из интернет-сайтов, входящих в кольцо сайтов. Все программные модули, реализующие сервисы интернет-сайтов, должны использовать общие принципы функционирования вне зависимости от сайта, входящего в кольцо сайтов.
В качестве ядра программного компонента «Кольцо сайтов» должны использоваться программные компоненты интернет-сайта Следственного комитета при прокуратуре Российской Федерации
3.1. Общие требования
Создаваемая система должна отвечать следующим требованиям:
· Кольцо сайтов должно обеспечивать одновременное бесперебойное функционирование интернет-сайтов следственных органов Следственного комитета при прокуратуре Российской Федерации по субъектам Российской Федерации;
· Кольцо сайтов должно быть построено по клиент-серверной схеме взаимодействия с тонким клиентом. Веб-страницы, хранящиеся и генерируемые на серверной стороне, должны загружаться по сети Интернет на компьютеры конечных пользователей;
· Проектирование и разработка программных средств Кольца сайтов должно осуществляться с использованием принципов и подходов модульной архитектуры программных решений;
· Интернет-сайты кольца сайтов должны предоставлять доступ к информационным ресурсам следственных органов по субъектам Российской Федерации и возможность размещения регионально-привязанных информационных материалов;
· Программные средства Кольца сайтов должны обеспечить централизованное управление информационным наполнением интернет-сайтов следственных органов, с помощью графического интерфейса, не требующего от пользователей знания специализированных языков программирования.
Интернет-сайты кольца сайтов должны включать следующие типы информационных страниц:
· текстовые страницы;
· новостная лента;
· вопросы и ответы;
· архив файлов;
· формы сбора обращений;
· карта сайта.
3.2. Текстовая страница
Сетка типовой текстовой страницы представлена на рис. 12
Рис. 12. Сетка типовой внутренней текстовой страницы.
Типовая текстовая страница должна содержать заголовок, изображение и текстовое описание. Также должна быть возможность вставки файлов для скачивания.
3.3. Новости
Сетка страницы ленты новостей представлена на рис. 13
Рис. 13. Сетка страницы «лента новостей».
Список новостей должен формироваться в хронологическом порядке и содержать информацию о дате публикации и названии новости.
При нажатии на название одной из новостей должна открываться страница с полным описанием новости (рис. 14)
Рис. 14. Сетка страницы «Описание новости».
Данная страница должна включать в себя заголовок новости, изображение, текстовое описание, а также видео, которое должно воспроизводиться в этом же окне без перезагрузки страницы.
3.4. Вопросы и ответы
Сетка страницы «вопросы и ответы» представлена на рис. 15
Рис. 15. Сетка страницы «Вопросы и ответы».
Страница должна представлять собой список вопросов. При нажатии на название вопроса должна открываться сразу под ним форма с ответом без перезагрузки страницы.
3.5. Архив файлов
Должен представлять собой страницу со списком файлов для скачивания. При нажатии на название файла должно происходить автоматические скачивание файла без перезагрузки страницы (рис. 16)
https://pandia.ru/text/78/390/images/image018_31.jpg" width="646" height="505">
Рис. 17. Сетка страницы «Форма обращения».
3.7. Карта сайта
Модуль «Карта сайта» должен обеспечивать отображение информации о структуре разделов выбранного интернет-сайта.
Названия разделов интернет-сайта должны отображаться в виде списка ссылок на соответствующий раздел. С помощью переходов по ссылкам пользователю должна быть предоставлена возможность осуществлять навигацию по выбранному интернет-сайту.
3.8. Требования к механизму создания и удаления сайтов
В рамках развития существующей программной платформы интернет-сайта Следственного комитета при прокуратуре Российской Федерации необходимо разработать механизм позволяющий добавлять новые и удалять существующие интернет-сайты Кольца сайтов на основе единого шаблона, согласованного с Заказчиком. Создание и удаление интернет-сайтов должно осуществляться без применения языков программирования. Данный механизм должен предусматривать возможность создания как сайтов с доменным именем третьего уровня, так и сайтов с доменным именем второго уровня.
3.9. Требования к информационному обеспечению
В рамках создания кольца сайтов должно быть осуществлено первичное наполнение одного пилотного интернет-сайта информационными материалами, которые должны быть предоставлены Заказчиком.
3.10. Требования к дизайну
Для интернет-сайтов входящих в состав кольца сайтов должен быть разработан единый дизайн страниц и элементов управления, соответствующий стилевой направленности и цветовому решению интернет-сайта Следственного комитета при прокуратуре Российской Федерации. Дизайн должен быть согласован с Заказчиком и предусматривать принадлежность интернет-сайта к соответствующему субъекту Российской Федерации.
Дизайн интернет-сайтов должен соответствовать современным требованиям к дизайну сайтов. Цветовая гамма кольца сайтов должна быть согласована с Заказчиком в рамках создания системы.
Дизайн интернет-сайтов кольца сайтов должен отвечать следующим стилевым характеристикам: строгий, деловой, лаконичный, эргономичный, информативный.
3.11. Требования к языковой поддержке
Интерфейсы кольца сайтов должны быть выполнены на русском и английском языках . Административные интерфейсы кольца сайтов должны быть выполнены только на русском языке.
3.12. Развитие единой программной платформы сайта СКП
В рамках развития необходимо осуществить:
· Информационное наполнение одного пилотного сайта кольца сайтов в объеме, достаточном для проверки всей функциональности Системы, которое должно быть осуществлено в рамках проведения обучения;
· Проведение опытной эксплуатации;
· Ввод в промышленную эксплуатацию.
3.13. Требования к результатам проведенных работ
1. программные средства Кольца Сайтов Следственного комитета при прокуратуре Российской Федерации
2. эксплуатационную документацию в следующем составе:
· Программа и методика испытаний;
· Руководство администратора;
· Руководство контент-менеджера;
· Руководство по инсталляции;
· Руководство программиста.
Отчетные материалы должны быть предоставлены в двух экземплярах. Программные средства предоставляются только на электронном носителе в одном экземпляре.