Руководства, Инструкции, Бланки

как правильно написать техническое задание образец img-1

как правильно написать техническое задание образец

Категория: Бланки/Образцы

Описание

Как написать правильное техническое задание (ТЗ)? Системо - сайты на WordPress

Как написать правильное техническое задание (ТЗ)?

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

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

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

Вот как раз о том как мы пишем ТЗ, тут и поговорим.

Изначальные условия, из которых выросла наша методика:

  1. Мы перестали работать с крупными проектами. Если задача слишком большая, мы просто разбиваем ее на куски и делаем по шагам. Сначала самые важные части, затем докручивая постепенно дополнительные компоненты. Задачи делим на куски по 1-2 недели. Иногда по 2-4 недели. Слишком большие задачи сложнее ставить, легко допустить ошибки в постановке задачи и затем получить проблемы в результате. Пошаговая схема — оптимальна. Еще этот метод называют Agile .
  2. Мерилом прогресса являются итерации или версии продукта. Чем чаще делаются итерации тем лучше.

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

Берем чистый лист бумаги (Google Документ лучше всего) и начинаем писать ТЗ, которое состоит из следующих основных разделов:

Первый раздел ТЗ звучит как Задача.

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

Исходные данные

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

Требования к результату

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

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

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

Ограничения

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

Согласование

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

Как пишет задачу клиент?

Клиенты разные по характеру — пишут задачи по разному:

  1. Кто то пишет просто задачу в одну строку «Нужен сайт, который будет продавать Угги».
  2. Часть клиентов описывают задачи в Evernote с гиперссылками между требованиями. Где на каждый важный участок есть своя карточка.
  3. А кто то пишет ТЗ в трекерах, где каждый тикет — это часть задачи, а задача определяется как веха (millestone).
  4. Кто то пишем в MindMap.
  5. Есть те кто все еще используют в MS Word.
  6. Самые любимые наши клиенты пишут задачи в Google Документах. Таким сразу +10 к уровню уважения и любви ??

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

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


Поделитесь страницей в социальных сетях:

2 комментария Получайте раз в неделю интересные материалы о улучшении сайтов на базе WordPress

Другие статьи

ТХconsult - Как правильно составить частное техническое задание

Главный инженер проектов - А.И. Кондратьев

Ведущий инженер технолог - А.А. Баранов

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

2. Алгоритм составление частного технического задания (ЧТЗ).

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

Уважаемые коллеги, последние время на наш электронный адрес info @ txconsult. ru приходит множество запросов с целью проектирования не типовых, сложных объектов производственного назначения.

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

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

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

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

ЧТЗ напрямую влияет на стоимость проектных и строительно-монтажных работ, а также на сроки выполнения таковых.

Наш опыт, позволяет нам рассмотреть наиболее типичные ошибки при составлении ЧТЗ.

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

Итак, по нашему мнению и опыту работы, наиболее типичные ошибки при составлении ЧТЗ сегодня таковы:

Ошибка №1. ЧТЗ составлено без увязки с технологическим процессом, или новый процесс, осуществляемый на новом оборудовании, пытаются вписать в старые технологии.

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

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

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

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

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

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

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

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

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

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

Пожалуй, на этом можно - остановится.

2.Алго ритм составление частного технического задания .

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

Старожилы проектных организаций могут ухмыльнуться, а как же ГОСТ (Техническое задание требуется готовить по ГОСТу 19.201-78)? Таким читателям лучше закончить прочтение данной статьи и простить меня за потраченное время. Для поколения молодых специалистов, пожалуй, продолжу, ГОСТ – слишком общий документ и не обязателен для коммерческих организаций, каждая организация пишет его по-своему, но всё же стоит один раз прочесть ГОСТ, чтобы знать, что он есть. Я же представляю свой алгоритм (шаблон ЧТЗ), с перечнем требований, условий, целей, задач, которые я, как исполнитель (технолог) хочу видеть от своих Заказчиков.

Указывается адрес площадки строительства. Необходимость указывать район обусловлена:

- предварительным просчетом климатической зоны;

- анализ грунтов для выбора типа фундамента;

- граница жилой зоны и профилактория, для анализа ООС (Охрана окружающей среды);

- необходимость разрабатывать проект ОЗДС;

- для запроса КП с учетом расходов на доставку;

- анализ затрат на командировочные расходы.

Как правильно написать техническое задание образец

ГОСТ 19.201-78

United system for program documentation.
Technical specification for development. Requirements to contents and form of presentation

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3351 срок введения установлен

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

Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ

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

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

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

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

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

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

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

(Измененная редакция, Изм. № 1)

