<<
>>

П. 1.2. Общая характеристика состояния

Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы.

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

Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны по большей части с документированием функциональных характеристик ПС. Следует отметить, что стандарты ЕСПД (ГОСТ 19) носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПС (ГОСТ 34, Международному стандарту ISO/IEC и др.). Эти стандарты становятся обязательными на контрактной основе, т.е. при ссылке на них в договоре на разработку (поставку) ПС.

Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела.

К числу основных недостатков ЕСПД можно отнести: ориентацию на единственную, «каскадную» модель жизненного цикла (ЖЦ) ПС; отсутствие четких рекомендаций по документированию характеристик качества ПС; отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например ЕСКД; нечетко выраженный подход к документированию ПС как товарной продукции; отсутствие рекомендаций по самодокументированию ПС, например, в виде экранных меню и средств оперативной помощи пользователю (хэлпов); отсутствие рекомендаций по составу, содержанию и оформлению перспективных документов на ПС, согласованных с рекомендациями международных и региональных стандартов.

Итак, ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла ПС, об этом стандарте далее будет сказано подробнее.

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

Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию ЖЦ продуктов программного обеспечения (ПО) — казалось бы, весьма неконкретный, но вполне новый и отчасти модный стандарт.

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

В [60] подробно описана методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ — конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.

П. 1.2.1. Краткое представление стандартов ЕСПД

Тем не менее до пересмотра всего комплекса многие стандарты ЕСПД могут с пользой применяться в практике документирования ПС. Эта позиция основана на следующем:

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

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

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

Код группы

Наименование группы

0

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

1

Основополагающие стандарты

2

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

3

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

4

Правила выполнения документации сопровождения

5

Правила выполнения эксплуатационной документации

6

Правила обращения программной документации

7

Резервные группы

8

9

Прочие стандарты

Обозначение стандарта ЕСПД строят по классификационному признаку.

Обозначение стандарта ЕСПД должно состоять из: числа 19 (присвоенных классу стандартов ЕСПД); одной цифры (после точки), обозначающей код классификационной группы стандартов, указанной в таблице;

двузначного числа (после тире), указывающего год регистрации стандарта.

Перечень документов ЕСПД: ГОСТ 19.001-77 ЕСПД. Общие положения. ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов. ГОСТ 19.102-77 ЕСПД. Стадии разработки. ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов. ГОСТ 19.104-78 ЕСПД. Основные надписи. ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам. ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом. ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению. ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению. ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний. ГОСТ 19.401-78 ЕСПД.

Текст программы. Требования к содержанию и оформлению. ГОСТ 19.402-78 ЕСПД. Описание программы. ГОСТ'19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению. ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению. ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению. ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению. ГОСТ 19.504-79 ЕСПД. Руководство программиста. ГОСТ 19.505-79 ЕСПД. Руководство оператора. ГОСТ 19.506-79 ЕСПД. Описание языка. ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению. ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом. ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. ГОСТ 19.781-90 ЕСПД. Обеспечение систем обработки информации программное.

Из всех стандартов ЕСПД остановимся только на тех, которые могут чаще использоваться на практике.

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

ГОСТ (СТ СЭВ) 19.201-78 (1626-79). ЕСПД. Техническое задание. Требования к содержащие и оформлению (переиздан в ноябре 1987 г. с изм. 1)

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

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

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

ГОСТ (СТ СЭВ) 19.101-77 (1626-79). ЕСПД. Виды программ и программных документов (переиздан в ноябре 1987 г. с изм. 1)

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

Виды программ

Вид

программы

Определение

Компонент

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

Комплекс

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

Виды программных документов

Вид программного документа

Содержание программного документа

Спецификация

Состав программы и документации на нее

Ведомость держателей подлинников

Перечень предприятий, на которых хранят подлинники программных документов

Текст программы

Запись программы с необходимыми комментариями

Описание программы

Сведения о логической структуре и функционировании программы

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

Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля

Техническое задание

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

Пояснительная записка

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

Эксплуатационные

документы

Сведения для обеспечения функционирования и эксплуатации программы

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

Вид эксплуатационного документа

Содержание эксплуатационного документа

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

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

Формуляр

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

Описание применения

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

Окончание

Вид эксплуатационного документа

Содержание эксплуатационного документа

Руководство системного программиста

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

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

Сведения для эксплуатации программы

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

Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы

Описание языка

Описание синтаксиса и семантики языка

Руководство по техническому обслуживанию

