Комплект документации описывающий процесс строительства и эксплуатации

ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

Information technology. Set of standards for automated systems. Types, sets and indication of documents for automated systems design

Дата введения 01.01.90

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

Пояснение терминов, применяемых в настоящем стандарте, приведены в приложении 1.

1. ВИДЫ И НАИМЕНОВАНИЕ ДОКУМЕНТОВ

1.1. Состав видов документов, разрабатываемых на стадии «Исследование и обоснование создания АС» определяют в соответствии с разд. 3 ГОСТ 24.601, исходя из требуемых результатов выполнения данной стадии.

1.2. На стадии «Техническое задание» разрабатывают Техническое задание (ТЗ) на создание автоматизированной системы в соответствии с требованиями ГОСТ 34.602.

Кривая Гаусса. Аддитивное производство Часть 2 / Additive Manufacturing

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

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

Перечисление в систематизированном виде объектов, предметов и т. д.

Графическое изображение форм документов, частей, элементов системы и связей между ними в виде условных обозначений

Изложение состава действий и правил их выполнения персоналом

Изложение сведений, подтверждающих целесообразность принимаемых решений

Пояснение назначения системы, ее частей, принципов их действия и условий применения

1.3.1. Наименование конкретных документов, разрабатываемых при проектировании системы в целом или ее части, приведены в табл. 2.

Ведомость эскизного проекта

Пояснительная записка к эскизному проекту

Схема организационной структуры

Допускается включать в документ П3 или ПВ

Схема функциональной структуры

При разработке документов СО, С1, С2, С3 на стадии ЭП допускается их включать в документ П1

Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистемы, систем)

* Документы, код которых установлен в соответствии с требованиями стандартов ЕСКД

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

• 1. В таблице приняты следующие обозначения:

• ЭП — эскизный проект;
• ТП — технический проект;
• РД — рабочая документация;
• ОР — общесистемные решения;
• ОО — решения по организационному обеспечению;
• ТО — решения по техническому обеспечению;
• ИО — решения по информационному обеспечению;
• ПО — решения по программному обеспечению;
• МО — решения по математическому обеспечению.

1.3.2. Виды документов на программные средства, используемые при создании АС (ее частей), — по ГОСТ 19.101.77.

Обязательные разделы проектной документации. 29/03/2021

1.3.3. Виды документов на технические средства, используемые при создании АС (ее частей), — по ГОСТ 2.102 и по ГОСТ 2.601 в части эксплуатационных документов.

1.3.4. В зависимости от применяемых методов проектирования и специфики создаваемых АС допускается:

• 1) разрабатывать групповые и базовые документы в соответствии с разд. 1, 3, 4, 6 ГОСТ 2.113;
• 2) выпускать документы отдельными самостоятельными частями, соответствующими разделам основного документа;
• 3) расширять номенклатуру документов, установленную настоящим стандартом.

1.4. На стадиях «Изготовление несерийных компонентов КСА» и «Ввод в действие» разрабатывают следующие организационно-распорядительные документы:

• 1) акт завершения работ;
• 2) акт приемки в опытную эксплуатацию;
• 3) акт приемки в промышленную эксплуатацию;
• 4) план-график работ;
• 5) приказ о составе приемочной комиссии;
• 6) приказ о проведении работ;
• 7) программа работ;
• 8) протокол испытаний;
• 9) протокол согласования.

2. КОМПЛЕКТНОСТЬ ДОКУМЕНТАЦИИ

2.1. Перечень наименований разрабатываемых документов и их комплектность на систему и ее части должен быть определен в техническом задании на создание автоматизированной системы (подсистемы).

Примечание. Комплектность проектно-сметных документов определяют в соответствии с правилами, установленными системой проектной документации для строительства (СПДС).

2.2. На каждый комплект должна быть составлена ведомость документов.

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

2.4. Комплектность документации на программные средства вычислительной техники — по ГОСТ 19.101.77.

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

3. ОБОЗНАЧЕНИЯ ДОКУМЕНТОВ

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

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

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

3.3. Обозначение документа имеет следующую структуру:

