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

ЕСПД

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

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

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

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

Перечень стандартов, входящих в ЕСПД

• ГОСТ 19.001-77 ЕСПД. Общие положения. (текст)
• ГОСТ 19.002-80 ЕСПД. Схемы алгоритмов и программ. Правила выполнения. (Заменен на ГОСТ 19.701-90). (текст)
• ГОСТ 19.003-80 ЕСПД. Схемы алгоритмов и программ. Обозначения условные графические. (Заменен на ГОСТ 19.701-90). (текст)
• ГОСТ 19.004-80 ЕСПД. Термины и определения. (Заменен на ГОСТ 19781-90).
• ГОСТ 19.005-85 ЕСПД. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения. (текст)
• ГОСТ 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.403-79 ЕСПД. Ведомость держателей подлинников. (текст)
• ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению. (текст)
• ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению. (текст)
• ГОСТ 19.502-78 ЕСПД. Общее описание. Требования к содержанию и оформлению. (текст)
• ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению. (текст)
• ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению. (текст)
• ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению. (

В свое время, когда я только начинал работать программистом, часто приходилось слышать “напиши, пожалуйста, документацию к своей программе”. Я честно все описывал, отдавал начальнику, после чего начинался сеанс черной магии. Начальник через некоторое время меня вызывал и начинал мычать нечленораздельные звуки, мять распечатку моего “самого лучшего” текста в руках, бегая глазами. Общий смысл его мычания заключался в том, что получилось “не то”, “не так”, и “посмотри, как делают другие”. Так как никакого другого ответа из него вытянуть было невозможно, я шел за примерами документов к “другим”. Как правило, это были веселые ребята, смысл речей которых заключался в том, что “вот примеры”, “вообще то по ГОСТу” и “это все никому не нужно”. Так я узнал впервые, что программист может соприкоснуться со страшными ГОСТами.
Поразительно, что среди многих десятков моих коллег, очень неглупых программистов, не было никого, кто бы относился к ГОСТам по другому. Даже те несколько человек, которые их знали и, вроде как, даже умели оформлять документы, относились к ним презрительно-формально. Ситуация, когда даже люди, ответственные за управление разработкой не понимают, зачем нужны ГОСТы и как их применят, встречается на многих предприятиях, сплошь и рядом. Да, были и компании, в которых понимали, чем “Описание программы” отличается от “Описания применения”, но таких было явное меньшинство. В интернете вообще господствует точка зрения, что ГОСТы для программистов - это явный рудимент, и нужны только если “нагибают” под них. Эскизный проект считают “сравнительно честным способом отъемы лишних дензнаков у заказчика”. Вникнуть и разобраться пришлось относительно недавно - в процессе разработки системы управления требованиями, заточенной под отечественную специфику. Документацию которая, разумеется, должна генерировать “по ГОСТу”.

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

Стандарты

Рассмотрим кратко, какие бывают стандарты (фокусируясь на ИТ-области).

1. международные. Отличительный признак - принят международной организацией. Пример такой организации - ISO (международная организация стандартизации). Пример её стандарта: ISO 2382-12:1988 (Переферийное оборудование). Распространены совместные стандарты ISO и международной электротехнической комиссии(IEC, в по русски - МЭК): например, ISO/IEC 12207:2008 (жизненный цикл ПО);
2. региональные. Отличительный признак - принят региональной комиссией по стандартизации. К примеру, многие советские ГОСТы сейчас являются региональным стандартом, т.к. приняты межгосударственным советом, куда входят некоторые бывшие советские республики. Этим советом принимаются и новые стандарты - и они тоже получают обозначение ГОСТ. Пример: ГОСТ 12.4.240-2013;
3. стандарты общественных объединений; К примеру, той же МЭК: IEC 60255;
4. национальные стандарты. Для России в начале таких стандартов - “ГОСТ Р”. Могут быть трех типов:
   1. точные копии международных или региональных. Обозначаются неотличимо от “самописных” (национальных, написанных самостоятельно);
   2. копии международных или региональных с дополнениями. Обозначаются добавлением к шифру отечественного стандарта шифра международного, который был взят за основу. Например: ГОСТ Р ИСО/МЭК 12207;
   3. собственно, национальные стандарты. Например, ГОСТ Р 34.11-94.

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

ГОСТ

Итак: стандарты бывают международные, межгосударственные(региональные) и национальные. ГОСТ, как мы выяснили, это региональный стандарт. ГОСТы имеют достаточно запутанную, на мой взгляд, систему обозначений. Полностью она изложена в ГОСТ Р 1.5-2004, я приведу минимум, что бы в ней ориентироваться. Во первых, надо различать обозначение ГОСТа и его классификацию. Обозначение - это, грубо говоря, уникальный идентификатор стандарта. Код по классификатору - это вспомогательный код, помогающий найти стандарт или определить, к какой области знаний он относиться. Классификаторов может быть много, в основном используются два: КГС (классификатор государственных стандартов) и его наследник ОКС (общероссийский классификатор стандартов). Например: “ГОСТ Р 50628-2000“ - это обозначение стандарта.По обозначению понятно только то, что он принят в 2000 году. Он имеет код по ОКС “33.100;35.160”: т.е. “33” - раздел “Телекоммуникации, аудио, видео”, “100” - подраздел “электромагнитная совместимость”. Однако он также входит в ветвь классификатора 35.160. “35” - “Информационные технологии. Машины конторские”, “160” - “Микропроцессорные системы....”. А по КГС он имеет код “Э02”, что означает “Э” - “Электронная техника, радиоэлектроника и связь”, “0” - “Общие правила и нормы по электронной технике, радиоэлектронике и связи”, и т.д.

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

1. стандарт относиться к серии стандартов. В этом случае после индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ РВ) идет код серии, точка и обозначение стандарта внутри серии. Правила обозначения стандартов внутри серии устанавливаются правилами серии. Например: ГОСТ РВ 15.201-2000, ГОСТ Р 22.8.0-99, ГОСТ 19.101-77;
2. стандарт не относиться к серии стандартов. Тогда после индекса категории идет просто порядковый номер стандарта, тире и год принятия. Например, ГОСТ Р 50628-2000.

