АИС_Конспект. Учебное пособие по предмету основы построения автоматизированных информационных систем для специальности

• Название: Учебное пособие по предмету основы построения автоматизированных информационных систем для специальности
• Дата: 04.09.2019
• Размер: 1.88 Mb.
• Имя файла: АИС_Конспект.doc
• Тип: Учебное пособие; #85919
• страница: 8 из 18

2.2. Каноническое проектирование информационных систем

В основе процесса проектирования информационных лежит методика канонического проектирования систем. Данная методика описана в стандарте ГОСТ 34.601-90.

Согласно данному стандарту каноническое проектирование предусматривает выполнение проектных работ по определенному алгоритму. Допускается выполнять сразу несколько шагов проектирования, объединяя их в одни этап.

В общем виде этапы канонического проектирования можно свести в таблицу 2.1.

Таблица 2.1. Каноническое проектирование.

Номер этапа	Краткое описание
1	Формирование требований к системе
2	Разработка концепции системы
3	Техническое задание на разработку
4	Составление эскизного проекта
5	Разработка технического проекта
6	Составление рабочей документации
7	Ввод системы в эксплуатацию
8	Поддержка системы, послы сдачи ее заказчику

Охарактеризуем данные этапы.

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

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

Техническое задание (ТЗ). Содержит основные требования, предъявляемые к информационной системе. В ТЗ указываются назначение системы, область ее применения, стадии разработки конструкторской документации, её состав, сроки исполнения. Указываются особые требования, обусловленные спецификой самой системы, либо условиями ее эксплуатации.

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

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

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

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

Сопровождение системы предусматривает:

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

2.3. Управление требованиями, спецификация RUP

Существуют различные определения требований предъявляемых к системам:

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

При разработке информационной системы в качестве требования можно рассматривать потребности заказчика.

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

Требования, возникающие при разработке систем можно ранжировать по трем основным уровням:

• 
  бизнес – требования;
  
• 
  требования пользователей;
  
• 
  функциональные требования.
  

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

Выделяют определенные уровни требований. В общем виде требования являются системными. Такие требования предъявляются к системам, в состав которых входят другие подсистемы. При этом под системой понимается программная, программно – аппаратная, либо человеко-машинная система.

В международной спецификации Rational Unified Process (RUP) при классификации требований используется пяти уровневая система модель требований:

1. Функциональные требования.

2. Требования применимости.

3. Требования надежности.

4. Требования производительности.

5. Требования эксплуатационной пригодности.

Дополнительно определяется четыре уровня:

1. Ограничения проекта.

2. Требования выполнения.

3. Требования к интерфейсу.

4. Физические требования.

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

• 
  извлечение требований;
  
• 
  анализ требований в узком смысле;
  
• 
  специфицирование требований;
  
• 
  проверка требований.
  

Стандарт RUP предлагает следующие цели, которые преследует процесс анализа:

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

Методология RUP рекомендует двухуровневую схему планирования работ над проектом. При этом выделяется план проекта и план итерации.

План проекта разбивается на фазы:

• 
  начало;
  
• 
  уточнение;
  
• 
  конструирование;
  
• 
  переход к следующему этапу.
  

В зависимости от степени сложности проекта и квалификации разработчиков системы, в каждой фазе выделяется отдельные этапы ­– итерации.

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

С точки зрения движения требований их можно подразделить на 4 класса.

Условно обозначим их:

• 
  «Заказчик – Требование»;
  
• 
  «Требование – Система»;
  
• 
  «Система» – «Требование»;
  
• 
  «Требование» – «Заказчик».
  

2.4. Модели жизненного цикла информационной системы

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

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

• 
  каскадная модель;
  
• 
  каскадная модель с обратными связями;
  
• 
  спиральная модель.
  

Каскадная модель жизненного цикла предусматривает выделение основных этапов создания системы и ввода ее в эксплуатацию:

• 
  анализ требований к системе;
  
• 
  разработка системы – проектирование;
  
• 
  реализацию системы;
  
• 
  внедрение – ввод ее в эксплуатацию.
  
• 
  сопровождение системы в процессе эксплуатации.
  

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

Достоинства каскадного подхода:

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

Рис.2.2. Каскадная модель жизненного цикла.

Иерархическая каскадная технология может быть использована, когда требования к системе сформированы в полном объеме.

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

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

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


Рис.2.3. Каскадный жизненный цикл с обратными связями.

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

В работе [4] отмечается, что основная проблема спиральной модели – определение момента перехода на следующий виток (см. рис. 2.4). Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.


Рис.2.4. Спиральная модель жизненного цикла.

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