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

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

организацию Жизненного Цикла (ЖЦ) создания и использования Автоматизированных Систем (АС) и Программного Обеспечения (ПО);
по утверждающей организации: официальные международные стандарты, официальные национальные или национальные ведомственные (например ГОСТы, 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

независимости проверяющего персонала от какой-либо прямой ответственности за проверяемые объекты.
Степень обязательности: после решения организации о применении 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. Направленность на создание информационной системы с базами данных в достаточно традиционном понимании.

информационных систем.
Примеры стандартов на разработку информационных систем.
Предмет стандарта ISO/IEC 12207:

1995-08-01.
На кого ориентирован стандарт ISO/IEC 12207: 1995-08-01.
Структура стандарта ISO/IEC 12207: 1995-08-01.
Особенности стандарта ISO/IEC 12207: 1995-08-01.
Предмет стандарта ГОСТ 34-601.90.
На кого ориентирован стандарт ГОСТ 34-601.90.
Структура стандарта ГОСТ 34-601.90.
Этапы стадии формирования требований к АС.
Перечислите этапы разработки концепции АС.
Перечислите этапы создания технического задания, эскизного и технического проектов.
Этапы стадии рабочая документация.
Этапы стадии ввод в действие.
Этапы стадии сопровождение АС.
Особенности стандарта ГОСТ 34-601.90.
Для каких целей был основан метод CDM.
Этапы метода CDM.
Процессы метода CDM.
Особенности метода CDM.