39990

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

Книга

Информатика, кибернетика и программирование

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

Русский

2013-10-13

959.15 KB

773 чел.

Космачев С.Н.

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

для студентов специальности «Автоматизированные системы обработки информации и управления»

дневной формы обучения

2009


Содержание

1. Понятие автоматизированной информационной системы 3

2. Структура автоматизированной информационной системы 6

3. Основные понятия системного анализа 9

4. Порядок системного анализа 12

5. Принципы системного анализа 15

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

7. Процессы жизненного цикла АИС: основные, вспомогательные, организационные. 20

8. Этапы (стадии) жизненного цикла АИС 23

9. Описание предметной области АИС моделью «Как есть» 25

10. Информационное обеспечение АИС и информационные модели «Как должно быть» 26

11. Управление требованиями на стадиях детального проектирования, разработки, внедрения и сопровождения ИС 28

12. Анализ предметной области АИС 31

13. Выбор проектных решений АИС и его обоснование 35

14. Проектирование системной архитектуры и анализ требований к ПО 38

15. Проектирование программной архитектуры и техническое проектирование программных средств 40

16. Кодирование 43

17. Тестирование 45

18. Установка и сопровождение 47

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

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

21. Понятие и виды моделей информационной системы 54

22. Методы проектирования АИС 55

23. Графическая нотация и метод проектирования IDEF0 57

24. Графическая нотация и метод проектирования IDEF3 59

23. Методика построения DFD-диаграмм 63

24. Графическая нотация EPC 67

25. Нотация ARIS Organizational Chart 69

26. Нотация ARIS Information Flow 70

27. Сравнительный анализ ARIS IDEF0 и IDEF3 71

28. Метод проектирования 1С:Профкейс 72

29. Понятие технологии проектирования 73

30. Технология проектирования информационного обеспечения АИС 74

31. Технологии проектирования программного обеспечения АИС (структурный и объектно-ориентированный подходы). 76

32. САSЕ-средства, их функциональные возможности и характеристика. 79

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

34. Организация труда при разработке АИС 82

35. Оценка необходимых ресурсов для реализации проекта 83

36. Технология групповой разработки АИС 84

37. Автоматизация управления групповой разработкой проектов АИС на примере 1С:Предприятия 84

38. Классификация АИС по признаку структурированности задач 87

39. Классификация АИС по виду деятельности 90

40. Классификация информационных систем по уровням управления 91


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

Система (от греч. σύστημα, «составленный») — множество взаимосвязанных объектов и ресурсов, организованных процессом системогенеза в единое целое и противопоставляемое среде.

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

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

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

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

Цели деятельности, определяющие назначение АИС, формулируются одним из двух способов:

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

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

Таблица 1. Технологии, меняющие старые правила новыми

Старое правило

Технология

Улучшение (пример)

Информация может появляться только в одно время в одном месте

Распределенные базы данных

И. может одновременно появляться в неск. местах по необходимости

Сложную работу могут выполнить только эксперты

Экспертные системы

Функции эксперта может выполнить генеральный менеджер

Фирмы должны выбирать между централизацией и децентрализацией

Телекоммуникационные сети

Ф. могут одновременно использ. выгоды централиз. и децентрализация

Всё решают менеджеры

Инструменты поддержки принятие решений

Каждый работник принимает участие в принятии решения

Полевому персоналу необходим офис идя приема, хранения и передачи информации

Беспроволочные коммуникации, широковещательные сети и портативные компьютеры

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

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

Интерактивный оптический диск

Лучший контакт с потенц. покупателем — эффективный контакт

Кто-то должен отслеживать местонахождение предметов

Автоматическая идентификация и технология трекинга

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

Планы пересматриваются периодически

Высококачественное выполнение вычислений, компьютерные сети, сетевое программное обеспечение

Планы пересматриваются мгновенно

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

Рис.1. Цепочка Деминга

Например, «Оперативный учет продажи билетов». В театральную кассу я обращаюсь за билетом, и меня вполне устроит, если кассирша выпишет мне его ручкой на бланке, лишь бы меня по нему пустили в зал. Кассирше, по большому счету, тоже все равно, как именно изготовить билет. Ее устроит любой способ, если он будет не слишком трудоемок и обеспечит ей возможность продать мне билет. Иначе говоря, у нас с ней есть общая цель. В ГОСТ 34.003-90 для ее обозначения используется термин цель деятельности. Всякий раз, когда очередной зритель отходит от окошка с билетом в руках, а театр становится чуточку богаче, эта цель деятельности достигается.

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

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

Функции автоматизированной системы формулируются следующим образом.

Совокупность действий автоматизированной системы, направленная на достижение определенной цели, согласно ГОСТ 34.003-90, называется ее функцией. Функция это действие или набор действий, выполняемых над исходным объектом (документом, ТМЦ и прочим) с целью получения заданного результата.

Функция автоматизированной системы — фундаментальное понятие в ГОСТ 34. Автоматизированная система рассматривается, в первую очередь, как сумма своих функций и уж потом как куча «софта» и «железа». Самое главное, что делает система, а из чего она состоит, второстепенно.

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

Задачи автоматизированной системы.

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

В ГОСТ 34.003-90 задачей называется последовательность автоматических действий, приводящая к результату заданного вида.

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

2. Структура автоматизированной информационной системы

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

Рис.2. Элемент состава системы

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

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

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

Связь входит в любое определение системы наряду с понятием «элемент» и обеспечивает возникновение и сохранение структуры и целостных свойств системы. Это понятие характеризует одновременно и строение (статику), и функционирование (динамику) системы.

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

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

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

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

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

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

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

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

информационное обеспечение — все данные и метаданные, с которыми работает система;

программное обеспечение — все программы, которые входят в состав системы;

техническое обеспечение — все технические средства (иначе говоря, оборудование, аппаратура), которые входят в состав системы.

Повторим еще раз, это не все виды обеспечения. Мы даже не можем уверенно сказать, что они самые важные. Например, для автоматизированных систем управления технологическими процессами (АСУТП) огромное значение имеет метрологическое обеспечение. Многие автоматизированные системы требуют сложного математического и лингвистического обеспечения. Но представить себе автоматизированную систему, которая была бы полностью лишена одного из трех перечисленных (табл.2) видов обеспечения, затруднительно.

Таблица 2. Пример деления автоматизированной системы

Виды обеспечения

Подсистема продажи билетов

Подсистема формирования ежедневных отчетов

информационное обеспечение

цены на билеты, карта зрительного зала

форма ежедневного отчета

записи о проданных билетах

техническое обеспечение

персональный компьютер, принтер, контрольно-кассовая техника (ККМ, сканер штрих-кода)

программное обеспечение

текстовый редактор

СУБД

электронные таблицы

3. Основные понятия системного анализа

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

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

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

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

Рис.3. Связь системы – предприятия с внешней средой

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

Важным для описания и исследования систем является понятие алгоритм функционирования As, под которым понимается метод получения выходных характеристик y(t) с учетом входных воздействий x(t), управляющих воздействий u(t) и воздействий внешней среды n(t).

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

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

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

