#собеседование #логическая #задача

На столе лежат девять монет. Одна из них — фаль­шивая. Как при помощи двух взвешиваний можно найти фальшивую монету? (Фальшивая монета легче настоящих.)

‐-------‐----------------------
Посмотреть ответ

​​Рекомендации по проведению интервью при сборе требований.
#сбортребований #интервью

Интервью - беседа с заказчиком или его предсиавителем в офлайн или онлайн режиме.
Чаще применяется  для получения информации по какой-либо конкретной теме или уточнения требований.

Этапы и рекомендации по проведению интервью
Подготовка:
° Определите цели интервью
° Выберите для беседы "подходящего" человека
° Заранее подготовте вопросы, вспомогательные материалы
° Поделитесь повесткой с будущим собеседником

Проведение:
° Установите контакт с собеседником
° Больше спрашивайте, а не предлагайте
° Чередуйте открытые (для получения информации) и закрытые (для уточнения, подтверждения) вопросы.
° Проговаривайте альтернативные ситуации
° Используйте активное слушание
° Старайтесь выяснять "что" и "зачем" хочет получить заказчик, а не "как" это должно быть реализовано.
° Обращайте внимание на неявные/предполагаемые требования
° Придерживайтесь границ проекта
° Фиксируйте информацию
° Не затягивайте время

Завершение:
° Проговорите итоги встречи
° Договоритесь о дальнейших действиях
° Подготовте и разошлите протокол встречи всем заинтересованным лицам

Более подробно познакомиться  с тем, как провести интервью с заказчиком, можно в статье

​​Прототипирование как метод сбора требований.
#сбортребований #прототипирование

Прототипирование - метод,  заключающийся в создании макета/ скелета системы (прототипа), который позволяет предметно обсуждать с пользователем требования к системе, демонстрировать принятые решения, внешний вид системы и порядок работы.

Прототип может быть:
° Статическим - показывает положение элементов в интерфейсе или структуру данных.
° Динамическим - с возможностью демонстрации поведения системы по наступлению определенных событий.
° Интерактивным - позволяет пользователям и участникам заинтересованных сторон выполнять реальные действия так, как это будет работать в разрабатываемой системе.

Выделяют два основных типа (подхода) прототипирования:
° Быстрое (одноразовое) - прототип  используется на этапе сбора требований, после чего "выбрасывается". Чаще концентрируется на наименее понятных требованиях.
° Эволюционное - прототип сохраняется после выявления требований и используется для создания конечного программного продукта. Концентрируется на ясно изложенных требованиях
Подробнее о типах...

Использование метода прототипирования позволяет:
° лучше понять/уточнить требования;
° вовлечь заказчика в процесс разработки;
° минимизировать ошибки проектирования, обнаружить недостаточность или несоответствие требованиям на начальных этапах, за счёт чего сократить  время и стоимости разработки;
° уменьшить расхождения в представлении о программе между разработчиками и пользователями.

-------------
° Почему стоит включить в разработку прототипирование

° Инструменты для прототипирования

° Как использовать бумажные прототипы в интерфейсах: практическое руководство

​​Кто такие стейкхолдеры?
#стейкхолдер #теория

Стейкхолдеры (заинтересованные стороны) - лица или организации, которые:
° Заинтересованы в результате и/или особенностях процесса разработки и развития вашего проекта или продукта
° Могут оказывать влияние на процессы, цели и результаты вашей работы

Стейкхолдер - это носитель определённой роли, а не конкретный человек или организация.

Классифицировать стейкхолдеров можно:
1.По принципу взаимодействия
° Внутренние - все, кто непосредственно работает над результатом и финансирует проект (владельцы компании, основатели проекта, акционеры,  сотрудники..)
° Внешние - те, кто могут каким-то образом повлиять на компанию или на конкретный продукт (госорганы, банки, СМИ, конкуренты, посредники..)

