Государственное бюджетное образовательное учреждение Астраханской области среднего профессионального образования

«Астраханский государственный политехнический колледж»

(ГБОУ АО СПО «АГПК»)

КУРС ЛЕКЦИЙ

2014

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

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

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

В ходе достижения цели решаются следующие задачи:

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

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

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

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

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

Курс лекций соответствует рабочей программе 3 поколения  по дисциплине «Устройство и функционирование информационный системы» для специальности 230103.52 «Информационные системы (по отраслям)», а также требованиям ФГОС СПО.

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

1. Емельянова Н. З., Партыка Т. Л., Попов И. И.   «Устройство и функционирование информационных систем», М, Форум "Инфра-М", 2011,  Учебное пособие.

2. Емельянова Н.З. , Партыка Т.Л., Попов И.И. Основы построения автоматизированных информационных систем. М, Форум "Инфра-М", 2009. Учебное пособие.  
3. Грекул В.И., Денищенко Г.Н, Коровкина Н.Л.  Проектирование информационных систем., М, 2009г,серия «Основы  информационных технологий».
4. Гвоздева В.А., Лаврентьева И..Ю. Основы построения автоматизированных систем, М,  ИД форум, инфра-М, 2010.

РАЗДЕЛ 1 ОБЩАЯ ХАРАКТЕРИСТИКА  ИНФОРМАЦИОННЫХ СИСТЕМ

Тема 1.1.  Информационные системы: основные понятия

Тема 1.2 Средства автоматизированных информационных систем

Тест №1

РАЗДЕЛ 2 ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ АИС

Тема 2.1 Классификация методов проектирования систем

Тема 2.2. Жизненный цикл ИС

Тема 2.3. Организация разработки ИС

Тема 2.4. Проектирование ИС и реинжиниринг бизнес-процессов

Тема 2.5. Спецификация функциональных требований к ИС

Тест №2

РАЗДЕЛ 3. ЭФФЕКТИВНОСТЬ АИС

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

Тема 3.2. Организация труда при разработке информационной системы;

Тест №3

ГЛОССАРИЙ

РАЗДЕЛ 1 ОБЩАЯ ХАРАКТЕРИСТИКА  ИНФОРМАЦИОННЫХ СИСТЕМ

Тема 1.1.  Информационные системы: основные понятия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основные цели автоматизации

1. Повышение производительности
2. Достижение оптимальных условий прохождения технологического процесса
3. Достижение максимальной повторяемости
4. Снижение трудозатрат при обслуживании оборудования
5. Получение оперативной информации о ходе производственного процесса

Повышение производительности

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

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

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

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

Достижение максимальной повторяемости

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

Снижение трудозатрат при обслуживании оборудования

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

Получение оперативной информации о ходе производственного процесса

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

Необходимость автоматизации обработки информационных потоков.

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

Информационный поток — информация, рассматриваемая в процессе ее движения в пространстве и времени в определенном направлении.

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

Основные понятия: информация, данные, способы сбора и хранения информации.

Термин информация происходит от латинского слова informatio – разъяснение, изложение. В середине ХХ века термин «информация» превратился в общенаучное понятие, означающее обмен сведениями между людьми, между человеком и автоматом, между автоматами, а также обмен сигналами в животном и растительном мире.

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

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

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

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

В Федеральном законе «Об информации, информатизации и защите информации» дается следующее определение:

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

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

Рис.1. Информационная система.

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

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

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

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

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

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

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

Схема потока информации задается указанием отношения вхождения относительно каждого элемента потока.

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

Вопросы  для самопроверки:

1. Дайте определение термина «информационные системы».

2. Что такое «информационные ресурсы»

6. Основные принципы существования информационной системы.

7. Требования, предъявляемые к обработке информации в информационной системе.

8. Что такое информационный поток?

9.  В чем заключается анализ информационных потоков?

Типы организационных структур  АИС

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

Подсистема - часть системы с некоторыми связями и отношениями.

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

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

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

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

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

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

Понятие проблемы в системном анализе - шире, чем понятие задачи, и состоит обычно из ряда взаимосвязанных задач.

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

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

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

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

Определим, пока не формализованно, понятие структуры системы.

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

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

Базовые топологии структур (систем) приведены на  рисунке 2-5.

Рисунок  2. Структура линейного типа

Рисунок 3. Структура иерархического типа (первая цифра - номер уровня)

Рисунок  4.  Структура сетевого типа (вторая цифра - номер в пути)

Рисунок 5. Структура матричного типа

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

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

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

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

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

Можно теперь дать более полное определение системы.

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

Рисунок 6. Структура системы

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

Совокупность элементов и связей между ними позволяет судить о структуре системы.

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

Внутреннее описание дает информацию о поведении системы, о соответствии (несоответствии) внутренней структуры системы целям, подсистемам (элементам) и ресурсам в системе, внешнее описание - о взаимоотношениях с другими системами, с целями и ресурсами других систем (см. рис.6).

Внешнее описание системы определяется ее внутренним описанием.

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

Структура АИС Составные части АИС

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

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

Cтруктуру АИС составляет совокупность отдельных ее частей, называемых подсистемами. ( рис.7)

Рисунок 7. Cтруктура АИС

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

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

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

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

Вопорсы  для самопроверки

1. Что такое цель, структура, система, подсистема, задача, решение задачи, проблема?
2. Каковы основные признаки и топологии систем? Каковы их основные типы описаний?
3. Какова  структура АИС?
4. Дайте характеристику подсистем АИС.

Задачи и упражнения

1. Каковы подсистемы системы "ВУЗ"? Какие связи между ними существуют? Описать их внешнюю и внутреннюю среду, структуру. Классифицировать (с пояснениями) подсистемы. Описать вход, выход, цель, связи указанной системы и ее подсистем. Нарисовать топологию системы.
2. Привести пример некоторой системы, указать ее связи с окружающей средой, входные и выходные параметры, возможные состояния системы, подсистемы. Пояснить на этом примере (т.е. на примере одной из задач ), возникающих в данной системе конкретный смысл понятий "решить задачу " и "решение задачи ". Поставить одну проблему для этой системы.

Темы для научных исследований и рефератов, интернет-листов

1. Плохо структурируемые и формализуемые системы.
2. Свойства систем, их актуальность и необходимость. Примеры.

Тема 1.2  Средства автоматизированных информационных систем

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

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

Рисунок 8. Информационное обеспечение АИС

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

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

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

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

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

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

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

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

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

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

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

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

При решении этих задач осуществляется:

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

Создание ИО проходит следующие этапы:

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

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

ИО реализуется (рис. 9) как:

1. Внешнее (немашинное) ИО, которое, однако, должно учитывать принципы автоматизации информационных процессов. Его состав:

• СКК (система классификации и кодирования);
• НСД (нормативно-справочные документы);
• ОД (оперативные документы);
• ММ (методические и инструктивные материалы).

Движение этих документов реализуется в соответствии с организационной структурой управления.

2. Внутримашинное ИО включает:

• ИМ (информационные массивы), составляющие информационную базу системы;
• ПП (пакеты программ).

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

Рис. 2.1. Состав информационного обеспечения

Рисунок 9. Состав информационного  обеспечения

Традиционно, в соответствии с ГОСТ 34.03-90, информационное обеспечение рассматривалось как «совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в АС при ее функционировании».

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

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

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

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

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

Основными функциями ИО являются:

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

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

Классификация - система распределения объектов по классам в соответствии с определенным признаком (основание классификации).

Объекты необходимо классифицировать для:

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

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

В АИС внедрены общесоюзные, отраслевые и локальные классификаторы. Всего в связи эксплуатируется более 300 общесоюзных, отраслевых и локальных классификаторов. Из общесоюзных классификаторов различных категорий используются такие, как «Система обозначений единиц измерения», «Система обозначения органов государственного управления», «Система обозначения объектов административно-территориального деления» и др. В настоящее время в эксплуатации находится более 20 отраслевых классификаторов, из которых наиболее распространены следующие: «Отраслевой классификатор предприятий и организаций отрасли связи», «Классификатор подсистем и задач АСУ», «Отраслевая система классификации и кодирования средств связи», «Отраслевой классификатор технико-экономических показателей» и т. д.

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

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