2. СОДЕРЖАНИЕ РАЗДЕЛОВ

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

(Измененная редакция, Изм. № 1)

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

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

(Измененная редакция, Изм. № 1)

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

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

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

(Измененная редакция, Изм. № 1)

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

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

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

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

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

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

(Измененная редакция, Изм. № 1)

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

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

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

(Введен дополнительно, Изм. № 1).

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

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

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

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

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

Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июле 1981 г (ИУС 7-81)

Как правильно написать техническое задание для тендера образец

Скачать как правильно написать техническое задание для тендера образец: лучший фон для презентаций

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

Как правильно составить техническое задание для тендера: пример. Какие требования предъявляются к написанию технического задания для. 21 дек 2010 Что же входит в тех. задание для визуализации. цоколя до крыши, а так же предоставить образцы материалов в виде фотографий. ФАС Узнайте, когда и как подавать жалобу в ФАС и как правильно ее написать. Пролог Большое поле сплошь покрыто травой с многочисленными вкраплениями полевых цветов. Библиотека ТЗ для торгов (аукцион, конкурс, котировка) Правильно написанное ТЗ поможет вам получить изделие с нужным набором помогут образцы технических заданий для тендера по закупке оборудования, Вы можете самостоятельно написать техзадание для аукциона, взяв за образец один. Почему на сайте СОТВ до сих пор не загружено видео последней передачи? И почему саму. 10 дек 2014 С техническим заданием, или ТЗ, связано много шуток, мемов и проблем. Многие люди не понимают, зачем это нужно и как правильно. Правильно составленное ТЗ помогает получать более качественный контент. вписывать ключевые слова в текст, даже если вы идеально напишите ТЗ. + Делать заказ в форме тендера, чтобы самому выбирать исполнителя. 25 май 2015 Техническое задание - это документ, содержащий требования заказчика к объекту закупки. Заказчик разрабатывает отдельное техническое задание под каждую конкретную закупку. 17 135-ФЗ при проведении государственных тендеров нужно учитывать Комментарии Написать свой. Тендер – конкурентная борьба в условиях проведения конкурса за составляет первоначальный вариант технического задания, на основании которого Универсальная форма позволяет заказчику в короткие сроки произвести их чтобы правильно составить документацию по тендеру;; Предоставлять. «Форум Документ» Справочник Главного инженера Год выпуска: 2008 года Обновление: Декабрь.

ПОЛОЖЕНИЕ о проведении тендера на предоставление услуг в сфере управления персоналом. Разработка ПОС, искусство проектирования Технология и организация строительства. Качественная подготовка технического задания на участие в закупках по Если вам требуется помощь в подготовке технического задания по 44-ФЗ в Статья. Техническое задание (форма 2). тендеры костромская область. 4 июн 2015 Как правильно подготовить техническое задание к тендеру по информационной безопасности Техническое задание на тендер, образец (примерная структура) Комментарии. 2 комментария Написать свой.

РАЗРАБОТКА И ПРАВИЛА ОФОРМЛЕНИЯ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА СОЗДАНИЕ АИС

6.4. РАЗРАБОТКА И ПРАВИЛА ОФОРМЛЕНИЯ
ТЕХНИЧЕСКОГО ЗАДАНИЯ НА СОЗДАНИЕ АИС

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

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

Разработка ТЗ ведётся в соответствии со стандартами:

ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

ГОСТ 34.602-89. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

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

1. Организация-заказчик (пользователь), для которой создаётся АИС и которая обеспечивает финансирование, приёмку работ и эксплуатацию как по всей АИС, так и по отдельным её компонентам;

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

3. Организация-поставщик, изготавливающая и (или) поставляющая программные и технические средства по заказу Разработчика или Заказчика;

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

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

ТЗ на АИС разрабатываются на основании исходных данных.

Любые изменения к ТЗ оформляются дополнительными протоколами, подписанными заказчиком и разработчиком. Оформленные таким образом дополнения являются неотъемлемой частью ТЗ на АИС. На титульном листе ТЗ должна быть запись “Действует с …”.

СОСТАВ И СОДЕРЖАНИЕ ТЕХНИЧЕСКОГО ЗАДАНИЯ

Рассмотрим состав ТЗ с учётом требований ГОСТ 34.602-89.

ТЗ на АИС содержит следующие разделы:

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

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

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

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

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

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

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

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

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

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

Рассмотрим содержание основных разделов ТЗ с учётом требований ГОСТ 34.602-89.

Раздел “Общие сведения”:

1. Полное наименование системы и её условное обозначение.

2. Наименование и реквизиты предприятий (объединений) разработчика и заказчика системы.

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

