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

Борис Аронович Позин, директор департамента консалтинга и методологии создания ПО информационных систем компании АйТи, с ним можно связаться по адресу bpozin@it.ru
Эту статью можно рассматривать как своего рода «промежуточное завершение» большой серии публикаций на тему стандартов в проектировании ИС, которую представлял в нынешнем и в прошлом году «Директор» (статья при этом выражает — как и всегда, если не указано иное, — мнение автора). Но она же дает толчок к публикации других, может быть, более частных, но и более конкретных материалов по данному направлению.

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

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

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

Именно поэтому перед ответственными лицами возникают естественные вопросы:

  • Кому и зачем нужны стандарты?
  • Какова структура нормативной базы предприятия и как ее выбрать?
  • Всё ли надо стандартизировать?
  • Нужно ли пользоваться международными стандартами или разрабатывать свои, российские?

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

Кому и зачем нужны стандарты?

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

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

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

Стандартизация выгодна всем: и производителям, и потребителям ИС. Она позволяет потребителям ИС:

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

Итак, стандарты нужны:

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

Какова структура нормативной базы предприятия и как ее выбрать?

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

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

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

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

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

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

Конечно, в каждом конкретном случае проблемы, решаемые директором ИТ-службы или руководителем разрабатывающего коллектива, различаются.

Рассмотрим основные принципы формирования нормативной базы (с акцентом на разработку, сопровождение и развитие ПО ИС).

Цели, задачи и состав нормативно-методического обеспечения

Нормативно-методическое обеспечение (НМО) представляет собой комплекс документов, регламентирующих:

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

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

Основными задачами НМО являются:

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

В состав НМО входят стандарты и руководящие документы, методики выполнения сложных операций, шаблоны проектных и программных документов (см. рисунок).

Рис.1 Состав нормативно-методического обеспечения

Все входящие в состав НМО документы должны быть определены по:

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

Нормативное обеспечение должно определять:

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

Все ли надо стандартизировать?

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

Объекты, подлежащие регламентации, можно подразделить на две большие группы:

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

Соответственно, целесообразно рассматривать:

  • элементы НМО, относящиеся к конструкции ИС: общая архитектура, протоколы, интерфейсы;
  • процессы создания, интеграции, сопровождения, развития, обслуживания, эксплуатации ИС и т. д.

Областью действия элементов НМО может быть вся организация либо отдельный проект.

Все входящие в состав НМО документы должны быть определены по:

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

В качестве объектов регламентации и методического обеспечения могут выступать:

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

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

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

Нормативно-методическая документация должна регламентировать и методически поддерживать процессы жизненного цикла по ГОСТ Р ИСО/МЭК 12207-99, в первую очередь: планирование проектных работ, управление графиком и ресурсами для их выполнения; метрики и методики оценки трудоемкости работ на всех стадиях выполнения проекта; управление рисками; управление качеством ПО; управление требованиями; конфигурационное управление; управление изменениями; тестирование ПО; порядок испытаний; документирование.

Заметим, что не все документы, входящие в состав НМО, являются стандартами. Стандартизации подлежат только объекты и процессы, характерные для предприятия в целом, прошедшие длительную апробацию, проверку временем. Такие документы закрепляются в виде стандартов предприятия. Гораздо больший объем составляют руководящие и методические документы. Они просто регламентируют отдельные объекты или процессы для упорядочения работ.

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

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

Нужно ли пользоваться международными стандартами или разрабатывать свои, российские?

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

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

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

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

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

Нормативной базой НМО являются прежде всего следующие международные и отечественные стандарты в области информационных технологий:

  • стандарты ИСО/МЭК;
  • стандарты IEEE;
  • стандарты OMG;
  • стандарты ГОСТ Р;
  • стандарты организациии-заказчика.

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

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

Состав и статус дополнительных стандартов

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

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

  • порядок инициации проекта и разработки ПО;
  • порядок приемки ПО;
  • порядок внедрения и эксплуатации;
  • порядок постановки работ по сопровождению;
  • состав выпускаемых программных документов и их соответствие ГОСТ Р.

В этих нормативных документах не должно быть привязки к конкретным проектам, системам или платформам.

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

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

Методические документы и шаблоны

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

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

Методические документы могут описывать по составу и содержанию работ следующие процессы:

1) вспомогательные процессы (ГОСТ Р ИСО/МЭК 12207-99) — документирование (определяет действия для записи информации, являющейся результатом выполнения какого-либо процесса жизненного цикла); управление конфигурацией; обеспечение качества (определяет действия для достижения гарантии, что программные продукты и процессы соответствуют заданным требованиям);

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

Методические документы, как правило, регламентируют следующие аспекты выполнения проектов программных средств и управления этими проектами:

1) функциональная схема технологических процессов для каскадного и спирального жизненных циклов.

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

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

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

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

Регламентирующие документы

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

Заключение

В статье мы попытались дать общее описание работ по созданию и использованию НМО заказывающими и разрабатывающими организациями. Многие могут сказать: «Зачем такая страсть - ведь живем же без этого».

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

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

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

P.S. Кто должен разрабатывать стандарты?

Здесь есть два аспекта: стратегический и тактический.

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

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

Стандарты, рекомендуемые в качестве первоочередных

В части регламентации процессов предприятия

1. IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology.

2. ГОСТ Р ИСО МЭК 12207-99. Информационные технологии. Процессы жизненного цикла программного обеспечения.

3. IEEE 1074. Жизненный цикл разработки программных средств.

4. ИСО/ТО 10006:1997 (R). Менеджмент качества. Руководство качеством при административном управлении проектами.

5. ISO 15846, ISO 10007. Стандарты по менеджменту конфигурации программных средств.

6. ISO 9000 - 2000; группы ГОСТ Р 9000х.

7. ISO/IEC TR 15504. Оценка процессов жизненного цикла ПО (Information technology - Software process assessment).

В части порядка разработки и документирования ИС и ПО

8. ГОСТ 34.ххх. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы.

9. ГОСТ 19.ххх. Единая система программной документации.

10. IEEE 1063-1987. Standard for Software User Documentation.

11. IEEE 830-1994. Рекомендуемая практика формирования спецификаций программного обеспечения.

12. IEEE 829. Планирование тестирования программных средств.

13. DoD STD 2167A. Разработка программного обеспечения оборонных систем.

В части качества программных средств

14. ГОСТ 28806. Качество программных средств. Термины и определения.

15. ГОСТ 28195. Оценка качества программных средств. Общие положения.

16. ГОСТ 9126. Информационная технология. Оценка программного продукта. Характеристики качества и руководящие указания по их применению.