2.По уровню влияния
° Первичные - активно влияют на деятельность организации или выполнение проекта (владельцы, команда проекта, партнёры, клиенты).
° Вторичные - воздействуют на компанию или проект опосредованно (инвесторы, конкуренты, органы власти, СМИ)

----------
Познакомиться чуть подробнее с методами выявления, анализа и управления стейкхолдерами помогут статьи:

° Анализ стейкхолдеров проекта

° Кто такие стейкхолдеры: Таблица интересов стейкхолдеров, Карта заинтересованных сторон, Матрица стейкхолдеров

​​Видеокурс Погружение в SQL + VBA
#sql #excel #vba #видеоуроки

В данном видеокурсе рассматривается вариант взаимодействия SQL и Excel через vba на примере проекта "Магазинчик"

Содержание курса:
Введение
1. Хранимые процедуры
2. Соединяем SQL и Excel
3. Получаем данные в Recordset из БД
4. Получаем данные на форму Form в Excel из Recordset
5. Проектирует таблицы БД
6. Продолжаем получать данные
7. Хранимая процедура для Склада
8. Из формы Excel в БД
9. Рефакторинг кода VBA
10. OUTPUT и SCOPE_IDENTITY
11. IF - ELSE
12. Удаление товаров и функция REPLACE
13. Циклический оператор WHILE
14. Выгружаем данные из БД в Excel
15. SELECT CASE и OUTPUT
16. Права доступа для БД
17. Вызов хранимой процедуры из другой хранимой процедуры
18. Скалярные функции. Возврат значения из функции
19. Временные таблицы
20. Курсор CURSOR. Обработка таблицы циклом
21. MERGE оператор слияния таблиц

Перейти к видеоурокам

​​Уровни требований к ПО.
#требования #уровни #теория

Обычно выделяют три уровня требований.

1. Бизнес-требования - описывают цели, которых хочет достичь заказчик (организация) с помощью разрабатываемой системы.
-- Отвечают на вопрос: "Зачем", "Для достижения каких целей" нужна система;
-- Источники требований: акционеры, покупатели системы, управляющий реальными пользователями, топ-менеджер или ответственный за концепцию продукта.
-- Данные требования можно отразить: в документе о концепции и границах, в уставе проекта, в положении о бизнес-задачах, в документе основных рыночных требований ..
-- Пример: авиакомпания хочет на 20% снизить затраты на сотрудников у стойки в аэропорту;

2. Пользовательские требования  - описывают задачи, которые пользователь сможет (должен иметь возможность) выполнять с помощью разрабатываемой системы.
-- Отвечают на вопрос: "Что" пользователь должен иметь возможность делать с помощью системы;
-- Данные требования можно представить в виде: вариантов использования, пользовательских историй.
-- Источник требований: представители пользователей;
-- Пример: Как пассажир я хочу зарегистрироваться на рейс, чтобы можно было сесть на самолет

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

​​Что такое Бизнес-правила и почему стоит обратить на них внимание при сборе требований к ПО?
#бизнесправила #сбортребований #теория

Бизнес-правила (БП) - представляют описания применяемых в конкретной компании алгоритмов, нормативов, законов, ограничений, проверок, постановлений и политик.

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

Пример:
БП - регистрация на авиарейс заканчивается за 40 мин. до времени вылета;
ФТ - система не должна позволить пользователю (пассажиру) пройти регистрацию, менее чем за 40 мин до времени вылета.

Приведем один из вариантов классификации БП:
° Факты  — верные утверждения о бизнесе на определенный момент времени. (Оплачивается доставка каждого заказа);
° Ограничения - определяют, какие операции не может выполнять система и ее пользователи. (Постоянный посетитель библиотеки может отложить для себя до 10 книг);
° Активаторы операций - при определенных условиях инициируют выполнение определенных действий - «Если <некоторое условие верно или наступило определенное событие>, то <действие>». (Если срок хранения заказа истек, то об этом необходимо уведомить лицо, оформившее данный заказ);
° Выводы - формируют новый факт на основе имеющегося - «Если <некоторое условие верно или наступило определенное событие>, то <факт>». (Если платеж не поступил в течение 30 календарных дней с момента отправки счета, то счет считается просроченным);
° Вычисления - преобразуют существующие данные в новую информацию с использованием математических формул и алгоритмов. (Цена единицы товара снижается на 10% при заказе от 6 до 10 единиц, на 20% — при заказе от 11 до 20 единиц и на 30% — при заказе свыше 20 единиц.)

Источниками БП могут быть:
° Документация - нормативные документы, отраслевые стандарты, документы корпоративных политик, контракты и бизнес-планы, спецификации требований из предыдущих проектов;
° Сотрудники организации;
° Другие системы, в требованиях и коде которых реализованы БП.

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

#собеседование #вопросы #статья

Редакция MC. today изучила, о чем спрашивают на собеседовании в Google, Ford, General Motors, Facebook, Microsoft и других..
Список вопросов привели в статье:
"Эти 15 вопросов задают на собеседованиях в Google, Facebook, Microsoft и других компаниях"

​​Атрибуты качества ПО
#сбортребований #атрибуты #качество #ак #нфт #теория

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

АК можно разделить на две группы:
° Внешние - проявляются в период взаимодействия с системой (напр., доступность, удобство использования, надежность...). Наиболее значимы для пользователей системы.
° Внутренние - характеристики, которые нельзя наблюдать напрямую при работе с системой (напр., возможность модификации, масштабируемость..). Имеют значение для разработчиков и службы тех. поддержки.

Перечень некоторых АК привели в таб. "Атрибуты качества ПО "

Т.к. на практике невозможно удовлетворить в полной мере ожидания по всем возможным АК , необходимо выяснить, какие атрибуты наиболее важны для успеха вашего проекта/продукта.

Этапы выявления АК:
1. Составьте список всех возможных атрибутов (характеристик);
2. Совместно с заинтересованными лицами (пользователи, заказчики, разработчики) определите какие из характеристик наиболее важны для проекта;
3. Определите приоритеты выбранных атрибутов;
4. Выявите конкретные ожидания по каждому атрибуту (т.е. что же именно подразумевают заинтересованные лица под тем, что система, напр.,  должна быть простой в обращении, быстрой, надежной)
5. Создайте конкретные и поддающиеся проверке требования на основе информации, собранной по каждому атрибуту качества.

Важно! При написании требований к качеству следуйте "правилу SMART", то есть они должны быть:
° конкретными (Specific);
° измеримыми (Measurable);
° достижимыми (Attainable);
° актуальными (Relevant);
° ограниченными во времени (Time-sensitive).

​​Критерии качества требований / характеристики требований
#характеристики #требований #анализтребований

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

К таким характеристикам можно отнести:
° Корректность в описании;
° Понятность всем заинтересованным лицам;
° Полнота изложения;
° Однозначность понимания;
° Модифицируемость в случае изменения;
° Прослеживаемость отношения между требованиями;
° Возможность проверки с помощью тестирования;
° Ранжируемость по важности;
° Непротиворечивость в отношении к другим требованиям

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

Пренебрежение данными характеристиками ведёт за собой:
° увеличение итераций на разъяснения и  уточнения требований;
° увеличение разницы между ожидаемым и разрабатываемым продуктом;
° сложности в поддержке требований;
° частые переделки, некоторые из которых будет невозможно реализовать;
° превышение времени и бюджета на разработку;

--------------
Чуть подробнее разобраться в критериях качества требований помогут статьи:

° О критериях качества требований - что такое критерии качества требований, для чего понимать и уметь определять эти критерии, а также, как улучшить качество требований..

° Характеристики качества требований - в статье более подробно рассматриваются некоторые критерии качества

​​Модели разработки ПО
#модель #разработки

Модель разработки ПО - представляет  описание того, какие и в какой последовательности проходит продукт стадии жизненного цикла и что происходит на каждой из них.

Модели разработки ПО разделяют на классические и гибкие.

Классические модели делают акцент на последовательности, сроках и конечных требованиях к продукту.
К ним относят:
° Code and Fix - только пишем код, проверяем и устраняем ошибки;
° Waterfall /каскадная модель - последовательный переход от одного этапа разработки на другой без пропусков и возвращений на предыдущие стадии.
° V-Model - упор на тестирование в ходе разработки.Тесты проводятся параллельно с самим процессом создания продукта. 
° Инкрементная модель - разработка по частям. Проект делится на составные компоненты, команда по очереди готовит каждый из них, затем происходит финальная сборка;
° Спиральная модель представляет повторяющуюся последовательность циклов разработки с непрерывным контролем рисков.  
° Итеративная модель - сначала делается базовая модель продукта, затем следуют итерации по ее усовершенствованию;
° RAD-Model (скоростная разработка продукта) - все этапы создания продукта делятся не несколько отдельных блоков, с каждым из которых работает отдельная команда разработчиков.

Гибкая модель разработки - Agile model, представляет итеративный подход, позволяет вносить изменения на каждом этапе проекта, м.б. не ограничена во времени.

Agile model имеет множество вариаций и фреймворков, среди которых выделяют: Scrum, Kanban, Экстремальное программирование (XP), Lean.
----------

Подробнее о применении основных моделей разработки ПО расскажем в следующих постах

​​Waterfall / Каскадная модель: особенности, преимущества и недостатки применения.
#waterfall #каскадная #модель

Waterfall — это работа по заранее написанному и согласованному ТЗ, заключающаяся в последовательном прохождении всех этапов разработки ПО.

Особенности приминения Waterfall:
° все этапы создания ПО идут в строгой последовательности друг за другом;
° переход на следующий этап осуществляется только после завершения предыдущего;
° после завершения этапа возвращаться к нему нельзя;
° все требования, задачи, планы фиксируются в документах;
° требования к проекту после утверждения не меняются;
° Заказчик не участвует в создании продукта после постановки ТЗ.

Основные этапы(стадии) разработки:
° Анализ
° Проектирование
° Разработка
° Тестирование
° Эксплуатация и поддержка

Преимущества и недостатки модели:
+ все процессы зарегламентированы и описаны;
+ сроки и бюджет зафиксированы;
+ требования не меняются во время работ;
+ прозрачность процессов для заказчика;
+ ход выполнения проекта легко проследить с помощью использования временной шкалы (или диаграммы Ганта);
+ участники знают свои задачи и в какой последовательности их выполнять;

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

Модель Waterfall стоит применять в проектах, где:
° требования к программному продукту четко определены и не должны меняться;
° осуществляется перенос уже существующего продукта на новую платформу;
° вовлечение заказчика в процесс разработки не требуется;
° первостепенна реализация сложных алгоритмов, а роль и объем пользовательского интерфейса невелик;
° по созданию и выпуску новой версии уже существующего продукта, если вносимые изменения вполне определены и управляемы.

Заметки Аналитика | @notes_analyst

#собеседование #вопросы #статья

Автор статьи "Как подготовиться к собеседованию на позицию системного аналитика. ТОП-5 тем", опираясь на личный опыт, выделяет 5 основных тем с примерными вопросами, которым стоит уделить внимание при подготовке к собеседованию:
1. Требования к ПО
2. Процесс разработки ПО
3. Документация к системе
4. Проектирование решения
5. Интеграция

И приводит ссылки на ресурсы для изучения данных тем.

Заметки Аналитика | @notes_analyst

​​Agile-подходы гибкой разработки ПО: Scrum и Kanban.
#agile #scrum #kanban 

Суть  Agile описана в Agile-манифесте, в котором на первое место выходят:  взаимодействие, работающий продукт, сотрудничество с заказчиком и готовность к изменениям.
Подробнее:"Ценности и принципы Agile-манифеста"

К отдельным Аgile-подходам (методологиям) относятся Scrum и Kanban. 
Данные подходы гибкой разработки ориентированы на итеративный и инкрементальный процесс программирования, в котором:
 ° разработка ПО разбивается на короткие циклы - итерации (в Scrum - спринты);
 ° формируется автономная и самоорганизующаяся команда;
 ° клиенты или представляющий их владелец продукта участвуют на всех стадиях проекта;
 ° требования могут документироваться менее подробно, чем в традиционных проектах;
 ° формируется Резерв  (backlog) проекта, содержащий список задач, которые должна выполнить команда;
 °  каждая задача должна быть актуальна (разрешается добавлять/удалять задачи), иметь вес (время, которое необходимо на её реализацию) и приоритет (может пересматриваться в ходе работы);
 ° для визуализации  данных подходов используют доски: физические или электронные, которые позволяют сделать рабочий процесс открытым и понятным для всех специалистов.

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

Особенности и принципы Kanban:
 ° над задачей может работать несколько узкопрофильных команд (дизайнеры, аналитики, разработчики…);
 ° внутри команды нет выделенных ролей;
 ° проект делят на итерации, длина которых может различаться;
 ° рабочие задачи располагаются на доске, поделенной на колонки, каждая из которых отражает текущее состояние работ (стадии) - например: «Планируется», «Разрабатывается», «Тестируется», «Завершено»; 
° каждая задача представляется в виде отдельной карточки;
° основная цель - закончить задачу, т.е. пройти все стадии выполнения (когда задача завершает определённый этап, карточку с её описанием переносят в соответствующую колонку);
° над задачей трудятся столько времени, сколько это необходимо до её завершения или утраты актуальности и отмены;
° главный показатель эффективности -
среднее время прохождения задачи по доске;
° приоритеты задач расставляет команда;
° добавление новых задач - в любое время;
° проводить ежедневные встречи не обязательно.

---------
Подробнее о принципах работы по Scrum  и Kanban можно прочитать в статьях:
° Scrum
° Kanban: принципы и возможности в управлении проектами
° Разбираемся в Scrum и Kanban

Заметки Аналитика | @notes_analyst

​​"Разработка требований к программному обеспечению". Карл Вигерс и Джой Битти
#литература

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

Найти электронную версию можно тут (2014г.)

Обзоры на книгу:
° Рецензия на книгу «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти

° Стоит прочитать: обзор книги Карла Вигерса «Разработка требований к программному обеспечению»


Заметки Аналитика | @notes_analyst

​​Варианты использования (Use Case).  Элементы структуры и примеры составления.
#usecase #работастребованиями #теория

Вариант использования/Use Case - описывает последовательность взаимодействия системы и внешнего действующего лица, в результате которого действующее лицо получает полезный результат.

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

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

Единого формата (шаблона) составления Вариантов использования не существует. Чаще их представляют в текстовой форме, дополняя диаграммами/схемами.

Основными элементами структуры Варианта использования являются:

🔹️Имя - пишется в формате «глагол + объект», отражает цель и смысл сценария ( Зарегистрироваться на рейс, Снять деньги в банкомате).

🔹️Цель - короткое описание того, чего  намеревается достигнуть действующее лицо с этим сценарием

🔹️Актор (actor) - действующее лицо (человек/другая программная система/аппаратное устройство), взаимодействующее с системой для реализации Варианта использования.

🔹️Предусловия  - условия, которые должны быть удовлетворены до начала выполнения Варианта использования.

🔹️Активатор (триггер) – внешнее, внутреннее или временное событие, инициирующее выполнение Варианта использования.

🔹️Выходные условия (результат, постусловие) - описывают состояние системы после успешного выполнения Варианта использования. 

🔹️Порядок Событий (основной поток/сценарий) — пронумерованный список действий, иллюстрирующий последовательность этапов взаимодействия действующего лица и системы (диалогов) от предварительных до выходных условий.

🔹️Альтернативные пути (альтернативный поток/вторичный сценарий) - описание действий , которые тоже приводят к успешному результату  и удовлетворяют выходным условиям Варианта использования, но представляют менее популярные или менее приоритетные вариации самой задачи или способа ее выполнения. 

