Автоматизация процессов разработки ис кратко

Обновлено: 02.07.2024

Автоматизированные системы управления разработкой ИС

Автоматизированная система управления разработкой (АСУР) информационных систем является одним из наших решений по организации эффективной разработки информационных систем, которое мы предлагаем нашим Заказчикам. В рамках работ по внедрению АСУР мы выполняем адаптацию методологии IBM Rational Unified Process и автоматизируем проектную среду в соответствии с лучшими практиками (Best Practices) ведения проектов.

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

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

Основными целями внедрения АСУР являются:

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

Снижение затрат и повышение качества создаваемых информационных систем достигается за счет:

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

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

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

АСУР состоит из подсистем, каждая из которых соответствует отдельным ключевым процессам IBM RUP. При этом по выбору Заказчика могут быть внедрены и автоматизированы все или отдельные процессы из отмеченных галочками на Рисунке 1:

Рисунок 1. Жизненный цикл проекта в соответствии с IBM RUP

Соответственно, основные подсистемы АСУР с примерами инструментов (возможно применение и других инструментов, в том числе, Open Source):

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

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

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

ESS помогают найти ответы на следующие вопросы:

- В каком бизнесе мы должны быть?

- Что делают конкуренты?

- Какие новые приобретения защитили бы нас от циклических деловых колебаний?

- Какие подразделения мы должны продать, чтобы увеличить наличность?

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

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

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

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

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

CASE- технологии обладают следующими основными достоинствами:

· улучшают качество создаваемых ИС за счет средств автоматического контроля;

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

· поддерживают развитие и сопровождение разработки ИС;

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

Исполнительные системы (ESS).

Системы поддержки принятия решений (DSS).

ESS помогают найти ответы на следующие вопросы:

- В каком бизнесе мы должны быть?

- Что делают конкуренты?

- Какие новые приобретения защитили бы нас от циклических деловых колебаний?

- Какие подразделения мы должны продать, чтобы увеличить наличность?

CASE- технологии обладают следующими основными достоинствами:

· улучшают качество создаваемых ИС за счет средств автоматического контроля;

· поддерживают развитие и сопровождение разработки ИС;

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

Привет, хабр! В этой статье расскажу, как мы в Positive Technologies создавали и развивали отдел автоматизации разработки, внедряли идеи DevOps в практику разработки и какие инструменты и технологии для этого использовали, а также как организовали процессы CI/CD. В том числе поделюсь успехами и планами на будущее.

Кто мы и что мы делаем

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

На данный момент наш отдел отвечает за весь конвейер по серийному производству продуктов компании и сопутствующую инфраструктуру, начиная от сборки отдельных компонент продуктов и интеграционных сборок, до их отправки на тестирование на наших серверах и доставку обновлений на географически распределенную инфраструктуру серверов обновлений и затем ― на инфраструктуру заказчиков. Несмотря на большой объем задач, с ними справляется всего 16 человек (10 человек решает задачи Continuous Integration и 6 — задачи Continuous Delivery), при этом количество людей, участвующих в разработке продуктов, более 400.

Модель Continuous Integration и Continuous Delivery

Continuous Integration ― это лишь один из процессов, соединяющих разработчиков и конечных пользователей продуктов. Инфраструктура Continuous Integration в Positive Technologies развивалась вокруг связки из трех базовых сервисов:

TeamCity — основная система организации Continuous Integration;
GitLab — система хранения исходного кода;
Artifactory — система хранения собранных бинарных версий компонент и продуктов.

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

Мы развивали нашу систему Continuous Integration более двух лет, и к настоящему моменту, помимо стандартных конфигураций для сборки, деплоя, тестирования и продвижения сборок, мы дополнили ее разработанной нами системой Continuous Delivery, названной SupplyLab, для публикации протестированных релизных сборок на Global Update-серверы, откуда они забираются и распространяются через Front Update-серверы дальше, вплоть до инфраструктуры заказчиков, на которой разворачиваются и обновляются.

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

