Главная / Информатика / Курс лекций по дисциплине "Автоматизированные информационные системы"

Курс лекций по дисциплине "Автоматизированные информационные системы"

Министерство образования Пензенской области

Государственное бюджетное образовательное учреждение

Среднего профессионального образования Пензенской области

«Пензенский многопрофильный колледж»

торгово-экономическое отделение







Автоматизированные информационные системы

Курс лекций

для студентов, обучающихся по специальности 230103

«Автоматизированные системы обработки информации

и управления (по отраслям)»







Автор: Комарова Е.В.









Пенза, 2013 г.

Одобрены методической (цикловой) комиссии естественнонаучных дисциплин

Протокол №____от________________ Председатель

_____________________ С.А. Луконина

Составлены в соответствии с

Государственными требованиями к

минимуму содержания и уровню

подготовки выпускникапо специальности 230103

«Автоматизированные системы обработки информации

и управления (по отраслям)»

Утверждаю

Заместитель начальника отделения

____________________ Л.В. Волкова










Автор (составитель) _____________________Е.В. Комарова








Пояснительная записка


Курс лекций составлен для студентов, обучающихся по специальности 230103 «Автоматизированные системы обработки информации и управления (по отраслям)» в соответствии с требованиями федерального государственного образовательного стандарта 2 поколения к минимуму содержания и уровню подготовки выпускников СПО по дисциплине «Автоматизированные информационные системы».

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



Лекция №1 Основные понятия системного анализа


План лекции:

  1. Принципы системного подхода

  2. Системотехника, предмет и компоненты.Основные понятия системотехники

  3. Составные части системотехники


  1. Принципы системного подхода

Основные идеи и принципы проектирования сложных систем выражены в

системном подходе. Системный подход - это подход к исследованию объекта (проблемы, явления, процесса) как к системе, в которой выделены элементы, внутренние и внешние связи, наиболее существенным образом влияющие на исследуемые результаты его функционирования, а цели каждого из элементов, исходя из общего предназначения объекта. Системный подход рассматривают как направление научного познания и социальной политики. Он является базой для обобщающей дисциплины «Теория систем» (другое используемое название –«Системный анализ»). Теория систем - дисциплина, в которой конкретизируются положения системного подхода; она посвящена исследованию и проектированию сложных экономических, социальных, технических систем, чаще всего слабоструктурированных.

Далее рассмотрим основные принципы системного подхода:

1. Целостность, позволяющая рассматривать одновременно систему как единое целое и в то же время как подсистему для вышестоящих уровней.

2. Иерархичность строения, т.е. наличие множества (по крайней мере, двух) элементов, расположенных на основе подчинения элементов низшего уровня - элементам высшего уровня. Реализация этого принципа хорошо видна на примере любой конкретной организации. Как известно, любая организация представляет собой взаимодействие двух подсистем: управляющей и управляемой. Одна подчиняется другой.

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

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

2. Системотехника, предмет и компоненты. Основные понятия системотехники

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

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

Система — множество элементов, находящихся в отношениях и связях между собой.

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

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

Подсистема—часть системы (подмножество элементов и их взаимосвязей),которая имеет свойства системы.

Надсистема — система, по отношению к которой рассматриваемая системаявляется подсистемой.

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

  1. Составные части системотехники.

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

  • иерархическая структура систем, организация их проектирования;

  • анализ и моделирование систем;

  • синтез и оптимизация систем.

Моделирование имеет две четко различимые задачи:

1 создание моделей сложных систем;

2 - анализ свойств систем на основе исследования их моделей .

Синтез также подразделяют на две задачи:

1 синтез структуры проектируемых систем (структурный синтез);

2 выбор численных значений параметров элементов систем (параметрический синтез).

Эти задачи относятся к области принятия проектных решений. Моделирование и оптимизацию желательно выполнять с учетом статистической природы систем. Детерминированность - лишь частный случай. При проектировании характерны нехватка достоверных исходных данных, неопределенность условий принятия решений. Учет статистического характера данных при моделировании в значительной мере основан на методе статистическихиспытаний (методе Монте-Карло), а принятие решений - на использованиинечетких множеств, экспертных систем, эволюционных вычислений.

Контрольные вопросы:

  1. Перечислите принципы системного подхода.

  2. В чем заключается принцип целостности?

  3. Что понимают под системотехникой?

  4. Что такое структура?

  5. Что называют системой, подсистемой и надсистемой?

  6. Какие разделы включает в себя системотехника?


Литература:

Норенков И.П. Основы автоматизированного проектирования. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2002.-336 с.



Лекция №2 Понятие и структура АИС. История создания и развития АИС.


План лекции:

  1. Основные понятия. Предпосылки создания ИС

  2. История развития ИС

  3. Структура ИС

  1. Основные понятия. Предпосылки создания ИС

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

Предпосылки создания ИС:

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

  2. Отработанность (стабильность) технологического процесса обработки данных

  3. Готовность руководства предприятия и сотрудников к освоению и применению АИС.


  1. История развития ИС

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

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

В 70-х - начале 80-х гг. информационные системы начинают широко использоваться в качестве средства управленческого контроля, поддерживающего и ускоряющего процесс принятия решений.

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

  1. Структура ИС

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

Подсистема - это часть системы, выделенная по какому-либо признаку.

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

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

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

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

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

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

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

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

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

Организационное обеспечение — это совокупность методов и средств, регламентирующих взаимодействие работников с техническими средствами и между собой в процессе разработки и эксплуатации ИС.

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

Контрольные вопросы:
  1. Что такое АИС?
  2. Перечислите основные этапы развития ИС.
  3. Что такое подсистема?
  4. Назовите составные части ИС.
  5. Что подразумевают под математическим и программным обеспечением ИС?



Лекция №3 Жизненный цикл АИС

План лекции:

  1. Понятие жизненного цикла АИС. Его структура.

  2. Стадии жизненного цикла АИС: начало и уточнение.

  3. Стадия конструирования и передачи в эксплуатацию.


  1. Понятие жизненного цикла АИС. Его структура.

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

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

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

  1. Стадии жизненного цикла АИС: начало и уточнение.

Согласномеждународному стандарту ISO, жизненный цикл информационной системы подразделяется на четыре стадии:

  • начало;

  • уточнение;

  • конструирование;

  • передача в эксплуатацию.

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

Начальная стадия

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

Деловое применение включает:

  • критерии успеха разработки;

  • оценку риска;

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

  • календарный план с указанием сроков завершения основных этапов.

Стадия уточнения

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

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

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

  1. Стадия конструирования и передачи в эксплуатацию.

Стадия конструирования

