Что такое системные требования в бизнес аналитике

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

Содержание статьи скрыть

Кто такой системный аналитик и чем занимается

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

Главная задача системного аналитика — разработка информационной системы, которая помогает наладить бизнес-процесс, автоматизировать его и решить проблемы компании

Системный аналитик читает код, разрабатывает программное обеспечение, проектирует информационные системы и внедряет их в бизнес-процессы. Он собирает требования заказчиков продукта, переводит на технический язык и превращает их в задачи для команды. После того как по его ТЗ собран готовый продукт, он проверяет его и презентует заказчику.

Зачем нужны бизнес требования?

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

Возможные задачи системного аналитика

Как я стал системным-аналитиком

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

Постепенно вместо исполнителя я стал своеобразным переводчиком задач между бизнесом и разработкой. Я собираю все требования, объединяю, систематизирую и описываю задачи команде. Я формирую задачи на создание системы, программного обеспечения и приложений — делаю то самое «техническое задание» или ТЗ, которое будет отвечать задачам бизнеса и которое поймут разработчики. Так я стал приносить больше пользы компании , у меня поменялась должность и в разы выросла зарплата»

Андрей, системный аналитик

Ежедневные советы от диджитал-наставника Checkroi прямо в твоем телеграме!
Подписывайся на канал
Подписаться

Востребованность профессии «Системный аналитик»

По данным сайта hh.ru, в июле 2021 было открыто около 3700 вакансий «системный аналитик». Около 2000 специалистов требуются в Москве, остальных ждут в Санкт-Петербурге и регионах. В этом списке более 800 удалённых вакансий, которые доступны специалистам из любой точки мира.

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

Бизнес-анализ или Системный анализ? Отличия и обязанности

График и формат работы системного аналитика

Поскольку от системного аналитика зависит работа всей команды и специалисту такого профиля приходится зачастую согласовывать большое количество вопросов с разными людьми, то полный рабочий день с обязательным присутствием в офисе — наиболее распространённое требование работодателей. Чаще всего работать в офисе предлагают по стандартной системе — 5/2 по 8-9 часов в день.

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

Статистика по форматам работы для системного аналитика

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

Зарплата системного аналитика

По данным сервиса Glassdoor средняя зарплата системного аналитика по Москве — 150 000 руб. в месяц. На hh.ru предложения по зарплате варьируются от 65 000 руб. до 330 000 руб. в месяц и выше, в зависимости от уровня специалиста, а также масштабов компании, сферы её деятельности и географической локации. Компании из регионов могут платить меньше своим специалистам, чем московские организации и филиалы зарубежных фирм.

Плюсы и минусы профессии «Системный аналитик»

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

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

• необходимость проводить много времени за компьютером — длительная работа без отрыва от монитора вредит здоровью;
• стресс и высокая ответственность — зачастую от решений системного аналитика зависит эффективность работы всей компании. К тому же многие задачи подразумевают жёсткие дедлайны и работу сверхурочно;
• необходимость специализированных знаний — профессия системного аналитика не подразумевает быстрого и лёгкого старта. Чтобы устроиться на работу, необходимо освоить хотя бы базовый набор аналитика: язык запросов к базам данных SQL, математическую статистику, основы построения удобного интерфейса и Customer Journey Map — путь пользователя при взаимодействии с продуктом.

Навыки , необходимые для системного аналитика

Системный аналитик выполняет множество разноплановых задач, поэтому должен:

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

Личностные характеристики системного аналитика

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

• восприимчивость к новой информации — системный аналитик должен схватывать всё на лету и держать в голове большой объём информации;
• аналитический склад ума поможет быстрее и точнее выстраивать модели и гипотезы, а также продуктивно обрабатывать данные;
• коммуникабельность — в отличие от других IT-профессий, где специалист может быть волком-одиночкой, системный аналитик — командный игрок, которому часто приходится договариваться с другими людьми и отстаивать ту точку зрения, что обеспечит эффективность деятельности всей компании;
• стрессоустойчивость — системному аналитику приходится работать с большим количеством задач и соблюдать сразу несколько дедлайнов;
• усидчивость — этот специалист проводит много времени за компьютером, поэтому способность долго, не отрываясь, сидеть за работой очень пригодится.

Как стать с истемным аналитиком

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

Освоить специальность можно тремя способами:

1. На практике. Попасть в компанию, где готовы делиться знаниями, обучать этой профессии и растить своих специалистов, но приоритетное право занять вакансию получают те, у кого есть техническое или экономическое образование.
2. Получить высшее образование . В вузах есть специальности «Системный анализ и управление». Дипломированным специалистам проще устроиться на официальную работу и начать карьерный рост, но на обучение придётся потратить не менее четырёх лет.
3. Онлайн-обучение. Пройти курс по системному анализу на одной из образовательных платформ. Многие программы рассчитаны на людей без специальных знаний и предлагают обучение с нуля. Средний срок обучения — 6 месяцев. Обычно такие курсы делают упор на практику — это позволяет быстро сформировать портфолио и влиться в рабочий процесс после обучения. По окончанию курса выдаётся сертификат.

