ГОСТ 34.602-89. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ

Публикация № 13773

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

Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее - ТЗ на АС).
Дата введения с 01.01.1990г

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

1.1. ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

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

Дополнительно могут быть разработаны ТЗ на части АС:
на подсистемы АС, комплексы задач АС и т. п. в соответствии с требованиями настоящего стандарта;
на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП;
на программные средства в соответствии со стандартами ЕСПД;
на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

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

1.3. Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают.

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

1.5. ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС», установленной ГОСТ 24.601.

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

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с ... ».
2. СОСТАВ И СОДЕРЖАНИЕ

2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:
1) общие сведения;
2) назначение и цели создания (развития) системы;
3) характеристика объектов автоматизации;
4) требования к системе;
5) состав и содержание работ по созданию системы;
6) порядок контроля и приемки системы;
7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8) требования к документированию;
9) источники разработки.

В ТЗ на АС могут включаться приложения.

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

В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом.

2.3. В разделе «Общие сведения» указывают:
1) полное наименование системы и ее условное обозначение;
2) шифр темы или шифр (номер) договора;
3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
5) плановые сроки начала и окончания работы по созданию системы;
6) сведения об источниках и порядке финансирования работ;
7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:
1) назначение системы;
2) цели создания системы.

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

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

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

2.5. В разделе «Характеристики объекта автоматизации» приводят:
1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Примечание: Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

2.6. Раздел «Требования к системе» состоит из следующих подразделов:
1) требования к системе в целом;
2) требования к функциям (задачам), выполняемым системой;
3) требования к видам обеспечения.

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

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

2.6.1.1. В требованиях к структуре и функционированию системы приводят:
1) перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы;
2) требования к способам и средствам связи для информационного обмена между компонентами системы;
3) требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.);
4) требования к режимам функционирования системы;
5) требования по диагностированию системы;
6) перспективы развития, модернизации системы.

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

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

Для АСУ указывают:
степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления;
допустимые пределы модернизации и развития системы;
вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

2.6.1.4. В требования к надежности включают:
1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;
2) перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности, и значения соответствующих показателей;
3) требования к надежности технических средств и программного обеспечения;
4) требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

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

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

2.6.1.7. Для подвижных АС в требования к транспортабельности включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам.

2.6.1.8. В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают:
1) условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания;
2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.;
3) требования по количеству, квалификации обслуживающего персонала и режимам его работы;
4) требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов;
5) требования к регламенту обслуживания.

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

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

2.6.1.11. В требованиях к средствам защиты от внешних воздействий приводят:
1) требования к радиоэлектронной защите средств АС;
2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

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

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

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

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

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

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

2.6.3.2. Для информационного обеспечения системы приводят требования:
1) к составу, структуре и способам организации данных в системе;
2) к информационному обмену между компонентами системы;
3) к информационной совместимости со смежными системами;
4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии;
5) по применению систем управления базами данных;
6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
7) к защите данных от разрушений при авариях и сбоях в электропитании системы;
8) к контролю, хранению, обновлению и восстановлению данных;
9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

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

2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:
1) к независимости программных средств от используемых СВТ и операционной среды;
2) к качеству программных средств, а также к способам его обеспечения и контроля;
3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

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

2.6.3.6. В требованиях к метрологическому обеспечению приводят:
1) предварительный перечень измерительных каналов;
2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;
3) требования к метрологической совместимости технических средств системы;
4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;
5) требования к метрологическому обеспечению технических и программных средств, входящих в состав измерительных каналов системы, средств, встроенного контроля, метрологической пригодности измерительных каналов и средств измерений, используемых при наладке и испытаниях системы;
6) вид метрологической аттестации (государственная или ведомственная) с указанием порядка ее выполнения и организаций, проводящих аттестацию.

2.6.3.7. Для организационного обеспечения приводят требования:
1) к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию;
2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;
3) к защите от ошибочных действий персонала системы.

2.6.3.8. Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т. п.).

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

В данном разделе также приводят:
1) перечень документов, по ГОСТ 34.201-89, предъявляемых по окончании соответствующих стадий и этапов работ;
2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);
3) программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
4) перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).

2.8. В разделе «Порядок контроля и приемки системы» указывают:
1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
2) общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
З) статус приемочной комиссии (государственная, межведомственная, ведомственная).

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

В перечень основных мероприятий включают:
1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
2) изменения, которые необходимо осуществить в объекте автоматизации;
3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
4) создание необходимых для функционирования системы подразделений и служб;
5) сроки и порядок комплектования штатов и обучения персонала.

