Тема 3.

Информационные системы. Основные положения

Понятие жизненного цикла по. Процессы жизненного цикла.

Жизненный цикл программного обеспечения определяется как период времени, начинающийся с момента принятия решения о необходимости создания ПО и оканчивающийся в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим состав процессов ЖЦПО, является международный стандарт ISO/IEC 12270, определяющий структуру ЖЦ, содержащую процессы, действия и задачи, выполняемые во время создания ПО. Все процессы разделены на три группы:

Основные процессы

Вспомогательные процессы

Приобретение

Документирова-ние

Поставка

Управление кон-фигурацией

Эксплуата-ция

Обеспечение качества

Верификация

Сопровож-дение

Аттестация

Совместная оценка

Аудит

Организационные процессы

Управление

Создание инфраструктуры

Разрешение проблем

Усовершенство-вание

Обучение

Основные процессы

Процесс приобретения охватывает следующие действия:

• Инициирование приобретения

  • Определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы

  • Анализ требований к системе

  • Принятие решения относительно приобретения, разработки или усовершенствования

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

  • Подготовку и утверждение плана приобретения, включающего требования к системе, тип договора, ответственность сторон

• Подготовку заявочных предложений

  • Требования к системе

  • Перечень программных продуктов

  • Условия и соглашения

  • Технические ограничения

• Подготовку и корректировку договора

  • Определение заказчиком процедуры выбора поставщика, включающей критерии оценки предложений возможных поставщиков

  • Выбор поставщика на основе анализа предложений

  • Подготовку и заключение договора с поставщиком

  • Внесение изменений в договор в процессе его выполнения

• Надзор за деятельностью поставщика

  • Предусматривает процедуру совместной оценки и аудита

• Приемку и завершение работ

  • В процессе приемки выполняются необходимые тесты.

Процесс поставки:

• Инициирование поставки

• Подготовка ответа на заявочные предложения

• Подготовка договора

• Планирование

  • Принятие решение поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика

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

• Выполнение и контроль

• Проверка и оценка

• Поставка и завершение работ.

Процесс разработки:

• Подготовительная работа – выбор модели ЖЦ ПО, выбор адаптированной к условиям проекта стандартов, методов и средств разработки и составление плана работ

• Анализ требований к системе – определение ее функциональных возможностей, пользовательских требований к надежности и безопасности, к внешним интерфейсам и т.д.

• Проектирование архитектуры системы – определение компонентов ее оборудования, ПО и операций, выполняемых эксплуатирующим систему персоналом

• Анализ требований к ПО – определение характеристик для каждого компонента ПО:

  • Функциональные возможности включая характеристики производительности и среды функционирования компонента

  • Внешние интерфейсы

  • Спецификации надежности и безопасности

  • Эргономические требования

  • Требования к используемым данным

  • Требования к установке и приемке

  • Требования к пользовательской документации

  • Требования к эксплуатации и сопровождению

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

  • Трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов

  • Разработку и документирование программных интерфейсов ПО и баз данных

  • Разработку предварительной версии пользовательской документации

  • Разработку и документирование предварительных требований к тесам и плана интеграции ПО

• Детальное проектирование ПО, включая задачи:

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

  • Разработку и документирование детального проекта БД

  • Обновление пользовательской документации

  • Разработку и документирование требований к тестам и плана тестирования ПО

  • Обновление плана интеграции ПО

• Кодирование и тестирование

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

• Квалификационное тестирование ПО – проводится разработчиком в присутствии заказчика

• Интеграция системы –сборка всех компонентов системы

• Квалификационное тестирование системы

• Установка ПО – осуществляется разработчиком

• Приемка ПО.

Процесс эксплуатации:

• Подготовительная работа, включает:

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

  • Определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации

• Эксплуатационное тестирование

• Эксплуатация системы

• Поддержка пользователей

Процесс сопровождения

• Подготовительная работа

• Анализ проблем и запросов по модификации ПО

• Модификация ПО

• Проверка и приемка

• Перенос ПО в другую среду

• Снятие ПО с эксплуатации.

Вспомогательные процессы

Процесс документирования – формализованное описание информации, созданной в течении ЖЦ. Процесс включает:

• Подготовительная работа

• Проектирование и разработка

• Выпуск документации

• Сопровождение

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

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

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

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

• Принцип «разделяй и властвуй» - дробление крупного на более мелкое

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

• Принцип абстрагирования – выделение существенных аспектов и отвлечение несущественных

• Принцип непротиворечивости – обоснованность и согласованность элементов системы

• Принцип структурирования данных – данные должны быть организованы

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

• DFD – Data Flow Diagrams –диаграммы потоков данных

• SADT – Structured Analysis and Design Technique (метод структурного анализа и проектирования)

• –ERD – Entity-Relationship Diagrams диаграммы «сущность»-«связь»

DFD и SADT модели и соответствующие функциональные диаграммы используются на стадии формирования требований для построения модели «как есть» и «как будет», отражая существующую и предлагаемую структуру бизнес-процессов. С помощью ERD выполняется описание данных на концептуальном уровне, независимо от средств реализации БД.

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

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

Метод функционального моделирования SADT

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

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

Концепции метода:

• Графическое представление блочного моделирования. Блоки изображают функции, дуги – интерфейсы входа-выхода. Взаимодействие блоков описывается посредством дуг, выражающих «ограничения»

• Строгость и точность. Выполнение правил SADT требует достаточной точности и строгости, не накладывая чрезмерных ограничений на деятельность аналитика. Правилами SADT определяется количество блоков на каждом уровне декомпозиции (3-6), связность диаграммы (номера блоков), уникальность меток и наименований, синтаксические правила для блоков и дуг, разделение входов и управления (правило определения роли данных).

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

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

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

Управляющая информация входит в блок сверху, входная информация – с левой стороны, механизм (автоматизированная система или человек) - снизу, а РЕЗУЛЬТАТЫ (выход) – с правой стороны.