pre> ___________
|___________|. XX. XX. X- X. M
| | | | | |
Обозначение системы | | | | | |
(части системы) | | | | | |
Код документа | | | | |
Порядковый номер документа одного | | | |
наименования | | | |
Номер редакции документа | | |
Номер части документа | |
Признак документа, выполненного на машинных |
носителях |

3.3.1. Правила обозначения системы (части системы) приведены в приложении 2.

3.3.2. Код документа состоит из двух буквенно-цифровых знаков. Код для документов, определенных настоящим стандартом, проставляют в соответствии с графой 3 табл. 2. Код дополнительных документов формируют следующим образом: первый знак — буква, означающая вид документа согласно табл. 1, второй знак — цифра или буква, указывающая порядковый номер документа данного вида.

Код документа отделяют от предыдущего обозначения точкой.

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

3.3.4. Номер редакции документа присваивают, начиная со второй в порядке возрастания от 2 до 9, и отделяют от предыдущего значения точкой. Очередной номер редакции присваивают в случаях сохранения (не аннулирования) предыдущей редакции.

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

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

ПРИЛОЖЕНИЕ 1
Справочное

ПОЯСНЕНИЕ ТЕРМИНОВ, ПРИМЕНЯЕМЫХ В НАСТОЯЩЕМ СТАНДАРТЕ

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

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

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

ПРИЛОЖЕНИЕ 2
Рекомендуемое

ПРАВИЛА ОБОЗНАЧЕНИЯ СИСТЕМ И ИХ ЧАСТЕЙ

1. Структура обозначения автоматизированной системы или ее части имеет вид:

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

3. Код классификационной характеристики системы или ее части (подсистемы, комплекса, компонента) присваивают в соответствии с правилами, установленными в отрасли на основе 425 подкласса общесоюзного классификатора продукции и/или общесоюзного классификатора подсистем и комплексов задач АСУ — 1 84 154.

4. Порядковый регистрационный номер системы (части системы) присваивает служба организации разработчика, ответственная за ведения картотеки и учет обозначений. Регистрационные номера присваивают с 001 до 999 по каждому коду регистрационной характеристики.

ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. РАЗРАБОТАН И ВНЕСЕН
Государственным комитетом СССР по стандартам
Министерством приборостроения, средств автоматизации и систем управления СССР

ИСПОЛНИТЕЛИ
И.П. Вахлаков; Я.Г. Виленчик; Н.М. Вицын, канд. техн. наук; Ф.Р. Выдра, канд. техн. наук; С.В. Гаршина; Б.А. Дюков; Л.М. Зайденберг, канд. техн. наук; А.П.

Игошин, канд. техн. наук; Ю.Б. Ирз, канд. техн. наук (руководитель темы); В.Ю. Королев; И.А. Коротеева; Е.С. Кранков, канд. техн. наук; В.И. Махнач, д-р техн. наук; И.С. Митяев; А.М.

Мустафина; Е.И. Некрылов, канд. техн. наук; В.Ф. Попов; Е.Г. Савина; Н.В. Степанчикова; В.К.

Чистов, канд. техн. наук; П.А. Шалаев, канд. техн. наук

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитата СССР по стандартам от 24.03.89 № 664

3. Срок проверки — 1999 г.; периодичность проверки — 10 лет

4. ВЗАМЕН ГОСТ 24.101-80, ГОСТ 24.102-80, РД 50-617-86

5. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

Обозначение НТД, на которую дана ссылка Номер пункта

ГОСТ 2.102-68	1.3, 1.3.3, 2.3
ГОСТ 2.113-75	1.3.4
ГОСТ 2.601-68	1.3.3, 2.3
ГОСТ 19.101-77	1.3, 1.3.2, 2.4
ГОСТ 24.601-86	Вводная часть, 1.1
ГОСТ 34.602-89	1.2

Внесены изменения ¹ 1, (Утверждены и введены в действие Постановлением Государственного комитета СССР по управлению качеством продукции и стандартам от 29.12.90 № 3468, дата введения 01.07.91).

Источник: www.rugost.com

Система менеджмента качества в вопросах и ответах.

18 ноября 2014

Система менеджмента качества в вопросах и ответах.