На стадии конструирования разрабатывается законченное изделие, готовое к передаче пользователю.

По окончании этой стадии определяется работоспособность разработанного программного обеспечения.

Стадия передачи в эксплуатацию

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

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


Контрольные вопросы:

  1. Что такое ЖЦ информационной системы?

  2. Что включает в себя полный ЖЦ информационной системы?

  3. Что в себя включает стадия уточнения?



Лекция №4, 5 Классификация АИС

План лекции:

  1. Классификация АИС по масштабу.

  2. Классификация АИС по сфере применения

  3. Классификация АИС по способу организации

  4. Области применения информационных систем.


  1. Классификация АИС по масштабу

По масштабу информационные системы подразделяются на следующие группы(рис. 1.1):

  • одиночные;

  • групповые;

  • корпоративные.

hello_html_m49c379f7.gif Одиночные информационные системы

Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере . Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и QicrosoftAccess.

Групповые информационные системы

Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (называемые также SQL-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов, как коммерческих, так и свободно распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, QicrosoftSQLServer, InterBase, Sybase, Inforqix.

Корпоративные информационные системы

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что ипри разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Qicrosoft SQL Server.

  1. Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре

группы (рис.1.2):

  1. системы обработки транзакций;

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

  1. системы принятия решений;

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

  1. информационно-справочные системы;

Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные системы получили в сети Интернет.

  1. офисные информационные системы.

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

hello_html_2bb4a168.gif

  1. Классификация по способу организации

По способу организации групповые и корпоративные информационные системыподразделяются на следующие классы (рис. 1.3):

системы на основе архитектуры файл-сервер;

системы на основе архитектуры клиент-сервер;

системы на основе многоуровневой архитектуры;

системы на основе Интернет/интранет-технологий.

hello_html_m3c9af496.gif

Архитектура файл-сервер использует компьютер для функций отображения, что облегчает построениеграфического интерфейса. Файл-сервер только извлекает данные из файлов,так что дополнительные пользователи и приложения добавляют лишь незначительнуюнагрузку на центральный процессор. Каждый новый клиент добавляетвычислительную мощность к сети.Разработанное приложение реализуется либо в видезаконченного загрузочного модуля, либо в виде специального кода для интерпретации. Недостаток: при выполнении некоторыхзапросов к базе данных клиенту могут передаваться большие объемыданных, загружая сеть и приводя к непредсказуемости времени реакции.

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

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

Многоуровневая архитектура

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своейклассической форме состоит из трех уровней:

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

  • средний уровень представляет собой сервер приложений, на котором выполняетсяприкладная логика BL и с которого логика обработки данных DL вызываетоперации с базой данных DS;

  • верхний уровень представляет собой удаленный специализированный сервербазы данных, выделенный для услуг обработки данных DS и файловых операцийFS (без риска использования хранимых процедур).

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

Интернет/интранет-технологии

В развитии технологии Интернет/интранет основной акцент пока что делается наразработке инструментальных программных средств. В то же время наблюдаетсяотсутствие развитых средств разработки приложений, работающих с базами данных.Компромиссным решением для создания удобных и простых в использованиии сопровождении информационных систем, эффективно работающих с базамиданных, стало объединение Интернет/интранет-технологии с многоуровневойархитектурой. При этом структура информационного приложения приобретаетследующий вид: браузер — сервер приложений — сервер баз данных — сервер динамическихстраниц — web-сервер.Благодаря интеграции Интернет/интранет-технологии и архитектуры клиент-серверпроцесс внедрения и сопровождения корпоративной информационной системысущественно упрощается при сохранении достаточно высокой эффективностии простоты совместного использования информации.

  1. Области применения информационных систем.

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

  • Бухгалтерский учет;

  • Управление финансовыми потоками;

  • Управление складом, ассортиментом, закупками;

  • Управление производственным процессом;

  • Управление маркетингом;

  • Документооборот;

  • Оперативное управление предприятием;

  • Предоставление информации о фирме.


Контрольные вопросы:

  1. Какие подходы к классификации вы знаете?

  2. Что понимают под корпоративными ИС ?

  3. Приведите примеры одиночных и групповых ИС.

  4. Чем отличается архитектура файл- сервер от архитектуры клиент- сервер ?

  5. Какая архитектура доминирует на российском рынке?

  6. Где применяются информационные системы?



Лекция №6. Стадии жизненного цикла.

План лекции:

  1. Стадия моделирования и управления требованиями.

  2. Стадия уточнения: анализ и проектирование.

  3. Стадия конструирования: кодирование и тестирование

  4. Стадия передачи в эксплуатацию: установка и сопровождение.

1. Стадия моделирования и управления требованиями.

Жизненный цикл информационной системы подразделяется на четыре стадии:

• начало;

• уточнение;

• конструирование;

• передача в эксплуатацию.

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

Начальная стадия: моделирование, управление требованиями

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

Деловое применение включает:

• критерии успеха разработки;

• оценку риска;

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

• календарный план с указанием сроков завершения основных этапов.

В рамках данной стадии проводится исследование и анализ деятельности автоматизируемого объекта; значение имеют, разумеется, только те процессы, которые соответствуют целям и задачам этого объекта. В результате получается модель объекта, которую обычно описывают в терминах бизнес-процессов и бизнес-функций. Параллельно с этим выявляются недостатки существующих информационных систем (вспоминаем принцип преемственности) и формулируются потребности в совершенствовании системы управления объектом и/или автоматизации его отдельных функций. Требования должны быть экономически обоснованными. Результатом выполнения описанных этапов стадии является оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ) на разработку ИС. Обычно ТЭО оформляется как часть ТЗ. Кроме того, в ТЗ обязательно отражаются требования к ИС и ограничения на ресурсы проектирования (в первую очередь, сроки исполнения). Требования к ИС определяются как множество функций, реализуемых системой, а также описание предоставляемой ей информации.


2. Стадия уточнения: анализ и проектирование.

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

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

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

В соответствии с полученными требованиями проектировщики разрабатывают функциональную архитектуру ИС, которая отражает структуру выполняемых ей функций, и системную архитектуру ИС, которая представляет собой состав обеспечивающих подсистем. Построение системной архитектуры проводится на базе описания функциональной архитектуры ИС и фактически заключается в составлении технологии обработки информации с участием всех обеспечивающих подсистем ИС (в первую очередь, информационного, технического, и программного обеспечения). Результатом выполнения стадии проектирования обычно являются: 1) концептуальная, логическая и физическая модели данных ИС; 2) спецификации модулей ИС; 3) спецификация пользовательских интерфейсов ИС; 4) множество выбранных проектных решений, определяющих архитектуру ИС – в том числе выбранная платформа ПО, количество звеньев в архитектуре (однозвенная, двухзвенная [клиент-сервер или файл-сервер], трехзвенная) и др. Итоговый документ, завершающий стадию проектирования, – технический проект (ТП).


