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

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

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

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

Получите 267 видеоуроков по 1С бесплатно:

Что должно содержать в себе техническое задание?

Тех. задание обязательно должно содержать в себе:

• цель — задача, которую мы решим, реализуя данное ТЗ;
• описание — краткое изложение предстоящих доработок;
• способ реализации — подробное описание методов решения цели. В этом пункте необходимо описать все нюансы задачи на языке программиста: какие , создаем/редактируем, как должен выглядеть интерфейс и т.д. Если Вы не владеете «языком программиста», но «что-то слышали», лучше не пытаться писать на техническом языке — получается достаточно весело. Описание должно быть однозначным и не вызывать вопросов. Также может содержать в себе пример реализации подобного решения в другой сфере;
• оценка работы — очень важный пункт, описание трудозатрат.

Также существуют государственные стандарты к написанию ТЗ — ГОСТы. На практике мало где применяются, но бывает, заказчик настаивает на этом.

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

Примеры и образцы ТЗ для 1С

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

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

Почему важно зафиксировать весь процесс работы в виде технической документации?

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

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

Если одна из сторон хочет сотрудничать без техзадания

Это может означать следующее:

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

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

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

Участники проекта

Если проект большой , дополнительно могут добавиться участники:

• Product Manager
• Руководитель проекта
• Спонсор проекта
• Тестировщики
• Технические писатели
• Кураторы
• Пользователи/потребители (например, для финального тестирования)
• И др.

Если проект маленький , то заказчик и исполнитель, как правило, работают напрямую. В этом случае тестирование берёт на себя заказчик, а разработчик сам контролирует сроки и ставит приоритеты.

Что дает сторонам каждый раздел ТЗ:

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

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

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

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

Обычно разработке качественного ТЗ мешают следующие моменты:

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

Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.

Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.

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

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

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

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

Техзадание должно отвечать на вопросы:

1. Что? (какие работы, содержание элементов)
2. Где? (расположение элементов)
3. Когда? (последовательность выполнения и установленные сроки работ)
4. Как? (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
5. Откуда? / Куда? (при переносе и т. п.)
6. Зачем? (обоснование работ, если задание будет согласовываться с 3-м лицом)
7. Особенности.

1. Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
2. Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
3. Программисту нужны четкие условия. Формулировки “как вариант”, “примерно”, “около”, “где-то рядом”, “там, где лучше по вашему мнению”, - неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
4. Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
5. Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
6. ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.

7 типовых ошибок

1. Нечеткие цели и задачи.
2. Мало деталей в технической информации.
3. Размытые или неустановленные сроки.
4. Нет согласованности по всем вопросам между сторонами.
5. Нет регламента взаимодействия.
6. Нет ответственных лиц.
7. Нет критериев оценки результата.

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

Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.

Описание :

1. ГДЕ? Добавить в главное верхнее меню сайта новый раздел «Ваш консультант» между разделами «Блог» и «Наши клиенты».
2. КУДА? URL новой страницы сделать: /vash_konsultant.htm
3. КАК? Макет новой страницы взять со страницы “Наши врачи”. Только вместо врачей будут консультанты.
4. ЧТО? Структура страницы следующая:
   • заголовок: Ваш консультант - по центру (в стиле других заголовков страниц сайта);
   • 3 блока в ряд, имеющие поля:
     • с фотографиями продавцов размером 400*600 (выравнивание по центру);
     • Ф.И.О. продавцов под фотографиями (текстовый формат с возможностью правки);
     • телефон общий у всех: 555-555-55 под Ф.И.О. (текстовый формат с возможностью правки);
     • электронный адрес под телефоном (e-mail: site 2@ mail . ru );
     • кнопка «Получить консультацию» ниже всех полей, размер кнопки, цвет и форма в стиле кнопок на сайте (см. кнопка «Сделать заказ» на url: /katalog.ru).
5. ОТКУДА? Данные консультантов должны правиться в редакторе сайта. Также должны редактироваться теги TITLE, DESCRIPTION, H1.

Если работы выполняются для целей SEO - не забывайте закладывать все необходимые элементы на странице.

Также внизу разместить форму заказа.

1. ГДЕ? Под списком консультантов, над футером.
2. ЧТО? Три поля:
   • Имя
   • Номер телефона
   • Содержание заявки
3. КАК? Обязательные для заполнения поля: Имя и Номер телефона. Оформление сделать по образцу формы обратной связи. Если обязательное поле не заполнено, то должно выводиться сообщение, как в форме обратной связи.
4. КУДА? Заявку отправлять на email заказчика: info @ common . com
5. КАК? Оформление письма в свободной форме.
6. ОСОБЕННОСТИ Защиту от ботов поставить, как на форме обратной связи.
   При отправке заявки, если все заполнено правильно, в Яндекс-метрику должно отсылаться событие “Отправка заявки”.
7. НЕ ЗАБЫТЬ О ПРАВИЛАХ ПРИЁМКИ
   Проверить:
   • На странице не должно быть незакрытых HTML-тегов.
   • Проверить адаптив на мобильных устройствах Android с разрешением ***x**** и ****x****, и планшетах с разрешением 1280 x 1024.
   • Проверить работу в браузерах Safari, Chrome, Mozilla.

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ
НА МОДЕРНИЗАЦИЮ САЙТА

Екатеринбург

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. эксплуатационную документацию в следующем составе:

· Программа и методика испытаний;

· Руководство администратора;

· Руководство контент-менеджера;

· Руководство по инсталляции;

· Руководство программиста.

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

С точки зрения ГОСТов*, в которых регламентирована деятельность по разработке программного обеспечения и автоматизированных систем (АС) – это основной документ, определяющий требования и порядок развития или модернизации (далее – создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

• *ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

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

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

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

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

Кто разрабатывает техническое задание

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

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

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

• Излагаются не системно, без привязки к какой-либо структуре (модули системы, бизнес-процессы);
• Дублируются;
• Относятся к различным уровням детализации.

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

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

• Излишняя детализация;
• Требования, противоречащие друг другу;
• Неточные формулировки.

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

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

Как избежать ошибок при составлении ТЗ

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

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

Руководствоваться нужно следующими правилами:

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

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