Стандарты в области информационных систем

изменяются не только требования к информационным системам и информационным технологиям,

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

стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на

организацию Жизненного Цикла (ЖЦ) создания и использования Автоматизированных Систем (АС) и Программного Обеспечения (ПО);
по утверждающей организации: официальные международные стандарты, официальные национальные или национальные ведомственные (например ГОСТы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (OSF, OMG, ранее широко известный CODASYL), стандарты "де-факто" (таким долгое время был SQL или язык диаграмм SADT Д. Росса), фирменные стандарты (Microsoft ODBC, IBM SNA);
по методическому источнику: методические материалы фирм-разработчиков ПО, фирм-консультантов, научных центров, консорциумов по стандартизации (например, Oracle Method, Price Waterhouse SMM, SEI CMM); они могут называться по-разному - например, "Метод", "Методология", "Подход", "Модель".

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

продуктов программного обеспечения (ПО).
Стандарты комплекса ГОСТ 34 на создание и

развитие АС.
Методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, расчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.

ПО, ориентированный на различные виды ПО и типы проектов АС,

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

действий каждой из двух сторон:
поставщик (разработчик) и покупатель (пользователь);
может

быть в равной степени применен, когда обе стороны - из одной организации.

процессов ЖЦ.
Каждый процесс разделен на набор действий, каждое действие -

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

разработки,
процесс функционирования,
процесс сопровождения

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

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

примыкает особый процесс адаптации, который определяет основные действия, необходимые для

адаптации стандарта к условиям конкретного проекта.

и задач, при которой один процесс при необходимости вызывает другой

или его часть.
Степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте.
Стандарт принципиально не содержит конкретные методы действий, тем более - заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует ее в деталях. В нем не описано как реализовать или выполнить услуги и задачи, включенные в процессы. Он не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт.

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

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

комплекс взаимоувязанных межотраслевых документов.
Объектами стандартизации являются АС различных видов и

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

Действовали следующие комплексы и системы стандартов, устанавливающие требования к различным

видам АС:
единая система стандартов автоматизированных систем управления (24-я система) для АСУ, ОАСУ, АСУП, АСУТП и др. организационно-экономических систем;
комплекс стандартов системы 23501, распространявшихся на САПР - системы автоматизированного проектирования;
четвертая группа 14-й системы стандартов, распространяющаяся на АС технологической подготовки производства.

общую схему разработки, общий набор документов с их содержанием и

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

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

и объединять стадии "Технический проект" и "Рабочая документация";
опускать этапы, объединять

и опускать большинство документов и их разделов;
вводить дополнительные документы, разделы документов и работы;
динамически создавая т. н. ЧТЗ - частные технические задания - достаточно гибко формировать ЖЦ АС; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

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

ЖЦ или близкую к ней.
4. Введение единой, достаточно качественно определенной

терминологии, наличие достаточно разумной классификации работ, документов, видов обеспечения. ГОСТ34 способствует более полной и качественной стыковке действительно разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС, например, типа CAD-CAM, которые включают в свой состав АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ и др. системы.

объекта стандартизации,
Например: "в общем случае АС состоит из программно-технических

(ПТК), программно-методических (ПМК) комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечений".
Разделение понятий ПТК и АС закрепляло принцип, по которому АС есть не "ИС с БД", но: "организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях" (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга; "система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций" (по ГОСТ 34.003-90).

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

на АС - и производится на любых последующих этапах и

с любой степенью независимости экспертизы.
7. Степень обязательности: прежняя полная обязательность отсутствует. Материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС.
8. Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).

(Custom Development Method), известной по использованию Oracle CASE (ныне Designer/2000)

и книгам Р. Баркера.
CDM теснейшим образом опирается на использование инструментария Oracle.
Согласно этой методике ЖЦ формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов.

системе;
проектирование: преобразование требований в детальные спецификации системы;
реализация: написание и тестирование

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

Исследование существующих систем,
TA - Определение технической архитектуры,
DB - Проектирование и

построение БД,
MD - Проектирование и реализация модулей,
CV - Конвертирование данных,
DO - Документирование,
TE - Тестирование,
TR - Обучение,
TS - Переход к новой системе,
PS - Поддержка и сопровождение.

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

все работы/задачи и этапы),
"быстрая разработка" (Fast Track), еще более

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

Методика не предусматривает:
включение дополнительной задачи, которой нет в CDM, и ее привязку к остальным;
дополнительное удаление задачи (и порождаемых ею документов), не предусмотренное одной из трех моделей ЖЦ;
изменение последовательности выполнения задач по сравнению с предложенной, тем более - по ходу процесса проектирования.

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

действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач.
3. Степень обязательности: методика необязательна, но может считаться фирменным стандартом; при формальном применении степень обязательности полностью соответствует ограничениям возможностей адаптации.
4. Прикладная система рассматривается в основном как программно-техническая система - например, моменты организации выполнения вполне возможных оргструктурных преобразований, реально всегда происходящих при переходе к новой АС (вовсе не имеется в виду BPR!), и соответствующего обеспечения отсутствуют в этой методике.
5. Направленность на создание информационной системы с базами данных в достаточно традиционном понимании.