3. Стадия конструирования: кодирование и тестирование

На стадии конструирования разрабатывается законченное изделие, готовое к передаче пользователю.

По окончании этой стадии определяется работоспособность разработанного программного обеспечения.

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


4. Стадия передачи в эксплуатацию: установка и сопровождение.

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

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

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


Контрольные вопросы:

  1. Какие стадии жизненного цикла существуют?

  2. Что является результатом выполнения стадии проектирования?

  3. Как осуществляется тестирование ИС?

  4. Охарактеризуйте стадию установки ИС.



Лекция №7 Процессы жизненного цикла информационной системы.

План лекции:

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

  2. Основные процессы жизненного цикла.

  3. Вспомогательные процессы жизненного цикла.

  4. Организационные процессы жизненного цикла.


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

Согласно международному стандарту ISOструктура жизненного цикла основывается на трех группах процессов:

  • основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

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

Рассмотрим каждую из указанных групп более подробно.

2. Основные процессы жизненного цикла.

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

Разработка.

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

  • оформление проектной и эксплуатационной документации;

  • подготовку материалов, необходимых для проведения тестирования разработанных программных продуктов;

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

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

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

Эксплуатационные работы можно подразделить на подготовительные и основные.

К подготовительным относятся:

  • конфигурирование базы данных и рабочих мест пользователей;

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

  • обучение персонала.

Основные эксплуатационные работы включают:

  • непосредственно эксплуатацию;

  • локализацию проблем и устранение причин их возникновения;

  • модификацию программного обеспечения;

  • подготовку предложений по совершенствованию системы;

  • развитие и модернизацию системы.

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

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

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

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

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

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

3. Вспомогательные процессы жизненного цикла.

Среди вспомогательных процессов одно из главных мест занимает управление конфигурацией. Это один из вспомогательных процессов, поддерживающих основные процессы жизненного цикла информационной системы, прежде всего процессы разработки и сопровождения. При разработке проектов сложных информационных систем, состоящих из многих компонентов, каждый из которых может разрабатываться независимо и, следовательно, иметь несколько вариантов реализации и/или несколько версий одной реализации, возникает проблема учета их связей и функций, создания единой структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты информационной системы на всех стадиях ее жизненного цикла.

4. Организационные процессы жизненного цикла.

Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает:

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

определение методов описания промежуточных состояний разработки;

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

обучение персонала.

Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов информационной системы.

Верификация — это процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа.

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

Контрольные вопросы:

  1. Что такое верификация?

  2. Что относят к основным процессам жизненного цикла?

Лекция №8 Модели жизненного циклаинформационной системы

План лекции:

  1. Понятие модели жизненного цикла АИС

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

  3. Достоинства и недостатки каскадной модели

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

  5. Преимущества и проблемы спиральной моедли

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

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

каскадная модель, иногда также называемая моделью «водопад» (waterfall);

спиральная модель.

Каскадная модель жизненного циклаинформационной системы

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

Основные этапы разработки по каскадной модели

За десятилетия существования модели «водопад» разбиение работ на стадии иназвания этих стадий менялись. Кроме того, наиболее разумные методики и стандартыизбегали жесткого и однозначного приписывания определенных работ кконкретным этапам. Тем не менее все же можно выделить ряд устойчивых этаповразработки, практически не зависящих от предметной области (рис. 2.2):

  • анализ требований заказчика;

  • проектирование;

  • разработка;

  • тестирование и опытная эксплуатация;

  • сдача готового продукта.

hello_html_mdcf340e.gifНа первом этапе проводится исследование проблемы, которая должна быть решена,четко формулируются все требования заказчика. Результатом, получаемым наданном этапе, является техническое задание (задание на разработку), согласованноесо всеми заинтересованными сторонами.

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

Третий этап — реализация проекта. Здесь осуществляется разработка программного

обеспечения (кодирование) в соответствии с проектными решениями, полученнымина предыдущем этапе. Методы, используемые для реализации, не имеютпринципиального значения. Результатом выполнения данного этапа является готовыйпрограммный продукт.

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

Последний этап — сдача готового проекта. Главная задача этого этапа — убедитьзаказчика, что все его требования реализованы в полной мере.Этапы работ в рамках каскадной модели часто также называют частями «проектногоцикла» системы. Такое название возникло потому, что этапы состоят из многихитерационных процедур уточнения требований к системе и вариантов проектныхрешений. Жизненный цикл самой системы существенно сложнее и больше. Он можетвключать в себя произвольное число циклов уточнения, изменения и дополненияуже принятых и реализованных проектных решений. В этих циклах происходитразвитие информационной системы и модернизация отдельных ее компонентов.

Основные достоинства каскадной модели

Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошозарекомендовала себя при выполнении различного рода инженерных разработоки получила широкое распространение. Рассмотрим основные достоинствамодели «водопад»:

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

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

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

Недостатки каскадной модели

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

  • существенная задержка получения результатов;

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

  • сложность распараллеливания работ по проекту;

  • чрезмерная информационная перенасыщенность каждого из этапов;

  • сложность управления проектом;

  • высокий уровень риска и ненадежность инвестиций.

Задержка получения результатов обычно считается главным недостатком каскаднойсхемы. Данный недостаток проявляется в основном в том, что вследствие последовательногоподхода к разработке согласование результатов с заинтересованнымисторонами производится только после завершения очередного этапа работ. Поэтомуможет оказаться, что разрабатываемая информационная система не соответствуеттребованиям пользователей. Причем такие несоответствия могут возникать налюбом этапе разработки — искажения могут непреднамеренно вноситься и проектировщиками аналитиками, и программистами, так как они не обязательно хорошоразбираются в тех предметных областях, для которых производится разработка информационнойсистемы. Кроме того, используемые при разработке информационной системы моделиавтоматизируемого объекта, отвечающие критериям внутренней согласованностии полноты, могут в силу различных причин устареть за время разработки(например, из-за внесения изменений в законодательство, колебания курса валюти т. п.). Это относится и к функциональной модели, и к информационноймодели, и к проектам интерфейса пользователя, и к пользовательской документации.

