- •Введение
- •1. Цели и задачи архитектора информационных систем
- •1.1. Цели создания информационных систем
- •1.2. Базовые структуры информационных систем
- •1.3. Уровни реализации архитектуры ИС
- •1.4. Атрибуты качества информационных систем
- •1.5. Сопровождение бизнес-ориентированных ИС
- •2.2. Структурное программирование
- •2. Парадигмы программирования
- •2.1. Модульное программирование
- •2.4. Функциональное программирование
- •2.5. Общие тенденции развития парадигм программирования
- •3. Чистая архитектура
- •3.1. Кричащая архитектура
- •3.2. Принципы SOLID
- •3.2.1. Принцип единственной ответственности
- •3.2.2. Принцип открытости/закрытости
- •3.2.3. Принцип подстановки Б. Лисков
- •3.2.4. Принцип разделения интерфейсов
- •3.2.5. Принцип инверсии зависимостей
- •3.3. Программные компоненты и принципы их организации
- •3.3.1. Диаграмма компонентов
- •3.3.2. Принципы взаимосвязи компонентов
- •3.3.3. Принцип эквивалентности повторного использования и выпусков
- •3.3.4. Принцип согласованного изменения
- •3.3.5. Принцип совместного повторного использования
- •3.3.6. Сравнение принципов взаимосвязи компонентов
- •3.4. Компонентный подход как способ динамического изменения архитектуры ИС
- •3.4.1. Принцип ацикличности зависимостей
- •3.4.2. Принцип устойчивых зависимостей
- •3.4.3. Принцип устойчивости абстракций
- •3.4.4. Графическая интерпретация принципов SDP и SAP
- •3.5. Вычислительные архитектуры ИС
- •3.5.1. Клиент-серверная архитектура
- •3.5.2. Трёхзвенная архитектура
- •3.5.3. Микросервисная архитектура
- •3.6. Шаблоны и антишаблоны проектирования ИС
- •3.6.1. Шаблоны проектирования
- •3.6.2. Антишаблоны проектирования
исправлений позволит исправить недочёты проектирования других ат-
рибутов качества.
Атрибуты надёжности и переносимости ИС обеспечиваются на административном уровне, что не снимает требования по соответствию ГОСТ.
Производительность на этапе проектирования закладывается на архитектурном уровне, последующая оптимизация системы выполняет-
ся ближе к концу жизненного цикла.
Внешний вид (удобство использования, UX) на этапе проектиро-
вания по возможности изолируют от всей части проектирования.
1.5. Сопровождение бизнес-ориентированных ИС
Рост сложности ИС представляет собой количественную характе-
ристику, которую можно выразить через отношение динамики роста количества строк кода к динамике роста количества разработчиков.
Сложность бизнес-ориентированных информационных систем является их главной проблемой [23].
Росту сложности информационных систем способствует недоста-
точное внимание к «чистоте» архитектуры системы. Помимо качества архитектурной композиции ИС к росту сложности могут приводить следующие основные проблемы разработки, внедрения и сопровожде-
ния информационных систем:
–нереалистичность бюджетов и сроков;
–недостаточная формализация функциональных требований к ИС;
–ограниченная или отсутствующая документация на разных ста-
диях разработки ИС;
14
–частичное или полное отсутствие процесса тестирования в ходе разработки ИС.
Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем, создаваемых в различных областях экономики.
Рост сложности ИС в свою очередь влечёт за собой следующие проблемы:
–сложность описания предметной области из-за большого коли-
чества реализованных функций, описанных процессов, опери-
руемых системой элементов данных и взаимосвязей между ни-
ми;
–сложность управления процессом разработки из-за высокого числа разработчиков, привлекаемых к сопровождению системы и расширению её функционала;
–разобщённость отдельных групп разработчиков;
–существенную временную протяжённость проекта, связанную с ограничениями по коллективу разработчиков и масштабам реа-
лизуемых функций.
Наиболее простым способом уменьшения динамики роста сложно-
сти систем является фокусировка на реализации потребностей так на-
зываемых стейкхолдеров системы [24].
Понятие «стейкхолдер» может трактоваться по-разному, но в об-
щем виде это организация, являющаяся владельцем автоматизирован-
ного бизнес-процесса.
Например, по определению Э. Фримена, стейкхолдерами компании являются любые индивидуумы, группы или организации, оказывающие значимое влияние на принимаемые компанией решения и/или оказы-
вающиеся под воздействием этих решений. 15
Другое определение даёт Бредли Гугинс: стейкхолдеры – это груп-
пы, организации или индивидуумы, на которые компания влияет и от которых зависит.
И. Фассин даёт следующую классификацию стейкхолдерам (по мере уменьшения их влияния на проект):
–истинные стейкхолдеры – лица, непосредственно включённые в проект;
–стейквотчеры – лица, интересы которых затрагивает проект;
–стейккпиперы – проект не влияет на них, но они регулируют деятельность компании, следят за соблюдением законов;
–стейксикеры – проект не влияет на них, но может непосредст-
венно затронуть их.
Подробнее методология уменьшения скорости роста сложности ИС описана в разделе 3 настоящего пособия.
16