Классификация - основа кодирования.

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

Цель кодирования - представление информации в более компактном и удобной форме при записи ее на машинный носитель; приспособление к передаче по каналам связи; упрощение логической обработки. Система кодирования применяется для замены названия объекта на какой-либо код. Код строится на основе использования букв и цифр.

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

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

Информационная база, записанная на машинные носители информации и используемая для решения задач на ЭВМ, называется базой данных

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

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

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

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

Условно-постоянные подразделяются на группы:

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

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

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

Базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

Файлы исходных данных содержат объекты, подлежащие обработке.

Файлы вторичной информации содержат описания объектов или их элементов.

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

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

Среди наиболее известных СУБД можно отметить: иерархические — IMS (Information Management System) фирмы IBM, «ОКА» и «ИНЭС» отечественные, реляционные — MS Access, Lotus Approach, Borland dBase, Borland Paradox, MS Visual FoxPro, MS SQL Server, Oracle.

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

СУБД различаются по своим возможностям и требованиям к вычислительной технике. Различают два основных класса СУБД:

• персональные — ориентированы на работу одного пользователя на ПК (dBase, FoxPro, MS Access и др.);
• многопользовательские — ориентированы на параллельную работу многих пользователей на больших компьютерах (MS SQL Server).

Персональная СУБД имеет удобный интерфейс и применяется как единая программа.

Информация БД размещается в файлах (в реляционных БД — в табличных файлах).

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

Математическое обеспечение

Назначение, состав и структура математического обеспечения (МО)

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

Состав МО:

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

Система математического обеспечения АС должна выполнять следующие функции:

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

В МО по последовательности проектирования АСУ рассматривают три уровня:

1. математическое обеспечение конкретной АС, которой определяется мощность АС;
2. автоматизацию проектирования АС;
3. автоматизацию программирования и организацию работ на ЭВМ.

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

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

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

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

Так как АСУ является информационной системой, то ее функционирование есть последовательность действий по обработке информации, предназначенной для управления. Поэтому рассмотрим структуру МО на примере АСУ. МО АСУ включает совокупность методов и средств, позволяющих строить экономико-математические модели задач управления объектом: методы + модели + алгоритмы обработки информации.

На рис. 10 представлена схема состава МО системы.

Рисунок 10. Состав математического обеспечения:

С — средства; Д — документация; М — методы; СМ — средства моделирования; ОЗУ — описания задач управления; МОМ — методы оптимизации моделей; ММС — методы математической статистики; 03 — описание задач; ЗА — задания на алгоритмическом языке; ЭММ — экономико-математическая модель; А — алгоритм решения задач; П — контрольный пример; МОЗ — методы определения типа задач; МОС — методы оценки вычислительной сложности алгоритмов; МОО — методы оценки отношений

Формализация и моделирование

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

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

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

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

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

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

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

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

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

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

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

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

К математическим моделям предъявляются требования универсальности, адекватности и экономичности (меньше затрат ресурсов).

Классификация математических моделей приведена в табл. 1.

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

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

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

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

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

Автоматизированное проектирование оптимальных объектов и систем на основе математических методов с использованием компьютеров содержит две основные задачи:

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

Операционная модель — это совокупность алгоритмов, описывающих функциональные свойства проектируемого объекта, отвечающего всем требованиям, предъявляемых в рамках конкретных задач проектирования. Операционная модель выражает зависимость критерия эффективности операции от выбранных параметров, а также условий проведения операций. Функционально это выражается зависимостью W = = F(A/, Xj), где W — выражения критерия эффективности операции; F — оператор (символ модели); Aj — информация, вводимая в модель, на которую оператор не оказывает влияние; X, — управляемые параметры.

Схема метода построения операционных математических моделей приведена на рис. 11.

В аналитических моделях критерий связан с величинами Aj и X/ математическими зависимостями, по которым можно определить экстремальное значение либо непосредственно, либо с помощью численных методов на ЭВМ. Связь между W и X/ и A j может быть очень сложной.

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

Рисунок  11. Схема метода построения операционных математических моделей

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

Статистические модели строятся методом статистических испытаний случайных чисел.

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

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

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

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

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

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

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

Вопорсы  для самопроверки:

1. Что входит в состав АИС?
2. Какова типовая структура АИС?
3. Что включает обеспечивающая часть АИС? Охарактеризуйте ее.
4. Что включает функциональная часть АИС? Охарактеризуйте ее на примере системы.
5. Каково назначение и состав математического обеспечения (МО) АИС?
6. Какие функции реализует система математического обеспечения АС?
7. Что такое математическое моделирование в АИС?

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

Назначение и состав программного обеспечения (ПО)

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

ПО включает в себя ОС (операционные системы), ППП (пакеты прикладных программ) и системы программирования (СП).

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

ПО тесно связано с математическим обеспечением (МО), так как составляется на базе МО, на основе алгоритмов.

Состав программного обеспечения показан на рисунке 12.

Рисунок  12. Состав программного обеспечения:

УЧ — управляющая часть; 04 — обрабатывающая часть; ПОН — программы общего назначения; ПФН — программы функционального назначения; ОВП — организация выполняемого процесса; ВИБ — ведение информационной базы

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

В настоящее время широко распространены такие ОС как UNIX и разработанные под ее влиянием MS DOS, Windows 95/NT, OS/2. Для персональных компьютеров, часто используют версии Windows 2000, Windows ХР и другие.

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

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

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

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

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

В некоторых ЭВМ супервизор + монитор образуют программу-диспетчер.

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

Внутреннее ПО тесно связано со структурой ЭВМ и реализует возможности, заложенные в аппаратуре.

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

СП содержит средства автоматизированной разработки и отладки программ, организации выполняемого процесса (ОВП) и ведения информационной базы (ВИБ).

СП могут быть одноязычными (Visual Basic, Turbo С, Turbo Pascal) и многоязычными, т. е. когда отдельные части программных модулей написаны на разных языках (СП OS/360, СП UNIX и др.). После компиляции они объединяются в исполняемые модули. Каждый язык программирования в большей степени пригоден для определенного класса задач (информационных, оптимизации и т. д.), поэтому система программирования содержит целый набор языков, которые используют для решения задач разного типа.

СП могут быть замкнутыми и открытыми, когда в систему можно добавлять ЯП с транслятором.

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

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

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

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

Пакеты прикладных программ (ППП) или Приложения.

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

К ПОН можно отнести системы программирования на языках высокого уровня, СУБД, программы-редакторы текстов, изображений, издательские системы. Первые реализуют типовые режимы работы вычислительной системы.

К ПФН относят пакеты программ, предназначенные для решения задач в определенной предметной области. Деление это достаточно условно.

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

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

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

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

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

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

Внешнее ПО решает конкретные задачи АС в соответствии с иерархическими уровнями системы управления.

Рисунок  13. Состав программного обеспечения

Техническое обеспечение. Состав, структура и функции ТС в  ИС

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

Состав КТС — это номенклатура комплекса технических средств.

В состав комплекса технических средств АИС входят:

• средства подготовки и регистрации информации (СПР);
• средства сбора и передачи информации (ССП);
• средства хранения и обработки информации (СХО);
• средства вывода и воспроизведения информации (СВВ).

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

Кроме КТС к техническому обеспечению (ТО) (рис. 14) относятся:

ММ — методические материалы, включающие:

М — методику выбора КТС;

ТПР — библиотеки типовых программных решений для функционирования КТС;

МО — методику оценки показаний качества функционирования КТС;

П — персонал по разработке, внедрению и эксплуатации ТС, включающий:

ПВТ — персонал по обслуживанию вычислительной техники;

ППС — персонал по периферийным средствам;

ПСТ — персонал по системам телеобработки данных;

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

ОП — обслуживающий персонал.

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

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

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

Рисунок  14. Состав технического обеспечения

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