Например, для АСУ приводят:
изменения применяемых методов управления;
создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

2.10. В разделе «Требования к документированию» приводят:
1) согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли заказчика;
перечень документов, выпускаемых на машинных носителях;
требования к микрофильмированию документации;
2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

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

2.12. В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:
1) расчет ожидаемой эффективности системы;
2) оценку научно-технического уровня системы.

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.
3. ПРАВИЛА ОФОРМЛЕНИЯ

3.1. Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд. 2 настоящего стандарта.

3.2. ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней.

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

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

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

При этом в текст ТЗ на АС изменений не вносят.

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

Форма титульного листа ТЗ на АС приведена в приложении 2. Форма последнего листа ТЗ на АС приведена в приложении 3.

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

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

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

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

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Egor 24.04.06 05:20 Сейчас в теме
Как Вы думаете, почему в составе комплекта документов фирмы 1С нет ни единой формы, соответствующей старым советским и российским стандартам по автоматизации? Да потому, что если заполнить такую форму характеристиками имеющегося коммерческого продукта 1С, его никто не купит - слишком хорошо станут видны очевидные недостатки. А клиент в 99 случаев из 100 не только не применяет систем стандартизации, он про них даже не подозревает, а если подозревает, то считает их лишней палкой в колёсах его бизнеса. И зачастую клиент прав! В таких стандартах без поллитры не разберёшься.
hame1e00n; The gray Cardinal; +2 Ответить
2. jjinn 21.09.11 10:33 Сейчас в теме
В июле 2006 года был принят Закон № 152-ФЗ «О персональных данных», устанавливающий как для государственных, так и для коммерческих жесткие требования к защите личной информации россиян, их обработке и хранению. Его «чары» должны были распространиться на тысячи организаций (банки, страховые и сотовые компании, турагентства, гостиницы, торговые фирмы, дошкольные учреждения, жилконторы). Представители бизнес-сообщества запаниковали, благо было от чего: статья 19 этого документа обязывала фирмы в кратчайшие сроки установить для сохранности клиентских баз баснословно дорогие (10 млн рублей не предел) сертифицированные программные комплексы, причем не абы какие, а только приглянувшиеся Федеральной службе безопасности и Федеральной службе по техническому и экспортному контролю (ФСТЭК). Денег и времени на приобретение систем ограничения доступа, программ по криптографической и антивирусной защите у бизнеса просто не было, санкции же за невыполнение предписаний вводились самые суровые – от крупных штрафов до отзыва лицензий. Да и сам закон представлялся предпринимателям крайне сырым, нелогичным, коррупционноемким, «делегализующим» существование прямого маркетинга, составление черных списков проблемных клиентов и даже видеонаблюдение за посетителями, приравнивающееся к фиксации биометрических данных человека.
3. PochekutovOleg 21.11.11 07:57 Сейчас в теме
4. Sintson 363 05.12.13 11:52 Сейчас в теме
То что нужно, затеял писать ТЗ по ГОСТ для достаточно крупной компании.
Впервые встречаю работодателя (заказчика), не только лояльно относящегося к документированию, но и можно сказать требующего такого подхода.
Долго думал над содержанием ТЗ (писал разненькие), но в этот раз решил остановиться на ГОСТе.
Жаль комментаторов нет совсем, никто опытом не делится, а тема-то интереснейшая.
PS:
Автору, спасибо в виде звезды и продвижения публикации.
Посетителей публикации приглашаю к обсуждению.
5. mymyka 05.12.13 11:58 Сейчас в теме
(4)А что комментировать то? микрофильмирование документов?) с 1990 года много воды утекло.
ТЗ это тз, фактически пользователская хотелка в общих фразах, а вот насколько подробна будет проектная документации зависит только от ее составителя, и ни один ГОСТ такие вещи не регламентирует.
6. Sintson 363 05.12.13 13:59 Сейчас в теме
(5) Вот тут я с Вами не соглашусь, проектную документацию Вы как формировать собираетесь? На основании чего? Где формализованные требования к будущему проекту?
При чем тут 90-й год и микрофильмирование, тоже не понятно.

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

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

Сейчас вот сижу разбираю 7-ку, сильно переписанную из "Торговли и склада", документации нет, часть механизма не известно для чего, никто уже и не вспомнит, что это было...
7. mymyka 05.12.13 14:48 Сейчас в теме
(6)
При чем тут 90-й год и микрофильмирование, тоже не понятно.

микрофильмирование это один из пунктов данного госта, а 90 год - год вступления в силу.
формализованные требования к будущему проекту