Возврат на более ранние стадии. Данный недостаток каскадной модели в общем то является одним из проявлений предыдущего. Поэтапная и последовательнаяработа над проектом может быть следствием того, что ошибки, допущенные на болееранних этапах, как правило, обнаруживаются только на последующих стадиях работынад проектом. Поэтому, после того как ошибки проявятся, проект возвращаетсяна предыдущий этап, перерабатывается и снова передается на последующуюстадию. Это может служить причиной срыва графика работ и усложнения взаимоотношениймежду группами разработчиков, выполняющих отдельные этапы работы.Самым же неприятным является то, что недоработки предыдущего уровня могутобнаруживаться не сразу на последующем уровне, а позднее (например, на стадииопытной эксплуатации могут проявиться ошибки в описании предметной области).Это означает, что часть проекта должна быть возвращена на начальный уровеньработы. Вообще, работа может быть возвращена с любого этапа на любой предыдущийэтап, поэтому в реальном случае каскадная схема разработки имеет вид,приведенный на рис. 2.3. hello_html_m6a5c057a.gifОдной из причин данной ситуации является то, что в качестве экспертов, участвующихв описании предметной области, часто выступают будущие пользователисистемы, которые нередко не могут четко сформулировать то, что онихотели бы получить. Кроме того, заказчики и исполнители часто неправильнопонимают друг друга вследствие того, что исполнители обычно не являютсяспециалистами в предметной области решаемой задачи, а заказчики далеки отпрограммирования.

Сложность параллельного ведения работ. Отмеченные выше проблемы возникаютвследствие того, что работа над проектом строится в виде цепочки последовательныхшагов. Причем даже в том случае, когда разработку некоторых частей проекта(подсистем) можно вести параллельно, при использовании каскадной схемы распараллеливаниеработ весьма затруднительно. Сложности параллельного веденияработ связаны с необходимостью постоянного согласования различных частейпроекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще итщательнее должна выполняться синхронизация, тем сильнее зависимы друг отдруга группы разработчиков. Поэтому преимущества параллельного ведения работпросто теряются.Отсутствие параллелизма негативно сказывается и на организации работы всегоколлектива разработчиков. Работа одних групп сдерживается другими. Покапроизводится анализ предметной области, проектировщики, разработчики и те,кто занимается тестированием и администрированием, почти не имеют работы.Кроме того, при последовательной разработке крайне сложно внести измененияв проект после завершения этапа и передаче проекта на следующую стадию.Так, например, если после передачи проекта на следующий этап группаразработчиков нашла более эффективное решение, оно не может быть использовано.Это связано с тем, что более раннее решение уже, возможно, реализовано исвязано с другими частями проекта. Поэтому исключается (или, по крайней мере,существенно затрудняется) доработка проекта после его передачи на следующийэтап.

Информационная перенасыщенность. Проблема информационной перенасыщенностивозникает вследствие сильной зависимости между различными группамиразработчиков. Данная проблема заключается в том, что при внесенииизменений в одну из частей проекта необходимо оповещать всех разработчиков,которые использовали или могли использовать эту часть в своей работе.Когда система состоит из большого количества взаимосвязанных подсистем,то синхронизация внутренней документации становится важной самостоятельнойзадачей.Причем синхронизация документации на каждую часть системы — это не болеечем процесс оповещения групп разработчиков. Самим же разработчикам необходимоознакомиться с изменениями и оценить, не сказались ли эти измененияна уже полученных результатах. Все это может потребовать проведения повторноготестирования и даже внесения изменений в уже готовые части проекта.Причем эти изменения, в свою очередь, должны быть отражены во внутреннейдокументации и быть разосланы другим группам разработчиков. Как следствие,объем документации по мере разработки проекта растет очень быстро, так чтотребуется все больше времени для составления документации и ознакомленияс ней.Следует также отметить, что, кроме изучения нового материала, не отпадает и необходимостьв изучении старой информации. Это связано с тем, что вполне вероятнаситуация, когда в процессе выполнения разработки изменяется состав группыразработчиков (этот процесс носит название ротации кадров). Новым разработчикамнеобходима информация о том, что было сделано до них. Причем чемсложнее проект, тем больше времени требуется, чтобы ввести нового разработчикав курс дела. Сложность управления проектом при использовании каскадной схемы в основномобусловлена строгой последовательностью стадий разработки и наличием сложныхвзаимосвязей между различными частями проекта.Последовательность разработки проекта приводит к тому, что одни группы разработчиковдолжны ожидать результатов работы других команд. Поэтому требуетсяадминистративное вмешательство для того, чтобы согласовать сроки работы и составпередаваемой документации.В случае же обнаружения ошибок в выполненной работе необходим возврат к предыдущимэтапам выполнения проекта. Это приводит к дополнительным сложностямв управлении проектом. Разработчики, допустившие просчет или ошибку,вынуждены прервать текущую работу (над новым проектом) и заняться исправлениемошибок. Следствием этого обычно является срыв сроков выполнения какисправляемого, так и нового проектов. Требовать же от команды разработчиковожидания окончания следующей стадии разработки нерационально, так как приводитк существенным потерям рабочего времени.Упростить взаимодействие между группами разработчиков и уменьшить информационнуюперенасыщенность документации можно, уменьшая количество связеймежду отдельными частями проекта. Однако это обычно весьма непросто. Далеконе каждую информационную систему можно разделить на несколько слабосвязанных подсистем.Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждогоиз этапов разработки и тем сложнее взаимосвязи между отдельными частямипроекта, количество которых также увеличивается. Причем результаты разработкиможно реально увидеть и оценить лишь на этапе тестирования, то есть послезавершения анализа, проектирования и разработки — этапов, выполнение которыхтребует значительного времени и средств. Как уже было отмечено выше, запоздалаяоценка создает значительные проблемы при выявлении ошибок анализаи проектирования — требуется возврат проекта на предыдущие стадии и повторениепроцесса разработки.Однако возврат на предыдущие стадии может быть связан не только с ошибками,но и с изменениями, произошедшими за время выполнения разработки в предметнойобласти или в требованиях заказчика. Причем возврат проекта вследствие этихпричин на доработку не гарантирует, что предметная область снова не изменитсяк тому моменту, когда будет готова следующая версия проекта. Фактически этоозначает, что существует вероятность того, что процесс разработки «зациклится»и никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постояннорасти, а сроки сдачи готового продукта — постоянно откладываться.Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскаднойсхеме, имеют повышенный уровень риска.

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

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

Итерации