Формально процесс функционирования как последовательная смена состояний интерпретируется как координаты точки в k-мерном фазовом пространстве. Причем каждой реализации процесса будет соответствовать некоторая фазовая траектория. Совокупность всех возможных значений состояний {z} называется пространством состояний системы.

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

C = Целостность (П, И, Н, Д),

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

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

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

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

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

С* = max{СJ}.

Если решение выбирается по качественным характеристикам, то критерий называется решающим правилом.

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

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

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

4. Порядок системного анализа

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

Рис.4. Общий подход к решению проблем системного анализа

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

Рис.5. Дерево функций системного анализа

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

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

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

3. Описание воздействующих факторов.

4. Описание тенденций развития, неопределенностей разного рода.

5. Описание системы как «черного ящика».

6. Функциональная (по функциям), компонентная (по виду элементов) и структурная (по виду отношений между элементами) декомпозиции системы.

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

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

Рассмотрим некоторые наиболее часто применяемые стратегии декомпозиции.

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

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

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

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

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

2. Морфологический анализ- анализ взаимосвязи компонентов.

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

4. Анализ аналогов.

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

6. Формирование требований к создаваемой системе, включая выбор критериев оценки и ограничений.

Этап проектирования (синтеза) системы:

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

2. Синтез альтернативных структур системы, снимающей проблему.

3. Синтез параметров системы, снимающей проблему.

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

Оценка степени снятия проблемы проводится при завершении системного анализа.

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

5. Принципы системного анализа

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

Принцип конечной цели, абсолютный приоритет конечной (глобальной) цели:

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

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

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

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

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

Принцип природной специфичности объекта, подсистем, факторов внешней среды.

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

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

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

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

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

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

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

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

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

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

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

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

Условными фазами или стадиями жизненного цикла ИС являются анализ, проектирование, реализация проекта, внедрение (ввод в эксплуатацию), сопровождение (эксплуатация, наращивание возможностей - модернизация), вывод из эксплуатации (замена):

анализ - определение того, что должна делать система;

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

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

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

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

Стандарты жизненного цикла ИС:

ГОСТ 34.601-90 (не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели).

ISO/IEC 12207:1995. "Information Technology - Software Life Cycle Processes" (российский аналог — ГОСТ Р ИСО/МЭК 12207-99, введен 1 июля 2000 г.) является основным нормативным документом, регламентирующим состав процессов жизненного цикла ИС. Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС.

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

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

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

  1.  последовательность выполняемых стадий;
  2.  результаты выполнения работ на каждой стадии;
  3.  ключевые события - точки завершения работ и принятия решений.

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Специфические (отраслевые) подходы к разработке программного обеспечения реализованы в концепциях жизненного цикла, в основе которых лежат требования ИСО 12207:

Rapid Application Development (RAD) – стадии анализ и планирование требований, проектирование, реализация, внедрение.

Custom Development Method (методика Oracle).

Rational Unified Process (RUP) – рациональный унифицированный процесс (IBM).

Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования (Microsoft).

Подход «кодирование и исправление» (code and fix) упрощенно может быть описан следующим образом. Разработчик начинает кодирование (написание программы) системы с самого первого дня ее разработки, не занимаясь серьезным проектированием. Все ошибки и недоработки обнаруживаются, как правило, к концу кодирования и требую исправления через повторное кодирование.

Экстремальное программирование (англ. Extreme Programming, XP). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.

7. Процессы жизненного цикла АИС: основные, вспомогательные, организационные.

Рис.6. Структура процессов ЖЦ АИС
(цифра – номер пункта стандарта ГОСТ Р ИСО/МЭК 12207-99)

Таблица 3. Содержание основных процессов ЖЦ ПО АИС (ISO/IEC 12207):

Процесс (испол- нитель)

Действия

Вход

Результат

Приобретение (действия и задачи заказчика, приобретающего ИС)

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

Решение о начале работ. Результаты обследования. Результаты анализа рынка ИС/ тендера. План поставки/ разработки. Комплексный тест.

Технико-экономическое обоснование внедрения. Техническое задание. Договор на поставку/ разработку. Акты приемки этапов работы. Акт приемно-сдаточных испытаний.

Поставка (поставщик снабжает заказчика прогр. продуктом или услугой)

Инициирование. Ответ на заявочные предложения. Подготовка договора. Планирование исполнения. Поставка.

Техническое задание. Решение руководства об участии в разработке. План управления проектом. Разработанная ИС и документация.

Решение об участии в разработке. Коммерческие предложения/ конкурсная заявка. Договор на поставку/ разработку. План управления проектом. Реализация/ корректировка. Акт приемо-сдаточных испытаний.

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

Подготовка. Анализ требований ТЗ. Проектирование архитектуры. Разработка требований к ПО. Проектирование архитектуры ПО. Детальное проектирование ПО. Кодирование и тестирование ПО. Интеграция ПО и квалификационное тестирование ПО. Интеграция ИС и квалификационное тестирование ИС.

Техническое задание на ИС. Модель ЖЦ. Подсистемы ИС. Спецификации требования к компонентам ПО. Архитектура ПО. Материалы детального проектирования ПО. План интеграции ПО, тесты. Архитектура ИС, ПО, документация на ИС, тесты.

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

В соответствии с ИСО 12207 основные процессы так же:

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

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

Вспомогательные процессы жизненного цикла ИС:

Документирование (формализованное описание информации, созданной в течение ЖЦ ИС)

Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ИС для определения состояния компонентов ИС, управления ее модификациями).

Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)

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

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

Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

Аудит (определение соответствия требованиям, планам и условиям договора)

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

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

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

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

Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

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

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

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

3. Подготовка и корректировка договора.

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

5. Приемка и завершение работ.

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

1. Формирование требований к системе.

2. Формирование списка программных продуктов.

3. Установление условий и соглашений.

4. Описание технических ограничений (среда функционирования системы и т. д.).

8. Этапы (стадии) жизненного цикла АИС

Модель ЖЦ ИС включает в себя:

1. Стадии.

2. Результаты выполнения работ на каждой стадии.

3. Ключевые события - точки завершения работ и принятия решений.

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

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

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

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

1. Предпроектное обследование (анализ):

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

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

2. Проектирование:

2.1 предварительное проектирование:

- выбор проектных решений по аспектам разработки ИС;

- описание реальных компонент ИС;

- оформление и утверждение технического проекта (ТП).

2.2 детальное проектирование:

- выбор или разработка математических методов или алгоритмов программ;

- корректировка структур БД;

- создание документации на доставку и установку программных продуктов;

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

2.3 разработка техно-рабочего проекта ИС (ТРП).

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

3. Разработка ИС:

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

- тестирование и доводка программного комплекса;

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

4. Ввод ИС в эксплуатацию:

- ввод технических средств;

- ввод программных средств;

- обучение и сертификация персонала;

- опытная эксплуатация;

- сдача и подписание актов приемки-сдачи работ.

5. Эксплуатация ИС:

- повседневная эксплуатация;

- общее сопровождение всего проекта.

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

9. Описание предметной области АИС моделью «Как есть»

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

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

Модели «AS-IS» («как есть») отражают существующее на момент обследования положение дел в организации и позволяющие понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации.

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

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

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

