Организация разработки внутрифирменных стандартов

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

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

1. Определение дерева задач (оглавления стандарта).

2. Определение типовых форм для каждой задачи.

3. Назначение исполнителей.

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

5. Разработка календарного графика.

6. Описание входящих и исходящих показателей.

7. Составление глоссария терминов.

Группировка задач по разделам осуществляется логически, причем в соответствии с рекомендациями функциональной деком­позиции ГОЕРО рекомендуется на одном уровне располагать от 2 до 8 задач.

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

В том случае, когда не планируются кардинальные изменения бизнес-процессов, могут использоваться традиционные докумен­ты и неизменные исполнители; стоит лишь исключать дублиро­вание функций. Если речь идет о перепроектировании, то на этом этапе следует очень тщательно подойти к отбору релевантных задач и выбрать показатели, характеризующие состояние и пове­дение экономических объектов. Рекомендуется подумать о целе­сообразности включения в стандарт тех или иных показателей.

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

На следующем этапе следует определить структуру докумен­тов, если это не было сделано ранее.

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

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

(календарного) графика.

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

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

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

Разработка и внедрение внутрифирменных стандартов — тру­доемкие процессы, но в результате их оптимизируются бизнес-процессы, уточняется организационная структура, осуществляется постановка задачи формирования единого информационно-I о пространства. Все эти факторы повышают качество деятельности предприятия, что непосредственно влияет на его конкурентоспособность.

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

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

Стандарт на подпись может быть таким:

Фамилия, Имя, Отчество (на русском) сотрудника,

должность (на русском)

Отдел, Название фирмы (на русском)

-----------------------------------------------------------------------------

Телефон (7-095) (код страны, код города),

ХХХ-ХХ-ХХ (телефон)

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

Иванов Иван Иванович, системный аналитик,

отдел системного анализа, ЗАО «Б&С»

------------------------------------------------

Телефон (7-095) 964-16-44

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

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

На практике удобно выделять рабочее пространство на пространства:

• аналитиков;

• программистов;

• тестеров;

• специалистов отдела внедрения;

• конической поддержки.

Анализ и проектирование. Обычно для целей функционирования аналитического отдела разрабатывается ряд стандартов, Которые регламентируют, как правило:

• применение методик структурного анализа или методов объектно-ориентированного анализа;

• описание бизнесс-процессов предметной области одним или несколькими программными средствами (Rational Rose, Erwin, BPwin и др.);

• ограничение или расширение использования отдельных элемен­тов для выбранной методологии анализа или выбранного программного средства, поддерживающего эту методологию. На­пример, для объектно-ориентированного анализа, выполняе­мого с помощью Rational Rose, использование диаграмм состояний (State Diagram), диаграмм последовательности (Sequence Diagram);

• правила хранения проектно-аналитической документации (ПАД), правила кодирования имен файлов.

Например, всю проектно-аналитическую документацию стандар­та на хранение одна из фирм — разработчиков банковского программного обеспечения разделила на следующие типы документов:

• Постановка задачи;

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

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

• Аналитическая записка;

• Описание технологий;

• Настройки;

• Консалтинговый документ;

• Маркетинговый документ;

• Нормативный документ;

• Внутренний регламент банка;

• Внешний документ;

• Организационный документ;

• Рабочий документ.

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

Шапка.

Наименование постановки, код постановки

Автор, дата создания

Модифицировавший сотрудник, дата модификации

Тело постановки

Первичные данные для постановки:

Описание бизнес-процессов:

Постановка задачи:

Ограничения, допущения

Изменение в структуре данных

Изменение в структуре классов

Основная часть постановки

Приложения

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

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

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

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

• Правила именования основных элементов модели системы (например, стереотип, класс, метод, форма, переопределение методов и пр.).

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

• Документирование исходного кода.

• Регламент отладки программы. Использование заглушек, драйверов, отладочного протокола.

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

• Визуальный интерфейс. Регламентирует использование элементов интерфейса, их взаимное расположение, выравнивание на экране

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

• Регламент проектирования базы данных.

• Регламент работы с программным обеспечением, используемым при разработке (среда разработки, компиляторы и пр.).

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

• Ведение версий разрабатываемого программного обеспечения.

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

• стандарт на разработку методики тестирования;

• стандарт на разработку и создание карт тестирования;

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

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

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

Лекция 5. Общая характеристика состояния в области документирования программных средств

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

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

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

Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы:

• Что должно быть сделано, кроме собственно программы?

• Что и как должно быть оформлено в виде документации?

• Что передавать пользователям, а что — службе сопровождения?

• Как управлять всем этим процессом?

• Что должно входить в само задание на программирование?

На эти и другие вопросы когда-то отвечали государственные стан­дарты на программную документацию — комплекс стандартов 19-й серии ГОСТ ЕСПД. Но уже тогда у программистов была масса пре­тензий к этим стандартам.

Основу отечественной нормативной базы в области докумен­тирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы 20 века. Сейчас этот комплекс представляет собой систему межгосудар­ственных стандартов стран СНГ (ГОСТ), действующих на тер­ритории Российской Федерации на основе межгосударственного соглашения по стандартизации.

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

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

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

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

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

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

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

• Тем не менее, до пересмотра всего комплекса многие стандар­ты могут с пользой применяться в практике документирования ПС.

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

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

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

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

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

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

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

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

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

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

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

В ЕСПД входят следующие ГОСТы:

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

ГОСТ 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 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

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

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

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

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

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

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

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

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

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

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

ГОСТ подразделяет программы на следующие виды:

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

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

Рассмотрим виды про­граммных документов и их содержание:

Спецификация — содержит состав программы и документа­цию на нее.

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

Текст программы — представляет запись программы с необ­ходимыми комментариями.

Описание программы — содержит сведения о логической струк­туре и функционировании программы.

Программа и методика испытаний — содержит требования, подлежащие проверке при испытании программы, а также поря­док и методы их контроля.

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

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

Эксплуатационные документы — содержат сведения для обес­печения функционирования и эксплуатации программы.

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

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

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

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

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

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

- Научно-исследовательские работы;

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

2.Эскизный проект

-Разработка эскизного проекта;

-Утверждение эскизного проекта.

3. Технический проект

- Разработка технического проекта;

- Утверждение технического проекта.

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

- Разработка

- Разработка программы

- Испытания программы

5. Внедрение

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

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

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

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

Титульная часть оформляется согласно ГОСТ 19.104-78.

Информационная часть должна состоять из аннотации и со­держания.

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

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

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

Техническое задание должно содержать следующие разделы:

- введение;

- основания для разработки;

- назначение разработки;

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

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

- технико-экономические показатели;

- стадии и этапы разработки;

- порядок контроля и приемки;

- в техническое задание допускается включать приложения.

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

Данный стандарт определяет состав и требования к содержа­нию программного документа «Описание программы». Описание программы включает:

1. Общие сведения.

2. Функциональное назначение.

3. Описание логической структуры.

4. Используемые технические средства.

5. Вызов и загрузка.

6. Входные данные.

7. Выходные данные.

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

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

1. Введение.

2. Назначение и область применения.

3. Технические характеристики.

4. Ожидаемые технико-экономические показатели.

5. Источники, использованные при разработке.

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

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

1. Общие сведения о программе.

2. Структура программы.

3. Настройка программы.

4. Проверка программы.

5. Дополнительные возможности.

6. Сообщения системному программисту.

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

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

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

2. Характеристики программы.

3. Обращение к программе.

4. Входные и выходные данные.

5. Сообщения.

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

Руководство оператора должно включать:

1. Назначение программы.

2. Условия выполнения программы.

3. Выполнение программы.

4. Сообщения оператору.

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

При описании языка необходимо указать:

1. Общие сведения.

2. Элементы языка.

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

3. Способы структурирования программы.

4. Средства обмена данными.

5. Встроенные элементы.

6. Средства отладки программы.

Лекция 6. Государственные стандарты Российской Федерации