stankin / oop-model Goto Github PK

• стрелки механизмов преобразуются в актеров;
• декомпозируемые механизмы становятся родительскими актерами;
• имена блоков становятся именами прецедентов;
• все блоки дочерней диаграммы объединяются в один пакет с именем родительской.

• Анализ функционала тестируемого программного обеспечения на уязвимости

• Описание алгоритмов тестирования функциональных возможностей системы SWOT-анализа

• блоки
• механизмы
• входные данные
• выходные данные
• ограничения

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

Распределение задач по исполнителям.

Результат: на странице проекта.

Поиск и краткое описание аналогов ПП, выделение основных функций и преимуществ.

Результат: документ.

Как: аналитик
Хочу: функцию преобразования диаграммы IDEF0 в Use Case
Чтобы: сэкономить время и устранить ошибки при конвертации диаграмм

Приемочный тест: потоки конвертированы корректно, механизмы преобразованы в актеров

Эпик: задача 2

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

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

Все блоки дочерней диаграммы объединяются в один пакет с именем родительской.

Как: директор по развитию
Хочу: получать результаты SWOT-тестов процессов развития предприятия (открытия новых отделов, внедрение новых технологий)
Чтобы: разработать и маркетинговую стратегию и определить дальнейшее распределение ресурсов по сегментам

Приемочный тест: сформирован swot-отчёт за запрашиваемый период

Эпик: задача 8

Стрелки механизмов преобразуются в актеров

Как дизайнер, я хочу получить требования к оформлению интерфейса, а также продумать User-Friendly интерфейс для проекта, то есть предложить прототип HTML-страниц.

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

Четкое фиксирование сроков исполнения в рабочем календаре.

Результат: Angular Calendar.

1. Рассмотреть различные варианты исходных данных для конвертации в UML Class Diagram.
2. Произвести классификацию данных.

Выбор наиболее подходящего языка программирования для реализации тестов

• определение состава и структуры таблиц БД на основе результатов концептуального проектирования;
• проверка полученной модели с помощью методов нормализации;
• выделение сущностей;
• построение ER-диаграмм;

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

Как: РП
Хочу: видеть формализованные данные для преобразования к UML Class Diagram
Чтобы: в дальнейшем можно было осуществить данное преобразование
Приемочный тест: в качестве приемочного теста необходимо увидеть преобразования исходных данных пользователя в UML Class Diagram в экранной форме

Описание требований и их фиксация.

Задача выполнена. Результат представлен на странице.

1. Создать различные наборы тестовых значений.
2. Произвести детальную проверку работы функции.
3. Занести результаты тестов в отчет.

• выделение задач;

• распределение задач по исполнителям.

• 4,5:1 для небольших текстов
• 3:1 для больших текстов (14pt жирный/ 18pt обычный)

Разработка структуры БД, необходимой для проекта

Результат: схема БД.

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

• тайм-менеджмент по конкретным задачам;

• подтверждение выполнения задачи.

1. Обоснование необходимости внедрения продукта
2. Внедрение продукта

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

• Сформировать команду
• Определить роли
• Описать кто-что должен делать в проекте

Результат: документ.

• BPMN-терминология;
• BPMNSTORM Project;

Задача выполнена.
Результат: диаграмма BPMN на BPMNStorm, терминология.

1. Проанализировать проект системы преобразования данных.
2. Разработать функцию преобразования данных.

Модуль отправки JSON-файла

1. Получить данные тестов.
2. Создать документацию для внедрения продукта.

Описание основного функционала.

Задача выполнена.
Результат: doc.

Планирование сроков, ресурсов и стоимости разработки.

• SWOT-терминология;
• описание требований к ПП;
• существующие реализации;
• выделение функций, которые будут реализованы;
• делегирование задач исполнителям;
• занесение сроков в календарь;

• механизм = актер;
• декомпозируемые механизмы = родительские актеры;
• блок = прецедент;
• дочерняя диаграмма = пакет.

1. Проанализированные данные необходимо распределить в обособленные группы
2. Спроектировать модуль преобразования данных

• выбор СУБД;
• реализация спроектированной БД на конкретной СУБД;
• описание структур таблиц БД;
• схема данных;
• выбор языка программирования;
• создание шаблона Web-сайта;
• встраивание БД в Web-сайт;
• тестирование работоспособности.

Как технический писатель, я хочу получить задачи и описать их в To Do List.

Имена блоков становятся именами прецедентов.

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

Задание выполнено.
Результат: doc.

Написание исходного кода тестов

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

Как аналитик, я хочу получить список User Story, для дальнейшей регистрации задач проекта (Issue).