Директор по качеству «Челябинского тракторного завода – УРАЛТРАК»

Несмотря на солидный возраст концепции менеджмента качества (она появилась в 50-е годы прошлого столетия), в России лишь немногие предприятия сознательно применяют систему менеджмента качества в своей деятельности. Большинство российских руководителей не понимают, о чем идет речь и какую пользу можно получить от СМК. В этом цикле статей мы попытаемся объяснить, что такое СМК и в чем ее отличие от применяющихся в организациях систем управления. В первых трех статьях цикла и мы определили и описали, что такое система менеджмента качества, кто должен заниматься управлением качеством и как выделять и описывать процессы. В этой четвертой части речь пойдет о документировании процессов.

Каким должен быть объем документации?

Объем документации должен быть разумным. Ее разработка должна идти сверху вниз, от процессов — к документам. Процитируем ГОСТ Р ИСО/ТО 10013-2007: «На основе анализа процессов организация должна определить необходимое число документов системы менеджмента качества. Документирование не должно быть самоцелью».

Минимально — это может быть всего 2 документа: «Политика в области качества» и «Руководство по качеству», включающее в себя 6 документированных процедур. Максимально — это могут быть сотни документов.

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

• согласовано и полно;
• необходимо и достаточно;
• кратко и точно;
• быстро и удобно.

Эти принципы описаны в таблице 1.

Таблица 1. Принципы разработки документации СМК.

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

Документация СМК должна разрабатываться централизованно, тогда все процессы будут увязаны в систему. Функциональные подразделения должны участвовать в разработке и согласовывать документ.

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

Необходимо и достаточно

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

Документация должна быть разбита на уровни (процесс, подпроцесс, операция). Уровень детализации и документирования на каждом уровне должен быть разумным (не быть излишним).

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

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

Быстро и удобно

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

Каким должен быть состав документации?

Характер и степень документирования системы менеджмента качества зависят от особенностей организации. В наиболее общем случае производственного предприятия, с учетом изложенных выше принципов разработки документации на взгляд автора необходимо разрабатывать 12 видов документов (таблица 2). Графически структура документов СМК показана на рис. 1.

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

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

Таблица 2. Виды документов СМК.

Наименование

Обязательность применения

Политика в области качества

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

Руководство по качеству

Описывает систему менеджмента качества организации.

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

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

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

Содержит информацию, помогающую выполнить работу наиболее рациональным методом. Например, «Установление целей в области качества».

Рабочая (технологическая, производственная, контрольная) инструкция

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

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

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

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

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

Нормативно -техническая документация

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

зависит от документа

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

Рис. 1. Структура документов СМК.

Кто должен разрабатывать документацию СМК?

Разработку документации лучше поручить службе менеджмента качества, но при обязательном участии функциональных специалистов. Конечно, СМК не может заменить функциональные подразделения с точки зрения содержания документов, но вполне заменит с точки зрения оформления в соответствии с правилами и взаимоувязки документов. Инициатива по разработке документации может принадлежать как структурным подразделениям, так и службе менеджмента качества. Например, подразделение разрабатывает первичный вариант документа, затем он дорабатывается службой менеджмента качества, далее документ согласовывается с заинтересованными подразделениями и наконец, утверждается (как правило, первым руководителем).

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

Кто должен заниматься совершенствованием процессов?

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

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

Иначе подразделения начинают локальную оптимизацию, которую Деминг называл «субоптимизацией» и считал очень вредной. Например, резкое повышение объема продаж может разладить все процессы предприятия; закупка материалов по низкой цене приведет к браку и издержкам в другом процессе. Локальная оптимизация с благими намерениями может быть совершенно невыгодна для процесса в целом. Для этого и нужно централизованное управление улучшениями и изменениями.

Источник: upr.ru

ГОСТ Р 59795-2021 Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов

Текст ГОСТ Р 59795-2021 Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТ Р 59795— 2021

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

КОМПЛЕКС СТАНДАРТОВ НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ

Автоматизированные системы. Требования к содержанию документов

Москва Российский институт стандартизации 2021

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО «ИАВЦ»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 25 октября 2021 г. № 1297-ст

4 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

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

1 Область применения