Например, система «Экспресс», предназначенная для автоматизации обслуживания пассажиров в масштабе всей нашей страны, имеет следующий состав и структуру (рис. 15).

Рисунок 15. Состав и структура системы «Экспресс»

Управляет работой комплекса периферийных устройств АРМ устройство управления, построенное на базе микропроцессора. В АРМ в качестве устройств вывода служат:

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

Некоторые АРМ взаимодействуют между собой в режиме локальной сети, передавая данные с дисплея на дисплей, с магнитного диска (МД) одного АРМ на МД другого.

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

Средства  сбора и передачи  информации.

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

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

Сбор информации может осуществляться в ручном, механизированном, автоматизированном и автоматическом режимах.

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

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

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

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

Устройства передачи данных — совокупность ТС и магнитных накопителей (НМ), предназначенная для обмена информацией между ее источниками, потребителями и объектами управления. Обмен информацией происходит по каналам связи._Канал связи — совокупность ТС и физическая среда, предназначенная для передачи сигнала. Физическая среда, по которой распространяется сигнал, называется линией.

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

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

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

Локальные сети — совокупность ЭВМ и линий связи, расположенных на небольшой территории и принадлежащих, как правило, одной организации. В локальных сетях используются качественные линии связи — коаксиальные кабели, оптоволоконные кабели, витая пара. Скорость передачи данных 10, 16 и 100 Мбит/с.

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

Глобальные сети — территориально рассредоточенные на большие расстояния компьютеры, объединенные скоростными каналами связи. В глобальных сетях применяются сложные методы передачи данных: модуляция, асинхронность, контрольное суммирование, квитирование, повторная передача искаженных фрагментов. Скорость передачи данных 2400, 9600, 28 800, 33 600 бит/с и 64 Кбит/с, на магистральных каналах — до 2 Мбит/с. Но в некоторых коммерческих глобальных сетях, использующих оптическую цифровую передачу данных по оптоволоконным линиям связи, скорости передачи данных приближаются к скоростям передачи по локальным сетям. По типу используемых компьютеров глобальные сети относятся к неоднородным, т. е. к программно несовместимым.

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

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

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

Потребность в совместном использовании информационных ресурсов, их сборе и передаче привели к соединению миникомпьютеров (персональных компьютеров) в локальные вычислительные сети (ЛВС). В локальных сетях уже в 1980-х гг. широко применялись стандартные технологии объединения компьютеров в сеть (Ethernet, Arc net и др.). Для создания сети нужны были сетевые адаптеры, например Ethernet, и стандартный кабель, к которому подключались адаптеры через разъемы. На компьютере в этом случае устанавливалась одна из сетевых операционных систем (например, NetWare).

Локальные сети классифицируют по признакам расстояния и скорости передачи информации:

• расстояние 10-500 м, скорость 2400-19200 бод. ЛВС ориентированы на массового пользователя;
• расстояние — до 1 км, скорость 19200-1 Мбод. ЛВС включают кроме ПЭВМ технологическое оборудование с встроенной микропроцессорной техникой (средства автоматизации, кассовые аппараты), а также средства электронной почты;
• расстояние — до нескольких километров, скорость — до 120 Мбод. ЛВС включают ПЭВМ, мини-ЭВМ и ЭВМ среднего класса. Они используются для организации сложных производственных процессов в гибких автоматизированных модулях, САПР и т. п.;
• расстояние — до 10 км, скорость 10-50 Мбод. ЛВС объединяют все классы ЭВМ. Используются для управления сложным производством, отраслью и т.п.

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

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

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

Появление высокоскоростных каналов связи привело к развитию глобальных сетей. С 1999 г. реализуется международный проект 174 стран по созданию сверхскоростных каналов связи протяженностью 275 тыс. км.

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

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

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

В Интернете действуют два главных протокола: IP (Internet Protocol) — межсетевой протокол и TCP (Transmission Control Protocol) — протокол управления передачей. В соответствии с IP-протоколом передаваемые данные разбиваются с помощью прикладной программы на блоки определенного формата, упаковываются в пакеты, имеющие номер и заголовок, и передаются по определенным маршрутам, а поступающие пакеты обрабатываются. TCP-протокол управления потоком данных следит за комплектностью и порядком получения и сборки пакетов. Работа по этим протоколам подобна работе почтовой службы.

На основе протоколов IP и TCP разработаны сетевые сервисные протоколы:

• FTP (File Transfer Protocol) — протокол передачи файлов;
• HTTP (Hyper Text Transfer Protocol) — протокол передачи гипертекста;
• SMTP (Simple Mail Transfer Protocol) — протокол пересылки электронной почты;
• NNTP (Network News Transfer Protocol) — протокол передачи новостей (телеконференций);
• Telnet — протокол удаленного доступа.

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

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

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

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

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

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

Правовое, организационное, методическое  и эргономическое обеспечение

Правовое, организационное, методическое и эргономическое обеспечение

ГОСТ 34.003-90 предлагает следующие определения:

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

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

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

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

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

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

1. «Закон об информации, информатизации и защите информации» от 20 февраля 1995 г. № 24-ФЗ.
2. «Закон о правовой охране для электронных вычислительных машин и баз данных» от 23 сентября 1992 г. № 3523-1.
3. «Закон о стандартизации» от 10 июня 1993 г. № 5154-1.
4.  «Закон о сертификации продукции и услуг» от 27 апреля 1993 г. № 5151-1 (в редакции от 27 декабря 1995 г. № 211-ФЗ; от  1 марта 1998 г. № 30-Ф3; от 31 июля 1998 г. № 154-ФЗ).
5. «Закон об участии в международном информационном обмене» от 4 июля 1996 г. № 85-ФЗ.
6. «Закон об авторском праве и смежных правах» от 9 июля 1993 г. № 5351-1 (в редакции от 19 июля 1995 г. № 110-ФЗ).

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

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

Так, требования к содержанию документов, разрабатываемых при создании АС, устанавливают:

• Руководящий документ по стандартизации РД 50-34.698-90;
• Единая система программной документации (ЕСПД);
• Единая система конструкторской документации (ЕСКД);
• Систему проектной документации для строительства (СПДС);
• ГОСТ 34.602.

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

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

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

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

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

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

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

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

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

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

Непосредственно с АИС работают:

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

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

Руководящий документ по стандартизации РД 50-34.698-90 рекомендует при создании АС разрабатывать документ по организационному обеспечению «Описание организационной структуры». В нем должны быть отображены изменения в организационной структуре управления объектом, организация новых подразделений и реорганизация существующих подразделений.

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

Руководящий документ по стандартизации РД 50-34.698-90 рекомендует в области методического обеспечения разрабатывать:

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

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

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

Документ «Руководство пользователя» содержит, как правило, следующие разделы:

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

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

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

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

Вопорсы  для самопроверки:

1. Каково назначение и состав программного обеспечения АИС?
2. Каково назначение и состав технического обеспечения АИС?
3. Какова структура комплекса технических средств (КТС) АИС?
4. Каковы требования, предъявляемые к КТС?
5. Какие вы знаете средства сбора и передачи информации? Кратко охарактеризуйте их.
6. Что необходимо учитывать при выборе КТС?

РАЗДЕЛ 2 ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ АИС

Тема.  Классификация методов проектирования систем

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

Проектирование (от лат. projectus – брошенный вперед) – это процесс создания проекта – прототипа, прообраза предлагаемого или возможного объекта, состояния.

Понятия «проектирование» охватывает все составляющие процесса научных/прикладных исследований: анализ, синтез, «исследование», «разработка» и т. п.;

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

Проектирование информационных систем – сравнительно новый вид проектирования. Здесь необходимо вспомнить определение проектируемого объекта:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методы проектирования ИС можно классифицировать по следующим основаниям:

По степени автоматизации:

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

По степени использования типовых проектных решений:

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

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

По степени адаптивности проектных решений:

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

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

• Каноническое проектирование;
• Индустриальное проектирование, которое подразделяется на два подкласса:
• Автоматизированное проектирование;
• Типовое проектирование.

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

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

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

