Теория информационных процессов и систем

Размещено на http://www.allbest.ru/

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

«Теория информационных процессов и систем (ТИПиС)»

(3-й семестр, 12 часов лекций, 18 часов лаб., экзамен)

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



1. Распечатать текст лекций по ТИПиС (лекции 1 - 3, 5 - 7, 9 - 11, 17, 19, 20 из Moodle) и привезти с собой на сессию.

2. Познакомиться (по возможности) с интегрированной средой Turbo Delphi, чтобы легче было выполнить лабораторные занятия по ТИПиС, и с языком программирования Pascal, включая основы объектно-ориентированного программирования.

3. Научиться копировать базу данных, набранную и сохраненную в СУБД Access, в папку проекта, созданного в Turbo Delphi.

Литература

1. Ю.С. Избачков, В.Н. Петров. Информационные системы. Учебник. - СПб.: Питер, 2008. - 656 с.

2. Бройдо В.Л. Вычислительные системы, сети и телекоммуникации . Учебник для вузов. - СПб.: Питер, 2008, 688 с.

3. Н.Б. Культин. Основы программирования в Turbo Delphi . - СПб.: БХВ-Петербург, 2007. - 384 с.

4. Дарахвелидзе П.Г., Марков Е.П. Программирование в Delphi 7. - СПб.: БХВ-Петербург, 2005. - 784 с.

Примечание: среда Turbo Delphi входит в состав пакета Borland Developer Studio, является свободно распространяемым программным продуктом и может быть скачена из Интернета.



Темы рефератов /(контрольная работа для студентов заочной формы обучения)

1. Методы описания систем типа «мозговой атаки»

2. Методы описания систем типа «сценариев»

3. Методы экспертных оценок для описания систем

4. Методы описания систем типа «Дельфи»

5. Методы описания систем типа «дерева целей»;

6. Морфологические методы описания систем

7. Методика системного анализа

8. Информационные модели систем поддержки принятия решений;

9. Уровни абстрактного описания систем

10. Символический уровень описания систем

11. Теоретико-множественный уровень описания систем

12. Абстрактно-алгебраический уровень описания систем

13. Топологический уровень описания систем

14. Логико-математический уровень описания систем

15. Теоретико-информационный уровень описания систем

16. Динамический уровень описания систем

17. Эвристический уровень описания систем

18. Технические, биологические и другие системы

19. Детерминированные и стохастические системы

20. Хорошо и плохо организованные системы

21. Самоорганизующиеся системы

22. Системный подход, системные исследования, системный анализ

23. Кибернетический подход к описанию систем

24. Динамическое описание систем

25. Агрегатное описание систем

26. Информационные процессы Поиск информации и Хранение информации

27. Информационные процессы Передача информации и Обработка информации

28. Информационный процесс Кодирование информации

29. Информационный процесс Использование информации

30. Информационный процесс Защита информации



Вопросы для экзамена по курсу «Теория информационных процессов и систем»

(заочная форма обучения)

1. Основные понятия теории систем (система, элемент, подсистема, структура, связь, состояние, поведение).

2. Основные понятия теории систем ( внешняя среда, модель, входы и выходы, равновесие, устойчивость, развитие, цель, информация, данные).

3. Основные задачи теории систем.

4. Общая классификация систем.

5. Модели систем.

6. Понятие информационной системы. Типовые программные компоненты ИС.

7. Факторы, влияющие на развитие ИС.

8. Корпоративные информационные системы. Структура КИС.

9. Классификация информационных систем (по масштабу,по сфере применения, по способу организации).

10. Типовые функциональные компоненты информационных систем.

11. Архитектура информационных систем. Краткая сравнительная характеристика.

12. Основные архитектуры ИС (централизованная, файл-сервер, клиент-сервер, многоуровневая, интернет/интранет-технологии).

13. Понятие проекта. Отличительные признаки проекта.

14. Классификация проектов.

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

16. Понятие жизненного цикла информационных систем. Процессы ЖЦ ИС.

17. Структура жизненного цикла информационных систем.

18. Модели жизненного цикла информационных систем. Краткая характеристика.

19. Каскадная модель ЖЦ ИС. Основные этапы разработки. Основные достоинства. Недостатки каскадной модели.

20. Спиральная модель ЖЦ ИС. Итерации. Преимущества и недостатки спиральной модели.

21. Методология и технология разработки ИС (основные задачи методологии, основное содержание технологии, основные требования).

