Стандарты и методики. Виды стандартов. Методика Oracle CDM. Стандарт ISO/IEC. 12207. Комплекс стандартов ГОCT 34

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

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

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

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

· стандарты на продукты и услуги;

· стандарты на процессы и технологии;

· стандарты на формы коллективной деятельности, или управленческие стандарты.

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

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

· по утверждающей организации. Здесь можно выделить официальные международные, официальные национальные или национальные ведомственные стандарты (например, ГОСТы, ANSI, IDEFO/l), стандарты международных консорциу­мов и комитетов по стандартизации (например, консорциума OMG), стандарты « де-факто» – официально никем не утвержденные, но фактически действующие(например, стандартом «де-факто» долгое время были язык взаимодействия с реляционными базами данных SQL и язык программирования С), фирменные стандарты (например, Microsoft ODBC);

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

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

Рассмотрим следующие стандарты и методики, касающиеся организации ЖЦ ИС и ПО:

· методика Oracle CDM (Custom Development Method) по разработке приклад­ных ИС под заказ;

· международный стандарт ISO/IEC 12207:1995-08-01 наорганизацию жизнен­ного цикла продуктов программного обеспечения;

· отечественный комплекс стандартов ГОCT 34.

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

Методика Oracle CDM.Одним из уже сложившихся направлений деятельности фирмы Oracle стала разработка методических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентированных на интенсивное использование баз данных. Методика Oracle CDM являете развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE (в новых версиях – Designer/2000).

Основу CASE-технологии и инструментальной среды фирмы ORACLE cocтавляют:

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

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

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

· наличие централизованной базы данных, репозитария, для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Такой репозитарий представляет собой базу данных специальной структуры, работающую под управлением СУБД ORACLE;

· возможность одновременной работы с репозитарием многих пользователе. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД ORACLE. Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от других;

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

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

Отметим основные особенности методики Oracle CDM, определяющие область применения и присущие ей ограничения.

1. Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:

· классическая – предусматривает все этапы;

· быстрая разработка – ориентированна на использование инструментов моделирования и программирования Oracle;

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

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

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

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

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

6. CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения о простом приспособлении CDM к проектам, в кото­рых используется другой комплект инструментальных средств.

7. Методика Oracle CDM представляет собой вполне конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах информационных систем с опорой на инст­рументальные средства и СУБД фирмы Oracle.

Международный стандарт ISO/IEC 12207: 1995-08-01.Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения».

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

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

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

В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жиз­ненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов, причем по сравнению с Oracle CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов: приобретение, поставка, разработка и.т.п. Несколько утрируя, можно сказать, что один процесс ISO 12207 сопоставим со всеми процессами Oracle CDM вместе взятыми.

Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие – на ряд задач.

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

В стандарте ISO 12207 описаны пять основных процессов жизненного цикла про­граммного обеспечения:

· процесс приобретения определяет действия предприятия-покупателя, которое приобретает информационную систему, программный продукт или службу про­граммного обеспечения;

· процесс поставки определяет действия предприятия-поставщика, которое снаб­жает покупателя системой, программным продуктом или службой программ­ного обеспечения;

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

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

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

Кроме основных, стандарт ISO 12207 оговаривает 8 вспомогательных процессов, которые являются неотъемлемой частью всего жизненного цикла программного изделия и обеспечивают должное качество проекта программного обеспечения. К вспомогательным процессам относятся: процесс решения проблем; процесс документирования; процесс управления конфигурацией; процесс обеспечения качества; процесс верификации; процесс аттестации; процесс совместной оценки; процесс аудита.

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

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

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

Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO 12207, в нем предусмотрено, что заказчик может разрабатывать автоматизированную систему для себя сам (например, создав для этого специализированное подразделение). Однако формулировки ГОСТ 34 не ориентированы на столь явное и в известном смысле симметричное отражение действий обеих сторон, это сделано в ISO 12207. Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно производится исходя из этого содержания.

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

· Основной целью разработки комплекса нормативных документов ГОСТ 34 было разрешение противоречий, возникающих при интеграции систем вследствие несогласованности нормативно-технической документации. Практика применения стандартов на ОАСУ, АСУП, АСУТП, САПР, АСТПП показала, что, по существу, в них применяется единая система понятий и есть много общих объектов стандартизации, однако требования стандартов не согласованы между собой, имеются различия по составу и содержанию работ, различия в обозначении, составе, содержании и оформлении документов. В этих условиях было решено выработать одну обобщенную понятийную и терминологическую систему, общую схему разработки, общий набор документов и их содержания и определить их как обязательные для всех автоматизирован­ных систем. Таким образом, комплекс стандартов ГОСТ 34 более близок к схемам конкрет­ных методик, чем к стандартам типа ISO 12207.

· Несмотря на достаточно большую гибкость формирования жизненного цикла, предопределенные документами ГОСТ 34 этапы и стадии разработки на прак­тике ориентируют разработчиков на каскадную схему жизненного цикла.

· Документы ГОСТ 34 определяют единую терминологию и вполне разумно классифицируют работы по созданию автоматизированной системы и документы, разрабатываемые в результате этих работ. Благодаря ГОСТ 34 упрощается ин­теграция разных систем и повышается качество систем, полученных в резуль­тате интеграции.

· Обеспечение качества согласно ГОСТ 34 определяется в техническом задании на автоматизированную систему и производится на любых последующих эта­пах и с любой степенью независимости экспертизы. В последовательности эта­пов разработки эти экспертизы располагаются несколько позже, чем в ISO 12207.

· Степень обязательности ГОСТ 34: полная обязательность отсутствует, матери­алы ГОСТ 34, по сути, являются методической поддержкой. Причем эта под­держка в значительной степени ориентирована на заказчика: в стандарте имеется набор требований к содержанию технического задания и проведению испыта­ний разработанной системы.

· Ключевым документом взаимодействия сторон является техническое задание (ТЗ) на создание автоматизированной системы. ТЗ является основным исходным документом для создания автоматизированной системы и ее приемки, оно определяет важнейшие точки взаимодействия заказчика и разработчика.

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

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

ГОСТ 34 достаточно полно и фундаментально определяет:

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

· аналитические и при необходимости исследовательские работы, направлен­ные на разработку обоснованной концепции автоматизированной системы;

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

Материалы ГОСТ 34 почти так же, как и ISO 12207, а может быть, еще более четко определяют, что автоматизированная система – это в первую очередь люди, которые выполняют свои функции с помощью информационных техно­логий.

· ГОСТ 34 благодаря своей комплексной ориентации на систему и обеспечению единой терминологии позволяет избежать ситуаций, в которых разработчики разных профессий (например, финансовые аналитики и проектировщики баз данных) «говорят на разных языках», от чего в итоге страдают цельность и глу­бина проработки проекта.

ГОСТ 34 и CDM в первую очередь ориентированы на действия по созданию и поддержке систем, a ISO 12207 – на приобретение и эксплуатацию систем (при этом разработка является процессом, логически вытекающим из приобретения).