Свойство рототабельности:
–
дисперсия
по ротору
Свойство рандомизации
Рандомизация – процедура планирования, когда опыты ставятся случайным и независимым образом. При этом достигается то, что систематическая погрешность переводится в разряд случайной, т.е. систематическая погрешность исключается.
Виды обеспечения асу.
АСУ – автоматизированная система управления, человеко-машинная система, в управлении которой человек принимает непосредственное участие наряду с техническими средствами и является звеном этой системы. Управление делается для оптимизации того или иного процесса.
Состав АСУ
Под составом АСУ понимаются виды обеспечения АСУ:
1. Организационное
2. Информационное
3. Математическое
4. Программное
5. Техническое
6. Лингвистическое
7. Метрологическое
8. Правовое.
Организационное обеспечение – документы, определяющие функции подразделений управления, действия и взаимодействия персонала АСУ.
Информационное обеспечение – классификаторы, технико-экономическая информация, формы представления и организации данных в системах, в том числе, формы документов, видеограмм, массивов (протоколы обмена данными).
Математическое обеспечение – совокупность математических методов, моделей и алгоритмов для решения задач и обработки информации с применением средств вычислительной техники. Математическое обеспечение в АСУ, как правило, реализуется через ПО. Математическое обеспечение включает в себя следующие основные части:
1. Математические модели ТОУ.
2. Алгоритмы первичной обработки информации.
3. Вычисление обобщенных показателей процесса и не измеряемых величин.
4. Оптимальное управление технологическими процессами, которое включает в оптимальную постановку задачи и методы их решения.
Программное обеспечение – программы с документацией на них, необходимые для реализации всех функций АСУ в объеме предусмотренном ТЗ.
ПО принято подразделять на:
1) общее;
2) специальное;
3) тестовое.
Техническое обеспечение – технические средства необходимые для реализации функций АСУ.
В общем случае техническое обеспечение включает:
1) средства получения, ввода, подготовки, преобразования, обработки информации и т.п.
2) средства реализации управляющих воздействий.
Лингвистическое обеспечение – тезаурусы и языки описания и манипулирования данными.
Метрологическое обеспечение – метрологические средства и инструкции по их применению.
Правовое обеспечение - нормативные документы, определяющие правовой статус АСУ, персонала АСУ, правил функционирования АСУ и нормативы на автоматически формируемые документы, в том числе, на машинных носителях информации.
Структуры АСУ
В АСУ принято выделять 6 структур. Каждая структура характеризуется составляющими: элемент и связи.
1. Функциональная:
Элемент – функции, задачи, операции.
Связи – информация.
2. Техническая:
Элемент – устройства.
Связи – линии связи.
3. Организационная:
Элемент – коллективы людей и отдельные исполнители.
Связи – информационные связи.
4. Алгоритмическая:
Элемент – алгоритмы.
Связи – информационные связи.
5. Программная:
Элемент – программные модули.
Связи – информационные и управляющие связи.
6. Информационная:
Элемент – формы существования и представления информации в системе.
Связи – операции преобразования информации.
Scada-системы.
SCADA сокр. от англ. Supervisory Control And Data Acquisition — диспетчерское управление и сбор данных.
Под термином SCADA понимают инструментальную программу для разработки программного обеспечения систем управления технологическими процессами в реальном времени (АСУ ТП) и удаленного сбора данных
Основные задачи, решаемые SCADA-системами:
1. Обмен данными с УСО (устройства связи с объектом) в реальном времени.
2. Обработка информации в реальном времени.
3. Отображение информации на экране монитора в понятной для человека форме (HMI сокр. от англ. Human Machine Interface — человеко-машинный интерфейс).
4. Ведение базы данных реального времени с технологической информацией.
5. Аварийная сигнализация и управление тревожными сообщениями.
6. Подготовка и генерирование отчетов о ходе технологического процесса.
7. Осуществление сетевого взаимодействия между SCADA ПК.
8. Обеспечение связи с внешними приложениями (СУБД, электронные таблицы, текстовые процессоры и т.д.)
SCADA-системы позволяют разрабатывать АСУ ТП в клиент-серверной или в распределенной архитектуре (DCS сокр. от англ. Distributed Control System — распределённая система управления).
Часто SCADA-системы комплектуются дополнительным ПО для программирования промышленных контроллеров. Такие SCADA-системы называются интегрированными и к ним добавляют термин SoftLogiс.
Исполнительные модули АСУ ТП и АСУП
АСУ ТП |
АСУП |
1. Soft Logic 2. SCADA/HMI 1995 г. объединение |
1. EAM 2. HRM 3. MES |
Trace Mode 6, 2005 г.
HMI – системы человеко-машинного управления
EAM-система — Enterprise Asset Management, система управления основными фондами предприятия. Позволяет сократить простои оборудования, затраты на техобслуживание, ремонты и материально-техническое снабжение.
HRM – системы управления персоналом
MES Manufacturing Execution System — исполнительная система производства. Системы такого класса решают задачи синхронизации, координируют, анализируют и оптимизируют выпуск продукции в рамках какого-либо производства.
SCADA Trace Mode
TRACE MODE - это одна из самых покупаемых в России SCADA-система, предназначенная для разработки крупных распределенных АСУТП широкого назначения. Система TRACE MODE создана в 1992 году и к настоящему времени имеет свыше 6500 инсталляций. Проекты, разработанные на базе TRACE MODE, работают в энергетике, металлургии, атомной, нефтяной, газовой, химической, космической и других отраслях промышленности, в коммунальном и сельском хозяйстве России. По числу внедренний в России, TRACE MODE значительно опережает зарубежные пакеты подобного класса. Имеются также внедрения в странах СНГ, странах Балтии, Анголе, Ирландии, Италии, Ираке, Китае, США.
TRACE MODE - основана на инновационных, не имеющих аналогов технологиях. Среди них: разработка распределенной АСУТП как единого проекта, автопостроение, оригинальные алгоритмы обработки сигналов и управления, объемная векторная графика мнемосхем, единое сетевое время, уникальная технология playback - графического просмотра архивов на рабочих местах руководителей. TRACE MODE - это первая интегрированная SCADA- и SOFTLOGIC-система, поддерживающая сквозное программирование операторских станций и контроллеров при помощи единого инструмента.
Основные функции:
0.001 с - минимальный цикл системы;
Открытый формат драйвера для связи с любым УСО;
Открытость для программирования (Visual Basic, Visual C++ и т.д.);
Разработка распределенной АСУТП как единого проекта;
Cредства сквозного программирования АСУТП верхнего (АРМ) и нижнего (ПЛК) уровня;
Встроенные библиотека из более чем 150 алгоритмов обработки данных и управления в т.ч. фильтрация, PID, PDD, нечеткое, адаптивное, позиционное регулирование, управление устройствами (клапан, задвижка, привод и т.д.), статистические функции и произвольные алгоритмы;
Более 200 типов форм графического отображения информации в т.ч. тренды, мультипликация на основе растровых и векторных изображений, ActiveX;
Автоматическое резервирование архивов и автовосстановление после сбоя;
Мониторинг и управление через Internet;
Полностью русифицирована;
Архитектура TRACE MODE
TRACE MODE состоит из инструментальной системы и исполнительных (run-time) модулей. При помощи инструментальной системы осуществляется разработка АСУ. Исполнительные модули служат для запуска в реальном времени проектов, разработанных в инструментальной системе TRACE MODE.
7.Понятие жизненного цикла ПО ИС. Модели жизненного цикла ИС.
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ разработки систем (Systems Development Life Cycle, SDLC) отслеживает историю ЖЦ ИС и представляет «полную картину», в рамках которой могут быть спланированы и качественно оценены и проекты БД и разработка прикладных программ. ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Методология проектирования ИС описывает процесс создания и сопровождения систем в виде ЖЦ ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственности участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
Модель ЖЦ отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель ЖЦ – структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. [ISO/IEC 12207]
В настоящее время известны и используются следующие модели ЖЦ:
- Каскадная модель (рис. 1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок (т. е. единое целое). Для разработки такого типа приложений эффективным оказался каскадный способ. (рис. 1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем [2]:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рис. 1. Каскадная схема разработки ПО
Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем (рис. 2).
- Поэтапная модель с промежуточным контролем (рис. 2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки. Однако, и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
Рис. 2. Поэтапная модель с промежуточным контролем
- Спиральная модель (рис. 3.). Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо вводить временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Рис 3. Спиральная модель ЖЦ
На практике наибольшее распространение получили две основные модели ЖЦ:
- каскадная (период 1970-1985);
-спиральная (после 1985).
Стандарты, регламентирующие жц ис
В последние годы в России идет интенсивная работа по гармонизации государственных стандартов Российской Федерации с международными стандартами ISO в области создания нормативной базы управления жизненным циклом программных средств и информационных систем. В основе стандартизации ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств», который является аутентичным переводом стандарта ISO.
Таблица 2.1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207) |
|||
Процесс (исполнитель процесса) |
Действия |
Вход |
Результат |
Приобретение (заказчик) |
|
|
|
Поставка (разработчик ИС) |
|
|
|
Разработка (разработчик ИС) |
|
|
|
Другие стандарты:
Стандарты комплекса ГОСТ34 в основном уделяет внимание содержанию проектных документов. ) Введение единой, достаточно качественно определенной терминологии (см. материалы Группы 0 ГОСТ34), наличие достаточно разумной классификации работ, документов, видов обеспечения и др. безусловно полезно. ГОСТ34 способствует более полной и качественной стыковке действительно разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС
ГОСТ 34.601-90 Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89 Техническое задание на создание АС.
ГОСТ Р ИСО/МЭК ТО 15271-2002. Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств). Настоящий стандарт содержит рекомендации по применению ГОСТ Р ИСО/МЭК 12207. В стандарте основное внимание уделено особенностям, подлежащим учету при прикладном применении ГОСТ Р ИСО/МЭК 12207 в условиях реальных проектов создания программных средств.
ГОСТ Р ИСО/МЭК ТО 16326-2002, Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом. Настоящий стандарт уточняет и дополняет ГОСТ Р ИСО/МЭК 12207 в части процесса управления. Настоящий стандарт предназначен для лиц, отвечающих за управление реализацией основных процессов по ГОСТ Р ИСО/МЭК 12207: заказа, поставки, разработки, эксплуатации и сопровождения.
Обзор существующих методологий проектирования ис. Методика Oracle cdm
Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.
Возникла как развитие разработанной давно версии Oracle CASE-Method, известной по использованию Oracle CASE (ныне Designer/2000) и книгам Р. Баркера. CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения (см. описание CDM) о простом приспособлении CDM к проектам, в которых используется другой инструментальный комплекс.
Общая структура.
ЖЦ формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов.
Этапы:
"Определение требований" (представляется более точным по форме и содержанию переводом, чем "Стратегия" в [1], далее наименования в большинстве случаев - но не всегда - выбраны совпадающими с принятыми в указанной публикации);,
"Анализ" (формулирование детальных требований к прикладной системе);
"Проектирование" (преобразование требований в детальные спецификации системы);
"Реализация" (написание и тестирование приложений);
"Внедрение" (установка новой прикладной системы, подготовка к началу эксплуатации);
"Эксплуатация" (поддержка и слежение за приложением, планирование будущих функциональных расширений).
Процессы:
RD - Определение производственных требований,
ES - Исследование существующих систем,
TA - Определение технической архитектуры,
DB - Проектирование и построение БД,
MD - Проектирование и реализация модулей,
CV - Конвертирование данных,
DO - Документирование,
TE - Тестирование,
TR - Обучение,
TS - Переход к новой системе,
PS - Поддержка и сопровождение.
Степень адаптивности CDM ограничивается тремя моделями ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track), еще более сильно ориентированная на использование инструментов моделирования и программирования Oracle, "облегченный подход", рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения.
Все модели ЖЦ АС и ПП являются по сути каскадными; даже "облегченный подход", несмотря на понятную итерационность выполнения действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач.
Фактической ориентацией методики является ее (исторически понятная) направленность на создание Информационной Системы с Базами Данных в достаточно традиционном понимании.
Rational Unified Process (RUP)
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.
Предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы.
4 фазы цикла:
1. Начало (Inception)
На этом этапе:
Формируются видение и границы проекта.
Создается экономическое обоснование (business case).
Определяются основные требования, ограничения и ключевая функциональность продукта.
Создается базовая версия модели прецедентов.
Оцениваются риски.
При завершении фазы Начало оценивается достижение вехи целей жизненного цикла Lifecycle Objective Milestone, которое предполагает соглашение заинтересованных сторон о продолжении проекта.
2. Проектирование (Elaboration)
На этапе Проектирование производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
Документирование требований (включая детальное описание для большинства прецедентов использования).
Спроектированную, реализованную и оттестированную исполняемую архитектуру.
Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
Сниженные основные риски.
Успешное выполнение фазы Проектирование означает достижение вехи архитектуры жизненного цикла (Lifecycle Architecture Milestone).
3. Построение (Construction)
Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).
4. Внедрение (Transition)
Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.
Microsoft Solutions Framework (MSF)
Microsoft Solutions Framework (MSF) — это методология разработки программного обеспечения от Microsoft. MSF опирается на практический опыт корпорации Майкрософт и описывает управление людьми и рабочими процессами в процессе разработки решения.
Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral).
Модель процессов включает такие основные фазы процесса разработки:
Выработка концепции (Envisioning)
Планирование (Planning)
Разработка (Developing)
Стабилизация (Stabilizing)
Внедрение (Deploying)
Кроме этого существует большое количество промежуточных вех, которые показывают достижение в ходе проекта определенного прогресса и расчленяют большие сегменты работы на меньшие, обозримые участки.
Управление рисками (risk management) — это одна из ключевых дисциплин Microsoft Solutions Framework® (MSF). Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. Девиз MSF – мы не боремся с рисками — мы ими управляем.
Проект (project) — ограниченная временными рамками деятельность, цель которой состоит в создании уникального продукта или услуги. Управление проектами (project management) — это область знаний, навыков, инструментария и приемов, используемых для достижения целей проектов в рамках согласованных параметров качества, бюджета, сроков и прочих ограничений.
Управление подготовкой – это также одна из ключевых дисциплин Microsoft Solutions Framework (MSF). Она посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений.
MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес- Extreme Programming (XP).
Экстремальное программирование (Extreme Programming, XP)
Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование (Test driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous Integration)
Рефакторинг (Design Improvement, Refactor)
Частые небольшие релизы (Small Releases)
Понимание, разделяемое всеми
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
Стандарт кодирования (Coding standard or Coding conventions)
Социальная защищенность программиста (Programmer welfare):
40-часовая рабочая неделя (Sustainable pace, Forty hour week)
Rapid Application Development (RAD)
RAD (Rapid Application Development) – методология быстрой разработки приложений. Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
фаза анализа и планирования требований;
Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.
фаза проектирования;
Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. На этой же фазе происходит определение набора необходимой документации.
Результатом данной фазы должны быть:
общая информационная модель системы;
функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
построенные прототипы экранов, отчетов, диалогов.
фаза построения;
На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
фаза внедрения.
Производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой).
Классификация методов проектирования ис. Каноническое и типовое проектирование ис. Автоматизированное проектирование ис. Case-средства.
Классификация методов проектирования ИС
По признаку степени автоматизации проектных работ методы проектирования делятся на:
оригинальное (индивидуальное, каноническое) проектирование.
типовое проектирование:
элементарное;
подсистемное;
модельное;
автоматизированное проектирование:
структурное;
объектное.
Каноническое проектирование ИС
Каноническое проектирование ИС отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких-либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций. Как правило, каноническое проектирование применяется для небольших локальных ИС.
В основе канонического проектирования лежит каскадная модель жизненного цикла ИС. Процесс каскадного проектирования в жизненном цикле ИС в соответствии с применяемым в нашей стране ГОСТ 34.601-90 «Автоматизированные системы стадий создания» делится на следующие стадии:
формирование требований к ИС;
разработка концепции ИС;
разработка технического задания;
создание эскизного проекта;
техническое проектирование;
рабочее проектирование;
ввод в действие;
функционирование, сопровождение, модернизация
В целях изучения взаимосвязанных приемов и методов канонического проектирования ИС перечисленные 8 стадий можно сгруппировать в часто используемые на практике четыре стадии процесса разработки ИС:
На первой «Предпроектной стадии» принято выделять два основных этапа: сбор материалов обследования; анализ материалов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ).
При каноническом проектировании основной единицей обработки данных является задача. Поэтому функциональная структура предметной области на стадии предпроектного обследования изучается в разрезе решаемых задач и комплексов задач.
Вторая стадия «Техно-рабочее проектирование» выполняется в два этапа: техническое проектирование и рабочее проектирование.
На этапе «Техническое проектирование» выполняются работы по логической разработке и выбору наилучших вариантов проектных решений, в результате чего создается «Технический проект».
Этап «Рабочее проектирование» связан с физической реализацией выбранного варианта проекта и получением документации «Рабочего проекта». При наличии опыта проектирования эти этапы иногда объединяются в один, в результате выполнения которого получают «Техно-рабочий проект» (ТРП)
Третья стадия «Внедрение проекта» включает в себя три этапа: подготовка объекта к внедрению проекта; опытное внедрение проекта и сдача его в промышленную эксплуатацию.
На этапе «Подготовка объекта к внедрению проекта» осуществляется комплекс работ по подготовке предприятия к внедрению разработанного проекта ИС.
На этапе «Опытное внедрение» осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную документацию и «Акт о проведении опытного внедрения».
На этапе «Сдача проекта в промышленную эксплуатацию» осуществляют комплексную системную проверку всех частей проекта, в результате которой получают доработанный «Техно-рабочий проект» и «Акт приемки проекта в промышленную эксплуатацию».
Четвертая стадия «Эксплуатация и сопровождение проекта» включает этапы: эксплуатация проекта; сопровождение и модернизация проекта.
На этапе «Эксплуатация проекта» получают информацию о работе всей системы в целом и отдельных ее компонентов и собирают статистику о сбоях системы в виде рекламаций и замечаний, которые накапливаются для выполнения следующего этапа.
На этапе «Сопровождение проекта» выполняются два вида работ: ликвидируются последствия сбоев в работе системы и исправляются ошибки, не выявленные при внедрении проекта, а также осуществляется модернизация проекта.
В процессе модернизации проект либо дорабатывается, т.е. расширяется по составу подсистем и задач, либо производится перенос системы на другую программную или техническую платформу с целью адаптации ее к изменяющимся внешним и внутренним условиям функционирований, в результате чего получают документы модернизированного «Техно-рабочего проекта»
Типовое проектирование ИС
Состав стадий и этапов типового автоматизированного проектирования практически не отличается от аналогичных стадий и этапов канонического проектирования. Отличие заключается в содержании проводимых работ, используемых средствах проектирования и применяемой модели жизненного цикла.
Типовое проектирование предполагает конфигурирование ИС из готовых типовых проектных решений (программных модулей). Выполняется на основе опыта, полученного при разработке индивидуальных проектов. Типовые проекты, как обобщение опыта для некоторых групп организационно-экономических систем или видов работ, в каждом конкретном случае связаны со множеством специфических особенностей и различаются по степени охвата функций управления, выполняемым работам и разрабатываемой проектной документации.
Кроме того, отличием является переход от позадачного проектирования к методологии реинжиниринга бизнес-процессов. Реинжиниринг предусматривает радикальное перепроектирование бизнес-процессов предприятий для достижения резких, скачкообразных улучшений показателей их деятельности: стоимости, качества, сервиса, темпов развития на базе новых информационных технологий. Реинжиниринг подразумевает перестройку экономической деятельности экономического объекта на базе новой ИТ. В то же время реинжинирингу подвергаются ИС, их техническое, программное, информационное обеспечение, перепроектирование которых ведется на основе вновь создаваемой абстрактной модели пересматриваемой исходной системы.
Автоматизированное проектирование ИС. CASE-средства
CASE-технология представляет собой совокупность методов анализа, проектирования, разработки и сопровождения АИС, поддержанной комплексом взаимосвязанных средств автоматизации.
Основная цель CASE-технологии состоит в том, чтобы отделить процесс проектирования АИС от ее кодирования и последующих этапов разработки, а также максимально автоматизировать процесс разработки и функционирования систем. Кроме того, CASE-средства обладают следующими характеристиками:
мощная графика для описания и документирования систем, а также для улучшения интерфейса с пользователем, развивающая творческие возможности специалистов;
интеграция, обеспечивающая легкость передачи данных и позволяющая управлять всем процессом проектирования и разработки системы непосредственно через процесс планирования проекта;
использование компьютерного хранилища (репозитария) для всей информации о проекте, которая может разделяться между разработчиками и исполнителями как основа для типового проектирования АИС и повторного его использования в будущих системах.
Помимо принципов графической ориентации, интеграции и локализации всей проектной информации в репозитарии в основе построения CASE-средств лежат следующие положения:
Человеческий фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс.
Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний и др).
Автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ.
Ограничение сложности, позволяющее получать компоненты, поддающиеся управлению, обозримые и доступные для понимания, а также обладающие простой и ясной структурой.
Доступность для разных категорий пользователей.
Рентабельность.
Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям.
Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin);
средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE);
средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).
На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
Vantage Team Builder (Westmount I-CASE);
Designer/2000;
Silverrun;
ERwin+BPwin;
S-Designor;
CASE.Аналитик.
Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает:
отдельные локальные средства, решающие небольшие автономные задачи (tools);
набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit);
полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием.
Структурный подход к проектированию ис. Модели idef0, idef3. Диаграмма потоков данных.
Сущность структурного подхода заключается в декомпозиции программы или программной системы по функциональному принципу. При данном подходе проектирование ИС начинают с определения ее структуры.
Функциональная методика idef0
Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий (ICAM). Последняя редакция IDEF была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).
Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы.
Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций.
В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником. Каждая из четырех сторон функционального блока имеет свое определенное значение (роль):
Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей" или "управляющей".
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Глоссарий. Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Модель может содержать четыре типа диаграмм:
контекстную диаграмму(в каждой модели может быть только одна контекстная диаграмма);
диаграммы декомпозиции;
диаграммы дерева узлов;
диаграммы только для экспозиции (FEO).
Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы — диаграммы наиболее абстрактного уровня описания системы в целом – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.
Диаграмма декомпозиции предназначена для детализации работы. Работы нижнего уровня — это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня — это то же самое, что границы диаграммы декомпозиции. Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему.Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу помещается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое размещение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ
Стрелки(Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными (например, "Звонки клиентов", "Правила и процедуры", "Бухгалтерская система".)
В IDEF0 различают пять типов стрелок:
Вход(Input) — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа.
Управление(Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления.
Выход(Output) — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода.
Механизм(Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д.
Вызов(Call) — специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.
Граничные стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот.
Внутренние стрелки. Для связи работ между собой используются внутренние стрелки, то есть стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы:
1. Связь по входу(output-input), когда стрелка выхода вышестоящей работы (далее — просто выход) направляется на вход нижестоящей
2. Связь по управлению(output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы.
3. Обратная связь по входу(output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов.
4. Обратная связь по управлению(output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей. Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса.
5. Связь выход-механизм(output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы.
Все внутренние стрелки делятся на:
Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.
Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах.
Туннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня. Туннелирование может быть применено для изображения малозначимых стрелок
Диаграмма деревьев узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами. Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов.
Диаграммы "только для экспозиции" (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку по сути являются просто картинками — копиями стандартных диаграмм и не включаются в анализ синтаксиса.
Диаграммы потоков данных dfd (Data Flow Diagrams)
Используются для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота вашей организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
Всего DFD использует четыре важных элемента:
Работы. Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами.
Стрелки. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота.
Внешние ссылки. Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы.
Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных.
В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота.
IDEF3
Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии – IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.
IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать «сеть переходных состояний объекта», предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.
С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец при закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции организации.
Модель, выполненная в IDEF3, может содержать следующие элементы:
Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.
Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:
Связь предшествования (Precedence) – показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.
Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.
Поток объектов (Object Flow) – показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.
Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков:
Перекресток слияния (Fan-in Junction) – узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса.
Перекресток ветвления (Fan-out Junction) – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.
Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы.
Объектно-ориентированный подход к проектированию ис.
Начиная с 70-80-ых годов ХХ-го века развитие аппаратных средств существенно опережало развитие систем и средств программирования. Чтобы выправить положение, были предложены различные подходы к увеличению производительности труда программиста. Среди этих попыток выделяется такое популярное направление, как объектно-ориентированный подход (ООП) к проектированию ИС. Особую роль в популярности этого подхода сыграло как его тесная связь с интерфейсами пользователя (особенно графическими), так и включение элементов этого подхода в популярные реализации языков программирования C++ и Pascal with Objects фирмы Borland.
ООП также получил признание в сфере автоматизированного проектирования, как альтернатива структурного подхода в проектировании сложных информационных систем и реляционной модели данных как основного средства отображения информации о сложных объектах.
Среди типовых задач, для которых ООП является перспективным, можно выделить такие:
Проектирование сложных инженерных объектов и систем (таких как ракетные комплексы, АСУП и САПР, управление технологиями, автоматизация эксперимента, робототехника) ;
Диспетчеризация, планирование современного производства;
Сети коммуникации и связи;
Системы искусственного интеллекта, системы поддержки принятия решений, экспертные системы;
Операционные системы, системы реального времени;
Системы имитации и моделирования, тренажеры и т.д.
Новая методология ориентирована, прежде всего, на создание больших сложных систем, коллективную их разработку, последующее активное сопровождение при эксплуатации и регулярные модификации.
До сих пор большинство сложных систем были построены на принципах структурного подхода, суть которого состоит в декомпозиции системы на ряд модулей, процедур, функций и структур данных, связанных общим алгоритмом функционирования. Но распространение мощных персональных компьютеров создало в 90-х годах основу для широкого применения объектно-ориентированного подхода в практике проектирования и программирования. В последнее время более широко начинают использоваться как языки программирования, созданные в рамках объектно-ориентированной методологии, так и объектно-ориентированные СУБД.
В основе объектно-ориентированной методологии (ООМ) лежит объектный подход, когда прикладная предметная область представляется в виде совокупности объектов, которые взаимодействуют между собой посредством передачи сообщений. Под объектом понимается некоторая сущность (реальна или абстрактная), обладающая состоянием, поведением и индивидуальностью. Состояние объекта характеризуется перечнем всех его возможных (обычно статических) свойств - структурой и значениями каждого из этих свойств. Поведение объекта (или его функциональность) характеризует то, как объект взаимодействует с другими объектами или подвергается взаимодействию других объектов, проявляя свою индивидуальность. Индивидуальность - это такие свойства объекта, которые отличают его ото всех других объектов. Поведение объекта реализуется в виде функций, которые называют методами. При этом структура объекта доступна только через его методы, которые в совокупности формируют интерфейс объекта.
Такой подход позволяет локализовать принимаемые решения рамками объекта, объединяя в нем и структуру и поведение, а следовательно, снижая сложность описания и реализации объекта. Эта способ объединения структуры и поведения в одном месте и сокрытия всех данных внутри объекта, что делает их невидимыми для всех, за исключением методов самого объекта называется инкапсуляцией. Это позволяет объектам функционировать совершенно независимо друг от друга, скрывая за интерфейсом детали реализации. Инкапсуляция позволяет рассматривать объекты, как изолированные "черные ящики", которые знают и умеют выполнять определенные действия. С этой точки зрения, внутреннее устройство "черных ящиков" для нас значения не имеет, нам все равно, что происходит внутри. Важно только знать, что надо положить в ящик при обращении к нему и что мы при этом из него получим. Таким образом, объекты - это минимальные единицы инкапсуляции.
Но к объекту может обращаться не только программист, разработчик или администратор, но и любой объект, функционирующий в системе. Для этого нужно только послать интересующему объекту сообщение, которое представляет требование выполнить некоторые действия. И если такое требование может быть выполнено принявшим сообщение объектом, то оно выполняется, а если не может быть выполнено, то пославший требование объект информируется о реакции на полученное сообщение.
Для упрощения описания и управления множеством объектов была введена одна из ключевых концепций объектно-ориентированного программирования - идея группировки объектов в классы, в соответствии с тем как они устроены и действуют. Под классом понимается множество объектов, связанных общностью структуры и поведения. Именно класс вначале описывает переменные и методы объекта, то есть структуру и поведение объекта. Любой конкретный объект представляет собой экземпляр класса.
Структура и поведение схожих объектов определяют общий для них класс, т.о. объект это экземпляр класса. Классы, как и объекты, не существуют изолированно. Между ними существует 3 вида отношений:
- отношение «разновидность-обобщение» отражает степень общности, например «роза-разновидность цветов», что означает, что роза есть специализированный подкласс класса цветов;
- отношение «составная часть-целое» отражает агрегатирование объектов, например, лепесток – не разновидность цветка, а его составляющая часть;
- отношение «ассоциация» – смысловая связь между классами, которые не связаны никакими другими типами отношений, например, роза и ромашка пригодны для декоративного оформления.
Существует еще один механизм, позволяющий определять некоторый порядок среди классов. Достигается это с помощью введения механизма наследования - пожалуй, самого мощного средства в любой объектно-ориентированной системе, поскольку оно позволяет многократно использовать однажды созданное описание. Механизм наследования очень прост: один класс, называемый в рамках этих отношений суперклассом, полностью передает другому классу, который называется подклассом, свою структуру и поведение, то есть все свои переменные и все методы. Что далее делать с этим богатством определяет только подкласс: он может добавить в структуру что-то свое, что-то из наследуемого интерфейса он может использовать без изменений, что-то изменить, и, разумеется, может добавить свои собственные методы. То есть класс с помощью подклассов расширяется, и как результат, создаваемые объекты становятся все более и более специализированными. Классы, расположенные по принципу наследования, начиная с самого общего, базового класса, образуют иерархию классов.
Разумеется система, реализующая такие принципы построения, предъявляет более жесткие, чем при структурном подходе, требования к производительности вычислительной системы и СУБД.
Прежде, чем двигаться дальше, стоит отметить, что ООП не является отрицанием или противопоставлением структурному подходу. Эту методологию правильнее представлять как инструмент, позволяющий снизить сложность задачи и подойти к созданию таких систем, поведение которых невозможно представить в виде исчерпывающего набора всех возможных ситуаций и разветвлений алгоритма. Таким образом в заключение, можно сделать вывод, что концептуально объектно-ориентированная методология опирается на объектный подход, который включает четыре основных принципа:
Абстрагирование.
Выделение таких существенных характеристик объектов, которые отличают его ото всех других объектов и которые четко определяют особенности данного объекта с точки зрения дальнейшего рассмотрения и анализа. Только существенное для данной задачи и ничего более. Минимальной единицей абстракции в ООМ является класс.
Ограничение доступа.
Процесс защиты отдельных элементов объекта, не затрагивающий существенных характеристик объекта, как целого.
Модульность.
Свойство системы, связанное с возможностью декомпозиции на ряд тесно связанных частей (модулей). Модульность опирается на дискретное программирование объектов, которые можно модернизировать или заменять, не воздействуя на другие объекты и систему в целом.
Существование иерархий.
Ранжирование, упорядочивание по некоторым правилам объектов системы.
Объектно-ориентированная методология (ООМ) создания автоматизированных систем состоит из следующих частей:
объектно-ориентированный анализ (OOA),
объектно-ориентированное проектирование (OOD),
объектно-ориентированное программирование (OOР).
ООА - методология анализа сущностей реального мира на основе понятий класса и объекта, составляющих словарь предметной области, для понимания и объяснения того, как они (сущности) взаимодействуют между собой.
Рассматривая реальную задачу, аналитик разбивает ее на некоторое число предметных областей. Каждая предметная область - мир, наделенный объектами. В предметной области выделяются классы объектов, которые, если это необходимо, разбиваются на подклассы. Каждый класс и его подкласс анализируются в три этапа: информационное моделирование, моделирование состояний, моделирование процессов.
Модели OOA в дальнейшем преобразуются в объектно-ориентированный проект. OOD - методология проектирования, соединяющая в себе процесс объектной декомпозиции, опирающийся на выделение классов и объектов, и приемы представления моделей, отражающих логическую (структура классов и объектов) и физическую (архитектура моделей и процессов) структуру системы. Следующие понятия являются в OOD фундаментальными.
Инкапсуляция.
Концепция сокрытия в как бы "капсуле" всей информации об объекте, то есть объединение в некое целое данных и процедур (методов) их обработки. Единицей инкапсуляции в OOD является объект, в котором содержатс и данные состояния объекта и сообщения, которые объект может обрабатывать.
Наследование.
Получение от предшественника - такое соотношение между классами, находящимис в некоторой определенной иерархии, при которой один класс моделирует поведение и свойства другого класса, добавляя свою специфику. Класс поведение которого наследуется называется суперклассом, а класс, который наследует поведение, называется подклассом.
Полиморфизм.
Возможность единообразного обращения (посылки объектам одноименных сообщений) при сохранении уникального поведения объектов. Другими словами, поскольку поведение объектов определяется методами, метод, ассоциированный с одним и тем же именем сообщения, допускает различные реализации для разных классов.
Фундаментальная концепция OOP состоит в том, что объекты и классы взаимодействуют друг с другом путем передачи сообщений. Для этого необходимо, чтобы объекты определялись вместе с сообщениями, на которые они реагируют, в отличии от процедурного стиля программирования, когда сначала определяются данные, которые затем передаются в процедуры (функции) как параметры. При этом средством программирования выступает один из объектно-ориентированных языков программирования.
Моделирование данных с использованием er-диаграмм. Базовые понятия idef1x.
Процесс проектирования длительный, он требует обсуждений с заказчиком, со специалистами в предметной области. Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, как говорилось раньше, оно не должно быть привязано к конкретной СУБД. Выбор СУБД — это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД.
Потребности проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области вызвали к жизни направление семантических моделей данных. Притом, что любая развитая семантическая модель данных, как и реляционная модель, включает структурную, манипуляционную и целостную части, главным назначением семантических моделей является обеспечение возможности выражения семантики (смысла) данных.
Модель «сущность-связь» (Entity-Relationship, или ER-модель) представляет собой высокоуровневую концептуальную модель данных, которая была разработана с целью упрощения задачи проектирования баз данных. Основная цель разработки высокоуровневой модели данных заключается в создании модели пользовательского восприятия данных и согласовании большого количества технических аспектов, связанных с проектированием базы данных. Следует особо подчеркнуть, что концептуальная модель данных не зависит от конкретной СУБД или аппаратной платформы, которая используется для реализации БД.
На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. (и получила дальнейшее развитие в работах Баркера). Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В 1985 г. нотация методологии IDEF1 была расширена и переименована в IDEF1X. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin , Design/IDEF).
Как любая модель, модель «сущность—связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определенным правилам.
Класс однотипных объектов моделируется с помощью Сущностей. Сущность (Entity)- это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована в пределах моделируемой системы.
Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности, обладающих общими атрибутами или характеристиками. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов — характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности.
Атрибутом сущности является любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для уточнения, идентификации, классификации, количественной характеристики или выражения состояния сущности. Уникальным идентификатором сущности является атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа.
Рис. 1. Пример определения сущности в модели ER
Сущность в методологии IDEF1X является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности.
Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Связь - это графически изображаемая именованная ассоциация, устанавливаемая между двумя сущностями, значимая для рассматриваемой предметной области. Установка связи определяет, что каждый экземпляр одной сущности ассоциирован с произвольным (в том числе с нулевым) количеством экземпляров второй сущности (или наоборот). Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае – неидентифицирующей. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, дочерняя сущность автоматически преобразуется в зависимую. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности (изображается сплошной линией). Такая операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - FK. При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых атрибутов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей (изображается пунктирной линией).
Мощность связи (Cardinality) – служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Типы мощностей (Одному экземпляру родительской сущности соответствуют…):
- 0, 1 или много (N);
- 1 или много (Р);
- 0 или 1 (Z);
- заданное число (цифра); (…экземпляров дочерней сущности)
Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка.
Типы зависимых сущностей
Характеристическая – зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности:
Ассоциативная – сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей.
Именующая – частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа).
Категориальная – дочерняя сущность в иерархии наследования, которая представляет собой особый тип объединения сущностей, которые разделяют общие характеристики. Иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи (например, если бы Постоянный сотрудник и Совместитель имели сходную по смыслу связь Работает в с сущностью Организация). Например, в организации работают служащие, занятые полный рабочий день и совместители. Из их общих свойств можно сформировать обобщенную сущность Сотрудник, чтобы представить информацию, общую для всех типов служащих. Специфическая для каждого типа информация может быть расположена в категориальных сущностях Постоянный сотрудник и Совместитель. Для каждой категории можно указать дискриминатор – атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой (на рис. Тип).
Нормальные формы ER-схем
Как и в реляционных схемах баз данных, в ER-схемах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем. Мы приведем только очень краткие и неформальные определения трех первых нормальных форм.
В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных" под атрибуты.
Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального идентификатора. Эта часть уникального идентификатора определяет отдельную сущность.
В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.
Получение реляционной схемы из ER-схемы
Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.
Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.
Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.
Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:
все подтипы в одной таблице (а)
для каждого подтипа - отдельная таблица (б)
При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется по крайней мере один столбец, содержащий код ТИПА; он становится частью первичного ключа.
При использовании метода (б) для каждого подтипа первого уровня (для более нижних - представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа).
Все в одной таблице |
Таблица - на подтип |
Преимущества |
Преимущества |
Все хранится вместе Легкий доступ к супертипу и подтипам Требуется меньше таблиц |
Более ясны правила подтипов Программы работают только с нужными таблицами |
Недостатки |
Недостатки |
Слишком общее решение Требуется дополнительная логика работы с разными наборами столбцов и разными ограничениями Потенциальное узкое место (в связи с блокировками) Столбцы подтипов должны быть необязательными В некоторых СУБД для хранения неопределенных значений требуется дополнительная память |
Слишком много таблиц Смущающие столбцы в представлении UNION Потенциальная потеря производительности при работе через UNION Над супертипом невозможны модификации |
Шаг 7. Имеется два способа работы при наличии исключающих связей:
общий домен (а)
явные внешние ключи (б)
Если остающиеся внешние ключи все в одном домене, т.е. имеют общий формат (способ (а)), то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей, покрываемых дугой исключения. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи.
Если результирующие внешние ключи не относятся к одному домену, то для каждой связи, покрываемой дугой исключения, создаются явные столбцы внешних ключей; все эти столбцы могут содержать неопределенные значения.
Общий домен |
Явные внешние ключи |
Преимущества |
Преимущества |
Нужно только два столбца |
Условия соединения - явные |
Недостатки |
Недостатки |
Оба дополн-ых атрибута должны использоваться в соединениях |
Слишком много столбцов |
Правовые ис.
Правовые ИС - особый класс компьютерных ИС, содержащих тексты нормативных документов различных государственных органов, а также консультации специалистов по праву и бухгалтерскому учету, судебные решения, типовые формы деловых документов и др.
Развитие в России
1976 г. – научный центр правовой информации (НЦПИ) при министерстве Юстиции.
1989 г. – первая негосударственное предприятие по правовой информации – ЮСИС.
1991 г. – Гарант.
1992 г. – Консультант-Плюс.
На сегодняшний день лидеры:
Консультант-Плюс (АО «Консультант+», г. Москва):
имеются федеральные и международные документы, судебные решения, финансовые консультации; состоит из федеральной, региональной и местной баз данных
Кодекс (АО «ЦКР» (центр компьютерных разработок), г. Санкт-Петербург):
большое количество нормативно-технических документов — ГОСТов, СНиПов, РД и т. д.;
имеет специализированные справочные системы по различным отраслям деятельности (строительство, экология, электроэнергетика, охрана труда и пр.)
Гарант (НПП «Гарант-Сервис», г. Москва):
имеются международные и федеральные документы, судебные решения, финансовые консультации, тексты указов президента;состоит из одной объединённой базы
1С:Кодекс, 1С:Гарант, 1С:Эталон.
Государственными являются: Эталон (НЦПИ Минюста), Система (ФАПСИ–ФСО).
Основные потребительские свойства правовых ис
Информационное наполнение:
Полнота банка документов;
Оперативность; Достоверность;
Юридическая обработка;
Технологические качества
Пользовательский интерфейс;
Способ транспортировки документов;
Общий уровень сервиса:
Возможность обучения пользователей;
Возможность проведения консультаций;
Возможность заказа документов;
Бесплатные demo-версии.
Правовая информация делится на:
официальная
нормативные правовые акты
законы (конституция, ФЗ, федеральные конституционные законы, законы субъектов);
международные договоры и соглашения;
акты (акты Президента, Правительства, федеральных исполнительных органов власти, Палат федерального Собрания);
иная правовая информация
правоприменительные акты;
официальные разъяснения;
неофициальная
комментарии;
обзоры;
типовые формы документов;
правовая статистика;
индивидуальная
Способы распространения правовой информации
печатный;
электронный.
Преимущества печатного способа:
общедоступность;
традиционность;
возможность ссылки на официальный документ;
удобство.
Преимущества электронного способа:
оперативность;
объем;
поиск;
использование различных сервисов.
Проблемы и перспективы использования электронных ИПС:
нет гарантии свободного доступа населения к правовой информации;
нет гарантии, что электронный документ соответствует бумажному оригиналу;
фиксация даты помещения документа в БД.
Особенности технологии создания правовых ис
3 подхода к созданию ИПС:
использование традиционных СУБД;
использование промышленных СУБД, ориентированных на хранение текстовой информации;
создание специализированных СУБД, ориентированных на правовую информацию.
Специфика правовой информации:
Большой объем текстовой информации;
Гипертекстовые связи между документами;
Необходимость одновременного хранения разных версий документа;
Частая актуализация документов с сохранением связи между ними;
Рубрикация;
Специальные сервисные инструменты.
MFC (MS Foundation Classes) – интерфейс Консультанта; ядро – C ++.
Сопровождение функционирования правовых ис
Основные этапы производственных работ по сопровождению ИПС:
Организация доступа к первоисточникам правовой информации;
Классификация (рубрикация) полученных документов (Указ Президента РФ от 15.03.2000 г. №511 «О классификации правовой информации»);
Подготовка электронной версии документа: оцифровка, проверка орфографии, сверка с официальным текстом документа;
Юридическая обработка документов:
выявление связей между документами;
фиксирование связей с помощью ссылок, примечаний и справок;
формирование списка ключевых слов документа;
подготовка новой редакции документа
Объективная юридическая обработка – основывается на самом документе или на общепринятых юридических нормах.
Субъективная юридическая обработка – анализ, проводимый экспертами - юристами
Актуализация БД у разработчика – процесс подразумевает полную интеграцию документа в существующую БД со всеми взаимными ссылками и связями с имеющимися документами;
Передача новой информации потребителям:
удаленный доступ к БД;
вся БД устанавливается на компьютере потребителя и периодически обновляется.
Для обслуживания ИПС создается сеть сервисных центров, которые выполняют три функции:
маркетинг;
представительство;
техническое обслуживание и сопровождение БД.
Функциональные возможности правовых ИС (на примере Консультант-Плюс):
Поиск документов:
по реквизитам;
правовой навигатор;
справочная информация;
обзоры;
кодексы;
словари;
Работа с документами:
контекстный поиск по документу;
определение связей документа;
история редакции;
справки и примечания;
установка закладок и комментариев;
экспорт в Word;
сохранение в файл;
печать;
Работа со списками документов:
сортировка;
уточнение списка;
экспорт в Word;
сохранение в файл;
печать;
Сервис по организации работы пользователя:
создание пользовательских папок;
ведение истории работы пользователя;
постановка документа на контроль;
аналитические обзоры.
Информационные технологии административного управления. Система ацк - Финансы.
АЦК – автоматизированный центр контроля (ядро)
АЦК-Финансы – управление процессом исполнения бюджета.
Одна из основных задач - централизация финансовой власти региона (города).
Решение:
централизация абсолютно всей первичной, производной и отчетной финансовой информации
централизация всех средств в администрации, и как следствие,
централизацией самого процесса управления финансами.
Комплексная оптимизация и автоматизация всех участков и всех участников бюджетного процесса, в т. ч. автоматизация всех структурных подразделений внутри финансового органа (ФО), подчиненных территориальных подразделений ФО, распорядителей и получателей бюджетных средств (РБС и ПБС).
Связь ФО с МНС и УФК, с обслуживающим банком или РКЦ.
Создание единого электронного документооборота, обеспечивающего полную автоматизацию процесса исполнения бюджета, охватывающего всех участников бюджетного процесса:
Бухгалтерию ФО;
Бюджетный и отраслевые отделы ФО;
Отдел ценных бумаг и неденежных форм расчетов ФО;
Отдел доходов ФО;
Казначейский отдел ФО;
Отдел управления и обслуживания государственного долга (или Отдел кредитов и долговых обязательств) ФО;
Отдел учета бюджетных обязательств ФО;
Отдел автоматизации систем финансовых расчетов ФО;
РБС (территориальные и ведомственные);
ПБС и прочие.
Обеспечение
автоматизации рабочего места каждого специалиста
функционирования специалиста в рамках должностных инструкций
связи всех автоматизированных рабочих мест с единой системой электронного документооборота с использованием при передаче электронных документов средств криптографической защиты и электронно-цифровой подписи.
Организация единого удаленного документооборота обеспечивает создание единой информационной системы ФО, позволяющей осуществлять мониторинг исполнения регионального (местного) бюджета в режиме реального времени, вплоть до конечных ПБС вне зависимости от их территориальной удаленности.
Система АЦК-Финансы автоматизирует следующие функции:
осуществление казначейского расхода
Формирование проекта бюджета.
Проведение взаимных расчетов между уровнями бюджета.
Расчет/принятие лимитов бюджетных обязательств.
Учет бюджетных (договорных) обязательств.
Исполнение бюджета по расходам.
Исполнение бюджета по доходам.
Операции с привлеченными средствами и средствами, размещенными на возвратной основе.
Бухгалтерский учет.
Учет средств, полученных от предпринимательской и иной приносящей доход деятельности.
Учет гарантий и поручительств.
Исполнение бюджета по источникам покрытия дефицита бюджета.
Исполнение доходов и расходов целевых бюджетных фондов.
Проведение операций с ценными бумагами.
Анализ исполнения бюджета, получение и свод отчетности об исполнении бюджета.
Капитальное строительство и другие.
Система АЦК-Финансы работает как конвейер обработки документов и обеспечивает взаимосвязь всех документов системы. На этапе адаптации системы разрабатывается последовательность документооборота и полномочий каждого сотрудника по отношению к документам.
Система ацк - Планирование.
АЦК – автоматизированный центральный комплекс (ядро)
АЦК-Планирование – управление процессом планирования бюджета.
ПО, входящее в состав комплексной системы АЦК-Планирование позволяет:
Систематизировать данные, используемые при планировании бюджета;
Автоматизировать следующие процедуры:
Сбор, хранение и анализ показателей социально-экономического развития и финансового состояния субъекта РФ (МО);
Формирование многовариантного финансового плана с заданием различных временных и нормативных параметров;
Планирование доходной части бюджета с применением различных методик, алгоритмов исходя из ставок, нормативов отчислений, уровня собираемости налогов, в разрезе администраторов платежей, территорий и других параметров;
Составление проекта бюджета по расходам с применением различных методов расчета (нормативного, учетного, программно-целевого) и методик в рамках каждого метода;
Планирование межбюджетных трансфертов на уровне субъекта РФ и на уровне муниципального;
Определения допустимого уровня долговой нагрузки, структуры возможных долговых обязательств бюджета;
Визуально отображать данные планирования бюджета в следующих формах: интерактивное, табличное, текстовое и графическое представление;
Создать единую базу данных процесса планирования бюджета, актуальную и достоверную на любой момент запроса информации пользователями системы в рамках их полномочий.
Преимущества комплексной системы АЦК-Планирование:
Структурирование и централизация первичной информации по проекту составления бюджета в единой базе данных с едиными форматами документов;
Возможность получения каждым участником процесса планирования бюджета в рамках его полномочий и утвержденного регламента за счет единства базы данных абсолютно достоверной и актуальной информации на любой момент ее запроса;
Оперативное получение и использование аналитических данных, применяемых в процессе подготовки проекта бюджета;
Полная информация о расчетных показателях проекта бюджета не только в денежном, но и натуральном выражении (Гкал, КВт, кг, шт., чел/час, койко-днях, и т.п.);
Возможность выбора метода расчета соответствующей статьи бюджета (нормативный, программно-целевой, учетный) и методики расчета в рамках каждого метода;
Возможность ситуационного моделирования проекта бюджета по принципу "что-если";
Одновременная работа с различными версиями проектов бюджета, их сравнительный анализ и выбор наиболее предпочтительного варианта при изменившихся обстоятельствах;
Подключение к единому электронному документообороту системы всех участников процесса планирования вне зависимости от территориальной удаленности;
Контроль соответствия сформированного проекта бюджета соотношениям, установленным Бюджетным Кодексом РФ.
Cистема ацк - Госзаказ
АЦК – автоматизированный центральный комплекс (ядро)
АЦК-Госзаказ – управление госзакупками.
АЦК-Госзаказ разработана с целью оптимизации и автоматизации процесса осуществления гос. (муниципальных) закупок в соответствии с основными направлениями гос. политики и основными требованиями законодательства РФ.
Государственные (муниципальные) закупки (госзакупки) - это закупки, т.е. приобретение товаров, работ, услуг, для государственных (муниципальных) нужд.
Госзакупки осуществляются в соответствии со специально разработанными процедурами и правилами, закрепленными в законодательстве.
Гос. и муниципальными заказчиками могут выступать соответственно органы гос. власти РФ или органы гос. власти субъектов РФ и органы местного самоуправления, а также уполномоченные указанными органами государственной власти или органами местного самоуправления на размещение заказов получатели бюджетных средств при размещении заказов на поставки товаров, выполнение работ, оказание услуг за счет бюджетных средств.
Непоср-но формированием и размещением заказов занимается обычно заказчик.
Система АЦК-Госзаказ предполагает:
полную автоматизацию планирования и формирования заказа на основании потребностей конечных потребителей товаров и услуг (ПБС);
контроля соответствия этих потребностей принятой бюджетной росписи;
ведения базы ценовых предложений поставщиков товаров, работ, услуг для государственных (муниципальных) нужд;
автоматизацию размещения заказа (проведение торгов, без проведения торгов, электронных торгов на специальном интернет-сайте, организованном для государственного (муниципального) заказчика, автоматическое создание проектов договоров и др.);
контроль за исполнением договоров заказа (цен по заключаемым договорам; факта поставки продукции и др.).
Общие положения относительно деятельности в области государственных закупок
Основным законодательным актом, регулирующим деятельность в области государственных закупок, на сегодня является Федеральный закон от 21 июля 2005 г. N 94-ФЗ "О размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд". И др.
Общие принципы осуществления государственных закупок. Их реализация в системе АЦК-Госзаказ
равноправное и справедливое отношение ко всем поставщикам;
экономное и эфф-е расходование средств бюджетов и внебюджетных фондов;
открытость и прозрачность процесса размещения Заказа;
подотчетность;
ответственность;
проведение гос. закупок в строгом соотв-ии с утвержденной бюджетной росписью;
обязательная финансовая обеспеченность проводимых закупок.
Участники процесса осуществления государственных закупок.
Уполномоченный орган (УО) - организация, которая формирует и размещает Заказ на свободном рынке с использованием тех или иных процедур. УО не заключает сам договора, а обеспечивает их заключение Заказчиком.
Администрация региона в лице органа, организующего исполнение бюджета.
ПБС, РБС.
Поставщики товаров/услуг.
Взаимодействие участников обеспечивается установкой АРМ у каждого участника.
Интернет технологии в государственных муниципальных закупках.
Правовые основы функционирования официальных сайтов для размещения информации о размещении заказов.
Положение о пользовании официальными сайтами в сети Интернет для размещения информации о размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд и о требованиях к технологическим, программным, лингвистическим, правовым и организационным средствам обеспечения пользования указанными сайтами.
III. Требования к правовым и организационным средствам обеспечения пользования официальными сайтами
14. Уполномоченный орган обязан:
а) обеспечивать ведение официального сайта в соответствии с законодательством Российской Федерации о размещении заказов и настоящим Положением;
б) обеспечивать организацию учета информации, поступающей от лиц, указанных в пункте 5 (Информацию на соответствующих официальных сайтах размещают:
- государственные или муниципальные заказчики;
- органы, уполномоченные на размещение заказов для государственных и муниципальных нужд;
- специализированные организации, выполняющие функции по размещению заказов;
- юридические лица, обязанные размещать информацию в соответствии с законодательством Российской Федерации.) настоящего Положения;
в) предоставлять по запросам судебных и правоохранительных органов, органов, уполномоченных на осуществление контроля и нормативного правового регулирования в сфере размещения заказов, и заинтересованных организаций выписки из электронных журналов учета операций, выполненных с помощью программного обеспечения и технологических средств ведения официального сайта, подтверждающие размещение на официальном сайте информации, а также предоставлять по запросам указанных органов статистические сведения о ней.
Открытый аукцион в электронной форме (Интернет аукцион) и его место в системе государственных и муниципальных закупок.
Статья 32. Аукцион на право заключить государственный или муниципальный контракт
1. В целях настоящего Федерального закона под аукционом на право заключить государственный или муниципальный контракт понимаются торги, победителем которых признается лицо, предложившее наиболее низкую цену государственного или муниципального контракта.
2. Аукцион может быть открытым или закрытым. Заказчик, уполномоченный орган вправе размещать заказ путем проведения закрытого аукциона исключительно в случае размещения заказа на поставку товаров, выполнение работ, оказание услуг, сведения о которых составляют государственную тайну.
3. В случае, если начальная (максимальная) цена государственного или муниципального контракта (цена лота) не превышает один миллион рублей, открытый аукцион может проводиться в электронной форме на сайте в сети "Интернет" в порядке, установленном статьей 41 настоящего Федерального закона.
Статья 41. Порядок проведения открытого аукциона в электронной форме
1. Извещение о проведении открытого аукциона в электронной форме опубликовывается и размещается в порядке, установленном частями 1 и 2 статьи 33 настоящего Федерального закона, не менее чем за десять дней до даты проведения аукциона.
2. В извещении о проведении открытого аукциона в электронной форме помимо сведений, предусмотренных пунктами 1 - 7 части 4 статьи 21, пунктами 3 - 7 части 4 статьи 22, пунктом 7 части 3 статьи 33, частями 2 и 3 и пунктом 6 части 4 статьи 34 настоящего Федерального закона, указываются также сайт в сети "Интернет", на котором будет проводиться такой аукцион, дата и время начала регистрации участников аукциона на таком сайте, порядок регистрации на таком сайте, дата и время начала проведения аукциона. Документация об аукционе при проведении открытого аукциона в электронной форме не разрабатывается.
3. Доступ к участию в открытом аукционе, проводимом в электронной форме на сайте в сети "Интернет", указанном в части 2 настоящей статьи, осуществляется без взимания платы.
4. Порядок пользования сайтами в сети "Интернет", на которых осуществляется проведение открытых аукционов в электронной форме, и требования к технологическим, программным, лингвистическим, правовым и организационным средствам обеспечения пользования указанными сайтами, а также к системам, обеспечивающим проведение открытых аукционов в электронной форме, устанавливаются Правительством Российской Федерации.
5. Заказчиком обеспечивается надежность программного обеспечения, используемого для проведения открытого аукциона в электронной форме, равный доступ участников размещения заказа к участию в аукционе.
6. Для участия в открытом аукционе, проводимом в электронной форме, участники размещения заказа должны зарегистрироваться на сайте в сети "Интернет" в порядке, указанном в извещении о проведении открытого аукциона в электронной форме. Участник размещения заказа вправе зарегистрироваться на указанном сайте в любое время с даты и времени начала регистрации, указанных в извещении о проведении открытого аукциона в электронной форме, до окончания проведения открытого аукциона.
7. Представление в электронной форме предложений о цене контракта осуществляется зарегистрированным в соответствии с частью 6 настоящей статьи участником аукциона с даты и времени начала проведения аукциона, указанных в извещении о проведении открытого аукциона. При проведении открытого аукциона в электронной форме "шаг аукциона" не устанавливается.
8. С даты и времени начала проведения аукциона на сайте в сети "Интернет" должны быть указаны:
1) предмет и условия контракта;
2) начальная цена контракта;
3) порядок регистрации участников открытого аукциона;
4) в режиме реального времени последнее и предпоследнее предложения о цене контракта и время поступления указанных предложений, за исключением случаев, если в последнем предложении указывается цена контракта, равная цене контракта, указанной в предпоследнем предложении, или превышающая такую цену.
9. Аукцион считается оконченным, если в течение одного часа с момента размещения на сайте в сети "Интернет" последнего предложения о цене контракта не поступило ни одного предложения, предусматривающего более низкую цену контракта. В случае, если в нескольких предложениях указана одинаковая наиболее низкая цена контракта, победителем аукциона признается участник аукциона, предложение о цене контракта которого поступило ранее других предложений. Информация об окончании аукциона должна размещаться на таком сайте немедленно.
10. В течение одного часа с момента окончания аукциона, проводимого на сайте в сети "Интернет" в электронной форме, на указанном сайте размещаются решение о признании участника аукциона победителем аукциона, информация о цене контракта, последнем и предпоследнем предложениях о цене контракта, наименование (для юридического лица), фамилия, имя, отчество (для физического лица) победителя аукциона и участника аукциона, который сделал предложение о цене контракта, равной цене, предложенной победителем аукциона, при отсутствии такого участника аукциона - участника аукциона, который сделал предпоследнее предложение о цене контракта.
…
15. Аукцион признается несостоявшимся в случае, если в аукционе участвовал один участник аукциона или если в течение одного часа с момента начала проведения аукциона не представлено ни одно предложение о цене контракта, предусматривающее более низкую цену контракта. В этом случае заказчик, уполномоченный орган вправе объявить о проведении повторного аукциона или размещении заказа путем запроса котировок, если цена контракта не превышает двести пятьдесят тысяч рублей.
Cистема ацк - Госзаказ
АЦК – автоматизированный центральный комплекс (ядро)
АЦК-Госзаказ – управление госзакупками.
АЦК-Госзаказ разработана с целью оптимизации и автоматизации процесса осуществления гос. (муниципальных) закупок в соответствии с основными направлениями гос. политики и основными требованиями законодательства РФ.
Государственные (муниципальные) закупки (госзакупки) - это закупки, т.е. приобретение товаров, работ, услуг, для государственных (муниципальных) нужд.
Госзакупки осуществляются в соответствии со специально разработанными процедурами и правилами, закрепленными в законодательстве.
Гос. и муниципальными заказчиками могут выступать соответственно органы гос. власти РФ или органы гос. власти субъектов РФ и органы местного самоуправления, а также уполномоченные указанными органами государственной власти или органами местного самоуправления на размещение заказов получатели бюджетных средств при размещении заказов на поставки товаров, выполнение работ, оказание услуг за счет бюджетных средств.
Непоср-но формированием и размещением заказов занимается обычно заказчик.
Система АЦК-Госзаказ предполагает:
полную автоматизацию планирования и формирования заказа на основании потребностей конечных потребителей товаров и услуг (ПБС);
контроля соответствия этих потребностей принятой бюджетной росписи;
ведения базы ценовых предложений поставщиков товаров, работ, услуг для государственных (муниципальных) нужд;
автоматизацию размещения заказа (проведение торгов, без проведения торгов, электронных торгов на специальном интернет-сайте, организованном для государственного (муниципального) заказчика, автоматическое создание проектов договоров и др.);
контроль за исполнением договоров заказа (цен по заключаемым договорам; факта поставки продукции и др.).
Общие положения относительно деятельности в области государственных закупок
Основным законодательным актом, регулирующим деятельность в области государственных закупок, на сегодня является Федеральный закон от 21 июля 2005 г. N 94-ФЗ "О размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд". И др.
Общие принципы осуществления государственных закупок. Их реализация в системе АЦК-Госзаказ
равноправное и справедливое отношение ко всем поставщикам;
экономное и эфф-е расходование средств бюджетов и внебюджетных фондов;
открытость и прозрачность процесса размещения Заказа;
подотчетность;
ответственность;
проведение гос. закупок в строгом соотв-ии с утвержденной бюджетной росписью;
обязательная финансовая обеспеченность проводимых закупок.
Участники процесса осуществления государственных закупок.
Уполномоченный орган (УО) - организация, которая формирует и размещает Заказ на свободном рынке с использованием тех или иных процедур. УО не заключает сам договора, а обеспечивает их заключение Заказчиком.
Администрация региона в лице органа, организующего исполнение бюджета.
ПБС, РБС.
Поставщики товаров/услуг.
Взаимодействие участников обеспечивается установкой АРМ у каждого участника.
17.
18. Бухгалтерские информационные системы.
Бухгалтерские информационные системы отражают отраслевые особенности деятельности предприятий, различаются по функциям, принципам построения, техническому и методологическому сопровождению, оказываемым дополнительным услугам и другим признакам.
Особенности бухгалтерских информационных систем:
разрабатываются применительно к малым, средним и большим предприятиям;
бывают универсальными или специализированными;
используются для целей управления на уровне отдельного предприятия или отраслевом уровне;
ориентируются на разный вид собственности;
используют разный тип настройки.
Компоненты бухгалтерских информационных систем:
информационная база объекта управления;
программное обеспечение;
вычислительная система;
пользователи.
Основу бухгалтерских информационных систем составляет информация — совокупность количественных данных, необходимых для выполнения функций планирования, контроля, анализа и являющихся основой для принятия управленческих решений.
На различных предприятиях бухгалтерский учет организуется по-разному.
На крупных предприятиях реализуются все виды учета — первичный, управленческий, финансовый учет, каждый из которых решает свои задачи;
На уровне первичного учета осуществляется сбор, регистрация, частичная обработка информации.
На уровне управленческого учета формируются результатные данные, отражающие совершаемые хозяйственные операции в стоимостной оценке в виде файлов бухгалтерских проводок;
На уровне финансового учета реализуется сводный учет, формируется Главная книга, бухгалтерский баланс и другие отчетные регистры.
На каждом уровне управления создаются автоматизированные рабочие места специалистов-экономистов, бухгалтеров, финансистов, аналитиков, взаимодействующие между собой.
К задачам бухгалтерских информационных систем относятся:
автоматизированное решение всего комплекса задач бухгалтерского учета, планирования, анализа финансово-хозяйственной деятельности, внутреннего аудита;
получение достоверной оперативной информации о текущем состоянии дел на предприятии для принятия на ее основе необходимых управленческих решений.
интеграция оперативного, бухгалтерского, статистического учета на основе единой первичной информации;
автоматизация обработки информации на всех стадиях техпроцесса, начиная со стадии первичного учета.
Бухгалтерская информация
Чтобы бухгалтерская информация однозначно воспринималась и понималась теми, кто участвовал в ее подготовке на предприятии, и теми, кто использует ее вне предприятия, она должна удовлетворять определенным требованиям.
Бухгалтерская информация должна удовлетворять требованиям сравнения и постоянства, т. е. нельзя в течение учетного периода использовать разные формы и методы бухгалтерского учета. В этом случае пропадает возможность сравнения данных. Однако это не означает, что устаревший или неудачно выбранный метод бухгалтерского учета должен использоваться бесконечно долго. Для изменения используемой системы учета должны быть веские основания. Такие изменения можно совместить с началом нового учетного периода (года).
Бухгалтерская информация должна быть существенной. Не следует терять время на учет незначительных факторов, т. е. если усилия по учету сравнимы со стоимостью учитываемых средств, то учет необходимо упростить. Каждое предприятие выбирает свой уровень существенности учета. Так, в зависимости от того, какое значение придается объекту, в одном случае он может быть отнесен к основным средствам, а в другом — сразу списан на затраты.
Бухгалтерская информация должна быть консервативной. Так как отражение фактов хозяйственной деятельности в бухгалтерском учете не всегда является однозначным, необходимо выбирать оценку, которая менее оптимистична. Это означает, что следует рассчитывать на отсутствие прибыли и учитывать возможные убытки. Данная особенность обеспечивает осторожность в оценке активов, имущества и в определении величины прибыли.
Бухгалтерская информация должна быть полной, содержать максимум того, что необходимо пользователю.
Бухгалтерская учетная информационная система (БУИС)
В целях получения информации, необходимой для управления производственной и хозяйственной деятельностью, предприятие на базе современных информационных технологий создает систему автоматизированной обработки учетной информации, или БУИС.
Современные информационные технологии позволяют унифицировать и существенно облегчить трудоемкий процесс формирования учетной информации, обеспечить оперативность получения финансовой отчетности предприятия для принятия решений.
В этой связи БУИС рассматривается как существенный инструмент управления деятельностью предприятия в условиях рынка.
Такая система служит связующим звеном между хозяйственной деятельностью и людьми, принимающими решения. В ней осуществляется сбор, регистрация данных о хозяйственной деятельности на предприятии в первичных документах, их обработка, накопление, формирование финансово-экономических показателей отчетов, передача информации пользователям для анализа и принятия решений.
Таким образом, данные о хозяйственной деятельности являются входом в БУИС, а полезная информация для лиц, принимающих решения, — выходом из нее.
Главная цель функционирования БУИС на предприятии — обеспечить руководство предприятия финансовой информацией для принятия обоснованных решений при выборе альтернативных вариантов использования ограниченных ресурсов.
В БУИС осуществляется интеграция различных видов учета (оперативного, бухгалтерского и статистического) на основе единой первичной информации. При этом слияния этих видов учета не происходит, так как каждый из них выполняет свои функции и решает свои задачи.
Принцип обратной связи является одним из основных принципов любой системы управления. Однако осуществить обратную связь можно только решив задачи бухгалтерского учета.
Существует несколько видов БУИС.
БУИС для крупного предприятия должна обеспечивать:
автоматизированное решение всего комплекса задач бухгалтерского учета в соответствии с российским и международными стандартами, анализ финансово-хозяйственной деятельности предприятия, планирование, а также внутренний аудит;
получение оперативной, постоянно меняющейся информации о текущем состоянии дел на предприятии. Такой режим важен, например, для крупных промышленных предприятий, имеющих отдаленные подразделения, филиалы, с целью более эффективного использования их ресурсов, а также для предприятий, работающих в сфере оптовой торговли, которые контактируют с большим количеством клиентов, требующих оперативную информацию об ассортименте, текущих ценах, наличии товара на складах и условиях его поставки. Основной акцент при этом должен быть сделан на получении оперативных аналитических отчетов и сводок по использованию вложенных финансовых ресурсов;
возможность консолидированного управления и получения консолидированных финансовых отчетов.
Крупные предприятия могут иметь филиалы или удаленные склады. Кроме того, финансы такого предприятия могут принадлежать группе собственников. Поэтому актуальным является наличие в такой системе удаленных рабочих мест с возможностью осуществлять обмен данными для оперативного управления из центра.
БУИС крупного предприятия, отвечающую всем требованиям, можно создать на основе комплекса функционально взаимосвязанных АРМ специалистов. Такая БУИС относится к комплексным бухгалтерским системам.
БУИС на малых и средних предприятиях. При создании БУИС на малых и средних предприятиях использование ПК позволяет автоматизировать все процедуры по обработке информации на рабочем месте бухгалтера. В отличие от крупных предприятий на малых и средних предприятиях основное внимание уделяется ведению финансового учета. По трудоемкости и значимости данный вид бухгалтерского учета на таких предприятиях занимает главное место. Он направлен на обобщение, синтез учетной информации.
Существует несколько подходов к автоматизации бухгалтерского учета при создании БУИС. Это связано с тем, что небольшие предприятия с простой и слаборазвитой структурой не требуют ведения управленческого учета как отдельной подсистемы.
При первом подходе создается система, автоматизирующая только финансовый учет. Такую БУИС относят к классу «мини-бухгалтерий». Как правило, бухгалтерский учет в этой системе ведется с помощью одного-трех человек.
При втором подходе, кроме финансового учета, частично автоматизируется управленческий учет. В этом случае бухгалтерский учет могут вести от двух и более человек (бухгалтер и его помощники).
Автоматизация финансового и управленческого учета достигается при третьем подходе. В такой системе в случае значительных объемов обрабатываемой информации используется многопользовательский режим. Несколько компьютеров объединяются в локальную сеть, а каждый из компьютеров рассматривается как отдельное рабочее место бухгалтера. Выбор подхода зависит от типа предприятия и его размеров.
В настоящее время создание современных БУИС ориентировано на интегрированность в отношении автоматизации бухгалтерского учета анализа отчетности и планирования деятельности предприятия.
Интегрированные БУИС — это многофункциональные системы для управления предприятием. Необходимость создания таких систем очевидна для значительной части отечественных предприятий как производственной, так и торговой сферы.
Подобные системы должны обеспечивать решение всего комплекса задач по обработке учетной информации: сбора и проверки корректности информации, поступающей в базу данных, ее обработки по соответствующим алгоритмам до анализа данных, причем от пользователя в таких системах не требуется специальных знаний в области баз данных, факторного анализа или методов оптимизации.
Для создания интегрированных БУИС целесообразно использование компьютерной технологии «клиент-сервер». Установка мощных серверов или закупка СУБД, требует немалых финансовых средств, привлечения высококвалифицированных специалистов, а также программной и аппаратной модернизации всей системы учета на предприятии, что делает такой проект дорогостоящим.
Разработка интегрированной БУИС для комплексного бухгалтерского учета, финансового анализа и планирования на предприятии с использованием приложений, построенных в архитектуре «клиент-сервер», имеет ряд преимуществ:
чрезвычайно низкие требования к производительности рабочих станций;
возможность распределить задачи по обработке данных среди нескольких
Дальнейшее развитие бизнеса, деловых процессов, происходящих внутри предприятий, потребовало от БУИС расширенных возможностей и перехода от упрощенного учета к универсальному.
Для пользователей БУИС — квалифицированных бухгалтеров — была необходима автоматизация не только всех учетных задач, но и получение своевременной и оперативной финансовой информации для повышения эффективности управления предприятием, сохранения финансового равновесия, получения стабильной прибыли.
Потребовались бухгалтерские системы, работающие в сети. В этой связи появились комплексные бухгалтерские системы, такие, как «АВАС118», рассчитанный на бухгалтерию в 50-60 человек (фирма «Омега»); «Интегратор» (фирма «ИнфоСофт»); «БЭСТ» — для комплексной автоматизации предприятий
Из известных на российском рынке программ данного класса можно выделить: «Учет товаров и материалов» (фирма «Паритет-Софт»), «Склад» (фирма «Фолио»); «Торговый склад» (фирма «Компьютер-Сервис»); «Склад» (фирма «Инфин»); «Парус — Реализация Склад» (корпорация «Парус»); «1С-зарплата» (фирма «1С»); «Заработная плата» (фирма «Паритет-Софт»); «Мини-зарплата», «Макси-зарплата», «Супер-зарплата» (фирма «Инфин»); «Зарплата» (корпорация «Рарус») и др.
19. Информационные системы в образовании.
Современный период развития общества характеризуется сильным влиянием на него компьютерных технологий, которые проникают во все сферы человеческой деятельности, обеспечивают распространение информационных потоков в обществе, образуя глобальное информационное пространство. Неотъемлемой и важной частью этих процессов является компьютеризация образования. В настоящее время в России идет становление новой системы образования, ориентированного на вхождение в мировое информационно-образовательное пространство. Этот процесс сопровождается существенными изменениями в педагогической теории и практике учебно-воспитательного процесса, связанными с внесением корректив в содержание технологий обучения, которые должны быть адекватны современным техническим возможностям, и способствовать гармоничному вхождению ребенка в информационное общество. Компьютерные технологии призваны стать не дополнительным «довеском» в обучении, а неотъемлемой частью целостного образовательного процесса, значительно повышающей его эффективность.
Направления внедрения средств новых информационных технологий в образование.
Современные новые информационные технологии могут быть использованы в качестве:
Средства обучения, совершенствующего процесс преподавания, повышающего его эффективность и качество. При этом обеспечивается:
реализация возможностей программно-методического обеспечения современных ЭВМ и др. в целях сообщения знаний, моделирования учебных ситуаций. осуществления тренировки, контроля за результатами обучения;
использование объектно-ориентированных программных средств или систем (например, системы подготовки текстов, электронных таблиц, баз данных) в целях формирования культуры учебной деятельности;
реализация возможностей систем искусственного интеллекта в процессе применения обучающих интеллектуальных систем.
Инструмента познания окружающей действительности и самопознания.
Средства развития личности обучаемого.
Объекта изучения (например, в рамках освоения курса информатики).
Средства информационно—методического обеспечения и управления учебно—воспитательным процессом, учебными заведениями, системой учебных заведений.
Средства коммуникаций (например, на базе асинхронной телекоммуникационной связи) в целях распространения передовых педагогических технологий.
Средства автоматизации процессов контроля, коррекции результатов учебной деятельности, компьютерного педагогического тестирования и психодиагностики.
Средства автоматизации процессов обработки результатов эксперимента (лабораторного, демонстрационного) а управления учебным оборудованием.
Средства организации интеллектуального досуга, развивающих игр.
Создание опережающей информационной среды непрерывного российского образования требует решения ряда методических и организационных проблем, в том числе следующих:
Принятие единой системы программно и аппаратно совместимых средств вычислительной техники и техники связи, используемой в непрерывном учебном процессе. Это требует сертификации используемых средств учебного назначения и реализации программы по созданию сертификационных центров и эффективному их использованию.
Подключение образовательных организаций к единой цифровой сети в последующим выходом в Интернет. Решение этой задачи в значительной степени реализуется в настоящее время в высшем образовании и сдерживается в школьном образовании по финансовым причинам, а также и по причине сложности ее реализации для отдаленных районов.
Формирование единой информационной среды непрерывного образования с созданием баз данных по направлениям и специальностям подготовки, которые бы включали в себя методические документы, энциклопедии, справочники, учебники и учебные пособия, а также дополнительные средства, поддерживающие учебный процесс. Актуальным является представление в международной сети наших достижений и возможностей. Необходима организация обмена информационными ресурсами российской образовательной системы с международной.
Необходимо совершенствование инструментальных средств непрерывного образования, ориентированных на ускоренное освоение материала и приобретение устойчивых навыков обучаемых, а также преследующих цели индивидуального обучения. Сюда можно отнести перспективные программные оболочки по разработке компьютерных учебников и методических материалов, программные и аппаратные средства создания компьютерных обучающих систем, средства технологии разработки мультимедиа продуктов, геоинформационных систем т.д.
Необходима организация инфраструктуры информатизации образования как составной части информатизации общества в целом. Эта структура должна обеспечить создание новых, тиражирование и внедрение существующих информационных технологий в непрерывное образование.
Реализация указанных путей внедрения информационных технологий в образование возможно через Научно-методические советы по специальностям и Координационно-методические советы по направлениям подготовки. Они должны взять на себя курирование и контроль внедрения новых компьютерных средств обучения в учебный процесс и учебно-исследовательскую работу студентов по данным направлениям. Необходимо поднять статус электронного учебника, электронного учебного пособия, приравняв их по значимости к типовым традиционным средствам обучения, изданным на бумажном носителе. Следует особое внимание уделить изучению новых информационных технологий при подготовке педагогических кадров. Программы подготовки учителей по различным специальностям должны предусматривать обучение их современным информационным технологиям и привитие им навыков работы на компьютере
Идеологически при информатизации образования необходимо учитывать ряд принципиальных позиций:
Эволюционное развитие сложившейся методологии образования за счет явных преимуществ новых информационных технологий, а именно, возможность наглядного, динамичного представления информации с использованием изображений и звука, применения удаленного доступа к информационным ресурсам.
Непрерывность и преемственность компьютерного образования на всех уровнях обучения от дошкольного до послевузовского. Непрерывность может быть обеспечена компьютерной поддержкой всех предметов и дисциплин учебного процесса.
Обеспечение свободы выбора методики, стиля и средств обучения с целью выявления творческих индивидуальных способностей обучаемого в сочетании с возможностью их коллективной деятельности на основе информационных технологий и телекоммуникационных систем.
Создание научно и методически обоснованной системы базового образования на основе компьютерных технологий. Одним из реальных путей решения проблемы в целом является формирование и реализация региональных научно-технических программ с долевым федеральным и местным бюджетным финансированием при дополнительном использовании внебюджетных средств.
Система образования и новые информационные и коммуникационные технологии.
Вопрос о роли современных информационных, а в последнее время и коммуникационных технологий в деле совершенствования и модернизации сложившейся образовательной системы является актуальным на протяжении последних двух десятилетий. Однако, наибольшую остроту он получил в ходе внедрения в практику учебного процесса относительно недорогих и поэтому доступных персональных компьютеров, объеденных как в локальные сети, так и имеющих выход в глобальную сеть Internet. Для успешной реализации программы модернизации среднего образования, во многом базирующегося на компьютеризации и «интернетизации», потребуется не только современное техническое оснащение учебных заведений, но и соответствующая подготовка педагогов и организация системы образования.
Для каждого педагога, будь то школьный учитель или вузовский преподаватель, главная цель – обеспечение качества образования, чему в большей степени может способствовать использование информационных и коммуникационных технологий. В тоже время для руководителя помимо качества очень важной задачей является организация максимально широкого доступа к имеющемуся оборудованию и другим учебным ресурсам. И зачастую вместо обеспечения доступного качественного образования делается выбор в пользу решения только одной из этих задач.
Применение информационных технологий и коммуникационных технологий в высшем образовании традиционно сводится к двум основным направлениям. Первое состоит в использовании возможностей этих технологий для увеличения доступности образования, что осуществляется путём включения в систему образования тех лиц, для которых иной способ может быть вообще недоступен. Необходимо сказать, что такая дистанционная форма обучения встречает множество возражений. Её противники справедливо отмечают, что будущие студенты лишены всего того, что требуется для получения подлинно качественного образования: работа в лабораториях, доступ к научным библиотекам, общение с преподавателями и другими студентами на семинарах и в неофициальной обстановке.
Второе направление предполагает использование информационных технологий для изменения того, чему учить и как учить, т.е. содержания и способов обучения в рамках традиционной очной формы. Но здесь возникает весьма щепетильная проблема, связанная с тем, что внедрение передовых технологий часто создаёт дополнительные преимущества наиболее успевающим, активным и способным клиентам, не влияя на уровень подготовки основной массы.
В сложившейся структуре встаёт вопрос о доступности и качестве образования. Переход к реальной информатизации общего образования возможен на основе единой образовательной информационной среды, формируемой всеми участниками информационного процесса.
Создание такой среды может начаться со школьной Internet-библиотеки с наглядным и доступным для учащихся структурированным предоставлением информации. Организация широкого доступа к необходимым учебным ресурсам на практике способствует кооперации учебных заведений различного уровня по созданию регионального образовательного пространства.
Но в упрощённом, но, к сожалению, распространённом представлении утверждается, что всё решает просто широкое внедрение информационных и телекоммуникационных технологий, которым приписывается воистину волшебная сила. И в этом случае обществу предлагают весьма простое решение – достаточно обеспечить учебные заведения компьютерами и средствами телекоммуникаций и образование, как по мановению волшебной палочки, станет дешевле, качественнее и доступней. Но даже самые лучшие и передовые технологии, взятые на вооружение педагогами и обучаемыми, без адекватной реорганизации учебно-воспитательного процесса оказывают деморализующее влияние и попросту расточительны.
Прагматический подход к использованию информационных технологий предполагает: с их помощью образование можно сделать более доступным с предположением возможных потерь в качестве или повысить качество образования, но для ограниченного, наиболее подготовленного контингента обучаемых.
Другая трудность, которую нельзя оставить без внимания, это увеличение ответственности самого обучаемого за результаты обучения в ситуации, когда ему предоставляется множество возможностей выбора между различными формами обучения, лавина нужной и посторонней информации и посторонней информации в условиях дефицита времени. И в этих условиях педагоги должны помочь обучаемым в правильной организации их учебной деятельности с учётом их индивидуальных особенностей и возможностей.
Чрезвычайно опасна потеря контактов между обучаемыми, преподавателями и обучаемыми, а также в среде самих преподавателей. В этой ситуации обучаемые и преподаватели перестают ощущать себя членами единого сообщества, им остаются только роли получающих и предоставляющих знания анонимов.
Комплект программных и методических средств поддержки дистанционного обучения «Пегас»
Комплект «Пегас» состоит из следующих компонентов:
1) Методические средства. Регламентируют состав учебно-методических комплексов и процесс подготовки учебно-методических комплексов (УМК). Помогают авторам УМК правильно подготовить материалы УМК в текстовом редакторе Word.
Состав методических средств:
Положение об УМК (образец);
Методические указания на формирование УМК;
Шаблоны документов УМК;
Обучающий ролик UsingGIFTTemplate.swf.
В «Положении о составе и структуре учебно-методических комплексов дисциплин (курсов, предметов)» описаны состав и структура УМК электронных средств поддержки дистанционного обучения.
В минимальный состав каждого УМК должны быть включены:
Презентация учебной дисциплины.
Рабочая программа.
Учебно-практическое пособие.
Тестовые задания.
Хрестоматия.
В Методических указаниях на формирование УМК акцентировано внимание на технические требования к оформлению материалов учебно-методических комплексов в текстовом редакторе Word и подготовку презентации УМК в редакторе PowerPoint. Кроме того, в данном документе приводятся примеры оформления элементов УМК и описываются необходимые приемы оформления.
Использование шаблонов документов УМК позволяет упростить процедуру подготовки материалов учебно-методического комплекса. В них изначально задана нужная структура тех или иных элементов УМК. Кроме того, использование шаблонов позволяет унифицировать оформление учебно-методические комплексы различных авторов, по различным дисциплинам.
2) Комплекс программных средств (КПС). Позволяют осуществить проверку технической составляющей подготовки материалов УМК; конвертацию документов формата Word в формат HTML и формирование архивов для дальнейшей публикации в системах дистанционного обучения типа Moodle, генерацию архивных файлов для дальнейшего «локального» просмотра материалов УМК с помощью программы «Пегас Контент Плеер».
Состав программных средств:
«Пегас Просмотр»
«Пегас Конвертер»;
«Пегас Генератор»;
«Пегас Контент Плеер».
20. Системы автоматизированного проектирования. Математическое обеспечение сапр.
Система автоматизированного проектирования (САПР) - это совокупность средств и методов для осуществления автоматизированного проектирования. Она состоит из нескольких составных частей, называемых техническим, математическим, программным, лингвистическим, информационным, методическим и организационным обеспечением.
Система автоматизации проектных работ (САПР) или CAD (англ. Computer-Aided Design) — программный пакет, предназначенный для создания чертежей, конструкторской и/или технологической документации и/или 3D моделей. В современных системах проектирования CAD получает данные из систем твёрдотельного моделирования CAE (Computer-aided engineering), и передаёт в CАМ (Computer-aided manufacturing) для подготовки производства.
Обычно охватывает создание геометрических моделей изделия (твердотельных, трехмерных, составных), а также генерацию чертежей изделия и их сопровождение. Следует отметить, что русский термин «САПР» по отношению к промышленным системам имеет более широкое толкование, чем «CAD» — он включает в себя как CAD, так и элементы CAM, а иногда и элементы CAE.
Российские САПР
IndorCAD — система проектирования автомобильных дорог компании ИндорСофт
T-FLEX CAD — российская САПР для машиностроения
TopoR - российский САПР для проектирования печатных плат
КОМПАС — распространённая российская САПР компании АСКОН
Bcad - российская САПР. Основные направления: проектирование мебели и дизайн интерьеров.
САПР не российских производителей
AutoCAD — САПР для архитектуры самая распространённая САПР не российского производства.
Autodesk Inventor — система трехмерного твердотельного проектирования для разработки сложных машиностроительных изделий.
Cadmech- универсальная САПР для машиностроения
Electric — проектирование электропроводки.
MathCAD — математическое моделирование
OrCAD — САПР для проектирования электронных устройств
P-CAD — САПР для проектирования электронных устройств
Pro/Engineer — универсальная САПР для машиностроения
Rhinoceros — универсальный САПР для промышленного дизайна
SolidEdge — 2D/3D CAD-система.
SolidWorks- универсальная САПР для машиностроения
Составные части САПР
Техническое обеспечение САПР представляет собой совокупность взаимосвязанных и взаимодействующих технических средств, предназначенных для выполнения автоматизированного проектирования. Техническое обеспечение делится на группы средств программной обработки данных, подготовки и ввода данных, средств отображения и документирования, архива проектных решений, средств передачи данных.
Средства программной обработки данных представлены процессорами и запоминающими устройствами, т.е. устройствами ЭВМ, в которых реализуются преобразования данных и программное управление вычислениями. Средства подготовки, ввода, отображения и документирования данных служат для общения человека с ЭВМ. Средства архива проектных решений представлены внешними запоминающими устройствами. Средства передачи данных используются для организации связей между территориально разнесенными ЭВМ и терминалами (оконечными пунктами).
Математическое обеспечение САПР включает в себя математические модели (ММ) проектируемых объектов, методы и алгоритмы проектных процедур, используемые при автоматизированном проектировании. Элементы математического проектирования САПР чрезвычайно разнообразны. К ним относятся принципы построения функциональных моделей, методы численного решения алгебраических и дифференциальных уравнений, постановки экстремальных задач, поиска экстремума и т.д. Специфика предметных областей проявляется прежде всего в ММ проектируемых объектов, она заметна и в способах решения задач структурного синтеза. Формы представления математического обеспечения также довольно разнообразны, но его практическое использование происходит после реализации в программном обеспечении.
Программное обеспечение САПР объединяет собственно программы для систем обработки данных на машинных носителях и программную документацию, необходимую для эксплуатации программы. Программное обеспечение (ПО) делится на общесистемное, базовое и прикладное (специальное). Общесистемное ПО предназначено для организации функционирования технических средств, т.е. для планирования и управления вычислительным про цессом, распределения имеющихся ресурсов, и представлено операционными системами ЭВМ и ВС. Общесистемное ПО обычно создается для многих приложений и специфики САПР не отражает. Базовое и прикладное ПО создаются для нужд САПР. В базовое ПО входят программы, обеспечивающие правильное функционирование прикладных программ.
В прикладном ПО реализуется математическое обеспечение для непосредственного выполнения проектных процедур. Прикладное ПО обычно имеет форму пакетов прикладных программ (ППП), каждый из которых обслуживает определенный этап процесса проектирования или группу однотипных задач внутри различных этапов.
Информационное обеспечение САПР объединяет всевозможные данные, необходимые для выполнения автоматизированного проектирования. Эти данные могут быть представлены в виде тех или иных документов на различных носителях, содержащих сведения справочного характера о материалах, комплектующих изделиях, типовых проектных решениях, параметрах элементов, сведения о состоянии текущих разработок в виде промежуточных и окончательных проектных решений, структур и параметров проектируемых объектов и т.п. Основная часть информационного обеспечения САПР - банк данных, представляющий собой совокупность средств для централизованного накопления и коллективного использования данных в САПР. Банк данных (БНД) состоит из базы данных и системы управления базой данных.
База данных (БД) - сами данные, находящиеся в запоминающих устройствах ЭВМ и структурированные в соответствии с принятыми в данной БД правилами. Система управления базой данных (СУБД) - совокупность программных средств, обеспечивающих функционирование БД. С помощью СУБД производятся запись данных в БД, их выборка по запросам пользователей и прикладных программ, обеспечивается защита данных от искажений, несанкционированного доступа и т.п.
Лингвистическое обеспечение САПР представлено совокупностью языков, применяемых для описания процедур автоматизированного проектирования и проектных решений. Основная часть лингвистического обеспечения - языки общения человека с ЭВМ.
Методическое обеспечение САПР составляют документы, характеризующие состав, правила отбора и эксплуатации средств автоматизированного проектирования. Допускается более широкое толкование понятия методического обеспечения, при котором под методическим обеспечением подразумевают совокупность математического, лингвистического обеспечения и названных документов, реализующих правила использования средств проектирования.
Организационное обеспечение САПР включает положения, инструкции, приказы, штатные расписания, квалификационные требования и другие документы, регламентирующие организационную структуру подразделений проектной организации и их взаимодействие с комплексом средств автоматизированного проектирования.
МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ САПР
Математическое обеспечение САПР состоит из математических моделей объектов проектирования, методов и алгоритмов выполнения проектных операций и процедур.
В математическом обеспечении САПР можно выделить специальную часть, в значительной мере отражающую специфику объекта проектирования, физические и информационные особенности его функционирования и тесно привязанную к конкретным иерархическим уровням (эта часть охватывает математические модели, методы и алгоритмы их получения, методы и алгоритмы одновариантного анализа, а также большую часть используемых алгоритмов синтеза), и инвариантную часть, включающую в себя методы и алгоритмы, слабо связанные с особенностями математических моделей и используемые на многих иерархических уровнях (это методы и алгоритмы многовариантного анализа и параметрической оптимизации).
ТРЕБОВАНИЯ К МАТЕМАТИЧЕСКОМУ ОБЕСПЕЧЕНИЮ
Свойства математического обеспечения (МО) оказывают существенное, а иногда и определяющее влияние на возможности и показатели САПР.
При
выборке и разработке моделей, методов
и алгоритмов необходимо учитывать
требования, предъявляемые к МО в САПР.
Рассмотрим основные из них
.
Универсальность
Под универсальностью МО понимается его применимость к широкому классу проектируемых объектов. Одно из отличий расчетных методов в САПР от ручных расчетных методов - высокая степень универсальности. Например, в подсистеме схемотехнического проектирования САПР ИЭТ используются математические модели транзистора, справедливые для любой области работы (активной, насыщения, отсечки, инверсной активной), а методы получения и анализа моделей применимы к любой аналоговой или переключательной схеме на элементах из разрешенного списка; в подсистеме структурного проектирования САПР ЭВМ используются модели и алгоритмы, позволяющие исследовать стационарные и нестационарные процессы переработки информации при произвольных законах обслуживания в устройствах ВС и при произвольных входных потоках.
Высокая степень универсальности МО нужна для того, чтобы САПР была применима к любым или большинству объектов, проектируемых на предприятии.
Алгоритмическая надежность
Методы и алгоритмы, не имеющие строгого обоснования, называют эвристическими. Отсутствие четко сформулированных условий применимости приводит к тому, что эвристические методы могут использоваться некорректно. В результате либо вообще не будет получено решение (например, из-за отсутствия сходимости), либо оно будет далеким от истинного. Главная неприятность заключается в том, что в распоряжении инженера может не оказаться данных, позволяющих определить, корректны или нет полученные результаты. Следовательно, возможна ситуация, когда неверное решение будет использоваться в дальнейшем как правильное .
Свойство компонента МО давать при его применении в этих условиях правильные результаты называется алгоритмической надежностью. Степень универсальности характеризуется заранее оговоренными ограничениями, а алгоритмическая надежность - ограничениями, заранее не выявленными и, следовательно, не оговоренными.
Количественной оценкой алгоритмической надежности служит вероятность получения правильных результатов при соблюдении оговоренных ограничений на применение метода. Если эта вероятность равна единице или близка к ней, то говорят, что метод алгоритмически надежен .
Применение алгоритмичности ненадежных методов в САПР нежелательно, хотя и допустимо в случаях, когда неправильные результаты легко распознаются.
С проблемой алгоритмической надежности тесно связана проблема обусловленности математических моделей и задач. О плохой обусловленности говорят в тех случаях, когда малые погрешности исходных данных приводят к большим погрешностям результатов. На каждом этапе вычислений имеются свои промежуточные исходные данные и результаты, свои источники погрешностей. При плохой обусловленности погрешности могут резко возрасти, что может привести как к снижению точности, так и к росту затрат машинного времени .
Точность
Для большинства компонентов МО важным свойством является точность, определяемая по степени совпадения расчетных и истинных результатов. Алгоритмически надежные методы могут давать различную точность. И лишь в тех случаях, когда точность оказывается хуже предельно допустимых значений или решение вообще невозможно получить, говорят не о точности, а об алгоритмической надежности.
В большинстве случаев решение проектных задач характеризуется:
совместным использованием многих компонентов МО, что затрудняет определение вклада в общую погрешность каждого из компонентов;
векторным характером результатов (например, при анализе находят вектор выходных параметров, при оптимизации - координаты экстремальной точки), т.е. результатом решения является значение не отдельного параметра, а многих параметров.
В связи с этим оценка точности производится с помощью специальных вычислительных экспериментов. В этих экспериментах используются специальные задачи, называемые тестовыми. Количественная оценка погрешности результата решения тестовой задачи есть одна из норм вектора относительных погрешностей: m-норма или l-норма, где l - относительная погрешность определения j-го элемента вектора результатов; m - размерность этого вектора.
Затраты машинного времени
Универсальные модели и методы характеризуются сравнительно большим объемом вычислений, растущим с увеличением размерности задач. Поэтому при решении большинства задач в САПР затраты машинного времени Tм значительны. Обычно именно Tм являются главным ограничивающим фактором при попытках повысить сложность проектируемых на ЭВМ объектов и тщательность их исследования. Поэтому требование экономичности по Tм - одно из основных требований к МО САПР.
При использовании в САПР многопроцессорных ВС уменьшить время счета можно с помощью параллельных вычислений. В связи с этим один из показателей экономичности МО - его приспособленность к распараллеливанию вычислительного процесса.
В САПР целесообразно иметь библиотеки с наборами моделей и методов, перекрывающими потребности всех пользователей САПР.
Используемая память
Затраты памяти являются вторым после затрат машинного времени показателем экономичности МО. Они определяются длиной программы и объемом используемых массивов данных. Несмотря на значительное увеличение емкости оперативной памяти в современных ЭВМ, требование экономичности по затратам памяти остается актуальным. Это связано с тем, что в мультипрограммном режиме функционирования ЭВМ задача с запросом большого объема памяти получает более низкий приоритет и в результате время ее пребывания в системе увеличивается.
Улучшить экономичность по затратам оперативной памяти можно путем использования внешней памяти. Однако частые обмены данными между оперативной памятью и внешней могут привести к недопустимому росту Tм. Поэтому при больших объемах программ и массивов обрабатываемой информации целесообразно использовать МО, допускающее построение оверлейных программных структур и реализующее принципы диакоптической обработки информации.
22. Плоские графические элементы при моделировании деталей и узлов средствами систем автоматизированного проектирования.
Плоские графические элементы при моделировании деталей и узлов на примере Autodesk Inventor 10 и AutoCAD
При моделировании деталей с помощью плоских графических элементов основой является эскиз.
Эскизы служат для определения форм и размеров очертаний конструктивных элементов, траекторий, а также для размещения центров отверстий. После создания конструктивных элементов контур, траектории и центры отверстий поглощаются ими.
Эскизы размещаются на плоскостях построений, где и выполняется построение отрезков, дуг и другой геометрии. Наложение зависимостей при рисовании выполняется автоматически. Законченный эскиз используется как контур, на основе которого строится конструктивный элемент путем выдавливания, вращения, сдвига, натягивания или созданием пружины. Кроме того, эскизы могут определять траектории для таких операций, как сдвиг. В чертежах эскизная геометрия служит для создания обозначений, основных надписей и рамок.
В эскизах может присутствовать вспомогательная и заимствованная геометрия. Вспомогательная геометрия не может быть частью эскиза контура или траектории, однако относительно нее можно накладывать зависимости. Заимствованная геометрия представляет собой спроецированную геометрию других эскизов и, как правило, используется для получения образов ребер или силуэтов имеющихся конструктивных элементов.
При создании эскизов используются следующие конструктивные элементы:
Отрезки, дуги, сплайны;
Окружности, эллипсы;
Прямоугольники, многоугольники;
Сопряжения;
Размеры;
Симметрия;
Автонанесение размеров.
Отрезок Для построения прямолинейного сегмента нужно указать первую и вторую конечные точки. Каждый следующий сегмент присоединяется к предыдущему.
Касательная или перпендикулярная дуга Для построения нужно указать конечную точку имеющегося отрезка или дуги. Щелкнуть на конечной точке и, удерживая нажатой кнопку мыши, переместить курсор для формирования касательной или перпендикуляра для выбранной точки, затем отпустить кнопку.
2М сплайны представляют собой гладкие кривые, проходящие через множество заданных точек с изменением радиуса кривизны. Точки сплайна могут быть частично или полностью связаны зависимостями с другими объектами. |
Зависимости относительно имеющейся геометрии на точки сплайна могут накладываться по мере построения кривой. Однако наложение зависимостей и размеров можно выполнить и позже.
Сплайны можно редактировать, не только перемещая точки сплайна с наложением на них зависимостей, но и добавляя точки вдоль кривой сплайна с помощью щелчка правой кнопки. Существует также возможность замыкания сплайнов, показа зависимостей и изменения способа формирования. Кроме того, вдоль всего сплайна можно провести анализ кривизны.
Окружности.
Построение окружностей выполняется двумя способами: по центру и радиусу, либо по трем касательным.
Эллипсы.
При построение эллипса указываются точка центра, большая и малая оси.
Прямоугольники.
Построение прямоугольников выполняется с помощью двух способов построения: заданием двух противоположных углов либо заданием длины и ширины. Каждая сторона прямоугольника представляет собой прямолинейный сегмент.
Многоугольники.
При построении многоугольника принято указывать следующие параметры:
Тип многоугольника(вписанный, описанный);
Количество сторон многоугольника;
Геометрический центр многоугольника;
Сопряжение.
Для скругления угла или пересечения двух линий дугой заданного радиуса используется сопряжение.
Для построения сопряжения принято указывать следующие параметры:
Сопрягаемые линии;
Величина радиуса сопряжения;
Замечание: Пересекающиеся линии обрезаются в местах соединения с сопрягающей дугой.
Размеры.
При производстве деталей соблюдение их точных размеров является сложной, а то и невыполнимой задачей. Точное соблюдение размеров увеличивает стоимость производства. А слишком большие отклонения от заданных размеров могут привести к неработоспособности детали. Диапазон допустимых отклонений определяется типом и назначением детали.
Размерные допуски указываются на деталях, что позволяет:
Анализировать форму, величину посадки и правильность работы детали при максимальных значениях отклонений. При работе с изделием можно проверить совместную работу входящих в него деталей.
Модели позволяют совместно использовать данные не только проектировщикам, но и другим специалистам, а также поставщикам. Для обмена данными можно использовать Интернет.
Симметрия.
Симметричное отображение выбранной геометрии эскиза относительно заданного отрезка.
Среды: 2М эскиз, Изделие и Чертеж.
Автонанесение размеров.
Автоматическое нанесение размеров и наложение зависимостей с целью достижения достаточной определенности эскиза. Предварительно, перед автонанесением размеров, можно нанести отдельные ключевые размеры с помощью команды Размеры панели Эскиз. При этом программа помнит, какие размеры наносились отдельно командой Размеры, и их значения не изменяются при выполнении команды Автонанесение размеров.
Среды: 2М эскиз, Изделие и Чертеж.
23. Трехмерные модели детали в современной системе автоматизированного проектирования.
Трехмерные модели детали в современной САПР строятся на основе плоских эскизов с помощью следующих операций и конструктивных элементов:
Выдавливание;
Вращение;
Отверстие;
Оболочка;
Ребро жесткости;
По сечениям;
Сопряжение;
Фаска;
Рабочая плоскость;
Рабочая ось;
Рабочая точка и др.
Выдавливание.
Построение конструктивного элемента путем придания объема контуру эскиза. В изделиях элементы выдавливания часто используются для пробивания деталей. Форма создаваемого конструктивного элемента определяется формой эскиза, ограничивающими плоскостями и углом конуса.
Среды: Детали, изделия и сварные конструкции.
Вращение.
Построение конструктивного элемента путем вращения одного или нескольких контуров вокруг оси. Эскиз должен представлять собой замкнутый контур, кроме тех случаев, когда строится поверхность.
Отверстие.
Построение параметрического конструктивного элемента в виде отверстия одного из трех типов (обычное, цекованное или зенкованное). При работе с деталями в одном конструктивном элементе может объединяться несколько отверстий с одинаковыми параметрами (диаметром и методом ограничения). Различные отверстия могут создаваться из одного общедоступного эскиза с набором центральных точек. Построение массивов отверстий при работе с изделиями невозможно.
Среды: Детали, изделия и сварные конструкции.
Оболочка.
Полый конструктивный элемент с заданной толщиной стенок, получаемый удалением внутренней части детали. Пользователь может исключить некоторые грани оболочки, формируя открытую полость.
Ребро жесткости.
Эти конструктивные элементы создаются на основе разомкнутых эскизов контуров. Ребро жесткости имеет замкнутую, тонкостенную форму; стержень жесткости - открытую.
При построении ребра жесткости контур проецируется на ближайшую грань детали. При построении стержня жесткости контур вытягивается на заданное расстояние, определяемое как протяженность. Если необходимо, контур может быть удлинен до пересечения с геометрией.
По сечениям.
Элементы по сечениям создаются путем построения переходов между контурами, расположенными на разных рабочих плоскостях или плоских гранях. В качестве контуров можно использовать 2М или 3М эскизы, ребра и контуры граней модели. Форма элемента по сечениям может уточняться с помощью направляющих и сопоставления точек. Команда По сечениям позволяет создавать как тела, так и поверхности.
Сопряжение.
Конструктивный элемент, моделирующий сопряжения или скругления на одном или нескольких ребрах детали. Сопряжения могут иметь постоянный или переменный радиус. За одну операцию можно построить сопряжения различных радиусов. Все сопряжения и скругления, построенные за один вызов команды, являются одним конструктивным элементом.
Фаска.
Фаска представляет собой скос, который строится на одном или нескольких ребрах детали. При построении фаски задается способ обработки пересечений в вершинах и выбираются отдельные ребра или последовательности ребер. Все фаски, построенные за один вызов команды, являются одним конструктивным элементом.
При построении фасок на изделиях пользователь может выбирать элементы геометрии нескольких деталей.
Рабочая плоскость.
Рабочие элементы используются тогда, когда имеющейся геометрии модели недостаточно для создания или размещения дополнительных элементов. Создаваемые конструктивные элементы могут связываться зависимостями с рабочими элементами.
Рабочие плоскости служат для задания осей, плоскостей построений и плоскостей ограничения, а также для размещения секущих плоскостей при создании видов.
Рабочие плоскости используются в тех случаях, когда:
Грань детали недоступна для задания плоскости построений нового конструктивного элемента.
Требуется иметь промежуточное положение для создания другой рабочей плоскости - например, расположенной под нужным углом к грани, но проходящей в стороне от нее.
Рабочие плоскости часто располагают на осях цилиндрических элементов для нанесения параметрических размеров, выражающих расстояния между ними.
При создании 3М элементов разместите рабочие точки на пересечении рабочих осей и рабочих плоскостей. Затем выберите эти рабочие точки для создания траектории.
Рабочая ось.
Рабочая ось - это вспомогательная прямая, параметрически связанная с деталью.
В изделии рабочая ось опирается на имеющийся компонент.
Рабочую ось можно создать на геометрических элементах следующих типов:
Линейное ребро
Отрезок
3М отрезок
Отрезок и плоскость. Рабочая ось будет проходить через конечную точку отрезка, спроецированную на плоскость, и по нормали к плоскости.
Рабочая точка.
Рабочие элементы используются тогда, когда имеющейся геометрии модели недостаточно для создания или размещения дополнительных элементов. Создаваемые конструктивные элементы могут связываться зависимостями с рабочими элементами.
Пользователь может создавать или проецировать рабочие точки на грани деталей, линейные ребра, дуги и окружности. Кроме того, рабочие точки могут быть зафиксированы в центрах дуг, окружностей и эллипсов.
Для чего используются рабочие точки?
Обозначать центры валов и массивов
Определять системы координат
Определять плоскости (по трем точкам)
Задавать 3М траектории
При создании элементов сдвига можно разместить рабочие точки на пересечении рабочих осей и рабочих плоскостей. Выбирая эти точки и вершины существующих деталей, пользователь задает траекторию сдвига.
26. Метрики процессов администрирования информационных систем.
Метрика процесса - количественная мера степени достижения процессом своей цели.
Она должна включать как меры эффективности процесса, так рейтинги уровней зрелости.
Целевая точка - желаемое значение метрики процесса.
Правила эксплуатации и ответственные за их соблюдение
Цель: Обеспечить правильную и надежную работу информационных систем.
Часть 1: Необходимо определить обязанности и процедуры по администрированию и обеспечению функционирования компьютеров и сетей. Они должны быть зафиксированы в инструкциях и процедурах реагирования на инциденты. Для уменьшения риска некорректных или несанкционированных действий следует применять принцип разделения обязанностей.
Часть 2: Аудиторы должны проверить наличие правил по эксплуатации, разработке, сопровождению, тестированию, убедиться, что все необходимые операции должным образом документированы.
Проектирование информационных систем и их приемка
Цель: Свести риск отказов информационных систем к минимуму.
Часть 1: Для обеспечения доступности ресурсов и необходимой производительности информационных систем требуется предварительное планирование и подготовка. Для уменьшения риска перегрузки систем необходимо оценить будущие потребности и необходимую производительность. Эксплуатационные требования к новым системам следует определить, документировать и проверить до их приемки. Должны быть выработаны требования к переходу на аварийный режим для сервисов, поддерживающих несколько приложений.
Часть 2: Аудиторы должны проверить критерии приемки информационных систем, оценки их производительности, планы восстановительных работ по каждому сервису.
Защита от вредоносного программного обеспечения
Цель: Обеспечить целостность данных и программ
Часть 1: Для предотвращения и выявления случаев внедрения вредоносного программного обеспечения требуется принятие соответствующих мер предосторожности. В настоящее время существует целый ряд вредоносных программ ("компьютерные вирусы", "сетевые черви", "Троянские кони" и "логические бомбы"), которые используют уязвимость программного обеспечения по отношению к несанкционированной модификации. Администраторы информационных систем должны быть всегда готовы к проникновению вредоносного программного обеспечения в информационные системы и принимать специальные меры по предотвращению или обнаружению его внедрения. В частности, важно принять меры предосторожности для предотвращения и обнаружения компьютерных вирусов на персональных компьютерах.
Часть 2: Аудиторы должны убедиться, что процедуры, препятствующие внедрению вредоносного программного обеспечения, должным образом документированы, приняты адекватные меры предосторожности, случаи заражения регистрируются.
Обслуживание систем
Цель: Обеспечить целостность и доступность информационных сервисов.
Часть 1: Для поддержания целостности и доступности сервисов требуется выполнение некоторых служебных процедур. Должны быть сформированы стандартные процедуры резервного копирования, регистрации событий и сбоев, а также контроля условий функционирования оборудования.
Часть 2: Аудиторы должны убедиться, что процедуры резервного копирования соответствуют требованиям организации, операторы ведут протоколы всех производимых операций, неисправности регистрируются и принимаются меры к их устранению.
Сетевое администрирование
Цель: Обеспечить защиту информации в сетях.
Часть 1: Управление безопасностью сетей, отдельные сегменты которых находятся за пределами организации, требует особого внимания. Для защиты конфиденциальных данных, передаваемых по открытым сетям, могут потребоваться специальные меры.
Часть 2: Аудиторы должны проверить защитные меры, применяемые в организации.
Защита носителей информации
Цель: Предотвратить повреждение информационных ресурсов и перебои в работе организации.
Часть 1: Необходимо контролировать носители информации и обеспечивать их физическую защиту. Следует определить процедуры для защиты носителей информации (магнитные ленты, диски, кассеты), входных/выходных данных и системной документации от повреждения, хищения и несанкционированного доступа.
Часть 2: Аудиторы должны проверить установленные процедуры контроля, режим хранения носителей информации.
Обмен данными и программным обеспечением
Цель: Предотвратить потери, модификацию и несанкционированное использование данных.
Часть 1: Обмены данными и программами между организациями необходимо осуществлять на основе формальных соглашений. Должны быть установлены процедуры и стандарты для защиты носителей информации во время их транспортировки. Необходимо уделять внимание обеспечению безопасности при использовании электронного обмена данными и сообщениями электронной почты.
Часть 2: Аудиторы должны проверить существующие меры защиты электронного обмена данными, меры ИБ внутреннего электронного документооборота.
Управление доступом к служебной информации
Цель: Обеспечить контроль доступа к информации.
Часть 1: В организации должны быть установлены правила распространения информации и разграничения доступа. Доступ к сервисам и данным в системе необходимо контролировать в соответствии с требованиями организации.
Часть 2: Аудиторы должны проверить соответствие установленных правил доступа к информации существующей производственной необходимости.
Управление доступом пользователей
Цель: Предотвратить несанкционированный доступ к информационной системе.
Часть 1: Для управления процессом предоставления прав доступа к информационным системам требуются формальные процедуры. Эти процедуры должны включать в себя все стадии жизненного цикла управления доступом пользователей — от начальной регистрации до удаления учетных записей пользователей, для которых доступ закрывается. Особое внимание следует уделить процессу предоставления суперпользовательских прав, позволяющих обойти средства системного контроля.
Часть 2: Аудиторы должны проверить формальные процедуры регистрации и соответствие фактического положения вещей установленным процедурам. Следует проконтролировать использование особых привилегий.
27. Оперативное управление и регламентные работы в информационных системах.
Информационная система оперативного уровня поддерживает специалистов-исполнителей, обрабатывая данные о сделках и событиях (счета, накладные, зарплата, кредиты, поток сырья и материалов). Назначение ИС на этом уровне - отвечать на запросы о текущем состоянии и отслеживать поток сделок в фирме, что соответствует оперативному управлению. Чтобы с этим справляться, информация должна быть легкодоступной, непрерывно действующей и предоставлять точную информацию.
Задачи, цели и источники информации на операционном уровне заранее определены и в высокой степени структурированы. Решение запрограммировано в соответствии с заданным алгоритмом.
Информационная система оперативного уровня является связующим звеном между фирмой и внешней средой. Если система работает плохо, то организация либо не получает информации извне, либо не выдает информацию. Кроме того, система - это основной поставщик информации для остальных типов информационных систем в организации, так как содержит и оперативную, и архивную информацию.
Отключение этой ИС привело бы к необратимым негативным последствиям.
Пример. Информационные системы оперативного уровня:
бухгалтерская;
банковских депозитов;
обработки заказов;
регистрации авиабилетов;
выплаты зарплаты и т.д.
Оперативное управление — управление текущими событиями; совокупность мер, позволяющих воздействовать на конкретные отклонения от установленных заданий производства. Оперативное управление подразделяется на оперативное планирование, оперативный учет и оперативный контроль.
МОТИВ — это система оперативного управления компанией, реализованная в виде web-приложения, что обеспечивает эффективное взаимодействие между сотрудниками предприятия независимо от расстояния и структурной организации. Система МОТИВ позволяет руководителю оперативно получать информацию о процессе работы по проектам и задачам, помогая успешно управлять ежедневной деятельностью компании, холдинга, партнерской сети. Возможности системы:
Коллективная работа над проектами и документами
Создание иерархической структуры компании
Получение регулярных отчетов по работе над проектами и задачами
Контроль за процессом и сроками исполнения
Мониторинг занятости персонала компании
МОТИВ также включает в себя модуль электронного документооборота, что позволяет любой компании организовать эффективное управление большим потоком документов. Применение встроенной подсистемы электронного документооборота МОТИВ помогает предприятиям увеличить эффективность работы персонала на 20-25% и уменьшить затраты на хранение документов на 80%. Преднамеренное упрощение объектной модели системы способствует ее успешному внедрению и позволяет значительно снизить временные и финансовые затраты по обучению персонала.
Регламентные мероприятия
Инвентаризация оборудования и программного обеспечения серверного комплекса
Инвентаризация оборудования и программного обеспечения позволит создать и поддерживать актуальную карту системотехнических ресурсов, необходимую при оценке их достаточности для обеспечения требуемой надежности систем, а также для выбора оптимального пути развития информационной системы и оценки объемов необходимых инвестиций. Работы по инвентаризации включают в себя:
создание инвентаризационной базы оборудования, программного обеспечения, лицензий на использование программного обеспечения и базы конфигураций;
составление карты мест нахождения оборудования и программного обеспечения;
классификация и привязка прикладных задач к оборудованию;
создание и внедрение регламентов внесения изменений для высококритичных систем и учета их в инвентаризационной базе и базе конфигураций;
ежемесячное уточнение инвентаризационной базы и базы конфигураций для высококритичных систем;
ежегодная сверка инвентаризационной информации и базы конфигураций.
Документирование систем и оптимизация конфигураций оборудования и программного обеспечения серверного комплекса
При проектировании любой развивающейся системы нельзя заранее спланировать всех особенностей ее развития. Любая большая система по мере роста будет стремиться "уйти" из оптимального состояния. Регулярный контроль изменений конфигураций оборудования и программного обеспечения, контроль текущей производительности и других параметров работы систем позволит не только своевременно определять образование "узких мест" серверного комплекса, ограничивающих его производительность и устойчивость, но и повышать надежность системы с помощью оптимизации текущих конфигураций. Работы по документированию и оптимизации включают в себя:
создание первоначального комплекта эксплуатационной и проектной документации на системы;
создание и внедрение регламентов внесения изменений в комплект эксплуатационной и проектной документации для высококритичных систем;
проведение модификаций комплекта эксплуатационной и проектной документации;
проведение первоначальной оптимизации конфигураций систем;
контроль и анализ параметров работы систем и при необходимости проведение дополнительных оптимизаций конфигураций.
Разработка, документирование и внедрение основных регламентов
Разработка, документирование и внедрение регламентов и инструкций работы штатных специалистов компании и их взаимодействия с внешними обслуживающими организациями повысит эффективность эксплуатации информационной системы, создаст отлаженный и контролируемый механизм использования человеческих ресурсов, а также обеспечит согласованное и быстрое проведение работ по восстановлению системы в аварийных ситуациях.
Выполнение рутинных административных работ
Выполнение рутинных административных работ силами специалистов сервисного центра позволит эффективнее использовать высококвалифицированных штатных специалистов компании, а также компенсировать возможную нехватку штатных специалистов при росте объемов регламентированных рутинных работ. Административные работы, выполняемые специалистами сервисного центра, включают в себя:
ежедневное проведение регламентного мониторинга событий и текущего состояния высококритичных систем;
периодический контроль появления новых патчей и версий программного обеспечения, установка необходимых обновлений/патчей на высококритичные системы;
периодическое внесение изменений в высококритичные системы и учет соответствующих изменений в инвентаризационной базе и базе конфигураций.
Регламентные задания для 1С
Регламентные задания представляют собой неотъемлемую часть конкретного прикладного решения и описываются на этапе конфигурирования.
Для каждого регламентного задания может быть задано расписание, в соответствии с которым регламентое задание будет автоматически запущено на исполнение. В системе 1С:Предприятие 8 поддерживаются однократные и периодические расписания. Можно задать дату начала и окончания выполнения, дневное, недельное и месячные расписания. Расписание можно задать как на этапе конфигурирования, так и на этапе выполнения (в режиме 1С:Предприятие).
В процессе запуска регламентное задание порождает фоновое задание, которое и выполняет реальную обработку. Регламентное задание может выполняться от имени заданного пользователя и имеет возможность перезапуска (например, в случае непредвиденного завершения работы).
28. ИТ-инфраструктура и ИТ-ландшафт предприятия.
ИТ-инфраструктура
По мнению аналитиков, в типичном случае более 70% ИТ-бюджета расходуется на поддержку инфраструктуры — серверов, операционных систем, накопители и сети. К этой сумме нужно еще добавить затраты на модернизацию и управление настольными компьютерами и мобильными устройствами.
Многие организации, сознавая, насколько важно оптимизировать ИТ-инфраструктуру и сделать ее эффективной с экономической точки зрения, пытались рационализировать свои инфраструктуры за счет консолидации центров обработки данных, стандартизации настольных компьютеров, внедрения передового опыта эксплуатации информационных технологий и т. д. Взятые по отдельности, эти инициативы не дают долговременного эффекта. Чтобы его добиться, нужно хорошо представлять уровень зрелости ИТ-инфраструктуры и ее взаимосвязь с потребностями и общей стратегией бизнеса.
ПРИМЕР. Infrastructure Optimization Model от Microsoft
Модель оптимизации инфраструктуры (Infrastructure Optimization Model) от Microsoft помогает организациям понять и впоследствии улучшить состояние ИТ-инфраструктуры, а также получить представление о том. каких затрат она требует, каков уровень ее безопасности и гибкости в эксплуатации. Радикальной экономии можно добиться за счет перехода от неуправляемой среды к динамичной. Степень безопасности повышается с высокой уязвимости при базовом (Basic) уровне зрелости ИТ-инфраструктуры до проактивного противодействия угрозам при более высоких уровнях зрелости. Аналогично совершенствуется управление ИТ-инфраструктурой: необходимые операции выполняются не вручную, а с высокой степенью автоматизации и не в ответ на проявившиеся проблемы, а с работой на опережение, чтобы такие проблемы вообще не возникали. Microsoft и ее партнеры могут предоставить технологии, процессы и процедуры, помогающие оптимизировать инфраструктуру. Способность организации-заказчика эффективно использовать новые технологии для увеличения своих доходов и гибкости в бизнесе заметно возрастает по мере перехода от базового уровня зрелости ИТ-инфраструктуры к динамическому (Dynamic), который открывает бизнесу новые возможности.
Работая с Microsoft и используя модель оптимизации, заказчик может быстро понять стратегическую выгоду и преимущества для бизнеса от перехода с «базового» уровня зрелости ИТ-инфраструктуры (при котором она обычно считается основной статьей расходов) к более динамичному, где ее ценность для бизнеса четко понятна и ИТ-инфраструктура рассматривается как стратегический актив, способствующий эффективному ведению бизнеса.
Модель оптимизации инфраструктуры создана Microsoft с использованием передового опыта, накопленного как индустрией, так и самой Microsoft. Она основана на модели зрелости инфраструктуры (Infrastructure Maturity Model) от Gartner и модели зрелости архитектуры (Architecture Maturity Model) от MIT. Главная цель, стоявшая перед Microsoft при разработке модели оптимизации инфраструктуры, заключалась в том, чтобы найти простой и гибкий способ применения этих моделей, который можно было бы легко задействовать в качестве эталонного теста для определения технических возможностей инфраструктуры и ее ценности для бизнеса.
Первый шаг в применении этой модели на практике — оценка уровня зрелости ИТ-инфраструктуры организации в терминах данной модели, а следующий — планирование пути развития инфраструктуры для достижения нужного уровня ее зрелости.
Уровни зрелости
Уровень 1 — базовый (Basic)
ИТ-инфраструктура базового уровня зрелости характеризуется наличием большого количества процессов, выполняемых вручную, минимальной централизацией управления, отсутствием (или непродуманностью) стандартов и политик безопасности, резервного копирования, управления образами систем, а также несоблюдением других стандартов ИТ. В организации нет четкого понимания деталей существующей инфраструктуры и знания того, какая тактика ее модернизации даст наибольший эффект.
Работоспособность приложений и служб в целом неизвестна из-за отсутствия подходящих инструментов и ресурсов. Механизма обмена накопленными знаниями между отделами нет. Организациям с базовым уровнем инфраструктуры крайне сложно управлять своими средами, их расходы на управление персональными компьютерами и серверами чрезвычайно высоки, они легко уязвимы перед любыми угрозами безопасности, а бизнес получает от ИТ очень малую выгоду. Любые обновления или развертывание новых приложений/ служб требуют больших усилий и затрат.
Организации с базовым уровнем зрелости инфраструктуры получают значительный выигрыш при переходе на стандартизированный уровень (Standardized), радикально уменьшая расходы за счет:
разработки стандартов и политик, а также стратегии их применения;
снижения рисков, связанных с безопасностью, за счет создания эшелонированной обороны (это подход к обеспечению безопасности на нескольких уровнях: по периметру сети и на уровнях серверов, персональных компьютеров и приложений);
автоматизации многих ручных и длительно выполняемых операций;
внедрения передового опыта (библиотеки IT Infrastructure Library, SANS и др.).
Уровень 2 — стандартизированный (Standardized)
В инфраструктуре стандартизированного уровня появляются четко определенные точки управления благодаря применению стандартов и политик администрирования настольных компьютеров и серверов, правилам подключения машин к сети, управления ресурсами на основе Active Directory, политикам безопасности и управлению доступом. Организации с инфраструктурой уровня Standardized эффективно используют преимущества базовых стандартов и политик, но все еще реагируют на проблемы, только когда они уже явно проявились. Обновления или развертывание новых приложений/служб требуют обычно умеренных усилий и затрат (расходы иногда могут быть по-прежнему достаточно высокими). Однако в таких организациях уже есть достаточно внятная база инвентарной информации об аппаратно-программном обеспечении, и они начинают управлять лицензиями. Защита от внешних угроз усиливается благодаря блокированию периметра сети, но внутренняя безопасность пока оставляет желать лучшего.
Организации со стандартизированным уровнем инфраструктуры выигрывают от перехода на рационализированный уровень, получая гораздо больший контроль над инфраструктурой, а также политики и процессы для упреждающего реагирования на различные ситуации — от изменения рыночной конъюнктуры до стихийных бедствий.
Уровень 3 — рационализированный (Rationalized)
На этом уровне зрелости ИТ-инфраструктуры предприятия затраты на управление настольными компьютерами и серверами сводятся к минимуму, а процессы и политики начинают играть важную роль в поддержке и расширении бизнеса. В защите основное внимание уделяется профилактическим мерам, и на любые угрозы безопасности организация реагирует быстро и предсказуемо.
Применение развертывания по принципу «Zero touch» (полностью автоматизированное развертывание, с минимальным участием операторов) минимизирует расходы, время установки обновлений и вероятность технических проблем. Количество образов систем (images) минимально, и процесс управления настольными компьютерами требует совсем небольших усилий. В организации создана база данных с исчерпывающей информацией об аппаратно-программном обеспечении, поэтому закупаются лишь те лицензии и компьютеры, которые действительно нужны.
Достигнув динамического уровня, ИТ-инфраструктура с рационализированным уровнем дает массу преимуществ: организация становится способной к внедрению новых или альтернативных технологий, необходимых для решения новых бизнес-задач или целей, выигрыш от достижения которых значительно перевешивает дополнительные расходы.
Уровень 4 — динамический (Dynamic)
На предприятии с ИТ-инфраструктурой, достигшей динамического уровня зрелости, существует полное понимание стратегической ценности этой инфраструктуры, которая помогает эффективно вести бизнес и постоянно опережать конкурентов. Все расходы под полным контролем, пользователям доступны необходимые в их работе данные, на каких бы серверах они ни находились, организована эффективная совместная работа на уровне как сотрудников, так и отделов, а мобильные пользователи получают практически тот же уровень обслуживания, что и в офисах.
Процессы полностью автоматизированы и зачастую включены непосредственно в ИТ-системы, что позволяет управлять этими системами в соответствии с потребностями бизнеса. Дополнительные инвестиции в технологии дают быструю и заранее просчитываемую отдачу для бизнеса.
Применение ПО с автоматическим обновлением (self provisioning software) и систем с поддержкой карантина (quarantine-like systems), гарантирующих корректное управление обновлениями и соответствие установленным политикам безопасности, позволяет организациям с динамическим уровнем ИТ-инфраструктуры автоматизировать процессы, одновременно повышая их надежность. Это же способствует сокращению расходов и увеличению уровней обслуживания.
Организации с таким уровнем зрелости ИТ-инфра-структур способны отвечать на любые вызовы современного бизнеса.
ИТ – ландшафт
Прикладная архитектура современной компании представляет собой сложную систему, находящуюся в постоянном развитии. Это обязательная составляющая любого предприятия, которая может быть не описана, иногда даже не осознаваема, но она есть всегда. В такой архитектуре могут соседствовать следующие элементы.
1. Готовые прикладные системы:
готовое к использованию ПО, не требующее дополнительной разработки;
типовые решения, в той или иной степени измененные (настроенные) под потребности предприятия.
2. Собственные разработки:
относящиеся к так называемым унаследованным системам, которые были разработаны на предприятии давно, но все еще необходимы ему (обновление таких систем трудно, а иногда и невозможно из-за их слабой задокументированности и нередко отсутствия авторов разработки);
продукты, решающие уникальные задачи предприятия, когда, с одной стороны, процессы необходимо автоматизировать, а с другой — нужных типовых решений нет, а если и есть, то они совершенно расходятся с тем, как предприятие планирует эти задачи решать, и не остается ничего другого, как писать собственные программные системы;
экономные» системы, то есть такие, в которые по ряду соображений предприятие не стало вкладывать значительные средства.
Последнее — совсем не однозначный момент. Я не раз сталкивалась с мнением, что собственная разработка — это всегда малобюджетный проект. Сколько раз в смете проекта мне встречалось такое: «разработка ПО — ноль». И стоило больших трудов переубедить представителей бизнеса, что даже если программисты сидят на зарплате, это не может быть ноль. Если мы гонимся за дешевизной, то все равно надо посчитать, действительно ли «экономные системы» дешевы.
Плюсы типовых решений
1. Есть возможность выбора на основе оценки результатов внедрения на других предприятиях. Мы можем использовать чужой опыт, например посмотреть, каков результат, каковы риски и т. д. Конечно, всё это с определенной долей вероятности, но тем не менее в этом очень привлекательная сторона типового решения для бизнес-руководства. Возможность перенять уникальный опыт лидеров — очень сильный стимул, хотя тут не все так просто и очевидно.
2. Возможность привлечь к внедрению внешних консультантов, получать квалифицированную поддержку на протяжении всего жизненного цикла решения. Вообще информационные технологии внедряются трудно. Легко разработать — внедрять тяжело. И уникальный опыт внедрения — это тоже очень привлекательная составляющая типового решения. Тем более, что собственных внедренцев даже в крупных компаниях маловато. И поставщики типовых решений поняли это очень давно: сейчас любая серьезная ERP-система обязательно имеет в своем составе развернутую методологию внедрения.
3. Процессы выбора внедрения и сопровождения управляемы, прежде всего с точки зрения бюджетирования и оценки рисков. В случае собственной разработки нам очень трудно предсказать, сколько времени это займет, какой бюджет мы потратим, каковы окажутся риски и как это потом будет сопровождаться. При собственной разработке ответы на эти вопросы, как правило, не известны. А вот в случае типового решения есть возможность оценить все эти моменты.
4. Наличие методологий, в частности по выбору инфраструктуры, оценке необходимых мощностей, управлению проектом внедрения. Типовое решение внедряется на многих предприятиях, поэтому все эти параметры уже определены и опробованы. Поставщики понимают, что это одно из значительных преимуществ.
Однако все эти достоинства существуют скорее в виде возможностей, чем в форме твердых гарантий. Неправильный подход предприятия и прежде всего руководства к выбору, внедрению и сопровождению типового решения приводит к тому, что все эти преимущества превращаются в серьезные недостатки.
Обычно неверный подход связан с тем, что прилагательное «типовое» воспринимается на предприятии как синоним простоты и руководство уверено в том, что типовые решения внедряются сами по себе, без каких-либо усилий с их стороны, разве что с участием ИТ-подразделений. Результатом такого заблуждения является выбор продуктов, абсолютно не подходящих конкретному предприятию; управление его внедрением превращается исключительно в отслеживание сроков и бюджета; использование методологий сводится к излишней бюрократии, а все упреки за неудачу проекта (которая весьма вероятна при таком подходе) сваливаются на внешних консультантов.
Руководству предприятия, которое собирается внедрять типовое решение, следует настроиться на серьезную общекорпоративную работу, оно должно осознанно и коллегиально провести работу по выбору решения и активно руководить проектом. И одно из важнейших условий успешного внедрения при этом — соответствие продукта существующей архитектуре предприятия.
29. Назначение и функциональные возможности корпоративных информационных систем. Основные функциональные подсистемы.
Назначения и функциональные особенности
Эффективное управление современным предприятием представляет собой довольно нетривиальную задачу, учитывая многообразие используемых ресурсов и высокую скорость изменения операционного окружения. Основными функциями управления являются, как известно, планирование, организация, активизация, координация, контроль и анализ, которые осуществляются в многомерном пространстве различных областей деятельности предприятия. Формируемые в ходе выполнения вышеперечисленных функций управленческие решения служат отправным моментом для конкретных исполнителей. В связи с тем, что автоматизация исполнения должностных обязанностей и отдельных поручений фактически стала в последнее время стандартом де-факто, особую остроту приобретает проблема автоматизации непосредственно управленческих функций.
Таким образом, наиболее существенной чертой комплексной информационной системы должно стать расширение контура автоматизации для получения замкнутой, саморегулирующейся системы, способной гибко и оперативно перестраивать принципы своего функционирования.
Очевидно, что в состав КИС должны войти средства для документационного обеспечения управления, информационной поддержки предметных областей, коммуникационное программное обеспечение, средства организации коллективной работы сотрудников и другие вспомогательные (технологические) продукты. Из этого, в частности, следует, что обязательным требованием к КИС является интеграция большого числа программных продуктов.
Подобная широкопрофильная система должна в равной, максимально допустимой, степени удовлетворить все подразделения организации, по возможности сохранить существующие бизнес-процессы, а также методы и структуру управления. Без привлечения автоматизации практически нельзя контролировать постоянно меняющиеся бизнес-процессы.
Наполнение предметной части КИС может существенно изменяться в зависимости от профиля деятельности предприятия, включая, например, программное обеспечение для финансового анализа, складскую программу либо PDM-систему. Некоторая часть КИС определяется такими характеристиками, как масштаб организации и объемы информационных работ. С их увеличением становится актуальным внедрение специализированных модулей делопроизводства и архивного хранения, которые способны поддерживать крупные электронные архивы смешанной документации с обеспечением необходимого уровня надежности и безопасности хранения информации.
В дополнение к функционалу, структуру КИС определяют и реализующие данный функционал технологии. С этой точки зрения современные информационные системы должны отвечать целому набору обязательных требований. Среди них, в первую очередь, стоит отметить использование архитектуры клиент-сервер с возможностью применения большинства промышленных СУБД, обеспечение безопасности с помощью различных методов контроля и разграничения доступа к информационным ресурсам, поддержку распределенной обработки информации, модульный принцип построения из оперативно-независимых функциональных блоков с расширением за счет открытых стандартов (API, COM и другие), а также поддержку технологий Internet/intranet.
Кроме того, немаловажную роль играют и другие — эксплуатационные — характеристики: легкость администрирования, эргономичность, наличие локализованного (русифицированного) интерфейса.
Наиболее органичным и эффективным способом построения КИС, при котором были бы выполнены вышеперечисленные функции и требования к технологичности, является использование в качестве ядра всего информационного комплекса системы автоматизации деловых процессов.
Для того чтобы понять, почему это именно так, необходимо вспомнить, что, фактически, деятельность любой организации представляет собой не что иное, как совокупность выработанных в повседневной практике деловых процессов, в которые вовлечены финансовые, материальные, кадровые, информационные и прочие виды ресурсов. Именно деловые процессы определяют порядок взаимодействия отдельных сотрудников и целых отделов, а также принципы построения информационных систем. Поэтому автоматизация предприятия, исходя из делового процесса, наиболее логична, и самое главное, — вполне реальна благодаря современным системам, выступающим в роли связующего звена, вокруг которого и будут интегрироваться другие программные продукты. Сформированная таким образом КИС характеризуется одновременно универсальностью и эффективностью. Она способна автоматизировать деятельность предприятия практически любой отрасли и при этом позволяет сохранить специфические, критически важные нюансы управленческого и организационного ноу-хау. Кроме того, автоматизацию не нужно начинать с нуля. Интегрированный комплекс может создаваться на базе разрозненных автоматизированных рабочих мест, т. е. с использованием уже имеющегося системного и прикладного программного обеспечения. Не стоит забывать также, что при применении в предложенной структуре современных систем, которые характеризуются открытостью и широкими возможностями по настройке, легко достигается динамичная и гибкая модификация целей и функций КИС.
Функциональные подсистемы КИС
Системы управления документами
Прежде всего, это относится к делопроизводству, иначе говоря, к комплексу операций по созданию, управлению и исполнению документов, ведению электронного архива, организации офисного документооборота. Для реализации таких функций необходимо объединить систему с системой управления документами (СУД). К системам данного класса относятся, например, DOCS Open американской фирмы PC DOCS, DocuLive (Siemens Nixdorf), Documentum (Documentum, Inc.). Как правило, СУД имеют богатые возможности по интеграции с внешними приложениями (офисными и прикладными программами), которые и «снабжают» СУД документами. Кроме того, рынок СУД изначально ориентирован на КИС масштаба предприятия, в связи с чем все промышленные системы выполнены в архитектуре клиент-сервер и способны работать практически на всех программно-аппаратных платформах, т. е. характеризуются отличной масштабируемостью, переносимостью, безопасностью и надежностью хранения данных, а также обеспечивают распределенный режим работы.
Если составные части КИС поддерживают довольно широкий список оборудования и серверного программного обеспечения, это дает возможность уменьшить затраты, так как увеличивается вероятность того, что необходимые базовые продукты в организации уже есть. На сегодняшний день основными платформами, на которых должны функционировать формирующие КИС СУД, САДП (Система автоматизации деловых процедур САДП - это особый класс программных продуктов, интегрирующих функции планирования, учета, анализа и документооборота.) и прикладное программное обеспечение, следует считать Windows NT Server, Novell NetWare, основные разновидности Unix и промышленные СУБД Oracle, Microsoft SQL Server, Oracle или Sybase.
Важно отметить, что КИС на основе САДП и СУД являются довольно универсальными. Подобные комплексы, благодаря имеющимся инструментам интеграции, позволяют объединить офисный, (организационно-распорядительный) документооборот с инженерным, в который входит техническая, технологическая и чертежно-конструкторская документация (она, как правило, разрабатывается в САПР и ГИС, например в AutoCAD, MicroStation, КОМПАС), а также любые другие виды информации, вплоть до мультимедиа. Кроме того, в состав КИС может органично влиться программы бухгалтерского, складского и кадрового учета.
Средства обработки бумажных документов
Полный переход к электронной форме информации пока еще невозможен по ряду объективных причин, обусловленных не ограничениями современных информационных технологий (они как раз уже вполне созрели для этого и имеют в своем арсенале все необходимые инструменты), а внешними по отношению к ним факторами (законодательство, инерция мышления, недостаточный уровень компьютеризации в среднем по стране). Поэтому, говоря о концепции построения КИС, нельзя не упомянуть такую актуальную на сегодняшний день проблему, как совмещение в документообороте предприятия электронных и бумажных документов.
Практически все современные СУД, хранящие документы, предоставляют те или иные функции по обработке бумажных документов. Обычно они реализуются с помощью специального модуля, который позволяет автоматизировать сканирование и сохранение образов многостраничных документов, а также их распознавание и аннотирование. Последняя функция, в частности, дает возможность наносить на дополнительные слои произвольные пометки, сохраняя при этом первооснову.
При использовании специальных аппаратных средств (например, высокопроизводительных сканеров с поддержкой коррекции изображений и удаления искажений, дополнительных плат постобработки, фильтрации изображений) такой модуль позволяет создать линию массового (промышленного) ввода документов. Применение подобных комплексов обеспечивает не только высокую скорость преобразования данных, но и экономит место на носителях информации, благодаря более компактному представлению данных (за счет увеличения качества изображений и более мощных алгоритмов сжатия).
Системы поддержки принятия решений
Следующим немаловажным моментом в функционировании КИС является необходимость обеспечить помимо средств генерации данных также и средства их анализа. Имеющиеся во всех современных СУД и СУБД средства построения запросов и различные механизмы поиска хотя и облегчают извлечение нужной информации, но все же не способны дать достаточно интеллектуальную ее оценку, т. е. сделать обобщение, группирование, удаление избыточных данных и повысить достоверность за счет исключения ошибок и обработки нескольких независимых источников информации (как правило, не только корпоративных баз данных, но и внешних, расположенных, например, в Internet). Проблема эта становится чрезвычайно важной в связи с лавинообразным возрастанием объема информации и увеличением требований к инфосистемам по производительности — сегодня успех в управлении предприятием во многом определяется оперативностью принятия решений, данные для которых и предоставляет КИС. В этом случае на помощь старым методам приходит оперативная обработка данных (On-Line Analitical Processing, OLAP). Сила OLAP заключается в том, что в отличие от классических методов поиска запросы здесь формируются не на основе жестко заданных (или требующих для модификации вмешательства программиста и, следовательно, времени, т. е. об оперативности речь идти не может) форм, а с помощью гибких нерегламентированных подходов. OLAP обеспечивает выявление ассоциаций, закономерностей, трендов, проведение классификации, обобщения или детализации, составление прогнозов, т. е. предоставляет инструмент для управления предприятием в реальном времени.
Сегодня доступен целый ряд различных систем OLAP, ROLAP (реляционный OLAP), MOLAP (многомерный OLAP) — Oracle Express, Essbase (Arbor Software), MetaCube (Informix) и другие. Все они представляют собой дополнительные серверные модули для различных СУБД, способные обрабатывать практически любые данные. Интеграция КИС с системой оперативного анализа информации позволит во много раз увеличить эффективность первой, поскольку данные в ней будут не просто храниться, а работать.
Системы, основанные на применении Internet-технологий
Неотъемлемой чертой современных КИС стало применение технологий Internet. Учитывая этот факт, при выборе составляющих КИС необходимо отдавать предпочтение программам (СУД, САДП), которые поддерживают полноценную работу из обычного браузера, фактически, имеют так называемый тонкий клиент и специальное серверное программное обеспечение, обеспечивающее функционирование данного клиента. Как правило, такое техническое решение позволяет использовать стандартные хранилища данных (библиотеки документов, базы данных) из локальных, корпоративных и глобальных сетей, не требуя существенных затрат на дополнительное администрирование и поддержание целостности, надежности и безопасности хранения данных.
Рассматривая вопрос применения Internet-технологий, нельзя не затронуть такую важную проблему, как обеспечение информационной безопасности. Для предотвращения несанкционированного доступа к документам и для исключения возможных диверсий злоумышленников встроенных средств СУД и САДП недостаточно. Поэтому в состав КИС обязательно должны войти специальные программно-аппаратные средства защиты.
Они, в частности, позволяют шифровать данные, поддерживают электронную цифровую подпись и могут проводить на ее основе аутентификацию пользователей. Все это обеспечивает достоверность и целостность информации внутри КИС. В качестве подобной системы криптографической защиты информации можно, например, использовать одну из модификаций (в зависимости от операционной системы и требуемой сложности защиты) СКЗИ «Верба» (разработка Московского отделения Пензенского научно-исследовательского электротехнического института). Обычно СКЗИ представляют собой открытые системы, допускающие интеграцию с внешними программами, но необходимо обратить особое внимание на то, сертифицирована ли СКЗИ и по какому классу. В России сертификацией подобных систем занимается ФАПСИ.
Эффективность программных средств защиты может быть существенно повышена за счет применения аппаратных и биометрических средств: аппаратных ключей, смарт-карт, устройств распознавания отпечатков пальцев, сетчатки глаза, голоса, лица, оцифрованной подписи.
В дополнение к ним на стыке сегментов локальных сетей и Internet желательна установка брандмауэров — средств контроля за внешними (входящими и исходящими) соединениями. (Наиболее типичным примером системы данного класса является CheckPoint FireWall-1 фирмы CheckPoint Software.) Они позволяют отслеживать передачу информации практически всех известных на сегодняшний день протоколов Internet.
30. Аппаратные и программные платформы корпоративных информационных систем.
Выбор аппаратной платформы и конфигурации системы представляет собой чрезвычайно сложную задачу. Это связано, в частности, с характером прикладных систем, который в значительной степени может определять рабочую нагрузку вычислительного комплекса в целом. Однако часто оказывается просто трудно с достаточной точностью предсказать саму нагрузку, особенно в случае, если система должна обслуживать несколько групп разнородных по своим потребностям пользователей. Например, иногда даже бессмысленно говорить, что для каждых N пользователей необходимо в конфигурации сервера иметь один процессор, поскольку для некоторых прикладных систем, в частности, для систем из области механических и электронных САПР, может потребоваться 2-4 процессора для обеспечения запросов одного пользователя. С другой стороны, даже одного процессора может вполне хватить для поддержки 15-40 пользователей, работающих с прикладным пакетом Oracle*Financial. Другие прикладные системы могут оказаться еще менее требовательными. Но следует помнить, что даже если рабочую нагрузку удается описать с достаточной точностью, обычно скорее можно только выяснить, какая конфигурация не справится с данной нагрузкой, чем с уверенностью сказать, что данная конфигурация системы будет обрабатывать заданную нагрузку, если только отсутствует определенный опыт работы с приложением.
Обычно рабочая нагрузка существенно определяется "типом использования" системы. Например, можно выделить серверы NFS, серверы управления базами данных и системы, работающие в режиме разделения времени. Эти категории систем перечислены в порядке увеличения их сложности. Как правило серверы СУБД значительно более сложны, чем серверы NFS, а серверы разделения времени, особенно обслуживающие различные категории пользователей, являются наиболее сложными для оценки. К счастью, существует ряд упрощающих факторов. Во-первых, как правило нагрузка на систему в среднем сглаживается особенно при наличии большого коллектива пользователей (хотя почти всегда имеют место предсказуемые пики). Например, известно, что нагрузка на систему достигает пиковых значений через 1-1.5 часа после начала рабочего дня или окончания обеденного перерыва и резко падает во время обеденного перерыва. С большой вероятностью нагрузка будет нарастать к концу месяца, квартала или года.
Во-вторых, универсальный характер большинства наиболее сложных для оценки систем - систем разделения времени, предполагает и большое разнообразие, выполняемых на них приложений, которые в свою очередь как правило стараются загрузить различные части системы. Далеко не все приложения интенсивно используют процессорные ресурсы, и не все из них связаны с интенсивным вводом/выводом. Поэтому смесь таких приложений на одной системе может обеспечить достаточно равномерную загрузку всех ресурсов. Естественно неправильно подобранная смесь может дать совсем противоположенный эффект.
Все, кто сталкивается с задачей выбора конфигурации системы, должны начинать с определения ответов на два главных вопроса: какой сервис должен обеспечиваться системой и какой уровень сервиса может обеспечить данная конфигурация. Имея набор целевых показателей производительности конечного пользователя и стоимостных ограничений, необходимо спрогнозировать возможности определенного набора компонентов, которые включаются в конфигурацию системы. Любой, кто попробовал это сделать, знает, что подобная оценка сложна и связана с неточностью. Почему оценка конфигурации системы так сложна? Некоторое из причин перечислены ниже:
Подобная оценка прогнозирует будущее: предполагаемую комбинацию устройств, будущее использование программного обеспечения, будущих пользователей.
Сами конфигурации аппаратных и программных средств сложны, связаны с определением множества разнородных по своей сути компонентов системы, в результате чего сложность быстро увеличивается. Несколько лет назад существовала только одна вычислительная парадигма: мейнфрейм с терминалами. В настоящее время по выбору пользователя могут использоваться несколько вычислительных парадигм с широким разнообразием возможных конфигураций системы для каждой из них. Каждое новое поколение аппаратных и программных средств обеспечивает настолько больше возможностей, чем их предшественники, что относительно новые представления об их работе постоянно разрушаются.
Скорость технологических усовершенствований во всех направлениях разработки компьютерной техники (аппаратных средствах, функциональной организации систем, операционных системах, ПО СУБД, ПО "среднего" слоя (middleware) уже очень высокая и постоянно растет. Ко времени, когда какое-либо изделие широко используется и хорошо изучено, оно часто рассматривается уже как устаревшее.
Доступная потребителю информация о самих системах, операционных системах, программном обеспечении инфраструктуры (СУБД и мониторы обработки транзакций) как правило носит очень общий характер. Структура аппаратных средств, на базе которых работают программные системы, стала настолько сложной, что эксперты в одной области редко являются таковыми в другой.
Информация о реальном использовании систем редко является точной. Более того, пользователи всегда находят новые способы использования вычислительных систем как только становятся доступными новые возможности.
При стольких неопределенностях просто удивительно, что многие конфигурации систем работают достаточно хорошо. Оценка конфигурации все еще остается некоторым видом искусства, но к ней можно подойти с научных позиций. Намного проще решить, что определенная конфигурация не сможет обрабатывать определенные виды нагрузки, чем определить с уверенностью, что нагрузка может обрабатываться внутри определенных ограничений производительности. Более того, реальное использование систем показывает, что имеет место тенденция заполнения всех доступных ресурсов. Как следствие, системы, даже имеющие некоторые избыточные ресурсы, со временем не будут воспринимать дополнительную нагрузку.
Для выполнения анализа конфигурации, система (под которой понимается весь комплекс компьютеров, периферийных устройств, сетей и программного обеспечения) должна рассматриваться как ряд соединенных друг с другом компонентов. Например, сети состоят из клиентов, серверов и сетевой инфраструктуры. Сетевая инфраструктура включает среду (часто нескольких типов) вместе с мостами, маршрутизаторами и системой сетевого управления, поддерживающей ее работу. В состав клиентских систем и серверов входят центральные процессоры, иерархия памяти, шин, периферийных устройств и ПО. Ограничения производительности некоторой конфигурации по любому направлению (например, в части организации дискового ввода/вывода) обычно могут быть предсказаны исходя из анализа наиболее слабых компонентов.
Поскольку современные комплексы почти всегда включают несколько работающих совместно систем, точная оценка полной конфигурации требует ее рассмотрения как на макроскопическом уровне (уровне сети), так и на микроскопическом уровне (уровне компонент или подсистем).
Эта же методология может быть использована для настройки системы после ее инсталляции: настройка системы и сети выполняются как правило после предварительной оценки и анализа узких мест. Более точно, настройка конфигурации представляет собой процесс определения наиболее слабых компонентов в системе и устранения этих узких мест.
Следует отметить, что выбор той или иной аппаратной платформы и конфигурации определяется и рядом общих требований, которые предъявляются к характеристикам современных вычислительных систем. К ним относятся:
отношение стоимость/производительность
надежность и отказоустойчивость
масштабируемость
совместимость и мобильность программного обеспечения.
Отношение стоимость/производительность. Появление любого нового направления в вычислительной технике определяется требованиями компьютерного рынка. Поэтому у разработчиков компьютеров нет одной единственной цели. Большая универсальная вычислительная машина (мейнфрейм) или суперкомпьютер стоят дорого. Для достижения поставленных целей при проектировании высокопроизводительных конструкций приходится игнорировать стоимостные характеристики. Суперкомпьютеры фирмы Cray Research и высокопроизводительные мейнфреймы компании IBM относятся именно к этой категории компьютеров. Другим крайним примером может служить низкостоимостная конструкция, где производительность принесена в жертву для достижения низкой стоимости. К этому направлению относятся персональные компьютеры различных клонов IBM PC. Между этими двумя крайними направлениями находятся конструкции, основанные на отношении стоимость/производительность, в которых разработчики находят баланс между стоимостными параметрами и производительностью. Типичными примерами такого рода компьютеров являются миникомпьютеры и рабочие станции.
Надежность и отказоустойчивость. Важнейшей характеристикой вычислительных систем является надежность. Повышение надежности основано на принципе предотвращения неисправностей путем снижения интенсивности отказов и сбоев за счет применения электронных схем и компонентов с высокой и сверхвысокой степенью интеграции, снижения уровня помех, облегченных режимов работы схем, обеспечение тепловых режимов их работы, а также за счет совершенствования методов сборки аппаратуры.
Отказоустойчивость - это такое свойство вычислительной системы, которое обеспечивает ей, как логической машине, возможность продолжения действий, заданных программой, после возникновения неисправностей. Введение отказоустойчивости требует избыточного аппаратного и программного обеспечения. Направления, связанные с предотвращением неисправностей и с отказоустойчивостью, - основные в проблеме надежности. Концепции параллельности и отказоустойчивости вычислительных систем естественным образом связаны между собой, поскольку в обоих случаях требуются дополнительные функциональные компоненты. Поэтому, собственно, на параллельных вычислительных системах достигается как наиболее высокая производительность, так и, во многих случаях, очень высокая надежность. Имеющиеся ресурсы избыточности в параллельных системах могут гибко использоваться как для повышения производительности, так и для повышения надежности. Структура многопроцессорных и многомашинных систем приспособлена к автоматической реконфигурации и обеспечивает возможность продолжения работы системы после возникновения неисправностей.
Следует помнить, что понятие надежности включает не только аппаратные средства, но и программное обеспечение. Главной целью повышения надежности систем является целостность хранимых в них данных.
Масштабируемость. Масштабируемость представляет собой возможность наращивания числа и мощности процессоров, объемов оперативной и внешней памяти и других ресурсов вычислительной системы. Масштабируемость должна обеспечиваться архитектурой и конструкцией компьютера, а также соответствующими средствами программного обеспечения.
Добавление каждого нового процессора в действительно масштабируемой системе должно давать прогнозируемое увеличение производительности и пропускной способности при приемлемых затратах. Одной из основных задач при построении масштабируемых систем является минимизация стоимости расширения компьютера и упрощение планирования. В идеале добавление процессоров к системе должно приводить к линейному росту ее производительности. Однако это не всегда так. Потери производительности могут возникать, например, при недостаточной пропускной способности шин из-за возрастания трафика между процессорами и основной памятью, а также между памятью и устройствами ввода/вывода. В действительности реальное увеличение производительности трудно оценить заранее, поскольку оно в значительной степени зависит от динамики поведения прикладных задач.
Возможность масштабирования системы определяется не только архитектурой аппаратных средств, но зависит от заложенных свойств программного обеспечения.
Масштабируемость программного обеспечения затрагивает все его уровни от простых механизмов передачи сообщений до работы с такими сложными объектами как мониторы транзакций и вся среда прикладной системы. В частности, программное обеспечение должно минимизировать трафик межпроцессорного обмена, который может препятствовать линейному росту производительности системы. Аппаратные средства (процессоры, шины и устройства ввода/вывода) являются только частью масштабируемой архитектуры, на которой программное обеспечение может обеспечить предсказуемый рост производительности.
Совместимость и мобильность программного обеспечения. Концепция программной совместимости впервые в широких масштабах была применена разработчиками системы IBM/360. Основная задача при проектировании всего ряда моделей этой системы заключалась в создании такой архитектуры, которая была бы одинаковой с точки зрения пользователя для всех моделей системы независимо от цены и производительности каждой из них. Огромные преимущества такого подхода, позволяющего сохранять существующий задел программного обеспечения при переходе на новые (как правило, более производительные) модели были быстро оценены как производителями компьютеров, так и пользователями и начиная с этого времени практически все фирмы-поставщики компьютерного оборудования взяли на вооружение эти принципы, поставляя серии совместимых компьютеров. Следует заметить однако, что со временем даже самая передовая архитектура неизбежно устаревает и возникает потребность внесения радикальных изменений архитектуру и способы организации вычислительных систем.
31. Аутсорсинг в создании, внедрении и сопровождении информационных систем.
Аутсорсинг (out - внешний, source - источник) - способ оптимизации деятельности предприятий за счет сосредоточения усилий на основном предмете деятельности и передачи непрофильных функций и корпоративных ролей внешним специализированным компаниям. Аутсорсинг позволяет повысить эффективность выполнения определенных функций предприятий в области информационных технологий, снабжения и поставок, обслуживания, финансов, обеспечения персоналом и даже производства. Практика аутсорсинга помогает компаниям решить проблемы функционирования и развития в рыночной экономике путем сокращения издержек, ускорения адаптации к условиям внешней среды, улучшения качества продукции и услуг, уменьшения рисков. Компания-заказчик может, используя аутсорсинг второстепенных функций, сконцентрироваться на тех, которые свойственны именно ей, на своей специфике. В отличие от субподряда, аутсорсинг - это стратегия управления компанией, а не просто вид партнерского взаимодействия, он предполагает определенную реструктуризацию внутрикорпоративных процессов и внешних отношений компании.
Исследователи аутсорсинга условно разграничивают два вида аутсорсинга - производственный аутсорсинг и аутсорсинг бизнес-процессов. Производственный аутсорсинг предполагает передачу части производственных процессов или всего цикла производства сторонней компании.
Аутсорсинг бизнес-процессов (АБП) включает передачу сторонней организации отдельных бизнес-процессов, которые не являются для компании основными, бизнес-образующими. Из их числа на аутсорсинг могут быть переданы управление персоналом, решение юридических вопросов, бухгалтерский учет, маркетинг и т.д.
По мнению специалистов Института аутсорсинга (Outsourcing Institute, США), аутсорсинг бизнес-процессов является необычайно динамично развивающимся видом оптимизации деятельности предприятий, причем наибольший рост проявляет юридический аутсорсинг, а также аутсорсинг в сфере финансов и бухгалтерского учета.
Итак, на основе всего вышеизложенного, можно определить основные причины использования аутсорсинга:
- Стремление повысить прибыльность бизнеса. Аутсорсинг снижает издержки обслуживания бизнес-процесса;
- Концентрация руководителей на основном бизнесе. Талантливых менеджеров всегда не хватает. Не отвлекайте их от главного дела компании. Пусть о побочных вещах позаботятся другие;
- Использование чужого опыта. Вероятно, аутсорсинговая компания уже сталкивалась с проблемами, похожими на Ваши. С каждым разом она решает их все лучше;
- Внедрение передовых технологий. Специализированная аутсорсинговая компания раньше любой отраслевой фирмы знакомится с новыми разработками. Не упускайте шанс обогнать конкурентов;
- Повышение качества и надежности обслуживания. Аутсорсинговая компания обычно дает гарантии и несет ответственность за качество выполняемых работ;
- Улучшение управляемости. Аутсорсинговая компания обычно использует современные принципы и формы управления и предоставляет эту возможность менеджерам заказчика;
- Укрепление потенциала роста. Развитие Вашего бизнеса – задача аутсорсинговой компании.
Активное развитие IT-аутсорсинга во всем мире объясняется тем, что в связи со стремительным развитием технологий компаниям сложно самостоятельно отслеживать появление технологических новшеств и своевременно внедрять их, не имея большого штата технических специалистов. Оказывается, что компаниям, как правило, выгоднее привлекать опытные организации со штатом высококвалифицированных специалистов в области информационных технологий, чем создавать и расширять собственные специальные подразделения.
Примеры предоставляемых услуг:
Внедрение корпоративных информационных систем, постановка бухгалтерского, налогового и управленческого учета.
Построение инфраструктуры локальных вычислительных сетей – проектирование, подбор и поставка оборудования, монтаж, настройка, сопровождение, администрирование, консультации.
Внедрение и обслуживание цифровых АТС.
Поставка, техническое обслуживание и ремонт вычислительной и оргтехники.
Разработка и информационная поддержка Интернет-сайтов.