Стандартизация программной документации

Содержание:

Введение

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

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

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

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

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

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

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

- рассмотрено понятие программной документации: ее сущность, структура и требования;

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

- рассмотрен пример стандартизации программной документации.

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

Глава 1 Сущность, структура и требования к программной документации

1.1 Программная документация: проблемы и требования, предъявляемые к ней

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

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

При этом возникает ряд организационных, методологических и технологических проблем и задач, которые должны решаться при подготовке процессов документирования проектов программных средств. Проблемы определения потребности документирования программных средств, которые следует решать в проектах, начинаются с анализа, с целью понять каждую решаемую проблему до начала разработки проекта и комплекса документов программного средства:^[1]

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

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

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

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

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

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

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

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

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

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

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

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

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

- размер – масштаб, подлежащих разработке полностью новых программных компонентов и документов;

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

- относительные затраты ресурсов на создание проекта с оцененным масштабом: труда специалистов, времени, бюджета на единицу размера (на строку текста программ) или полные затраты на разработку всего ПС и комплекса документов.

Оценивая масштаб, функции и требования к документации, заказчик и разработчики должны хотя бы приближенно представлять тот объем затрат и физический размер комплекса документации, который придется создать в процессе всего жизненного цикла ПС, а также для обеспечения его эффективного применения. Известно, что на документирование крупномасштабных ПС требуется до 20 – 30% общей трудоемкости создания таких проектов, а для относительно малых проектов около 10% трудоемкости. Представляет интерес оценка ориентировочного физического объема документации (например, в стандартных страницах А4 или эквивалентных объемов файлов) для проектов комплексов программ.

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

Он должен охватывать (но не ограничиваться) следующие задачи: ^[4]

- установление графиков и сроков своевременного решения задач документирования;

- оценку необходимых трудозатрат на создание каждого документа и всего комплекса;

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

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

- определение обязанностей исполнителей по созданию содержания документов;

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

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

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

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

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

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

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

План и поддерживающее его Руководство по документированию конкретного проекта ПС должны отражать:

- общую структуру комплекта документов;

- номенклатуру и содержание (или ссылки на шаблоны) каждого документа;

- требования к качеству, оформлению и обозначению документов;

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

- правила обращения, изменения и сопровождения документов;

- графики подготовки, проверки, редактирования, согласования, утверждения и распространения документов.

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

- исходные данные (шаблоны), требующиеся для успешного выполнения данного этапа документирования проекта или компонента ПС;

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

- содержание процедур контроля состояния проекта и документов в процессе выполнения работ этапа;

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

Глава 2 Стандартизация программной документации

2.1 Стандартизация компонент информационных технологий

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

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

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

В зависимости от того, участники какого географического, экономического, политического региона мира принимают стандарт, стандартизация может быть: международная (ISO, IEC, ITU), региональная (CEN, CENELEC, ETSI) и национальная (ANSI, AFNOR, В SI, DIN, JISC), которая в свою очередь может быть государственная(ГОСТ), отраслевая (на уровне министерств), и внутрифирменная (стандарты, разрабатываемые фирмой).^[6]

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

- Единая система программной документации (ЕСПД) - комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ и программной документации. В состав ЕСПД входят: основополагающие и организационно-методические стандарты; стандарты, определяющие формы и содержание программных документов, применяемых при обработке данных; стандарты, обеспечивающие автоматизацию разработки программных документов. Стандарты качества и надежности используются для определения адекватности качества функционирования, наличия технических возможностей программных средств к взаимодействию, совершенствованию и развитию (стандарты качества ISO 9004-1-94; ISO 8402; ISO 9126:1991). Стандарты тестирования содержат указания, которые определяют порядок тестирования продукта на соответствие его требованиям к качеству. Стандартизация аппаратных средств - это стандарты на процессор (INTEL), мониторы (наиболее известны MPR -II, ТСО'92 и ТСО'95, ISO 9241-3, ЕРА EnergyStar, TUV Ergonomie), клавиатуры, периферийное оборудование, носители информации, организация сети и др.

