1. Направления в IT-сфере
1.1. Проект-менеджмент
1.1.1. Project Manager (работает на стороне продукта, определяет что нужно сделать) Ориентирован на продукт и его соответствие потребностям пользователей и бизнес-целям.
1.1.1.1. Зоны ответственности
1.1.1.1.1. Работа непосредственно над проектом
1.1.1.1.2. Общение с клиентом
1.1.1.1.3. Соблюдение интересов компании
1.1.1.1.4. Коммуникация с коллективом
1.1.1.1.5. Ведение документации
1.1.1.2. Взаимодействие PM на проекте
1.1.2. Delivery Manager (на стороне разработки, как это сделать) Ориентирован на доставку продукта в срок и в рамках бюджета
1.1.3. Director of Development (на стратегическом уровне, каким образом это будет делаться в компании в целом) Ориентирован на стратегию и процессы доставки продуктов в компании.
1.2. Обеспечение качества
1.2.1. Основные задачи QA-инженера
1.2.1.1. Планирование
1.2.1.2. Разработка тестовых сценариев
1.2.1.3. Выполнение тестов
1.2.1.4. Документирование багов
1.2.1.5. Составление отчетов
1.2.2. Основные артефакты
1.2.2.1. План тестирования (Test Plan)
1.2.2.2. Набор тест кейсов и тестов (Test Case & Test suite)
1.2.2.3. Дефекты / Баг Репорты (Bug Reports / Defects)
1.2.2.4. Тестовые отчеты (QA Reports)
1.2.2.5. Тестовые сценарии (Test Scenarios)
1.2.2.6. user stories
1.2.2.7. Отчет о тестировании (Test Report)
1.2.2.8. Тестовые метрики (Test Metrics)
1.2.2.9. Матрица соответствия требований (МСТ)
1.2.3. Классификации и виды тестирования
1.2.3.1. По уровню тестирования
1.2.3.1.1. Модульное тестирование: тестирование отдельных модулей или компонентов ПО.
1.2.3.1.2. Интеграционное тестирование: тестирование взаимодействия между модулями ПО.
1.2.3.1.3. Системное тестирование: тестирование ПО как единой системы.
1.2.3.1.4. Приемочное тестирование: тестирование ПО перед его выпуском в эксплуатацию.
1.2.3.2. По цели тестирования
1.2.3.2.1. Функциональное тестирование: проверка соответствия функций ПО требованиям и спецификациям.
1.2.3.2.2. Нефункциональное тестирование: проверка нефункциональных характеристик ПО, таких как производительность, безопасность, надежность, юзабилити и т.д.
1.2.3.2.3. Узнающее тестирование: исследование ПО для обнаружения неизвестных проблем или рисков.
1.2.3.3. По методу тестирования
1.2.3.3.1. Ручное тестирование: тестирование, выполняемое вручную человеком.
1.2.3.3.2. Автоматизированное тестирование: тестирование, выполняемое с помощью специальных программных инструментов.
1.2.3.4. По позитивности сценария
1.2.3.4.1. Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
1.2.3.4.2. Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
1.2.3.5. По знанию системы
1.2.3.5.1. Белый ящик (White-box testing). Тестирование, основанное на анализе внутренней структуры компонента или системы. Тестировщику полностью доступен исходный код.
1.2.3.5.2. Чёрный ящик (Black-box testing). Тестирование — функциональное или нефункциональное — без знания внутренней структуры компонента или системы.
1.2.3.5.3. Серый ящик. У специалистов есть доступ к базам данных или фрагментам кода.
1.2.3.6. По исполнителям тестирования
1.2.3.6.1. Альфа-тестирование
1.2.3.6.2. Бета-тестирование
1.2.4. Дефект
1.2.4.1. Error (ошибка) - это неправильное выполнение программы или системы, приводящее к непредвиденному результату.
1.2.4.2. Bug (Defect) (баг, дефект) - это программная ошибка, которая приводит к неправильному поведению программы.
1.2.4.2.1. Деление
1.2.4.3. Failure (сбой) - это отказ программы или системы выполнить свою функцию.
1.2.4.4. Примеры
1.3. UX/UI
1.3.1. User Interface (пользовательский интерфейс) способ взаимодействия (как выглядит)
1.3.2. User Experience (пользовательский опыт) достигает ли цели
1.3.3. UX/UI-дизайнер
1.3.4. Принципы эргономичного пользовательского интерфейса по Якобу Нильсену
1.3.4.1. Видимость статуса системы
1.3.4.2. Соответствие между системой и реальным миром
1.3.4.3. Контроль и свобода действий
1.3.4.4. Последовательность и стандарты
1.3.4.5. Предотвращение ошибок
1.3.4.6. Узнаваемость, а не воспоминание
1.3.4.7. Эффективность использования
1.3.4.8. Эстетика и минимализм
1.3.4.9. Помощь и подсказки
1.3.4.10. Равенство возможностей
1.3.5. Дизайн-система
1.3.5.1. Уровни
1.3.5.1.1. UI-кит
1.3.5.1.2. Фреймворк
1.3.5.1.3. Гайдлайны
1.4. DevOps
1.4.1. Инструменты для автоматизации процессов в разработке ПО
1.4.1.1. Jenkins
1.4.1.1.1. Jenkins: Широко используемая, гибкая и настраиваемая платформа с множеством плагинов для автоматизации процессов CI/CD.
1.4.1.2. TFS
1.4.1.2.1. TFS/Azure DevOps Server: Полный набор инструментов для управления жизненным циклом разработки от Microsoft, интегрированный с другими продуктами компании.
1.4.1.3. TeamCity
1.4.1.3.1. TeamCity: Мощная и удобная система CI/CD с поддержкой различных инструментов и технологий, известная своей интеграцией с продуктами JetBrains.
1.4.1.4. Распределенный контроль версий (Git, Mercurial, Subversion, CVS);
1.4.1.5. Контейнеризация (Docker, Rocket, Kubernetes);
1.4.1.6. Непрерывная интеграция – сборка и тестирование конечного продукта (Jenkins, TeamCity, Bamboo);
1.4.1.7. Управление инфраструктурой как кодом (Puppet, Chef, Ansible);
1.4.1.8. Виртуализация (Vagrant);
1.4.1.9. Балансировка облачных ресурсов (VMware DRS).
1.4.2. Задачи
1.4.2.1. Автоматизация процесса интеграции и развертывания (CI/CD): Внедрение систем непрерывной интеграции и доставки (Continuous Integration/Continuous Delivery), что позволяет автоматически собирать, тестировать и развертывать программное обеспечение.
1.4.2.2. Инфраструктура как код (IaC): Использование кода для управления и конфигурирования инфраструктуры, что обеспечивает её более быстрое и надежное развертывание.
1.4.2.3. Мониторинг и логирование: Внедрение систем мониторинга и логирования, которые позволяют оперативно отслеживать состояние приложений и инфраструктуры, быстро выявлять и устранять проблемы.
1.4.2.4. Обеспечение безопасности: Внедрение практик DevSecOps, которые включают безопасность на всех этапах жизненного цикла разработки ПО.
1.4.2.5. Обратная связь и мониторинг: Постоянное получение обратной связи от пользователей и использование данных мониторинга для улучшения процесса разработки и эксплуатации.
1.4.2.6. Культура непрерывного обучения: Обучение сотрудников новым инструментам и методологиям, а также поощрение обмена знаниями и опытом внутри команды.
1.4.3. Gitflow
1.4.3.1. Основные ветки
1.4.3.1.1. main (или master): Основная ветка, содержащая стабильный и готовый к выпуску код.
1.4.3.1.2. develop: Основная ветка для разработки, где происходит интеграция всех новых функций.
1.4.3.2. Вспомогательные ветки
1.4.3.2.1. Feature branches: Ветки для работы над отдельными функциями. Создаются от ветки develop и сливаются обратно в нее после завершения работы над функцией.
1.4.3.2.2. Release branches: Ветки для подготовки к выпуску новой версии. Создаются от develop, проходят финальное тестирование и исправление ошибок, после чего сливаются в main и develop.
1.4.3.2.3. Hotfix branches: Ветки для срочного исправления ошибок в продакшн-версии. Создаются от main и сливаются обратно в main и develop.
1.4.3.3. Преимущества
1.4.3.3.1. Структурированное управление разработкой.
1.4.3.3.2. Четкое разделение стабильного и разрабатываемого кода.
1.4.3.3.3. Удобство в работе с релизами и исправлениями.
1.4.4. Работа с контейнеризацией (Docker и Kubernetes)
1.4.4.1. Взаимосвязь и совместное использование
1.4.4.1.1. Docker используется для создания и управления контейнерами, предоставляя единый стандарт для упаковки приложений и их зависимостей.
1.4.4.1.2. Kubernetes используется для управления множеством контейнеров в распределенной системе, обеспечивая их координацию, масштабирование и надежность.
1.4.4.2. Docker
1.4.4.2.1. Использование
1.4.4.3. Kubernetes
1.4.4.3.1. Использование
1.4.5. несколько основных целей
1.4.6. Главные принципы DevOps
1.4.6.1. Культура
1.4.6.2. Автоматизация
1.4.6.3. Бережливость
1.4.6.4. Измерения
1.4.6.5. Обмен
1.5. Бизнес-аналитика (Business Intelligence)
1.5.1. Data Mining
1.5.1.1. Основные задачи и техники Data Mining:
1.5.1.1.1. Классификация:
1.5.1.1.2. Кластеризация:
1.5.1.1.3. Ассоциативные правила:
1.5.1.1.4. Регрессия:
1.5.1.1.5. Аномалия (выбросы):
1.5.1.2. Основные этапы Data Mining:
1.5.1.2.1. Определение целей:
1.5.1.2.2. Сбор данных:
1.5.1.2.3. Подготовка данных:
1.5.1.2.4. Выбор методов и алгоритмов:
1.5.1.2.5. Анализ данных и моделирование:
1.5.1.2.6. Оценка и интерпретация результатов:
1.5.1.2.7. Внедрение и мониторинг:
1.5.2. Основные компоненты
1.5.2.1. Источники данных: Включают базы данных, CRM, ERP, файлы, веб-данные и другие системы, откуда собираются данные. Примеры: базы данных (SQL Server, Oracle, MySQL), файлы (Excel, CSV), облачные сервисы (Google Analytics, Salesforce), API, ERP-системы (SAP, Microsoft Dynamics).
1.5.2.2. Инструменты для интеграции данных (ETL): ETL-процессы (Extract, Transform, Load): Используются для извлечения данных из различных источников, их преобразования в подходящий формат и загрузки в хранилище данных. Примеры инструментов: Talend, Apache Nifi, Informatica, Microsoft SSIS (SQL Server Integration Services).
1.5.2.3. Хранилище данных (Data Warehouse): Централизованное хранилище, где данные организуются и хранятся для дальнейшего анализа. Примеры: Data Warehouse (Amazon Redshift, Google BigQuery, Snowflake), Data Mart.
1.5.2.4. Инструменты для анализа данных: OLAP (Online Analytical Processing): Для многомерного анализа данных. Data Mining: Для выявления скрытых закономерностей и инсайтов. Машинное обучение: Для прогнозирования и продвинутого анализа. Примеры: SQL, Python, R, Apache Spark.
1.5.2.5. Инструменты для визуализации данных: Дашборды, отчеты, графики и диаграммы для представления данных в удобном для восприятия формате.
1.5.2.6. Инструменты для отчетности: Автоматизация создания и распространения отчетов среди пользователей.
1.5.2.7. Средства управления и администрирования: Для настройки, управления безопасностью, контролем доступа и мониторинга производительности системы.
1.5.3. Процесс преобразования сырых данных в готовые дашборды
1.5.3.1. Сбор данных Описание: Этот этап включает сбор данных из различных источников, таких как базы данных, файлы, API, сенсоры и другие источники. Примеры: Базы данных: SQL Server, MySQL, Oracle. Файлы: CSV, Excel. API: RESTful API, SOAP. Облачные сервисы: Google Analytics, Salesforce.
1.5.3.2. Интеграция данных (ETL) Описание: ETL (Extract, Transform, Load) - это процесс извлечения данных из различных источников, их трансформации и загрузки в хранилище данных. Этапы: Извлечение (Extract): Извлечение данных из различных источников. Трансформация (Transform): Очистка, фильтрация, агрегирование и преобразование данных в нужный формат. Загрузка (Load): Загрузка обработанных данных в хранилище данных. Примеры инструментов: Talend, Apache Nifi, Informatica, Microsoft SSIS (SQL Server Integration Services).
1.5.3.3. Хранилище данных (Data Warehouse) Описание: Централизованное хранилище, где данные структурируются и хранятся для дальнейшего анализа. Примеры: Amazon Redshift, Google BigQuery, Snowflake.
1.5.3.4. Очистка и подготовка данных Описание: Данные очищаются от ошибок, дубликатов и пропусков. Проводится нормализация и стандартизация данных. Примеры инструментов: Trifacta, OpenRefine, Alteryx.
1.5.3.5. Анализ данных Описание: Выполнение сложных запросов и анализа данных для выявления закономерностей, трендов и инсайтов. Примеры инструментов: SQL, Python (pandas, numpy), R.
1.5.3.6. Построение моделей и алгоритмов Описание: Использование статистических методов и машинного обучения для создания предсказательных моделей и алгоритмов анализа данных. Примеры инструментов: Scikit-learn, TensorFlow, PyTorch.
1.5.3.7. Визуализация данных Описание: Создание визуальных представлений данных (графики, диаграммы, дашборды) для облегчения восприятия и анализа. Примеры инструментов: Tableau, Power BI, Qlik Sense, Looker.
1.5.3.8. Создание дашбордов Описание: Интеграция различных визуализаций и метрик в единые дашборды для предоставления пользователям полной картины состояния бизнеса. Примеры инструментов: Tableau, Power BI, Qlik Sense.
1.5.3.9. Распространение и доступ Описание: Предоставление доступа к дашбордам и отчетам конечным пользователям через веб-порталы, мобильные приложения или электронную почту. Примеры: Web-порталы, мобильные приложения, автоматизированные рассылки отчетов.
1.5.3.10. Обратная связь и улучшения Описание: Сбор обратной связи от пользователей и внесение улучшений в данные, отчеты и дашборды для повышения их полезности и точности. Примеры: Регулярные опросы пользователей, анализ метрик использования.
1.5.4. Примерный сценарий
1.6. Направления в разработке(Development Domains)
1.6.1. Искусственный интеллект (AI)
1.6.2. Машинное обучение (Machine Learning)
1.6.3. Big Data
1.6.4. IoT
1.6.5. Blockchain
1.6.6. Виртуальная реальность (VR)
1.6.7. Дополненная реальность (AR)
1.6.8. Бизнес-домены
1.6.8.1. Финансовые услуги: Банки, страховые компании, инвестиционные фирмы.
1.6.8.2. Розничная торговля: Магазины, e-commerce, логистика.
1.6.8.3. Производство: Автомобили, электроника, тяжелая промышленность.
1.6.8.4. Здравоохранение: Больницы, клиники, фармацевтические компании.
1.6.8.5. Образование: Школы, университеты, онлайн-обучение.
1.6.8.6. Телекоммуникации: Мобильные и интернет-операторы.
1.6.8.7. Гостиничный бизнес и туризм: Отели, авиакомпании, туристические агентства.
1.6.8.8. Энергетика: Нефть и газ, возобновляемые источники энергии.
1.6.8.9. Государственный сектор: Правительственные учреждения, общественные службы.
1.6.8.10. Медиа и развлечения: Телевидение, кино, музыкальные сервисы.
1.6.8.11. Агропромышленность: Сельское хозяйство, пищевая промышленность.
1.6.8.12. Некоммерческие организации: Благотворительные организации, общественные фонды.
1.7. Модели конрактов(Contract Models)
1.7.1. Fixed Price
1.7.1.1. Малые и средние проекты, четкие требования
1.7.2. Time&Materials
1.7.2.1. Сложные и долгосрочные проекты
1.7.3. Dedicated team(Выделенная команда)
1.7.3.1. Долгосрочные проекты, постоянные изменения
2. Agile
2.1. SCRUM
2.1.1. Основные элементы Scrum
2.1.1.1. Артефакты Scrum
2.1.1.1.1. Product Backlog (Бэклог продукта)
2.1.1.1.2. Sprint Backlog (Бэклог спринта)
2.1.1.1.3. Increment (Инкремент)
2.1.1.2. Церемонии Scrum
2.1.1.2.1. Sprint Planning (Планирование спринта)
2.1.1.2.2. Daily Scrum (Ежедневный скрам, или Стэнд-ап митинг)
2.1.1.2.3. Sprint Review (Обзор спринта)
2.1.1.2.4. Sprint Retrospective (Ретроспектива спринта)
2.1.1.3. Участники Scrum
2.1.1.3.1. Product Owner (Владелец продукта)
2.1.1.3.2. Scrum Master
2.1.1.3.3. Development Team (Команда разработчиков)
2.1.2. Когда применяется Scrum
2.2. Kanban
2.2.1. Основные элементы Kanban
2.2.1.1. Артефакты Kanban
2.2.1.1.1. Kanban-доска
2.2.1.1.2. Карточки (Kanban Cards)
2.2.1.1.3. Лимиты незавершённой работы (WIP Limits)
2.2.1.2. Церемонии Kanban (не строгие в отличие от Scrum)
2.2.1.2.1. Ежедневные встречи (Daily Standup)
2.2.1.2.2. Ретроспективы (Retrospective)
2.2.1.2.3. Ревью работы (Replenishment Meeting/Planning)
2.2.1.3. Участники Kanban
2.2.1.3.1. Команда (Team Members)
2.2.1.3.2. Менеджер/Лидер команды (Team Lead/Manager)
2.2.1.3.3. Владельцы процессов (Process Owners)
2.2.2. Когда применяется Kanban
2.3. LESS, SAFE
2.3.1. LeSS (Large Scale Scrum)
2.3.1.1. Принципы
2.3.1.2. Когда использовать
2.3.2. SAFe (Scaled Agile Framework)
2.3.2.1. Принципы
2.3.2.2. Когда использовать
2.4. MoSCoW
2.4.1. Must – то, что необходимо сделать в любом случае. Без выполнения этих задач продукт не будет работать в принципе.
2.4.2. Should – не самые важные требования, но они тоже должны быть выполнены. Естественно, после реализации «must».
2.4.3. Could – желательные требования, которые можно сделать, если останется время и будут ресурсы.
2.4.4. Would – требования, которые хотелось бы сделать, но их можно проигнорировать или перенести на следующие релизы без вреда для продукта.
3. Моделирование и прототипирование
3.1. BPMN (нотация и модель бизнес-процессов)
3.1.1. Объекты потока
3.1.1.1. События( круги)
3.1.1.1.1. Типы По функции
3.1.1.1.2. Типы
3.1.1.1.3. Виды
3.1.1.2. Действия (прямоугольники с закругленными углами)
3.1.1.2.1. Задачи
3.1.1.2.2. Подпроцессы
3.1.1.2.3. Активность вызова
3.1.1.2.4. Специальные
3.1.1.2.5. События
3.1.1.3. Шлюзы(ромбы)
3.1.1.3.1. Эксклюзивный (XOR) ✖️
3.1.1.3.2. Параллельный (AND) ➕
3.1.1.3.3. Включительный/неЭксклюзивный (OR) (О)
3.1.1.3.4. Событие
3.1.1.3.5. Комплексный шлюз
3.1.2. Связи потока/соединяющие элементы
3.1.2.1. Поток последовательности(сплошная линия со стрелкой на конце)
3.1.2.2. Поток сообщения(пунктирная линия со стрелкой на конце)
3.1.2.3. Ассоциация(пунктирная линия с одним или двумя ромбами на концах)
3.1.2.4. Поток данных(двойная сплошная линия со стрелкой на конце.)
3.1.3. Артефакты
3.1.3.1. Данные(прямоугольник с закругленными углами и двумя параллельными линиями внутри)
3.1.3.2. Документ(папка с загнутым уголком)
3.1.3.3. Текстовая аннотация(текстовый блок с закругленными углами)
3.1.3.4. Ссылка на артефакт(стрелка, указывающая на другой артефакт)
3.1.3.5. Группа(прямоугольник с пунктирной линией и заголовком.)
3.1.3.6. Хранилище данных(цилиндр с закругленными углами и двумя параллельными линиями внутри)
3.1.3.7. Интерфейс человека(фигура человека с закругленными углами)
3.1.4. Зоны ответственности
3.1.4.1. Пулы
3.1.4.1.1. Свёрнутый пул
3.1.4.2. Дорожки
3.2. UML (унифицированный язык моделирования)
3.2.1. Строительные блоки
3.2.1.1. Сущьности
3.2.1.1.1. ➢ Структурные
3.2.1.1.2. ➢ Поведенческие
3.2.1.1.3. ➢ Группирующие
3.2.1.1.4. ➢ Аннотирующие
3.2.1.2. Связи
3.2.1.3. Диаграммы
3.2.1.3.1. Структурные диаграммы
3.2.1.3.2. Поведенческие диаграммы
3.2.2. UML диаграммы СА
3.2.2.1. Use Case диаграмма Вариантов использования
3.2.2.1.1. Актор
3.2.2.1.2. Перецендент (вариант)
3.2.2.1.3. Связи
3.2.2.1.4. Граница
3.2.2.1.5. Кооперация
3.2.2.2. Sequence диаграмма Последовательности
3.2.2.2.1. ➢ Актор, класс, компонент
3.2.2.2.2. Бары активации (прямоуголькик на линии жизни)
3.2.2.2.3. ➢ Связи
3.2.2.2.4. ➢ Линия жизни (изображается пунктирной вертикальной линией, спецификация использования
3.2.2.3. Activity диаграмма Активностей
3.2.2.3.1. ➢ Деятельность (изображается фигурой, напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами)
3.2.2.3.2. ➢ Поток управления (сплошной линией со стрелкой)
3.2.2.3.3. ➢ Ветвление (обозначается небольшим ромбом, внутри которого нет никакого текста)
3.2.2.3.4. Параллельные потоки управления (горизонтальные закрашенные прямоугольники)
3.2.2.3.5. ➢ Дорожки
3.2.2.3.6. Начальный узел (круг закрашен и сплошная стрелка)
3.2.2.3.7. Конец (в окружности закрашен круг поменьше)
3.2.2.3.8. Представление объектов
3.2.2.4. Классов Class
3.2.2.4.1. Класс
3.2.2.4.2. Отношение
3.2.2.5. Состояний State Machine
3.2.2.5.1. Состояние (прямоугольником со скругленными вершинами)
3.2.2.5.2. Переходы (дуги, сплошной линией со стрелкой, которая направлена в целевое состояние)
3.2.2.5.3. Автомат(это и есть диаграмма состояний)
3.2.3. Задачи
3.2.3.1. ➢ Визуализировать систему в ее текущем или желательном для нас состоянии;
3.2.3.2. ➢ Описать структуру или поведение системы;
3.2.3.3. ➢ Получить шаблон, позволяющий сконструировать систему;
3.2.3.4. ➢ Документировать принимаемые решения, используя полученные модели
3.3. Прототипирование
3.3.1. Виды прототипов
3.3.1.1. ❏ Скетч
3.3.1.2. ❏ Бумажные прототипы
3.3.1.3. ❏ Вайрфрейм
3.3.1.4. ❏ Прототип
3.3.1.5. ❏ Мокап
3.3.1.6. ❏ Карты диалоговых окон
3.3.2. Основные принципы
3.3.2.1. ❏ Единообразие внешнего вида и поведения
3.3.2.2. ❏ Выравнивание по сетке
3.3.2.3. ❏ Управление формами и цветами
3.3.2.4. ❏ Группировка по функциям
3.3.2.5. ❏ Много белого пространства
3.3.3. ПО/ инструменты
3.3.3.1. Бумага, карандаш для набросков
3.3.3.2. Figma
3.3.3.3. Sketch
3.3.3.4. Adobe XD
3.3.4. Структура описания
4. Техническая часть
4.1. ООП
4.1.1. Принципы
4.1.1.1. Инкапсуляция
4.1.1.2. Наследование
4.1.1.3. Полиморфизм
4.1.1.4. Абстракция
4.1.2. Разница между функциональной моделью программирования и объектно-ориентированной
4.1.2.1. Функциональная модель программирования (ФМП)
4.2. Интаграция
4.2.1. Веб-сервисы / API
4.2.1.1. Способы оптимизации работы высоконагруженных систем и веб-приложений
4.2.1.1.1. Масштабирование
4.2.1.1.2. Кэширование
4.2.1.1.3. Оптимизация базы данных
4.2.1.1.4. Балансировка нагрузки
4.2.1.1.5. Оптимизация кода и архитектуры
4.2.1.1.6. Мониторинг и анализ производительности
4.2.1.1.7. Оптимизация сетевых запросов
4.2.1.2. Веб-сервисы
4.2.1.3. API
4.2.2. Протоколы
4.2.2.1. Распространенные протоколы
4.2.2.1.1. TCP/IP используется для передачи данных по интернету.
4.2.2.1.2. HTTP – для доступа к веб-страницам.
4.2.2.1.3. FTP – для передачи файлов.
4.2.2.1.4. SMTP – для отправки электронной почты.
4.2.2.1.5. DNS – для разрешения доменных имён в IP-адреса.
4.2.2.2. SOAP (протокол)
4.2.2.2.1. Основные характеристики
4.2.2.2.2. Основные компоненты
4.2.2.2.3. Плюсы и минусы
4.2.2.3. REST (архитектурный стиль)
4.2.2.3.1. Основные принципы REST
4.2.2.3.2. HTTP/HTTPS
4.2.2.3.3. Плюсы и минусы
4.2.2.4. Уровни протоколов передачи данных
4.2.2.4.1. Модель OSI (7 уровней)
4.2.2.4.2. Модель TCP/IP (4 уровня)
4.2.2.5. Еще протоколы (помимо ПД)
4.2.3. Сервисная шина данных (EBS)
4.2.3.1. Из чего состоит (основное)
4.2.3.1.1. Брокера сообщений
4.2.3.1.2. Инструментов мониторинга и контроля
4.2.3.1.3. Комплекта адаптеров
4.2.3.2. ДОполнительно из чего состоит
4.2.3.3. Как работает ESB
4.2.3.3.1. Подключение систем через адаптеры: Приложения и системы подключаются к ESB через соответствующие адаптеры, поддерживающие их протоколы и форматы данных.
4.2.3.3.2. Отправка сообщений в брокер: Сообщения отправляются от отправителя в брокер сообщений ESB.
4.2.3.3.3. Маршрутизация и трансформация: Брокер маршрутизирует сообщения к нужным сервисам, при необходимости выполняет трансформацию данных.
4.2.3.3.4. Обработка и взаимодействие: Сообщения передаются к целевым системам или приложениям, где обрабатываются в соответствии с логикой бизнес-процессов.
4.2.3.3.5. Мониторинг и управление: Весь процесс отслеживается и контролируется с помощью инструментов мониторинга, обеспечивая надежность и эффективность интеграции.
4.2.3.4. Пример работы ESB
4.2.4. Брокеры сообщений
4.2.4.1. Примеры брокеров
4.2.4.1.1. Apache Kafka
4.2.4.1.2. Rabbit MQ
4.2.4.1.3. Разница между RabbitMQ и Apache Kafka
4.2.4.1.4. ActiveMQ
4.2.4.1.5. Amazon SQS (Simple Queue Service)
4.2.4.2. Как работают брокеры сообщений?
4.2.4.3. Компоненты БС
4.2.4.4. Чем брокеры сообщений отличаются от EBS (Enterprise Service Bus)?
4.2.5. Удаленный вызов процедур (RPC)
4.2.5.1. Основные компоненты RPC
4.2.5.2. Как работает RPC
4.2.5.3. Примеры реализации RPC
4.2.5.4. Плюсы и минусы
4.3. Архитектура
4.3.1. Типы
4.3.1.1. Монолитная архитектура
4.3.1.1.1. Стили монолитной архитектуры
4.3.1.1.2. Плюсы и минусы
4.3.1.1.3. Когда использовать
4.3.1.1.4. Балансировщик нагрузки (Load Balancer)
4.3.1.2. Микросервисная архитектура
4.3.1.2.1. Плюсы и минусы
4.3.1.2.2. Когда использовать
4.3.1.2.3. Что важно
4.3.1.3. Сервис-ориентированная архитектура (SOA)
4.3.1.3.1. Основные принципы работы SOA
4.3.1.3.2. Когда применяется SOA
4.3.1.3.3. Плюсы и минусы
4.3.1.3.4. Отличие SOA от микросервисной архитектуры SOA (Service-Oriented Architecture):
4.3.1.4. Событийно-ориентированная архитектура (EDA)
4.3.1.4.1. Плюсы
4.3.1.4.2. Минусы
4.3.1.4.3. Когда применять
4.3.1.5. Бессервисная
4.3.1.5.1. Плюсы и минусы
4.3.1.5.2. Когда используется
4.4. БД
4.4.1. Виды баз данных по модели
4.4.1.1. Иерархическая (древовидная)
4.4.1.2. Сетевая (может быть несколько потомков и предков)
4.4.1.3. Реляционная (таблица)
4.4.1.3.1. Принципы реляционных баз данных
4.4.1.3.2. Типы данных, используемые в реляционных базах данных
4.4.1.3.3. Примеры реляционных баз данных
4.4.1.3.4. Виды связей между таблицами
4.4.1.3.5. Нормализация БД
4.4.1.3.6. Виды Constraints (Ограничений)
4.4.1.3.7. Термины
4.4.1.4. Нереляционная (NoSQL)
4.4.1.4.1. Ключ-значение модель
4.4.1.4.2. Документно-ориентированные базы данных (Document-oriented DBMS)
4.4.1.4.3. Колонко-ориентированные базы данных (Column-family Stores)
4.4.1.4.4. Графовые базы данных (Graph DBMS)
4.4.2. Основные компоненты базы данных
4.4.2.1. Данные
4.4.2.2. Схема (Schema)
4.4.2.3. Система управления базами данных (СУБД, DBMS)
4.4.2.3.1. Основные функции СУБД
4.4.2.4. Язык запросов (SQL)
4.4.3. DW(Data Warehouse) и Data Lake
4.4.3.1. DW(Data Warehouse)
4.4.3.2. Data Lake
4.4.3.3. Основные различия между DW и Data Lake
4.5. Алгоритмы/Структуры данных
4.5.1. Стуктуры данных
4.5.1.1. Виды структур данных
4.5.1.1.1. Линейные (элементы образуют последовательность или линейный список, обход узлов линеен)
4.5.1.1.2. Нелинейные (если обход узлов нелинейный, а данные не последовательны)
4.5.1.1.3. Хэш таблицы
4.5.1.2. Виды списков
4.5.2. Алгоритмы
4.5.2.1. Виды алгоритмов
4.5.2.1.1. По назначению
4.5.2.1.2. По методологии:
4.5.2.1.3. По типу ввода/вывода:
4.5.2.1.4. По способу реализации:
4.5.2.1.5. По сложности:
4.5.2.2. Другое деление на виды
4.6. Типы приложений
4.6.1. Системное ПО
4.6.1.1. Операционные системы (ОС)
4.6.1.2. Драйверы устройств
4.6.1.3. Утилиты
4.6.2. Прикладное ПО
4.6.2.1. Офисные приложения
4.6.2.2. Мультимедийное ПО
4.6.2.3. Игры
4.6.2.4. Интернет-браузеры
4.6.3. Встраиваемое ПО
4.6.3.1. Прошивки
4.6.4. Серверное ПО
4.6.4.1. Веб-серверы
4.6.4.2. Базы данных
4.6.5. Сетевое ПО
4.6.5.1. VPN-клиенты
4.6.5.2. Программное обеспечение для управления сетью
4.6.6. Программное обеспечение разработки
4.6.6.1. IDE (Интегрированные среды разработки)
4.6.6.2. Системы контроля версий
4.6.7. Нативные и кроссплатформенные приложения
4.6.7.1. Нативные
4.6.7.2. Кроссплатформенные приложения
4.6.7.3. Что выбрать?
4.6.7.4. Примеры толстого и тонкого клиента Все преимущества каждого вида ПО
4.6.7.4.1. Толстый клиент (Thick Client)
4.6.7.4.2. Тонкий клиент (Thin Client)
4.6.7.4.3. Что выбрать?
4.7. Операционные системы
4.7.1. Виды ОС
4.7.1.1. По типу устройства
4.7.1.1.1. Настольные ОС: Windows, macOS, Linux, Chrome OS.
4.7.1.1.2. Мобильные ОС: Android, iOS, Windows Phone.
4.7.1.1.3. Встроенные ОС: Используются в бытовой технике, роутерах, автомобилях и т.д. (QNX,VxWorks,FreeRTOS).
4.7.1.1.4. Серверные ОС: Windows Server, Linux, macOS Server.
4.7.1.1.5. Специализированные ОС: Для военных целей, промышленных систем, медицинского оборудования и т.д. (VxWorks, RTEMS, Integrity).
4.7.1.2. По типу ядра
4.7.1.2.1. Монолитное ядро: Все компоненты ОС находятся в одном адресном пространстве (Windows, macOS).
4.7.1.2.2. Микроядро: Только базовые компоненты ОС находятся в ядре, остальные службы выполняются как пользовательские приложения (Linux, QNX).
4.7.1.2.3. Гибридное ядро: Сочетает элементы монолитного и микроядра (FreeBSD).
4.7.1.3. По типу распространения
4.7.1.3.1. Проприетарные ОС: Разрабатываются коммерческими компаниями и не распространяются под свободной лицензией (Windows, macOS).
4.7.1.3.2. Свободные ОС: Распространяются под свободной лицензией, что позволяет пользователям изучать, изменять и распространять код ОС (Linux, FreeBSD).
4.7.1.4. Популярные примеры
4.7.2. Виды файловых систем
4.7.2.1. Файловые системы для Windows
4.7.2.1.1. FAT (File Allocation Table): FAT12, FAT16, FAT32. NTFS (New Technology File System): Основная файловая система Windows. exFAT (Extended File Allocation Table): Поддержка больших файлов, используется на съемных носителях.
4.7.2.2. Файловые системы для Linux
4.7.2.2.1. ext (Extended File System): ext2, ext3, ext4. XFS: Высокопроизводительная файловая система. Btrfs (B-tree File System): Современная файловая система с поддержкой снапшотов и самовосстановления. ReiserFS: Файловая система с хорошей производительностью при работе с небольшими файлами.
4.7.2.3. Файловые системы для macOS
4.7.2.3.1. HFS+ (Hierarchical File System Plus): Использовалась до появления APFS. APFS (Apple File System): Современная файловая система с улучшенной производительностью и безопасностью.
4.7.2.4. Сетевые файловые системы
4.7.2.4.1. NFS (Network File System): Для Unix/Linux. SMB/CIFS (Server Message Block/Common Internet File System): Для Windows.
4.7.3. Инструменты для запуска другой ОС
4.7.3.1. Виртуальные машины
4.7.3.2. Эмуляторы
4.7.4. Запуск Android-приложений на Windows
4.7.4.1. Эмуляторы Android
4.7.4.2. Android Studio: Официальная среда разработки для Android с встроенным эмулятором Android.
4.7.4.3. Windows Subsystem for Android (WSA): Функция, доступная в Windows 11, позволяющая запускать Android-приложения прямо на Windows.
4.8. Информационная безопасность
4.8.1. Шифрование данных
4.8.1.1. Ключ шифрования (тут пример)
4.8.1.1.1. Открытый
4.8.1.1.2. Закрытый
4.8.2. Состояния безопасности информации
4.8.2.1. Конфиденциальность: Обеспечение защиты информации от несанкционированного доступа и раскрытия.
4.8.2.2. Целостность: Гарантирование точности и неприкосновенности информации, предотвращение несанкционированных изменений данных.
4.8.2.3. Доступность: Обеспечение доступности информации для авторизованных пользователей в необходимое время и место.
4.8.3. Этапы доступа к ресурсу
4.8.3.1. Идентификация
4.8.3.2. Аутентификация
4.8.3.3. Авторизация
4.8.4. Файрвол
4.8.4.1. Принцип работы
4.8.4.1.1. Анализ пакетов: Файрвол анализирует сетевой трафик на основе заранее определенных правил и политик безопасности.
4.8.4.1.2. Принятие решений: На основе анализа трафика файрвол принимает решения о разрешении или блокировании передачи данных в зависимости от установленных правил.
4.8.4.1.3. Фильтрация трафика: Файрвол фильтрует трафик, блокируя нежелательные или подозрительные соединения и разрешая только доверенные.
4.8.4.2. Основные функции
4.8.4.2.1. Фильтрация пакетов: Анализ и фильтрация сетевого трафика на основе IP-адресов, портов и протоколов.
4.8.4.2.2. Межсетевое взаимодействие: Обеспечение безопасного взаимодействия между различными сетями, например, между локальной сетью и интернетом.
4.8.4.2.3. VPN-поддержка: Поддержка виртуальных частных сетей (VPN), обеспечивающих безопасное удаленное подключение к сети.
4.8.4.2.4. Логирование и мониторинг: Запись событий и активности сетевого трафика для последующего анализа и мониторинга безопасности сети.
4.8.4.2.5. Защита от атак: Обнаружение и предотвращение различных типов сетевых атак, включая атаки отказа в обслуживании (DDoS), переполнение буфера и другие угрозы.
5. Windows: Самая распространенная настольная ОС в мире, разработанная компанией Microsoft. macOS: Операционная система для компьютеров Apple. Linux: Свободная операционная система, существующая в множестве дистрибутивов (Ubuntu, Debian, Fedora). Android: Мобильная операционная система от Google, используемая на большинстве современных смартфонов. iOS: Мобильная операционная система от Apple, установленная на iPhone и iPad.
6. Общее
6.1. Роль бизнес-аналитика
6.2. Роль системного аналитика
6.2.1. Задачи
7. Требования
7.1. Типы
7.1.1. BABOK
7.1.1.1. Бизнес-требования
7.1.1.1.1. Примеры
7.1.1.2. Требования заинтересованных сторон
7.1.1.2.1. Примеры
7.1.1.3. Требования к решению
7.1.1.3.1. Функциональные требования
7.1.1.3.2. Нефункциональные требования
7.1.1.3.3. Переходные требования
7.1.2. Wiegers
7.1.2.1. Функциональные требования
7.1.2.1.1. Бизнес-требования
7.1.2.1.2. Пользовательские требования
7.1.2.1.3. Функциональные требования
7.1.2.1.4. Системные требования
7.1.2.2. Нефункциональные требования
7.1.2.2.1. Бизнес-правила
7.1.2.2.2. Атрибуты качества
7.1.2.2.3. Ограничения
7.1.2.2.4. Внешние интерфейсы
7.2. Элиситация
7.2.1. Интервью
7.2.2. Анкетирование
7.2.3. Мозговой штурм
7.2.4. Проведение семинаров и воркшопов
7.2.5. Работы с фокус-группами
7.2.6. Анализ документации
7.2.7. Изучение существующего решения
7.2.8. (анализ интерфейсов, reverse engineering и т.д.)
7.2.9. Наблюдение
7.2.10. Прототипирование
7.3. Документация
7.3.1. Спецификация требований
7.3.2. Диаграммы
7.3.3. Прототипы
7.3.4. Use case
7.3.4.1. ➢ Имя сценария
7.3.4.2. ➢ Цель
7.3.4.3. ➢ Действующие лица
7.3.4.4. ➢ Заинтересованные лица
7.3.4.5. ➢ Предварительные условия
7.3.4.6. ➢ Активаторы
7.3.4.7. ➢ Порядок Событий
7.3.4.8. ➢ Альтернативные пути и дополнения
7.3.4.9. ➢ Исключения
7.3.4.10. ➢ Результат
7.3.4.11. ➢ Дополнения
7.3.5. User story
7.3.5.1. Как [пользователь], я хочу [цель] ... Чтобы [получить выгоду]...
7.3.5.2. Критерии приемки (Acceptance Criteria, AC)
7.3.5.2.1. Четкими и однозначными.
7.3.5.2.2. Измеримыми.
7.3.5.2.3. Достижимыми.
7.3.5.2.4. Релевантными User Story.
7.3.5.2.5. Ограниченными по времени.
7.3.5.3. INVEST
7.3.5.3.1. I — Independent. Не зависит от других историй. Все они могут быть реализованы в любом порядке.
7.3.5.3.2. N — Negotiable. Обсуждаема. Она отражает суть, а не детали, и не содержит конкретных шагов реализации.
7.3.5.3.3. V — Valuable. Ценна для клиентов, бизнеса и стейкхолдеров.
7.3.5.3.4. E — Estimable. Её можно оценить по сложности и трудозатратам.
7.3.5.3.5. S — Small. Она компактна и может быть сделана командой за одну итерацию.
7.3.5.3.6. T — Testable. Она имеет определённые критерии приёмки, т. е. тестируема.
7.3.5.4. Техника SMART
7.3.5.4.1. S (Specific) – Конкретная: Цель должна быть сформулирована максимально точно и однозначно, чтобы не было возможности интерпретировать ее по-разному.
7.3.5.4.2. M (Measurable) – Измеримая: Цель должна быть измеримой, чтобы можно было определить, достигнута она или нет.
7.3.5.4.3. A (Achievable) – Достижимая: Цель должна быть реальной и выполнимой с учетом имеющихся ресурсов и возможностей.
7.3.5.4.4. R (Relevant) – Релевантная: Цель должна соответствовать стратегическим задачам компании и личным интересам человека.
7.3.5.4.5. T (Time-bound) – Ограниченная во времени: Цель должна иметь конкретный срок достижения.
7.3.6. Gherkin
7.4. Менеджмент
7.4.1. Управление версиями
7.4.2. Управление изменениями
7.4.3. Отслеживание состояний требований
7.4.3.1. ❏ Идентификатор ❏ Автор требования ❏ Сложность ❏ Собственность ❏ Приоритет ❏ Источник требования ❏ Законченность ❏ Статус ❏ Срочность
7.4.4. Отслеживание связей требований
7.4.4.1. 1. Проверка достаточности требований и отсутствие "лишних" требований - достигается путём выявления взаимосвязей бизнес-целей (требований) с FR; 2. Используется как инструмент анализа влияния. При внесении изменений в требования, пройдя по цепочке взаимосвязей в матрице, можно определить, какие элементы затрагивают изменения; 3. Используется как система коммуникации между всеми ЗЛ на проекте; 4. Используется как источник информации при трансформации системы.
7.5. Верификация
7.5.1. Характеристики хороших требований
7.5.1.1. Четкими и однозначными: Требования должны быть сформулированы так, чтобы их можно было интерпретировать только одним образом.
7.5.1.2. Измеримыми: Требования должны быть измеримыми, чтобы можно было отслеживать их выполнение.
7.5.1.3. Достижимыми: Требования должны быть реалистичными и достижимыми с учетом имеющихся ресурсов и технологий.
7.5.1.4. Релевантными: Требования должны быть релевантными целям проекта и потребностям пользователей.
7.5.1.5. Ограниченными по времени: Требования должны иметь четко определенные сроки выполнения.
7.5.1.6. Полными: Требования должны описывать всю необходимую функциональность и характеристики ПО.
7.5.1.7. Непротиворечивыми: Требования не должны противоречить друг другу.
7.5.1.8. Изменяемыми: Требования должны быть изменяемыми, чтобы можно было адаптироваться к меняющимся потребностям.
7.5.2. Валидация
7.5.3. Верификация
8. Документы
8.1. V&S
8.1.1. Бизнес-требования
8.1.1.1. 1.1 Исходные данные
8.1.1.2. 1.2 Возможности бизнеса
8.1.1.3. 1.3 Бизнес-цели
8.1.1.4. 1.4 Критерии успеха
8.1.1.5. 1.5 Положение о концепции проекта
8.1.1.6. 1.6 Бизнес-риски
8.1.1.7. 1.7 Предположения и зависимости
8.1.2. Рамки и ограничения проекта
8.1.2.1. 2.1 Основные функции
8.1.2.2. 2.2 Объем первоначально запланированной версии
8.1.2.3. 2.3 Объем последующих версий
8.1.2.4. 2.4 Ограничения и исключения
8.1.3. Бизнес-контекст
8.1.3.1. 3.1 Профили заинтересованных лиц
8.1.3.2. 3.2 Приоритеты проекта
8.1.3.3. 3.3 Особенности развертывания
8.2. Спецификация требований ПО
8.2.1. IEEE 830-1998
8.2.2. Когда применять
8.2.3. RUP (Rational Unified Process)
8.2.3.1. фокусируется на процессе разработки и взаимодействии с пользователями
8.2.4. ISO IEEE 29148-2011
8.2.4.1. фокусируется на более формализованном и структурированном описании требований к системе
8.3. ТЗ, ЧТЗ
8.3.1. ТЗ
8.3.2. ЧТЗ
8.3.3. Стандарты написания ТЗ и ЧТЗ
8.3.3.1. • ГОСТ 34
8.3.3.1.1. 1. Общие сведения 2. Назначение и цели создания (развития) системы 3. Характеристика объектов автоматизации 4. Требования к системе 5. Состав и содержание работ по созданию системы 6. Порядок контроля и приемки системы 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 8. Требования к документированию 9. Источники разработки
8.3.3.2. • ГОСТ 19
8.3.3.2.1. 1. Введение; 2. Основания для разработки; 3. Назначение разработки; 4. Требования к программе или программному изделию; 5. Требования к программной документации; 6. Технико-экономические показатели; 7. Стадии и этапы разработки; 8. Порядок контроля и приемки; 9. Приложения.
8.3.3.3. • IEEE STD 830-1998
8.3.3.3.1. Содержание
8.3.3.4. • ISO/IEC/ IEEE 29148-2011
8.3.3.4.1. SyRS
8.3.3.4.2. SRS
8.3.3.5. • RUP
8.3.3.5.1. Содержание
8.3.3.6. • SWEBOK, BABOK
9. Фазы проекта
9.1. Пресейл
9.1.1. Понять потребности заказчика и определить его бизнес-проблемы, которые проект должен решить.
9.1.2. Сформулировать цели и задачи проекта, которые должны быть достигнуты.
9.1.3. Оценить объем работ и сформировать предварительную смету проекта.
9.1.4. Определить риски проекта и разработать план их mitigation.
9.1.5. Согласовать план действий и подписать договор на реализацию проекта.
9.2. Дискавери
9.2.1. Анализ
9.2.1.1. Анализ идеи – узнать потребности клиента и пользователей, оценить перспективы, выработать оптимальное IT-решение;
9.2.2. Требования
9.2.2.1. Требования к продукту – собрать требования с уровнем точности, достаточным для подготовки оценки, без погружения в детали и нюансы (ФТ, НФТ, ограничения, построить ЛМД)
9.2.3. Решение
9.2.3.1. Решение – прорабатываем оптимальное техническое решение (составляем список задач (BackLog), схема компонентов системы и внутренних или внешних сервисов, создаем прототип, оценка решения)
9.2.4. Артефакты
9.2.4.1. Mind Map
9.2.4.2. ER диаграмма или Диаграмма классов
9.2.4.3. UStory, Ucase – в качестве ФТ
9.2.4.4. BPMN или UML Activity diagram
9.2.4.5. Прототип (wireframe)
9.2.4.6. НФТ
9.2.4.7. Список задач (BackLog)
9.3. Запуск
9.3.1. Cпособы монетизации приложений
9.3.1.1. Реклама в приложении
9.3.1.2. Подписка
9.3.1.3. Продажа мест под рекламу
9.3.1.4. Встроенные покупки
9.3.1.5. Маркетплейс
9.3.1.6. Freemium
9.3.2. За что отвечает СА
9.3.2.1. Создание плана запуска: Определение сроков, задач и ответственных за их выполнение.
9.3.2.2. Разработка документации для пользователей: Руководства пользователя, обучающие материалы, FAQ.
9.3.2.3. Проведение тестов: Тестирование системы в production-среде, поиск и устранение ошибок.
9.3.2.4. Обучение пользователей: Проведение тренингов, семинаров, вебинаров.
9.3.2.5. Оказание поддержки пользователям: Ответы на вопросы, решение проблем.
9.3.2.6. Сбор обратной связи: Анкетирование, интервью, анализ логов.
9.3.2.7. Анализ данных: Отслеживание ключевых показателей эффективности (KPI), выявление проблемных зон.
9.3.2.8. Подготовка отчетов: Отчеты о ходе запуска, достижениях и проблемах.
9.4. Поддержка
9.4.1. Первая линия поддержки
9.4.2. Вторая линия поддержки
9.4.3. Третья линия поддержки
9.4.4. Четвертая линия поддержки
9.5. Этапы проекта
9.5.1. Сбор и анализ требований: Этап сбора и анализа информации о потребностях заказчика, бизнес-процессах и существующих системах.
9.5.2. Проектирование: Этап разработки архитектуры, функциональности и интерфейсов системы.
9.5.3. Разработка: Этап реализации системы, включая программирование, тестирование и отладку.
9.5.4. Внедрение: Этап установки, настройки и обучения пользователей системы.
9.5.5. Поддержка: Этап исправления ошибок, обновления системы и оказания технической поддержки.
10. Проект
10.1. Эстимация
10.1.1. Цели
10.1.2. Техники оценки проекта
10.1.2.1. Three-point estimating
10.1.2.2. T-shirts estimating
10.1.2.3. Planning poker
10.1.2.4. WBS
10.1.2.5. Delphi
10.1.2.6. Три амиго
10.1.3. Процесс
10.1.3.1. Определите задачи
10.1.3.2. Определите ресурсы
10.1.3.3. Оцените время
10.1.3.4. Установите приоритеты
10.1.4. Story points
10.2. Онбродинг
10.2.1. Методы
10.3. Процессы
10.3.1. Бэклог продукта
10.3.1.1. Категории
10.3.1.1.1. Исправления ошибок
10.3.1.1.2. Нефункциональные задачи
10.3.1.1.3. Функциональные задачи
10.3.1.2. Взаимодействие SA с другими
10.3.1.2.1. создание US (проанализировать задачу, хорошо ее описать в юзер стори, правильно разделить ее на части),
10.3.1.2.2. работа с Backlog (работая с владельцем продукта и помогая ему наполнять юзер стори),
10.3.1.2.3. работа со спринтами (следить за выполнением задач в рамках каждого спринта и управлять изменениями требований),
10.3.1.2.4. разработка MVP (отвечает за определение, какие функции должны быть включены в MVP, и какие требования можно отложить на будущее),
10.3.1.2.5. декомпозиция задач (это помогает команде лучше понимать, что нужно делать, и помогает улучшить планирование работы)
10.3.1.3. V and S
10.4. Риски
10.4.1. Виды
10.4.1.1. По причинам
10.4.1.1.1. Внутренние: Возникают из-за внутренних факторов проекта (некомпетентность команды, ошибки в планировании, устаревшие технологии).
10.4.1.1.2. Внешние: Возникают из-за внешних факторов (изменение рынка, экономические кризисы, стихийные бедствия).
10.4.1.2. По возможным последствиям
10.4.1.2.1. Временные. Последствия этих рисков приведут к нарушению сроков проекта.
10.4.1.2.2. Бюджетные. Такие финансовые риски грозят увеличением проектной сметы.
10.4.1.2.3. Риски объёмов работ. Они влияют на трудочасы команды или отдельных сотрудников.
10.4.1.2.4. Риски взаимодействия или зависимости. Возникают, когда один этап проекта зависит от окончания другого.
10.4.1.3. По размеру возможных потерь
10.4.1.3.1. Допустимые. Если риск перерастает в проблему, то потери не превысят размер прибыли.
10.4.1.3.2. Критические. Могут привести к потере выручки или вложенных в проект денег.
10.4.2. Реестр рисков
10.4.3. Техники выявления
10.4.3.1. Мозговой штурм: Групповая генерация идей о потенциальных рисках.
10.4.3.2. Интервью: Опрос экспертов в различных областях проекта.
10.4.3.3. Анализ исторических данных: Изучение прошлых проектов для выявления рисков, которые уже реализовались.
10.4.3.4. Анализ SWOT: Анализ сильных и слабых сторон, возможностей и угроз проекта.
10.4.3.4.1. Пример SWOT-анализа для интернет-магазина
10.4.3.5. Чек-листы: Использование готовых списков потенциальных рисков.
10.4.4. Активности управления рисками
10.4.4.1. Выявление: Определение потенциальных рисков, которые могут повлиять на проект.
10.4.4.2. Анализ: Оценка вероятности и потенциального влияния каждого риска.
10.4.4.3. Планирование: Разработка стратегии реагирования на каждый риск.
10.4.4.4. Реализация: Осуществление запланированных действий по реагированию на риски.
10.4.4.5. Мониторинг: Отслеживание рисков и корректировка плана управления рисками по мере необходимости.