Сведения для применения тестовых и диагностических программ при обслуживании технических средств

В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы.

Виды программных документов, разрабатываемых на разных стадиях, и их коды

Код

вида

докумен

та

Вид документа

Стадии разработки

Эскизный

проект

Техни

ческий

проект

Рабочий проект

компо

нент

комплекс

Спецификация

1

+

05

Ведомость

держателей

подлинников

?

12

Текст программы

+

?

/>13

Описание

программы

?

?

20

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

?

?

Окончание

Код

вида

докумен

та

Стадии разработки

Вид документа

Эскизный

Техни

Рабочий

проект

проект

ческий

проект

компо

нент

комплекс

30

Формуляр

?

?

31

Описание

применения

?

?

32

Руководство

системного

программиста

?

?

33

Руководство

программиста

?

?

34

Руководство

оператора

?

?

35

Описание языка

?

?

46

Руководство

по техническому обслуживанию

?

?

51

Программа и методика

испытаний

?

?

81

Пояснительная

записка

?

?

90-99

Прочие

документы

?

?

?

?

Условные обозначения:

+ документ обязательный;

! документ обязательный для компонентов, имеющих самостоятельное применение;

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

— документ не составляют.

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

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

ГОСТ 19.102-77. ЕСПД. Стадии разработки

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

Стадии разработки, этапы и содержание работ

Стадии />разработки

Этапы работ

Содержание работ

Обоснование необходимости разработки программы

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

'I схническое задание

Научно

исследовательские

работы

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

Разработка и утверждение технического задания

Определение требований к программе

Разработка технико-экономического обоснования разработки программы

Определение стадий, этапов и сроков разработки программы и документации на нее Выбор языков программирования

Продолжение

Стадии

разработки

Этапы работ

Содержание работ

Определение необходимости проведения научно-исследовательских работ на последующих стадиях

Согласование и утверждение технического задания

Эскизный

проект

Разработка

эскизного

проекта

Предварительная разработка структуры входных и выходных данных

Уточнение методов решения задачи

Разработка общего описания алгоритма решения задачи Разработка технико-экономического обоснования

Утверждение

эскизного

проекта

Разработка пояснительной записки

Согласование и утверждение эскизного проекта

Технический

проект

Разработка

технического

проекта

Уточнение структуры входных и выходных данных Разработка алгоритма решения задачи

Определение формы представления входных и выходных данных

Определение семантики и синтаксиса языка Разработка структуры программы

Окончательное определение конфигурации технических средств

Утверждение

технического

проекта

Разработка плана мероприятий по разработке и внедрению программ

Окончание

Стадии

разработки

Этапы работ

Содержание работ

Разработка пояснительной записки

Согласование и утверждение технического проекта

Разработка

программы

Программирование и отладка программы

Разработка

программной

документации

Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77

Рабочий

проект

Испытания

программы

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

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

Внедрение

Подготовка и передача программы

Подготовка и передача программы и программной документации для сопровождения и (или) изготовления Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление

Передача программы в фонд алгоритмов и программ

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

ГОСТ 19.103-77ЕСПД. Обозначение программ и программных документов

Программа и ее документ «Спецификация» имеют следующую структуру обозначения:

А В.ХХХХХ-ХХ

Номер издания (для программы)

Номер редакции (для документа)

Регистрационный номер

Код организации-разработчика

Код страны

Структура обозначения других программных документов: А.В.ХХХХХ-ХХ XX ХХ-Х

Номер части документа

Номер документа данного вида

Код вида документа

Номер редакции документа

Общая часть обозначения программы и программных документов на нее Код страны-разработчика и код организации-разработчика присваивают в установленном порядке. Регистрационный номер присваивается в порядке возрастания, начиная с 00001 до 99999, для каждой организации-разработчика. Номер издания программы или номер редакции. Номер документа данного вида, номер части документа присваиваются в порядке возрастания с 01 до 99. (Если документ состоит из одной части, то дефис и порядковый номер части не указывают.) Номер редакции спецификации и ведомости эксплуатационных документов на программу должны совпадать с номером издания этой же программы.

ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам

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

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

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

Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных.

ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом

Программные документы оформляют: на листах формата А4 (ГОСТ 2.301-68) при изготовлении документа машинописным или рукописным способом; допускается оформление на листах формата АЗ; при машинном способе выполнения документа допускаются отклонения размеров листов, соответствующих форматам А4 и АЗ, определяемые возможностями применяемых технических средств; на листах форматов А4 и АЗ, предусматриваемых выходными характеристиками устройств вывода данных, при изготовлении документа машинным способом; на листах типографических форматов при изготовлении документа типографским способом.

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

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

