# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Шаблоны Тестирование требований Тест-анализ и тест дизайн Тест план Метрики качества Автотесты Selenium XPATH Генератор данных Безопасность Нагрузочное ДАННЫЕ Ресурсы MDM Big data Об информации SQL intro MongoDB intro БИБЛИОТЕКА Курсы Системная инженерия "Сумма технологии" "Антихрупкость" Экстраполяция в будущее Политэкономия Красивые диаграммы Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ: - ПРОЦЕССЫ - Управление - Теория ограничений - Водопад, этапы | Этапы развития приложения | Цели и потребности | Причастные стороны | Приложение AS IS | Варианты использования | Архитектура TO BE | Спецификация требований и ограничений | Сценарии для тестирования ТЕСТИРОВАНИЕ
Водопад: этапы, требования
last update: 13-10-2021, 19:25 UTC
Этапы развития приложения

Этап Исполнители На входе На выходе
1 Определение ценностей и потребностей
  • Заказчик(и)
  • Аналитик(и)
  1. Постановка задачи от заинтересантов, обозначение целей и потребностей
  1. Цели и потребности
  2. Причастные стороны
2 Сбор и формирование требований
  • Заказчик(и)
  • Аналитик(и)
  • Др. причастные стороны
  1. Цели, проблематика, потребности
  2. Репозиторий для хранения требований
  3. Доступ Аналитиков к репозиторию существующего приложения
  1. Приложение AS IS
3 Проектирование (архитектура, требования)
  • Заказчик(и)
  • Аналитик(и)
  • Др. причастные стороны
  1. Требования к приложению
  2. Репозиторий для хранения архитектурного описания
  3. Финансовые, технологические и иные ограничения
  4. Доступ Аналитиков к репозиторию существующего приложения
  1. Варианты использования
  2. Целевая архитектура
  3. Спецификация требований и ограничений
4 Разработка
  • Администраторы
  • Аналитики
  • Разработчики
  1. Архитектура приложения
  2. Требования к приложению
  3. Оборудование, развёрнутое и настроенное окружение для разработки
  4. Оборудование, развёрнутое и настроенное окружение для dev-версий приложения
  5. Оборудование, развёрнутое и настроенное окружение для репозитория
  6. Оборудование, развёрнутое и настроенное окружение для CI
  7. Репозиторий для хранения кода приложения
Сборки приложения.
5 Тестирования
  • Заказчик
  • Администраторы
  • Аналитики
  • Разработчики
  • Тестировщики
  1. Архитектура приложения
  2. Требования к приложению
  3. Оборудование, развёрнутое и настроенное окружение для разработки
  4. Оборудование, развёрнутое и настроенное окружение для dev-версий приложения
  5. Оборудование, развёрнутое и настроенное окружение для test-версий приложения
  6. Оборудование, развёрнутое и настроенное окружение для репозитория
  7. Оборудование, развёрнутое и настроенное окружение для CI
  8. Репозиторий для хранения кода приложения
Приложение, удовлетворяющее требованиям, без критических ошибок и готовое к эксплуатации
6 Развёртывание
  • Администраторы
  • Разработчики
  1. Оборудование, развёрнутое и настроенное окружение для CI
  2. Оборудование, развёрнутое и настроенное окружение для prod-версий приложения
  3. Скрипты, джобы и описание развёртывания
Развёрнутое на мощностях приложение, готовое к эксплуатации
7 Эксплуатация, поддержка и развитие
  • Все причастные стороны
  1. Обратная связь от эксплуатирующих приложение
  2. Мощности для доработок
  3. Мощности для тестирования доработок
  4. Репозиторий для хранения кода приложения
  5. Репозиторий для хранения требований
  6. Репозиторий для хранения архитектурного описания
Сборки приложения.
8 Вывод из эксплуатации
  • Заказчик
  • Администраторы
  1. Волевое решение Заказчика
void

Цели и потребности

Требование (requirement) = утверждение (statement), которое выражает нужды (needs) и связанные с ними обстоятельства (conditions) и ограничения (constraints).
Требование это описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи.

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

Цели разработки ПО

Код цели Приоритет Цель
П.Ц.01 1 Обеспечение ...
П.Ц.02 2 Реализация ...
П.Ц.03 1 Мониторинг ...

Бизнес-требования

Код БТ Код цели, покрываемой требованием Приоритет Бизнес-требование
П.БТ.01 СП.Ц.01 1 Приложение должно давать возможность ...

Причастные стороны

Стейкхолдеры (stakeholders, заинтересованная сторона, причастная сторона) = физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы/проекта/продукта или её свойств, удовлетворяющих их потребностям и ожиданиям ( ISO/IEC 15288:2015, ISO/IEC 29148:2018).
Иными словами, это те, кто оказывает воздействие (affects) на Систему/Проект/Продукт/Услугу либо подвергается воздействию Системы (affected by) каким-либо образом.

Роль Исполнитель Комментарий
.. .. ..

Приложение AS IS

Архитектура AS IS

Требования AS IS

Варианты использования

Use case = последовательность действий в диалоге между Актором и Компонентом/Системой с получением значимого результата, где Актором может быть пользователь или что-то, что может обмениваться информацией с Системой.

Маппинг бизнес-требований и Вариантов использования

UC БТ
П.UC.01 П.БТ.01
П.UC.01.02 П.БТ.02
П.БТ.03
П.БТ.04
П.UC.04 П.БТ.05

Варианты использования

Use case Клиент сервиса Поток событий Комментарий
.. .. .. ..

Архитектура TO BE

Спецификация требований и ограничений

Ограничение дизайна и реализации, зависимости

Ограничения (limitations, constraints) представляют собой факторы, ограничивающие выбор способов и средств (в том числе инструментов) реализации продукта.

Код Связь с БТ Приоритет Ограничение / зависимость
П.ОГ.01 П.БТ.09 1 Средствами devops должны быть:
1. ...

Функциональные требования

Функциональные требования (functional requirements) описывают поведение системы, т.е. её действия (вычисления, преобразования, проверки, обработку и т.д.) В контексте проектирования функциональные требования в основном влияют на дизайн системы. Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что она не должна делать (например: "приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции").

Код ФТ Код покрываемого UC Приоритет Критерии Функциональное требования
П.ФТ.01 П.UC.04 1 compliance В случае проведения таких-то операций -- подключён контроль по ...

Требования к данным

Требования к данным (data requirements) описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание базы данных и особенностей её использования.

Требования к интерфейсам/интеграции

Требования к внешним интерфейсам (external interfaces requirements) описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой.

Требования к масштабируемости

Требования к надёжности

Требования к безопасности

Требования к операционной среде

Требования к документации

Сценарии для тестирования