 |
|
Автоматизированные системы сбора, хранения и анализа информации
Автоматизированные информационные системы (АИС) относятся к классу сложных систем, как правило, не столько в связи с большой физической размерностью, сколько в связи с многозначностью структурных отношений между их компонентами. В рамках системного анализа сложные системы изучаются посредством разбиения на элементы: предполагается, что сложная система есть целое, состоящее из взаимосвязанных частей, которые не могут быть определены априорно, а строятся или выбираются в процессе декомпозиции (физической или концептуальной) исходной системы. Поэтому, прежде чем непосредственно перейти к изучению АИС, рассмотрим основные понятия и подходы к классификации информационных систем (ИС) вообще.
В настоящее время нет единого определения ИС и нет единой их классификации в связи с динамично протекающими процессами накопления знаний в области информационных технологий, поэтому приведем для сравнения наиболее существенные.
Информационная система - совокупность информационных, экономико-математических методов и моделей, технических, программных, технологических средств и специалистов, предназначенная для сбора, хранения, обработки и выдачи информации и принятия управленческих решений.
Информационная системаесть распространенное обозначение человеческого коллектива и процедур, а также разработанного, построенного, используемого и обслуживаемого оборудования для сбора, обработки, сохранения, извлечения и отображения информации.
Актуальной задачей в информационном плане на сегодняшний день для предприятий и корпораций всех организационных форм и видов собственности и в любой предметной области является обеспечение надежного управления всем объемом разнородных данных, которые порождаются, хранятся и используются в различных ИС, существующих на предприятии и связанных с информационной поддержкой продукции (услуг) в течение ее жизненного цикла. Разнообразие проблем, решаемых с помощью ИС, привело к появлению разнотипных систем, различающихся принципами построения и заложенными в них правилами обработки информации.
ИС можно классифицироватьпо различным признакам. В основу нижеприведенной классификации положен ряд существенных признаков, определяющих функциональные возможности и особенности построения современных систем; также принимались во внимание объем решаемых задач, используемых технических средств, организации функционирования и т.д.
По типу хранимых данных ИСделятся на фактографические и документальные. Фактографические системы предназначены для хранения и обработки структурированных данных в виде чисел и текстов. Над такими данными можно выполнять различные операции.
В документальных системах информация представлена в виде документов, состоящих из наименований, описаний, рефератов и текстов. Поиск по неструктурированным данным осуществляется с использованием семантических признаков. Отобранные документы предоставляются пользователю, а обработка данных в таких системах практически не производится.
Основываясь на степени автоматизации информационных процессовв системе управления фирмой (организацией), ИС делятся на ручные, автоматические и автоматизированные.
Ручные ИС характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком.
В автоматических ИС все операции по переработке информации выполняются без участия человека.
Автоматизированные И С предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль в выполнении рутинных операций обработки данных отводится компьютеру. Именно этот класс систем соответствует современному представлению понятий "информационная система" и "автоматизированная система".
Автоматизированная система (АС) - это система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию установленных функций.
Комплекс средств автоматизации (КСА) - совокупность всех компонентов АС, за исключением персонала.
Пользователь АС - лицо, участвующее в функционировании АС или использующее результаты ее функционирования.
В зависимости от характера обработки данныхАИС1 делятся на информационно-поисковые и информационно-решающие.
Информационно-поисковые системы производят ввод, систематизацию, хранение, выдачу информации по запросу пользователя без сложных преобразований данных. Например, ИС библиотечного обслуживания, резервирования и продажи билетов на транспорте, бронирования мест в гостиницах и пр.
Информационно-решающие системы осуществляют, кроме того, операции переработки информации по определенному алгоритму. По характеру использования выходной информациитакие системы принято делить на управляющие и советующие. Результирующая информация управляющих АИС непосредственно трансформируется в принимаемые человеком решения. Для этих систем свойственны задачи расчетного характера и обработка больших объемов данных, например АИС планирования производства или заказов, бухгалтерского учета. Советующие АИС вырабатывают информацию, которая принимается человеком к сведению и учитывается при формировании управленческих решений, а не инициирует конкретные действия. Эти системы имитируют интеллектуальные процессы обработки знаний, а не данных (например, экспертные системы).
В зависимости от сферы примененияразличают следующие классы АИС.
Системы организационного управления предназначены для автоматизации функций управленческого персонала как промышленных предприятий, так и непромышленных объектов (гостиниц, банков, магазинов и пр). Основными функциями подобных систем являются: оперативный контроль и регулирование, оперативный учет и анализ, перспективное и оперативное планирование, бухгалтерский учет, управление сбытом, снабжением и другие экономические и организационные задачи.
Системы управления технологическими процессами (ТП) служат для автоматизации функций производственного персонала по контролю и управлению производственными операциями. В таких системах обычно предусматривается наличие развитых средств измерения параметров технологических процессов (температуры, давления, химического состава и т.п.), процедур контроля допустимости значений параметров и регулирования технологических процессов.
Системы автоматизированного проектирования (САПР) предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники, сооружений или технологий. Основными функциями подобных систем являются: инженерные расчеты, создание графической документации (чертежей, схем, планов), создание проектной документации, моделирование проектируемых объектов.
Интегрированные (корпоративные) АИС используются для автоматизации всех функций фирмы (корпорации) и охватывают весь цикл работ - от планирования деятельности до сбыта продукции. Они включают в себя ряд модулей (подсистем), работающих в едином информационном пространстве и выполняющих функции поддержки соответствующих направлений деятельности.
Анализ современного состояния рынка АИС показывает устойчивую тенденцию роста спроса на информационные системы организационного управления. Причем продолжает расти спрос именно на интегрированные системы. Автоматизация отдельной функции, например, бухгалтерского учета или сбыта готовой продукции, считается уже пройденным этапом для многих предприятий.
В интегрированных АИС выделяют функциональные и обеспечивающие подсистемы. Функциональные подсистемы информационно обслуживают определенные виды деятельности, характерные для структурных подразделений предприятия или функций управления. Интеграция функциональных подсистем в единую систему достигается за счет создания и функционирования обеспечивающих подсистем.
Функциональная подсистема представляет собой комплекс задач с высокой степенью информационных обменов (связей) между задачами. При этом под задачей понимается некоторый процесс обработки информации с четко определенным множеством входной и выходной информации. Состав функциональных подсистем определяется характером и особенностями автоматизируемой деятельности, отраслевой принадлежностью, формой собственности, размером предприятия. Деление АИС на функциональные подсистемы может строиться по различным принципам:
• предметному;
• функциональному;
• проблемному;
• смешанному (предметно-функциональному).
При использовании предметного принципа выделяют подсистемы, отвечающие за управление отдельными ресурсами: управление сбытом, управление производством, управление финансами, управление персоналом и т.д. При этом в подсистемах рассматривается решение задач на всех уровнях управления, обеспечивая интеграцию информационных потоков по вертикали.
Применение функционального принципа предполагает выделение подсистем по направлениям деятельности: технико-экономическое планирование, бухгалтерский учет, анализ хозяйственной деятельности, перспективное развитие.
Состав обеспечивающих подсистем не зависит от конкретных функциональных подсистем и предметной области.
Рассмотренная классификация АИС с указанными выше классификационными признаками не является единственной. Приведем пример классификации, где в качестве основного классификационного признака рассматриваются особенности автоматизируемой профессиональной деятельности - процесса переработки входной информации для получения требуемой выходной.
В соответствии с названиями приведенных на рис.1 систем (аббревиатуры общеприняты среди специалистов по информационным технологиям и системам) нетрудно определить назначение и особенности каждой из них.
Рис.1. Классификация АИС с учетом особенностей автоматизируемой профессиональной деятельности:
АСУ - автоматизированные системы управления (П - персоналом, ТС - техническими средствами); СППР - системы поддержки принятия решения (Р - руководителя, О - должностного лица органа управления, Д - оперативного дежурного, Оп - оператора); АИВС - автоматизированные информационно-вычислительные системы; ИРС - информационно-расчетная система; САПР - система автоматизированного проектирования; МЦ - моделирующий центр; ПОИС - проблемно-ориентированная имитационная система; АИИС - автоматизированные информационно-справочные системы; АА - автоматизированные архивы; АСД - автоматизированные системы делопроизводства; АС - автоматизированные справочники и АК - автоматизированные картотеки; АСВЭК - автоматизированные системы ведения электронных карт; АСО - автоматизированные системы обучения; АСОДИ - автоматизированные системы обеспечения деловых игр; Т и ТК - тренажеры и тренажерные комплексы
Различают девять обеспечивающих подсистем или так называемое обеспечение АИС, в частности:
• информационное;
• лингвистическое;
• математическое;
• методическое;
• организационное;
• правовое;
• программное;
• техническое;
• эргономическое.
Ниже приведены тестированные определения каждого вида обеспечения, его компоненты и особенности.
Информационное обеспечение -совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в АИС при ее функционировании.
Информационное обеспечение включает:
• описание технологических процессов;
• описание организации информационной базы;
• описание входных потоков;
• описание выходных сообщений;
• описание систем классификации и кодирования;
• формы документов;
• описание структуры массивов.
Системы классификации позволяют группировать объекты, выделяя определенные классы, которые характеризуются рядом общих свойств. Классификаторы представляют собой систематизированные своды, перечни классифицируемых объектов и имеют определенное (обычно числовое) обозначение. Применяются государственные, отраслевые, региональные классификаторы. Например, классифицированы отрасли промышленности, оборудование, профессии, единицы измерения, статьи затрат и т.д.
Назначение классификаторов:
• систематизация наименований кодируемых объектов;
• однозначная интерпретация одних и тех же объектов в различных задачах;
• возможность обобщения информации по заданной совокупности признаков;
• возможность сопоставления одних и тех же показателей, содержащихся в формах статистической отчетности;
• возможность поиска и обмена информацией между подсистемами и внешними АИС;
• оптимизация использования ресурсов вычислительной техники при работе с кодируемой информацией.
Используются три метода классификации объектов, которые различаются стратегией применения классификационных признаков:
• иерархический;
• фасетный;
• дескрипторный.
Иерархический метод реализует достаточно жесткую процедуру построения структуры классификации. Предварительно определяется цель - набор свойств, которыми должны обладать классифицируемые объекты. Эти свойства полагают признаками классификации. В иерархической системе классификации каждый объект на любом уровне должен быть отнесен к одному классу, характеризуемому конкретным значением выбранного классификационного признака. Количество уровней классификации, соответствующее числу признаков, выбранных в качестве основания деления, характеризует глубину классификации.
Достоинства иерархической системы классификации: простота построения и использование независимых классификационных признаков в различных ветвях иерархической структуры.
Недостатками этой системы являются жесткая структура, осложняющая внесение изменений, так как это приводит к перераспределению классификатора, и невозможность группировать объекты по заранее не предусмотренным сочетаниям признаков.
При использовании фасетного метода классификации допустимо выбирать признаки классификации независимо как друг от друга, так и от семантического содержания классифицируемого объекта. Признаки классификации называются фасетами (Гасе1 - рамка). Каждый фасет содержит совокупность однородных значений данного классификационного признака, причем значения в фасете могут располагаться в произвольном порядке, хотя предпочтительнее их упорядочение. Схема построения фасетной системы классификации представляется в виде таблицы. Названия столбцов соответствуют выделенным классификационным признакам (фасетам). В каждой клетке таблицы хранится конкретное значение фасета. Процедура классификации состоит в присвоении каждому объекту соответствующих значений из фасетов.
Достоинства фасетной системы классификации: возможность создания большой емкости классификации, т.е. использования большого числа признаков классификации и их значений для создания группировок; возможность простой модификации всей системы классификации без изменения структуры существующих группировок.
Недостатком системы является сложность ее построения, так как необходимо учитывать все многообразие классификационных признаков.
Для организации поиска информации, для ведения тезаурусов (словарей) эффективно используется дескрипторная (описательная) система классификации, язык которой приближается к естественному языку описания информационных объектов. Особенно широко она используется в библиотечной системе поиска.
Системы классификации принципиально отличаются от систем кодирования в соответствии с определением.
Система кодирования - совокупность правил кодового обозначения объектов. 'Код строится на базе алфавита, состоящего из букв, цифр и других символов. Код характеризуется: длиной - число позиций в коде, и структурой - порядок расположения в коде символов, используемых для обозначения классификационного признака.
Кодирование применяется для замены названия объекта на условное обозначение (код) в целях обеспечения удобной и более эффективной обработки информации.
Унифицированные системы документации создаются на государственном, отраслевом и региональном уровнях. Главная цель их использования - обеспечение сопоставимости показателей различных сфер общественного производства. Разработаны стандарты, где устанавливаются требования к:
• унифицированным системам документации;
• унифицированным формам документов различных уровней управления;
• составу и структуре реквизитов и показателей;
• порядку внедрения, ведения и регистрации унифицированных форм документов.
Однако, несмотря на существование унифицированной системы документации, при обследовании большинства организаций постоянно выявляют типичные недостатки:
• чрезвычайно большой объем документов для ручной обработки;
• одни и те же показатели часто дублируются в разных документах;
• работа с большим количеством документов отвлекает специалистов от решения непосредственных задач;
• наличие показателей, которые создаются, но не используются, и др.
Устранение указанных недостатков является одной из задач, стоящих при создании информационного обеспечения.
Схемы информационных потоков отражают маршруты движения информации, ее объемы, места возникновения и использования. Анализ таких схем позволяет выработать меры по совершенствованию всей системы управления.
Для создания информационного обеспечения необходимо:
• ясное понимание целей, задач, функций всей системы управления организацией;
• выявление движения информации от момента возникновения и до ее использования на различных уровнях управления, представленной для анализа в виде схем информационных потоков;
• совершенствование системы документооборота;
• наличие и использование системы классификации и кодирования;
• владение методологией создания концептуальных информационно-логических моделей, отражающих взаимосвязь информации;
• создание массивов информации на машинных носителях, что требует наличия современного технического обеспечения.
Лингвистическое обеспечение -совокупность средств и правил для формализации естественного языка, используемых при общении пользователей и эксплуатационного персонала АИС с комплексом средств автоматизации при функционировании АИС.
Языковые средства лингвистического обеспечения делятся на две группы: традиционные языки (естественные, математические, алгоритмические, моделирования) и языки, предназначенные для диалога с ЭВМ.
Математическое обеспечение -совокупность математических методов, моделей и алгоритмов, применяемых в АИС.
В состав математического обеспечения входят:
• средства математического обеспечения (средства моделирования типовых задач управления, методы многокритериальной оптимизации, математической статистики, теории массового обслуживания и др.);
• техническая документация (описание задач, алгоритмы решения задач, экономико-математические модели);
• методы выбора математического обеспечения (методы определения типов задач, методы оценки вычислительной сложности алгоритмов, методы оценки достоверности результатов).
Методическое обеспечение -совокупность документов, описывающих технологию функционирования АИС, методы выбора и применения пользователями технологических приемов для получения конкретных результатов при функционировании АИС.
Организационное обеспечение -совокупность документов, устанавливающих организационную структуру, права и обязанности пользователей и эксплуатационного персонала АИС в условиях функционирования, проверки и обеспечения работоспособности АИС.
Организационное обеспечение реализует следующие функции:
• анализ существующей системы управления предприятием (организацией), где используется АИС, выявление задач, подлежащих автоматизации;
• подготовку задач к автоматизации, включая разработку технических заданий и технико-экономических обоснований эффективности;
• разработку управленческих решений по изменению структуры организации и методологий решения задач, направленных на повышение эффективности системы управления.
Организационное обеспечение включает:
• методические материалы, регламентирующие процесс создания и функционирования АИС;
• совокупность средств для эффективного проектирования и функционирования АИС;
• техническую документацию, получаемую в процессе обследования предприятия, проектирования, внедрения и сопровождения системы;
• персонал (организационно-штатные структуры предприятия), проектирующий, внедряющий, сопровождающий и использующий ИС.
Правовое обеспечение -совокупность правовых норм, регламентирующих правовые отношения при функционировании АИС и юридический статус результатов ее функционирования. Примечание: правовое обеспечение реализуется в организационном обеспечении АИС.
В состав правового обеспечения входят законы, указы, постановления государственных органов власти; приказы, инструкции и другие нормативные документы министерств, ведомств, организаций, местных органов власти. В правовом обеспечении можно выделить общую часть, регулирующую функционирование любой ИС, и локальную часть, регулирующую функционирование конкретной системы.
Правовое обеспечение разработки АИС включает нормативные акты, связанные с договорными отношениями разработчика и заказчика и правовым регулированием отклонений от договора.
Правовое обеспечение функционирования АИС включает:
• статус АИС;
• права, обязанности и ответственность персонала;
• правовые положения отдельных видов процесса управления;
• порядок создания и использования информации.
Программное обеспечение -совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АИС.
К программному обеспечению АИС относят:
• программное обеспечение, специально разработанное в рамках автоматизации, реализующее разработанные модели разной степени адекватности, отражающие функционирование реального объекта;
• программное обеспечение общего назначения, предназначенное для решения типовых задач обработки информации.
Техническая документация на разработку программных средств должна содержать описание задач, задание на алгоритмизацию, экономико-математическую модель задачи, контрольные примеры.
Техническое обеспечение -совокупность всех технических средств, используемых при функционировании АИС.
К техническим средствам относят:
• используемую вычислительную технику разного назначения (серверы, рабочие станции);
• специальные устройства сбора, накопления, обработки, передачи и вывода информации;
• устройства передачи данных и линии связи;
• устройства автоматического съема информации;
• оргтехнику, эксплуатационные материалы и т.д.
Выбор технических средств, организация их эксплуатации, технологический процесс обработки данных, технологическое оснащение документально оформляются.
Документацию технического обеспечения можно условно разделить на группы:
• общесистемная документация, включающая государственные и отраслевые стандарты по техническому обеспечению;
• специализированная документация, содержащая комплекс методик по всем этапам разработки технического обеспечения;
• нормативно-справочная документация, используемая при выполнении расчетов по техническому обеспечению.
Эргономическое обеспечение -совокупность реализованных решений в АИС по согласованию психологических, психофизиологических, антропометрических, физиологических характеристик и возможностей пользователей АИС с техническими характеристиками комплекса средств автоматизации АИС и параметрами рабочей среды на рабочих местах персонала АИС.
Охрана здоровья трудящихся, обеспечение безопасности условий труда, ликвидация профессиональных заболеваний и производственного травматизма составляют одну из главных забот человеческого общества. Обращается внимание на необходимость широкого применения прогрессивных форм научной организации труда, сведения к минимуму ручного, малоквалифицированного труда, на создание обстановки, исключающей профессиональные заболевания и производственный травматизм.
Архитектура АИС. Термин "архитектура" применительно к вычислительным системам появился задолго до создания первых АИС, тем не менее он является одним из основополагающих и в сфере информационных технологий. Существуют различные подходы к определению архитектуры АИС, различные точки зрения и различная степень детализации рассмотрения; приведем некоторые из них.
Согласно архитектура -это организационная структура автоматизированной системы. Известно и другое определение: архитектура -это концептуальное описание структуры системы, включающее описание элементов системы, их взаимодействия и внешних свойств. Выделяют два уровня архитектуры АИС:
• бизнес-архитектуру (бизнес-уровень);
• уровень информационных технологий (технический уровень).
Бизнес-архитектура обычно первична по отношению к техническому уровню; может существовать и реализуема вне зависимости от существования АИС. Бизнес-архитектура является предметной областью для анализа и проведения автоматизации. На бизнес-уровне определяется набор задач, требований, характеристик, осуществляемых с помощью АИС. Соответствие указанному уровню технического уровня является основой эффективности функционирования АИС.
С другой стороны, новые возможности, предоставляемые использованием информационных технологий, стимулируют развитие и корректировку бизнес-архитектуры, в связи с чем она является неотъемлемой частью архитектуры АИС и всего предприятия.
Уровень информационных технологий или технический уровень представляет собой интегрированный комплекс технических средств, используемых в АИС для реализации задач предприятия, и включает в себя как логические, так и технические (программные и аппаратные) компоненты. Компонентами этого уровня, в свою очередь, являются следующие подуровни:
• архитектура программных систем;
• информационная архитектура;
• технологическая (инфраструктурная) архитектура.
Информационная архитектура представляет собой логическую организацию данных, с которыми работает АИС, т.е. практически структуры баз данных и баз знаний, а также принципы их взаимодействия.
Под архитектурой программных систем понимают совокупность следующих технических решений:
• общий архитектурный стиль и общую организацию программной части АИС;
• деление программного комплекса на функциональные подсистемы и модули;
• свойства модулей, методы их взаимодействия и объединения, используемые интерфейсы.
Архитектура программной системы охватывает не только структурные и поведенческие аспекты, но и правила ее использования и интеграции с другими системами, функциональность, производительность, гибкость, надежность, эргономичность, технологические ограничения.
Технологическая архитектура описывает инфраструктуру, используемую для передачи данных. На этом уровне решаются вопросы сетевой структуры, применяемых каналов связи и т.д.
По мере развития программных систем все большее значение приобретает их комплексная интеграция для построения единого информационного пространства предприятия. Обеспечение такой интеграции является важнейшим элементом архитектуры, в противном случае АИС окажется неэффективной.
Жизненный цикл АИС.Одним из базовых понятий методологии проектирования АИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
По аналогии правомерно будет утверждать, что жизненный цикл АИС есть непрерывный процесс с момента принятия решения о необходимости ее создания до полного завершения ее эксплуатации. Продолжительность жизненного цикла современных АИС составляет около 10 лет, что значительно превышает сроки морального и физического старения технических и системных программных средств, используемых при реализации АИС. Поэтому, как правило, в течение ЖЦ системы проводится ее модернизация, после чего все функции системы должны выполняться с не меньшей эффективностью.
Добиться этого на протяжении всего ЖЦ АИС - довольно сложная по ряду объективных и субъективных причин задача, в результате подавляющее большинство проектов АИС внедряется с нарушениями качества, сроков или сметы; почти треть проектов прекращают свое существование незавершенными.
Из мировой практики известно, что затраты на сопровождение прикладного программного обеспечения АИС составляют не менее 70% его совокупной стоимости на протяжении ЖЦ, поэтому крайне важно еще на проектной стадии предусмотреть необходимые методы и средства сопровождения, включая методы конфигурационного управления.
Среди основных процессовжизненного цикла самыми важными являются разработка, эксплуатация и сопровождение. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами.
Разработка АИС включает все работы по созданию программного обеспечения и его компонентов в соответствии с заданными требованиями. Этот процесс также предусматривает:
• оформление проектной и эксплуатационной документации;
• подготовку материалов, необходимых для тестирования разработанных программных продуктов;
• разработку материалов, необходимых для обучения персонала.
Как правило, составляющими процесса разработки являются стратегическое планирование, анализ, проектирование и реализация (программирование).
К процессу эксплуатации относятся:
• конфигурирование базы данных и рабочих мест пользователей;
• обеспечение пользователей эксплуатационной документацией;
• обучение персонала.
Основные эксплуатационные работы включают:
• непосредственно эксплуатацию;
• локализацию проблем и устранение причин их возникновения;
• модификацию программного обеспечения;
• подготовку предложений по совершенствованию системы;
• развитие и модернизацию системы.
Профессиональное, грамотное сопровождение - необходимое условие решения задач, выполняемых АИС. Службы технической поддержки играют весьма заметную роль в жизни любой АИС. Ошибки на этом этапе могут привести к явным или скрытым финансовым потерям, сопоставимым со стоимостью самой системы.
К предварительным действиям при организации технического обслуживания АИС относятся:
• выделение наиболее ответственных узлов системы и определение для них критичности простоя (это позволит выделить наиболее критичные составляющие АИС и оптимизировать распределение ресурсов для технического обслуживания);
• определение задач технического обслуживания и их разделение на внутренние, решаемые силами обслуживающего подразделения, и внешние, решаемые специализированными сервисными организациями (таким образом четко ограничивается круг исполняемых функций и производится распределение ответственности);
• проведение анализа имеющихся внутренних и внешних ресурсов, необходимых для организации технического обслуживания в рамках описанных задач и разделения компетенции (основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалификация персонала);
• подготовка плана организации технического обслуживания с определением этапов исполняемых действий, сроков их исполнения, затрат на этапах, ответственности исполнителей.
Обеспечение качественного технического обслуживания АИС требует привлечения специалистов высокой квалификации, которые в состоянии решать не только ежедневные задачи администрирования, но и быстро восстанавливать работоспособность системы при сбоях и авариях.
Среди вспомогательных процессоводним из главных является управление конфигурацией, которое поддерживает основные процессы жизненного цикла АИС, прежде всего процессы разработки и сопровождения.
Разработка сложных АИС предполагает независимую разработку компонентов системы, что приводит к появлению многих вариантов и версий реализации как отдельных компонентов, так и системы в целом. Таким образом, возникает проблема обеспечения сохранения единой структуры в ходе разработки и модернизации АИС. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты АИС на всех стадиях ее ЖЦ.
Организационные процессыимеют очень большое значение, так как современные АИС - это большие комплексы, в создании и обслуживании которых занято много людей разных специальностей.
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков, контроля сроков и качества выполнения работ. Техническое и организационное обеспечение проекта включает:
• выбор методов и инструментальных средств реализации проекта;
• определение методов описания состояния процесса разработки;
• разработку методов и средств испытаний созданного программного обеспечения;
• обучение персонала.
Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов АИС.
Верификация - процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа.
Проверка - процесс определения соответствия параметров разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое проводится для определения различий между действительными и ожидаемыми результатами, а также для оценки соответствия характеристик АИС исходным требованиям.
Модели жизненного цикла АИС. Рассмотренные выше процессы характеризуются определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. При этом ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах. Известные модели ЖЦ ПО (каскадная, итерационная, спиральная) определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу.
По аналогии с известным определением модели ЖЦ ПО и в соответствии с устоявшейся среди специалистов терминологией, приведем определение модели ЖЦ АИС.
Модель жизненного цикла АИС -это структура, описывающая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения в течение всего жизненного цикла системы.
Модель ЖЦ АИС отражает состояние системы с момента осознания необходимости создания данной АИС до полной ее утилизации. Выбор модели жизненного цикла зависит от специфики, масштаба, сложности проекта и набора условий, в которых АИС создается и функционирует. Модель ЖЦ АИС включает:
• стадии;
• результаты выполнения работ на каждой стадии;
• ключевые события или точки завершения работ и принятия решений.
В соответствии с известными моделями ЖЦ ПО определяют модели ЖЦ АИС - каскадную, итерационную, спиральную. Ниже подробно рассмотрена каждая из них.
Каскадная модельописывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970-80-х гг. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различных отраслях в связи с наличием теоретического обоснования, промышленных методик и стандартов, а также успешного использования модели в течение десятилетий.
Каскадная модель предусматривает последовательную организацию работ, причем основной особенностью модели является разбиение всей работы на этапы. Переход от предыдущего этапа к последующему происходит только после полного завершения всех работ предыдущего. Каждый этап завершается выпуском полного комплекта документации для того, чтобы иметь возможность при необходимости всегда продолжить разработку.
Периодически названия стадий разработки в каскадной модели менялись; кроме того, в каждый период времени регламент приписывания определенных работ к конкретным этапам никогда не являлся жестким и однозначным. Тем не менее выделяют пять устойчивых этапов разработки, практически не зависящих от предметной области.
На первом этапе проводится исследование проблемной области, формулируются требования заказчика. Результатом данного этапа является техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами.
В ходе второго этапа, согласно требованиям технического задания, разрабатываются те или иные проектные решения. В результате появляется комплект проектной документации.
Третий этап - реализация проекта; по существу, разработка программного обеспечения (кодирование) в соответствии с проектными решениями предыдущего этапа. Методы реализации при этом принципиального значения не имеют. Результатом выполнения этапа является готовый программный продукт.
На четвертом этапе проводится проверка полученного программного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная эксплуатация позволяет выявить различного рода скрытые недостатки, проявляющиеся в реальных условиях работы АИС.
Последний этап - сдача готового проекта, и главное здесь - убедить заказчика в том, что все его требования выполнены в полной мере.
Этапы работ в рамках каскадной модели часто называют частями проектного цикла АИС, поскольку этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решений. ЖЦ АИС существенно сложнее и длиннее: он может включать в себя произвольное число циклов уточнения, изменения и дополнения уже принятых и реализованных проектных решений. В этих циклах происходит развитие АИС и модернизация отдельных ее компонентов.
Каскадная модель получила широкое распространение не только среди специалистов, так как обладает достоинствами, проявляющимися при выполнении различных разработок. Ниже приведены основные:
1) на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах разрабатывается пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения АИС (организационное, информационное, программное, техническое и т.д.);
2) последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты.
Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значения для прикладной области до настоящего времени. Кроме того, каскадный подход идеально подходит для разработки АИС, так как уже в самом начале разработки можно достаточно точно и полно сформулировать все требования с тем, чтобы предоставить разработчикам свободу технической реализации. К таким АИС, в частности, относятся сложные расчетные системы и системы реального времени.
Тем не менее модель имеет ряд недостатков, ограничивающих ее применение:
• существенная задержка в получении результатов;
• ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата;
• сложность параллельного ведения работ по проекту;
• чрезмерная информационная перенасыщенность каждого из этапов;
• сложность управления проектом;
• высокий уровень риска и ненадежность инвестиций.
Задержка в получении результатов проявляется в том, что при последовательном подходе к разработке согласование результатов с заинтересованными сторонами производится только после завершения очередного этапа работ. В результате может оказаться, что разрабатываемая АИС не соответствует требованиям, и такие несоответствия могут возникать на любом этапе разработки; кроме того, ошибки могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они не обязаны хорошо разбираться в тех предметных областях, для которых разрабатывается АИС.
Кроме того, используемые при разработке АИС модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, в силу различных причин могут устареть за время разработки (например, из-за внесения изменений в законодательство).
Возврат на более ранние стадии. Этот недостаток является одним из проявлений предыдущего: поэтапная последовательная работа над проектом может привести к тому, что ошибки, допущенные на более ранних этапах, обнаруживаются только на по следующих стадиях. В результате проект возвращается на предыдущий этап, перерабатывается и только затем передается в последующую работу. Это может послужить причиной срыва графика и усложнения взаимоотношений между группами разработчиков, выполняющих отдельные этапы.
Самый плохой вариант, когда недоработки предыдущего этапа обнаруживаются не на следующем этапе, а позднее. Например, на стадии опытной эксплуатации могут проявиться ошибки в описании предметной области. Это означает, что часть проекта должна быть возвращена на начальный этап работы. Вообще, работа может быть возвращена с любого этапа на любой предыдущий.
Одной из причин возникновения данной ситуации является то, что в качестве экспертов, участвующих в описании предметной области, часто выступают будущие пользователи системы, которые иногда не могут четко сформулировать требования к АИС. Кроме того, заказчики и исполнители часто неправильно понимают друг друга, так как заказчики далеки от программирования, а исполнители обычно не являются специалистами в предметной области.
Сложность параллельного ведения работ связана с необходимостью постоянного согласования различных частей проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще и тщательнее должна выполняться синхронизация, тем сильнее зависят друг от друга группы разработчиков. В результате преимущества параллельного ведения работ просто теряются;
отсутствие параллелизма негативно сказывается и на организации работы всего коллектива.
В частности, пока производится анализ предметной области, проектировщики, разработчики и те, кто занимается тестированием и администрированием, почти не загружены. Кроме того, при последовательной разработке крайне сложно внести изменения в проект после завершения этапа и передачи проекта на следующую стадию. Так, если после передачи проекта на следующий этап группа разработчиков нашла более эффективное решение, оно не может быть реализовано, поскольку предыдущее решение уже, возможно, реализовано и увязано с другими частями проекта.
Проблема информационной перенасыщенности возникает вследствие сильной зависимости между различными группами разработчиков. Дело в том, что при внесении изменений в одну из частей проекта, необходимо оповещать тех разработчиков, которые использовали (могли использовать) ее в своей работе. При наличии большого числа взаимосвязанных подсистем синхронизация внутренней документации становится отдельной важнейшей задачей: разработчики должны постоянно знакомиться с изменениями и оценивать, как скажутся (или уже сказались) эти изменения на полученных результатах.
В итоге может потребоваться повторное тестирование и внесение изменений в уже готовые части проекта. Причем эти изменения, в свою очередь, необходимо отразить во внутренней документации и разослать другим группам разработчиков. Как следствие, резко возрастет объем документации и, соответственно, понадобится больше времени для ознакомления с ней.
Помимо изучения нового материала, не отпадает необходимость и в изучении старой информации. Ведь вполне вероятно, что в процессе разработки изменится кадровый состав и новым разработчикам понадобится информация о сделанном ранее. Причем, чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела.
Сложность управления проектом в основном обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между различными частями проекта. Регламентированная последовательность работ приводит к тому, что одни группы разработчиков должны ожидать результатов работы других команд, поэтому требуется административное вмешательство для согласования сроков и состава передаваемой документации.
В случае же обнаружения ошибок в работе необходим возврат к предыдущим этапам; текущая работа тех, кто ошибся, прерывается. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов.
Упростить взаимодействие между разработчиками и уменьшить информационную перенасыщенность документации можно, сокращая количество связей между отдельными частями проекта, но далеко не каждую АИС можно разделить на слабо связанные подсистемы.
Высокий уровень риска. Чем сложнее проект, тем дольше длится каждый этап разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, т.е. после завершения анализа, проектирования и разработки - этапов, выполнение которых требует значительного времени и средств.
Запоздалая оценка порождает серьезные проблемы при выявлении ошибок анализа и проектирования - требуется возврат на предыдущие стадии и повторение процесса разработки. Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими в предметной области или в требованиях заказчика за время разработки. При этом никто не гарантирует, что предметная область снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность "зацикливания" процесса разработки: расходы на проект будут постоянно расти, а сроки сдачи готового продукта постоянно откладываться.
Помимо приведенных недостатков каскадной модели есть еще один. Он связан с возникновением конфликтов (не всегда явных) между разработчиками, которые обусловлены тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском виновных. Поскольку однозначно персонифицировать виноватого не всегда возможно, отношения в коллективе усложняются.
Как следствие, в рабочей группе часто ценится не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет "отстоять" своих подчиненных, обеспечить им более удобные условия работы и т.п. В результате появляется опасность снижения и квалификации, и творческого потенциала всей команды. Соответственно, техническое руководство проектом начинает в большей степени подменяться организационным, более детальной проработкой должностных инструкций и более формальным их исполнением.
Тот, кто не умеет организовать работу, обречен бороться за дисциплину. И здесь возникает проблема несовместимости дисциплины и творчества. Чем строже дисциплина, тем менее творческой становится атмосфера в коллективе. Такое положение вещей может привести к тому, что наиболее одаренные кадры со временем покинут коллектив.
Построение итерационной моделизаключается в серии коротких циклов (шагов) по планированию, реализации, изучению, действию.
Создание сложных АИС предполагает проведение согласований проектных решений, полученных при реализации отдельных задач. Подход к проектированию "снизу - вверх" обусловливает необходимость таких итераций возвратов, когда проектные решения по отдельным задачам объединяются в общие системные решения. При этом возникает потребность в пересмотре ранее сформировавшихся требований.
Преимущество итерационной модели в том, что межэтапные корректировки обеспечивают меньшую трудоемкость разработки по сравнению с каскадной моделью.
Недостатки итерационной модели:
• время жизни каждого этапа растягивается на весь период разработки;
• вследствие большого числа итераций возникают рассогласования выполнения проектных решений и документации;
• запутанность архитектуры;
• трудности использования проектной документации на стадиях внедрения и эксплуатации вызывают необходимость перепроектирования всей системы.
Спиральная модель,в отличие от каскадной, но аналогично предыдущей предполагает итерационный процесс разработки АИС. При этом возрастает значение начальных этапов, таких как анализ и проектирование, на которых проверяется и обосновывается реализуемость технических решений путем создания прототипов.
Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой.
Таким образом, каждый виток спирали соответствует созданию фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы на следующем витке спирали. Каждая итерация служит для углубления и последовательной конкретизации деталей проекта, в результате этого выбирается обоснованный вариант окончательной реализации.
Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения текущего, - недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации - как можно быстрее создать работоспособный продукт для демонстрации пользователям. Таким образом, существенно упрощается процесс внесения уточнений и дополнений в проект.
Спиральный подход к разработке программного обеспечения позволяет преодолеть большинство недостатков каскадной модели и, кроме того, обеспечивает ряд дополнительных возможностей, делая процесс разработки более гибким.
Преимущества итерационного подхода:
• итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;
• при использовании спиральной модели отдельные элементы АИС интегрируются в единое целое постепенно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (при использовании каскадной модели интеграция занимает до 40% всех затрат в конце проекта);
• снижение уровня рисков (следствие предыдущего преимущества, так как риски обнаруживаются именно во время интеграции). Уровень рисков максимален в начале разработки проекта, по мере продвижения разработки он снижается. Данное утверждение справедливо при любой модели разработки, однако при использовании спиральной снижение уровня рисков происходит с наибольшей скоростью, так как интеграция выполняется уже на первой итерации. На начальных итерациях выявляются многие аспекты проекта (пригодность используемых инструментальных средств, программного обеспечения, квалификация разработчиков и т.п.);
• итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие. Так, можно сократить сроки разработки за счет снижения функциональности системы или использовать в качестве составных частей продукцию сторонних фирм вместо собственных разработок (актуально при рыночной экономике, когда необходимо противостоять продвижению изделия конкурентов);
• итерационный подход упрощает повторное использование компонентов, поскольку гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после нескольких начальных итераций позволяет выявить общие многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться;
• спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно корректируются критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы;
• итерационный подход позволяет совершенствовать процесс разработки - в результате анализа в конце каждой итерации проводится оценка изменений в организации разработки; на следующей итерации она улучшается.
Основная проблема спирального цикла - трудность определения момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Иначе процесс разработки может превратиться в бесконечное совершенствование уже сделанного.
При итерационном подходе полезно следовать принципу "лучшее - враг хорошего". Поэтому завершение итерации должно производиться строго в соответствии с планом, даже если не вся запланированная работа закончена. Планирование работ обычно проводится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.