Алгоритм оценки и редактирования проекта документа
Разработанный и согласованный в установленном порядке проект документа поступает в приемную, где секретарь осуществляет его подготовку к подписанию руководителем, проводит нормоконтроль и, в случае необходимости, редактирование. Несоответствующий нормам проект документа следует вернуть на доработку исполнителю.
Рекомендуем использовать алгоритм оценки и редактирования проекта документа (Алгоритм). Далее рассмотрим, что нужно проверить и учесть на каждом этапе.
Этап 1. Как ознакомиться с проектом документа?
Редактирование начинается с общего ознакомления с текстом проекта документа. Это очень важный этап. Никогда не пропускайте его и не приступайте к редактированию по ходу первого прочтения. Секретарю важно прочитать текст от начала и до конца, чтобы иметь целостное восприятие. На следующих этапах редактирования это поможет оценить композицию текста, обнаружить противоречия, логические ошибки и т.д.
Требования стандартов к программной документации
Как
уже было отмечено, качество программного
обеспечения, наряду с другими факторами,
определяется полнотой и качеством
пакета документов, сопровождающих ПО.
К программным документам относятся
документы, содержащие сведения,
необходимые для разработки, изготовления,
сопровождения программ и эксплуатации.
19-я
система стандартов (Единая система
программной документации — ЕСПД)
устанавливает следующие виды программной
документации.
1.
Спецификация. Состав программы и
документация на нее.
2.
Ведомость держателей подлинников.
Перечень предприятий, на которых хранят
подлинники программных документов.
3.
Текст программы. Запись программы с
необходимыми комментариями.
4.
Описание программы. Сведения о логической
структуре и функционировании программ.
5.
Программа и методика испытаний.
Требования, подлежащие проверке при
испытании программы, а также порядок и
методы контроля.
6.
Техническое задание. Назначение и
область применения программы, технические,
технико-экономические и специальные
требования, предъявляемые к программе,
необходимые стадии и сроки разработки,
виды испытаний.
7.
Пояснительная записка. Схема алгоритма,
общее описание алгоритма и функционирования
программы, а также обоснование принятых
технических и технико-экономических
решений.
8.
Эксплуатационные документы. Сведения
для обеспечения функционирования и
эксплуатации программы. Перечень
эксплуатационных документов представлен
в таблице 3.1.
Полный
пакет документов, разрабатываемых при
создание автоматизированной системы
и, в частности, программного обеспечения,
установленный в отечественных стандартах,
включает:
ГОСТ
34.602-89 — техническое задание на создание
АС;
ГОСТ
34.201-90 – виды и комплектность документов;
РД
50-34.698-90 — пояснительная записка, схема
функциональной структуры, общее описание
системы, описание постановки задачи,
описание информационного обеспечения
системы, описание организации
информационной базы, перечень входных
сигналов и данных, перечень выходных
сигналов/документов, описание программного
обеспечения;
ГОСТ
19.201-78 – техническое задание;
ГОСТ
19.402-78 – описание программы;
ГОСТ
19.404-79 – пояснительная записка;
ГОСТ
19.301-79 – программа и методика испытаний.
Согласно
ГОСТ 19.201-78 техническое задание на
разработку ПО должно включать следующие
разделы:
требования
к программной документации;
стадии
и этапы разработки;
порядок
контроля и приемки;
В
зависимости от особенностей разрабатываемого
ПО стандарт допускает уточнение
содержания разделов, введение новых
разделов или их объединение.
В
разделе “Введение” указывается
наименование, краткая характеристика
области применения ПО.
В
разделе “Основания для разработки”
указывается:
документ
(документы), на основание которых ведется
разработка;
организация,
утвердившая документ, и дата утверждения;
наименование
(условное обозначение) темы разработки.
В
разделе “Назначение разработки” должно
быть указано функциональное и
эксплуатационное назначение ПО.
В
раздел “Требования к программе”
включаются следующие подразделы.
1.
Требования к функциональным характеристикам,
в котором указываются требования к
составу выполняемых функций, организации
входных и выходных данных, временным
характеристикам и т.д. В данном подразделе
описывается поведение ПО с точки зрения
соотношения входа и выхода, без
конкретизации его внутренней структуры.
Описание выполняемых функций делается
либо в текстовом виде, либо на специальном
графическом языке. Описание входа
заключается в фиксации синтаксиса и
семантики всех входных данных. Описание
выхода должно содержать точное описание
всех возможных выходных данных в тесной
взаимосвязи с входными.
2.
Требования к надежности, где указываются
требования к обеспечению надежного
функционирования ПО, его защите (контроль
входной и выходной информации, описание
последствий отказов ПО и т.д.).
3.
Условия эксплуатации, в котором должны
быть указаны характеристики операционной
среды, вид обслуживания, необходимое
количество и квалификация персонала и
др., а также допустимые параметры
окружающей среды (относительная
влажность, температура и др.).
4.
Требования к составу и параметрам
технических средств – необходимый
состав технических средств (конфигурация)
с указанием их основных технических
характеристик.
5.
Требования к информационной и программной
совместимости, в котором указываются
требования к информационным структурам
на входе и выходе и методам решения,
исходным кодам, языкам программирования
и программным средствам, используемым
ПО. Кроме того, могут указываться
протоколы межмашинного сетевого обмена
данными, стандарты протоколов формализации
данных и управления терминалами,
стандарты и форматы сообщений, протоколы
транзакций, протоколы запросов данных,
стандарты представления данных,
требования к СУБД и операционным
системам.
6.
Требования к маркировке и упаковке.
7.
Требования к транспортированию и
хранению.
В
разделе “Требования к программной
документации” должен быть указан
предварительный состав программной
документации и, при необходимости,
специальные требования к ней.
В
разделе “Технико-экономические
показатели” указывается: ориентировочная
экономическая эффективность, предполагаемая
годовая потребность, экономические
преимущества разработки по сравнению
с лучшими отечественными и зарубежными
образцами или аналогами.
В
разделе “Стадии и этапы разработки”
устанавливают необходимые стадии
разработки, этапы и содержание работ
(перечень документов, которые должны
быть разработаны, согласованы и
утверждены), а также сроки разработки
и исполнителей.
В
разделе “Порядок контроля и приемки”
должны быть указаны виды испытаний и
общие требования к приемке ПО. Здесь
фиксируют важнейшие характеристики ПО
в некоторой количественной или иной
достаточно простой форме, с тем, чтобы
можно было установить степень соответствия
готового ПО принятым техническим
условиям.
В
приложениях к техническому заданию при
необходимости приводят:
перечень
научно-исследовательских и других
работ, обосновывающих разработку;
схемы
алгоритмов, таблицы, описания, обоснования,
расчеты и другие документы, которые
могут быть использованы при разработке;
Техническое
задание на создание АС разрабатывается
в соответствии с ГОСТ 34.602-89. Данный
стандарт устанавливает следующие
разделы, включаемые в техническое
задание.
1.
Общие сведения, включающие полное
наименование системы, условное обозначение
системы, шифр темы (шифр (номер) договора),
наименование предприятий разработчика
и заказчика системы и их реквизиты,
перечень документов, на основании
которых создается система, плановые
сроки начала и окончания работ по
созданию АС, сведения об источниках и
порядке финансирования работ.
2.
Назначение и цели создания АС, в котором
указывают назначение системы и цели ее
создания.
3.
Характеристика объекта автоматизации.
4.
Требования к системе. Данный раздел
состоит из следующих подразделов.
а)
Требования к системе в целом. Здесь
указывают перечень подсистем, их
назначение и основные характеристики,
требования к числу уровней иерархии и
степени централизации системы, требования
к способам и средствам связи для
информационного обмена между компонентами
системы, требования к характеристикам
взаимосвязей АС со смежными системами,
требования к ее совместимости, способы
обмена информации. Кроме того, требования
к численности и квалификации персонала
и режиму его работы, к надежности,
безопасности и т.д.
б)
Требования к функциям.
в)
Требования к видам обеспечения
(математическому, информационному,
лингвистическому программному ,
техническому организационному и т.д.).
5.
Состав и содержание работ по созданию
(развитию) АС.
6.
Порядок контроля и приемки системы.
7.
Требования к составу и содержанию работ
по подготовке объекта автоматизации к
вводу в действие.
8.
Требования к документированию.
Содержание
документов, разрабатываемых на
предпроектных стадиях (“Формирование
требований к АС” и “Разработка концепции
АС”), приведено в рекомендуемом приложении
к РД 50-34.698-90. На первой стадии разрабатывается
отчет (согласно ГОСТ 7.32) и заявка на
разработку АС. На второй – отчет согласно
ГОСТ 7.32.
Содержание
организационно-распорядительных
документов установлено также в
рекомендуемом приложении. К
организационно-распорядительным
документам относятся:
акты
приемки в опытную и промышленную
эксплуатацию;
приказы
о проведении работ и составе приемочной
комиссии;
протоколы
испытаний и согласования.
Документ
“Описание
программного обеспечения”
содержит вводную часть и разделы:
структура ПО, функции частей ПО, методы
и средства разработки ПО, операционная
система, средства, расширяющие возможности
операционной системы.
Во
вводной части приводят основные сведения
о техническом, информационном и других
видах обеспечения АС, необходимые для
разработки ПО или ссылку на соответствующие
документы проекта АС.
В
разделе “Структура ПО” приводят
перечень частей ПО с указанием их
взаимосвязей и обоснованием выделения
каждой из них. В разделе “Функции частей
ПО” приводят назначение и описание
основных функций для каждой части ПО.
В
разделе “Методы и средства разработки
ПО” приводят перечень методов
программирования и средства разработки
ПО АС с указанием частей ПО, при разработке
которых следует использовать
соответствующие средства и методы.
В
разделе “Операционная система”
указывают следующее.
1.
Наименование, обозначение и краткую
характеристику выбранной операционной
системы и ее версии, в рамках которой
будут выполнять разрабатываемые
программы, с обоснованием выбора и
указанием источников, где дано подробное
описание выбранной версии.
2.
Наименование руководства, в соответствие
с которым должна осуществляться генерация
выбранного варианта операционной
системы.
3.
Требования к варианту генерации выбранной
версии операционной системы.
Раздел
“Средства, расширяющие возможности
операционной системы” содержит
подразделы, в которых для каждого
используемого средства, расширяющего
возможности операционной системы,
указывают:
наименование,
обозначение и краткую характеристику
средства, с обоснованием необходимости
его применения и указанием источников,
где дано подробное описание выбранного
средства;
наименование
руководства, в соответствие с которым
следует настраивать используемое
средство на конкретное применение;
требования
к настройке используемого средства.
“Пояснительная
записка к эскизному (техническому)
проекту”
содержит следующие разделы (согласно
РД 50-34.698-90): общие положения; описание
процесса деятельности; основные
технические решения; мероприятия по
подготовке объекта автоматизации к
вводу системы в действие.
В
разделе “Общие положения” приводят:
наименование
проектируемой АС и наименование
документов, их номера и дату утверждения,
на основании которых ведут проектирование
АС;
перечень
организаций, участвующих в разработке
системы, сроки выполнения стадий;
цели,
назначение и область использования АС;
подтверждение
соответствия проектных решений
действующим нормам и правилам техники
безопасности и т.п.;
сведения
об использованных при проектирование
нормативно-технических документах;
сведения
о НИР, передовом опыте, изобретениях,
использованных при разработке проекта.
В
разделе “Описание процесса деятельности”
отражают состав процедур (операций) с
учетом обеспечения взаимосвязи и
совместимости процессов автоматизированной
и неавтоматизированной деятельности,
формируют требования к организации
работ в условиях функционирования АС.
В
разделе “Основные технические решения”
приводят:
решения
по структуре системы, подсистем, средствам
и способам связи для информационного
обмена между компонентами системы,
подсистем;
решения
по взаимосвязям АС со смежными системами,
обеспечению их совместимости;
решения
по режимам функционирования,
диагностированию работы АС;
решения
по численности, квалификации и функциям
персонала АС, режимам его работы, порядку
взаимодействия;
сведения
об обеспечении заданных в техническом
задании потребительских характеристик
системы (подсистем), определяющих ее
качество;
состав
функций, комплексов задач, реализуемых
системой (подсистемой);
решения
по комплексу технических средств, его
размещению на объекте;
решения
по составу информации, объему, способам
ее организации, видам машинных носителей,
входным и выходным документам и
сообщениям, последовательности обработки
информации и другим компонентам;
решения
по составу программных средств, языкам
деятельности, алгоритмам процедур и
операций и методам их реализации.
В
разделе приводят в виде иллюстраций
другие документы, которые допускается
включать по ГОСТ 34.201.
В
разделе “Мероприятия по подготовке
объекта автоматизации к вводу системы
в действие” приводят:
мероприятия
по приведению информации к виду,
пригодному для обработки на ЭВМ;
мероприятия
по обучению и проверке квалификации
персонала;
мероприятия
по созданию необходимых подразделений
и рабочих мест;
мероприятия
по изменению объекта автоматизации;
другие
мероприятия, исходящие из специфических
особенностей создаваемых АС.
Рассмотрим
содержание ряда документов, определенных
в стандарте DO–178B. Некоторые документы,
именуемые в данном стандарте как “данные
жизненного цикла ПО”, уже рассматривались
нами в разделе 2.
В
DO–178B определено, что данные жизненного
цикла могут принадлежать к одной из
двух категорий: Категории Управления
1 и Категории Управления 2. Эти категории
связаны с элементами управления
конфигурацией. Данное разделение
позволяет иметь средства управления
затратами на разработку там, где может
применяться менее строгий контроль без
снижения степени защищенности данных.
В приложении А к документу DO–178B приведены
минимальные категории управления,
назначенному каждому виду данных и их
вариации в зависимости от уровня ПО (А,
В, С, D, Е). Ниже, в таблице 3.3, представлены
некоторые фрагменты целей этапов
жизненного цикла и их выходы – данные
жизненного цикла.
Документ
DO–178B устанавливает, что приложение А
не предназначено для представления
всех данных, необходимых для создания
ПО, и не предусматривает какого-либо
определенного способа хранения этих
данных или их организации внутри
структур хранения. В дополнении к
указанным документам могут вырабатываться
другие, необходимые для сертификации
ПО.
Характеристики
данных жизненного цикла ПО следующие:
непротиворечивость:
информация непротиворечива, если она
записана в терминах, допускающих
единственное толкование и дополненная,
по необходимости, определениями;
проверяемость:
информация проверяема, если она может
быть проконтролирована на предмет
корректности;
состоятельность;
информация состоятельна, если внутри
нее нет конфликтов;
модифицируемость:
информация модифицируема, если она
структурирована и стилизована таким
образом, что вносимые изменения
полноценны, непротиворечивы и корректны;
трассируемость:
информация трассируема, если могут быть
определены источники ее компонентов;
форма;
форма должна обеспечить возможность
эффективно получать доступ к данным
жизненного цикла По в течение всего
срока службы системы;
управление;
если предназначены для использования
с этой целью, то данные должны быть
определены в плане ПО, который
регламентирует этап, для которого
вырабатываются эти данные.
Дадим
краткую характеристику основных данных
жизненного цикла ПО.
План
программных аспектов сертификации
– первичное средство из используемых
службами сертификации для определения,
предлагает ли разработчик такой жизненный
цикл ПО, который удовлетворяет уровню
разрабатываемого ПО. Данный план должен
включать следующие разделы.
1.
Обзор системы. Этот раздел содержит
обзор системы, включая описание ее
функций и их распределение между
аппаратной и программной частями,
архитектуры, программно-аппаратных
интерфейсов, возможностей по обеспечению
безопасности и т.д.
2.
Обзор ПО. Здесь коротко описывают функции
ПО с акцентом на предлагаемый уровень
концепции безопасности.
3.
Аспекты сертификации. Этот раздел
содержит сводку базиса сертификации,
включая средства обеспечения соответствия
по отношению к программным аспектам
сертификации. Здесь также устанавливается
предлагаемый уровень ПО и приводятся
выводы этапа оценки безопасности
системы, включая потенциальную возможность
работы ПО в неблагоприятных условиях.
4.
Жизненный цикл ПО. В данном разделе
описан используемый жизненный цикл и
приводятся резюме по каждому его этапу
и подэтапу, для которых детальная
информация определяется в соответствующих
планах на разработку ПО. Резюме определяет,
какие цели каждого этапа и подэтапа ЖЦ
ПО должны быть достигнуты, вовлекаемые
структуры для их достижения и т.д.
5.
Данные жизненного цикла ПО. Этот раздел
определяет данные, которые будут
выработаны и управляемы подэтапами ЖЦ
ПО. Здесь также описывается отношение
данных друг к другу и другим данным,
определяющим систему, данные, требуемые
для сертификации, форма данных и т.д.
6.
Планировка. Этот раздел описывает
средства, которые будут использованы
разработчиком для предоставления
отчетности по деятельности в течение
жизненного цикла ПО при сертификации.
7.
Дополнительные аспекты. Здесь приводятся
специфические возможности, которые
могут повлиять на этап сертификации:
например, альтернативные методы
обеспечения соответствия, оценка
качества инструментальных средств,
ранее разработанное ПО и т.д.
План
оценки качества ПО.
Устанавливает используемые методы для
достижения целей этапа оценки качества
ПО (ОКПО). План ОКПО может включать
описание методов улучшения и прогрессивного
управления этапом и может состоять из
следующих разделов.
1.
Среда. Описание среды оценки качества
ПО, включая структуру, организационные
ответственности и интерфейсы, стандарты,
процедуры, средства, методы и метрики.
2.
Полномочия. Характеристика полномочий,
ответственности и независимости оценки
качества ПО.
3.
Методы. Методы оценки качества ПО,
которые должны использоваться для
каждого подэтапа жизненного цикла ПО
на всем его протяжении, включая:
методы
ОКПО, такие, как обзоры, ведение протоколов,
отчеты, проверки и наблюдение за этапами
ЖЦ ПО;
методы,
относящиеся к оповещению о проблемах
и их исправлению;
методы
описания проверки ПО.
4.
Промежуточный критерий. Устанавливает
промежуточный критерий для перехода к
этапу оценки качества ПО.
5.
Временные требования. Временные
требования методик этапа ОКПО по
отношению к методикам подэтапов ЖЦ ПО.
6.
Результаты оценки качества ПО. Описание
результатов, выработанных этапом оценки
качества ПО.
7.
Управление поставщиками. Описание
средств оценки соответствия действий
поставщиков нижнего уровня плану оценки
качества ПО.
Документ
“Требования
к ПО”
определяет требования высокого уровня,
включая и производные требования, если
это необходимо. Этот документ должен
включать следующее (но не ограничиваться
этим).
1.
Описание приведения системных требований
к программным, с особым акцентом на
требования безопасности и потенциальные
условия возникновения сбойных ситуаций.
2.
Функциональные и операционные требования
для каждого режима работы.
3.
Критерии функционирования, например,
точность.
4.
Временные требования и ограничения.
5.
Ограничения по размеру памяти.
6.
Программные и аппаратные интерфейсы,
например, протоколы обмена, форматы
данных, частота входных и выходных
сигналов.
7.
Требования на обнаружение сбоев и
мониторинг за безопасностью
функционирования.
8.
Требования к расчленению ПО на отдельные
компоненты и на их взаимодействие друг
с другом (например, при реализации в
виде распределенной системы).
Таким
образом, хотя стандарт DO – 178B и не
устанавливает явно процессы документирования
в своем жизненном цикле, ясно видно, что
документации в нем уделено большое
внимание.
Документ
“Соглашение о требованиях” должен
содержать первое письменное соглашение
между заказчиком и разработчиком о том,
что будет сделано, и что не будет делаться
при разработке и выпуске программного
обеспечения. В отличие от него спецификация
предполагает наличие более точных и
исчерпывающих формулировок и определений.
При этом, первые два документа содержат
информацию о том, что представляет собой
ПО; а третий должен объяснять, как ПО
устроено и как достигаются установленные
для него цели и требования. Все документы
имеют схожую структуру для облегчения
контроля над проектом, а также для
обеспечения прослеживаемости всех
технических решений от требований до
их реализации. По мере продвижения
проекта разделы документа либо просто
копируются в соответствующие разделы
следующего создаваемого документа,
либо расширяются описаниями технических
решений текущего этапа.
Ниже
приведена общая структура документа
“Внешняя спецификация”, с развернутыми
комментариями в тех пунктах, которые
касаются технической стороны дела
(документ также включает экономические,
управленческие и другие аспекты, которые
не рассматриваются здесь):
1.
ОПИСАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ
1.1.
Наименование и шифры ПО (полное
наименование, сокращенные наименования,
шифры ПО и проекта).
1.2.
Краткое описание ПО (включая сведения
об авторском праве, иерархию документов,
с указанием документов вышестоящих
уровней).
1.3.
Результирующие компоненты ПО (оформляется
в виде таблицы или другой формы и включает
в себя, перечень спецификаций, другой
документации и компонентов программного
обеспечения).
Этот
раздел содержит причины выпуска ПО с
указанием различного типа заявок, планов
и т.п. и носит полностью управленческий
характер.
3.1.
Соглашения относительно представления
материала.
3.1.1.
Обозначения (определяются все обозначения,
используемые в требованиях: например,
если применяются индексы, то дается
пример их использования и определяется
принцип индексации).
3.1.2.
Терминология (особенно специфическая
для данного изделия).
3.1.3.
Синтаксис (приводятся, если необходимо,
синтаксические правила для дальнейшего
описания требований).
3.2.
Генерируемое программное обеспечение
(классифицируется как вспомогательное
и порождаемое описываемым изделием).
3.3.
Системное программное обеспечение (все
остальное ПО, включая ОС, утилиты, пакеты
прикладных программ, которое
классифицируется как основное, поскольку
оно “генерирует” ПО предыдущего
пункта).
Примечание.
Причина такой расстановки пунктов
состоит в том, что при правильном
проектировании сверху вниз генерируемое
программное обеспечение является
основной целью проектирования и должно
быть описано раньше, чем его генератор.
Другими словами, структура генерируемых
программ должна определять структуру
генератора, а не наоборот. Если все ПО
является основным, то в п.3.2. делается
пометка “не используется” и опускаются
все его подпункты. Структура подпунктов
п.п. 3.2 и 3.3 полностью дублируется и далее
для простоты используется нумерация
только п.п. 3.3.
3.3.n.
Общие характеристики функции “n”. Если
технически затруднительно и неестественно
рассматривать ПО как один большой
функциональный модуль, то следует
привести его функциональную декомпозицию,
показав связи между функциями
(функциональными модулями) и присвоив
каждой функции некоторое уникальное
имя “n”. Затем для каждой функции
отводится подраздел раздела 3.3 (т.е.
3.3.1, 3.3.2 и т.д.), в заглавии которого
используется слово “функция” с
последующим именем функционального
модуля. Отметим, что такая функциональная
декомпозиция не
указывает, как
именно ПО будет фактически разбито на
программные модули (это составляет
содержание документа “Внутренняя
спецификация”). Для удобства работы,
конечно, полезно иметь некоторое
соответствие функционального и
фактического разбиения, но это не
является требованием и не должно уводить
с правильного пути проектирования
изделия.
3.3.n.1.1.
Стандарты (список используемых
промышленных стандартов и собственных
стандартов предприятия).
3.3.n.1.2.
Ограничения на совместимость. Необходимо
рассматривать несколько аспектов
совместимости: исходный язык, машинный
язык, форматы данных и сообщений, форматы
отчетов, форматы листингов и т.п.
Специально должна оговариваться
совместимость со следующими программными
изделиями:
изделиями-предшественниками
(т.е. такими, которые пользователь может
заменить новым изделием; если число
функций при такой замене уменьшается,
то следует привести обоснование этому);
изделиями-компаньонами
(т.е. относящимися к той же группе средств
и являющимися альтернативой);
подобными
изделиями (т.е. выполняющих похожие
функции в других программных изделиях);
конкурирующими
изделиями (других организаций).
3.3.n.1.3.
Программные ограничения. Описываются
программное окружение разрабатываемого
ПО, включая указание средств для его
загрузки и запуска. Также отмечаются
все действующие программные ограничения,
например использование вычислений с
удвоенной точностью для некоторых
функций.
3.3.n.1.4.
Аппаратные ограничения. Приводится
перечень устройств, необходимых для
работы ПО (с указанием минимальной,
оптимальной и максимальной конфигурации).
Указываются все действующие ограничения
на оборудование, например, физические
характеристики терминала или требование
запрещения использования звукового
сигнального устройства.
Примечание.
Если разрабатываемое ПО является
расширением уже существующего, то
описываются, главным образом, его
дополнительные характеристики. В любом
случае наибольшее внимание должно
уделяться самым важным для конечного
пользователя вопросам. Эти разделы
являются основой документа и содержат
полное и окончательное описание всех
свойств программного изделия.
3.3.n.2.1.
Результаты. Описываются все выходные
данные ПО с точки зрения их функционального
содержания и назначения (например,
файлы, сообщения, программно устанавливаемые
сигналы и прерывания). При этом должны
быть рассмотрены все возможные в системе
носители и средства отображения
информации. Указываются тип, структура,
формат, объем, расположение и диапазон
изменения. Для всех выходных данных,
читаемых людьми (сообщения и отчеты)
должны быть приведены образцы.
3.3.n.2.2.
Процессы обработки. Описываются операции,
выполняемые ПО в целом или функциональными
модулями, рассматриваемыми как “черный
ящик”. Если обсуждение идет на уровне
модулей или этапов разработки, указываются
также модули или этапы, требуемые для
получения определенной выходной
информации. Точно определяются все
возможные ошибки, потенциальные условия
их возникновения и способы рестарта и
восстановления. Подраздел должен
описывать инициацию, преобразование
данных, все варианты завершения работы
(нормального и аварийного).
3.3.n.2.3.
Входы. Описание подобно п. 3.3.2.1
Примечание.
Этот раздел описывает свойства,
обеспечивающие надежность, комфорт и
продуктивность работы пользователей
и операторов, а также вопросы безопасности,
секретности, восстанавливаемости после
сбоев, мобильности ПО. Остановимся более
подробно на двух подразделах: “Надежность”
и “Рабочие характеристики”.
В
разделе “Надежность” (это свойство
программы понимается здесь как способность
к восстановлению нормальной работы при
ошибках и сбоях в работе оборудования)
рассматриваются следующие вопросы:
степень
защиты программ от ошибок, возникающих
в других частях системы (например,
работающих одновременно с данной
программой в другой области памяти).
Следует рассмотреть, как могут повлиять
на работу предлагаемых программных
средств такие ошибки, учитывая следующие
моменты: распределение ресурсов памяти
(указать, если предусмотрено обеспечение
изоляции отводимых областей памяти);
связь программ через общие аппаратные
ресурсы.
Раздел
“Рабочие характеристики” описывает
основные параметры или принципы, по
которым должна оцениваться эффективность
работы программы, по возможности в
количественном виде с указанием возможных
допусков. Все параметры должны быть
измеряемыми, к их числу могут относиться
быстродействие, пропускная способность,
скорость передачи данных, расход машинных
ресурсов, время реакции (или задержки)
и т.д.
3.3.n.4.
Внутренние характеристики (этот раздел
полностью расширяется в документе
“Внутренняя Спецификация”, однако
частично может быть заполнен с целью
полного описания соответствующих
внешних свойств).
3.4.
Внутренние ограничения (здесь речь идет
о тех свойствах, которые пользователю
логично ожидать, но которые по тем или
иным причинам будут исключены из
программного изделия или потенциально
оставлены на усмотрение разработчика:
например, неполная взаимозаменяемость
носителей, отсутствие поддержки
каких-либо возможностей оборудования,
и т.п.).
4.
ИСПОЛЬЗУЕМЫЕ МАТЕРИАЛЫ (в т.ч. справочные)
5.
ПЕРЕДАЧА ЗАКАЗЧИКУ И ВВОД В ДЕЙСТВИЕ.
Этап 2. Как оценить композиционную структуру текста?
Нормы оформления документов, требования к их композиции устанавливают в инструкциях по делопроизводству организаций, которые обычно разрабатывают с учетом положений ГОСТ Р 7.0.97-2016 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов» (далее – ГОСТ Р 7.0.97-2016). Инструкция по делопроизводству, если работе над ней было уделено достаточно внимания, становится надежным помощником в процессе редактирования.
Приведем Чек-лист для оценки композиционной структуры документа и рассмотрим, как именно следует работать с текстом на этом этапе.
Материал публикуется частично. Полностью его можно прочитать в журнале «Секретарь-референт» № 2, 2021.
Задачи, функции и структура СК
Состав и маршруты перемещения документов в любом подразделении призваны обеспечивать решение стоящих перед ним задач и выполнение возложенных функций. Каковы же функции и задачи, стоящие перед СК?
Задачи службы многочисленны и разнообразны. Я знавала предприятия, где в перечень функций СК входили организация проведения ежегодной диспансеризации работников предприятия, проверка качества приготовленной пищи в заводской столовой и даже проверка качества закупаемых для работников подарков к 8 Марта, 23 Февраля и детских новогодних подарков. Но это, я считаю, скорее, относится к разряду курьезов.
Главная же задача СК на всех предприятиях и в организациях – предотвращение выпуска продукции, не соответствующей требованиям стандартов, технических условий, технической документации или условий, содержащихся в соответствующей договорной документации.
Исходя из этого, сформулируем основные функции СК (Схема 1).
Если предприятие достаточно большое, то внутри СК могут создаваться более мелкие подразделения (секторы, группы, бюро), решающие какие-либо определенные задачи. Поэтому структура СК может быть такой, как на Схеме 2.
Критерии экспертизы ценности документов
Включение документов, образовавшихся в деятельности организаций, в состав Архивного фонда Российской Федерации осуществляется на основе комплексного применения критериев:
— происхождения документов (функционально-целевое назначение организации — источника комплектования с учетом его особой роли или типового характера, время и место создания документа);
— содержания документов (значимость информации, в том числе ее уникальность, типичность или повторяемость, вид документа, его подлинность);
— внешних особенностей документов (форма фиксирования и передачи содержания, удостоверения и оформления документа, физическое состояние документов). Общие критерии экспертизы ценности документов могут применяться для всех видов документов, образующихся в процессе деятельности организации.
Наряду с ними, для отдельных видов документов, таких как научно-техническая документация, аудиовизуальные документы, а также и по личному составу, необходимо применение специальных критериев.
Так, для научно-технической документации используются кроме перечисленных выше общих критериев такие критерии, как:
— оригинальность разработки;
— уровень научно-технического решения;
— актуальность и востребованность;
— присуждение разработкам международных и/или государственных премий, наград.
Экспертиза ценности научно-технической документации проводится в два этапа. На первом этапе выявляются конкретные объекты проектирования, конструирования, технологические процессы, научные проблемы (темы), комплекс научно-технической документации по которым подлежит передаче на постоянное хранение. Первый этап экспертизы завершается составлением «Перечня проектов/объектов, проблем/тем, документация (НТД) по которым подлежит передаче на постоянное хранение». Перечни рассматриваются и утверждаются на соответствующей ЭПК.
На втором этапе осуществляется экспертиза ценности внутри всех видов документации, имеющей отношение к отобранным проектам. Второй этап экспертизы завершается составлением описей единиц хранения научно-технической документации постоянного хранения. На каждый вид научно-технической документации составляется отдельная опись.
Для аудиовизуальных документов используются также следующие критерии:
— комплектность документов;
— наличие сопроводительной документации;
— общественное признание информации, содержащейся в аудиовизуальных документах;
— известность автора и других участников съемки, аудиозаписи, фотодокументов;
— дата и место съемки;
— физико-химические и технические характеристики.
При проведении экспертизы ценности аудиовизуальных документов, архив может использовать разработанный им «Перечень фактов, событий, памятных дат, явлений, которые могут быть отражены в аудиовизуальных документах, подлежащих приему в государственные архивы».
При экспертизе ценности электронных документов оценивается воспроизводимость (пригодность для использования) электронных документов. Проверяется физико-химическое, техническое и биологическое состояние носителей; отсутствие вредоносного программного обеспечения; наличие технических возможностей для воспроизведения электронных документов с данного вида носителей; используемые форматы. Документы, прошедшие проверку на воспроизводимость, рассматриваются с применением критериев содержания.
При проведении экспертизы ценности документов личного происхождения (документов граждан) используются следующие критерии:
— общественная значимость лица (лиц, семьи);
— наличие документов членов семьи;
— наличие имущественно-хозяйственных документов за разные хронологические периоды;
— особая ценность собраний документов и других артефактов.
Для документов по личному составу используются такие критерии, как:
— участие гражданина в Великой Отечественной войне и других войнах, и вооруженных конфликтах, в ликвидации последствий стихийных бедствий и техногенных катастроф;
— принадлежность гражданина к профессиональным (трудовым) династиям работников, творческим профессиям;
— стаж работы (в целом в организации и в определенные, наиболее значимые для нее, периоды, а также работа в градообразующих и типичных для определенной территории организаций).