22. Методология RAD (основные особенности, основные принципы, ограничения).

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

24. Основные информационные процессы и их характеристика.

25. Процесс накопления информации. Процесс хранения информации.

26. Процесс передачи информации. Процесс обработки информации.

27. Среда разработки приложений Delphi.

28. Консольные приложения в Delphi.

29. Основные понятия и принципы объектно-ориентированного программирования.



Лекция 1. Введение. Основные понятия. Корпоративные информационные системы. Структура КИС

Введение

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

Базы данных

Итак, СУБД является неотъемлемой частью любой ИС. Тип используемой СУБД обычно определяется масштабом ИС - малые ИС могут использовать локальные СУБД, а корпоративные ИС требуют мощной клиент-серверной СУБД, поддерживающей многопользовательскую работу. Несмотря на очевидные преимущества и растущую популярность объектно-ориентированных СУБД (ObjectStore, Objectivity, O2, Jasmin), пока преобладают реляционные БД, являющиеся хорошо отлаженными системами, поддерживающими стандарт SQL-92 (Structured Query Language - структурированный язык запросов) (Oracle, Informix, Sybase, DB2, MS SQL Server). Традиционный способ организации ИС - двухзвенная архитектура клиент-сервер, при которой вся прикладная часть ИС размещается на рабочих станциях, а сервер осуществляет только доступ к БД. Чтобы разгрузить клиентскую рабочую станцию и уменьшить загрузку сети, применяют трех-звенную архитектуру клиент-сервер, в которой добавляется еще промежуточный сервер приложений. В этом случае на стороне клиента выполняются только интерфейсные действия, а вся логика обработки информации поддерживается сервером приложений.

Средства разработки

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

В качестве среды разработки приложений рассмотрим популярную в России среду Delphi. Delphiбазируется на языке Object Pascal, для которого характерны строгость и простота, и в котором в полной мере реализованы все основные концепции ООП. ООП позволяет сделать любую систему более гибкой и динамичной, исключив необходимость постоянного переписывания структуры БД и приложений.

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

CASE-средства

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

Указанные проблемы способствовали появлению программно-технологических средств специального класса, так называемых CASE-средств, призванных повысить эффективность разработки ИС (CASE - Computer Aided Software/-System Engineering). Под CASE-средствами понимают программные средства, поддерживающие процессы разработки и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и БД, генерацию кода, конфигурационное управление и управление проектом, а также другие процессы.

Примеры CASE-средств: система моделирования Power Designer фирмы Sybase для разработки онцептуальных моделей ИС, система Rational Rose фирмы Rational Software и др.

Часть I

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

Основные понятия

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

В общем случае типовые программные компоненты ИС включают: диалоговый ввод-вывод, логику диалога, прикладную логику обработки данных, логику управления данными, операции с файлами и/или БД.

Можно выделить три наиболее существенных фактора, оказавших влияние на развитие ИС в последние годы:

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

2. развитие сетевых технологий: локальные ИС повсеместно вытесняются клиент-серверными и многоуровневыми ИС;

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

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

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

Структура КИС

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



Лекция 2. Классификация информационных систем (по масштабу, по сфере применения, по архитектуре)

Классификация ИС

ИС можно классифицировать по разным признакам. Рассмотрим наиболее часто используемые способы классификации.

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

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

Схема 1 

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

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

Групповые ИС ориентированы на коллективное использование информации и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используют серверы БД (SQL-серверы). Наиболее популярные SQL-серверы: Oracle, DB 2, Microsoft SQL Server, InterBase, Sybase, Informix .

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

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

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

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

Схема 2 

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

Транзакция - это последовательность операций над базой данных, рассматриваемых СУБД как единое целое.

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

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

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

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

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

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



Схема 3

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



Лекция 3. Типовые функциональные компоненты ИС. Архитектура ИС (файл-сервер, клиент-сервер, многоуровневая архитектура)

Типовые функциональные компоненты ИС

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

Таблица 1

Архитектура ИС

Архитектура файл-сервер

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

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

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

Архитектура клиент-сервер

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

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FSразмещаются на сервере, а диалог PS , PL и логика BL , DL - на клиенте. Двухуровневая модель архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД - на сервере.

Схема 4

Классический вариант клиент-серверной ИС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пока на российском рынке доминирует архитектура клиент-сервер.

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

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