Итак, если совсем просто - то обозначение ГОСТа - это либо просто порядковый номер, тире, год, либо номер серии, точка и дальше в зависимости от серии. В реальности все сложнее (к примеру, можно встретить что то типа ГОСТ 11326.19-79, и это будет вовсе не серия 11326 - но программистам такое нужно очень редко. За подробностями - в ГОСТ Р 1.5-2004).

ЕСПД

ЕСПД - одна из таких серий ГОСТов, номер 19. Т.е. все стандарты, относящиеся к ЕСПД, начинаются с префикса “19.”: например, ГОСТ 19.106-78. Расшифровывается как “Единая система программной документации”. Существуют и другие серии:

• ГОСТ ЕСКД (единая система конструкторской документации, префикс “2.”);
• ГОСТ ЕСТД (единая система технологической документации, префикс “3.”);
• ГОСТ Р, Система разработки и постановки продукции на производство, префикс “15.”;
• ГОСТ РВ, Вооружение и военная техника. Система разработки и постановки продукции на производство, префикс “15.”;
• ГОСТ, Система технической документации на АСУ, префикс “24.”;
• ГОСТ, Комплекс стандартов на автоматизированные системы, префикс “34.”.

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

19.001-77. Общие положения

Описывает правила присвоения обозначений стандартов в серии ЕСПД. В практической жизни не нужен.

19.102-80. Схемы алгоритмов и программ. Правила выполнения.

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

19.003-80. Схемы алгоритмов и программ. Обозначения условные графические

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

19.004-80. Термины и определения.

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

19.005-85. Р-схемы алгоритмов и программ

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

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

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

19.102-77. Стадии разработки