- Единая система стандартов автоматизированных систем управления (АСУ). Данные стандарты устанавливают основные положения по надежности АСУ, виду, комплектностности и обозначения документов при создании автоматизированных систем, интерфейсу для АСУ, техническому заданию на создание АСУ, виды испытаний.

- Стандарты информационной безопасности. Информационная безопасность предполагает защиту информации от разнообразных угроз для поддержки непрерывности бизнеса, сокращения убытков, увеличения прибылей на инвестированный капитал и расширения возможностей для бизнеса. Независимо от того, на каком этапе развития находится информационная система компании, она должна соответствовать определенному набору минимальных требований к режиму информационной безопасности (ИБ), которые могут быть продиктованы корпоративными, отраслевыми или международными стандартами. Первым оценочным стандартом, получившим международное признание и оказавшим исключительно сильное влияние на последующие разработки в области информационной безопасности, стал стандарт Министерства обороны США "Критерии оценки доверенных компьютерных систем" (Department of Defense TrustedComputer System EvaliationCriteria, TCSEC), более известный (по цвету обложки) под названием "Оранжевая книга". Среди международных стандартов по информационной безопасности наиболее известным является британский - BS 7799, разработанный Британским институтом стандартов (British Standards Institution - В SI) Стандарт BS 7799 состоит из двух частей. Первая - BS 7799 Part III «Практические правила управления информационной безопасностью». В 1999 г. она была переработана и передана в Международную организацию по стандартизации (ISO). Последней версией, принятой в 2005 г, является ISO/IEC17799:2005. Стандарт ISO17799 описывает более 100 механизмов контроля, необходимых для построения системы управления информационной безопасностью (СУИБ) организации. Этот документ устанавливает основные принципы и представляет собой руководство по созданию системы обеспечения информационной безопасности организации. С 5 сентября 2002 г. в силу вступила вторая часть Стандарта BS 7799 Part 211 «Спецификация системы управления информационной безопасностью». С 15 октября 2005 г. ISO приняла стандарт BSIBS 7799-2:2002 в качестве международного - ISO/IEC 27001:2005. В докладе основное внимание уделено международному стандарту ISO/IEC 15408-1999 и его российскому аналогу ГОСТ Р ИСО/МЭК 15408-2002 "Критерии оценки безопасности информационных технологий".

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

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

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

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

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

Стандарты комплекса ГОСТ 34 на создание и развитие автоматизированных систем (АС) – обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Но эти стандарты многими считаются бюрократическими до вредности и консервативны ми до устарелости. Насколько это так, а насколько ГОСТ 34 остается работающим с пользой – полезно разобраться. ЕСПД нуждается в полном пересмотре на основе стандарта ИСО.МЭК 12207-95 на процессы ЖЦ ПС. Тем не менее, до пересмотра всего комплекса, многие стандарты ЕСПД могут с пользой применяться в практике документирования ПС.

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

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

Таблица 1 - Группы стандарта ЕСПД ^[8]

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

Обозначение стандарта ЕСПД должно состоять из:

-числа 19 (присвоенных классу стандартов ЕСПД);

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

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

14.2.1. Перечень документов ЕСПД.

1. ГОСТ 19.001-77 ЕСПД. Общие положения.

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

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

5. ГОСТ 19.104-78 ЕСПД. Основные надписи.

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

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

8. ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.

9. ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.

10. ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.

11. ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.

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

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

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

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

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

17. ГОСТ 19.504-79 ЕСПД. Руководство программиста.

18. ГОСТ 19.505-79 ЕСПД. Руководство оператора.

19. ГОСТ 19.506-79 ЕСПД. Описание языка.

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

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

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

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