2 Нормативные ссылки

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

5 Требования к содержанию документов по общесистемным решениям

5.1 Ведомость эскизного (технического) проекта

5.2 Пояснительные записки к эскизному, техническому проектам

5.3 Схема функциональной структуры

5.4 Ведомость покупных изделий

5.5 Описание автоматизируемых функций

5.6 Описание постановки задачи (комплекса задач)

5.7 Локальная смета и локальный сметный расчет

5.10 Проектная оценка надежности системы

5.11 Общее описание системы

5.12 Ведомость эксплуатационных документов

5.13 Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)

5.14 Схема организационной структуры

6 Требования к содержанию документов с решениями по организационному обеспечению

6.1 Описание организационной структуры

6.2 Методика (технология) автоматизированного проектирования

6.3 Технологическая инструкция

6.4 Руководство пользователя

6.5 Описание технологического процесса обработки данных

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

7.1 Схема автоматизации

7.2 Описание комплекса технических средств

7.3 План территориального расположения комплексов АС

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

7.5 Технические задания на разработку специализированных (новых) технических средств

7.6 Задания на разработку строительных, электротехнических, санитарно- технических и других разделов проекта, связанных с созданием системы

7.7 Перечень заданий на разработку специализированных (новых) технических средств

7.8 Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы

7.9 Схема структурная комплекса технических средств

7.10 Схема соединения внешних проводок

7.11 Схема подключения внешних проводок

7.12 Таблица соединений и подключений

7.13 Схема деления системы (структурная)

7.14 Чертеж установки технических средств

7.15 Схема принципиальная

7.16 Спецификация оборудования

7.17 Инструкция по эксплуатации комплекса технических средств

7.18 Ведомость оборудования и материалов

8 Требования к содержанию документов с решениями по информационному обеспечению

8.1 Перечень входных данных

8.2 Перечень выходных данных

8.3 Описание информационного обеспечения системы

8.4 Ведомость машинных носителей информации

8.5 Описание организации информационной базы

8.6 Описание систем классификации и кодирования

8.7 Описание массива информации

8.8 Массив входных данных

8.9 Описание базы данных

9 Требования к содержанию документов с решениями по программному обеспечению

9.1 Описание программного обеспечения

10 Требования к содержанию документов с решениями по математическому обеспечению

10.1 Описание алгоритма (проектной процедуры)

Приложение А (рекомендуемое) Содержание документов, разрабатываемых на предпроектных стадиях

Приложение Б (рекомендуемое) Содержание организационно-распорядительных документов

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

КОМПЛЕКС СТАНДАРТОВ НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ

Автоматизированные системы.

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

Information technology. Set of standards for automated systems.

Automated system. Document content requirements

Дата введения — 2022—04—30

1 Область применения

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

2 Нормативные ссылки

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

ГОСТ Р 2.106 Единая система конструкторской документации. Текстовые документы

ГОСТ Р 2.105 Единая система конструкторской документации Общие требования к текстовым документам

ГОСТ 2.109 Единая система конструкторской документации. Основные требования к чертежам

ГОСТ 7.32 Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления

ГОСТ 19.005 Единая система программной документации. P-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения

ГОСТ 19.701 Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения

ГОСТ 21.110 Система проектной документации для строительства. Спецификация оборудования, изделий и материалов

ГОСТ 24.301 Система технической документации на АСУ. Общие требования к выполнению текстовых документов

ГОСТ 34.201 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем

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

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

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

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

3 Сокращения

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

АСУ ТП — автоматизированная система управления технологическим процессом;

ЕСПД — Единая система программной документации;

ЕСКД — Единая система конструкторской документации;

КТС — комплекс технических средств;

НИР — научно-исследовательская работа;

СПДС — система проектной документации для строительства;

ТЗ на АС — техническое задание на создание автоматизированной системы.

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

4.1 Требования к содержанию документов, разрабатываемых при создании АС, установлены настоящим стандартом, а также соответствующими стандартами ЕСПД, ЕСКД, СПДС и ГОСТ 34.602.

Виды и комплектность документов регламентированы ГОСТ 34.201. Перечень эксплуатационных документов должен быть согласован с заказчиком.

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