Важный и нужный стандарт, в котором описаны виды документов и приведены коды видов программных документов. Этот стандарт (совместно с 19.103-77) является одним из ключей к “разгадке” обозначений документов подобных АБВГ.10473-01 32 01-1.
В стандарте вводится понятие комплекса и компонента (на ряде предприятий добавляют третий вид - комплект, когда речь идет о несвязанных программных элементах), дается разделение: какие документы эксплуатационные, какие нет.
Следует аккуратно относиться к таблице 4, в которой показано, какой документ на какой стадии разработки выполняется. Стадии разработки обычно регламентируются в стандартах на выполнения ОКР, и там-же указывается, какие документы нужно предъявлять заказчику на каждом этапе.

19.102-77. Стадии разработки

На моей памяти этот стандарт не применялся ни разу: кто что делает на каком этапе и чем отчитывается прописывается в ТТЗ или делается отсылка к ГОСТам, где это прописано более четко (например, ГОСТ РВ 15.203). При этом для новичка он содержит неплохой в своей лаконичности конспект работ на основных этапах ОКР.

19.103-77. Обозначения программ и программных документов

Нужен, в основном, для того, что бы научиться читать обозначения документов подобных приведенному выше. Однако понимание схемы обозначений полезно в случае, когда приходиться выходить за рамки типовых работ: к примеру, помнить, что документы с кодами после 90 - пользовательские, т.е. любые. В моей практике мы выпускали документ 93, который назвали “Ведомость программной документации”, 96 документ - “Инструкция по сборке”.
Распространенное словосочетание “вариант исполнения” в ЕСПД отсутствует, и заменяется “номером редакции”. С одной стороны, это не совсем корректно: номер редакции задумывался для отслеживания эволюции программы: вначале выходит первая редакция, потом, к примеру, после доработки - вторая. Но на практике, когда нужно выпустить версию ПО для нескольких операционных систем (кросс-платформенное ПО), другого выхода нет. Точнее - есть, но неправильный: присвоить версии для каждой операционки свое обозначение - и закладывать в архив несколько дисков с исходниками (по числу операционок), разрабатывать (фактически - копировать) весь комплект документации и т.д… Т.е. чистой воды бестолковая и сбивающая с толку деятельность. Решение в виде присвоения версии под каждую операционку своего номера редакции позволяет часть документов сделать общими.
В ЕСПД используется смущающее многих программистов обозначение исходных текстов программы и результата сборки “документами”. Документ “текст программы”, согласно 19.101-77, имеет обозначение 12. Дальше принято, что исходники обозначаются как 12 01 - т.е. 01(первый) документ вида 12, а бинарники - как 12 02 - т.е. второй документ вида 12. В ряде случаев для сборки программы требуются дополнительные инструментальные средства - компиляторы, генераторы инсталляторов и т.д. Т.е. программы, которые не входят в поставку, но нужны для сборки. Решением может быть их обозначение как 12 03 - т.е. третий документ вида 12.

19.104-78. Основные надписи

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

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

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

19.105-78. Общие требования к программным документам

Вводится общая структура документа, не зависящая от способа его исполнения. Т.е. еще в 1978 году было заложено в стандарт, что документ может быть не обязательно бумажным. В частности, вводиться понятие содержания для полностью электронных документов. Для бумажного исполнения, распространенного в то время, был принят ГОСТ 19.106-78.
В настоящее время к этому стандарту приходиться обращаться очень редко: разве что забывается порядок следования основных частей документа.

19.106-78. Общие требования к программным документам, выполненным печатным способом