Согласитесь, что проектная документация для печатной формы, бизнес-процесса CRM и адресного склада будет иметь мало общего. Разве что глобальные подразделы: цель, методы решения, экономическое обоснование.
Но для выделения данных разделов совсем не обязательно иметь ГОСТ, достаточно толику здравого смысла.
Совсем другое дело детализация, например, методов решения, способов расчета экономического эффекта. Если на все эти задачи применить ГОСТ, то для некоторых из них он может оказаться чрезмерно избыточным, для других недостаточным. В первом случае это значительно затрудняет его применение, во втором вообще может обратиться финансовыми потерями как для заказчика, так и для исполнителя.
Сейчас вот сижу разбираю 7-ку, сильно переписанную из "Торговли и склада", документации нет, часть механизма не известно для чего, никто уже и не вспомнит, что это было...

Как гласит народная мудрость, "Работает - не трогай" =) А, если разбор идет для перехода на 8, то, имхо, проще забить. 2/3 доработок в 7 это типовой функционал в 8.
8. Sintson 363 05.12.13 15:07 Сейчас в теме
(7)
Переход на 8, и нет там такого, что в 7-ке навояли.
По поводу избыточности и недостаточности, здравый смысл - думаю лучшее мерило применения или не применения методов документирования.
Про 90-е.. ИМХО если хорошо для использования, почему не взять на вооружение?
9. mymyka 05.12.13 15:36 Сейчас в теме
(8)Здравый смысл это антипод стандартам. Я об этом и говорю. Например, здравый смысл говорит мне, что на сухой прямой загородной дороге в светлое время суток в ясную погоду я могу двигаться 150, но согласно ГОСТу знак стоит 80. Аналогично и с автоматизацией. Избирательность подхода только усугубит ситуацию. Часть изменений будет задокументирована, на это будет потрачено время, а другую часть пропустят, посчитав неважной. На основании каких данных вы начнете исследование? Неполной документации, рискуя упустить важные, но незадокументированные моменты, или по старинке, с самой конфы, опроса пользователей и т.д.? Зачем тогда тратили время на документирование, актуализацию проектной документации при доработках?

Переход на 8, и нет там такого, что в 7-ке навояли

Но при этом никто не знает, что именно наваяли) Для бизнес-процессов(не касательно автоматизации, а вообще)есть, кстати, замечательная система сертификации ISO-900х. Переход на новую учетную систему отличный момент, чтобы собрать, описать и регламентировать бизнес-процессы(делать это все равно придется, только по частям).
Начинаете переход без описания бизнес-процессов, да еще и воьсмерку семерошные костыли тащите? По лезвию бритвы, однако, ходите =)Перефразируя известное выражение, я бы сказал truthfail is out there )
10. angele 31.01.14 15:15 Сейчас в теме
Былобы неплохо выложить его в PDF формате.
Оставьте свое сообщение

См. также

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

23.02.2017    27096    0    Gavrik    10    

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

Техническое задание Бесплатно (free)

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

28.05.2020    6924    0    sapervodichka    69    

Модернизация КА 2.4 под маркетинговую компанию. Часть 1

Управление взаимоотношениями с клиентами (СRM) Техническое задание v8 КА2 Россия УУ Бесплатно (free)

Выполнил для компании, которая занимается маркетингом и продвижением продуктов, проектирование и модификацию конфигурации КА 2.4 и справочника «Проекты». Теперь в конфигурации «Проекты» имеют особенную роль и на основании выполненной доработки руководство компании принимает решения по продолжению, закрытию или продвижению проекта/ов, поиск путей решения возникающих вопросов. При необходимости доработку можно реализовать под ERP конфигурацию. Архитектура решения выполнена «рядом» с основной конфигурацией. В настоящее время конфигурация поддерживается, модификация ведется в актуальной версии КА 2.4.10 на платформе 8.3.14.1630.

29.10.2019    5792    0    BraunAlex    1    

Impact mapping: чем он может быть вам полезен

Техническое задание Бесплатно (free)

Привет, коллеги! Сегодня хочу поговорить про один из инструментов Владельца продукта - Impact mapping (карта влияния). Чем он хорош и почему его стоит использовать.

26.07.2019    6204    0    slozhenikin_com    14    

Как оценивать задачи программисту 1С Промо

Техническое задание Россия Бесплатно (free)

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

11.08.2016    33035    0    SamBadi    52    

Как проектировать отчетность

Техническое задание Управление проектом Управленческие v8 УУ Бесплатно (free)

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

16.10.2018    9155    0    weissfeuer    2    

