Главная страница
Навигация по странице:

  • 1.7. Архитектурный подход к проектированию ИС

  • 1.8. Плохие и хорошие архитектуры

  • Контрольные вопросы

  • АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем


    Скачать 4.65 Mb.
    НазваниеВодяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
    Дата03.06.2022
    Размер4.65 Mb.
    Формат файлаdocx
    Имя файлаАРИС Текст 2.docx
    ТипДокументы
    #568218
    страница4 из 30
    1   2   3   4   5   6   7   8   9   ...   30

    1.6. Корпоративные информационные системы (КИС)

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

    Промышленные корпорации. Понятие “корпорация” обычно обозначает оптимальную форму организации крупномасштабного производства промышленной продукции и услуг. Необходимо заметить, что изначально корпорация представляла собой объединение свободных хозяйствующих субъектов, которые объединялись для достижения собственных экономических целей. На сегодняшний день сложились качественно отличные друг от друга типы корпораций. Можно выделить, по крайней мере 3 типа промышленных корпораций [13]:

    • классические или индустриальные корпорации;

    • этатистские или государственные корпорации;

    • креативные корпорации.

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

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

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

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

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

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

    Специфика КИС как ИС состоит в следующем.

    1. КИС – это большая или очень большая ИУС, в состав которой на правах подсистем входят другие достаточно крупные ИС.

    2. Архитектура КИС – это один из уровней корпоративной архитектуры.

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

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

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

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

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

    Можно выделить следующие основные стратегии построения КИС:

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

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

    • организация заказывает КИС специализированной организации.

    Применительно к промышленным предприятиям обычно используют 4-уровневую модель управления, которая включает следующие уровни (контуры) управления (рис. 1.9):

    • управление оборудованием и технологическими процессами;

    • управление производством;

    • управление предприятием.



    Рис. 1.9. Уровни (контуры) управления промышленным предприятием

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

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

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

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

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

    На самом нижнем уровне работают SCADA –системы. Термин SCADA расшифровывается как Supervisory Control and Data Acquisition – системы диспетчерского управление и сбора данных. В современном понимании – это программные пакеты, которые устанавливаются на компьютеры. Они предназначенные для разработки или обеспечения работы в реальном времени систем сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления. SCADA можно отнести к классу УС. Иногда в понятие SCADA, кроме программной, включают и аппаратную компоненту. Следует отметить, что SCADA могут использоваться не только в производственных системах, но и системах автоматизации научного эксперимента, системах управления сложными техническими системами, системах экологического мониторинга и т.п. [17].

    Информация от SCADA обычно поступает в MES-системы. Термин MES (Manufacturing Execution System) можно перевести как система управления производством. MES-системы предназначены для того, чтобы контролировать, упорядочивать и систематизировать все рабочие процессы на производстве. Они работают на уровне управления оборудованием и технологическими процессами, т.е. на том же уровне, что и SCADA. MES-системы– это программные системы, которые позволяет решать задачи анализа, синхронизации, координации и оптимизации процессов, связанных с производством продукции. MES-системы устанавливается не только на компьютеры предприятия, но и на оборудование, участвующее в процессе производства. MES-системы позволяют решать следующие основные задачи.

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

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

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

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

    5. MES-системы также способны осуществлять контроль качества выпускаемой продукции.

    6. Могут реагировать на требования, предъявляемые к номенклатуре производства.

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

    К MES-системы относятся достаточно много стандартов, основными из которых являются следующие: ISA95 ("Enterprise-Control System Integration") – интеграция MES-систем и технологического процесса производства, ISA88 ("Batch Control") – управление периодическим производством. Фактически, данный стандарт участвует в определении всей технологии управления производством, приоритетность и иерархию рецептур, а также за производственные данные, Supply-Chain Operations Reference (SCOR) – модель процессов цепочки поставок, который описывает процессы каждого этапа взаимоотношений заказчика и поставщика. Такой раздел SCOR, как "Make" ("производство"), полностью посвящается производству [18].

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

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

    Дальнейшим развитием концепции MRP является стандарт MRP II, основная идея которого состоит в том, прогнозирование, планирование и контроль производства осуществляются по всему производственному циклу, - от закупки сырья до отгрузки товара потребителю. Функциональность MRP II определяет Стандартом Американского Общества Управления Производством и Запасами (American Production and Inventory Control Society – APICS), в соответствии с которым системы класса MRP II реализует 16 групп функций:

    • планирование продаж и производства;

    • управление спросом;

    • составление плана производства;

    • планирование материальных потребностей;

    • спецификации продуктов;

    • управление складом;

    • плановые поставки;

    • планирование на уровне производственного цеха;

    • планирование потребностей в мощностях;

    • контроль входа/выхода;

    • материально-техническое снабжение;

    • планирование ресурсов распределения;

    • планирование и управление инструментальными средствами;

    • управление финансами;

    • моделирование;

    • оценка результатов деятельности.

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

    CRM и SRM системы. Система управления взаимоотношениями с клиентами.(Customer relationship management, CRM) ориентированы на поддержку и управление взаимодействием с клиентами. Они позволяют сохранять и анализировать информацию о клиентах, включая историю взаимодействия, управляет контактами, поддерживает бизнес-процессы, направленные на удовлетворение потребностей клиентов, сервисное обслуживание, предоставление качественной продукции. Система управления взаимодействием с поставщиками (Supplier relationship management, SRM) ориентированы на оптимизацию бизнес-процессов и снижение совокупных затрат, связанных с материально-техническим снабжением и закупкой материально-технических ресурсов.

    ERP системы. Если объектом стандарта MRP были производственные процессы, материально-технические и производственные ресурсы, то стандарт ERP (Enterprise Resource Planning), разработанный в 90-е годы, объединял стандарт MRP II со стандартом финансового планирования FRP (Finance Requirements Planning). Сам термин планирование ресурсов предприятия (Enterprise Resource Planning, ERP) появился как развитие стандарта MRP II в самом начале 90-х годов. Идея состояла в создании КИС, способной обеспечить сбалансированное управление всеми ресурсами организации. Основе своей ERP – это датацентрическая система, в основу функционирования которой должна быть положена общая модели данных о производстве, закупках, сбыте, финансах, кадрах. Основу ERP-систем составляет единое хранилища (репозиторий) данных, в котором хранится вся бизнес-информация: (плановая, финансовая информация, производственные данные, данные о персонале и др). Наличие единого корпоративного репозитория устраняет необходимость в передаче данных между отдельными подсистемами. Целью создания ERP-систем является улучшение управления производственной деятельностью предприятия и уменьшение затрат на поддержку бизнес-процессов.

    В конце 2000 года была предложена концепция построения ERP второго поколения, которая была названа ERP II. В ERP II была добавлена новая функциональность. ERP-системы теперь должны обеспечивать не только автоматизацию внутренних бизнес-процессов предприятия, но и обеспечивать свободное взаимодействие предприятия с заказчиками, поставщиками, партнёрами по бизнесу, банками, налоговыми органами и пр. Была существенно расширена область применения ERP-систем. Если раньше ERP-системы были ориентированы на производственные и дистрибуторские организации, то новые ERP II-системы – на самый широкий круг организаций, включая некоммерческие. Существенно изменился характер поддерживаемых бизнес-процессов. Если в ERP I это были преимущественно внутренние процессы, то ERP II способна реализовывать взаимодействия с внешними партнерами (Business-to Buiseness, B2B) взаимодействия. В качестве составных частей е ERP системы вошли CRM, системы управления цепочками поставок (SCM - Supply Chain Management, модулями работы с персоналом (Human Resources Management), подсистему управления знаниями (Knowledge Management, KM), а также подсистемами электронного бизнеса (e-Business) и электронной коммерции (e-Commerce). Сами системы стали строиться по модульному принципу. HRM системы занимаются управлением персоналом, в задачи которых входит сбор и сохранение сведений по квалификации работников, рекрутинг, управление и эффективное использование потенциала всех сотрудников предприятия KM-системы предназначены для управления корпоративными знаниями. Исторически эти системы создавались для накопления корпоративных знаний и использовались для внутреннего потребления. В настоящее время на рынке имеется большое число ERP систем таких компаний как SAP, 1С, Oracle, Галактика, Парус.

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

    Для автоматизации этих функций разработаны BPM (Business Performance Management, BPM)-системы, которые достаточно просто интегрируются с ERP системами. Термин BPM тесным образом связан с такими понятиями как система поддержки принятия решений (Decision Support System, DSS) и бизнес-интеллект (Business Intelligence, BI).

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

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

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

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

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

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

    Стандарты и инструменты управления КИС. Как указывалось ранее КИС должна постоянно адаптироваться к изменениям параметров внешней среды, т.е. быть способной к адаптации. Стандартом de facto в области организации и управления информационной средой является ITSM-стандарт (IT Service Management), реализующий процессный подход к управлению IT-средой, ITSM является подмножеством библиотеки ITIL (Information Technology Infrastructure Library). В ITSM определены 10 основных процессов управления КИС.

    1. Управление инцидентами (Incident management). Обработка событий, поступающих на Service desk, и требующих ответной реакции: сбои, запросы на консультации и т.п.

    2. Управление проблемами (Problem management). Выявление и устранение причин инцидентов

    3. Управление конфигурациями (Configuration management). Создание и поддержка в актуальном состоянии логической модели IT-инфраструктуры с целью обеспечение соответствия IT-инфраструктуры потребностям бизнеса

    4. Управление изменениями (Change management). Анализ необходимости и координация проведения изменений.

    5. Управление релизами (Release management). Создание и использование средств, поддерживающих работоспособность информационной среды при проведении изменений с целью обеспечение работоспособности производственной среды при проведении изменений с целью.

    6. Управление уровнем сервиса (Service level management). Выявление требуемого состава и уровня сервиса, оценка степени его достижения, инициирование действий по устранению некачественного сервиса обеспечение требуемого состава и уровня сервиса.

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

    8. Управление мощностью (Capacity management). Оптимизация соотношения затрат и потребностей в функциональном, организационном, территориальном и др. масштабах КИС с целью нахождения компромисса между затратами и потребностями в информационной поддержке

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

    10. Управлениефинансами (Financial management for IT services). Процесс состоит в планировании, бюджетировании, учете и оптимизации использования финансовых ресурсов для обеспечения процессов управления IT-средой с целью оптимизации финансового обеспечения всех процессов управления IT-средой.

    Одной из наиболее часто используемых компонент, входящих в состав практически всех ITSM систем является Service Desk, который представляет собой программный продукт, предназначенный для построения службы технической поддержки пользователей КИС. Service Desk работает с БД, содержащей накопленные знания, серверов приложений и клиентской части. Каждый сотрудник имеет на рабочем компьютере Service Desk-клиента, который позволяет ему обратиться к БД, содержащей решения типичных задач. Если проблема нестандартная, то обращение переадресуется сотруднику технической поддержки, который либо оперативно решает возникшую проблему, либо направляет запрос соответствующему сотруднику. Обычно с состав данного приложения входят встроенные механизмы работы со знаниями. На рынке инструментальных средств управления КИС имеется достаточно много разнообразных продуктов, отличающихся функциональными возможностями и стоимостью. В качестве наиболее известных систем, можно назвать такие системы как OpenView от фирмы HP, Tivoli от IBM, Microsoft Operations Framework (MOF) и много других [20].

    1.7. Архитектурный подход к проектированию ИС

    Архитектурное описание самым тесным образом связано с процессом проектирования ИС, причем в ряде определений термина «архитектура» на этот факт указывается в явном виде. Обычно выделяются пять различных подходов к проектировании, которые называют также стилями проектирования и, по существу, определяют группы методологий разработки ПО: стиль, основанный на календарном планировании (Calendar-driven), стиль, основанный на управлении требованиями (Requirements-driven), стиль, в основу которого положен процесс разработки документации (Documentation-driven), стиль, основанный на управлении качеством (Quality-driven), архитектурный стиль (Architecture-driven).

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

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

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

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

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

    1.8. Плохие и хорошие архитектуры

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

    Ниже приведены некоторые эмпирические правила, которым надо следовать, чтобы избежать грубых ошибок на этапе архитектурного проектирования. Эти правила можно разделить на 2 группы: правила, связанные с выбором архитектурного проектирования и правила, связанные с процессом архитектурного проектирования [10].

    Правила, связанные с выбором архитектурных решений:

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

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

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

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

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

    6. Не следует ставить во главу угла принцип «один модуль - один компонент». Например, функции модуля обработки могут решать несколько параллельно работающих процессоров.

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

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

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

    Правила, связанные с архитектурным процессом:

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

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

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

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

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

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

    1. Группа разработчиков не может назвать архитектора.

    2. Количество компонентов верхнего уровня очень велико (больше 20).

    3.Архитектура подгоняется под структуру организации.

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

    5. Одно требование ведет весь проект.

    6. Архитектура зависит он специфики операционной системы.

    7. Определение компонентов идет от используемой аппаратуры.

    8. Имеется избыточность, не диктуемая надежностью.

    9. Проектом движут исключения.
    Контрольные вопросы

    1. Дайте толкование понятия архитектура применительно к информационным системам.

    2. Что такое (software-intensive systems)?

    3. Перечислите и охарактеризуйте основные этапы развития программного обеспечения?

    4. В чем состоит сущность объектно-ориентированного подхода?

    5. В чем состоит разница между архитектурой и архитектурным описанием?

    6. Сравните различные определения понятия «Архитектура ИС»

    7. Что такое архитектурные уровни?

    8. В чем суть доменного подхода?

    9. Назовите основные классификационные признаки ИС?

    10. Укажите отличительные характеристики информационно-управляющих систем.

    11. Перечислите основные элементы управляющих систем

    12. Каково назначение систем мониторинга и управления ресурсами?

    13. Укажите отличительную особенность систем управления производством.

    14. На какой эталонной модели базируется система управления доступом?

    15. Определите понятие «Корпоративная информационная система»

    16. Что такое CRM и SRM системы?

    17. Что такое ERP системы?

    18. Укажите стили проектирования ИС.

    19. Охарактеризуйте Архитектурный подход к проектированию ИС

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

    21. Перечислите основные правила, связанные с архитектурным процессом.

    22. Определите понятия плохой и хорошей архитектуры.


    1   2   3   4   5   6   7   8   9   ...   30


    написать администратору сайта