Статья посвящена методам проектирования архитектуры информационных систем. Описаны достоинства и недостатки рассмотренных подходов. Представлено мнение автора об использовании нужного из перечисленных методов при проектировании архитектуры различных программных продуктов.
Ключевые слова: информационная система, архитектура, методы проектирования.
Проектирование информационной системы представляет собой сложный процесс, который адаптирует заданные требования заказчика в описание архитектуры программного продукта, который может выполнять нужные функции. Архитекторы информационных систем обычно решают поставленную задачу, сосредотачиваясь на отдельных аспектах проектирования, таких как данные или конкретные приложения, и опираясь на свой предыдущий опыт для сравнения альтернативных архитектурных решений. Затраты на приобретение необходимого оборудования обычно учитываются, но связанные с ними эксплуатационные расходы и затраты на техническое обслуживание часто игнорируются или недооцениваются. Сложность оптимизации отдельных задач проектирования приводит к тому, что исследователи избегают перспективы глобальной оптимизации, и, таким образом, архитектура информационной системы обычно является результатом сопоставления нескольких локальных оптимумов [1].
Техническая архитектура — это совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений [2].
В широком смысле информационной системой называется комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства и информационные ресурсы, а также системный персонал и обеспечивающий поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей.
Достаточно часто под информационной системой понимается прикладная программная подсистема, ориентированная на сбор, хранение, поиск и обработку текстовой и/или фактографической информации [3].
Проектирование ИС представляет собой последовательность выполнения взаимообусловленных действий — процедур. В свою очередь, процедуры подразумевают использование определенных методов, основанных на тех или иных законах природы и общества. Сложность процесса проектирования информационных систем (как и любой другой творческой деятельности), нестандартность проектных (жизненных) ситуаций вызывают необходимость знать различные методы проектирования информационных систем и умения владеть ими.
Метод проектирования информационных систем — это целенаправленная совокупность процедур, позволяющая получить в результате описание разрабатываемой информационной системы с такой степенью детализации, которая достаточна для ее реализации [4].
Можно выделить 5 основных методологий проектирования информационных систем [5]:
– календарный метод;
– метод, основанный на управлении требованиями;
– метод, в основу которого положен процесс разработки документации;
– метод, основанный на управлении качеством;
– архитектурный метод.
При проектировании информационной системы календарным методом в основу закладывается график работ, которые выполняются поэтапно. Решения по выполнению проекта принимаются из цели и задач конкретного этапа разработки. Недостатком данного метода является принятие решений по проектированию исходя из локальных целей, уделяя мало внимания процессу разработки, разработке технической документации, созданию стабильной архитектуры и внесению изменений. Это приводит к высокой суммарной стоимости проекта для заказчика. Данный метод считается устаревшим, однако многие организации продолжают его использовать.
Метод, основанный на управлении требованиями, уделяет основное внимание функциональным характеристикам системы, при этом часто недостаточно прорабатываются нефункциональные характеристики, например, такие как масштабируемость. Данный подход достаточно эффективен в случае, если требования определены в начале работы над проектом и не изменяются в процессе проектирования, что сегодня бывает крайне редко. Основным недостатком данного подхода можно выделить отсутствие стабильной разрабатываемой архитектуры, поскольку каждая из реализуемых функций отображается на один или несколько функциональных компонентов, что существенно усложняет добавление к системе новых требований. Данный метод позволяет успешно отслеживать процесс выполнения всех требований в плане реализации проекта, однако использование его для долгосрочных проектов является неэффективным.
Метод, в основу которого положен процесс разработки документации, направлен на разработку необходимой технической литературы в рамках проекта. Этот подход продолжает использоваться в правительственных организациях и крупных компаниях. Главными недостатками данного метода можно выделить затраты большого количества времени и сил на разработку документации в ущерб качеству и тестированию разрабатываемого кода. При этом пользователь и заказчик чаще всего не используют созданную документацию.
Метод, основанный на управлении качеством, предполагает использование различных мер для отслеживания определенных параметров программного продукта. Например, по техническому заданию необходимо получить время реакции системы на запрос менее одной миллисекунды, тогда этот параметр отслеживается на всех этапах проектирования информационной системы и часто это происходит в ущерб другим характеристикам, например, таким как масштабируемость и простота сопровождения. При использовании данного метода можно выделить следующие недостатки: чаще всего оптимизируются не те параметры, которые должны быть в действительности, а также когда появляются новые требования от заказчика, могут возникнуть проблемы с изменением функциональности разрабатываемой информационной системы. Созданные таким образом информационные системы обычно представляют собой низкокачественные архитектурные решения, а данный метод считается консервативным. Его использование может быть оправдано в случае, когда необходимо создать системы с экстремальными характеристиками.
В основу архитектурного метода ставится создание фреймворков, которые могут быть легко адаптированы ко всем техническим требованиям всех потенциальных заказчиков. Отличительной чертой этого подхода является разбиение задачи проектирования на две отдельные подзадачи: проектирование и разработка многократно используемого фреймворка и создание конкретного программного продукта на его основе. При этом эти две задачи могут решаться разными специалистами. Использование архитектурного подхода позволяет оперативно изменять существующую и добавлять новую функциональность в проектируемую информационную систему.
В таблице 1 представлены достоинства и недостатки рассмотренных подходов к построению архитектуры информационных систем.
Таблица 1
Достоинства и недостатки методов к построению архитектуры ИС
|
Метод |
Достоинства |
Недостатки |
|
Календарный метод |
Выполнение проекта в срок, поскольку график выполнения работ является приоритетным. Поэтапное выполнение работ. |
Решения по проектированию принимаются исходя из локальных целей. Создание стабильной архитектуры не ставится в приоритет. Устаревший метод. |
|
Метод, основанный на управлении требованиями |
Отслеживание выполнения всех требований в плане реализации проекта. Особое внимание уделяется функциональным характеристикам системы. |
Отсутствие стабильной разрабатываемой архитектуры. Сложность добавления новых требований к проекту. Недостаточная проработка нефункциональных характеристик. Неэффективен для долгосрочных проектов. |
|
Метод, в основу которого положен процесс разработки документации |
Подробно описанная документация для пользователя и заказчика. Использование в правительственных организациях и крупных компаниях. |
Большие затраты ресурсов команды на разработку документации в ущерб качеству. Пользователь и заказчик чаще всего не используют созданную документацию. |
|
Метод, основанный на управлении качеством |
Создание систем с экстремальными характеристиками. Покрытие большей части кода тестами. Использование различных мер для отслеживания определенных параметров программного продукта. |
Оптимизация не тех параметров, которые должны быть в действительности. Сложность изменения функциональности при появлении новых требований. |
|
Архитектурный метод |
Разбиение задачи на подзадачи. Создание фреймворков, который может легко адаптироваться под разные требования заказчиков. Оперативное добавление новой функциональности. |
Выполнение работы разными специалистами. |
На основе представленных выше методов проектирования архитектуры информационных систем можно предположить, что для проектирования мобильного приложения лучше всего подойдет архитектурный метод, поскольку он актуален на данный момент и его использование упрощает работу разработчику, если подобный программный продукт уже был написан ранее. При проектировании десктопного приложения лучше использовать метод, основанный на управлении требованиями, поскольку настольные программы создаются для определенных заранее целей и выполняют определенный функционал, который практически всегда остается неизменным. Для разработки веб-сайта больше всего подойдет использование архитектурного метода, поскольку на сегодняшний день уже существует большое количество фреймворков, которые могут быть использованы для реализации поставленной задачи.
Литература:
- Ardagna D., Francalanci C., Piuri V. Designing and rightsizing the information system architecture //Information Systems Frontiers. — 2004. — Т. 6. — №. 3. — С. 229–245.
- Вакорин М. П. Архитектура предприятий и информационных систем: учебное пособие / М. П. Вакорин, Д. Н. Достовалов. — Новосибирск: Изд-во НГТУ, 2022. — 62 с.
- Рогозов Ю. И., Свиридов А. С., Кучеров С. А. Архитектура информационных систем: учебное пособие. — Ростов-на-Дону: Изд-во ЮФУ, 2014. — 117 c.
- Бражнев С. Методы проектирования информационных систем / С. Бражнев. — Текст: электронный // Онлайн-дневник Сергея Бражнева: [сайт]. — URL: https://brasmlibras.ru/metody-proektirovaniya-informacionnyh-sistem/ (дата обращения: 04.12.2022).
- Галимянов А. Ф., Галимянов Ф. А. Архитектура информационных систем / А. Ф. Галимянов, Ф. А. Галимянов. — Казань: Казан. ун-т, 2019. — 117 с.