Как и куда развиваться в профессии

Карьерный рост системного аналитика может быть как вертикальным, так и горизонтальным.

Вертикальный карьерный рост

Начинающий специалист может пройти все традиционные этапы интернет-профессий: начинающий — джуниор, специалист с опытом — мидл и опытный специалист — синьор. Эти статусы определяются не возрастными границами, а зависят от опыта работы, объёма знаний и количества выполненных проектов.

• Джуниор — это стажёры и младшие системные аналитики, которые только начинают свой путь в профессии. Требования, предъявляемые к ним работодателям довольно просты. В основном — это высшее, но не обязательно профильное образование, системное мышление, владение MS Office. Преимуществом будет знание различных языков программирования и моделирования: SQL, BPMN, UML, JSON или XML.
• Мидл — это опытные специалисты, которые могут быстро внедриться в проект и начать решать задачи компании в первые же недели работы. От таких специалистов требуется: опыт работы в этой должности не менее двух-трёх лет, умение работать с отчётностью, аналитическими документами и технической документацией.

Пример вакансий джуниор и мидл специалиста

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

Горизонтальный карьерный рост

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

• Бизнес-аналитик — многие системные аналитики переключаются на бизнес-аналитику, граница между этими профессиями тонкая и зачастую обязанности схожи. Но бизнес-аналитик лучше разбирается в экономических показателях — как снизить издержки и повысить прибыль после автоматизации и внедрения правильного ПО.
• Системный архитектор — систематизирует знания в IT-архитектуре и проектирует программное обеспечение. В отличие от с истемного аналитика, который только продумывает строение системы, архитектор самостоятельно её создаёт и следит за тем, чтобы она могла быстро изменяться и гармонично вписываться в бизнес-процессы.
• Менеджер продукта — собирает и анализирует отзывы клиентов, чтобы понимать плюсы и минусы продукта. Он составляет задания для разработчиков и вместе с ними доводит продукт до совершенства.

Подведём итоги

Профессия системного аналитика сегодня востребована на рынке труда. Таких специалистов ждут не только в IT-сфере, системные аналитики востребованы в сфере продаж, банковских и инвестиционных компаниях. Зарплата начинающего системного аналитика стартует от 65 000 руб. в месяц, профессионалы же в этой сфере могут получать более 300 000 руб. в месяц.

Освоить специальность с нуля можно на курсе «Системный аналитик» от Нетологии . Вы научитесь решать сложные организационно-технические задачи, раскладывать процессы на множество частей и анализировать их, находить подходящие решения с учётом потребностей бизнеса и возможностей команды разработки. Курс на две трети состоит из практики — это поможет легко справиться с тестовыми заданиями при трудоустройстве и освоиться в задачах на рабочем месте.

Поделитесь материалом в соцсетях — обсудите его с друзьями и коллегами!

Не знаете с чего начать?

Получите персональный список курсов, пройдя бесплатный тест по карьере

Источник: checkroi.ru

Глава 4 Аналитик требований

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

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

В этой главе я познакомлю вас с функциями аналитика требований, требованиями, которые предъявляются к его знаниям и опыту, а также расскажу, как воспитать аналитика в своей организации (Wiegers, 2000). Пример должностных обязанностей аналитика требований опубликован на: https://www.processimpact.com/goodies.shtml.

Роль аналитика требований

Аналитик требований — это основное лицо, отвечающее за сбор, анализ, документирование и проверку требование к проекту. Это основной коммуникативный канал между группой клиентов и командой разработчиков (рис. 4-1), хотя, конечно, не единственный: есть и другие, Аналитик отвечает за сбор и распространение информации о продукте, а менеджер проекта — за обмен информацией о проекте.

Рис. 4-1. Обязанности аналитика требований: наведение коммуникативных мостов между различными группами клиентов и разработчиков проекта

Аналитик требований — это одна из ролей участников проекта, а не обязательно название должности. На эту роль можно назначить одного или нескольких специалистов. Кроме того, функции аналитика могут выполнять другие члены команды параллельно со своими обязанностями, например менеджер проекта, менеджер по продукту, профильный специалист (subject matter expert), разработчик и даже пользователь. В любом случае аналитик должен обладать всеми навыками, знаниями и личными качествами, необходимыми для эффективной работы.