Моделирование проблемной области БП выполняется в два под-этапа:

  1.  определяется объективная структура новой организации БП: состав объектов, функций и событий;
  2.  объекты и функции БП распределяются по структурным подразделениям предприятия, и определяют требования к ИС.

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

сравнение средних значений и дисперсий динамических характеристик различных альтернатив процессов при одинаковых исходных данных (один сценарий моделирования – несколько моделей);

отыскание оптимальных значений переменных на множестве возможных значений (несколько сценариев моделирования – одна модель);

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

10. Информационное обеспечение АИС и информационные модели «Как должно быть»

Стадия проектирования (синтеза), или прямого инжиниринга, выражается в создании модели «Как должно быть», или информационной модели. Модели «AS-TO-BE» («как должно быть»), отражают представление о новых процессах и технологиях работы организации. Моделирование «Как должно быть» позволяет определить, какой должна быть система до начала её разработки. Методика разработки информационной модели предполагает моделирование нового варианта организации информационной системы предметной области («КАК ДОЛЖНО БЫТЬ»), а именно:

  1.  полного состава информации, необходимой для решения задач АИС;
  2.  отражение этой информации на всех типах носителей;
  3.  отражение процесса преобразования информации, начиная от получения первичной переменной и условно-постоянной информации, загрузки ее в файлы и заканчивая получением файлов с результатной информацией и выдачей ее пользователю;
  4.  состава исходных первичных документов и распределение их по задачам;
  5.  источники и способы получения первичной информации;
  6.  состав файлов с первичной, условно-постоянной, промежуточной и результатной информацией;
  7.  информационную потребность для каждой задачи комплекса;
  8.  способы выдачи результатной информации;
  9.  состава результатных документов для каждой задачи, реализуемых на рассматриваемом АРМе;
  10.  адресатов выдачи и получения результатной информации;
  11.  взаимосвязей входных, промежуточных и результатных информационных потоков и задач, реализуемых на данном АРМе (структурно - функциональной диаграмма или диаграмма потоков данных).

Переход от модели «AS-IS» к модели «AS-TO-BE» может выполняться двумя способами: совершенствованием существующих технологий на основе оценки их эффективности и радикальным изменением технологий и перепроектированием (реинжинирингом) бизнес-процессов.

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

Структурное моделирование включает:

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

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

Информационная модель строится в двух формах:

  1.  схема данных;
  2.  структурно – функциональная модель или диаграмма потоков данных по методологии Гейна / Сарсона, Йодана / ДеМарко. Для ее разработки целесообразно использовать CASE - средства, например Design/IDEF, Power Designer, BPwin, Silverrun-BMP, Oracle Designer, ARIS и др.

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

11. Управление требованиями на стадиях детального проектирования, разработки, внедрения и сопровождения ИС

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

Рис.7. Виды требований к ИС

На иллюстрации обозначены:

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы.

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система.

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

Системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие эподсистемы, то есть система.

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы.

Спецификации требований к ПО (software requirements specification, SRS) документируют функциональные требования, где описывается так полно, как необходимо, ожидаемое поведение системы.

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

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

Требования к внешнему интерфейсу определяют правила внешних взаимодействий между системой и внешним миром.

Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.

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

Рис.8. Порядок спецификации требований

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

К действиям по разработке (извлечению, документированию, анализу, утверждению, проверке) требований относятся:

идентификация классов пользователей для данного продукта;

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

определение задач и целей пользователей, а также бизнес-целей, с которыми эти задачи связаны;

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

распределение высокоуровневых требований по компонентам ПС, определенным в системной архитектуре;

установление относительной важности атрибутов качества;

установление приоритетов реализации;

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

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

К действиям по управлению требованиями относятся:

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

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

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

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

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

отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;

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

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

a) учет потребностей заказчика;

b) соответствие потребностям заказчика;

c) тестируемость;

d) выполнимость проектирования системной архитектуры;

e) возможность эксплуатации и сопровождения.

12. Анализ предметной области АИС

Анализ - определение того, что должна делать система, стадия жизненного цикла.

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

Анализ предполагает изучение: макроокружения, конкурентной среды; внутренней среды организации, взаимодействия и соответствия «объект управления - система управления». К анализу предметной области при разработке АИС относятся:

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

постановка задачи (цель и назначение автоматизированного варианта решения задачи, общая характеристика организации решения задачи на ЭВМ, формализация расчетов);

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

обоснование проектных решений по видам обеспечения (по техническому обеспечению (ТО), по информационному обеспечению (ИО), по программному обеспечению (ПО)).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для выполнения структурно-функционального анализа объекта управления и решаемой задачи рекомендуется разработать структурно-функциональную диаграмму («КАК ЕСТЬ») по методологии SADT(IDEF0) или диаграмму потоков данных по методологии Гейна / Сарсона, Йодана / ДеМарко. Для их разработки целесообразно использовать CASE - средства, например Design/IDEF, Power Designer, BPwin, Silverrun-BMP, Oracle Designer и др.

Далее следует сделать акцент на те недостатки, устранение которых предполагается осуществить, например:

  1.  наличие опозданий в поставках сырья и материалов;
  2.  наличие выплат штрафных санкций и неустоек;
  3.  простои оборудования;
  4.  низкая производительность труда в производственной сфере;
  5.  невозможность расчета показателей, необходимых для управления объектом из-за сложности вычислений или большого объема информации;
  6.  высокая трудоемкость обработки информации (привести объемно-временные параметры);
  7.  низкая оперативность, снижающая качество управления объектом;
  8.  невысокая достоверность результатов решения задачи из-за дублирования потоков информации;
  9.  несовершенство организации сбора и регистрации исходной информации;
  10.  несовершенство процессов сбора, передачи, обработки, хранения, защиты целостности и секретности информации и процессов выдачи результатов расчетов конечному пользователю и т.д.

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

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

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

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

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

13. Выбор проектных решений АИС и его обоснование

Организация решения задачи на ЭВМ предполагает раскрытие требований к будущему проекту:

  1.  к архитектуре аппаратной платформы (например, использование архитектуры файл-сервер или клиент- сервер с указанием распределения функций, организация работы сайта в сети Internet);
  2.  к изменениям в функциях подразделения, связанных со сбором, обработкой и выдачей информации;
  3.  к источникам поступления оперативной и условно-постоянной информации и периодичность ее поступления;
  4.  к этапам решения задачи, последовательность и временной регламент их выполнения, выявленные на основе рассмотренной в п.1.2. декомпозиции задачи (при этом следует рассмотреть целесообразность автоматизации этапов и операций решения задачи, оценивая возможность формализации связей между ними);
  5.  к порядку ввода первичной информации (названия документов) и перечень используемых экранных форм;
  6.  к характеристике результатов (названия результатных документов, экранных форм выдачи результатов, перечень результатных файлов, способов их выдачи: на экран, печать или в канал связи) и мест их использования;
  7.  к характеристике системы ведения файлов в базе данных (перечень файлов или таблиц с условно-постоянной и оперативной информацией, периодичность обновления, требования защиты целостности и секретности);
  8.  к режиму решения задачи (пакетный, диалоговый, с использованием методов телеобработки или смешанный);
  9.  к периодичности решения задачи.