4.3 Содержание каждого документа, разрабатываемого при проектировании АС согласно ГОСТ 34.201, определяет разработчик в зависимости от объекта проектирования (системы, подсистемы и т. д.).

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

4.6 Документы, при необходимости, сброшюровывают в книги или тома, к которым составляют описи.

5 Требования к содержанию документов по общесистемным решениям

5.1 Ведомость эскизного (технического) проекта

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

5.1.2 Ведомость заполняют по разделам — частям проекта АС.

5.1.3 Документ следует выполнять по ГОСТ Р 2.106.

Наименования разделов и подразделов записывают в графах «Обозначение» и «Наименование» в виде заголовков и выделяют подчеркиванием.

5.2 Пояснительные записки к эскизному, техническому проектам

5.2.1 Документы должны содержать разделы:

— описание процессов деятельности объекта автоматизации;

— основные технические решения;

— мероприятия по подготовке объекта автоматизации к вводу АС в действие.

5.2.2 В разделе «Общие положения» приводят:

— наименование проектируемой АС и наименования документов, их номера и даты утверждения, на основании которых ведут проектирование АС;

— перечень организаций, участвующих в разработке АС, сроки выполнения стадий;

— цели, назначение и области использования АС;

— подтверждение соответствия проектных решений действующим нормам и правилам техники безопасности, пожаро- и взрывобезопасности и т. п.;

— сведения об использованных при проектировании нормативно-технических документах;

— сведения о НИР, передовом опыте, изобретениях, использованных при разработке проекта;

— очередность создания АС и объем каждой очереди.

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

5.2.4 В разделе «Основные технические решения» приводят:

— решения по структуре АС и ее подсистем, по взаимодействию подсистем, по связям между компонентами АС;

— решения по взаимодействию АС со смежными системами и обеспечению совместимости;

— решения по режимам функционирования, диагностированию работы АС;

— решения по численности, квалификации и функциям персонала АС, режимам его работы;

— сведения об обеспечении заданных в ТЗ на АС потребительских характеристик системы (подсистем), определяющих ее качество;

— состав функций, комплексов задач (задач), реализуемых АС (подсистемой);

— решения по комплексу технических средств, его размещению на объекте;

— решения по составу информации, способам ее организации, входным и выходным документам и сообщениям;

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

В разделе в виде иллюстраций приводят другие документы, которые допускается включать по ГОСТ 34.201.

5.2.5 В разделе «Мероприятия по подготовке объекта автоматизации к вводу АС в действие» приводят:

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

— мероприятия по обучению и проверке квалификации персонала;

— мероприятия по созданию необходимых подразделений и рабочих мест;

— мероприятия по изменению объекта автоматизации;

— другие мероприятия, исходящие из специфических особенностей создаваемой АС.

5.3 Схема функциональной структуры

Документ «Схема функциональной структуры» должен содержать:

— элементы функциональной структуры АС (подсистемы АС); автоматизированные функции и (или) задачи (комплексы задач); совокупности действий (операций), процедур;

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

— детализированные схемы частей функциональной структуры (при необходимости).

5.4 Ведомость покупных изделий

Документ «Ведомость покупных изделий» оформляется в соответствии с ГОСТ Р 2.106.

5.5 Описание автоматизируемых функций

5.5.1 Документ «Описание автоматизируемых функций» должен содержать разделы:

— цели АС и автоматизируемые функции;

— характеристика функциональной структуры;

— типовые решения (при наличии).

5.5.2 В разделе «Исходные данные» приводят:

— перечень исходных материалов и документов, использованных при разработке функциональной части проекта АС;

— особенности объекта автоматизации, влияющие на проектные решения по автоматизируемым функциям;

— данные о других АС, взаимосвязанных с разрабатываемой АС, и сведения об информации взаимообмена;

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

5.5.3 В разделе «Цели АС и автоматизируемые функции» приводят описание автоматизируемых функций, направленных на достижение установленных целей.

5.5.4 В разделе «Характеристика функциональной структуры» приводят:

— перечень подсистем АС с указанием функций и (или) задач, реализуемых в каждой подсистеме;

— описание процесса выполнения функций (при необходимости);