Следующий стандарт ориентирован на документирование результирующего продукта разработки.

ГОСТ 19.402-78 ЕСПД. Описание программы

Состав документа «Описание программы» в своей содержательной части может дополняться разделами и пунктами, почерпнутыми из стандартов для других описательных документов и руководств: ГОСТ 19.404-79ЕСПД. Пояснительная записка', ГОСТ              19.502-78ЕСПД.              Описание применения', ГОСТ              19.503-79ЕСПД.              Руководство              системного программиста', ГОСТ              19.504-79 ЕСПД.              Руководство              программиста', ГОСТ              19.505-79 ЕСПД.              Руководство              оператора.

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

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

Наконец, последний по году принятия стандарт.

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

Он устанавливает правила выполнения схем, используемых для отображения различных видов задач обработки данных и средств их решения и полностью соответствует стандарту ИСО 5807:1985.

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

ГОСТ 19.781-90. Обеспечение систем обработки информации программное. Термины и определения

Разработан взамен ГОСТ 19.781-83 и ГОСТ 19.004-80 и устанавливает термины и определения понятий в области программного обеспечения систем обработки данных (СОД), применяемые во всех видах документации и литературы, входящих в сферу работ по стандартизации или использующих результаты этих работ.

ГОСТ 28388-89. Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения

Распространяется не только на программные, но и на конструкторские, технологические и другие проектные документы, выполняемые на магнитных носителях.

П.1.2.2. Стандарты комплекса ГОСТ 34

ГОСТ 34 задумывался в конце 1980-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Мотивы и получившиеся результаты описаны ниже в «Особенностях» ГОСТ 34. Объектами стандартизации являются АС различных (любых!) видов и все виды их компонентов, а не только ПО и БД.

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

Из всех существующих и нереализованных групп документов будем основываться только на Группе 0 «Общие положения» и Группе 6 «Создание, функционирование и развитие АС». Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические указания РД 50-34.698-90 (Требования к содержанию документов). Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.

Для общего случая разработки АС стадии и этапы ГОСТ 34 приведены в таблице.

1. ФТ—Формирование требований к АС

Обследование объекта и обоснование необходимости создания АС Формирование требований пользователя к АС Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)

2. РК — Разработка концепции АС

Изучение объекта Проведение необходимых научноисследовательских работ Разработка вариантов концепции АС, удовлетворяющей требованиям пользователя Оформление отчета о выполненной работе

Окончание

3. ТЗ — Техническое задание на создание АС

3.1. Разработка и утверждение технического задания на создание АС

4. ЭП — Эскизный проект

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

5. ТП — Технический проект

Разработка проектных решений по системе и ее частям Разработка документации на АС и ее части Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку Разработка заданий на проектирование в смежных частях проекта объекта автоматизации

6. РД — Рабочая документация

Разработка рабочей документации на систему и ее части Разработка или адаптация программ

7. ВД — Ввод в действие

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

8. Сп — Сопровождение АС

Выполнение работ в соответствии с гарантийными обязательствами Послегарантийное обслуживание

Описано содержание документов, разрабатываемых на каждом этапе. Это определяет потенциальные возможности выделения на содержательном уровне сквозных работ, выполняемых параллельно или последовательно (то есть по сути — процессов), и составляющих их задач. Такой прием может использоваться при построении профиля стандартов ЖЦ проекта, включающего согласованные подмножества стандартов ГОСТ 34 и IS012207.

Главный мотив: разрешить проблему «вавилонской башни».

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

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

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

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

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

Степень адаптивности формально определяется возможностями: опускать стадию эскизного проектирования и объединять стадии «Технический проект» и «Рабочая документация»; опускать этапы, объединять и опускать большинство документов и их разделов; вводить дополнительные документы, разделы документов и работы; динамически создавая так называемые ЧТЗ — частные технические задания — достаточно гибко формировать ЖЦ АС; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

Стадии и этапы, выполняемые организациями — участниками работ по созданию АС, устанавливаются в договорах и техническом задании, что близко к подходу ISO.

Введение единой, достаточно качественно определенной терминологии, наличие достаточно разумной классификации работ, документов, видов обеспечения и т.д., безусловно, полезно. ГОСТ 34 способствует более полной и качественной стыковке действительно разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС, например, типа CAD-CAM, включающих в свой состав АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ и другие системы.

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