Формализация решения задачи сводится к рассмотрению последовательности проведения расчетов, а также выделению алгоритмов расчета экономических показателей на каждом этапе, перечисленных в разделе «Экономическая сущность задачи». Позже на этот пункт необходимо будет сделать ссылку из пункта проектной части (характеристика результатной информации). Для достижения большей степени формализации описания задачи дипломник может, например, использовать группировку всех показателей в две таблицы: формализованного описания входных и результатных показателей (табл.4,5).

Таблица 4. Формализованное описание входных показателей

Наименование входного показателя

Идентификатор входного показателя

1

Количество поступившего i–го материала от j-го поставщика на дату -d

Кijd

Таблица 5. Формализованное описание результатных показателей

№№

Наименование результатного показателя

Идентификатор результатного показателя

Алгоритм расчета

1

Кол-во поступления i-го матер. от j-го поставщ. с начала месяца r

Kijr

Kijr =

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

Обзор рынка программных средств удобно проводить с помощью Internet. Адреса используемых при обзоре ресурсов следует добавить в список литературы дипломной работы.

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

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

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

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

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

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

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

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

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

При обосновании выбора общего ПО целесообразно:

  1.  дать классификацию ОС, указать факторы, влияющие на выбор конкретного класса и его версии, и обосновать выбор операционной системы;
  2.  дать классификацию, привести факторы и обосновать выбор используемой СУБД.

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

Кроме того, стоит выработать требования к оформлению экранных и печатных форм, эргономике программного обеспечения.

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

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

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

14. Проектирование системной архитектуры и анализ требований к ПО

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

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

Общая характеристика системной архитектуры проектируемого программного средства (архитектуры верхнего уровня) – это описание объектов технических и программных средств и ручных операций.

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

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

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

a) учет требований к системе;

b) соответствие требованиям к системе;

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

d) возможность программных объектов архитектуры выполнять установленные для них требования;

e) возможности эксплуатации и сопровождения.

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

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

Разработчик должен установить и документально оформить следующие требования к программным средствам, включая технические требования к характеристикам качества (рекомендации по определению характеристик качества приведены в ГОСТ Р ИСО/МЭК 9126):

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

b) требования к внешним интерфейсам программного объекта архитектуры;

c) квалификационные требования;

d) требования безопасности, включая требования, относящиеся к методам эксплуатации и сопровождения, воздействию окружающей среды и травмобезопасности персонала;

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

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

g) требования к определению данных и базе данных;

h) требования по вводу в действие и приемке поставляемого программного продукта на объекте(ах) эксплуатации и сопровождения;

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

j) требования к эксплуатации объекта пользователем;

k) требования к обслуживанию пользователя.

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

a) учет требований к системе и проекту системы;

b) внешняя согласованность с требованиями к системе;

c) внутренняя согласованность требований к объектам между собой;

d) тестируемость требований;

е) выполнимость программного проекта;

f) возможность эксплуатации и сопровождения.

15. Проектирование программной архитектуры и техническое проектирование программных средств

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

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

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

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

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

Разработчик должен разработать и документально оформить общий (эскизный) проект внешних интерфейсов программного объекта и интерфейсов между компонентами объекта.

Разработчик должен разработать и документально оформить общий (эскизный) проект базы данных.

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

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

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

a) учет требований к программному объекту;

b) внешняя согласованность с требованиями к программному объекту;

c) внутренняя согласованность между компонентами программного объекта;

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

e) возможность технического проектирования;

f) возможность эксплуатации и сопровождения.

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

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

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

Техническое проектирование программных средств – это описание программных модулей и файлов.

Если проектирование ведется с помощью языков четвертого поколения, например генераторов экранных форм, отчетов, то эту схему следует преобразовать в схему настройки, отражающей виды и состав используемых объектов проектирования по каждому виду, применяемых в этих средствах: «Формы», «Отчеты», «Запросы» и «Кнопочная форма».

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

Разработчик должен разработать технический проект для каждого компонента программного объекта. Компоненты программного объекта должны быть уточнены на уровне программных модулей, которые можно программировать (кодировать), компилировать и тестировать независимо. Должно быть обеспечено распределение технических требований к компонентам программного объекта между программными модулями. Технический проект должен быть документально оформлен.

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

Разработчик должен разработать и документально оформить технический проект базы данных.

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

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

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

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

a) учет требований к программному объекту;

b) внешнее соответствие спроектированной архитектуре;

c) внутренняя согласованность между компонентами программного объекта и программными модулями;

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

e) возможность тестирования;

f) возможность эксплуатации и сопровождения.

16. Кодирование

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

Разработчик должен разработать и документально оформить следующие продукты:

a) каждый программный модуль и базу данных;

b) процедуры испытаний (тестирования) и данные для тестирования каждого программного модуля и базы данных.

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

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

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

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

a) учет требований к программному объекту и проекту объекта в целом;

b) внешнее соответствие требованиям и проекту программного объекта;

c) внутреннее соответствие между требованиями к программным модулям;

d) тестовое покрытие всех модулей;

e) соответствие методов программирования и используемых для них стандартов;

f) возможность сборки и тестирования;

g) возможность эксплуатации и сопровождения.

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

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

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

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

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

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

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

a) учет требований к системе;

b) внешнее соответствие требованиям к системе;

c) внутренняя согласованность между программными объектами;

d) тестовое покрытие требований к программному объекту;

e) соответствие используемых испытательных стандартов и методов испытаний;

f) соответствие ожидаемым результатам;

g) выполнимость квалификационного испытания программного объекта;

h) возможность эксплуатации и сопровождения.

Разработчик должен проводить совместный анализ.

17. Тестирование

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

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

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

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

a) тестовое покрытие требований к программному объекту;

b) соответствие ожидаемым результатам;

c) возможность сборки и тестирования системы (при их проведении);

d) возможность эксплуатации и сопровождения.

Разработчик должен:

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

b) определить состояние конфигурации (базовую линию) проекта и программ данного программного объекта.

Примечание - Квалификационное испытание может быть выполнено в процессах верификации (подраздел 6.4) или аттестации.

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

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

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

Собранная система должна быть оценена по следующим критериям (при этом результаты оценок должны быть документально оформлены):

a) тестовое покрытие требований к системе;

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

c) соответствие ожидаемым результатам;

d) выполнимость квалификационных испытаний системы;

e) возможность эксплуатации и сопровождения.

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

Система должна быть оценена по следующим критериям (при этом результаты оценок должны быть документально оформлены):

a) тестовое покрытие требований к системе;

b) соответствие ожидаемым результатам;

c) возможность эксплуатации и сопровождения.

Разработчик должен обеспечить проведение аудиторской проверки(ок). Результаты аудиторской проверки(ок) должны быть документально оформлены.

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

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

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

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

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

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

18. Установка и сопровождение

Ввод в действие программных средств состоит из следующих задач.

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

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

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

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

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

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

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

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

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

1) подготовка процесса;

2) анализ проблем и изменений;

3) внесение изменений;

4) проверка и приемка при сопровождении;

5) перенос;

6) снятие с эксплуатации.

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

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

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

Этапы проекта в соответствии с каскадной моделью:

1.Формирование требований

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

3.Реализация

4.Тестирование

5.Ввод в действие

6.Эксплуатация и сопровождение

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