Используя указанное определение, можно сформулировать основные признаки средств проектирования ИС:

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

Все средства проектирования ИС можно разделить на два класса:

Компьютерные, которые можно подразделить на следующие подклассы:

• Средства проектирования операций обработки информации (алгоритмические языки, библиотеки стандартных подпрограмм и классов, инструменты тестирования и отладки программ);
• Средства проектирования отдельных компонентов ИС (специализированные пакеты программ мат. статистики и мат. программирования, СУБД, графические и текстовые редакторы и др.);
• Средства автоматизированной разработки различных этапов проекта ИС – CASE-средства.

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

Проектирование ИС охватывает три основные области:

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

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

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

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

Классификация  информационных систем

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

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

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

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

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

Рисунок  16. Классификация информационных систем

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

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

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

В зависимости от характера обработки данных ИС делятся на информационно-поисковые и информационно-решающие.

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

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

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

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

В зависимости от сферы применения различают следующие классы ИС.

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

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

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

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

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

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

Вопорсы  для самопроверки:

1. Каковы классы методологий проектирования АИС?
2. Каковы методы разработки АИС? Дайте их характеристику.
3. Что значит классифицировать АИС? Приведите основания классификации.
4. По каким принципам происходит деление АИС по масштабу?
5. Какова классификация групповых и корпоративных АИС по способу организации?
6. Как классифицировать АИС по видам выполняемых операций?
7. Что понимают под одноуровневой и многоуровневой многоцелевыми системами?

 Тема.  Жизненный цикл ИС

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

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

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

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

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

• Поэтапная модель с промежуточным контролем (рис.17). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

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

Рисунок 16. Каскадная модель ЖЦ ИС

Рисунок 17. Поэтапная модель с промежуточным контролем

Рисунок 18. Спиральная модель ЖЦ ИС

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

• каскадная модель (характерна для периода 1970-1985 гг.);
• спиральная модель (характерна для периода после 1986.г.).

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

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

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

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

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

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

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

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

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

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

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

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

Среди наиболее известных стандартов можно выделить следующие:

• ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
• ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.
• Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.
• Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.
• Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
• Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

1. Основные процессы:

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

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

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

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

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

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

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

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

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

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

Обычно выделяют следующие этапы создания ИС:

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

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

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

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

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

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

Конечными продуктами этапа проектирования являются:

• схема базы данных (на основании ER-модели, разработанной на этапе анализа);
• набор спецификаций модулей системы (они строятся на базе моделей функций).

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

• будет ли это архитектура "файл-сервер" или "клиент-сервер";
• будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
• будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
• будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);
• будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Этап проектирования завершается разработкой технического проекта ИС.

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

Этап тестирования обычно оказывается распределенным во времени.

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

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

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

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

Вопорсы  для самопроверки.

1. Перечислите этапы и стадии жизненного цикла АИС.
2. Перечислите модели жизненного цикла?
3. Какие положительные стороны можно выделить в применении каскадного подхода?
4. На какие три группы делятся процессы ЖЦ ПО с базовым международным стандартом  ISO/IEC 12207?
5. К чему относится формирование требований к системе, проектирование, реализация, тестирование и т.д.?
6. Назовите этапы типового проектирования.
7. Что является конечным этапом проектирования?

Тема. Организация разработки ИС

Стадии и этапы канонического проектирования

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

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

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

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

Стадия 2. Разработка концепции ИС.

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

• оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

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

Стадия 4. Эскизный проект.

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

Стадия 5. Технический проект.

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

Стадия 6. Рабочая документация.

• разработка рабочей документации на ИС и ее части;
• разработка и адаптация программ.

Стадия 7. Ввод в действие.

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

Стадия 8. Сопровождение ИС.

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

Состав и содержание работ на предпроектной стадии создания ИС

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

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

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

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

Кроме того, объектами обследования служат:

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

Основной целью выполнения первого этапа предпроектного обследования «Сбор материалов» является:

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

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

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

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

1. Факторы, связанные с параметрами входных информационных потоков, поступающих на обработку ЭВМ: объем информации, тип носителя информации, характер представления информации.

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

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

Методы проведения обследования

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

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

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

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

При выборе метода следует учитывать следующие критерии:

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

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

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

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

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

«План-график» служит инструментом для планирования и оперативного управления предпроектной стадией.

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

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

Отчет об обследовании объекта

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

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

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

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

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

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

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

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

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

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

Анализ материалов обследования

На основе формализованного описания предметной области выполняется этап «Анализ материалов обследования», целями которого являются:

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

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

Вопорсы  для самопроверки:

1. Сколько стадий и этапов создания ИС?

2. Расскажите кратко о всех стадиях и этапах ИС.
3. Каковы основные этапы канонического проектирования АИС
4. Содержание и результаты предпроектного обследования.
5. Содержание и результаты технорабочего проектирования.
6. Что такое стадия и этап создания автоматизированной системы?
7. Что такое техническое задание на создание АС и из каких разделов оно состоит?

Типовое проектирование.  Понятие типового проекта, предпосылки типизации

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

Причины применения типового проектирования:

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

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

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

В первую очередь, сюда относятся экономические системы, для которых характерны:

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

Процесс проектирования ИС состоит из следующих основных этапов:

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

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

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение.

Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

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

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

Основные особенности различных классов ТПР приведены в таблице 3.

Основные черты ТПР:

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

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

Требования, выдвигаемые к типовым проектным решениям:

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

Объекты типизации

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

Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

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

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

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

Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций . Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

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

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

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

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

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

Методы типового проектирования

Для реализации типового проектирования используются два подхода: параметрически-ориентированное и модельно-ориентированное проектирование.

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

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

Рисунок 19. Представление пакета прикладных программ в виде «черного ящика».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Репозиторий

Рисунок  20.  Конфигурация информационной системы на основе модельно-ориентированной технологии.

Модель функций.

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

Модель процессов.

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

Модели объектов (данных).

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

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

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

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

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

Рисунок 21. Установление связи модели бизнес-процессов и модели организационной структуры.

Модели бизнес-правил.

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

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

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

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

Оценка эффективности использования типовых решений.

В рамках спиральной модели ЖЦ широкое распространение получила методология прототипного проектирования . Ядром этой методологии является способ быстрой разработки приложений — RAD (Rapid Application Development). Подход RAD предусматривает наличие трех составляющих :

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

Технология обеспечивает создание на ранней стадии действующей интерактивной модели — системы-прототипа ЖЦ: анализ и планирование, проектирование, построение — быстрая разработка приложения, внедрение.

Прототип позволяет:

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

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

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

Такие инструментальные средства можно разделить на два класса :

• интегрированные инструменты быстрой разработки приложений (класс BUILDER );
• инструменты быстрой разработки приложения в развитых СУБД (класс DEVELOPER).

Вопорсы  для самопроверки:

1. Что такое предпосылки типизации, типовое проектирование,  типовое проектное решение.
2. Опишите основные черты ТПР?
3. Какие этапы включает в себя параметрически-ориентированное проектирование? И расскажите про каждый этап.
4. Что такое проектирование системы?
5. Какие комплексы проектных решений предусматривает создание АИС?
6. На основе чего разрабатываются процедуры и технологии АИС?
7. Какие этапы проходит создание ИО?

 Тема. Проектирование ИС и РБП — реинжиниринг бизнес-процессов  

(BPR — business process reengineering)

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

Это встраивание является основанием для переосмысления и переструктуризации самих бизнес-процессов — реинжиниринг бизнес-процессов (РБП) или, в оригинале, — business process reengineering (BPR).

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

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

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

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

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

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

Рисунок  22. Идеальный (а) и реальный (б) процессы разработки по каскадной схеме.

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

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

 Рисунок 23. Распределение людских ресурсов при разработке программной системы: а- конвейерное, б- реальное.

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