Каждая итерация представляет собой законченный цикл разработки, приводящийк выпуску внутренней или внешней версии изделия (или подмножества конечногопродукта), которое совершенствуется от итерации к итерации, чтобы стать законченнойсистемой (рис. 2.4). hello_html_4ae5282b.gifТаким образом, каждый виток спирали соответствует созданию фрагмента иливерсии программного изделия, на нем уточняются цели и характеристики проекта,определяется его качество, планируются работы следующего витка спирали.На каждой итерации углубляются и последовательно конкретизируются деталипроекта, в результате чего выбирается обоснованный вариант, который доводитсядо окончательной реализации.Использование спиральной модели позволяет осуществлять переход на следующийэтап выполнения проекта, не дожидаясь полного завершения работы на текущем— недоделанную работу можно будет выполнить на следующей итерации.Главная задача каждой итерации — как можно быстрее создать работоспособныйпродукт, который можно показать пользователям системы. Таким образом, существенноупрощается процесс внесения уточнений и дополнений в проект.

Преимущества спиральной модели

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

  • итерационная разработка существенно упрощает внесение изменений в проектпри изменении требований заказчика;

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

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

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

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

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

Проблемы, возникающие при использовании

спиральной модели

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

Контрольные вопросы:

  1. Что такое модель жизненного цикла АИС?

  2. Какие модели жизненного цикла вы знаете?

  3. В чем отличие каскадной модели от спиральной?

  4. В чем преимущество спиральной модели перед каскадной?





Тема 7. Методы проектирования АИС

План лекции:

  1. Основные понятия проектирования

  2. Обеспечивающая часть АИС

  3. Функциональная часть АИС

  4. Признаки проекта. Классификация проектов


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

Под проектированием ИС понимается процесс преобразования входной информации об объекте, методах и опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом в проект ИС.

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

В качестве субъекта проектирования ИС выступают коллективы специалистов, которые осуществляют проектную деятельность, как правило, в составе специализированной (проектной организации), и организация-заказчик, для которой необходимо разработать ИС.

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


Основные понятия и структура автоматизированных информационных систем


Обеспечивающая часть

Информационное обеспечение АИС — это совокупность баз данных и файлов операционной системы, форматной и лексической баз, а также языковых средств, предназначенных для ввода, обработки, поиска и представления информации в форме, необходимой потребителю.

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

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

Математическое обеспечение — «совокупность математических методов, моделей и алгоритмов, примененных вАС» (ГОСТ 34.03-90).

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

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

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

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

Эргономическое обеспечение — совокупность методов и средств по созданию оптимальных условий для работы специалистов в рамках АИС.

Функциональная часть

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

Операторы выполняют первичный сбор и систематизацию информации. Собранная информация анализируется с точки зрения выявления сущностей, которые будут являться прообразами создаваемых таблиц БД (если БД реляционная). Далее информация направляется в подсистему представления, хранения и обработки информации.

Подсистема представления, хранения и обработки информации выполняет предмашинную подготовку данных и ввод их в базу данных, рассматриваемую как информационную модель предметной области. Операторы при участии администратора базы данных по определенным правилам на основе инструкций заполняют базу данных подготовленной информацией. В этой подсистеме осуществляется проверка данных на достоверность и непротиворечивость, редактирование, обработка и анализ данных, осуществляется сохранность накапливаемых данных, восстановление утерянных. Основой этой подсистемы является информационный фонд — база данных (БД), управляемая системой управления базами данных (СУБД).

База данных — именованная совокупность структурированных, организованных данных, отображающая состояние объектов и их отношений в определенной предметной области.

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

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

Банк данных (БнД) — система специально организованных данных, программных, языковых, организационных и технических средств, предназначенных для централизованного накопления и коллективного многоцелевого использования данных.

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


Выделяют следующие основные отличительные признаки проекта как объекта управления:

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

  2. ограниченность конечной цели

  3. ограниченность продолжительности

  4. ограниченность бюджета

  5. ограниченность требуемых ресурсов

  6. новизна для предприятия, для которого реализуется проект

  7. комплексность, т.е. наличие большого числа факторов прямо или косвенно влияющих на прогресс и результат проекта

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


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

  • объем работ

  • сроки выполнения

  • себестоимость

  • экономическая эффективность, обеспеченная реализацией проекта

  • социальная и общественная значимость проекта

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

Основные признаки классификации проектов:

  1. Класс проекта определяется по составу и структуре проекта. Здесь различают монопроект – отдельный проект, который может быть любого типа, вида и масштаба; мультипроект – комплексный проект, состоящий из ряда монопроектов и требующий применения многопроектного управления.

  2. Тип проекта, определяется по основным сферам деятельности, в которых осуществляется проект. Выделяют 5 основных типов:

  • Технический

  • Организационный

  • Экономический

  • Социальный

  • Смешанный

  1. Масштаб проекта. Определяется по размерам бюджета и количеству участников. Выделяют мелкие проекты; малые проекты; средние; крупные проекты. Масштабы проектов рассматривают также в более конкретной форме, а именно отраслевые, корпоративные, ведомственные и проекты одного предприятия.

Контрольные вопросы:

  1. Что такое проект и проектирование?

  2. Что понимают под субъектами и объектами проектирования?

  3. Что включает в себя обеспечивающая часть АИС?

  4. Перечислите основные виды проектов.

Тема 8. Основные фазы проектирования информационной системы

План лекции:

  1. Основные фазы проектирования информационных систем. Концептуальная фаза.

  2. Фазы подготовки технического задания и проектирования

  3. Фазы разработки и ввода системы в эксплуатацию



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

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

Можно выделить следующие фазы развития информационной системы:

  • формирование концепции;

  • подготовка технического задания;

  • проектирование;

  • разработка;

  • ввод системы в эксплуатацию.

Рассмотрим каждую из них более подробно.

Концептуальная фаза

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

  • формирование идеи, постановку целей;

  • формирование ключевой команды проекта;

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

  • сбор исходных данных и анализ существующего состояния;

  • определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов;

  • сравнительную оценку альтернатив;

  • представление предложений, их экспертизу и утверждение.

Подготовка технического предложения

Главным содержанием фазы подготовки технического предложения является уточнение технического предложения в ходе переговоров с заказчиком о заключении контракта. Общее содержание работ этой фазы:

  • разработка основного содержания, базовой структуры проекта;

  • разработка и утверждение технического задания;

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

  • составление сметы и бюджета проекта, определение потребности в ресурсах;

  • разработка календарных планов и укрупненных графиков работ;

  • подписание контракта с заказчиком;

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

Проектирование

На фазе проектирования определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характерные работы этой фазы:

  • выполнение базовых проектных работ;

  • разработка частных технических заданий;

  • выполнение концептуального проектирования;

  • составление технических спецификаций и инструкций;

  • представление проектной разработки, экспертиза и утверждение.

Разработка

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

  • выполнение работ по разработке программного обеспечения;

  • подготовка к внедрению системы;

  • контроль и регулирование основных показателей проекта.