Каскадная модель (waterfall model) жизненного цикла (рис.9) считается основой технологических подходов к ведению жизненного цикла. Эта модель была предложена в 1970 году У. Ройсом. Впоследствии данная модель была регламентирована множеством нормативных документов, в частности, широко известным стандартом Министерства обороны США Dod-STD-2167A и российскими стандартами серии ГОСТ 34. Принципиальными свойствами так называемой «чистой» каскадной модели являются следующее:

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

 

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

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

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

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

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

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

Рис.10. Модель реального процесса разработки системы.

Основными недостатками каскадного подхода являются:

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

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

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

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

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ИС создается в несколько итераций (витков спирали) методом прототипирования (рис.11).

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

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

На каждой итерации оцениваются:

Риск превышения сроков и стоимости проекта

Необходимость выполнения еще одной итерации

Степень полноты и точности понимания требований к системе

Целесообразность прекращения проекта.

Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод быстрой разработки приложений).

Принципиальные особенности спиральной модели:

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

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

идентификация и анализ риска на каждой итерации;

использование каскадной модели для реализации окончательного прототипа;

оценка результатов по завершении каждой итерации и планирование следующей итерации.

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

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

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

Достоинствами спиральной модели являются:

  1.  ускорение разработки (раннее получение результата за счет прототипирования);
  2.  постоянное участие заказчика в процессе разработки;
  3.  разбиение большого объема работы на небольшие части;
  4.  снижение риска (повышение вероятности предсказуемого поведения системы).

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

К недостаткам спиральной модели можно отнести:

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

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

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

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

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

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

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

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

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

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

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

Для информационной системы строится 2 вида моделей:

модели «AS-IS» («как есть»), отражающие существующее на момент обследования положение дел в организации и позволяющие понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;

модели «AS-TO-BE» («как должно быть»), отражающие представление о новых процессах и технологиях работы организации.

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

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

Информационная модель отражает отношения между элементами системы в виде структур данных (состав и взаимосвязи).

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

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

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

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

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

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

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

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

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

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

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

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

нотацию (систему обозначений) - визуальное представление элементов моделирования;

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

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

Наиболее важное значение имеет знакомство с нотациями IDEF0, IDEF3, EPC, DFD, ERD так как они являются наиболее распространенными визуальными моделями:

IDEF0 - функциональная модель SADT (Structured Analysis and Design Technique); IDEF0 – нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. Она была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий, получила чрезвычайно широкое распространение и является, в частности, стандартом в НАТО и МВФ.

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

Нотация ARIS eEPC расшифровывается следующим образом: extended Event Driven Process Chain — расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером.

DFD (Data Flow Diagrams) - диаграммы потоков данных. Нотация DFD предназначена для описания информационных потоков в обследуемой организации.

Модель «сущность - связь» (ERD — Entity-Relationship Diagram) описывает отношения между данными.

23. Графическая нотация и метод проектирования IDEF0

Таблица 6. Объекты нотации IDEF0

Наименование

Описание

Графическое представление

Нотация IDEF0

1

Работа (Activity)

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

2

Стрелка входа

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

3

Стрелка выхода

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

4

Стрелка управления

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

5

Стрелка механизма

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

6

Стрелка вызова

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

Рис.12. Внешний вид модели IDEF0

(1) Все “Работы” принадлежат одному классу, т.е. обладают одинаковым набором свойств и поведением. Этот важный и часто нарушаемый принцип отдельно обсудим ниже.

(2) Все связи между “Работами” относятся к классу “Ресурс”. Например, электронное издание “Налогового кодекса РФ” является общедоступным информационным ресурсом.

(3) Для однозначной “привязки” ресурсов к трем возможным входам БП на множестве “Ресурсов” вводится следующая классификация.

1. Признак изменчивости “Ресурса” при исполнении “Работы”. 

1.1. “Ресурсы”, подлежащие трансформации в другие виды “Ресурсов”. 

1.2. Нетрансформируемые “Ресурсы”.

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

1.2.2. Изнашиваемые (устаревающие) “Ресурсы”. Например, вспомогательные инструменты, персонал.

2. Признак блокировки “Ресурса” “Работой”, исключающий возможность использования “Ресурса” другими “Работами”

2.1. “Ресурсы”, которые не могут блокироваться “Работами” (“Ресурсы” общего пользования)

2.2. Блокируемые “Ресурсы”

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

24. Графическая нотация и метод проектирования IDEF3

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

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

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

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

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

Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..."

Два типа диаграмм в IDEF3

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.

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

Рис.13. Пример PFDD диаграммы

На рис.13 изображена диаграмма PFDD, являющаяся графическим отображением сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса. Линии бывают следующих видов:

- Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз.

- Отношения (Relational Link)- пунктирная линия, использующаяся для изображения связей между UOB

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

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице.

Таблица 7. Перекрестки модели IDEF3.

Обозначение

Наименование

Смысл в случае слияния стрелок
(Fan-in Junction)

Смысл в случае разветвления стрелок (Fan-out Junction)

Asynchronous AND

Все предшествующие процессы должны быть завершены

Все следующие процессы должны быть запущены

Synchronous AND

Все предшествующие процессы завершены одновременно

Все следующие процессы запускаются одновременно

Asynchronous OR

Один или несколько предшествующих процессов должны быть завершены

Один или несколько следующих процессов должны быть запущены

Synchronous OR

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

Один или несколько следующих процессов запускаются одновременно

XOR (Exclusive OR)

Только один предшествующий процесс завершен

Только один следующий процесс
запускается

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J".

Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

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

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB "Окрасить Деталь", представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 1, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

Рис.14. Пример OSTN диаграммы

Если диаграммы PFDD технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис.14 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

23. Методика построения DFD-диаграмм

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

Таблица 8. Объекты нотации DFD

Наиме-нование

Описание

Графичес- кое пред-ставление

1

Работа (Activity)

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

  1.  "Ввести сведения о клиентах";
  2.  "Выдать информацию о текущих расходах";
  3.  "Проверить кредитоспособность клиента".

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

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

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

2

Объект ссылки

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

3

Хранилище данных

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

4

Стрелка

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

Рис.15. Пример описания документооборота в нотации DFD

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

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

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

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

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

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

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

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

  1.  правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
  2.  правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

  1.  наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
  2.  возможности описания преобразования данных процессом в виде последовательного алгоритма;
  3.  выполнения процессом единственной логической функции преобразования входной информации в выходную;
  4.  возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

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

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

24. Графическая нотация EPC

Нотация ARIS eEPC расшифровывается следующим образом: extended Event Driven Process Chain — расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В следующей таблице приводятся основные используемые в рамках нотации объекты.

Таблица 9. Объекты нотации eEPC

Наименование

Описание

Графическое представление

1

Функция

Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия

2

Событие

Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций

3

Организационная единица

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

4

Документ

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

5

Прикладная система

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

6

Кластер информации

Объект характеризует данные как набор сущностей и связей между ними. Используется для создания моделей данных

7

Стрелка связи между объектами

Объект описывает тип отношений между другими объектами, например активацию выполнения функции некоторым событием

8

Логическое «И»

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

9

Логическое «ИЛИ»

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

10

Логическое исключающее «ИЛИ»

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

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