— необходимые пояснения к разделению автоматизируемых функций на действия (операции), выполняемые техническими средствами и человеком;

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

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

5.6 Описание постановки задачи (комплекса задач)

5.6.1 Документ «Описание постановки задачи (комплекса задач)» должен содержать разделы:

— характеристики задачи (комплекса задач);

5.6.2 В разделе «Характеристики задачи (комплекса задач)» приводят:

— назначение задачи (комплекса задач);

— перечень объектов (технологических объектов, подразделений предприятия и т. п.), при автоматизации которых решается задача (комплекс задач);

— периодичность и продолжительность решения задач (комплекса задач);

— условия, при которых прекращается решение задачи (комплекса задач) автоматизированным способом (при необходимости);

— связи данной задачи (комплекса задач) с другими задачами (комплексами задач) АС;

— должности лиц и (или) наименования подразделений, определяющих условия и временные характеристики конкретного решения задачи (комплекса задач), если они не определены общим алгоритмом функционирования АС;

— распределение действий между персоналом и техническими средствами при возникновении различных ситуаций при решении задачи (комплекса задач).

5.6.3 В разделе «Входная информация» приводят:

— перечень и описание входных сообщений (идентификатор, форму представления, сроки и частоту поступления, допустимые форматы данных);

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

5.6.3.1 В описании по каждой структурной единице информации входных сообщений следует указывать:

— идентификатор входного сообщения, содержащего структурную единицу информации;

— требуемую точность ее числового значения (при необходимости);

— допустимый формат данных;

— источник информации (документ, устройство, информационная база и т. д.);

— идентификатор источника информации.

5.6.4 В разделе «Выходная информация» приводят:

— перечень и описание выходных сообщений;

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

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

— форму представления сообщения (документ, сигнал) и требования к ней;

— сроки выдачи и допустимое время задержки;

— допустимые форматы данных;

— получателей и назначение выходной информации.

5.6.4.2 В описании по каждой структурной единице информации выходных сообщений следует указывать:

— идентификатор выходного сообщения, содержащего структурную единицу информации;

— требования к точности и надежности вычисления (при необходимости);

— допустимый формат данных.

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

5.7 Локальная смета и локальный сметный расчет

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

Примечание — При изменении сметной стоимости работ и объектов по сравнению с запланированной уточняют экономическую эффективность АС.

5.8 Паспорт

5.8.1 Документ «Паспорт» должен содержать разделы:

— общие сведения об АС;

— основные характеристики АС;

— свидетельство (акт) о приемке;

— гарантии изготовителя (поставщика);

— сведения о рекламациях.

5.8.2 В разделе «Общие сведения об АС» приводят наименование АС, ее обозначение, присвоенное разработчиком, наименование поставщика и другие сведения об АС в целом.

5.8.3 В разделе «Основные характеристики АС» приводят:

— сведения о составе функций, реализуемых АС, в том числе измерительных и управляющих;

— описание принципа функционирования АС;

— общий регламент и режимы функционирования АС и сведения о возможности изменения режимов ее работы;

— сведения о совместимости АС с другими АС.

5.8.4 В разделе «Комплектность» приводят все непосредственно входящие в состав АС комплексы технических и программных средств, отдельные средства, в том числе носители данных и эксплуатационные документы.

5.8.5 В разделе «Свидетельство (акт) о приемке» приводят дату подписания акта о приемке АС в постоянную эксплуатацию и фамилии лиц, подписавших акт.

5.8.6 В разделе «Гарантии изготовителя (поставщика)» приводят сроки гарантии на АС в целом и ее отдельные составные части, если эти сроки не совпадают со сроками гарантии на АС в целом.

Источник: allgosts.ru

Научная электронная библиотека

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

Эту документацию можно разбить на две группы:

 документы управления разработкой ПС.

 документы, входящие в состав ПС.

Документы управления разработкой ПС (software process documentation) управляют и протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков и менеджерами ПС (software managers) — лицами, управляющими разработкой ПС. Эти документы могут быть следующих типов:

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

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

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

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

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

Документы, входящие в состав ПС (software product documen­ta­tion), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами). Во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС.