На чьей стороне мячик? Алгоритм определения исполнителя задачи

Техническое задание Управление бизнес-процессами (BPM) Бесплатно (free)

Я считаю, что мало кому удалось избежать ситуации, когда его назначали исполнителем работы, мягко скажем, не его уровня. На мой взгляд, такое особенно часто встречается среди технических специалистов. Причем, в случае возражения, обычным аргументом противоположной стороны является: "Нам так раньше всегда делали!". Эта публикация является попыткой описать формализовано процесс определения исполнителя с точки зрения логики. Посвящается тем, кто, будучи невежественным в вопросе, смеет указывать, кому его решать. А также тем, кто это терпит.

14.08.2018    7277    0    itriot11    42    

Первый шаг к успешному проекту автоматизации

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Россия Бесплатно (free)

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

30.03.2018    10164    0    Aprsoft    1    

Направления работы программиста 1С Промо

Техническое задание Бесплатно (free)

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

08.11.2012    43281    0    adhocprog    58    

Должностная инструкция специалиста по 1С

Техническое задание Бесплатно (free)

Описание функциональных обязанностей для трёх категорий специалистов 1С: Администратор платформы, Программист, Администратор конфигурации (Методист).

14.12.2017    25376    0    Vikki-di    20    

Внедрение МСФО: план-график выполнения проекта по автоматизации МСФО

Техническое задание Управление проектом МСФО (GAAP) МСФО (GAAP) БУ Бесплатно (free)

В данной статье будут детально рассмотрены задачи, которые предстоит выполнить в процессе запуска проекта автоматизированной подготовки отчетности МСФО

23.10.2017    10073    0    user743750    0    

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

Техническое задание 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

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

26.04.2017    24036    0    Soliton    33    

Есть 2 подхода к внедрению информационных систем. На примере 1С УПП 8 Промо

Управление проектом Техническое задание v8 УПП1 Россия Бесплатно (free)

С детальным ТЗ? Или без серьезного ТЗ? Какой лучше? И где успех более вероятен?

26.01.2012    55698    0        54    

Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С

Техническое задание Управление проектом Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика Бухгалтерский учет Управленческий учет (прочее) Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика v8 Россия УУ Бесплатно (free)

Это схема и обоснование концепции системы АУБ (Автоматизация Управления Бизнесом, авторская разработка) для автоматизации многопрофильного холдинга на платформе 1С. Система изначально проектировалась для многопрофильного холдинга, что определило особенность ее концепции - три уровня автоматизации. Система АУБ не является готовым решением, это определенная концепция (видение, подход) к автоматизации управленческого учета и расширяемый базис наработок реализованных в этой концепции. В конкретном проекте автоматизации, с учетом специфики управления предприятием, делается индивидуальная «функциональная сборка» с использованием готовых, существенно модифицируемых и заново разрабатываемых подсистем. Таким образом, концепция и расширяемый базис наработок системы АУБ, представляют своего рода конструктор, из которого компонуется решение в конкретном проекте, при этом заново разрабатывается лишь функционал, отражающий новую специфику. На практике концепция использовалась, например, в отраслевом решении для производства ЖБИ и добычи нерудных материалов.

02.03.2017    18370    0    aaw    3    

Как самим написать техническое задание

Техническое задание Россия Бесплатно (free)

Как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. 

21.02.2017    14277    0    user694964_olamikyw    6    

Проектное внедрение прав доступа в системах 1С

Техническое задание Управление бизнес-процессами (BPM) Управление проектом v8::Права 1cv8.cf Бесплатно (free)

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

17.01.2017    17401    0    Gavrik    4    

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

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

06.12.2016    18978    0    Gavrik    19    

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

Техническое задание Управление проектом Бесплатно (free)

Хочу рассказать об очень интересном проекте, с которым мы недавно столкнулись. В этом проекте необходимо было сделать огромный объем работы за очень короткий промежуток времени, поэтому мы его условно назвали «Марафон со спринтерской скоростью».

26.09.2016    14356    0    R.Tsarenko    27    

Дропшиппинг или "виртуальные" склады поставщиков в 1С

Техническое задание Оптовая торговля Розничная торговля Учет ТМЦ Оптовая торговля Розничная торговля Учет ТМЦ v8 УТ10 УУ Бесплатно (free)