14.2.2. Термины и определения Из всех стандартов ЕСПД остановимся только на тех, которые могут чаще использоваться на практике. Первым укажем стандарт, который можно использовать при формировании заданий на программирование. ГОСТ (СТ СЭВ) 19.201-78 (1626-79). ЕСПД. Техническое задание. Требование к содержанию и оформлению. (Переиздан в ноябре 1987г с изм.1). Техническое задание (ТЗ) содержит совокупность требований к ПС и может использоваться как критерий проверки и приемки разработанной программы. Поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком, ТЗ является одним из основополагающих документов проекта ПС. Техническое задание должно содержать следующие разделы: введение; основания для разработки; назначение разработки; требования к программе или программному изделию; требования к программной документации; технико-экономические показатели; стадии и этапы разработки; порядок контроля и приемки; в техническое задание допускается включать приложения. В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. Следующий стандарт ГОСТ (СТ СЭВ) 19.101-77 (1626-79). ЕСПД. Виды программ и программных документов (Переиздан в ноябре 1987г с изм.1).устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

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

Таблица 2 – Виды эксплуатационных документов^[9]

Примечания.

1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях – вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.

2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком. ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов Программа и ее документ «Спецификация» имеют следующую структуру обозначения: Структура обозначения других программных документов: Код страны-разработчика и код организации-разработчика присваивают в установленном порядке. Регистрационный номер присваивается в порядке возрастания, начиная с 00001 до 99999, для каждой организации-разработчика. Номер издания программы или номер редакции.номер документа данного вида, номер части документа присваиваются в порядке возрастания с 01 до 99. (Если документ состоит из одной части, то дефис и порядковый номер части не указывают).

Таблица 3 - Стадии разработки, этапы и содержание работ

Номер редакции спецификации и ведомости эксплуатационных документов на программу должны совпадать с номером издания этой же программы. ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам. Настоящий стандарт устанавливает общие требования к оформлению программных документов для вычислительных машин, комплексов и систем, независимо от их назначения и области применения и предусмотренных стандартами Единой системы программной документации (ЕСПД) для любого способа выполнения документов на различных носителях данных. Программный документ может быть представлен на различных типах носителей данных и состоит из следующих условных частей: – титульной; – информационной; – основной. Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных. ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом. Программные документы оформляют: на листах формата А4 (ГОСТ 2.301-68) при изготовлении документа машинописным или рукописным способом; допускается оформление на листах формата А3; при машинном способе выполнения документа допускаются отклонения размеров листов, соответствующих форматам А4 и А3, определяемые возможностями применяемых технических средств; на листах форматов А4 и А3, предусматриваемых выходными характеристиками устройств вывода данных, при изготовлении документа машинным способом; на листах типографических форматов при изготовлении документа типографским способом.

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

Следующий стандарт ориентирован на документирование результирующего продукта разработки – ГОСТ 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. Наряду с ЕСПД на межгосударственном уровне действуют еще два стандарта, также относящихся к документированию ПС и принятых не так давно, как большая часть ГОСТ ЕСПД. ГОСТ 19781-90 Обеспечение систем обработки информации программное. Термины и определения. Разработан взамен ГОСТ 19.781-83 и ГОСТ 19.004-80 и устанавливает термины и определения понятий в области программного обеспечения (ПО) систем обработки данных (СОД), применяемые во всех видах документации и литературы, входящих в сферу работ по стандартизации или использующих результаты этих работ. ГОСТ 28388-89 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения. Распространяется не только на программные, но и на конструкторские, технологические и другие проектные документы, выполняемые на магнитных носителях.

В РФ действует ряд стандартов в части документирования ПС, разработанных на основе прямого применения международных стандартов ИСО. Это самые «свежие» по времени принятия стандарты. Некоторые из них впрямую адресованы руководителям проекта или директорам информационных служб. Вместе с тем они неоправданно мало известны в среде профессионалов. Вот их представление. ГОСТ Р ИСО/МЭК 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения. Стандарт полностью соответствует международному стандарту ИСО/МЭК ТО 9294:1990 и устанавливает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Стандарт полностью соответствует международному стандарту ИСО/МЭК 9126:1991. В его контексте под характеристикой качества понимается «набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается». Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС (ПО, программной продукции): функциональные возможности; надежность; практичность; эффективность; сопровождаемость; мобильность. Эти характеристики образуют основу для дальнейшего уточнения и описания качества ПС. ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. Стандарт полностью соответствует международному стандарту ИСО 9127:1989.

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