Эти документы образуют два комплекта с разным назначением:

 пользовательская документация ПС (П-документация).

 документация по сопровождению ПС (С-документация).

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

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

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

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

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

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

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

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

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

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

 руководство по управлению ПС. Предназначено для администраторов ПС. Оно должно описывать сообщения, генерируемые, когда ПС взаимодействует с другими системами, и как должен реагировать администратор на эти сообщения. Кроме того, если ПС использует системную аппаратуру, этот документ может объяснять, как сопровождать эту аппаратуру.

Документация по сопровождению программных средств

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроено (сконструировано), и модернизацию его программ. Сопровождение — это продолжающаяся разработка.

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

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

 документацию, определяющую строение программ и структур данных ПС и технологию их разработки;

 документацию, помогающую вносить изменения в ПС.

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

 внешнее описание ПС (Requirements document);

 описание архитектуры ПС (description of the system architect­ture), включая внешнюю спецификацию каждой ее программы (подсистемы).

 для каждой программы ПС описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;

 для каждого модуля спецификацию и описание его строения (design description);

 тексты модулей на выбранном языке программирования (program source code listings);

 документы установления достоверности ПС (validation docu­ments), описывающие, как устанавливалась достоверность каждой программы ПС, и как информация об установлении достоверности связывалась с требованиями к ПС.

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

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

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

Создание и использование пакета прикладных программ (ППП) от формирования концепции и требований к первой версии до изъятия его из эксплуатации со­провождается документированием объектов и процессов жизненно­го цикла ППП.

По своему назначению документацию ППП можно классифицировать как:

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

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

 документацию тестирования компонентов и комплексов про­грамм;

 документацию испытаний ППП;

 документацию сопровождения и управления конфигурацией ППП.В состав проектной документации входят:

 отчет по обследованию предметной области, для которой предназначен разрабатываемый ППП, с описанием комплекса за­дач;

 описание концепции проектирования;

 техническое задание на проектирование;

 спецификации эскизного и технического проекта;

 документация на разработанные программные модули пакета;

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

В состав документации тестирования входят:

 исходные данные для проведения тестирования (методы тестирования, тестовые наборы, эталонные значения, реальные ресурсы тестирования — временные, аппаратно-программные, люд­ские, критерии полноты и качества тестирования);

 программа (сценарии) тестирования;

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

 описание методов и методик испытаний;

 акт завершения работ;

 акт приемки ППП в эксплуатацию.В состав документации сопровождения управления конфигу­рацией входят:

 отчеты пользователей о выявленных дефектах и предло­жения по корректировке программ;

 журнал выявленных дефектов и предложений по совершенствованию и развитию версии ППП;

 журнал подготовленных и утвержденных корректировок, а также реализованных изменений в новой версии пакета;

 отчет о результатах эксплуатации снятой с сопровождения версии пакета;

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

 паспорт на программное средство, где содержатся общие сведения о ППП, его основные характеристики, комплектность, акт о приемке, гарантии изготовителя (поставщика);

 общее описание информационной системы (ИС), в составе которой будет использоваться ППП (назначение и описание ИС, описание взаимосвязей ППП с другими составляющими ИС);

 руководство администратора программного средства, кото­рое регламентирует функции администрирования, процедуры по инсталляции и подготовке ППП к эксплуатации, порядок и средства ведения базы данных и восстановления ин­формации при сбоях;

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

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

В процессе сопровождения в програм­мы вносятся различные изменения:

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

 модернизация — расширение функциональных возможно­стей или улучшение качества решения отдельных задач в соответ­ствии с новым или дополнительным техническим заданием на ППП;

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

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

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

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

Рис. 11. Кривая продаж программного продукта

Сопровождение коммерческого программного продукта произ­водится в форме устранения обнаруженных ошибок путем выпуска программных «заплаток» — патчей. Эти программы выкладываются на Web-сайте разработчика и предлагаются пользователям. Об­новление обычно происходит в автоматическом режиме при загруз­ке патча. Кроме этого, ведется и модернизация программ.

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

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

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