4. Возможные сроки начала и окончания работ по созданию системы.

5. Сведения об источниках и порядке финансирования работ.

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

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

1. Под “Назначением системы” понимается вид автоматизируемых процессов (деятельности) и перечень предполагаемых к использованию объектов.

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

Раздел “Характеристики объекта автоматизации”.

1. Краткие сведения об объекте автоматизации или ссылки на документы, содержащие эти данные.

2. Сведения об условиях эксплуатации объекта автоматизации.

3. Характеристики внешней среды, в которой функционирует объект автоматизации.

Раздел “Требования к системе” содержит подразделы с требованиями к системе в целом, функциям (задачам), выполняемым системой, видам обеспечения.

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

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

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

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

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

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

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

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

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

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

    В части требований к организационному обеспечению приводят требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию; организации функционирования системы и порядку взаимодействия персонала АИС с персоналом объекта автоматизации; защите от ошибочных действий персонала системы.

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

    Раздел “Состав и содержание работ по созданию (развитию ) системы” должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 34.601-90, сроки их выполнения, перечень организаций-исполнителей работ, ссылки на документы, подтверждающие их согласие на участие в создании системы и т.п.

    В разделе “Порядок контроля и приемки системы” указывают: 1. Виды, состав, объём и методы испытаний системы и её составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
    2. Общие требования к приемке работ по стадиям (перечень участвующих организаций, и/или юридических и физических лиц, место и сроки проведения), порядок согласования и утверждения приёмочной документации;
    3. Статус приёмочной комиссии (государственная, межведомственная, ведомственная и т.п.).

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

    В разделе “Требования к документированию” приводят: 1. Согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, в т.ч. выпускаемых на машинных носителях;
    2. Требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
    3. При отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

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

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

    В состав ТЗ на АИС включают приложения, содержащие расчёт ожидаемой эффективности системы; оценку научно-технического уровня системы; использованные при разработке ТЗ методические и наиболее важные информационные материалы из состава документов указанных в разделе “Источники разработки”.

    Дополнительные рекомендации по составу и содержанию ТЗ на автоматизированные системы различного назначения и приложений к ним содержатся также в РД 50-640-87 и ГОСТ 24.602-86.

    ПРАВИЛА ОФОРМЛЕНИЯ ТЗ НА АИС

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

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

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

    Разделы и подразделы ТЗ должны быть размещены в порядке, установленном ГОСТ 34.602-89.

    Если конкретные значения показателей, норм и требований не могут быть установлены в процессе разработки ТЗ на АИС, в нём делают запись о порядке установления и согласования этих показателей, норм и требований “Окончательное требование (значение) уточняется в процессе. и согласовывается протоколом с. на стадии. ”. При этом в текст ТЗ на АИС изменений не вносят.

    Титульный лист дополнения к ТЗ на АИС оформляют аналогично титульному листу Технического задания. Вместо наименования “Техническое задание” пишут “Дополнение 1. к ТЗ на АИС. ”.

    На следующих листах дополнения к ТЗ на АИС помешают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.

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

    Реально сложившаяся практика проектирования АИС предусматривает следующие этапы (стадии) проектирования: 1. Предпроектное обследование . включающее:
    • краткую характеристику исходного состояния объекта автоматизации и среды, в которой он функционирует;
    • указание основных целей и перечень задач автоматизации;
    • описание укрупнённой организационно-функциональной структуры выбранного варианта (вариантов) построения создаваемой системы;
    • технико-экономическое обоснование системы;
    • укрупнённое описание и основные требования к средствам информационного и лингвистического обеспечения;
    • перечень и общие требования к средствам программно-аппаратного обеспечения;
    • перечень и укрупнённую характеристику этапов создания системы, сроки их выполнения;
    • исходную оценку стоимостных показателей выполнения работ;
      2. Техническое задание на систему в целом и (или) её основные составные части (подсистемы, программно-технические комплексы и средства, отдельные задачи и т.д.), выполненное в соответствии с ГОСТ 34.601-90.
      3. Эскизное проектирование. При проектировании программного обеспечения системы Эскизный проект должен содержать полную спецификацию разрабатываемых программ.

    4. Опытная и промышленная эксплуатация разработанной АИС. По результатам опытной, а порой и промышленной эксплуатации системы оптимизируют работу её составляющих и взаимодействие между ними, в том числе с учётом выполнения работниками действий, определённых для них Техническим заданием и Проектом. Это не означает, что с течением времени цели, задачи, способы их достижения, используемые технические и программные средства остаются неизменными.

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

    Сайт создан в системе uCoz