Рис.16. Пример модели в нотации eEPC

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

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

Рис.17. Пример применения объектов ARIS для описания бизнес-процессов

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

Бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения.

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).

25. Нотация ARIS Organizational Chart 

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

Рис.18. Модель организационной структуры предприятия

Модель строится из объектов «Organizational unit», «Position», «Internal person» и др. Заложенные в нотацию виды связей позволяют отразить различные виды отношений между объектами организационной структуры. В представленном на рис. 5 примере «Предприятие» управляется «Директором», при этом используется тип связи «is Organization Manager for». Иерархия подразделений строится при помощи связей типа «is composed of». Кроме того, могут быть указаны должности — «Position» и фамилии реальных сотрудников, их занимающих: «Internal person», а также тип связи «occupies».

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

26. Нотация ARIS Information Flow 

Нотация Information Flow является аналогом нотации DFD (см. ниже) и используется при построении схем потоков данных или документов между функциями бизнес-процессов предприятия:

Рис.19. Фрагмент диаграммы ARIS Information Flow

Простота нотации ограничивает области ее полезного применения. Основными объектами нотации являются «Function» (используется также при построении моделей бизнес-процессов) и «Information Flow» — информационный поток.

Рис.20. Нотация ARIS Information Flow

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

27. Сравнительный анализ ARIS IDEF0 и IDEF3

Таблица 10. Объекты нотаций ARIS, IDEF0 и IDEF3

Критерии сравнения

ARIS

IDEF0

IDEF3

1

Принцип построения диаграммы/логика процесса

Временная последовательность выполнения процедур

Принцип доминирования (см. стандарт IDEF0)

Временная последовательность выполнения процедур

2

Описание процедуры процесса

Объект на диаграмме

Объект на диаграмме

Объект на диаграмме

3

Входящий документ

Используется отдельный объект для описания («документ»)

Стрелка входа, стрелка управления

Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)

4

Входящая информация

Используется отдельный объект для описания («кластер», «технический термин»)

Стрелка входа, стрелка управления

Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)

5

Исходящий документ

Используется отдельный объект для описания («документ»)

Стрелка выхода

Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)

6

Исходящая информация

Используется отдельный объект для описания («кластер», «технический термин»)

Стрелка выхода

Используется отдельный объект для описания (Объект ссылки типа Object или стрелка Object flow)

7

Исполнитель процедуры

Используется отдельный объект для описания («позиция», «организационная единица»)

Стрелка механизма

Нет (может быть отражен в модели только привязкой объекта ссылки)

8

Используемое оборудование

Используется отдельный объект для описания

Стрелка механизма

Нет (может быть отражен в модели только привязкой объекта ссылки)

9

Управление процедурой

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

Стрелка управления

Только временная последовательность выполнения процедур и логика процесса

10

Контроль выполнения процедуры

Нет. Может быть отражен указанием входящих документов

Стрелка управления

Нет (может быть отражен в модели только привязкой объекта ссылки).

11

Обратная связь по управлению/контролю

Нет. Может быть отражена только символами логики (последовательность выполнения процедур)

Стрелка управления

Нет

12

Обратная связь по входу

Нет. Может быть отражена только символами логики (последовательность выполнения процедур)

Стрелка входа

Нет

28. Метод проектирования 1С:Профкейс

Разработка проекта информационной системы на платформе 1С:Предприятие сводится к заполнения специализированного опросника 1С:Профкейс ST-411-T на основе спецификации бизнес-сценария обследования предприятия, заполнив который можно описать все факты, необходимые для проектирования бизнес-процесса, выявить проблемы и подводные камни на этапе проектирования, выработать единую точку зрения между ИТ-специалистом и заказчиком. Проектирование сводится к заполнению опросника, состоящего из 8 разделов. Каждый раздел снабжен поясняющим комментарием и примером заполнения:

1. Бизнес-процесс. Строится графическая модель обследования предприятия "Как есть" в стандарте IDEF0, либо диаграмма Ариса eEPC "Как есть" а также в текстовом виде кратко описываются цели и содержание автоматизируемого бизнес-процесса.

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

3. Причины, цели и риски автоматизации.

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

5. Описание условий и объектов маршрутизации.

6. Отчетность. В этом разделе описывается отчетность о ходе выполнения как отдельных экземпляров так и всех бизнес-процессов данного вида.

7. Нерешенные вопросы. Фиксируются нерешенные на момент проектирования вопросы, которые могут повлиять на автоматизацию рассматриваемого бизнес-процесса.

8. Глоссарий. В этой секции описываются термины, сокращения и аббревиатуры, используемые при заполнении опросника.

29. Понятие технологии проектирования

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

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

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

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

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

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

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

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

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

30. Технология проектирования информационного обеспечения АИС

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

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

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

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

Характеристика базы данных представляет собой построение инфологической и даталогической модели.

Характеристика инфологической модели БД представляет собой анализ состава и структуры первичных и результатных документов, определение состава данных, их нормализация и выявление состава и типов информационных сущностей, отражение их взаимосвязей в виде диаграммы «сущность-связь» (ER – модели), возможно выполненное на основе уже разработанной структурно-функциональной диаграммы или диаграммы потоков данных.

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

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

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

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

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

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

Если информационная база организована в форме корпоративной базы данных, то приводится описание и других её элементов: распределение прав доступа, бизнес-правил, триггеров.

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

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

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

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

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

31. Технологии проектирования программного обеспечения АИС (структурный и объектно-ориентированный подходы).

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

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

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

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

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

- принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

1. В виде декомпозиции небольших подсистем, каждую из которых можно разрабатывать независимо от других, в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами SADT (Structured Analysis and Design Technique) модели и соответствующими функциональными диаграммами.