Существуют другие варианты легального распространения программного продукта, кроме коммерческого, которые появились с использованием глобальных или региональных сетей:freeware — бесплатно распространяемые и поддерживаемые самим пользователем программы;shareware — условно-бесплатные программы. Ими можно поль­зоваться бесплатно некоторое время, а при условиях регулярного использования требуется внести определен­ную сумму разработчику программы;demo-версии (демонстрационная и пробная програм­мы).

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

Пробная версия обычно полнофункциональна, но остается работоспособной лишь в течение небольшого промежутка времени, достаточного для ознакомления с ней (несколько дней или недель, либо определенное количество запусков). После этого работоспособность программы блокируется или же она превраща­ется в демонстрационную версию;ad ware — программа, показывающая рекламу. Бесплатная про­грамма такого типа, как правило, сохраняет все функции коммерче­ской версии и остается работоспособной в течение неограниченно­го времени, однако она постоянно показывает пользователю рекламные окна — баннеры. Чтобы «отключить» назойливую рек­ламу, необходимо оплатить коммерческую версию;OEM (Original Equipment Manufacturer) — программы, постав­ляемые с купленной компьютерной техникой по OEM-контракту ме­жду фирмой-разработчиком и продавцом ПК (или другого hardware). Их стоимость меньше, чем стоимость retail-программ, поставляе­мых в розницу в «коробочном» исполнении.

Источник: monographies.ru

Документальное оформление бизнес-процессов в проектах по автоматизации

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

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

Структура проектной документации проекта 1С и место бизнес-процессов в ней

Для начала приведу общие принципы разработки документации

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

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

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

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

Либо на бизнес-процессы – изначально оторванные или частично оторванные от конечного продукта процессы компании.

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

Подходы к декомпозиции бизнес-процессов

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

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

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

Самый первый уровень – это группы процессов. Здесь могут быть:

либо группы процессов, ориентированные на конкретные виды деятельности;

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

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

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

Нотации, которые я считаю наиболее эффективными при описании бизнес-процессов.

Для описания процессов уровня 3 и ниже (для описания подпроцессов конкретных бизнес-функций) я считаю наиболее подходящими нотации BPMN или EPC. Лично я предпочитаю использовать для этой цели BPMN, потому что он достаточно информативный и понятный – его и бизнес понимает, и в принципе, в нем достаточно насыщена логика, чтобы подробно описать бизнес-процесс даже неопытному специалисту. Но это исключительно мое мнение – я знаю, что есть идеологи других нотаций.

А нотацию IDEF0, я считаю, удобно использовать для верхнеуровневых процессов – для уровня 1 и 2, потому что в том же BPMN не получится отрисовать всю сложность взаимосвязей этих групп процессов, либо придется ее как-то избыточно детализировать, что не приветствуется. А в IDEF можно сделать много стрелок.

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

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

На слайде показан пример, как мы описываем декомпозицию процессов.

А здесь приведена безличная схема описания бизнес-процесса в BPMN.

Подходы к описанию бизнес-процесса

Поговорим про информацию, которая детализирует пояснение к схеме.

Обязательно выделяйте атрибуты бизнес-процесса.

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

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

Владелец – это какое-то подразделение или даже какая-то роль, если вы описываете бизнес-процесс для конкретной компании.

Старт – это событие или группа событий, в результате которых процесс запускается.

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

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

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

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

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

Также у шага есть атрибуты:

Описание бизнес-действия;

Исполнитель – роль, выполняющая действие;

Входящая информация;

Исходящая информация;

Хозяйственная операция;

Бизнес-требование;

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

Объекты системы;

Действие в системе;

Требуемая модификация и т.д.

Это – те атрибуты, с которыми мы работаем. Причем, здесь не весь список.

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

На слайде я привел пример таблицы с описанием бизнес-процесса в том виде, как мы ее заполняем в ТЗ. Причем, здесь видны не все, а только некоторые колонки.

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

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

Что дает описание бизнес-процесса

Что дает описанный подход к описанию бизнес-процессов?

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

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

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

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

Перечень требуемых модификаций.

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

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

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе «Бизнес-аналитик. Роль в команде, компетенции, инструментарий». Больше статей можно прочитать здесь.

Источник: infostart.ru