Ввод системы в эксплуатацию

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

  • комплексные испытания;

  • подготовка кадров для эксплуатации создаваемой системы;

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

  • сопровождение, поддержка, сервисное обслуживание;

  • оценка результатов проекта и подготовка итоговых документов;

  • разрешение конфликтных ситуаций и закрытие работ по проекту;

  • накопление опытных данных для последующих проектов, анализ опыта, состояния, определение направлений развития.

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

  • ошибки в определении интересов заказчика;

  • концентрация на маловажных, сторонних интересах;

  • неправильная интерпретация исходной задачи;

  • неправильное или недостаточное понимание деталей;

  • неполнота функциональных спецификаций (системных требований);

  • ошибки в определении требуемых ресурсов и сроков;

  • редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).

Контрольные вопросы:

  1. Перечислите основные виды работ на стадии подготовки технического предложения

  2. Перечислите основные виды работ на стадии проектирования

  3. Перечислите основные виды работ на стадии ввода системы в эксплуатацию





Тема 9. Методология RAD

План лекции:

  1. Понятие методологии RAD. Жизненный цикл АИС по методологии RAD

  2. Фаза анализа и планирования требований, фаза проектирования

  3. Фаза построения. Фаза внедрения

  4. Основные принципы методологии RAD



Одним из возможных подходов к разработке ПОв рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (RapidApplicationDevelopment). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

  • небольшую команду программистов (от 2 до 10 человек);

  • короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

  • фаза анализа и планирования требований;

  • фаза проектирования;

  • фаза построения;

  • фаза внедрения.

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

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

Результатом данной фазы должны быть:

  • общая информационная модель системы;

  • функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

  • точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

  • построенные прототипы экранов, отчетов, диалогов.

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

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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


Основные принципы методологии RAD:

  • разработка приложений итерациями;

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

  • обязательное вовлечение пользователей в процесс разработки ИС;

  • необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

  • необходимое использование генераторов кода;

  • использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;

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

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

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



Контрольные вопросы:

  1. Перечислите основные виды работ на стадии анализа и планирования требований

  2. Что является результатом фазы проектирования?

  3. Назовите основные принципы методологии RAD.





Тема 10. Объектно-ориентированное программирование

План лекции:

  1. Объектно-ориентированный подход. Преимущества.

  2. Объектно-ориентированное программирование и проектирвоание

  3. Объектно-ориентированный анализ.

  4. Принципы объектного подхода. Обязательные элементы

  5. Дополнительные элементы объектной модели


Объектно-ориентированный подход помогает справиться с такими сложными проблемами, как

  • уменьшение сложности программного обеспечения;

  • повышение надежности программного обеспечения;

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

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

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

Составными частями объектно-ориентированной методологии (ООМ) являются:

- объектно-ориентированный анализ;

- объектно-ориентированное проектирование;

- объектно-ориентированное программирование.

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

1) объектно-ориентированное программирование использует в качестве элементов конструкции объекты, а не алгоритмы;

2) каждый объект является реализацией определенного класса;

3) классы организованы иерархически.

Объектно-ориентированноепроектирование. Методы

программирования, прежде всего, подразумевают правильное и эффективное использование механизмов языков программирования. Методы проектирования напротив, основное внимание направляют на правильное и эффективное структурирование сложных систем.

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

В данном определении содержатся две важные части:

1) объектно-ориентированное проектирование ведет к объектно-ориентированной декомпозиции;

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

Именно поддержка объектно-ориентированной декомпозиции отличает объектно-ориентированное проектирование от структурного проектирования.

Объектно-ориентированный анализ. На объектный подход оказали влияние предыдущие этапы развития программных средств. Традиционные приемы структурного анализа основаны на потоках данных в системе.

Объектно-ориентированный анализ (ООА) направлен на создание моделей, более близких к реальности, с использованием объектно-ориентированного подхода; это методология, при которой требования формируются на основе понятий классов и объектов, составляющих словарь предметной области.

На результатах ООА формируются модели, на которых основывается объектно-ориентированное проектирование; объектно-ориентированное проектирование в свою очередь создает основу для окончательной реализации системы с использованием методологии объектно-ориентированного программирования

Главными достоинствами ООП по сравнению со структурными методами являются:

  • возможность преодолеть ограничения, связанные со сложностью разрабатываемых систем;

  • использование на стадии анализа моделей близких к реальности;

  • применение как при анализе и проектировании информационных систем, так и систем реального времени и аппаратно-программных комплексов;

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

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

  • естественная работа с разнородной информацией, используемой в мультимедиа системах;

  • создание более открытых систем;

  • полное использование описательных возможностей объектно-ориентированных языков программирования.

Принципы объектного подхода.

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

  • абстрагирование

  • ограничение доступа или инкапсуляция

  • модульность

  • иерархия.

Без любого из этих элементов модель не будет объектно-ориентированной. Кромеглавных имеется три дополнительных элемента:

  • типизация

  • параллелизм

  • сохраняемость или устойчивость

Эти элементы полезны в объектной модели, но не обязательны.

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

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

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