коммит в git — автоматическая сборка — деплой на тестовые серверы — функциональное и прочие виды автотестирования — продвижение сборки в стабильные — публикация на GUS — распространение через FUS на инфраструктуре заказчика — установка или обновление продукта на конкретных серверах.

На каждом из этих этапов DevOps-отдел помогает разработчикам решать конкретные задачи:

Рисунок 2. Верхнеуровневая IDEF0-модель процессов Continuous Integration и Continuous Delivery в компании Positive Technologies

Немного о мониторинге

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

Рисунок 3. Модель отношений между сущностями в Zabbix

Для упрощения конфигурирования реализована система, при которой Zabbix забирает с целевого сервера как можно больше данных о наблюдаемых показателях. Для этого в zabbixtools используется функциональность Low Level Discovery (LLD). Это позволяет вносить любые настройки мониторинга на самом отслеживаемом сервере, а не в админке Zabbix. Файлы настроек сохраняются и обновляются при этом через git.

Недостатки в функциональности используемых нами решений для CI/CD

Все обнаруженные проблемы и недостатки элементов наших CI/CD-систем мы фиксируем в нашей базе знаний DevOps. Обобщить проблемы каждого конкретного сервиса в пределах одной статьи довольно сложно, поэтому отмечу только наиболее показательные, например, для CI-системы TeamCity.

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

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

Наш инструментарий

Мы перепробовали множество различных сервисов и инструментов и со временем эволюционным путем сложился их определенный набор. Для решения задач нашего отдела мы используем: TeamCity и GitLab CI как CI-системы, GitLab для хранения кода, Artifactory как хранилище бинарных артефактов и проксирующий репозиторий, SaltStack для автоматизации сценариев развертывания окружений, Docker для изолированного сборочного окружения, SonarQube для анализа качества кода, UpSource для проведения командного код-ревью, TeamPass для безопасного хранения секретов, VMware как средство виртуализации, Zabbix для мониторинга всей нашей инфраструктуры, TestRail для хранения результатов тестранов, Kubernetes для управления контейнерами Linux и некоторые другие.

Из почтовых клиентов по корпоративному стандарту мы используем Outlook/OWA и Skype for Business, во всем остальном мы не ограничены регламентами, поэтому все используют то, что им удобно: браузеры Chrome, Thunderbird (Mozilla), Opera; файловые менеджеры Total Commander, FAR, ConEmu и обычный shell; редакторы MS Word, Notepad++ и, конечно, vim; ssh-клиенты Putty, WinSCP; снифферы и анализаторы трафика (tcpdump, windump, wireshark, burpsuite etc); из IDE любим PyCharm, Visual Studio, WebStorm; для целей виртуализации используем vSphere Client и VirtualBox.

Открытое сообщество Open DevOps Community на GitHub

В этом сообществе мы пытаемся объединить труд различных специалистов в единую систему лучших практик, знаний, инструментов и документации. Мы хотим делиться с коллегами тем, что умеем сами, а также перенимать их опыт. Согласитесь, ведь бывает так полезно обсудить сложную задачу с понимающим коллегой. Все, что мы делаем, — открытые инструменты. Приглашаем всех пользоваться ими, улучшать, делиться знаниями и подходами в DevOps. Если у вас есть идеи или инструменты для автоматизации чего-либо, давайте делиться ими через сообщество Open DevOps Community под MIT-лицензией! Это модно, почетно, престижно.

Цель сообщества Open DevOps Community — сформировать открытые готовые решения для управления полным циклом процесса разработки, тестирования и смежных процессов, а также доставки, развертывания и лицензирования сложных, многокомпонентных продуктов.

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