🔹️Исключения - условия, препятствующие успешному выполнению Варианта использования. Описывают ожидаемое ошибочное условие, которое может сложиться во время выполнения варианта использования, и как его обрабатывать.

🔹️Бизнес-правила - которые, наприпер, могут влиять на отдельные шаги нормального направления, задавая разрешенные входные значения или диктуя, какие вычисления должны выполняться.

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

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

------
Заметки Аналитика | @notes_analyst

​​Как подготовиться к собеседованию бизнес-/системному аналитику.
#подборка #собеседование

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

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

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

🔹 50 лучших вопросов из интервью для бизнес-аналитиков

🔹 Прохождение собеседования на позицию бизнес-аналитика

🔹 Как пройти техническое собеседование на системного аналитика в любой компании (сборник вопросов)

🔹 Как подготовиться к собеседованию на позицию системного аналитика. ТОП-5 тем

🔹 Что мы хотим от аналитика

🔹 Типовые вопросы на собеседовании на аналитика и ответы на них

🔹 «Кем вы видите себя через 5 лет»...

🔹 Бизнес-аналитик идет на собеседование

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

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

Следите за новыми постами на каналах @analysis_it и @notes_analyst, где сможете найти ответы на многие вопросы из представленных статей ⬆️

Давайте готовиться к собеседованиям вместе!

Project-менеджер в IT - один из немногих каналов для начинающих проджектов в телеграм. Если вы хотите развиваться в сторону менеджмента в IT — подписывайтесь!

​​Диаграммы прецедентов (вариантов использования).
#usecase #диаграмма #теория

Диаграммы вариантов использования (use-case diagrams) позволяют получить высокоуровневое визуальное представление о требованиях пользователей.
Их чаще применяют в качестве дополнения к более описательным текстовым Вариантам использования.

При помощи use-case диаграммы можно:
▪︎ продемонстрировать различные способы взаимодействия пользователя с системой;
▪︎ визуально представить логическое развитие сложного варианта использования;
▪︎ описать общую функциональность системы;
▪︎ определить общие границы и контекст моделируемой предметной области;   
 ▪︎ разработать исходную концептуальную модель системы;
 ▪︎ подготовить исходную документацию. 

Основными элементами use-case диаграммы являются:
 🔹 Актеры (акторы) - группы лиц или систем, взаимодействующие с описываемой системой;
🔹 Варианты использования (прецеденты) - функции, которые система предоставляет актерам;
🔹 Комментарии;
🔹 Отношения между элементами диаграммы - отношения ассоциации, обобщения, включения, расширения.

Графические обозначения и определения данных элементов привела в таблице Основные элементы Use-case диаграммы

Строить диаграмму прецедентов можно в следующей последовательности:
1.Выделите группы действующих лиц
2. Определите функциональность для каждой из групп (варианты использования/прецеденты)
3. Дополните прецеденты словесным описанием (сценарием) - для каждого прецедента создайте разделы: "основной поток" и " "альтернативный"
4. Проведите анализ связей (отношений)
5. Перенесети собранные данные в графический формат - постройте use-case диаграмму.

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

Ещё больше рекомендаций и примеров построения use-case диаграмм можете найти в статьях:
 ° Правила и рекомендации по разработке диаграмм прецедентов
 
° Использование диаграммы вариантов использования UML при проектировании программного обеспечения

Заметки Аналитика | @notes_analyst

​​Алистер Коберн. Современные методы описания функциональных требований к системам.
#работастребованиями #литература

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

"Данная книга эксперта по объектной технологии Алистера Коберна служит новейшим практическим руководством по написанию вариантов использования. Богатый опыт в этой области помогает автору расширить классическое толкование вариантов использования. В книге представлены начальная, промежуточная и развитая концепции, поэтому она подходит читателям с разным уровнем подготовки. Инструкции подкреплены наглядными примерами и упражнениями."

Электронную версию можно найти тут