Глава 3 Пример оформления руководства пользователя

Ниже представлен пример (образец) документа "Руководство пользователя", разработанного на основании методических указаний РД 50-34.698-90.

Данный документ формируется IT-специалистом, или функциональным специалистом, или техническим писателем в ходе разработки рабочей документации на систему и её части на стадии «Рабочая документация».

Для формирования руководства пользователя в качестве примера был взят инструмент OracleDiscoverer информационно-аналитической системы «Корпоративное хранилище данных».

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

Разделы руководства пользователя:

Введение.

Назначение и условия применения.

Подготовка к работе.

Описание операций.

Аварийные ситуации.

Рекомендации по освоению.

1. Введение

В разделе "Введение" указывают:

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

краткое описание возможностей;

уровень подготовки пользователя;

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

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

Требования настоящего документа применяются при:

предварительных комплексных испытаниях;

опытной эксплуатации;

приемочных испытаниях;

промышленной эксплуатации.

1.2. Краткое описание возможностей

Информационно-аналитическая система Корпоративное Хранилище Данных (ИАС КХД) предназначена для оптимизации технологии принятия тактических и стратегических управленческих решений конечными бизнес-пользователями на основе информации о всех аспектах финансово-хозяйственной деятельности Компании.

ИАС КХД предоставляет возможность работы с регламентированной и нерегламентированной отчетностью.

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

формирование табличных и кросс-табличных отчетов;

построение различных диаграмм;

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

печать результатов анализа;

распространение результатов анализа.

1.3. Уровень подготовки пользователя

Пользователь ИАС КХД должен иметь опыт работы с ОС MS Windows (95/98/NT/2000/XP), навык работы с ПО Internet Explorer, OracleDiscoverer, а также обладать следующими знаниями:

знать соответствующую предметную область;

знать основы многомерного анализа;

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

знать и иметь навыки работы с аналитическими приложениями.

Квалификация пользователя должна позволять:

формировать отчеты в OracleDiscovererPlus;

осуществлять анализ данных.

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

Информационно-аналитическая система «Корпоративное хранилище данных». ПАСПОРТ;

Информационно-аналитическая система «Корпоративное хранилище данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.

2. Назначение и условия применения OracleDiscovererPlus

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

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

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

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

Работа с OracleDiscovererPlus в составе ИАС КХД возможна всегда, когда есть необходимость в получении информации для анализа, контроля, мониторинга и принятия решений на ее основе.

Работа с OracleDiscovererPlus в составе ИАС КХД доступна всем пользователям с установленными правами доступа.

3. Подготовка к работе

В разделе "Подготовка к работе" указывают:

состав и содержание дистрибутивного носителя данных;

порядок загрузки данных и программ;

порядок проверки работоспособности.

3.1. Состав и содержание дистрибутивного носителя данных

Для работы с ИАС КХД необходимо следующее программное обеспечение:

Internet Explorer (входит в состав операционной системы Windows);

OracleJInitiator устанавливается автоматически при первом обращении пользователя к ИАС КХД.

3.2. Порядок загрузки данных и программ

Перед началом работы с ИАС КХД на рабочем месте пользователя необходимо выполнить следующие действия:

Необходимо зайти на сайт ИАС КХД ias-dwh.ru.

Во время загрузки в появившемся окне "Предупреждение о безопасности", которое будет содержать следующее: 'Хотите установить и выполнить "OracleJInitiator" ...' Нажимаем на кнопку "Да".

После чего запуститься установка OracleJInitiator на Ваш компьютер. Выбираем кнопку Next и затем OK.

3.3. Порядок проверки работоспособности

Для проверки доступности ИАС КХД с рабочего места пользователя необходимо выполнить следующие действия:

Открыть Internet Explorer, для этого необходимо кликнуть по ярлыку «Internet Explorer» на рабочем столе или вызвать из меню «Пуск».

Ввести в адресную строку Internet Explorer адрес: ias-dwh.ru и нажать «Переход».

В форме аутентификации ввести пользовательский логин и пароль. Нажать кнопку «Далее».

