- •Содержание
- •Тема 1: Теоретические основы проектирования информационных систем
- •Понятие ис. Структура ис
- •Основные понятия и структура проекта ис. Требования к эффективности и надежности проектных решений.
- •1.3 Жизненный цикл ис. Модели Жизненного цикла
- •Литература Основная литература:
- •Дополнительная литература
- •Тема 2. Технологии проектирования ис
- •2.1 Основные компоненты технологии проектирования ис.
- •2.2. Методы и средства проектирования ис.
- •2.3 Характеристика применяемых технологий проектирования.
- •Характеристики классов технологий проектирования
- •2.4 Требования, предъявляемые к технологии проектирования ис. Выбор технологии проектирования ис.
- •Литература Основная литература
- •Дополнительная литература
- •Тема 3. Стандарты и профили в области информационных систем
- •Классификация стандартов на проектирование и разработку информационных систем.
- •Международный стандарт iso/iec 12207: 1995-08-01
- •Основные процессы:
- •Вспомогательные процессы:
- •Организационные процессы:
- •Стандарты комплекса гост34
- •Методика Oracle cdm
- •Литература Основная литература
- •Дополнительная литература
- •Тема 4. Структурные методы анализа и проектирования ис (функционально ориентированный подход)
- •4.1 Классификация структурных методологий. Сравнительный анализ технологий.
- •Диаграммы «сущность-связь»
- •Сущности, отношения и связи в нотации Чена
- •Нотация Баркера
- •Спецификации управления
- •Этапы построения моделей в dfd – технологии
- •1.Разработка структурной функциональной модели бизнес-системы.
- •Разработка информационной модели бизнес -системы
- •Разработка событийной модели организации
- •4.3 Метод функционального моделирования sadt (idef0)
- •4.4 Метод моделирования процессов (idef3)
- •4.5 Моделирование данных (idef1x)
- •Литература Основная литература
- •Дополнительная литература
- •Тема 5. Каноническое проектирование ис
- •5.1 Стадии и этапы процесса проектирования ис.
- •5.2 Состав работ на стадиях жизненного цикла ис. Состав проектной документации.
- •5.3 Состав, содержание и принципы организации информационного обеспечения ис.
- •5.4 Проектирование пользовательского интерфейса.
- •. Реквизитный состав экранной формы
- •5.5 Проектирование документальных и фактографических баз данных
- •Литература Основная литература
- •Дополнительная литература
- •Тема 6. Автоматизированное проектирование ис
- •6.1 Основные принципы Case-технологии. Факторы эффективности Case-технологии.
- •6.2 Классификация Сase-средств проектирования и стратегия их выбора.
- •6.3 Функционально-ориентированный подход. Этапы проектирования.
- •6.4 Содержание rad-технологии прототипного создания приложений.
- •Литература Основная литература
- •Дополнительная литература
- •Тема 7. Типовое проектирование ис
- •7.1 Понятие типового элемента. Классификация и примеры типовых информационных систем и их характеристика.
- •7.2 Методы конфигурирования типовой информационной системы.
- •7.3 Технологии параметрически - ориентированного и модельно-ориентированного проектирования.
- •Литература Основная литература
- •Дополнительная литература
- •Тема 8. Проектирование интегрированных информационных систем
- •Литература Основная литература
- •Дополнительная литература
- •Тема 9. Эффективность информационной системы
- •Литература Основная литература
- •Дополнительная литература
Международный стандарт iso/iec 12207: 1995-08-01
По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО. Он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ. При этом процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.
Стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.
Общая структура стандарта представляет собой набор процессов ЖЦ. Каждый процесс разделен на набор действий, каждое действие - на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).
В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:
Основные процессы:
приобретение;
поставка;
разработка;
эксплуатация;
сопровождение.
Вспомогательные процессы:
документирование;
управление конфигурацией;
обеспечение качества;
разрешение проблем;
аудит;
аттестация;
совместная оценка;
верификация.
Организационные процессы:
создание инфраструктуры;
управление;
обучение;
усовершенствование.
В таблице 2.1 приведены ориентировочные описания основных процессов ЖЦ. Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами.
Для поддержки практического применения стандарта ISO/IEC 12207 разработан ряд технологических документов: Руководство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology - Guide for ISO/IEC 12207) и Руководство по применению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering - Guide for the application of ISO/IEC 12207 to project management).
Таблица 2.1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207) |
|||
Процесс (исполнитель процесса) |
Действия |
Вход |
Результат |
Приобретение (заказчик) |
|
|
|
Поставка (разработчик ИС) |
|
|
|
Разработка (разработчик ИС) |
|
|
|
Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.
Согласно стандарту ISO/IEC серии 15288 [7] в структуру ЖЦ следует включать следующие группы процессов:
Договорные процессы:
приобретение (внутренние решения или решения внешнего поставщика);
поставка (внутренние решения или решения внешнего поставщика).
Процессы предприятия:
управление окружающей средой предприятия;
инвестиционное управление;
управление ЖЦ ИС;
управление ресурсами;
управление качеством.
Проектные процессы:
планирование проекта;
оценка проекта;
контроль проекта;
управление рисками;
управление конфигурацией;
управление информационными потоками;
принятие решений.
Технические процессы:
определение требований;
анализ требований;
разработка архитектуры;
внедрение;
интеграция;
верификация;
переход;
аттестация;
эксплуатация;
сопровождение;
утилизация.
Специальные процессы:
определение и установка взаимосвязей исходя из задач и целей.
Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 2.2.
Таблица 2.2. Стадии создания систем (ISO/IEC 15288) |
||
№ п/п |
Стадия |
Описание |
1 |
Формирование концепции |
Анализ потребностей, выбор концепции и проектных решений |
2 |
Разработка |
Проектирование системы |
3 |
Реализация |
Изготовление системы |
4 |
Эксплуатация |
Ввод в эксплуатацию и использование системы |
5 |
Поддержка |
Обеспечение функционирования системы |
6 |
Снятие с эксплуатации |
Прекращение использования, демонтаж, архивирование системы |
Каких - либо этапов, фаз, стадий не предусмотрено, что дает хорошую степень адаптивности.
Особенности стандарта:
1. "Динамический" характер стандарта, заключающийся в такой последовательности выполнения процессов и задач, при которой один процесс при необходимости вызывает другой или его часть.
Примеры:
выполнение Процесса приобретения в части анализа и фиксации требований к системе или ПО может вызывать исполнение соответствующих задач Процесса разработки;
в Процессе поставки поставщик должен управлять субподрядчиками согласно Процессу приобретения и выполнять верификацию и аттестацию по соответствующим процессам;
сопровождение может требовать развития системы и ПО, что выполняется по Процессу разработки.
Такой характер позволяет реализовывать любую модель ЖЦ.
2. Степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте.
3. Стандарт принципиально не содержит конкретные методы действий, тем более - заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует ее в деталях. В нем не описано как реализовать или выполнить услуги и задачи, включенные в процессы. Он не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт.
Конкретность пользы стандарта в том, что он содержит наборы задач, характеристик качества, критериев оценки и др., дающие всесторонний охват проектных ситуаций. Например, при выполнении анализа требований к системе предусматривается, что:
рассматривается область применения системы для определения требований системы;
спецификация требований системы должна описывать: функции и возможности системы, бизнес, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования;
квалификация требований системы должна быть документирована.
Далее, при выполнении анализа требований к ПО предусмотрено 11 классов характеристик качества, которые используются позже при гарантировании качества. При этом разработчик должен установить и документировать как требования к программному обеспечению:
функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена;
внешние связи (интерфейсы) с единицей программного обеспечения;
требования квалификации;
спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
спецификации защищенности, включая спецификации, связанные с компрометированием точности информации;
человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;
определение данных и требований базы данных;
установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);
документация пользователя;
работа пользователя и требования выполнения;
требования сервиса пользователя.
Таким образом, стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО. Он определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО.
4. Гарантирование качества разными процессами выполняется с разной предусмотренной степенью организационной независимости контролирующей деятельности вплоть до обязательных требований к полной независимости проверяющего персонала от какой-либо прямой ответственности за проверяемые объекты.
5. Степень обязательности: после решения организации о применении ISO12207 в качестве условия торговых отношений является ее ответственность за указание минимального набора требуемых процессов и задач, которые составляют согласованность с этим стандартом.
6. Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД, но и не использовать БД вовсе.
Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.