Проектирование архитектуры в нотации ArchiMate с использованием ИИ. Часть 2

В сфере искусственного интеллекта произошло заметное событие. zvntver 53 минуты назад Проектирование архитектуры в нотации ArchiMate с использованием ИИ. Часть 2 Средний 26 мин 1. 8K Блог компании Axenix (ex-Accenture) Искусственный интеллект Анализ и проектирование систем * Будущее здесь “Процесс проектирования любой системы, предназначенной для решения определенных задач, начинается с определения того, что надо спроектировать.

”, Крэг Ларман (Craig Larman). Меня зовут Владимир Зуев, я руководитель разработки JAVA-практики в компании Axenix. Сегодня я хочу представить новую часть из цикла статей о нотации ArchiMate.

Технические детали

В прошлой части мы познакомились с ArchiMate и начали проектировать систему управления беспилотным грузовым автотранспортом для междугородних перевозок. В этой части мы продолжим выполнение данной задачи. Полностью разделяю мнение Крэга Лармана, автора книги «Применение UML 2.

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

Для этого мы подробно разберём требования к системе, составим перечень прецедентов использования c использованием обратного инжиниринга требований, а также сформируем техническое задание. Для решения всех задач будем использовать ИИ. Осмысление требованийCбор и систематизация требований при разработке информационной системы - это фундамент, на котором строится весь проект.

Отраслевые последствия

Ошибки на этом этапе самые дорогие. Закон Бёма (Boehm's Law) гласит, что стоимость исправления ошибки экспоненциально растет по мере продвижения проекта:ошибка в требованиях, найденная на этапе анализа, стоит 1 условную единицу;найденная на этапе проектирования — уже 3–6 единиц;на этапе тестирования — 10–20 единиц;в работающей системе (после внедрения) — 60–100 единиц и выше. Так что гораздо дешевле потратить немного времени на уточнение требований в начале, чем переписывать систему после релиза.

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

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

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.