— универсальный менеджер для скачивания пакетов для сборок многокомпонентных продуктов, по правилам, заданным в манифесте (подробнее на видео по ссылке); — инструмент для управления виртуальными машинами на vSphere прямо из консоли, с возможностью подключения в качестве API-библиотеки в Python-скриптах (подробнее на видео по ссылке); — Python-клиент для работы с API YouTrack; — Python-клиент для работы с API MS TFS; — Python-клиент для работы с API хранилища бинарных данных Artifactory; — универсальный нейронечеткий классификатор произвольных объектов, свойства которых могут быть оценены на нечеткой измерительной шкале (подробнее на видео и в статье).

Готовятся к публикации еще несколько инструментов:

CrossBuilder — система организации кросс-платформенных сборок Build As a Code, наподобие Travis CI, но не зависящая от используемой CI-системы (TeamCity, Jenkins, GitLab-CI);
ChangelogBuilder — генератор release notes с описанием изменений по продукту, который получает и агрегирует данные из различных трекеров: TFS, YouTrack, GitLab, Jira (подробнее на видео по ссылке);
pyteamcity — доработанный python-клиент для работы с API TeamCity;
MSISDK — SDK для создания msi-пакетов для инсталляторов.
SupplyLab — система для публикации, хранения, доставки, развертывания и лицензирования продуктов и обновлений для них (подробнее на видео).

Рисунок 4. Несколько простых шагов для подготовки своего инструмента к публикации в Open DevOps Community

Ретроспектива и планы на будущее

Подходит к концу 2017 год и уже можно провести небольшой ретроспективный анализ проделанной нашей командой работы по развитию идей DevOps в Positive Technologies:

В качестве основной функции нашего DevOps-отдела мы видим макросборку отдельных частей в единый полезный продукт и сокращение себестоимости цепочки: производство — доставка — развертывание ПО.

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

Вместо заключения

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

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

Статья подготовлена на основе интервью в журнале Системный администратор и доклада на Op!DevOps! 2017 (слайды).

Автор: Тимур Гильмуллин, руководитель группы поддержки процессов разработки, Positive Technologies

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

С самого начала CASE-технологии развивались с целью преодоления ограничений при

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

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

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

Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования

сводятся к следующему:

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

контроля и генерации;

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

- поддерживание адаптивности и сопровождения ИС;

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

прототип будущие системы и оценить его;

- освобождение разработчиков от рутинной работы по документированию проекта, так как при этом

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

- возможность коллективной разработки ЭИС в режиме реального времени.

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

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

Метод - это процедура или техника генерации описаний компонентов ЭИС (например, проектирование

потоков и структур данных).

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

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

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

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

- создавать элементы диаграмм и взаимосвязи между ними;

- задавать описания элементов диаграмм;

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

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

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

проектирования ЭИС. Он выполняет следующие функции:

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

- выделение на диаграмме ошибочных элементов.

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

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

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

- задания начальных параметров проекта;

- назначения и изменения прав доступа к элементам проекта;

- мониторинга выполнения проекта.

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

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

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

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

Наиболее известными CASE-средствами для моделирования деловых процессов относятся ERwin, BPwin, Silverrun,

Oracle Designer, Rational Rose и др. Основы функциональной возможности инструментальных средств структурного

моделирования деловых процессов будут рассмотрены на примере CASE-средства BPwin.

Моделирование в BPwin.

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

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

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

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

Процесс моделирования системы IDEFO начинается с создания контексной диаграммы - диаграммы наиболее абстрактного уровня описания системы в целом (рис.5.1).

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

обмен информации между функцими внутри системы.

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

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

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

ER- диаграммы был приняты в качестве основы для создания стандарта IDEFIX. Предварительный вариант этого стандарта был разработан в военно-воздушных силах США и предназначен для увеличения производительности при разработке компьютерных систем. В 1981 г. Этот стандарт был формализован и опубликован организацией ICAM (Integrated Computed Aided Manufacturing), и с тех пор является наиболее распространенным стандартом для создания моделей БД по всему миру.

