- •А. М. Минитаева разработка и стандартизация программных средств и информационных технологий
- •Isbn 978-5-8149-1063-9 введение
- •1.2. Какова структура нормативной базы предприятия и как ее выбрать?
- •1.3. Цели, задачи и состав нормативно-методического обеспечения
- •Все ли надо стандартизировать?
- •1.4. Нужно ли пользоваться международными стандартами или разрабатывать свои, российские?
- •Состав и статус дополнительных стандартов.
- •P.S. Кто должен разрабатывать стандарты?
- •1.5. Почему возрастает роль технологии при разработке программного обеспечения?
- •1.6. Стандартизация в области технологии разработки по
- •2. Общие положения о стандартах
- •2.1. Нормативные документы по стандартизации и виды стандартов
- •2.2. Стандарты в области программного обеспечения
- •2.3. Международные организации, разрабатывающие стандарты
- •2.4. Национальные организации, разрабатывающие стандарты
- •2.5. Внутрифирменные (внутрикорпоративные) стандарты
- •2.6. Организация разработки внутрифирменных стандартов
- •2.7. Хранение аналитической информации
- •3. Стандартизация разработки программных средств
- •3.1. Характеристики процессов жц пс согласно гост р исо/мэк 12207
- •3.2. Основные процессы жизненного цикла программного продукта
- •3.3. Вспомогательные (поддерживающие) процессы жизненного цикла программного продукта
- •3.4. Организационные процессы жизненного цикла программного продукта
- •3.5. Взаимосвязь между процессами жизненного цикла программного продукта
- •3.6. Технология разработки программного обеспечения
- •4. Жизненный цикл программного продукта
- •4.1. Общие принципы стандартизации жизненного цикла программных средств
- •4.2. Понятие жизненного цикла программного продукта
- •5. Модели жизненного цикла разработки программного продукта
- •5.1. Общие принципы моделирования жизненного цикла программных средств
- •5.2. Понятие модели жизненного цикла разработки программного продукта
- •5.3. Классическая каскадная, или «водопадная» модель
- •5.4. Модифицированная каскадная, или модель «водоворота»
- •5.5. Модель «сделал-исправил»
- •5.6. Прототипирование
- •5.7. Спиральная модель жц пс
- •5.8. Другие модели жц пс
- •5.9. Модель быстрой разработки приложений (rad-модель)
- •5.10. Многопроходная модель
- •6. Проектирование программного продукта
- •6.1. Общая характеристика и компоненты проектирования
- •6.2. Эволюция разработки программного продукта
- •6.3. Структурное программирование
- •6.4. Объектно-ориентированное проектирование
- •7. Основные этапы работы по созданию программного продукта
- •7.1. Длительность основных этапов
- •7.2. Характеристика основных этапов
- •Библиографический список
2.6. Организация разработки внутрифирменных стандартов
Разработка внутрифирменных стандартов должна проводится с привлечением владельцев бизнес-процессов (персонала). Необходим аналитик, постановщик задачи. Общее руководство осуществляется директором предприятия, который инициирует работы по проведению реинжиниринга и оказывает содействие в их реализации.
Приведем последовательность разработки внутрифирменного стандарта.
Определение дерева задач (оглавления стандарта).
Определение типовых форм для каждой задачи.
Группировка задач по разделам осуществляется логически, причем в соответствии с рекомендациями функциональной декомпозиции IDEF0 рекомендуется на одном уровне располагать от 2 до 8 задач.
Очень важно выбрать подходящий критерий декомпозиции. Группировать задачи можно различными способами, например, по функциональным областям; по последовательности создания документов; в соответствии со сложившимися правилами подготовки документа и др.
В том случае, когда не планируются кардинальные изменении бизнес-процессов, могут использоваться традиционные документы и неизменные исполнители, стоит лишь исключать дублирование функций. Если речь идет о перепроектировании, то на этом этапе следует очень тщательно подойти к отбору релевантных задач и выбрать показатели, характеризующие состояние и поведение экономических объектов. Рекомендуется подумать о целесообразности включения в стандарт тех или иных показателей.
После того, как определен набор документов для включения в стандарт, рекомендуется разработать матрицу ответственности, где указываются исполнители, а также должности лиц, согласующих и утверждающих документы.
На следующем этапе следует определить структуру документов, если это не было сделано ранее.
Затем необходимо определить показатели. Здесь существует определенная сложность: не следует путать экономические объекты, экономические показатели и их значения. Для исходящих показателей необходимо определить источники информации.
Определив источники данных для показателей всех форм, разработчик внутрифирменного стандарта может разработать матрицу вхождения показателей, которая является исходным материалом для определения предшествующих задач. А это, в свою очередь, необходимая информация для построения сетевого (календарного) графика.
После того, как определены предшествующие показатели, представляется возможность разработать сетевой график. В самом документе внутрифирменных стандартов вид сетевого графика не очень удобен, поэтому можно отразить последовательность подготовки задач условными номерами периодов. Так, задачи со сроком исполнения, равным двум, выполняются обязательно после задач с единичным сроком исполнения. Под номерами можно подразумевать периоды, равные одному дню, неделе, месяцу. Периоды могут быть неравномерными.
Заключительные работы по разработке внутрифирменных стандартов проводятся по составлению глоссария терминов, где должны быть представлены экономические показатели, хотя бы один раз встретившиеся в формах. Обязательно приводятся определение и краткое наименование показателя. При необходимости дается алгоритм расчета или более детализированная характеристика.
В каждом конкретном случае разработки внутрифирменных стандартов потребуется решить не только описанные, но и многие другие задачи. Но самая большая проблема, с которой столкнется разработчик, – их внедрение. Как бы хороши ни были стандарты, как бы тщательно ни прорабатывались, их реализация неизбежно вызовет сопротивление: исполнители, являющиеся владельцами бизнес-процессов, не заинтересованы в изменении должностных обязанностей. В процессе реструктуризации исполнители играют пассивную роль, хотя иногда степень сопротивления изменениям настолько высока, что пассивной эту позицию назвать сложно. В нормальных условиях на предприятии создается команда, отвечающая за результат проведения реинжиниринга. Заинтересованность участников команды прямая, поскольку существует проект, распределены обязанности, обеспечивается контроль за проведением работ, распределяется финансирование [3].
Разработка и внедрение внутрифирменных стандартов – трудоемкие процессы, но в их результате оптимизируются бизнес-процессы, уточняется организационная структура, осуществляется постановка задачи формирования единого информационного пространства. Все эти факторы повышают качество деятельности предприятия, что непосредственно влияет на его конкурентоспособность. Рассмотрим внутрифирменные стандарты в разрезе наиболее распространенных процессов разработки программного обеспечения: анализ и проектирование; кодирование; тестирование; документирование; внедрение; поддержка.
Общие стандарты, как правило, регламентируют общие моменты, связанные со вспомогательными процессами, касающимися деятельности, осуществляемой на фирме. Общие стандарты обычно регламентируют правила общения с клиентами компании, а также сотрудников внутри компании. Такой стандарт может содержать, например, правило формирования подписи электронного письма, состав реквизитов и порядок их следования. Также содержат перечень программного обеспечения, предназначенного для регулярного использования и не связанного с особенностями работы в подразделении, например: операционная система, электронная таблица, текстовый процессор, архиватор и др.
Очень важный момент, который обычно регламентируется общими стандартами, – это рабочее пространство для каждого подразделения. Под рабочим пространством понимается набор носителей для хранения различного рода информации со структурой каталогов и правами на них, а также правила работы с хранимой информацией.
Анализ и проектирование. Обычно для целей функционирования аналитического отдела разрабатывается ряд стандартов, которые регламентируют, как правило:
– применение методик структурного анализа или методов объектно-ориентированного анализа;
– описание бизнесс-процессов предметной области одним или несколькими программными средствами (Rational Rose, ERwin, BPwin и др.);
– ограничение или расширение использования отдельных элементов для выбранной методологии анализа или выбранного программного средства, поддерживающего эту методологию;
– правила хранения проектно-аналитической документации (ПАД), правила кодирования имен файлов.
Разработка. Стандарты разработки помогают разобраться в исходном коде программы, повышают читаемость исходного кода; использование стандартных шаблонов сокращает время разработки программного документа.
Тестирование. В процессе тестирования (особенно при применении методов белого ящика) широко используются внутрифирменные стандарты разработки программного обеспечения.
Все вышеперечисленные стандарты могут быть расширены или сужены – все зависит от конкретной необходимости для предприятия – разработчика программного обеспечения.