Убедиться, что в окне открылось приложение OracleDiscovererPlus.

В случае если приложение OracleDiscovererPlus не запускается, то следует обратиться в службу поддержки.

4. Описание операций

В разделе "Описание операций" указывают:

-описание всех выполняемых функций, задач, комплексов задач, процедур;

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

Для каждой операции обработки данных указывают:

-наименование;

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

-подготовительные действия;

-основные действия в требуемой последовательности;

-заключительные действия;

-ресурсы, расходуемые на операцию.

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

4.1. Выполняемые функции и задачи

Таблица 3 – Функции и задачиOracleDiscovererPlus в составе ИАС КХД

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

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

Ниже приведено описание пользовательских операций для выполнения каждой из задач.

Задача: «Визуализация отчетности»

Операция 1: Регистрация на портале ИАС КХД

Условия, при соблюдении которых возможно выполнение операции:

Компьютер пользователя подключен к корпоративной сети.

Портал ИАС КХД доступен.

ИАС КХД функционирует в штатном режиме.

Подготовительные действия:

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

Основные действия в требуемой последовательности:

На иконке «ИАС КХД» рабочего стола произвести двойной щелчок левой кнопкой мышки.

В открывшемся окне в поле «Логин» ввести имя пользователя, в поле «Пароль» ввести пароль пользователя. Нажать кнопку «Далее».

Заключительные действия:

Не требуются.

Ресурсы, расходуемые на операцию:

15-30 секунд.

Операция 2: Выбор отчета

Условия, при соблюдении которых возможно выполнение операции:

Успешная регистрация на Портале ИАС КХД.

Подготовительные действия:

Не требуются.

Основные действия в требуемой последовательности:

1. В появившемся окне «Мастер создания рабочих книг» поставить точку напротив пункта «Открыть существующую рабочую книгу».

2. Выбрать нужную рабочую книгу и нажать кнопку «Откр.»:

Заключительные действия:

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

Ресурсы, расходуемые на операцию:

15 секунд.

Задача: «Формирование табличных и графических форм отчетности»

Заполняется по аналогии.

5. Аварийные ситуации

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

В случае возникновения ошибок при работе ИАС КХД, не описанных ниже в данном разделе, необходимо обращаться к сотруднику подразделения технической поддержки ДИТ (HelpDesk) либо к ответственному Администратору ИАС КХД.

Таблица 4 – Ошибки

Класс ошибки	Ошибка	Описание ошибки	Требуемые действия пользователя при возникновении ошибки
Портал ИАС КХД	Сервер не найден. Невозможно отобразить страницу	Возможны проблемы с сетью или с доступом к порталу ИАС КХД.	Для устранения проблем с сетью обратиться к сотруднику подразделения технической поддержки (HelpDesk). В других случаях к администратору ИАС КХД.
	Ошибка: Требуется ввести действительное имя пользователя	При регистрации на портале ИАС КХД не введено имя пользователя.	Ввести имя пользователя.
	Ошибка: Требуется ввести пароль для регистрации	При регистрации на портале ИАС КХД не введен пароль.	Ввести пароль.
	Ошибка: Сбой аутентификации. Повторите попытку	Неверно введено имя пользователя или пароль, либо такая учетная запись не зарегистрирована.	Нужно повторить ввод имени пользователя и пароля, однако после третей неудачной попытки регистрации учетная запись блокируется. Если учетная запись заблокирована, нужно обратиться к администратору ИАС КХД.
Сбой в электропитании рабочей станции	Нет электропитания рабочей станции или произошел сбой в электропитании.	Рабочая станция выключилась или перезагрузилась.	Перезагрузить рабочую станцию. Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды: - нажать кнопку «Пуск» - выбрать пункт «Выполнить» - в строке ввода набрать команду telnet ias_dwh.ru 80 - если открылось окно Telnet, значит соединение возможно. Повторить попытку подключения (входа) в ИАС КХД
Сбой локальной сети	Нет сетевого взаимодействия между рабочей станцией и сервером приложений ИАС КХД	Отсутствует возможность начала (продолжения) работы с ИАС КХД. Нет сетевого подключения к серверу ИАС КХД	Перезагрузить рабочую станцию. Проверить доступность сервера ИАС КХД по порту 80, выполнив следующие команды: - нажать кнопку «Пуск» - выбрать пункт «Выполнить» - в строке ввода набрать команду telnet ias_dwh.ru 80 - если открылось окно Telnet, значит соединение возможно. После восстановления работы локальной сети повторить попытку подключения (входа) в ИАС КХД.

