
- •А. М. Минитаева разработка и стандартизация программных средств и информационных технологий
- •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.5. Внутрифирменные (внутрикорпоративные) стандарты
Внутрифирменные стандарты действуют внутри организации – разработчика программного обеспечения или любой другой компании, связанной с информационными технологиями. Такие стандарты, как правило, регламентируют порядок оформления документации, приказов и технической литературы внутри компании, пользовательский интерфейс разрабатываемых приложений (например, запрет на использование некоторых элементов интерфейса), стиль программирования, спецификацию модулей, имена используемых переменных, таблиц баз данных (БД). Внутрикорпоративные (внутрифирменные) стандарты имеют узкую сферу полномочий (одна или несколько фирм), но играют большую роль, так как они абсолютно конкретны [3].
Назначение и классификация внутрикорпоративных стандартов. Внутрифирменные (внутрикорпоративные) стандарты регламентируют технологические процессы, происходящие внутри фирмы (например, процессы анализа, кодирования, тестирования), они максимально конкретны и, если пользоваться управленческой терминологией детализируют уровень мероприятий.
Внутрифирменные стандарты, как правило, базируются на применении методик и технологий. Вместе с тем внутрифирменные стандарты учитывают особенности предприятия – разработчика программного обеспечения. Его конкретные особенности связаны со средством разработки, на котором кодируется программное средство, квалификацией персонала, финансовым положением фирмы.
Существуют общие подходы, известны технологии разработки внутрикорпоративных стандартов, но всякий раз этот процесс уникален, поскольку не существует двух совершенно одинаковых предприятий – они различаются отраслевой спецификой, размерами, стратегией, организационной структурой и многими другими факторами. Кроме того, документы, особенно относящиеся к внутреннему документообороту, различаются в силу устоявшихся бизнес-правил, традиций, корпоративной культуры, отношений между подразделениями. Внутрикорпоративные стандарты, разработанные для одного предприятия, не подойдут для другого. Поэтому типового внутрикорпоративного стандарта просто не может быть. При этом следует различать структуру бизнес-процессов, которая действительно может быть типовой, и внутрикорпоративный стандарт, согласующий структуру бизнес-процессов и организационную структуру конкретного предприятия.
Любой внутрикорпоративный стандарт должен иметь юридическую силу внутри предприятия, должен быть оформленным в виде документа и быть введенным в действие приказом или распоряжением. Это особенно важно в сфере информационных технологий, где развитие технологий и их смена идут очень быстро. Этого можно избежать, если разработать внутри фирмы механизм регулярного пересмотра стандарта для включения в него современных и передовых элементов. В комиссию по пересмотру стандартов должны входить специалисты высокой квалификации из всех заинтересованных подразделений, мнение конечного потребителя также должно быть учтено (например, если вопрос касается пользовательского интерфейса или совместимости с другими программными средствами).
Классификация внутрифирменных стандартов. Внутрифирменные стандарты можно разделить по отношению к процессам производства (рис. 2.4).
Рис. 2.4. Схема классификации внутрифирменных стандартов
Производственные стандарты – те стандарты, которые регламентируют процессы производства программного обеспечения по этапам и стадиям жизненного цикла.
Управленческие стандарты регламентируют порядок управления производственными процессами.
За счет внутрифирменных стандартов достигаются лучшие показатели обучения персонала, повышаются надежность и качество программного обеспечения; повышается дружественность программного продукта, сокращаются сроки обучения конечного пользователя, улучшается обслуживание, сокращаются сроки внедрения программного продукта.
Таким образом, внутрифирменный стандарт представляет собой структурированное формализованное описание бизнес-процессов. Цель его разработки - перепроектирование бизнес-процессов, обеспечивающих повышение качества работы предприятия и рост его конкурентоспособности, устранение ненужных функций, дублирование процессов, уточнение организационной структуры, улучшение организации документооборота, пересмотр содержания и количества документов, определение календарного графика подготовки документов, постановка задачи для автоматизации деятельности предприятия. Как показывает опыт, имеет смысл разрабатывать стандарт в том случае, когда требуется согласовать деятельность по разработке документов нескольких подразделений [3].
В целом внутрифирменный стандарт представляет собой текстовый документ с приложениями в виде диаграмм и таблиц. Для разработки дерева задач удобно использовать инструментальные средства, такие, как Design/IDEF или BPwin. Сетевой график удобно проектировать с использованием Microsoft Project или Time Line. Если внедрением стандарта документооборота занимаются сотрудники предприятия, а не внешние консультанты, у них могут возникнуть проблемы чтения и трактовки диаграмм. В этом случае а самом документе лучше использовать упрощенные средства изображения. Дерево задач может быть приведено без использования методологии IDEF0, в виде нумерованного списка. Сетевой гpaфик может отсутствовать, а вместо него следует предусмотреть календарный график подготовки документов. Так удобно поступать в том случае, когда известна контрольная дата, и она неизменна (например, разработка планов на следующий год).
От внедрения внутрифирменных стандартов руководители ожидают оптимизации бизнес-процессов, в результате чего сотрудникам будут делегированы четкие полномочия при упорядочении документооборота, определении актуальности данных, для улучшения работы с поставщиками и заказчиками. Самое главное, это изменения корпоративной культуры: роста инициативности подчиненных; переориентации на результат деятельности.