ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.12.2023
Просмотров: 158
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
2. ИНФОРМАЦИОННАЯ СИСТЕМА
Информационная система (ИС) — система, предназначенная для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию (ISO/IEC 2382:2015)[7].
Предназначена для своевременного обеспечения надлежащих людей надлежащей информацией[14], то есть для удовлетворения конкретных информационных потребностей в рамках определённой предметной области, при этом результатом функционирования информационных систем является информационная продукция — документы, информационные массивы, базы данных и информационные услуги[17].
3. ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ АРХИТЕКТУРЫ
ИНФОРМАЦИОННЫХ СИСТЕМ
На основе приведенных определений рассмотрим определение архитектуры информационных систем.
Определений архитектуры информационных систем много. На сайте SEI (Software Engineering Institute)
13 имеется специальный раздел, посвященный определениям архитектуры, где их собрано более ста. Различные источники дают следующие оперделения:
• архитектура — организационная структура системы;
• архитектура информационной системы
— концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы;
• архитектура — базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и окружением, а также принципы, определяющие проектирование и развитие системы;
• архитектура — набор значимых решений по поводу организации системы программного обеспечения, набор структурных элементов и их интерфейсов, при помощи которых компонуется система вместе с их поведением, определяемым во взаимодействии между этими элементами, компоновка элементов в постепенно укрупняющиеся подсистемы, а также стиль архитектуры, который направляет эту организацию (элементы и их интерфейсы, взаимодействия и компоновку);
• архитектура программы или компьютерной системы — структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними;
• архитектура — структура организации и связанное с ней поведение системы.
Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части и условия сборки частей. Части, взаимодействующие через интерфейсы, включают классы, компоненты и подсистемы;
• архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений в отношении структур программы и взаимодействий между этими структурами, составляющих системы.
Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения
14 предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания.
Для того чтобы разобраться в этом многообразии определений, выделим наиболее существенные стороны архитектуры ИС.
Основным критерием выбора архитектуры и инфраструктуры ИС в услових рыночной экономики является минимизация совокупной стоимости владения системой. Из этого следуют два основных тезиса.
1.
В проектах построения информационных систем, для которых важен экономический эффект, необходимо выбирать архитектуру системы с минимальной совокупной стоимостью владения.
2.
Совокупная стоимость владения ИС состоит из плановых затрат и стоимости рисков. Стоимость рисков определяется стоимостью бизнес-рисков, вероятностями технических рисков и матрицей соответствия между ними.
Матрица соответствия определяется архитектурой ИС.
Термин «архитектура информационной системы» обычно довольно согласованно понимается специалистами на уровне подсознания, но при этом и определения этого понятия неоднозначны. Имеются два основных класса определений архитектур — «идеологические» и «конструктивные».
Основные идеологические определения архитектуры ИС таковы:
1.
Архитектура ИС — набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой;
2.
Архитектура ИС — набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения.
Эти определения объединяет то, что если ключевое решение приходится изменять при изменении бизнес-технологии в рамках бизнес-видения, то резко возрастает стоимость владения системой. Как следствие возникает понимание важности принятия архитектуры системы как стандарта предприятия ввиду значимости архитектурных решений и их устойчивости по отношению к изменениям бизнес- технологии. Важный вывод из первого определения — архитектура системы должна строиться еще на стадии технико-экономического
15 обоснования системы. Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы:
• что делает система?;
• на какие части она разделяется?;
• как эти части взаимодействуют?;
• где эти части размещены?.
Таким образом, архитектура ИС является логическим построением, или моделью, и влияет на совокупную стоимость владения через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т. п. — т. е. через то, что мы называем инфраструктурой ИС. При этом инфраструктура включает решения не только по программному обеспечению, но и по аппаратному комплексу и организационному обеспечению.
3.1. Информационная система как объект архитектуры
Выше было приведено одно из определений информационной системы.
Применительно к информационным системам термин «архитектура» используется достаточно часто. Данный термин может относиться к организации, программно-аппаратному комплексу, программной системе или центральному процессору.
Применительно к организации обычно используют понятие корпоративная архитектура (enterprise architecture), при этом выделяются следующие типы архитектур: бизнес-архитектура (Business architecture), ИТ- архитектура (Information Technology Architecture), архитектура данных (Data
Architecture), архитектура приложения (Application Architecture) или программная архитектура (Software Architecture), техническая архитектура
(nardware Architecture). Совокупность данных архитектур и является архитектурой ИС (рис. 2).
Бизнес-архитектура, или архитектура уровня бизнес-процессов, определяет бизнес-стратегии, управление, организацию, ключевые бизнес- процессы в масштабе предприятия, причем не все бизнес- процессы
16 реализуются средствами ИТ-технологий. Бизнес-архитектура отображается на
ИТ-архитектуру.
ИТ-архитектура рассматривается в трех аспектах:
• обеспечивает достижение бизнес-целей посредством использования программной инфраструктуры, ориентированной на реализацию наиболее важных бизнес-приложений;
• среда, обеспечивающая реализацию бизнес-приложений;
• совокупность программных и аппаратных средств, составляющая информационную систему организации и включающая, в частности, базы данных и промежуточное программное обеспечение.
Рис 2. Архитектура информационной системы
Архитектура данных организации включает логические и физические хранилища данных и средства управления данными. Архитектура данных должна быть поддержана ИТ-архитектурой. В современных ИТ-системах, ориентированных на работу со знаниями, иногда выделяют отдельный тип архитектуры — архитектуру знаний (Knowledge Architecture).
Программная архитектура отображает совокупность программных приложений. Программное приложение — это компьютерная программа, ориентированная на решение задач конечного пользователя. Архитектура приложения — это описание отдельного приложения, работающего в составе
ИТ-системы, включая его программные интерфейсы. Архитектура приложения
17 базируется на ИТ-архитектуре и использует сервисы, предоставляемые ИТ- архитектурой.
Техническая архитектура характеризует аппаратные средства и включает такие элементы, как процессор, память, жесткие диски, периферийные устройства, элементы для их соединения, а также сетевые средства.
Часто нельзя провести четкой границы между ИТ-архитектурой и архитектурой отдельного приложения. В частности в том случае, когда некоторую фупкцию требуется реализовать в нескольких приложений, она может быть перенесена на уровень ИТ-архитектуры. Обычно приложения интегрируются средствами ИТ-архитектуры. Элементы архитектуры данных часто интегрируются в приложения.
3.2. Архитектура и проектирование информационных систем
Архитектурное описание самым тесным образом связано с процессом проектирования ИС, причем в ряде определений термина «архитектура» на этот факт указывается в явном виде. Обычно выделяются пять различных подходов к проектированию, которые называют также стилями проектирования и, по существу, определяют группы методологий разработки ПО:
• календарный стиль — основанный на календарном планировании
(Calendar-driven);
• стиль, основанный на управлении требованиями (Requirements- driven);
• стиль, в основу которого положен процесс разработки документации (Documental ion-driven);
• стиль, основанный на управлении качеством (Quality-driven);
• архитектурный стиль (Architecture-driven).
Основой календарного стиля является график работ. Команда разработчиков выполняет работы поэтапно. Проектные решения принимаются из целей и задач конкретного этапа. Слабыми местами данного стиля являются то, что основные решения принимаются исходя из локальных целей, при этом мало внимания уделяется процессу разработки, разработке документации,
18 созданию стабильных архитектур и внесению изменений. Все это приводит к высокой суммарной стоимости владением в долгосрочном плане. Данный стиль считается морально устаревшим, однако многие организации продолжают его использовать.
Стиль, основанный на управлении требованиями, предполагает, что основное внимание уделяется функциональным характеристикам системы, при этом часто недостаточно внимания уделяется нефункциональным характеристикам, таким как масштабируемость, портабельность, подцерживаемость и другим, определенным в ISO 9126. Проектные решения принимаются преимущественно исходя из локальных целей, связанных с реализацией тех или иных функций. Данный подход достаточно эффективен в случае, если требования определены и не изменяются в процессе проектирования. Основные недостатки данного подхода следующие: недостаточное внимание уделяется требованиям стандарта ISO 9126
(управление качеством); разрабатываемые архитектуры, как правило, не являются стабильными, так как каждая из реализуемых функций отображается на один или несколько функциональных компонентов. Это обстоятельство усложняет добавление к системе новых требований. Данный подход позволяет успешно отслеживать требования в плане реализации требуемой функциональности, однако использование его для долгосрочных проектов является неэффективным.
Стиль, в основу которого положен процесс разработки документации, до настоящего времени продолжает использоваться в правительственных организациях и крупных компаниях. Данный стиль может рассматриваться как вырожденный вариант стиля, основанного на управлении качеством, и ориентирован на разработку документации. В качестве основных недостатков данного подхода выделяются следующие: неоправданно много времени и сил затрачивается на разработку документации в ущерб качеству разрабатываемого кода. При этом создаваемая документация часто не используется ни пользователем, ни заказчиком.
19
Стиль, основанный на управлении качеством, предполагает самое широкое использование различных мер для отслеживания критичных с точки зрения функционирования параметров. Например, требуется получить время реакции системы на запрос менее одной секунды или обеспечить среднее время между отказами не менее 10 лет. В этом случае данные параметры отслеживаются на всех этапах проектирования систем и часто это делается в ущерб другим характеристикам, таким как масштабируемость, простота сопровождения и т. п. Типовыми проблемами, возникающими при использовании данного стиля, являются следующие: часто оптимизируются не те параметры, которые должны быть в действительности, когда появляются новые требования, бывает очень трудно изменить функциональность системы.
Созданные таким образом системы обычно не отличаются высоким качеством архитектурных решений. В целом данный стиль считается консервативным. Его использование может быть оправдано в случае, когда необходимо создать системы с экстремальными характеристиками.
Архитектурный стиль представляет собой наиболее зрелый подход к проектированию. В рамках данного стиля во главу угла ставится создание фреймворков, которые могут быть легко адаптированы ко всем потенциальным требованиям всех потенциальных заказчиком. Отличительная особенность данного стиля состоит в том, что задача проектирования разбивается на две отдельные подзадачи: создание многократно используемого фреймворка и создание конкретного приложения (системы) на его основе. При этом эти две задачи могут решать разные специалисты. Основная цель создания данного стиля — это устранение недостатков стиля, основанного на управлении требованиями. Использование архитектурного стиля позволяет реализовать инкрементное и итеративное проектирование, т.е. оперативно изменять существующую и добавлять новую функциональность.
В процессе проектирования важное значение приобретают атрибуты качества ИС.
20
Понятие качества ИС соответствует понятию о том, что система успешно справляется со всеми возлагаемыми на нее задачами, имеет хорошие показатели надежности и приемлемую стоимость, удобна в эксплуатации и обслуживании, легко сочетается с другими системами и в случае необходимости может быть модифицирована.
Разные группы пользователей имеют различные точки зрения на характеристики качества ИС. Например, если задать вопрос о том, какой должна быть хорошая ИС, то от пользователя можно получить следующие варианты ответов:
• система имеет хорошую производительность;
• система имеет широкие функциональные возможности;
• система удобна в эксплуатации;
• система надежна.
Менеджер даст скорее всего другие варианты ответов:
• стоимость системы не должна быть изначально очень высокой;
• система не должна быть очень дорогой в эксплуатации;
• система не должна морально устаревать в течение возможно более длительного периода времени и в случае необходимости может быть легко модифицирована.
Для системного администратора наиболее важными могут оказаться такие характеристики системы, как
• надежность и стабильность работы;
• простота администрирования;
• наличие хорошей эксплуатационной документации;
• хорошая поддержка изготовителем.
Другие заинтересованные лица могут иметь свои точки зрения на то, какой должна быть качественная система.
Поскольку в современных ИС ключевой компонентой является программная компонента, а пользователи, работающие с системой, в большинстве случаев взаимодействуют непосредственно с программной
21 компонентой, поэтому показатели качества информационных и программных систем в значительной степени совпадают.
Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем, необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспособна развиваться и удовлетворять растущие потребности пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации, как SEI (Software Engineering Institute), WWW (консорциум World
Wide Web), OMG (Object Management Group), организация разработчиков Java
— JCP (Java Community Process), IEEE (Institute of Electrical and Electronics
Engineers) и др.
Качество программного обеспечения определяется стандартом ISO 9126
[6] как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.
Различаются понятия внутреннего качества, связанного с характеристиками программного обеспечения (ПО) самого по себе, без учета его поведения; внешнего качества, характеризующего ПО с точки зрения его поведения; и качества ПО при использовании в различных контекстах — того качества, которое ощущается пользователями при конкретных сценариях работы ПО. Для всех этих аспектов качества введены метрики, позволяющие оценить их. Кроме того, для создания добротного ПО существенное значение имеет качество технологических процессов его разработки.
ISO 9126 — это международный стандарт, определяющий оценочные характеристики качества программного обеспечения. Российский аналог стандарта ГОСТ 28195. Стандарт разделяется на четыре части, описывающие следующие вопросы: модель качества, внешние метрики качества, внутренние метрики качества, метрики качества в использовании.
Информационная система (ИС) — система, предназначенная для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию (ISO/IEC 2382:2015)[7].
Предназначена для своевременного обеспечения надлежащих людей надлежащей информацией[14], то есть для удовлетворения конкретных информационных потребностей в рамках определённой предметной области, при этом результатом функционирования информационных систем является информационная продукция — документы, информационные массивы, базы данных и информационные услуги[17].
3. ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ АРХИТЕКТУРЫ
ИНФОРМАЦИОННЫХ СИСТЕМ
На основе приведенных определений рассмотрим определение архитектуры информационных систем.
Определений архитектуры информационных систем много. На сайте SEI (Software Engineering Institute)
13 имеется специальный раздел, посвященный определениям архитектуры, где их собрано более ста. Различные источники дают следующие оперделения:
• архитектура — организационная структура системы;
• архитектура информационной системы
— концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы;
• архитектура — базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и окружением, а также принципы, определяющие проектирование и развитие системы;
• архитектура — набор значимых решений по поводу организации системы программного обеспечения, набор структурных элементов и их интерфейсов, при помощи которых компонуется система вместе с их поведением, определяемым во взаимодействии между этими элементами, компоновка элементов в постепенно укрупняющиеся подсистемы, а также стиль архитектуры, который направляет эту организацию (элементы и их интерфейсы, взаимодействия и компоновку);
• архитектура программы или компьютерной системы — структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними;
• архитектура — структура организации и связанное с ней поведение системы.
Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части и условия сборки частей. Части, взаимодействующие через интерфейсы, включают классы, компоненты и подсистемы;
• архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений в отношении структур программы и взаимодействий между этими структурами, составляющих системы.
Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения
14 предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания.
Для того чтобы разобраться в этом многообразии определений, выделим наиболее существенные стороны архитектуры ИС.
Основным критерием выбора архитектуры и инфраструктуры ИС в услових рыночной экономики является минимизация совокупной стоимости владения системой. Из этого следуют два основных тезиса.
1.
В проектах построения информационных систем, для которых важен экономический эффект, необходимо выбирать архитектуру системы с минимальной совокупной стоимостью владения.
2.
Совокупная стоимость владения ИС состоит из плановых затрат и стоимости рисков. Стоимость рисков определяется стоимостью бизнес-рисков, вероятностями технических рисков и матрицей соответствия между ними.
Матрица соответствия определяется архитектурой ИС.
Термин «архитектура информационной системы» обычно довольно согласованно понимается специалистами на уровне подсознания, но при этом и определения этого понятия неоднозначны. Имеются два основных класса определений архитектур — «идеологические» и «конструктивные».
Основные идеологические определения архитектуры ИС таковы:
1.
Архитектура ИС — набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой;
2.
Архитектура ИС — набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения.
Эти определения объединяет то, что если ключевое решение приходится изменять при изменении бизнес-технологии в рамках бизнес-видения, то резко возрастает стоимость владения системой. Как следствие возникает понимание важности принятия архитектуры системы как стандарта предприятия ввиду значимости архитектурных решений и их устойчивости по отношению к изменениям бизнес- технологии. Важный вывод из первого определения — архитектура системы должна строиться еще на стадии технико-экономического
15 обоснования системы. Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы:
• что делает система?;
• на какие части она разделяется?;
• как эти части взаимодействуют?;
• где эти части размещены?.
Таким образом, архитектура ИС является логическим построением, или моделью, и влияет на совокупную стоимость владения через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т. п. — т. е. через то, что мы называем инфраструктурой ИС. При этом инфраструктура включает решения не только по программному обеспечению, но и по аппаратному комплексу и организационному обеспечению.
3.1. Информационная система как объект архитектуры
Выше было приведено одно из определений информационной системы.
Применительно к информационным системам термин «архитектура» используется достаточно часто. Данный термин может относиться к организации, программно-аппаратному комплексу, программной системе или центральному процессору.
Применительно к организации обычно используют понятие корпоративная архитектура (enterprise architecture), при этом выделяются следующие типы архитектур: бизнес-архитектура (Business architecture), ИТ- архитектура (Information Technology Architecture), архитектура данных (Data
Architecture), архитектура приложения (Application Architecture) или программная архитектура (Software Architecture), техническая архитектура
(nardware Architecture). Совокупность данных архитектур и является архитектурой ИС (рис. 2).
Бизнес-архитектура, или архитектура уровня бизнес-процессов, определяет бизнес-стратегии, управление, организацию, ключевые бизнес- процессы в масштабе предприятия, причем не все бизнес- процессы
16 реализуются средствами ИТ-технологий. Бизнес-архитектура отображается на
ИТ-архитектуру.
ИТ-архитектура рассматривается в трех аспектах:
• обеспечивает достижение бизнес-целей посредством использования программной инфраструктуры, ориентированной на реализацию наиболее важных бизнес-приложений;
• среда, обеспечивающая реализацию бизнес-приложений;
• совокупность программных и аппаратных средств, составляющая информационную систему организации и включающая, в частности, базы данных и промежуточное программное обеспечение.
Рис 2. Архитектура информационной системы
Архитектура данных организации включает логические и физические хранилища данных и средства управления данными. Архитектура данных должна быть поддержана ИТ-архитектурой. В современных ИТ-системах, ориентированных на работу со знаниями, иногда выделяют отдельный тип архитектуры — архитектуру знаний (Knowledge Architecture).
Программная архитектура отображает совокупность программных приложений. Программное приложение — это компьютерная программа, ориентированная на решение задач конечного пользователя. Архитектура приложения — это описание отдельного приложения, работающего в составе
ИТ-системы, включая его программные интерфейсы. Архитектура приложения
17 базируется на ИТ-архитектуре и использует сервисы, предоставляемые ИТ- архитектурой.
Техническая архитектура характеризует аппаратные средства и включает такие элементы, как процессор, память, жесткие диски, периферийные устройства, элементы для их соединения, а также сетевые средства.
Часто нельзя провести четкой границы между ИТ-архитектурой и архитектурой отдельного приложения. В частности в том случае, когда некоторую фупкцию требуется реализовать в нескольких приложений, она может быть перенесена на уровень ИТ-архитектуры. Обычно приложения интегрируются средствами ИТ-архитектуры. Элементы архитектуры данных часто интегрируются в приложения.
3.2. Архитектура и проектирование информационных систем
Архитектурное описание самым тесным образом связано с процессом проектирования ИС, причем в ряде определений термина «архитектура» на этот факт указывается в явном виде. Обычно выделяются пять различных подходов к проектированию, которые называют также стилями проектирования и, по существу, определяют группы методологий разработки ПО:
• календарный стиль — основанный на календарном планировании
(Calendar-driven);
• стиль, основанный на управлении требованиями (Requirements- driven);
• стиль, в основу которого положен процесс разработки документации (Documental ion-driven);
• стиль, основанный на управлении качеством (Quality-driven);
• архитектурный стиль (Architecture-driven).
Основой календарного стиля является график работ. Команда разработчиков выполняет работы поэтапно. Проектные решения принимаются из целей и задач конкретного этапа. Слабыми местами данного стиля являются то, что основные решения принимаются исходя из локальных целей, при этом мало внимания уделяется процессу разработки, разработке документации,
18 созданию стабильных архитектур и внесению изменений. Все это приводит к высокой суммарной стоимости владением в долгосрочном плане. Данный стиль считается морально устаревшим, однако многие организации продолжают его использовать.
Стиль, основанный на управлении требованиями, предполагает, что основное внимание уделяется функциональным характеристикам системы, при этом часто недостаточно внимания уделяется нефункциональным характеристикам, таким как масштабируемость, портабельность, подцерживаемость и другим, определенным в ISO 9126. Проектные решения принимаются преимущественно исходя из локальных целей, связанных с реализацией тех или иных функций. Данный подход достаточно эффективен в случае, если требования определены и не изменяются в процессе проектирования. Основные недостатки данного подхода следующие: недостаточное внимание уделяется требованиям стандарта ISO 9126
(управление качеством); разрабатываемые архитектуры, как правило, не являются стабильными, так как каждая из реализуемых функций отображается на один или несколько функциональных компонентов. Это обстоятельство усложняет добавление к системе новых требований. Данный подход позволяет успешно отслеживать требования в плане реализации требуемой функциональности, однако использование его для долгосрочных проектов является неэффективным.
Стиль, в основу которого положен процесс разработки документации, до настоящего времени продолжает использоваться в правительственных организациях и крупных компаниях. Данный стиль может рассматриваться как вырожденный вариант стиля, основанного на управлении качеством, и ориентирован на разработку документации. В качестве основных недостатков данного подхода выделяются следующие: неоправданно много времени и сил затрачивается на разработку документации в ущерб качеству разрабатываемого кода. При этом создаваемая документация часто не используется ни пользователем, ни заказчиком.
19
Стиль, основанный на управлении качеством, предполагает самое широкое использование различных мер для отслеживания критичных с точки зрения функционирования параметров. Например, требуется получить время реакции системы на запрос менее одной секунды или обеспечить среднее время между отказами не менее 10 лет. В этом случае данные параметры отслеживаются на всех этапах проектирования систем и часто это делается в ущерб другим характеристикам, таким как масштабируемость, простота сопровождения и т. п. Типовыми проблемами, возникающими при использовании данного стиля, являются следующие: часто оптимизируются не те параметры, которые должны быть в действительности, когда появляются новые требования, бывает очень трудно изменить функциональность системы.
Созданные таким образом системы обычно не отличаются высоким качеством архитектурных решений. В целом данный стиль считается консервативным. Его использование может быть оправдано в случае, когда необходимо создать системы с экстремальными характеристиками.
Архитектурный стиль представляет собой наиболее зрелый подход к проектированию. В рамках данного стиля во главу угла ставится создание фреймворков, которые могут быть легко адаптированы ко всем потенциальным требованиям всех потенциальных заказчиком. Отличительная особенность данного стиля состоит в том, что задача проектирования разбивается на две отдельные подзадачи: создание многократно используемого фреймворка и создание конкретного приложения (системы) на его основе. При этом эти две задачи могут решать разные специалисты. Основная цель создания данного стиля — это устранение недостатков стиля, основанного на управлении требованиями. Использование архитектурного стиля позволяет реализовать инкрементное и итеративное проектирование, т.е. оперативно изменять существующую и добавлять новую функциональность.
В процессе проектирования важное значение приобретают атрибуты качества ИС.
20
Понятие качества ИС соответствует понятию о том, что система успешно справляется со всеми возлагаемыми на нее задачами, имеет хорошие показатели надежности и приемлемую стоимость, удобна в эксплуатации и обслуживании, легко сочетается с другими системами и в случае необходимости может быть модифицирована.
Разные группы пользователей имеют различные точки зрения на характеристики качества ИС. Например, если задать вопрос о том, какой должна быть хорошая ИС, то от пользователя можно получить следующие варианты ответов:
• система имеет хорошую производительность;
• система имеет широкие функциональные возможности;
• система удобна в эксплуатации;
• система надежна.
Менеджер даст скорее всего другие варианты ответов:
• стоимость системы не должна быть изначально очень высокой;
• система не должна быть очень дорогой в эксплуатации;
• система не должна морально устаревать в течение возможно более длительного периода времени и в случае необходимости может быть легко модифицирована.
Для системного администратора наиболее важными могут оказаться такие характеристики системы, как
• надежность и стабильность работы;
• простота администрирования;
• наличие хорошей эксплуатационной документации;
• хорошая поддержка изготовителем.
Другие заинтересованные лица могут иметь свои точки зрения на то, какой должна быть качественная система.
Поскольку в современных ИС ключевой компонентой является программная компонента, а пользователи, работающие с системой, в большинстве случаев взаимодействуют непосредственно с программной
21 компонентой, поэтому показатели качества информационных и программных систем в значительной степени совпадают.
Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем, необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспособна развиваться и удовлетворять растущие потребности пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации, как SEI (Software Engineering Institute), WWW (консорциум World
Wide Web), OMG (Object Management Group), организация разработчиков Java
— JCP (Java Community Process), IEEE (Institute of Electrical and Electronics
Engineers) и др.
Качество программного обеспечения определяется стандартом ISO 9126
[6] как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.
Различаются понятия внутреннего качества, связанного с характеристиками программного обеспечения (ПО) самого по себе, без учета его поведения; внешнего качества, характеризующего ПО с точки зрения его поведения; и качества ПО при использовании в различных контекстах — того качества, которое ощущается пользователями при конкретных сценариях работы ПО. Для всех этих аспектов качества введены метрики, позволяющие оценить их. Кроме того, для создания добротного ПО существенное значение имеет качество технологических процессов его разработки.
ISO 9126 — это международный стандарт, определяющий оценочные характеристики качества программного обеспечения. Российский аналог стандарта ГОСТ 28195. Стандарт разделяется на четыре части, описывающие следующие вопросы: модель качества, внешние метрики качества, внутренние метрики качества, метрики качества в использовании.