6. Рекомендации по освоению

В разделе "Рекомендации по освоению" указывают рекомендации по освоению и эксплуатации, включая описание контрольного примера, правила его запуска и выполнения.

Рекомендуемая литература:

Oracle® Business Intelligence Discoverer Viewer User’s Guide

Oracle® Business Intelligence Discoverer Plus User’s Guide

Рекомендуемые курсы обучения:

Discoverer 10g: Создание запросов и отчетов

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

Заключение

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

Основная часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Частично эти стандартны морально устарели, к тому же они не лишены некоторых недостатков. Во-первых, в них не отражены некоторые современные тенденции оформления программ и программной документации, во-вторых, в этих стандартах наличествует многократное дублирование фрагментов программной документации. Тем не менее, за неимением лучшего ориентироваться приходится именно на них.

Итак, стандарты ЕСПД упорядочивают процесс документирования программных систем. Однако, во-первых, предусмотренный стандартами ЕСПД состав программных документов вовсе не такой "жесткий", как может показаться: стандарты позволяют вносить в комплект документации на программной системы (ПС) дополнительные виды, а, во-вторых, исходя из требований заказчика, допустимы некоторые изменения как в структуре, так и в содержании установленных видов ПД. Более того, можно отметить, что стандарты ЕСПД (а это относится и ко всем другим стандартам в области ПС - ГОСТ 34, Международному стандарту ISO/IEC, и др.) носят рекомендательный характер. Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе – т.е. при ссылке на них в договоре на разработку (поставку) ПС.

Библиография

1. Автоматизированные информационные технологии в экономике / Под общ.ред. И.Т. Трубилина. – М.: Финансы и статистика, 2010.
2. Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств. – М.: Финансы и статистика, 2013.
3. Информатика. Базовый курс / Под ред. С.В. Симоновича. – СПб., 2012.
4. Компьютерные технологии обработки информации / Под.ред. С.В. Назарова. – М.: Финансы и статистика, 2015.
5. Котов С.Л. Нормирование жизненного цикла программной продукции. – М.: ЮНИТИ-ДАНА, 2012.
6. Липаев В.В. Документирование и управление конфигурацией программных средств – М.: СИНТЕГ, 2012.
7. Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. – М.: СИНТЕГ, 2011.
8. Орлов С.А. Технологии разработки программного обеспечения: Разработка сложных программных систем: Учебное пособие для студентов вузов, обуч. по напр. подготовки бакалавров и магистров «Информатика и выч.техника». – СПб.: Питер, 2012.
9. Фридман А.Л. Основы объектно-ориентированной разработки программных систем – М.: Финансы и статистика, 2010.
10. www.gost.ru
11. www.standard.ru

1. Липаев В.В. Документирование и управление конфигурацией программных средств – М.: СИНТЕГ, 2012. ↑

2. Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. – М.: СИНТЕГ, 2011. ↑

3. Липаев В.В. Документирование и управление конфигурацией программных средств – М.: СИНТЕГ, 2012. ↑

4. Липаев В.В. Документирование и управление конфигурацией программных средств – М.: СИНТЕГ, 2012. ↑

5. Липаев В.В. Документирование и управление конфигурацией программных средств – М.: СИНТЕГ, 2012. ↑

6. ?Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. – М.: СИНТЕГ, 2011. ↑

7. ?Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. – М.: СИНТЕГ, 2011. ↑

8. Липаев В.В. Документирование и управление конфигурацией программных средств – М.: СИНТЕГ, 2012. ↑

9. Липаев В.В. Документирование и управление конфигурацией программных средств – М.: СИНТЕГ, 2012. ↑