Сейчас всё больше компаний работают по системе дропшиппинг (прямые поставки, когда поставщик отправляет товар непосредственно клиенту, а не продавцу) или продают товар со склада поставщика не закупая его себе на склад (под конкретные заказы покупателей). При этом за частую есть необходимость хранения остатков и цен поставщика, выгрузки их на сайты и другие информационные ресурсы, рассылки в своих прайс листах. В статье рассматриваются варианты отражения подобных операций в управленческих конфигурациях 1С без привязки к конкретной конфигурации. С некоторыми различиями данные схемы можно применить в Управлении торговлей 10 и 11, Рарус:Альфа-авто, Комплексной автоматизации, УПП и др. т.е. в целом в любой конфигурации с возможностью ведения управленческого учета и механизма заказов.

02.09.2016    28152    0    de0nis    17    

Как заставить разработки работать

Техническое задание Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

30.03.2016    21112    0    liurn    26    

Предприятие требует проект автоматизации? Начните правильно!

Техническое задание Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

23.12.2015    23730    0    Gavrik    5    

Большой проект: документация

Техническое задание Управление проектом Бесплатно (free)

Оставим за рамками нашей темы поиск потенциального клиента. Мы его нашли. Вот он - Большой клиент. Чего мы хотим? Хотим заработать. И чтобы этот Большой клиент был у нас не один. А к нам большинство таких клиентов пришли по рекомендации, а для рекомендаций положительных нужно, чтобы Большой клиент был очень доволен сотрудничеством с нами. Но и мы хотели бы быть довольны работой с ним. Вот о том, какими документами мы этого добиваемся, я и попытаюсь рассказать. *** Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года). Также она опубликована в журнале Инфостарта № 3

23.03.2015    20655    0    UR1    5    

Автоматизация работы фрилансера

Техническое задание Управление взаимоотношениями с клиентами (СRM) Управление проектом Управление взаимоотношениями с клиентами (СRM) УУ Бесплатно (free)

Появилось желание рассказать о социальном интранете - Битрикс24. Я опишу опыт внедрения и использования данного продукта от лица фрилансера 1С.

25.09.2013    25343    0    randa    45    

Алгоритм работы с техническим заданием заказчика

Техническое задание Бесплатно (free)

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

24.09.2013    33177    0    Neti    21    

Пример ТЗ и ТП на небольшую доработку

Техническое задание v8 БП2.0 Россия Бесплатно (free)

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

14.12.2012    63196    0    SergAn    10    

Как разработать Техническое задание. Часть 2. Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов.

Техническое задание Россия Бесплатно (free)

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

11.04.2012    36255    0    chavalah    34    

Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?

Техническое задание Россия Бесплатно (free)

В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается "как получится". Как сказал Генри Шоу "Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи".

03.04.2012    74341    0    chavalah    55    

РД 50-34.698-90 - АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ

Техническое задание Россия Бесплатно (free)

Методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т. п.), включая их сочетание, и устанавливают требования к содержанию ВСЕХ документов, разрабатываемых при создании АС.

06.01.2010    15346    0    nnn123    1    

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

Техническое задание Управление проектом Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

"Листая старые страницы" времен универа нашел несколько, которыми можно поделиться, не рискуя получить по бошке. :) В общем-то, ничего нового, но думаю, многим может пригодиться.

08.06.2009    31823    0    Оболтус    20    

7 Граблей или история одного IT-директора

Техническое задание Россия Бесплатно (free)

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

08.06.2009    36474    0    GSoft    82    

Переход с 1С:Предприятие 7.7 на 8.0. Всегда ли это нужно?

Перенос данных из 1С7.7 в 1C8.X Техническое задание О жизни Россия Бесплатно (free)

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

06.02.2008    28738    0    O-Planet    74    

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

Техническое задание Россия Бесплатно (free)

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

05.04.2007    23049    0    support    5    

ГОСТ 24.201-79. ТРЕБОВАНИЕ К СОДЕРЖАНИЮ ДОКУМЕНТА «ТЕХНИЧЕСКОЕ ЗАДАНИЕ»

Техническое задание Россия Бесплатно (free)

Постановлением Государственного комитета СССР по стандартам от 31 января 1979 г. № 383 срок введения установлен с 01.07 1980 г. Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления народным хозяйством (кроме общегосударственного), и устанавливает общие требования к содержанию документа «Техническое задание» (ТЗ) на создание АСУ, кроме АСУ технологическими процессами. В зависимости от вида и назначения АСУ требования, устанавливаемые в настоящем стандарте, допускается конкретизировать в нормативно-технической документации.

29.06.2005    25504    0    support    6    

ГОСТ 19.201-78. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ.

Техническое задание Россия Бесплатно (free)

Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Стандарт полностью соответствует СТ СЭВ 1627-79.

29.06.2005    33645    0    support    4