От таланта аналитика зависит успех проекта. Один из клиентов, которых я консультировал, пришел к выводу, что спецификации с требованиями, созданные опытными аналитиками, удается изучать вдвое быстрее, чем созданные новичками, поскольку в первых меньше недостатков. В модели Сосото II широко применяемой для оценки проектов, указано, что опыт и способности аналитика требований сильно влияют на материальные и трудовые затраты, связанные с реализацией проекта (Boemn et all., 2000). Привлекая опытных специалистов можно на треть снизить связанные с проектом трудозатраты по сравнению с аналогичными проектами, где заняты неопытные аналитики. Способности аналитика оказывают даже большее влияние, чем его опыт: трудозатраты удается сократить вдвое.

Задачи аналитика.

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

Определить бизнес-требования. Ваша работа в качестве аналитика начинается, когда вы помогаете спонсору, менеджеру продукта или менеджеру по маркетингу определить бизнес-требования к проекту. Возможно, первое, что следует спросить: «Зачем мы начинаем этот проект?» Бизнес-требования включают бизнес-цели организации и представление о внешнем виде и функциональности системы. Можно разработать шаблон документа об образе и границах (см. главу 5) и, расспросив людей, имеющих представление о внешнем виде системы, получить у них необходимую информацию.

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

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

Выявить требования. Требования к программному продукту не лежат на виду и не ждут, когда какой-нибудь аналитик придет и соберет их, Профессиональный аналитик помогает пользователям четко обрисовать функции системы, необходимые им для достижения бизнес-целей. (Подробнее об этом — в главах 7 и 3). Для этого у него в арсенале припасено множество способов сбора информации:

· посещение рабочих мест клиентов;

· анализ документооборота и задач;

· анализ конкурирующих продуктов;

· исследование существующих систем;

· ретроспективы развития предыдущего проекта.

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

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

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

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

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

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

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

Управлять требованиями. Аналитик требований вовлечен во все этапы разработки ПО, его задача — помочь создать, обсудить и осуществить план управления требованиями к проекту. Создав документацию, аналитик управляет требованиями и проверяет, как они реализуются в продукте. Хранение требований с помощью специальных коммерческих утилит упрощает управление ими. Подробнее о средствах управления требованиями — в главе 21.

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

Источник: poisk-ru.ru

Как мы делаем аналитику IT-проектов: прояснение требований

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

5664 просмотров

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

Vision/Виденье проекта

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

Проще говоря, в Vision формулируется:

• кто чего хочет
• почему и зачем хочет
• как должно быть устроено, чтобы всем понравилось
• что нужно сделать, чтобы этого добиться

В Vision зафиксированы наиболее существенные требования, ограничения и приемлемые уровни качества.

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

Пример Vision
User Stories/Юзер сторис

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

Текст каждой формулировки — User Story — должен объяснять роль или действия юзера в системе, его потребность и профит, который он получит после того, как история случится.

Особенности User Stories:

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

Именно на основании User Stories проводится дальнейший анализ.

Пример User Stories
Use Cases/Юзкейсы

Так же как и User Stories описывают, как пользователь должен взаимодействовать с системой, чтобы достичь конкретной цели. В чём же тогда отличие? User Story помогает определить задачу и намерение. А Use Cases не сообщают о задачах и намерениях, они более подробно фиксируют функциональные возможности.

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

Формулировка User Story может быть такой: «Я как пользователь хочу иметь возможность совершать математические операции, чтобы упростить механические расчеты».

А кейсы, соответствующие данной User Story, могут быть такими:

• Ввести число
• Добавить число
• Отнять число
• Разделить на число
• Умножить на число
• Подвести итог
• Добавить результат в память
• Очистить память
• Показать число в памяти
• Сбросить все
• Отключить устройство

Пример Use Cases на проекте iFarm — AgroTech информационной системы
Инструменты для наглядного описания процессов, алгоритмов, взаимосвязей между сущностями

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

В таком случае мы можем столкнуться с реальными функциональными ограничениями на то, что мы можем сделать за адекватный срок. Например, API, которую нам предоставляет внешняя система, накладывает обязательства на реализацию функционала регистрации пользователя. Это могут быть определённые поля, параметры или условия, которые мы должны включить в запрос. Иногда технические ограничения накладываются и на пользовательский интерфейс. Чтобы разобраться в существующих ограничениях и с их учётом создать удобный функционал, нужно разобраться, какие существуют и какие должны быть реализованы интеграционные сценарии, нарисовать диаграмму компонентов или развертывания.

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

Описание сущностей

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

Список Entities
Диаграммы компонентов

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

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

Таким образом, диаграмма компонентов помогает:

• визуализировать общую структуру исходного кода системы
• многократно использовать отдельные фрагменты программного кода
• представить концептуальную и физическую схему баз данных

В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты.

Диаграмма развертывания

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

Элементами диаграммы развертывания являются узлы, компоненты и связи между ними. Узел — это некоторый физически существующий элемент системы. В качестве узла могут рассматриваться компьютеры, датчики, принтеры, модемы, цифровые камеры, сканеры и т.д.

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

Карта экранов

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

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

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