1. Отставание — существенное запаздывание с получением результатов.
2. Бесполезность или вред — и в зарубежной, и в отечественной литературе практики и аналитики оценивали проектирование ИС как действие, очень часто ведущее к примитивной автоматизации (по сути — «механизации») существующих производственных функций работников.
3. Жесткость — из-за определяющего влияния иерархических структур на процессы и результаты проектирования ИС для представления в ИС функций и данных применявшиеся подходы получили общее условное название «структурное проектирование». Однако жесткость иерархических структур ограничивает их полезность, и чем дальше, тем менее допустимы эти ограничения.

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

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

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

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

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

Рисунок 24. Модель Дж. Хендерсона

Основываясь на этой модели, можно сделать следующие выводы.

1. Существует двунаправленное воздействие основных бизнес- и ИТ-платформ.
2. Если основная бизнес- или ИТ-платформа меняется, то маловероятно, что соответствующая наследуемая ИТ-архитектура сохранится.

Соответствие между бизнес- и ИТ-архитектурами является решающим фактором успеха, но

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

В табл. 4 показана взаимосвязь бизнес-архитектуры и ИТ-архитектуры в современных  условиях.

ИТ-архитектуры и общий бизнес-реинжиниринг

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

Отсюда следуют выводы:

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

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

Так же, как объявление РБП в качестве нового течения оправдано новыми рыночными условиями и взаимосвязями с ИТ, так и объявление НСП объясняется, в первую очередь, новыми требованиями к создаваемым корпоративным ИС, а также методами проектирования, развиваемыми в самих ИТ.

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

Основные принципиальные положения НСП следующие:

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

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

Направления НСП и используемые в них методы

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

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

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

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

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

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

Применяются методы функционального и организационного проектирования:

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

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

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

Разрабатываются или приобретаются информационно-аналитические системы для поддержки выполнения маркетинговых экспертиз в жизненном цикле товара, применяются системы поддержки хранилищ данных (Data WareHouse — DWH) и оперативной аналитической обработки (Online Analyse Processing — OLAP).

Сокращение числа иерархических уровней управления с использованием:

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

• корпоративной почты, телеконференций и видеоконференций.

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

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

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

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

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

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

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

Применяются:

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

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

• глобальные цифровые (компьютерные) сети и их услуги, например, построение выходов из корпоративных сетей в Интернет;
• инструменты и средства работы в глобальных сетях: средства гипертекстового просмотра БД серверов WWW, приложения для удаленных финансовых расчетов и др.;
• режимы и стандарты информационной супермагистрали для повсеместного доступа к информации любых видов — от прейскурантов и типовых условий возможных бизнес-партнеров до динамических потоков конъюнктурной и справочной информации общего характера;
• отказ от встраивания ограничений на возможности компьютерного общения в аппаратную архитектуру, архитектуру каналов связи, в программное обеспечение или в выделенный центр удаленного администрирования распределенной корпоративной сетью;
• средства защиты конфиденциальных данных, не ограничивающих возможности свободного обращения абонентов по нужному адресу (кроме особых случаев, в которых оправдано создание компьютерных островов);
• режимы работы коммуникаций и ИС в режиме 24 (часа) х 365 (дней).

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

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

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

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

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

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

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

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

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

Применяются:

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

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

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

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

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

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

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

Вопорсы  для самопроверки:

1. Что является основным недостатком каскадных схем?
2. Что такое основная бизнес-платформа, бизнес-архитектура, основная ИТ-платформа, ИТ-платформа?
3. Перечислите основные принципиальные положения НСП?
4. Опишите анализ стратегических целей, анализ факторов риска?
5. Перечислите основные компоненты подхода  «новое системное проектирование»
6. В чем, по вашему мнению, заключается сущность BPR и на какие типы аис этот подход  распространяется

 Тема. Спецификация функциональных требований к ИС

Процессные потоковые модели

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

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

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

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

Главными недостатками функционального подхода являются:

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

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

Процессный подход к организации деятельности организации

Процессный подход к организации деятельности предприятия предполагает:

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

Согласно стандарту "Основные Положения и Словарь — ИСО/ОПМС 9000:2000" понятие " Процессный подход " определяется как:

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

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

Процессная модель компании должна строиться с учетом следующих положений:

1. Верхний уровень модели должен отражать только контекст диаграммы – взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром.
2. На втором уровне должны быть отражены тематически сгруппированные бизнес-процессы предприятия и их взаимосвязи.
3. Каждая из деятельностей должна быть детализирована на бизнес-процессы.
4. Детализация бизнес-процессов осуществляется посредством бизнес –функций.
5. Описание элементарной бизнес–операции осуществляется с помощью миниспецификации.

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

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

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

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

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

Основные элементы процессного подхода

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

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

Каждый бизнес-процесс имеет свои границы и роли.

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

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

Лидер команды — работник, обладающий знаниями о бизнес-процессе и имеющий позитивные личные качества.

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

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

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

Одним из основных элементов процессного подхода является команда. Существует несколько типов процессных команд:

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

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

Ситуационный менеджер – высококвалифицированный специалист, способный самостоятельно выполнить до 90% объема работ.

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

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

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

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

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

Наиболее общими показателями оценки эффективности бизнес-процессов являются:

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

Выделение и классификация процессов

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

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

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

Наиболее распространены следующие четыре вида бизнес-процессов:

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

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

• основные;
• процессы управления;
• процессы обеспечения;
• сопутствующие;
• вспомогательные;
• процессы развития.

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

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

Рисунок 25. Упрощенная модель деятельности компании

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

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

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

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

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

Здесь тоже может быть применена своя матрица-генератор, как средство проверки полноты, — идентификация цикла.

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

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

• стратегическое управление;
• организационное проектирование (структуризация);
• маркетинг;
• финансово-экономическое управление;
• логистика и организация процессов;
• менеджмент качества;
• персонал.

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

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

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

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

1. сбор информации;

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

2. выработка решения;

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

3.реализация;

• планирование;
• организация;
• мотивация;
• координация;

4.контроль исполнения

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

5.анализ

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

6. регулирование

• регулирование на уровне реализации (возврат к п.3);
• регулирование на уровне выработки решения (возврат к п.1,2)

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

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

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

Рисунок 26. Двухуровневая модель деятельности предприятия

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

В основе цикла управления ресурсами лежит расчет или имитационное моделирование и контроль результатов:

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

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

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

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

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

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

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

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

Рисунок 27. Упрощенная матрица-генератор обеспечивающих бизнес-функций

Рисунок 28. Матрица-генератор обеспечивающих бизнес-функций

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

Референтная модель бизнес-процесса

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

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

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

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

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

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

1. Сводная информация о деятельности предприятия.

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

2. Регулярный документооборот предприятия.

1. Реестр входящей информации.
2. Реестр внутренней информации.
3. Реестр исходящей информации.

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

Списки вопросов для интервьюирования и анкетирования составляются по каждому обследуемому подразделению и утверждаются руководителем компании. Это делается с целью:

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

Общий перечень вопросов (с их последующей детализацией) включает следующие пункты:

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

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