Иерархия - ранжированная (упорядоченная) система абстракций. Основными видами иерархических структур, применительно к сложным системам, является структура классов (иерархия "is -а") и структура объектов (иерархия "partof). Принцип наследования позволяет упростить выражения абстракции, делая проект менее громоздким и более выразительным.

Наследование - это такая иерархичность абстракций, в которой подклассы наследуют строение от одного или нескольких суперклассов. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы. Суперклассы отражают наиболее общие, а подклассы более специализированные абстракции. Поэтому о наследовании говорят, как об иерархии «обобщение специализации». Различают случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного суперкласса, во втором случае суперклассов может быть несколько. Если в языке или системе поддерживается единичное наследование классов, набор классов образует древовидную иерархию. При поддержании множественного наследования классы связаны в ориентированный граф с корнем, называемый решеткой классов.

Дополнительные элементы:

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

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

Параллелизм. Для определенной категории задач автоматические системы реализуют обработку многих событий, происходящих одновременно. В то время как объектно-ориентированное программирование строится на абстракции, инкапсуляции и наследовании, параллелизм связан с абстрагированием процессов и синхронизацией. Объект является основой, которая объединяет обе концепции. Каждый объект (как абстракция реальности) может представлять собой отдельный поток управления (абстракцию процесса). Такой объект называется активным Параллелизм-свойство, отличающее активные объекты от пассивных. Для систем, построенных на основе объектно-ориентированного проектировании, реальность может быть представлена, как совокупность взаимодействующих объектов, часть из которых - активна.

Сохраняемость /устойчивость - это свойство объекта существовать во времени и/или пространстве, вне зависимости от процессов, породивших

Полиморфизм — взаимозаменяемость объектов с одинаковым интерфейсом. Здесь под интерфейсом понимается совокупность методов, через которые происходит взаимодействие с объектом. Несколько объектов должны иметь такой одинаковый набор методов (методов с одинаковыми именами и сигнатурами), а также эти методы должны реализовывать похожую функциональность.

Полиморфизм — это возможность использования экземпляра класса-наследника там, где требуется экземпляр базового класса. Однако, существуют языки, в которых нет выраженного понятия «наследование» или же для реализации полиморфных объектов не требуется использование наследования (например, в Perl).

К недостаткам ООП относятся некоторое снижение производительности функционирования ПО (которое, однако, по мере роста производительности компьютеров становится все менее заметным) и высокие начальные затраты.


Контрольные вопросы:

  1. Что такое объектно-ориентированное программирование?

  2. Приведите примеры языков объектно-ориентированного программирования

  3. Перечислите основные достоинства объектно-ориентированного программирования.

Тема 11. CASE - средства, их функциональные возможности и характеристика

План лекции:

  1. CASE-средства. Общая характеристика и классификация

  2. CASE-технологии



CASE-средства (от ComputerAidedSoftware/SystemEngineering) позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Применимы практически во всех сферах деятельности. Результат применения CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

  • применяемым методологиям и моделям систем и БД;

  • степени интегрированности с СУБД;

  • доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

  • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (MetaSoftware), BPwin (LogicWorks));

  • средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (VantageTeamBuilder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnellDouglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

  • средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. КнимотносятсяERwin (Logic Works), S-Designor (SDP) иDataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств VantageTeamBuilder, Designer/2000, Silverrun и PRO-IV;

  • средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), NewEra (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав VantageTeamBuilder, PRO-IV и частично - в Silverrun;

  • средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав VantageTeamBuilder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (RationalRose (RationalSoftware), ObjectTeam (Cayenne)).

Вспомогательные типы включают:

  • средства планирования и управления проектом (SE Companion, MicrosoftProject и др.);

  • средства конфигурационного управления (PVCS (Intersolv));

  • средстватестирования (Quality Works (Segue Software));

  • средства документирования (SoDA (RationalSoftware)).

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

  • Vantage Team Builder (Westmount I-CASE);

  • Designer/2000;

  • Silverrun;

  • ERwin+BPwin;

  • S-Designor;

  • CASE.Аналитик.

Описание перечисленных CASE-средств приведено в разделе 5. Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, SystemArchitect, VisibleAnalystWorkbench, EasyCASE), так и новые версии и модификации перечисленных систем.

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

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

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

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

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

Согласно обзору передовых технологий (SurveyofAdvancedTechnology), составленному фирмой SystemsDevelopmentInc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

  • CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

  • реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

  • широкое разнообразие качества и возможностей CASE-средств;

  • относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

  • широкое разнообразие в практике внедрения различных организаций;

  • отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

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

  • различная степень интеграции CASE-средств в различных проектах.

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

Для успешного внедрения CASE-средств организация должна обладать следующими качествами:

  • Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

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

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

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

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

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

  • отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;

  • CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;

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

  • негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

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

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

приемлемый уровень отдачи от инвестиций в CASE-средства





Тема 12. Оценка и управление качеством АИС

План лекции:

  1. Понятие профиля информационной системы.

  2. Принципы формирования профиля информационной системы

  3. Структура профилей информационных систем

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

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

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

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

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

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

Обычно рассматривают две группы профилей, регламентирующих:

• архитектуру и структуру информационной системы;

• процессы проектирования, разработки, применения, сопровождения и развития системы.

В зависимости от области применения профили могут иметь разные категории и соответственно разные статусы утверждения:

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

• профили информационной системы, предназначенные для решения некоторого класса прикладных задач.

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

Принципы формирования профиля информационной системы

Профили информационных систем призваны решить следующие задачи:

• снижение трудоемкости проектов;

• повышение качества компонентов информационных систем;

• обеспечение расширяемости и масштабируемости разрабатываемых систем;

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

• обеспечение переносимости прикладного программного обеспечения.

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

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

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

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

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

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

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

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

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

Между приложениями и средой определяются стандартизованные прикладные программные интерфейсы (ApplicationProgrammingInterface, API), которые являются необходимой частью профилей любой открытой системы. Кроме того, в профилях могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды системы. Спецификации выполняемых функций и интерфейсов взаимодействия могут быть оформлены в виде профилей компонентов системы. Таким образом, профили информационной системы с иерархической структурой могут включать в себя:

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

• функции взаимодействия системы с внешней для нее средой;

• стандартизованные интерфейсы между приложениями и средой информационной системы;

• профили отдельных функциональных компонентов, входящих в систему.

Для эффективного использования конкретного профиля необходимо:

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

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

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

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

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

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

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

Структура профилей информационных систем

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

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

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

Формирование и применение профилей конкретных информационных систем выполняется на основе международных и национальных стандартов, ведомственных нормативных документов, а также стандартов де-факто при условии доступности соответствующих им спецификаций. Для обеспечения корректного применения профилей их описания должны содержать:

• определение целей использования профиля;

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

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

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

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

• информационные ссылки на все исходные документы.

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

• прикладного программного обеспечения;

• среды информационной системы;

• защиты информации в информационной системе;

• инструментальных средств, встроенных в информационную систему.

Профиль прикладного программного обеспечения

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

Контрольные вопросы:

  1. Что такое профиль информационной системы?

  2. Какие профили информационной системы вы знаете?



Тема 13. Организация труда при разработке АИС. Оценка необходимых ресурсов дляорганизации проекта

Стандарты и методики

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

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

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

• на продукты и услуги;

• на процессы и технологии;

• на формы коллективной деятельности, или управленческие стандарты.

Виды стандартов

Существующие на сегодняшний день стандарты можно условно разделить на несколько групп.

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