2. DFD (Data Flow Diagrams) диаграмма потоков данных позволяет достигнуть и проиллюстрировать, что количество связей между отдельными подсистемами минимизировано (принцип «слабой связанности» (Low Coupling), а связность отдельных частей внутри каждой подсистемы максимальна (принцип «сильного сцепления» (High Cohesion).

3. Каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами. Выделение интерфейсов позволяет строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство. Структура системы должна быть такой, чтобы взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки, показываемые на ERD (Entity-Relationship Diagrams) диаграмме "сущность-связь".

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

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

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

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

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

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

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

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

Нотация рациональных унифицированных процессов (RUP) фирмы IBM охватывает объектно-ориентированную разработку программного обеспечения, начиная с анализа и заканчивая внедрением продукта. Основные принципы RUP:

1. Управляемая итеративная разработка (CID). RUP предоставляет структурированный подход к итерационной разработке программного обеспечения, подразделяя процесс на четыре фазы (milestones): Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание).

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

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

4. Принцип визуального моделирования. В RUP используются следующие виды моделей UML: Проектная модель (Design model), модель процессов (Process model), модель размещения (Deployment model).

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

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

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

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

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

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

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

Диаграммы классов - это набор статических, декларативных элементов модели, таких как классы, интерфейсы и их отношения. Диаграммы могут организовываться в модули (packages), в котором они логически собраны.

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

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

32. САSЕ-средства, их функциональные возможности и характеристика 

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

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

ERwin - средство концептуального моделирования БД, позволяющее создавать и воссоздавать модель данных. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений.

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

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

ARIS является одним из наиболее продвинутых и полнофункциональных инструментов для интегрированного описания деятельности организаций, моделирования и анализа бизнес-процессов и их окружения. В ARIS применяются ранее рассмотренные нотации Вильяма Шера: организационная схема (Organizational chart), событийная цепочка процесса (Extended event driven process chain-eEPC), информационный поток (Information Flow).

Microsoft Visio - решение для создания диаграмм и наглядного представления данных, которое позволяет строить диаграммы во всех вышеперечисленных нотациях.

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

Среди всех стандартов в области разработки и применения информационных технологий, используемых в настоящее время в мире, наиболее популярными моделями являются: ISO 9000, TickIT, SEI SW-CMM.

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

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

Стандарт TickIT – национальный (британский), получил достаточно широкую известность. Это отраслевой стандарт, который регламентирует требования к системе качества для организаций разработчиков программного обеспечения и базируется на модели ISO 9001:94. В отличие от модели ISO 9001, которая регламентирует "что необходимо сделать", разработчики данного стандарта попытались ответить на вопрос "как" можно выполнить требования, определенные в ISO 9001. TickIT объединяет в себе модель ISO 9001 с набором рекомендательных стандартов ISO 12207 и ISO 9000-3.

Стандарты SEI SW-CMM (Capability Maturity Model - модель зрелости процессов создания ПО) содержат очень интересный подход к улучшению внутренних процессов разработки программного обеспечения, который определен в модели СММ. В основу модели SEI SW-CMM (также как и в основу стандартов ISO серии 9000) положена теория TQM (Total Quality Management - философия всеобщего управления качеством, или концепция всеобщего качества). Теория TQM основывается на постепенном улучшении внутренних производственных процессов за счет множества небольших внедряемых в компании улучшений. Однако модели ISO и CMM несколько различаются в своих подходах к построению самосовершенствующихся систем управления качеством и улучшению производственных процессов.

В отличие от модели ISO, где для того, чтобы соответствовать требованиям, необходимо продемонстрировать 100%-ное соответствие модели (и только оно позволяет компании самосовершенствоваться), в модели SEI SW-CMM предусмотрен поэтапный подход к построению системы совершенствования процессов. Для достижения этой цели разработчики стандарта СММ определили пять уровней, которые должна пройти организация для того, чтобы достичь основной цели - повышения эффективности функционирования процессов компании и, как следствие, улучшения качества результатов производственных процессов и разрабатываемого программного обеспечения.

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

176 комитет ISO разработал рекомендательный стандарт ISO 10006 "Менеджмент качества. Руководство качеством при управлении проектами", который определяет основные подходы к управлению проектами и определяет его место в модели обеспечения качеством. Авторы стандартов ISO серии 9000 определяют процесс управления проектами как часть системы менеджмента качества. С другой стороны, возможен и противоположный взгляд (которого придерживаются оппоненты стандартов ISO серии 9000), согласно которому менеджмент качества является одной из составной частей системы управления проектами.

Управление проектами является скелетом производства в организациях разработчиков программного обеспечения. Поэтому неудивительно, что для приведения в соответствие системы управления качеством производства к требованиям модели ISO 9001 и к требованиям модели улучшения процессов производства SEI SW-CMM использование стандартов и признанных в мире технологий по управлению проектами является краеугольным камнем развития внутренних технологий в IT-компаниях.

34. Организация труда при разработке АИС

Служба Microsoft Consulting Services провела анализ результатов выполнения большого количества программных проектов. Оказалось, что только 24% проектов можно признать в той или иной степени успешными, 26% не были завершены, а остальные столкнулись с большими проблемами, например, бюджет был превышен вдвое или затрачено в 1,5 раза больше времени. Основными причинами неудач были признаны следующие:

- постоянное изменение требований;

- нечеткие или неполные спецификации;

- низкое качество кода;

- слишком широкая постановка задачи;

- ошибка в подборе кадров;

- плохая организация работы;

- нечетко сформулированные цели.

Для преодоления этих трудностей был предложен набор моделей Мicrosoft Solution Framework (MSF), в котором учтен опыт, накопленный группами разработки программных продуктов.

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

Формирование коллектива – сложная задача, которая должна решаться с помощью психологов. Вот некоторые основные положения:

- не должно быть команды из одних лидеров;

- не должно быть команды из одних исполнителей;

- в случае неудачи команда расформировывается;

- система штрафов (если проект проваливается – наказывают всех).

Рис.21. Модель команды разработчиков MSF

Этот "бублик" описывает только роли, за ними могут скрываться несколько человек, исполняющих каждую роль. Самое удивительное, что в этой модели не предусмотрено единоначалия – все роли важны, все роли равноправны, поэтому MSF называют моделью равных (team of peers).

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

Product management – управление продуктом. Исполнители этой роли отвечают за общение с заказчиком, написание спецификации, разъяснение задач разработчикам.

Development – наиболее традиционная роль – разработка и начальное тестирование продукта.

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

Logistic management – установка, сопровождение и техническая поддержка продукта, а также материально-техническое обеспечение работы коллектива.

Testing – тестирование. Выявление и устранение недоработок, исправление ошибок, другие функции QA.

Все решения принимаются коллективно, разделяется и ответственность в случае провала проекта.

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

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

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

Экономические стандарты для IT отражают видение информационных процессов и объектов с точки зрения управления бизнесом.

Управление инвестициями в информационные технологии описано в стандарте ISO 15288.

Определение информационных критериев потребностей бизнеса с учетом вышеперечисленных мировых стандартов и инструкций ITSEC, TCSEC, SPICE, SOCO, IFAC, IIA, AICPA, GAO, PCIE, ISACA, производственных и промышленных форумов описано в стандарте COBIT (лат.).

Модель ИТ - подразделения как совокупности служб, решающих конкретные задачи бизнеса, описана в стандарте ITIL/ITSM.

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

План развития информационных т ехнологий помогают реализовать: стандартный метод инвестиционного анализа (CBA, Cost Benefit Analysis), метод сбалансированных счетных карт (BSC, Balance Score Card), оценки совокупной ценности (TVO, Total Value of Opportunity) и совокупной стоимости владения (TCO, Total Coast of Owership).

36. Технология групповой разработки АИС

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

Определение

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

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

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

Разработка

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

Тестирование

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

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

Развертывание

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

Управление

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

Члены группы разработки - аналитики, разработчики, тестировщики и руководители проекта разработки приложения.

В современных технологиях используются специальные инструментальные средства, позволяющие фиксировать каждое изменение и откатываться к нужной точке, например, Visual Source Safe или PVCS. Обычно такие системы версионирования устанавливаются на сервере, разработчики играют роль клиентов (тем самым автоматически решаются технические проблемы, например, разрешение конфликтов при одновременном обращении, вопросы back-up и др.), а система предоставляет следующие методы:

Check-out: взять текст на исправление;

Check-in: вернуть обратно;

Undo check-in: отмена всех изменений, сделанных во время последней сессии;

Get latest version: берется один файл или файлы целого проекта в том состоянии, в котором их застал последний check-in.

Последняя версия обычно хранится отдельно.

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

37. Автоматизация управления групповой разработкой проектов АИС на примере 1С:Предприятия

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

Рис.22. Принципы автоматизации групповой разработки

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

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

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

При групповой разработке прикладное решение рассматривается как набор объектов, закрытых для изменения. Каждый из пользователей, допущенных к работе с хранилищем, может "захватить" для изменения произвольное число объектов, не захваченных другими пользователями. Каждый объект может быть захвачен только одним пользователем (рис.23):

Рис.23. Окно хранилища конфигурации

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

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

38. Классификация АИС по признаку структурированности задач

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

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

Различают три типа задач, для которых создаются информационные системы:

  1.  структурированные (формализуемые);
  2.  неструктурированные (не формализуемые);
  3.  частично структурированные.

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

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

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

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

Рис. Классификация АИС по структурированности задач

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

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

39. Классификация АИС по виду деятельности

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

Функциональные подсистемы ЭИС могут строиться по различным принципам:

  1.  предметному;
  2.  функциональному;
  3.  проблемному;
  4.  смешанному (предметно-функциональному).

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

  1.  управление сбытом готовой продукции;
  2.  управление производством;
  3.  управление материально-техническим снабжением;
  4.  управление финансами;
  5.  управление персоналом.

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

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

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

Маркетинговая деятельность включает в себя:

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

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

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

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

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

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

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

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

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

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

Таблица 11. Классификация АИС по уровням управления.

Уровни управления

Информационные подсистемы

Сбыт

Производство

Снабжение

Финансы

Стратегический уровень

Новые продукты и услуги.

Исследования и разработки

Производственные мощности.

Выбор технологий технологии

Материальные источники.

Товарный прогноз

Финансовые источники.

Выбор модели уплаты налогов

Тактический уровень

Анализ и планирование объемов сбыта

Анализ и планирование производственных программ

Анализ и планирование объемов закупок

Анализ и планирование денежных потоков

Оперативный уровень

Обработка заказов клиентов

Выписка счетов и накладных

Обработка производственных заказов

Складские операции.

Заказы на закупку

Ведение бухгалтерских книг

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

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

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

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

  1.  сравнение текущих показателей с архивными данными;
  2.  составление периодических отчетов за определенное время, а не выдача отчетов по текущим событиям, как на оперативном уровне;
  3.  разработка плановых заданий;
  4.  обеспечение доступа к архивной информации и т.д.

Большинство ЭИС данного типа обеспечивают принятие нетривиальных решений. В случае, когда требования к информационному обеспечению определены не строго, они способны отвечать на вопрос: «что будет, если ...?»

На этом уровне можно выделить два типа информационных систем: управленческие (для менеджмента) и системы поддержки принятия решений.

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

Характеристики управленческих информационных систем:

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

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

Характеристики систем поддержки принятия решений:

  1.  обеспечивают решение проблем, развитие которых трудно прогнозировать;
  2.  оснащены сложными инструментальными средствами моделирования и анализа;
  3.  позволяют легко менять постановки решаемых задач и входные данные;
  4.  отличаются гибкостью и легко адаптируются к изменению условий по несколько раз в день;
  5.  имеют технологию, максимально ориентированную на пользователя.

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

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

40568. Управление приложением пользователя 4.61 MB
  Для организации эффективной работы пользователя целесообразно создать целостное приложение предметной области, в котором все его компоненты должны быть сгруппированы по функциональному назначению. При этом необходимо обеспечить удобный графический интерфейс, чтобы пользователь мог решать задачи
40569. Введение в предмет АИС 29 KB
  Н 3 курс дисциплина АИС Занятие № 1 Тема: Введение в предмет АИС 1. Задачи АИС АИС являются широко распространенными в настоящее время развития общества когда информатика информационные технологии компьютеры сопровождают человека во всех сферах деятельности. Задачами АИС на данном этапе развития являются: изучение современных методов и средств проектирования информационных систем...
40570. Работа с данными таблицы 678 KB
  Достаточно часто возникает необходимость быстрого нахождения и редактирования заданных записей в больших массивах информация. Для этого важно быстро выбрать по некому шаблону записи и отсортировать их. Данная задача решается с помощью фильтрации записей в режиме таблицы или формы.
40571. СТРУКТУРА АИС 59.5 KB
  3курс дисциплина АИС Занятие №3 Тема: СТРУКТУРА АИС Типы обеспечивающих подсистем Структуру информационной системы составляет совокупность отдельных ее частей называемых подсистемами. Подсистема это часть системы выделенная по какомулибо признаку. Общую структуру информационной системы можно рассматривать как совокупность подсистем независимо от сферы применения. В этом случае говорят о структурном признаке классификации а подсистемы называют обеспечивающими.
40572. Классификация автоматизированных информационных систем 58 KB
  В файлсерверных ИС база данных находится на файловом сервере а СУБД и клиентские приложения находятся на рабочих станциях. В клиентсерверных ИС база данных и СУБД находятся на сервере а на рабочих станциях находятся клиентские приложения. twotier ИС всего два типа звеньев: сервер баз данных на котором находятся БД и СУБД bckend и рабочие станции на которых находятся клиентские приложения frontend. Типичный пример применения многозвенности современные вебприложения использующие базы данных.
40573. ВАРИАНТ ОПРЕДЕЛЕНИЯ НАПРЯЖЕННО-ДЕФОРМИРОВАННОГО СОСТОЯНИЯ УПРУГОГО ТЕЛА КОНЕЧНЫХ РАЗМЕРОВ С ТРЕЩИНОЙ 1.75 MB
  Рассмотрена задача о нахождении напряженно-деформированного состояния (НДС) в поврежденном трещиной теле конечных размеров. Трещина моделируется физическим разрезом с характерной толщиной и материальным слоем на его продолжении. Напряженное состояние слоя описывается средними по толщине и граничными напряжениями, связанными условиями равновесия
40574. Жизненный цикл автоматизированной информационной системы информационной системы 27.5 KB
  Жизненный цикл информационной системы представляет собой непрерывный процесс начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации. Стандарт ISO IEC 12207 определяет структуру жизненного цикла включая процессы действия и задачи которые должны быть выполнены во время создания информационной системы. Вообще говоря все стандарты на информационные системы как и на любые системы вообще можно разбить на следующие два основных класса:  Функциональные...
40575. Стадии ЖЦ АИС 29.5 KB
  В принципе это деление на стадии достаточно произвольно. Согласно методологии предлагаемой Rtionl Softwre жизненный цикл информационной системы подразделяется на четыре стадии: начало; уточнение; конструирование; передача в эксплуатацию. Границы каждой стадии определены некоторыми моментами времени в которые необходимо принимать определенные критические решения и следовательно достигать определенных ключевых целей.
40576. Классификация АИС 40 KB
  Сообщение темы урока постановка цели и задачи 13мин: Постановку целей начать с проблемы: на какие группы Вы бы разделили все известные АИС 4. Изложение нового материала применяемая методика 4050: Рассмотреть две современные классификации АИС: {таблица} по способу представления логической организации фактографические документальные геоинформационные по функциям решаемым задачам справочные расчетные поисковые технологические Рассмотреть перечисленные группы и привести примеры 5. Закрепление изучаемого материала применяемая...