• Каковы (с позиций вашего подразделения) должны быть цели создания интегрированной системы управления предприятием?
• Организационная структура подразделения.
• Задачи подразделения.
• Последовательность действий при выполнении задач.
• С какими типами внешних организаций (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается?
• Каким справочным материалом вы пользуетесь?
• Сколько времени (в минутах) вы тратите на исполнение основных операций? На какие даты приходятся "пиковые нагрузки"? (периодичность в месяц, квартал, год и т.д.) Техническое оснащение подразделения (компьютеры, сеть, модем и т.п.). Используемые программные продукты для автоматизации бизнес-процессов.
• Какие отчеты и как часто вы готовите для руководства? Ключевые специалисты подразделения, способные ответить на любые вопросы по бизнес-процессам, применяемым в подразделении.
• Характеристики удаленных объектов управления.
• Документооборот на рабочем месте.

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

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

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

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

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

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

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

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

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

Результатом предпроектного обследования является "Отчет об экспресс-обследовании предприятия", структура которого приведена ниже.

1. Краткое схематичное описание бизнес-процессов:

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

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

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

Операции бизнес-процесса

Описание документов бизнес-процесса

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

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

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

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

Вопросы для самопроверки:

1. Дайте определение термину «Процессные потоковые модели»?
2. Что такое лидер команды, коммуникатор, координатор процесса, владелец процесса, участник команды.
3. Что включает в себя подготовка и формирование команды?
4. Какие задачи должны решаться при процессном описании?

Методологии моделирования предметной области

Структурная модель предметной области

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

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

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

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

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

Структурный аспект предполагает построение:

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

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

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

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

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

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

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

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

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

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

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

Объектная структура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Организационная структура

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

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

На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

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

Техническая структура

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

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

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

На внутреннем уровне строится модель "клиент-серверной" архитектуры вычислительной сети.

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

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

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

Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.

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

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

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

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

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

Функционально-ориентированные и объектно-ориентированные методологии описания предметной области

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

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

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

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

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

Функциональная методика IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

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

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

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

• верхняя сторона имеет значение "Управление" (Control);
• левая сторона имеет значение "Вход" (Input);
• правая сторона имеет значение "Выход" (Output);
• нижняя сторона имеет значение "Механизм" (Mechanism).

Рисунок 29. Функциональный блок

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

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

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

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

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

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

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

Выделение подпроцессов. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели.

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

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

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

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

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

Что поступает в подразделение "на входе"?

• Какие функции и в какой последовательности выполняются в рамках подразделения?
• Кто является ответственным за выполнение каждой из функций?
• Чем руководствуется исполнитель при выполнении каждой из функций?
• Что является результатом работы подразделения (на выходе)?

На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

Функциональная методика потоков данных

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

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

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

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

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

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

Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.

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

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

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

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

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

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

Для простых процессов строится миниспецификация – формальное описание алгоритма преобразования входных данных в выходные.

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

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

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

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

К преимуществам методики DFD относятся:

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

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

Объектно-ориентированная методика

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

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

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

Основными понятиями объектно-ориентированного подхода являются объект и класс.

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

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

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

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

Объектно-ориентированный подход обладает следующими преимуществами:

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

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

Сравнение существующих методик

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

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

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

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

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

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

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

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

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

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

Синтетическая методика

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

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

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

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

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

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

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

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

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

Вопорсы  для самопроверки:

1. Каковы этапы анализа предметной области аис?
2. Что такое миссия компании?
3. Зачем проводится предпроектное обследование?
4. Назовите методологии моделирования деятельности организации при разработке АИС?
5. Что такое функциональный блок в методологии IDEF?
6. В чем заключается объектный подход к построению АИС?
7. Что подразумевают под инструментальными средствами CASE?
8. Что собой представляет референтная модель бизнес-процесса?
9. Что такое объектно-ориентированная методика и миниспецификации обработки?

РАЗДЕЛ 3. ЭФФЕКТИВНОСТЬ АИС

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

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

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

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

Качество разработанной АИС во многом зависит от того, как осуществлялись выявление и формулировка целей автоматизации:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При оценке эффективности АИС специалисты предлагают обратить внимание на разработанную в 1992 г. систему сбалансированных показателей Balanced Scorecard. Она применяется в основном для оценки эффективности управления предприятием. По мнению её создателей, представляет интерес использовать систему сбалансированных показателей для оценки эффективности автоматизированных информационных систем.

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

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

У=А/А мах,

где А – расчётная величина комплексного показателя качества системы (в балах);

А мах – постоянная величина = 6 баллам.

• от 0,75 до 1,00 – высокий уровень;
• от 0.35 до 0, 74 – достаточный (средний) уровень;
• от 0.00 до 0.34 – низкий уровень АИС.

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

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

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

Критериями  оценки качества информационных систем  являются:

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

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

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

Стандарты оценки качества информационных систем

Стандарт РФ ГОСТ Р ИСО/МЭК 9126—93. В отечественной практике разработки и сопровождения автоматизированных программных систем основным регламентирующим документом является ГОСТ Р ИСО/МЭК 9126-93.

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

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

Рассмотрим указанные характеристики качества программного обеспечения.

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

2. Надежность (Reliability) — набор атрибутов, относящийся к способности ПО сохранять свой уровень качества функционирования при установленных условиях за установленный период времени. Износ или старение программного обеспечения не происходит. Ограничения надежности возникают из-за ошибок в требованиях, проекте и реализации.
3. Практичность (Usability) — набор признаков, относящихся к объему работ, требуемых для использования и индивидуальной оценки такого использования определенным или предполагаемым кругом пользователей. «Пользователи» интерпретируются как большинство непосредственных пользователей интерактивного программного обеспечения. Круг пользователей может включать операторов, конечных пользователей и косвенных пользователей, на которых влияет данное ПО или которые зависят от его использования. Практичность должна рассматриваться во всем разнообразии условий эксплуатации пользователем, которые могут влиять на программное обеспечение, включая подготовку к использованию и оценку результатов.
4. Эффективность (Efficiency) — атрибуты, характеризующие соотношение между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях. Ресурсы могут включать другие программные продукты, технические средства, материалы (бумага, гибкие диски и пр.), услуги эксплуатирующего, сопровождающего или обслуживающего персонала, а также время, расходуемое на решение задач.
5. Сопровождаемость (Maintainability) — признаки, относящиеся к объему работ, требуемых для проведения конкретных изменений (модификаций). Изменения могут включать исправления, усовершенствование или адаптацию к окружающей обстановке, требованиям и условиям функционирования.
6. Мобильность (Portability) — атрибуты, характеризующие способность ПО быть перенесенным из одного окружения в другое. Окружение может включать организационное, техническое, программное, информационное окружения.

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

Таблица 6. Структура модели процесса оценивания ПО

Зарубежные стандарты. В настоящее время для оценки эффективности, качества и производительности информационных технологий существуют зарубежные системы стандартов, такие, как ESA, ISO 9000 или Baldride Award, IEC ТС (International Electrotechnical Commission Technical Committee 65C) и некоторые другие.

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

• EIAMUG — оценка параметров функционирования и управления системами;
• CCS — стандарты обработки данных в сетях;
• СММ — стандарты контроля и управления;
• FCS — стандарты оценки функциональных возможностей.

В рамках стандартов IEC ТС выполняются следующие работы:

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

Направления стандартизации IEC ТС:

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

В рамках указанных стандартов создаются стандартные тесты для оценки эффективности специальных информационных систем, например, стандартный тест PEMS — оценка качества и эффективности информационных технологий в медицине по системе IEC ТС 65С.

Методы осуществления стандартизации в рамках IEC ТС:

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

Методика разработки стандартов IEC ТС основана на большом опыте и анализе широкого спектра требований и методов работы различных организаций и фирм в разных странах Европы.

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

Стандарт ISO очень популярен в Европе. Сегодня стандартами охвачены многие технологические отрасли — от программирования и телекоммуникаций до банковской и финансовой сфер.

Создание стандартов проводится в соответствии с тремя принципами.

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

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

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

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

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

Некоторые стандарты ISO:

• ISO 8402. Управление качеством и гарантии качества;
• ISO 9001. Системная модель качества для процессов проектирования, разработки, производства, установки и обслуживания;
• ISO 9002. Системная модель качества для процессов проверки качества проектирования, установки и обслуживания;
• ISO 9003. Системная модель качества для процессов проверки качества при окончательном тестировании;
• ISO 10011-1, ISO 10011-2, ISO 10011-3. Руководство по аудиту качества систем;
• ISO 10012-1. Требования по качеству, предъявляемые к измерительной аппаратуре;
• ISO 10013. Руководство по созданию качественной документации.

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

Стандарт качества Baldridge Award. Объединение международных рынков, повышение требований к качеству и жесткая конкуренция привели к появлению параллельного стандарта качества Malcolm Baldrige National Quality Award (кратко Baldrige  Award), весьма популярного в США. Главная цель Baldrige Award — способствовать организациям в создании конкурентоспособных продуктов.

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

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

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

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

Контрольно-оценочные тесты классифицируются, как:

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

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

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

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

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

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

• Wenstone (1976 г.) и Dhrystone (1984 г.) — оценка пропускной способности системы. Комплексы тестов состоят из нескольких модулей, имитирующих нагрузку компьютерной системы в наиболее типичных режимах выполнения задач. Каждый модуль выполняется многократно, и в соответствии с исходной статистикой оценивается производительность;
• Linpac (1976 г.) — определение средней и предельной производительности системы. Тест имеет особую значимость при использовании компьютеров с векторной архитектурой и параллельной обработкой, т. е. дает характеристики глубины программного параллелизма вычислительной системы, определяет максимальные размеры обрабатываемых матриц и максимальную точность задач;
• Perfect — оценка производительности суперкомпьютеров, Unix-систем и рабочих станций. Осуществляет оптимизацию вычислительных и управляющих комплексов программ, обрабатывающих большие массивы информации, позволяет увеличить скорость обработки, выполняется дважды — до и после оптимизации программного комплекса;
• ТРС (1988 г., основан Комитетом по тестам производительности в составе компаний IBM, Control Data, Hewlett-Packard) — оценка производительности систем, а также характеристик стоимости приобретения и эксплуатации в течение 5 лет (цикл морального устаревания) компьютерного, серверного, периферийного оборудования и всего комплекса программного обеспечения. За основу взят стандарт Debit-Credit (1973 г., Bank of America).

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

Стандарты оценки качества программного обеспечения. Фирма Software Engineering Institute (SEI) предложила концепцию «Улучшение процессов создания ПО» (Software Process Improvement — SPI), которая опиралась на статистические методы контроля технологических процессов, разработанные в Японии в конце 30-х гг. Позднее появились другие концепции:

• «Сквозной контроль качества» (Total Quality Management — TQM);
• «Реинжиниринг бизнесс-процессов» (Business Process Reengineering — BPR), предполагающий модернизацию базовых бизнес-процессов организации;
• «Постепенное совершенствование деловых процессов» (Business Process Improvement — BPI).

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

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

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

Методология СММ. Университет Карнеги-Меллона под эгидой Министерства обороны США в 1987 г. разработал специальную систему оценки технологических процессов в организациях-разработчиках программного обеспечения. Предложенная ими модель уровней зрелости (Capability Maturity Model — СММ) основана на так называемых уровнях зрелости, среди которых можно выделить:

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

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

Модель оценки качества SCOPE*PROGEPT.B состав SCOPE*PROGEPT (разработчик — немецкий исследовательский центр GMD) входит несколько компонентов, соответствующих различным сторонам деятельности по созданию программ:

• специфицирование процессов тестирования (РгосеРТ);
• инжиниринг моделей качества (Model Y7), суть которого в определении модели качества для данного проекта с использованием методов оценки качества, что подразумевает встраивание этой модели в существующие технологические и бизнес-процессы;
• измерение характеристик (SIW), представляется в виде модели, на которой проводятся количественные исследования характеристик системы;
• моделирование процессов разработки (SPM) — данный компонент предназначен для оценки качества процессов разработки, причем на основе количественных показателей.

Модель оценки качества Trillium. Модель Trillium, созданная в 1994 г. фирмами Bell Canada, Nothern Telecom и Bell-Nothern Research, предлагает способ оценки процессов выпуска продуктов в телекоммуникационной и информационной областях, учитывающий все аспекты жизненного цикла ПО.

Моделью Trillium охвачены следующие виды деятельности:

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

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

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

Инструментом автоматизированного тестирования и оценки надежности ПО в методологии Cleanroom служит среда Cleanroorn Certification Assistant, в основе которой лежит идея использования статистических результатов тестирования для подсчета надежности ПО математическими методами. Компонент — Cleanroom Certification Model — фиксирует результаты тестирования в виде показателей среднего времени наработки на отказ, которые и используются для вычисления метрик надежности.

Другие модели оценки качества. Система Process-Weaver (компании Cap Gemini Innovation) позволяет автоматизировать процесс разработки с использованием терминов взаимозависимых заданий и совокупности входных/выходных данных, необходимых для реализации конкретной системы.

Также представляет интерес программа AMltool, созданная в Европейском центре ядерных исследований (CERN) и позволяющая с помощью метрики AMI (Application of Metrics In Industry) дать количественную оценку состояния фирмы, а также предлагающая план улучшения технологических процессов.

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

Основным элементом системы WIT является Дискуссионное окно (Discussion Area), соответствующее предметной области, в рамках которой ведется обсуждение. Внутри дискуссионного окна имеется набор Тем (Topics), связанный с определенными аспектами данной дискуссии. Участники дискуссии выражают свою точку зрения в виде Предложений (Proposals), которые передаются в WIT в форме сообщений.

На всех стадиях работы над проектом рождаются многочисленные документы (исходные требования, системные спецификации, исходные тексты программ, инструкции по эксплуатации и пр.), созданные различными специалистами. В крупных распределенных проектах, в которых задействованы большие коллективы разработчиков, обостряется проблема эффективного использования информационных материалов. Для ее решения была создана система LIGHT (Life cycle Global HyperTexT — глобальная гипертекстовая система для поддержки жизненного цикла ПО), которая, как и WIT, опирается на технологию WWW.

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

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

Вопорсы  для самопроверки:

1. Что означает понятие «эффективность?
2. В чем заключается цель разработки и эксплуатации АИС?
3. Где находят применение математические и другие модели, а также поддерживающие их программные комплексы?
4. Перечислите основные составляющие рационального управления.
5. Назовите основные характеристика качества функционирования АИС.
6. Назовите основные разделы документа «Расчет экономической эффективности».
7. В чем заключается суть методики оценки и расчета экономической эффективности создаваемой АИС?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Среди используемых организационных решений для ГУП можно отметить следующие:

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

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

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

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

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

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

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

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

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

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

После внедрения АИС, деятельность организации существенно зависит от нормальной работы системы. Поэтому большое значение приобретает качество сопровождения и поддержки поставщиком внедренного ПО. Косвенными показателями уровня качества поддержки могут выступать:

•  наличие у поставщика документарно-описанной политики по поддержке клиентов;

• тщательность проработки контракта на сопровождение и техническую поддержку;
• наличие отдельного подразделения, занимающегося техническим сопровождением;
• наличие специальных каналов связи (выделенные телефонные номера, адрес электронной почты, сайт, страницы в Интернет, посвященные поддержке);
• наличие специализированного ПО для автоматизации процесса приема и обработки проблем, возникающих у клиентов.

Таким образом, в частности, можно минимизировать или оптимизировать как финансовые затраты заказчика, так и трудовые (интеллектуальные, временные и др.) затраты разработчиков, поскольку объём программного кода практически отражает трудозатраты на разработку программы (число строк кода, человеко-дни и др.).

Приступая к разработке АИС, важно чётко разграничить цели, результаты и действия и соответственно определить области ответственности, в частности.

Очевидно, что основным вопросом организации труда при разработке АИС является организация труда разработчиков АИС. Важным элементом методологии программирования является принцип бригадной организации работ. Практическая реализация больших и средних программных проектов требует умения и опыта многих, входящих в бригаду, программистов. Выделяют три основные роли разработчиков:

1.архитектор проекта;

2.ответственные за подсистемы;

3.прикладные программисты.

Архитектор проекта отвечает за эволюцию и сопровождение архитектуры системы. Он не обязательно должен быть главным разработчиком, но обязан квалифицированно принимать стратегические решения, как правило, базируясь на имеющемся опыте построения подобных систем.

Руководитель (администратор, менеджер) проекта несёт ответственность за эффективное использование ресурсов и достижение результатов и не может нести прямую ответственность, например, за использование предоставляемых проектом услуг. Но он может осуществлять в течение определённого периода мониторинг связанных с этим рисков и допущений.

Архитекторы, хотя и должны уметь программировать, в первую очередь обязаны разбираться в принципах организации разработки АИС, а также весьма желательно, чтобы они владели принципами менеджмента.

Ответственные за подсистемы отвечают за проектирование конкретных модулей и подсистем. В сотрудничестве с архитектором проекта каждый из ответственных разрабатывает, обосновывает и согласовывает с другими разработчиками интерфейс своей подсистемы, а затем возглавляет её реализацию, тестирование и выпуск обновлений в течение развития системы. Они должны знать принятую систему обозначений и организацию процесса разработки АИС. Обычно они программируют лучше, чем архитекторы проекта, но не располагают столь обширным опытом. Ответственные за подсистемы составляют от трети до половины численности команды разработчиков.

Прикладные программисты – это младшие по рангу участники проекта. В основном они занимаются реализацией и последующим тестированием выполненных ими элементов подсистем и модулей. Они могут участвовать и в проектировании некоторых подсистем. Прикладные программисты должны быть хорошими программистами. Количественно они составляют не менее половины команды.

В больших проектах дополнительно в состав бригады могут входить и другие специалисты: менеджер проекта и интеграции, аналитик, инженер по повторному использованию, контролёр качества, ответственный за документацию, инструментальщик и др.

Менеджер проекта отвечает за управление материалами проекта, заданиями, ресурсами и графиком работ.

Аналитик отвечает за развитие и интерпретацию требований конечных пользователей. Он должен быть экспертом в предметной области, и его не следует изолировать от команды разработчиков.

Инженер по повторному использованию управляет хранилищем материалов проекта; активно ищет общее и добивается его использования; находит, разрабатывает или приспосабливает компоненты для общего использования.

Контролёр качества анализирует результаты процесса разработки; задаёт общее направление тестирования.

Менеджер интеграции отвечает за сборку подсистем в единое приложение и следит за конфигурированием подсистем.

Ответственный за документацию готовит для конечного пользователя документацию по выпускаемому продукту и его архитектуре.

Инструментальщик отвечает за создание и адаптацию инструментов программирования, которые облегчают создание программ.

Системный администратор управляет физическими компьютерными ресурсами в проекте.

Не каждый проект требует использования всех названных ролей. В не-больших проектах обязанности могут совмещаться. При этом в очень больших проектах каждой из ролей может заниматься отдельная организация.

Вопрос, который может возникнуть, как в самом начале проекта, так и на любой его фазе – осуществлять все работы своими силами или привлекать внешних консультантов? Привлечение консультантов (речь идёт о специалистах с соответствующей квалификацией и опытом работы) может увеличить первоначальные финансовые затраты на проект по выбору, но при этом значительно сокращается время на проведение работ и повышается качество их выполнения, а значит снижается риск их повторного выполнения, риск ошибок при принятии решений.

Качество разработки АИС напрямую зависит как от производительности, так и от квалификации разработчиков. Проблемы повышения качества программирования активно обсуждаются с конца 1960-х г. Оно включает ряд компонент, среди которых, например, одной из важных является снижение затрат на сопровождение АИС.

Существенный экономический эффект, высокое качество, сокращение сроков разработки АИС достигается применением интегрированного программно-математического обеспечения. Оно значительно упрощает процессы связывания и встраивания электронных документов, их передачи как внутри предприятия, так и другим информационным системам. Интегрированные программные системы максимально упрощают и эксплуатацию АИС, так как все задачи решаются с применением единообразного пользовательского интерфейса.

Значительно ускорить составление программ и облегчить их отладку можно, используя ранее составленные библиотеки стандартных, типовых модулей, а также средства автоматического проектирования программных продуктов. В этом случае CASE-средства служат также мощным инструментом решения исследовательских и проектных задач, связанных с начальными этапами разработки. К таким задачам относят: анализ предметной области, разработку проектных спецификаций, выпуск проектной документации, планирование и контроль разработок, моделирование деловых приложений, оперативного и стратегического планирования, управления ресурсами и т. п.

Экономическое обоснование необходимости разработки ИС

Важнейшей задачей является анализ экономической эффективности внедряемой системы. Ее своевременное решение дает возможность сравнивать различные варианты автоматизации и установить оптимальный вариант, оценить его влияние на изменение показателей деятельности организации.

Эффективность внедрения автоматизированной системы обуславливается действием ряда факторов организационного, информационного и экономического характера.
Организационный эффект проявляется в освобождение работников от рутинных операций по систематизации и группировке учетных данных, записей в реестры и другую документацию.
Информационный фактор эффективности выражается в повышение уровня информированности персонала.  

Экономический фактор проявляется в том, что учетная информация, имеющая целью полное и своевременное отражение и состояние объекта и причин, влияющих на его развитие, в конечном счете направлена на улучшение использование ресурсов.
Опыт эксплуатации комплексов задач показал, что в процессе автоматизации достигается снижение трудоемкости отдельных операций, рост производительности и улучшений условий труда отдельных работников, повышение оперативности достоверности, включая подготовку отчетности при постоянно растущем объеме без увеличения численности персонала и т.д.
Расчет затрат на разработку необходим для обоснования экономической эффективности системы. Плановые затраты на разработку включают все расходы, связанные с ее выполнением, независимо от источника их финансирования. Определение затрат на разработку производится путем составления калькуляции плановой себестоимости. Она является основным документом, на основании которого осуществляется планирование и учет затрат на выполнение

Смета затрат включает следующие статьи:

• основная заработная плата разработчиков информационной системы;
• дополнительная заработная плата разработчиков информационной системы;
• отчисления на социальные страхования;
• расчет затрат на амортизацию ЭВМ;
• расходы на электроэнергию, используемую при разработку информационной системы;
• накладные расходы.

Вопорсы  для самопроверки:

1.        Какие вопросы решаются при оценке качества спроектированной автоматизированной информационной системы?

2.        Критерии, применяемые при сравнении различного ПО.

3.        Какие показатели включает критерий технологичности разработки ПО?

4.        Чем отличается критерий «интегрируемость» от критерия «интегрированность»?

5.        Что можно сказать в отношении расчёта эффективности разрабатываемой АИС?

6.        Чем определяется эффективность АИС

7.        Как можно рассчитать уровень качества проектируемой АИС?

8.        Какие специалисты могут понадобиться для реализации больших проектов создания АИС?

9.        Основные роли разработчиков АИС.

10.   Как и когда осуществляется мониторингу проекта?

11.   Как можно повысить качество разработки АИС?

12.   Как можно повысить производительность труда разработчиков АИС?

ГЛОССАРИЙ

АСУ- автоматизированная система управления

АИС- автоматизированная информационная система

АИПС- автоматизированная информационно-поисковая система  

ОИС- офисная информационная система

ГИС- географическая информационная система

СИИ-системы искусственного интеллекта

АС - автоматизированная система;

АИС - автоматизированная  информационная система ;

ИС - информационные системы;

ЭС- экспертные системы

НСП- новое системное проектирование

ИТ- информационная технология

АИСЗ автоматизированная информационная система законодательства

ЮРИУС  юридическая универсальная информационная  система

ОИС офисные информационные системы

АРМ – автоматизированное рабочее место

РТС Российская торговая система

ГИС- географических информационных систем

ER – моделирование(сущность –связь

ЦММ- цифровых моделей местности)

АИС ВУЗ- автоматизированная информационная система высшего учебного заведения

АБИС- автоматизированные библиотечные информационные системы

STAIRS- система хранения и выдачи информации

Rational Rose- средство, предназначенное для автоматизации этапов  анализа и проектирования программного обеспечения

RAD (Rapid Application Development) – средство быстрой разработки Windows – приложений;

BPWIN- средство моделирования бизнес- процессов

CASE-средства (технологии) — программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.

IDEF0 (ICAM DEFinition) – метод анализа процессов взаимодействия в промышленных системах, обеспечивающий групповую работу над созданием модели с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта;

Erwin – среда  проектирование схемы БД, генерация ее описания на языке СУБД

Adabas – постреляционная система управления базами данных

LOTUS NOTES-  офисный комплекс

MRP-  методология потребности в материалах

ERP- система бизнес- планирования

MCP- планирование и контроль менеджмента