Базовые понятия ERD

Сущность (Entity) – множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

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

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

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

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

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

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

Проектирование БД при помощи Erwin

Наиболее распространенными методами для построения ERD является метод Баркера и мтод IDEF1.

Метод Баркера основан на нотации, предложенной автором, и используется в case- средства Oracle Designer.

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

IDEFIX –диаграммы используются в ряде распространенных case-средств, в частности Erwin, Design/IDEF/

Функциональная модель бизнес-процесса, представленная в BPwin, является основой для построения модели данных. Хорошим инструментом для такого построения является ErWin – средство разработки структуры БД. При этом функциональная ERWinмодель используется в качестве проектной документации.

ERWin имеет удобный графическтй Windows-интерфейс, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных, а также поддержку многих реляционных СУБД (в том числе и Access)/ ERWin поддерживает два уровня представления и моделирования – логический и физический. На логическом уровне модель БД описывается в терминах, наиболее приближенных к предметной области, не определяются типы данных, не подразумевается использование конкретной СУБД. Типы данных, целевая СУБД и т.д. определяются на физическом уровне.

Раздел: Информатика, программирование
Количество знаков с пробелами: 216919
Количество таблиц: 8
Количество изображений: 10

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

Вложение	Размер
lektsiya_1_ponyatie_ob_informatsionnyh_sistemah_i_avtomatizatsii_informatsionnyh_protsessov_so-11.docx	48.47 КБ

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

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

Цель: дать представление об информационных системах и автоматизации информационных процессов, рассмотреть возможности настольных издательских систем.

Задание: изучить теоретический материал, письменно в тетради ответить на контрольные вопросы.

I. Понятие об информационных системах

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

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

Главная цель системы

Люди, оборудование, материалы, здания и др.

Электронные и электромеханические элементы, линии связи

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

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

Производство профессиональной информации

В основе любой информационной системы лежит структурированный набор данных — структура данных .

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

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

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

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

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

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

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

2) Классификация по архитектуре

По степени распределённости отличают:

Настольные ( desktop ), или локальные ИС, в которых все компоненты ( БД , СУБД , клиентские приложения ) находятся на одном компьютере;
Распределённые ( distributed ) ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС, в свою очередь, разделяют на:

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

В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.

В свою очередь, клиент-серверные ИС разделяют на двухзвенные и многозвенные .

3) Классификация по степени автоматизации

По степени автоматизации ИС делятся на:

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

4) Классификация по сфере применения

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

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

5) Классификация по назначению

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

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

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

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

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

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

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

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

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

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

6) Классификация по охвату задач (масштабности)

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

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

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

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

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

На рис.2 представлена структура АИС.

Рис.2. Структура АИС

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

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

Функциональные подсистемы и приложения (ФП) – специализированные программы по обработке и анализу информации с целью подготовки документов и принятия решений в конкретной функциональной области на базе ИТ.

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

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

Пользователей АИС можно разделить на 4 категории.

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

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

Что такое информационная система?
Назовите структуру информационной системы.
Как классифицируются информационные системы?
Что такое автоматизированная информационная система (АИС)?
Структура АИС?

По теме: методические разработки, презентации и конспекты

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

Информационные системы - понятие и классификация

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

Лекция по дисциплине "Информационные технологии в профессиональной деятельности" специальности Сестринское дело, 2 курс.

Понятие об информационных системах. Возможности настольных издательских систем

Понятие об информационных системах.Возможности настольных издательских систем.

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

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

Лекция Понятие об информационных системах и автоматизации информационных процессов. Графический интерфейс WINDOWS

Лекция на тему "Понятие об информационных системах и автоматизации информационных процессов. Графический интерфейс WINDOWS".

Открытое учебное занятие на тему: "Понятие об информационных системах и автоматизации информационных процессов" (РСК)

Понятие об информационных системах и автоматизации информационных процессов.

Читайте также: