Управление сетями связи

Базовые международные стандарты в ИТ

ISO/IEC 12207:1995.. Информационная технология. Процессы жизненного цикла программного обеспечения.
ISO/IEC 9126-1:2000. Информационная технология. Качество программного обеспечения. Часть 1: Модель качества.
ISO/IEC 9126-1-3: 1998. Информационная технология — Характеристики и метрики качества программного обеспечения:
Часть 1. Характеристики и подхарактеристики качества; Часть 2. Внешние метрики Часть 3. Внутренние метрики (Первое издание).
ISO/IEC 9126:1991. Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению.
ISO/IEC 12119:1994. Информационная технология. Пакеты программ. Требования к качеству и оценка качества.
ISO/IEC 14598-1:1997. Информационная технология. Оценивание программного продукта. Часть 1: Общее руководство.
ISO/IEC 14598-4:1999. Информационная технология. Разработка программных средств. Процессы для заказчика.
ISO/IEC 15288: 2000. Управление жизненным циклом. Процессы жизненного цикла системы.
ISO 687:1983. ИТ. Управление конфигурацией программного обеспечения.
ISO 6592:1985. Информационная технология. Руководство по документации для вычислительных систем.
ISO 6592:1986. ОИ. Руководство по документации для вычислительных систем.
ISO 9127:1987. ИТ. Пользовательская и рекламная документация на пакеты программ.
ISO 9294:1990. TO. ИТ. Руководство по управлению документированием программного обеспечения.
ISO 15846:1998. ТО. Процессы жизненного цикла программных средств. Конфигурационное управление программными средствами.
MIL-STD-498:1994. Разработка и документирование программного обеспечения.
ISO TR 9127:1988. Системы обработки информации — Документация пользователя и сопроводительная информация для пакетов программ потребителя.
ISO 14102:1995. Информационная технология — Оценивание и выбор инструментальных средств CASE.
IEEE 1063-1993. Пользовательская документация на программное обеспечение.
IEEE 1074-1995. Процессы жизненного цикла для развития программного обеспечения.
ANSI/IEEE 828 — 1990. Планирование управления конфигурацией программного обеспечения.
ANSI/IEEE 829 — 1983. Документация при тестировании программ.
ANSI/IEEE 983 — 1986. Руководство по планированию обеспечения качества программных средств.
ANSI/IEEE 1008 — 1986. Тестирование программных модулей и компонентов ПС.
ANSI/IEEE 1012 — 1986. Планирование проверки (оценки) (verification) и подтверждения достоверности (validation) программных средств.
ANSI/IEEE 1042 — 1993. Руководство по планированию управления конфигурацией программного обеспечения.
ANSI/IEEE 1063:1993. Пользовательская документация на программные средства .
ANSI/IEEE 1219 — 1992. Сопровождение программного обеспечения.
ISO 8402:1994. Управление качеством и обеспечение качества – Словарь. Второе издание.
ISO 9000-3:1997. Стандарты в области административного управления качеством и обеспечения качества.
Часть 3. Руководящие указания по применению ISO 9001 при разработке, поставке, монтаже и обслуживании программного обеспечения. Второе издание.

Особенности и целесообразность разработки стандартов организации

Разработка и внедрение стандартов организации осуществляется только при выполнении условий, что описаны в статье 17 Федерального Закона Российской Федерации «О техническом регулировании». Стандарты организации не должны противоречить требованиям национальных стандартов и технических регламентов, которые разработаны для ее сферы деятельности.

Замечание 1

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

Объектами стандартов организации могут быть:

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

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

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

При разработке стандартов организации нельзя устанавливать параметры, требования, характеристики и другие показатели, которые противоречат национальным стандартам. Те стандарты, что обеспечивают применение ИСО, МЭК и других международных организаций, к которым присоединилась РФ, а также стандарты, что разработаны для обеспечения реализации международных обязательств государства, также не должны противоречить национальным.

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

Порядок разработки, учета, изменения, утверждения стандартов организации устанавливаются ими самостоятельно с учетом требований статей 11 и 12 Федерального закона РФ «О техническом регулировании». Организации могут сами регулировать и устанавливать порядок тиражирования, хранения, распространения и ликвидации тех стандартов, что утверждены ими.

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

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

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

Замечание 2

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

MOF (Microsoft Operations Framework)

— Управление информационными технологиями эта тема, в которой компания Microsoft имеет свое видение. Система стандартов Microsoft Enterprise Services от компании Microsoft представляет собой три области:

Первой областью является деятельность по подготовке к внедрению информационной системы где формализуются требования к ИТ и определяется объем проекта. Подготовка к внедрению информационной системы описана в стандарте Microsoft Readiness Framework (MRF);
Второй областью является деятельность по внедрению информационной системы на предприятии, где определяются основные вопросы разработки и развертывания ИТ- решения. Построение и внедрение информационной системы описано в стандарте Microsoft Solutions Framework (MSF);
Третьей областью является деятельность по поддержке информационной системы внедренной на предприятии. Вопросы эксплуатации информационной системы рассматриваются в стандарте Microsoft Operations Framework (MOF).

MOF состоит из набора статей (white papers), руководств (operations guides), обучающих курсов и включает в себя три основные модели:

Модель процессов (MOF Process Model); o Модель команды (MOF Team Model);
Модель управления рисками (MOF Risk Model).

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

Зачем нужны стандарты

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

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

Нужно также учитывать, что в любом проекте есть свои нюансы и особенности, поэтому стандарты не следует применять слепо, их надо использовать «как образец», как ориентир в современном мире ИТ.

1 Статья написана по материалам V консультационно-практической конференции «Современные концепции управления предприятием и информационные технологии» (Киев, 2006).

2 Методология управления проектами PRINCE/PRINCE2 является де-факто стандартом в Великобритании, и ее применение обязательно в государственных проектах. Название методологии является аббревиатурой от Projects In Controlled Environments и отражает ее предназначение — управление проектами и группами проектов внутри организации.

ITPM (IT Process Model)

– это стандарт, который был предложен компанией IBM в конце 70-х годов прошлого века для решения задач управления компьютерными системами. Была создана архитектура ISMA (Information Systems Management Architecture) и концепция (IT Process Model), возникшая из ISMA и принятая к использованию компанией IBM. Данный подход отличается от ITIL не только по способу деления процессов, но и в ряде терминологических моментов. Фактически IT Process Model — это 41 процесс, собранный в восемь групп по числу основных факторов, влияющих на успех ИТ- проектов:

Взаимодействие с клиентами;
Обеспечение управленческих систем корпоративной информацией;
Управление ИТ с точки зрения бизнеса;
Подготовка решений;
Развертывание решений;
Предоставление услуг и управление изменениями;
Поддержка ИТ-услуг и решений;
Управление ИТ-ресурсами и инфраструктурой.

Однако, если говорить о практике использования данной модели в России, то она используется достаточно редко. ISO 20000 – один из новых стандартов в области менеджмента качества, который вобрал в себя с незначительными изменениями большинство основных принципов и процессов ITIL. В настоящий момент времени производится сертификация ИТ – подразделений на соответствие сервис -ориентированному и процессному подходу в области управления ИТ с использованием данного стандарта.

Стандартизация 3D-печати в России

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

Впрочем, скорость разработки стандартов – лишь часть проблемы, поскольку даже вышедший стандарт может оказаться рамочным. Как заявил глава Росстандарта Алексей Абрамов: «Невостребованные промышленностью новые стандарты могут отрицательно влиять на внедрение инноваций».

Технология процесса разработки стандартов организации

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

Главными целями создания и внедрения стандартов организации считаются:

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

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

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

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

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

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

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

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

Российские стандарты ГОСТ в области ИТ

ГОСТ Р ИСО МЭК 12207-99. Информационные технологии. Процессы жизненного цикла программного обеспечения.
ИСО/ТО 10006:1997 (R). Менеджмент качества. Руководство качеством при административном управлении проектами.
ГОСТ 34.ххх. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы.
ГОСТ 19.ххх. Единая система программной документации.
ГОСТ 28806. Качество программных средств. Термины и определения.
ГОСТ 28195. Оценка качества программных средств. Общие положения.
ГОСТ 9126. Информационная технология. Оценка программного продукта.
Характеристики качества и руководящие указания по их применению.

Стандарты IEEE в области IT

IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
IEEE Std 730-1989, IEEE Standard for Software Quality Assurance Plans (ANSI)
IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Plans (ANSI)
IEEE Std 828-1990, IEEE Standard for Software Configuration Management Plans (ANSI)
IEEE Std 829-1983 (Reaff 1991), IEEE Standard for Software Test Documentation (ANSI)
IEEE Std 830-1993, IEEE Recommended Practice for Software Requirements Specifications (ANSI)
IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI)
IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI)
IEEE Std 990-1987 (Reaff 1992), IEEE Recommended Practice for Ada As a Program Design Language (ANSI)
IEEE Std 1002-1987 (Reaff 1992), IEEE Standard Taxonomy for Software Engineering Standards (ANSI)
IEEE Std 1008-1987 (Reaff 1993), IEEE Standard for Software Unit Testing (ANSI)
IEEE Std 1012-1986 (Reaff 1992), IEEE Standard for Software Verification and Validation Plans (ANSI)
IEEE Std 1016-1987 (Reaff 1993), IEEE Recommended Practice for Software Design Descriptions (ANSI)
IEEE Std 1016.1-1993, IEEE Guide to Software Design Descriptions (ANSI)
IEEE Std 1028-1988 (Reaff 1993), IEEE Standard for Software Reviews and Audits (ANSI)
IEEE Std 1042-1987 (Reaff 1993), IEEE Guide to Software Configuration Management (ANSI)
IEEE Std 1044-1993, IEEE Standard Classification for Software Anomalies (ANSI)
IEEE Std 1044.1-1995, IEEE Guide to Classification for Software Anomalies (ANSI)
IEEE Std 1045-1992, IEEE Standard for Software Productivity Metrics (ANSI)
IEEE Std 1058.101987, IEEE Standard for Software Project Management Plans (ANSI)
IEEE Std 1059-1993, IEEE Guide for Software Verification and Validation Plans (ANSI)
IEEE Std 1061-1992, IEEE Standard for a Software Quality Metrics Methodology (ANSI)
IEEE Std 1062-1993, IEEE Recommended Practice for Software Acquisition (ANSI)
IEEE Std 1063-1987 (Reaff 1993), IEEE Standard for Software User Documentation (ANSI)
IEEE Std 1074-1995, IEEE Standard for Developing Software Life Cycle Processes (ANSI)
IEEE Std 1074.1-1995, IEEE Guide for Developing Software Life Cycle Processes (ANSI)
IEEE Std 1175-1991, IEEE Standard Reference Model for Computing System Tool Interconnections < (ANSI)
Tools CASE of Selection and Evaluation the for Practice Recommended IEEE 1209-1992, Std>
IEEE Std 1219-1992, IEEE Standard for Software Maintenance (ANSI)
IEEE Std 1220-1994, IEEE Trial-Use Standard for the Application and Management of the Systems Engineering Process
IEEE Std 1228-1994, IEEE Standard for Software Safety Plans (ANSI)
IEEE Std 1233-1996, IEEE Guide for Developing of System Requirements Specifications
IEEE Std 1298-1992 (AS 3563.1-1991), IEEE Software Quality Management System, IEEE Part 1: Requirements (ANSI)
IEEE Std 1348-1995, IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools (ANSI)
IEEE Std 1420.1-1995, IEEE Standard for Information Technology — Software Reuse —
Data Model for Reuse Library Interoperability: Basic Interoperability Data Model (BIDM) (ANSI)
IEEE Std 1420.1a-1996, IEEE Supplement to Standard for Information Technology — Software Reuse —
Data Model for Reuse Library Interoperability: Asset Certification Framework
IEEE Std 1430-1996, IEEE Guide for Information Technology — Software Reuse —
Concept of Operations for Networks of Interoperability Reuse Libraries
J-STD-016-1995 (IEEE Std 1498-1995), EIA/IEEE Interim Standard for Information Technology —
Software Life Cycle Processes — Software Development Acquirer — Supplier Agreement (Issued for Trial Use).

Влияние стандартизации на успех ИТ-проектов

Использование стандартов в реальных проектах может оказать как положительное, так и отрицательное влияние на результат проекта — все зависит от того, кто и как использует стандарты. Если «инструмент» находится в умелых руках, то можно ожидать:

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

В то же время излишняя «зарегулированность» может не дать проекту динамично развиваться и даже привести к его краху.

Следует заметить, что роль стандартов на разных стадиях развития системы управления предприятием и на разных стадиях ИТ-проекта различна.

Отечественным предприятиям на данном этапе их развития наибольший эффект дает использование стандартов на ранних стадиях — на стадиях выбора и планирования проекта. Это обосновано тем, что ИТ-проекты — это особый вид проектов, они не являются «стандартным» видом деятельности даже для проектно-ориентированных компаний. То есть любая компания, начинающая ИТ-проект, сталкивается с ситуацией полной неопределенности — а что будет происходить с проектом? Как он будет развиваться? К чему приведут изменения?

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

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

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

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

Для исполнителя стандарты проекта:

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

COBIT (Control Objectives for Information and related Technology)

– стандарт управления и аудита в области информационных технологий. Основой стандарта COBIT являются 34 высокоуровневые цели контроля, по одной на каждый ИТ- процесс, которые сгруппированы в 4 домена: Планирование и Организация, Проектирование и Внедрение, Эксплуатация и Сопровождение, Мониторинг. Особенностью стандарта COBIT по отношению к другим стандартам в области ИТ является присутствие в нем модели зрелости разработанной в конце 80-х годов Институтом проектирования и разработки программного обеспечения (Software Engineering Institute’s). Maturity Models (MM) – не технология, не стандарт, для нее нет формальных описаний, в ней нет жестких требований, и она не привязана к конкретным информационным технологиям. Однако данная модель зрелости вводит понятие нескольких уровней зрелости процессов:

Не существует. Полное отсутствие каких-либо процессов управления ИТ. Организация не признает существования проблем в ИТ, которые нужно решать, и, таким образом;
Начало. Организация признает существование проблем управления ИТ и необходимость их решения. При этом не существует никаких стандартизованных решений;
Повторение. Существует всеобщее осознание проблем управления ИТ. Показатели деятельности и ИТ-процессов находятся в развитии, охватывая процессы планирования, функционирования и мониторинга ИТ;
Описание. Необходимость действовать в соответствии с принципами управления ИТ понимается и принимается. Процедуры стандартизованы и документированы;
Управление. Существует полное понимание проблем управления ИТ на всех уровнях организации, постоянно происходит обучение сотрудников. Четко распределена ответственность, установлен уровень владения процессами;
Оптимизация. В организации существует углубленное понимание управления ИТ, проблем и решений ИТ, а также перспектив. В результате непрерывного улучшения процессы соответствуют моделям зрелости, построенным на основании «лучшей практики».

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