Самый объемный стандарт из ЕСПД, уступающий разве что описанию R-схем. Является основным рабочим стандартом при оформлении документации. Вводит правила оформления текста, элементов структуры документа, изображений, формул и т.д. Однако в отличии от соответствующего 2.106 из ЕСКД, 19.106 существенно менее подробный, что приводит к многочисленным неопределенностям.
Во первых, стандарт фактически не определяет межстрочное расстояние и величину вертикальных отступов между заголовками. Он вводит три правила определения интервала: для машинописного текста, машинного и типографского.
Машинописный текст - это текст, набранный на печатной машинке. Смещение следующей строки относительно предыдущей производилось автоматически при так называемом «переводе каретки» - переходе к печати следующей строки, производимым перемещением специального рычага. Как правило, интервал мог быть вручную скорректирован поворотом вала протяжки бумаги, и имел “настройку”, позволяющую задать величину интервала - одинарный или двойной.
Машинный - это, скорее всего, и есть распечатанный текст. Но для него есть только указание, что результат должен быть пригоден для микрофильмирования. Это неявная ссылка на 13.1.002-2003, в котором, к сожалению, задается межстрочный интервал (и, кстати, минимальная высота шрифта) только для рукописных документов (п.4.2.5).
Типографский - текст, набранный в типографии. Учитывая год принятия стандарта, скорее всего речь идет о
[высокой печати , где межстрочный интервал определялся используемыми литерами. Я не специалист в типографском деле, а информации о методах набора сейчас очень мало.
Какой интервал использовать в итоге часто определяется местным нормоконтролем или СТО. Типичные значения - полуторный интервал и 14 размер шрифта.
Часто вызывает много вопросов способ структурирования документа. 19.106 считает, что весь документ делится на разделы, подразделы, пункты и подпункты. У всех них (кроме раздела и подраздела) заголовок может быть и или не быть. При этом:

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

В отличии от ЕСКД, в ЕСПД принят странный способ оформления рисунков: сначала идет название рисунка, потом сам рисунок, потом опциональный “подрисуночный текст”, и потом, на новой строке, “Рис. N”.
Этот стандарт имеет ряд “дыр”, недостказанностей. К примеру, сказано: “иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа. “ Но если иллюстрация одна, то она ненумерованная, и как тогда на нее ссылаться? Аналогично и для таблиц. Для сносок ГОСТ не указывает способ их нумерации - в пределах всего документа или в пределах страницы.
Таблицы. В самом документе дана ссылка на ГОСТ 1.5.68. Судя по первой серии, несложно заключить, что это стандарт на разработку стандартов. Причем тут он, неясно. По смыслу он соответствует правилам оформления таблиц в ЕСКД, с небольшими исключениями. Этот стандарт был отменен, взамен веден, через несколько итераций, 1.5-2012, в котором правила оформления таблицы… просто исчезли. Еще в 1.5-2002 были, а уже в 1.5-2004 исчезли. В реальной жизни мы оформляем таблицы согласно ЕСКД.
Приложения. Стандарт не указывает, попадают ли рисунки, формулы и таблицы из приложений в общий перечень. Аналогично не сказано, нужно ли в оглавлении раскрывать структуру приложения, если оно содержит свои разделы, пункты и т.д. В нашей практике мы не раскрываем внутренности приложений.
Наконец, следует сказать об отступах. Абзацный отступ, равный 5 символам, является общим для:

• красной строки;
• отступа элемента структуры документа после раздела (подраздел, пункт, подпункт);
• элемент перечисления.

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

В следующих частях планирую уже добраться до конца списка стандартов ЕСПД.

Метки: Добавить метки

ОСТ 19.ххх Единая система программной документации (ЕСПД) ГОСТ 19.001-77 Общие положения

ГОСТ 19781-90 Термины и определения.

ГОСТ 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.403-79 Ведомость держателей подлинников

ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению

ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению

ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению

ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению

ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению

ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению

ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению

ГОСТ 19.507-79 Ведомость эксплуатационных документов

ГОСТ 19.508-79 Руководство по техническом обслуживанию. Требования к содержанию и оформлению

ГОСТ 19.601-78 Общие правила дублирования, учета и хранения

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

ГОСТ 19.603-78 Общие правила внесения изменений

ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненных печатным способом

Единая система программной документации ГОСТ 19.001-77

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

United system for program documentation.

General principles

Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. № 1268 срок введения установлен

с 01.01. 1980 г.

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

1. НАЗНАЧЕНИЕ ЕСПД

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

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

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

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

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

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

2. ОБЛАСТЬ РАСПРОСТРАНЕНИЯ И СОСТАВ ЕСПД

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

2.2. В состав ЕСПД входят:

основополагающие и организационно-методические стандарты;

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

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

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

3. КЛАССИФИКАЦИЯ И ОБОЗНАЧЕНИЕ СТАНДАРТОВ ЕСПД

3.1. Стандарты ЕСПД подразделяют на группы, приведенные в таблице. Код группы Наименование группы

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

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

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

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

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

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

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

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

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

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

В обозначение стандарта ЕСПД должны входить:

цифры 19, присвоенные классу стандартов ЕСПД;

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

двузначное число, определяющее порядковый номер стандарта в группе;

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

Пример обозначения стандарта « Единая система программной документации. Общие положения »:

ГОСТ 19.001-77

| | || | Год регистрации стандарта

| | || Порядковый номер стандарта в группе

| | | Классификационная группа стандартов

| | Класс (стандарты ЕСПД)

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Единая система программной документации ГОСТ 19781-90

ОБЕСПЕЧЕНИЕ СИСТЕМ ОБРАБОТКИ ИНФОРМАЦИИ ПРОГРАММНОЕ

Software of data processing systems.

Terms and definitions.

General principles

Дата введения: с 01.01.92

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

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

Настоящий стандарт должен применяться совместно с ГОСТ 15971, ГОСТ 20886, ГОСТ 24402.

1. Стандартизованные термины с определениями приведены в табл. 3.

2. Для каждого понятия установлен один стандартизованный термин. Применение терминов-синонимов стандартизованного тер­мина не допускается. Недопустимые к применению термины-синонимы приведены в табл. 1 в качестве справочных и обозначены пометой «Ндп».

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

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

2.3. В табл. 1 в качестве справочных приведены иноязычные эквиваленты для ряда стандартизованных терминов на английском языке.

3. Алфавитные указатели содержащихся в стандарте терминов на русском и английском языках приведены в табл. 2-3.

4. Термины и определения общих понятий, относящихся к системам обработки информации, управлению обработкой данных и представлению данных, необходимые для понимания текста стандарта, приведены в приложении 11.

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

Определение

Основные понятия

1. Программа

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

2. Программное обеспечение

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

3. Программирование

Научная и практическая деятельность по созданию программ

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

4. Системная программа

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

5. Управляющая программа

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

6. Супервизор

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

7. Прикладная программа

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

8. Программа обслуживания

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

9. Абсолютная программа

Программа на машинном языке, выполнение которой зависит от ее местоположения в оперативной памяти

10. Переместимая программа

Программа на машинном языке, выполнение которой не зависит от ее местоположения в оперативной памяти

11. Реентерабельная программа

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

12. Мобильная программа

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

13. Драйвер

Программа, предназначенная для управления работой периферийных устройств, обычно в мини- и микро-ЭВМ

14. Подпрограмма

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

15. Программный модуль

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

16. Исходный модуль

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

17. Объектный модуль

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

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

18. Загрузочный модуль

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

19. Макроопределение

Программа, под управлением которой макрогенератор порождает макрорасширения макрокоманд

20. Рекурсивная подпрограмма

Подпрограмма, которая может обращаться к себе самой

Компоненты систем программирования

21. Система программирования

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

22. Кросс-система программирования

Система программирования, программные компоненты которой порождают программы на машинном языке, отличном от того, в среде которого они работают

23. Язык программирования

По ГОСТ 2:8397-89

24. Алгоритмический язык

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

25. Проблемно-ориентированный язык

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

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

26. Исходный язык

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

27. Машинный язык

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

Примечание. Для выполнения программы на машинном языке не требуется применение трансляторов, компиляторов и интерпрета­торов

28. Автокод

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

29. Язык ассемблера

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

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

30. Язык высокого уровня

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

31. Макроязык

Язык программирования, предназначенный для представления макроопределений.

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

32. Макрокоманда

Предложение языка программирования, вместе которого макрогенератор подставляет макрорасширения

33. Макрорасширение

Последовательность предложений, порождаемая макрогенератором при обработке макрокоманды на основании макроопределения

34. Декларативный язык

Язык программирования для выражения определений.

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

35. Объектно-ориентированный язык

Язык программирования, который соответствует концепциям объектно-ориентированного программирования

36. Процедурный язык

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

37. Функциональный язык

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

38. Транслятор

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

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

39. Конвертор языка

Конвертор

Транслятор с некоторого языка на другой язык такого же уровня

40. Компилятор

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

41. Ассемблер

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

42. Макрогенератор

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

43. Интерпретатор

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

Примечание. Большинство интерпретаторов осуществляют интерпретацию программы путем последовательной интерпретации ее предложений

44. Редактор связей

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

45. Библиотека программ

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

Примечание. Библиотека программ часто называется в соответствии с природой содержащихся в ней элементов.

Виды программирования

46. Структурное программирование

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

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

47. Объектно-ориентированное программирование

Примечание. Объекты состоят из данных и операций над данными

48. Логическое программирование

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

Технология программирования и отладки программ

49. Спецификация программы

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

50. Трансляция программы

Трансляция

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

51. Компиляция

Трансляция программы с языка высокого уровня в форму, близкую к программе на машинном языке

52. Ассемблирование

Компиляция программ с языка ассемблера

53. Поиск ошибок (в программе)

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

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

Доказательство того, что поведение программы соответствует спецификации на эту программу

Данные, представляющие собой полное или частичное содержимое оперативной памяти, выводимое на периферийное устройство

56. Аварийный дамп

Дамп, полученный в результате ненормального завершения программы

57. Тупиковая ситуация

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

Адресация в программах

58. Функция адресации

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

59. Адрес в пространстве памяти

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

60. Пространство памяти

Область памяти, некоторая совокупность подобластей которой является областью значений функции адресации

61. Указатель области памяти

Адрес области памяти, размещенный в пространстве памяти, в котором расположена эта область

62. Адрес команды

Адрес области памяти, которая занята командой

63. Исполнительный адрес

Адрес операнда команды, содержащийся в ней или вычисляемый на основании содержимого ее полей.

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

64. Базовый адрес

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

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

65. Индекс адреса

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

66. Базовая адресация

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

67. Индексирование адреса

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

Примечание. Индексирование может сочетаться с базовой адресацией.

68. Базовый регистр

69. Индексный регистр

Элементы и структуры организации программ и данных

7.0. Цикл (в программе)

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

71. Флажок (в программе)

Переменная, регистрирующая появление определенного события или состояния

72. Переключатель (в программе)

Управляемый флажком выбор одного перехода из группы возможных переходов в программе

73. Семафор

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

74. Общая переменная

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

75. Порция данных

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

Примечание. Контексты существенно зависят от решаемых задач и этапов их решения и могут изменяться от задачи к задаче и от одного этапа к другому

76. Литерная цепочка

Порция данных, состоящая из последовательности литер

77. Идентификатор

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

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

78. Составной идентификатор

Идентификатор объекта, включающий идентификаторы классов, которые вложены друг в друга и содержат этот объект

79. Область памяти

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

80. Подобласть памяти

Область памяти, рассматриваемая как составная часть другой области памяти

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

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

82. Поле данных

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

83. Экстент памяти

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

Примечание. В ОС ЕС ЭВМ под набор данных на устройствах прямого доступа пространство памяти отводится экстентами

Процессы обработки данных

84. Процесс обработки данных

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

Примечания:

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

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

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

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

85. Параллельные процессы

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

86. Конкурирующие процессы

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

87. Системный процесс

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

88. Процесс системного ввода

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

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

89. Процесс вывода

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

90. Приоритет процесса

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

91. Мультипрограммная смесь

Совокупность процессов, выполнением которых управляет одна и та же управляющая программа

Управление многопроцессорной системой, при котором процессоры как ресурсы участвуют в выполнении одной и той же мультипрограммной смеси

93. Ресурс системы обработки информации

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

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

94. Разделяемый ресурс

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

95. Задание системе работки информации

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

96. Пакетное задание

Задание системе обработки информации, выполняемое в режиме пакетной обработки

97. Пакет заданий

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

98. Пункт задания

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

99. Язык управления заданиями

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

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

100. Удаленный ввод заданий

Ввод заданий вычислительной системе средствами телеобработки данных

101. Диалоговый удаленный ввод заданий

Удаленный ввод заданий, при котором ввод

осуществляется в диалоговом режиме

102. Сеанс работы

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

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

Унификации программных изделий для взаимного обмена программами и применения ранее разработанных программ в новых разработках;

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

Автоматизации изготовления и хранения программной документации.

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

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

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

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

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

Согласно ГОСТ 28195-89, оценка качества осуществляется на всех этапах жизненного цикла ПС при:

Планировании показателей качества ПС;

Контроле качества на отдельных этапах разработки (техническое задание, технический проект, рабочий проект);

Контроле качества в процессе производства ПС;

Проверке эффективности модификации ПС на этапе сопровождения.

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

Основные задачи, решаемые при оценке качества ПС:

Планирование уровня качества;

Контроль значений показателей качества в процессе разработки и испытаний;

Эксплуатационный контроль заданного уровня качества;

Выбор базовых образцов по подклассам и группам;

Методическое руководство разработкой нормативно-технических документов по оценке качества.

Методы определения показателей качества ПС различаются:

По способам получения информации о ПС - измерительный, регистрационный, органолептический, расчетный;

По источникам получения информации - традиционный, экспертный, социологический.

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

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

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

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

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

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

Социологические методы основаны на обработке специальных анкет-вопросников. Отечественный стандарт ГОСТ 28195-89 определяет иерархическую структуру, номенклатуру и содержание понятий качества программных средств. На верхнем уровне выделены шесть характеристик: надежность, корректность, удобство применения, эффективность, универсальность и сопровождаемость, которые детализируются на втором уровне 19 комплексными показателями. На третьем уровне дальнейшая детализация содержит более чем 200 оценочных элементов. Состав используемых показателей рекомендуется выбирать в зависимости от назначения, функций и этапов жизненного цикла программного средства. Однако методы оценки показателей отсутствуют.

Методологии оценивания характеристик качества готовых ПП на различных этапах жизненного цикла посвящен международный стандарт ISO / IEC 14598-1-6:1998-2001. С момента вступления в силу ГОСТ 28195-89 произошли существенные изменения во многих аспектах общественной жизни, в том числе существенно изменились экономико-правовые отношения и в сфере разработки и эксплуатации программных средств. Например, в области коммерческих программных продуктов исчез фондодержатель, а разработчик и изготовитель обычно представляют собой одно и то же юридическое лицо. В рыночных условиях разработчик заинтересован в обеспечении качества своих продуктов в течение всего их жизненного цикла. Кроме того, изменился порядок сертификации продукции.

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

По договору об отчуждении исключительного права правообладатель передает или обязуется передать принадлежащее ему исключительное право приобретателю в полном объеме (пункт 1 статьи 1234 и ст. 1285 ГК РФ).

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

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

Поскольку договор об отчуждении исключительного права на зарегистрированную программу для ЭВМ подлежит государственной регистрации, то согласно пункту 4 статьи 1234 ГК РФ исключительное право на такие результаты переходит от правообладателя к приобретателю в момент государственной регистрации этого договора.

По лицензионному договору одна сторона - автор или иной правообладатель (лицензиар) предоставляет либо обязуется предоставить другой стороне (лицензиату) право использования этого произведения в установленных договором пределах (не в полном объеме). Лицензионный договор о предоставлении права использования программы ЭВМ обязательной регистрации не подлежит. Разработчик программы в договоре может разрешить другой стороне пользоваться программой на определенных условиях (по срокам, по территории, по сдаче в прокат и др.). В этом случае программа остается неотчуждаемой от ее автора.

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

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

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

Недостаток трассировки.

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

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

Недостаточная надежность. Самый сложный процесс - поиск и исправление ошибок в программах на ЭВМ. Поскольку число ошибок в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах. Следует отметить, что привлечение доказательного подхода к проектированию ПО позволяет обнаружить ошибки в программе до ее выполнения. Данная проблема возникает при неправильном выборе средств разработки. Например, при попытке создать программу, требующую средств высокого уровня, с помощью средств низкого уровня. Например, при попытке создать средства автоматизации с СУБД на ассемблере. В результате исходный код программы получается слишком сложным и плохо поддающимся структурированию.

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

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

Права собственности на ПО и хранящуюся в нем информацию;

Способы получения информации для заполнения соответствующих баз данных;

Права юридических и физических лиц на информацию;

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

Правоотношения (права, обязанности и ответственность) между лицами, обслуживающими ПО;

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

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

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

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

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

Предоставление права Мингосимуществу России устанавливать цену на конкретные информационные продукты и услуги;

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

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

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

Термин "интеллектуальная собственность" эпизодически употреблялся теоретиками - юристами и экономистами в XVIII и XIX веках, однако в широкое употребление вошел лишь во второй половине XX века, в связи с учреждением в 1967 году в Женеве Всемирной организации интеллектуальной собственности (ВОИС). Согласно учредительным документам ВОИС, "интеллектуальная собственность" включает права, относящиеся к:

Литературным, художественным и научным произведениям:

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

Изобретениям во всех областях человеческой деятельности:

Научным открытиям;

Промышленным образцам;

Товарным знакам, знакам обслуживания, Фирменным наименованиям и коммерческим обозначениям;

Защите против недобросовестной конкуренции;

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

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

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

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

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

Вопросы для самопроверки

1. Какими показателями качества определяются программы?

2. Что такое программный продукт?

3. Что понимается под жизненным циклом программного обеспечения?

4. Для какой цели определяются спецификации программного обеспечения?

5. Какие существуют стадии разработки программного обеспечения?

7. Что понимается под верификацией и сертификацией программного продукта?

8. В чем сущность модульной структуры программного обеспечения?

9. В чем разница между автономной и комплексной отладками программного обеспечения?

10. Что такое - переносимость программ?

11. Какими свойствами обладают открытые системы?

12. Что понимается под Единой системой программной документации?

13. Как оформляется отчуждаемая программа?

14. Каким правовым законом охраняется интеллектуальная собственность на программы для ЭВМ?

Литература

1. Иванова Г.С. Технология программирования. - М.: КноРус, 2011. - 333 с.
2. Камаев В.А. Технологии программирования. - М.: Высшая школа, 2006. - 454 с.
3. Орлов С.А. Технология разработки программного обеспечения. - СПб.: Питер, 2004. 526 с.
4. Рудаков А.В. Технология разработки программных продуктов. - М.: Академия, 2010. 207 с.
5. http://sp.cmc.msu.ru/info/37techprog.htm - технология программирования.
6. http://www.twirpx.com/file/27591/- технология программирования, лекции.
7. http://www.intuit.ru/department/se/introprogteach/1/3.html - жизненный цикл программы.
8. http://www.pervviurok.ru/Info/Internet Development/gl11/gl11.html - отладка модулей.
9. http://citforum.ru/database/articles/art 19.shtml - открытые системы.
10. http://www.mini-soft.ru/book/tech prog/- технология программирования.
11. http://www.labfor.ru/?act=metod&target=metod leso1 1 - среда программирования.