Разделение понятий ПТК и АС закрепляло принцип, по которому АС есть не «ИС с БД», но: «организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т.д.) или их сочетаниях» (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга; «система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций» (по ГОСТ 34.003-90).

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

Степень обязательности: прежняя полная обязательность отсутствует, материалы ГОСТ 34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и

проведению испытаний АС. При этом польза ГОСТ 34 может многократно возрасти в случае их более гибкого использования при формировании профиля ЖЦ АС.

Ключевым документом взаимодействия сторон является ТЗ — техническое задание на создание АС. ТЗ — основной исходный документ для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).

П. 1.2.3. Государственные стандарты РФ (ГОСТ Р)

В РФ действует ряд стандартов в части документирования ПС, разработанных на основе прямого применения международных стандартов ИСО. Это — самые «свежие» по времени принятия стандарты. Некоторые из них прямо адресованы руководителям проекта или директорам информационных служб. Вместе с тем они неоправданно мало известны в среде профессионалов. Вот их представление.

ГОСТР ИСО/МЭК 9294-93. Информационная технология. Руководство по управлению документированием программного обеспечения

Стандарт полностью соответствует международному стандарту ИСО/ МЭК ТО 9294:1990 и устанавливает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Цель стандарта — оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования. />ГОСТР ИСО/МЭК 9126-93. Информационная технаюгия. Оценка программной продукции. Характеристики качества и руководства по их применению

Стандарт полностью соответствует международному стандарту ИСО/ МЭК 9126:1991. В его контексте под характеристикой качества понимается «набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается». Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС (ПО, программной продукции): функциональные возможности; надежность; практичность; эффективность; сопровождаемость; мобильность. Эти характеристики образуют основу для дальнейшего уточнения и описания качества ПС.

ГОСТ Р ИСО 9127-94. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов

Стандарт полностью соответствует международному стандарту ИСО 9127:1989. В контексте настоящего стандарта под потребительским про

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

ГОСТ Р ИСО/МЭК 8631-94. Информационная технология. Программные конструктивы и условные обозначения для их представления

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

П. 1.2.4. Процессы жизненного цикла программных средств (ГОСТ Р ИСО/МЭК 12207-99)

Первая редакция ISO/IEC 12207: 1995-08-01 подготовлена в 1995 г. объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения».

В 1999 г. он введен в России и странах СНГ — ГОСТ Р ИСО/МЭК 12207:99.

По определению, IS012207 — базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратеги j и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Очень важные ЗАМЕЧАНИЯ СТАНДАРТА: процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО); добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Контракт понимается в широком смысле: от юридически оформленного контракта до неформального соглашения, соглашение может быть определено и единственной стороной как задача, поставленная самому себе; стандарт принципиально не содержит конкретных методов действий, тем более — заготовок решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить услуги и задачи, включенные в процессы, не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт.

ОПРЕДЕЛЕНИЯ СТАНДАРТА -. Система — комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям. Модель жизненного цикла — структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации — процесс исключения процессов, видов деятельности и задач, не применимых в конкретном проекте. Степень адаптивности — максимальная. Квалификационное требование — набор критериев или условий, которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт на соответствие установленным требованиям и готовность к использованию в заданных условиях эксплуатации.

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

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

Каждый процесс ЖЦ разделен на набор действий, каждое действие — на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируются и выполняются другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т.п.). Все процессы жизненного цикла изображены на рис. П.1.1.

В стандарте ISO 12207 описаны: пять основных процессов ЖЦ ПО: процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПО; процесс поставки. Определяет действия предприятия-поставщика, снабжающего покупателя системой, программным продуктом или сервисом ПО; процесс разработки. Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт; процесс функционирования. Определяет действия предприятия-оператора, обеспечивающего обслуживание системы (а не только ПО)

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

ОСНОВНЫЕ ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА

1

Злказ

2 Постановка s

4. Эксплуатация

/>

3. Разработка

1 '

5. Сопровождение

вспомогательные процессы жизненного

ЦИКЛА

1. Документирование

2. Управление конфигурацией

3. Обеспечение качества

4. Верификация

5. Аттестация

6. Совместный анализ

7. Аудит

8. Решение проблем

ОРГАНИЗАЦИОННЫЕ процессы жизненного цикла Создание инфраструктуры Усовершенствование

восемь вспомогательных процессов, которые поддерживают реализацию другого процесса, будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПО: решения проблем; документирования; управления конфигурацией; гарантирования качества, использующий результаты остальных процессов группы обеспечения качества, в которую входят: верификация; аттестация;