• По утверждающей организации. Здесь можно выделить официальные международные, официальные национальные или ведомственные национальные стандарты (например, ГОСТ, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (например, OMG), стандарты де-факто – официально никем не утвержденные, но фактически действующие (например, стандартом де-факто долгое время были язык взаимодействия с реляционными базами данных SQL и язык программирования C), фирменные стандарты (например, Microsoft ODBC).

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

Тема 14. Методика OracleCDM. Основные принципы стандарта OracleCDM.

Методика CDM является развитием давно разработанной методики CASE-Method фирмы Oracle, применяемой в CASE-средстве Oracle CASE (в новых версиях – Designer/2000).

Ниже перечислены основные составляющие CASE-технологии и инструментальной среды фирмы Oracle.

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

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

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

• Наличие централизованной базы данных – репозитария. Репозитарийпредназначен для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Он представляет собой базу данных специальной структуры, работающую под управлением СУБД Oracle.

• Возможность одновременной работы с репозитарием многих пользователей. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД Oracle.

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

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

Особенности методики CDM

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

• Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:

– классическая модель предусматривает все этапы;

– быстрая разработка ориентирована на использование инструментов моделирования и программирования Oracle;

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

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

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

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

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

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

• Методика CDM представляет собой вполне конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах информационных систем с опорой на инструментальные средства и СУБД фирмы Oracle.

Тема 15. Принципы стандарта ISO/IEC. Принципы стандарта ГОСТ 34.

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

Целесообразность совместного использования стандартов на информационные системы и наПО обуславливается одним из положений ISO 12207, согласно которому процессы, протекающие во время жизненного цикла ПО, должны быть совместимы с процессами, протекающими во время жизненного цикла автоматизированной системы.

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

Примечание.

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

Особенности стандарта ISO 12207

Все сказанное выше позволяет сформулировать некоторые особенности стандарта ISO 12207.

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

Примечание.

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

• Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами информационных систем. Адаптация сводится к исключению процессов, видов деятельности и задач, неприменимых в конкретном проекте.

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

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

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

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





Тема 16. Структура средств коллективного проектирования. Методы и средства. Идентификация

Создание крупных ИС требует согласованной работы целой группы программистов.

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

  1. Регистрация всех изменений, вносимых в проект;

  2. Централизованного хранения файлов проекта.

Под проектом понимают множество файлов с исходными текстами программ, а также файлов ресурсов и всех прочих файлов (исполняемых файлов, библиотек DLL, элементов ActiveX, объектных модулей, документов), необходимых для компиляции и запуска приложения.

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

  • Идентификацию состояния как отдельных компонентов, так и проекта в целом;

  • Контроль за вносимыми в компоненты и структуру проекта изменениями;

  • Координированное управление всеми составляющими проекта.

Идентификация

Чтобы осуществлять управление объектами, необходимо их идентифицировать. При идентификации объектов в системах PVCS используется понятие версии. Версией проекта называется некий уникальный идентификатор, обозначающий текущий номер разработки. Так как в отдельные составляющие проекта во время разработки могут вноситься изменения, каждому из объектов, помещенных в PVCS-хранилище, присваиваются идентификаторы версий самого объекта и проекта в целом. Это позволяет определить, какие именно файлы должны быть использованы для сборки заданной версии приложения.


Тема 17. Хранение файлов и контроль за изменением файлов. Блокировки. Последовательность работы с PVCS.

Хранение файлов и контроль за их изменением

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

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

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

Блокировки

Система контроля версий обязательно должна обеспечивать блокировку. Блокировка преследует две основные цели.

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

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

Последовательность работы

Последовательность операций, выполняемых при использовании системы PVCS:

  1. Ввод исходной операции о структуре проекта и его составляющих. Создание первой версии проекта в PVCS-хранилище.

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

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

  4. Занесение в PVCS-хранилище измененных (или вновь созданных) составляющих проекта с присвоением номеров версий как самим составляющим, так и проекту в целом.

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

Существует множество инструментов, предназначенных для контроля версий проектов. Наиболеепопулярны StarTeam, TeamSourse, Microsoft Visual Sourse Safe QSC Team Conerence.

Тема 18. Система контроля версии TeamSource. Структура. Идентификация проекта. Хранение.

Структура программы TeamSource

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

Izlib.tsx — основной контроллер версий, осуществляющий хранение файлов проекта в библиотеках формата ZLib (совместимого с форматом ZIP, но, в отличие от последнего, не требующего лицензирования);

tscomments.tsx — контроллер ввода комментариев к файлам и проектам.

Идентификация проекта и его составляющих в TeamSource

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

Можно также реализовать собственный генератор версий, создав специальное расширение TeamSource.

Версия проекта задается при его описании и не генерируется автоматически.

Отдельные версии проекта можно отмечать путем установки закладок. Установленная закладка отмечает текущую версию всех составляющих проекта.

Использование закладок в значительной степени упрощает управление файлами при сборке проекта, а также при указании текущей версии проекта. При необходимости закладку можно снабдить комментариями.

Хранилище TeamSource

Как уже отмечалось, хранилище TeamSource организовано по файловому принципу. Для каждого проекта выделяется каталог, называемый корневым (root), в котором создается структура вложенных каталогов и файлов, соответствующая файлам и каталогам, включенным в описание проекта. Ниже описана структура файлов и каталогов, которая создается для каждого корневого каталога изначально.

Archives — каталог, в котором содержатся версии файлов проекта. Файлы хранятся в архивированном виде в формате ZLib. В каталоге представлены все версии каждого из файлов проекта. Имена присваиваются файлам по следующему принципу: к имени исходного файла (включая расширение) добавляется расширение z (например, файл project.dpr получит имя project.dpr.z). Помимо файлов проекта, данный каталог содержит еще два файла:

  • файл с информацией о проекте (название проекта, версия TeamSource и уникальное имя контроллера версий, получаемое от соответствующего модуля расширения);

  • файл, содержащий версию проекта.

History — каталог, в котором сохраняется информация об изменениях файлов в хранилище. Имена файлов в этом каталоге, называемых файлами истории, имеют вид:

<код даты и времени>.<имя рабочей станции>

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

Locks — каталог, предназначенный для хранения информации о блокировках. Обычно содержит единственный файл lockinfo.txt

logs.txt — журнал работы с проектом.

Summary.txt — результирующие данные о каждом сеансе работы с проектом.



Курс лекций по дисциплине "Автоматизированные информационные системы"
  • Информатика
Описание:

Курс лекций составлен для студентов, обучающихся по специальности 230103 «Автоматизированные системы обработки информации и управления (по отраслям)» в соответствии с требованиями федерального государственного образовательного стандарта 3 поколения к минимуму содержания и уровню подготовки выпускников СПО по дисциплине «Автоматизированные информационные системы».

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


Автор Комарова Елена Валерьевна
Дата добавления 03.06.2015
Раздел Информатика
Подраздел Конспекты
Просмотров 3899
Номер материала 59857
Скачать свидетельство о публикации

Оставьте свой комментарий:

Введите символы, которые изображены на картинке:

Получить новый код
* Обязательные для заполнения.


Комментарии:

↓ Показать еще коментарии ↓