Благодаря интеграции Интернет/интранет-технологий и архитектуры клиент-сервер процесс внедрения и сопровождения ИС существенно упрощается.



Лекция 4. Области применения и примеры реализации ИС

Области применения и примеры реализации ИС

Рассмотрим наиболее важные задачи, решаемые с помощью ИС.

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

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

3. Управление складом, ассортиментом, закупками. Можно автоматизировать процесс анализа движения товара, тем самым отследив и зафиксировав те 20% ассортимента, которые приносят 80% прибыли. Подобный анализ позволяет также ответить на главный вопрос: как получить максимальную прибыль при постоянной нехватке средств?

4. Управление производственным процессом. Это очень трудоемкая задача. Основные механизмы здесь - планирование и оптимальное управление. Автоматизированное решение задачи УПП дает возможность грамотно планировать, учитывать затраты, оперативно управлять процессом выпуска продукции и т.д.

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

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

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

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



Лекция 5. Жизненный цикл информационных систем. Проект. Классификация проектов. Основные фазы проектирования ИС

Тема 2. Жизненный цикл информационных систем

Проект

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

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

1. изменчивость ;

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

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

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

5. новизна для предприятия ;

6. комплексность ;

7. правовое и организационное обеспечение.

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

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

Классификация проектов

Проекты можно классифицировать по различным признакам. Отметим основные из них.

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

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

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

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

Основные фазы проектирования ИС

Каждый проект проходит в своем развитии определенные состояния. Совокупность ступеней развития проекта принято разделять на фазы (стадии, этапы). Можно выделить следующие фазы развития ИС:

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

2. разработка технического задания ;

3. проектирование ;

4. изготовление ;

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

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

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

Разработка технического задания (ТЗ): главное содержание этой фазы - разработка ТЗ и переговоры с заказчиком о заключении контракта. На этой фазе разрабатывается основное содержание и структура проекта, разработка и утверждение ТЗ, составление сметы и бюджета проекта, разработка календарного плана и графика работ, подписание контракта.

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

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

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

Жизненный цикл ИС

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

Существует международный стандарт , регламентирующий ЖЦ ИС - ISO/IEC 12207 (ISO - International Organization of Standartization, IEC - International Electrotechnical Comission).

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

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

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

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

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

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

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

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

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

Вспомогательные процессы ЖЦ ИС

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

 Организационные процессы ЖЦ ИС

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

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

 Структура жизненного цикла ИС

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

Согласно методологии, предлагаемой Rational Software, ЖЦ ИС подразделяется на четыре стадии: начало, уточнение, конструирование, сдача в эксплуатацию. Границы каждой стадии определены некоторыми моментами времени, в которые должны быть достигнуты определенные ключевые цели.

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

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

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

Сдача в эксплуатацию: готовая ИС передается пользователю. 

Лекция 6. Основные модели ЖЦ ИС. Каскадная модель: характеристика, достоинства, недостатки. Спиральная модель: характеристика, достоинства, проблемы.

Модели жизненного цикла ИС

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

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ ИС: каскадная модель (модель «водопад» - waterfall ) и спиральная модель.

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

Каскадная модель (КМ) характерна для классического подхода к разработке различных систем в любых прикладных областях. Для разработки ИС данная модель широко использовалась в 70-80-х годах. Каскадные методы проектирования хорошо описаны в отечественной и зарубежной литературе. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различных областях

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

Основные этапы разработки по КМ

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

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

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

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

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

· сдача готового проекта .

Схема 5

Каскадная модель разработки

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

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

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

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

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

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

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

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

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

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

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

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

Основные недостатки каскадной модели следующие:

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

2. необходимость возврата на предыдущие этапы;

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

4. информационная перенасыщенность каждого этапа;

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

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

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

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

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

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

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

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

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

Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого этапа разработки. Результат можно увидеть лишь в конце работ. Изменения в предметной области или в законодательстве изменения в проекте «зацикливание» процесса разработки. Расходы растут, срок сдачи откладывается. Поэтому сложные проекты, разрабатываемые по КС, имеют повышенный уровень риска. По данным консалтинговой компании The Standish Group, в США более 31% проектов КИС (IT-проектов) прогорают; почти 53% IT-проектов завершаются с перерасходом бюджета в среднем на 189%, и только 16,2% проектов укладываются и в срок, и в бюджет.

Схема 6

Реальный процесс разработки по КС

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

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

Итерации

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

Схема 7

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

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

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

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

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

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

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

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

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