-совместная оценка;

-аудит; четыре организационных процесса: управления; создания инфраструктуры; усовершенствования; обучения.

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

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

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

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

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

Такой характер позволяет реализовывать любую модель ЖЦ.

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

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

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

(Интересно и важно, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ 34 по видам обеспечения системы.)

Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД, но и не использовать.

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

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

По этой причине центральным стандартом, положения которого берутся за начальный «стержневой» набор положений в процессе построения профиля стандартов ЖЦ для конкретного проекта, полезно рассматривать именно ISO 12207. Этот «стержень» может задавать модель ЖЦ

ПО и АС, принципиальную схему гарантирования качества, модель управления проектом. />Практики используют еще один путь: сами переводят и используют в своих проектах современные стандарты на организацию ЖЦ ПС и их документирование. Но этот путь страдает как минимум тем недостатком, что разные переводы и адаптации стандартов, сделанные разными разработчиками и заказчиками, будут отличаться массой деталей. Эти отличия неизбежно касаются не только наименований, но и их содержательных определений, вводимых и используемых в стандартах. Таким образом, на этом пути неизбежно постоянное возникновение путаницы, а это прямо противоположно целям не только стандартов, но и любых грамотных методических документов.  

<< | >>
Источник: Гринберг А.С., Король И.А.. Информационный менеджмент. 2003

Еще по теме П. 1.2. Общая характеристика состояния:

  1. Глава 18 ОБЩАЯ ОЦЕНКА И ПРОГНОЗИРОВАНИЕ ФИНАНСОВОГО СОСТОЯНИЯ ПРЕДПРИЯТИЯ
  2. 4.1. ОБЩАЯ ХАРАКТЕРИСТИКА МИРОВОГО ХОЗЯЙСТВ
  3. Общая характеристика
  4. 7.1. ОБЩАЯ ХАРАКТЕРИСТИКА ПРОИЗВОДНЫХ ИНСТРУМЕНТОВ И ИХ ВИДЫ
  5. Лекция 3. Общая характеристика рыночной экономики
  6. Глава 5. ОБЩАЯ ХАРАКТЕРИСТИКА РЫНОЧНОЙ ЭКОНОМИКИ
  7. Глава 1. Общая характеристика стратегического управления
  8. Глава 1. ОБЩАЯ ХАРАКТЕРИСТИКА БУХГАЛТЕРСКОГО УЧЕТА
  9. 10.1. Общая характеристика
  10. 2.2.1. Общая характеристика
  11. Глава 1. ОБЩАЯ ХАРАКТЕРИСТИКА РЫНКА ЦЕННЫХ БУМАГ
  12. РАЗДЕЛ VI. ОБЩАЯ ХАРАКТЕРИСТИКА СТРАН С НЕРЫНОЧНОЙ ЭКОНОМИКОЙ
  13. 3. СРОЧНЫЙ ВАЛЮТНЫЙ РЫНОК: ОБЩАЯ ХАРАКТЕРИСТИКА И ОПЕРАЦИИ
  14. ГЛАВА 1 ОБЩАЯ ХАРАКТЕРИСТИКА РЫНКА ЦЕННЫХ БУМАГ
  15. ГЛАВА 9 Общая характеристика системы и процессов бюджетирования
  16. Глава 7 ОБЩАЯ ХАРАКТЕРИСТИКА ФИНАНСОВ КОММЕРЧЕСКИХ ОРГАНИЗАЦИЙ
- Антикризисное управление - Деловая коммуникация - Документоведение и делопроизводство - Инвестиционный менеджмент - Инновационный менеджмент - Информационный менеджмент - Исследование систем управления - История менеджмента - Корпоративное управление - Лидерство - Маркетинг в отраслях - Маркетинг, реклама, PR - Маркетинговые исследования - Менеджмент организаций - Менеджмент персонала - Менеджмент-консалтинг - Моделирование бизнес-процессов - Моделирование бизнес-процессов - Организационное поведение - Основы менеджмента - Поведение потребителей - Производственный менеджмент - Риск-менеджмент - Самосовершенствование - Сбалансированная система показателей - Сравнительный менеджмент - Стратегический маркетинг - Стратегическое управление - Тайм-менеджмент - Теория организации - Теория управления - Управление качеством - Управление конкурентоспособностью - Управление продажами - Управление проектами - Управленческие решения - Финансовый менеджмент - ЭКОНОМИКА ДЛЯ МЕНЕДЖЕРОВ -