Презентация на тему Требования к системе в виде модели. Область применения и ограничения

аналитиков
Занимаюсь методологией и инструментальной поддержкой системного анализа

Disclaimer: это мой

субъективный анализ и выводы, математической проверки на контрольной группе – не было.

начало отсчета
Текущая метамодель
Инструментальная поддержка
Анализ и прогноз: приживется ли модель

на проекте
Планы на будущее

(например, в математической, физической, символической, графической или дескриптивной), предназначенное

для представления определённых аспектов этой реальности и позволяющее получить ответы на изучаемые вопросы[3]:80.
У нас это
набор связанных элементов, который описывает систему
с конкретной точки зрения (требований)
с определенным уровнем детализации
Отображается в виде визуальных диаграмм с участием элементов, содержащих текстовое описание
Поддерживается в актуальном состоянии после изменений

и синтез решения
Представление информации (Документирование требований)
Учет в целях управления

(управление требованиями)

И под всем этим лежит служебный сценарий:
Хранение требований и отношений между ними

– создает и поддерживает модель
Архитектор – использует модель при

архитектурном проектировании
Разработчик - использует модель или требования из нее при разработке
Тестировщик - использует модель или требования из нее при проектировании тестов и тестировании
Менеджер проекта – использует требования при планировании и анализе текущего статуса проекта

& *nix Apps
Infrastructure Services
Core Technologies
… Other PL
Mac PL
Mobile PL
Mac

Apps

Mobile Apps

Internal Research
Tools

Internal Development
Tools

(разнообразие вариантов и стилей ведения проектов в демократическом стиле)
Специфичная

предметная область (очень техническая область (ОС, файлы, участки памяти, вирусы, инжекты и т.д.), часто исследовательская работа (результат заранее неизвестен), наукоемкая (мат.методы) – мало информации в свободном доступе)
В продуктах фокус на обработку, а не на ввод/хранение/вывод информации (есть интерфейсы, обработка, нет БД, миграций данных и т.д.), в сервисах фокус может быть на потоковую обработку данных

Первоначальный контекст (проекты и продукты)

на своей поляне, теперь все вместе, набор новых людей)
Отсутствует

общая методологическая и инструментальная база
Разный уровень квалификации аналитиков и качества результатов, требуется единообразие для управления аналитическими работами
Требуются практики разработки требований для очень разных систем в духе современных тенденций (mainstream – UML, Usecase)

Architect (общее место для хранения требований)
Давайте писать требования в

виде usecase’ов
Вот методологическая группа, часть рабочего времени коллеги будут помогать (разрабатывать и описывать рекомендации по моделированию, готовить шаблоны отчетов для формирования SRS)
Ходите на тренинги в Люксофт, читайте Вигерса, Коберна и т.д.

решайте сами, иметь или не иметь

в САО ЛК

– usecase, requirement, связь trace, диаграмма, actor
2уровневая иерархия требований

в 1 проекте: бизнес-требование (BRQ) – Usecase (UC)+ функциональные и нефункциональные требования (SR)
Основные диаграммы: диаграмма usecase, диаграмма трассировок UC-SR, BRQ-UC
Дополнительные диаграммы: activity, DataFlow, StateChart, Classes, все, что захотите еще…

требованию
По конкретной функциональной области
По всей версии целиком

требованиях является модель требований системы
Демонстрация/представление новой функциональности для всех

ЗЛ: отчет по модели по диаграмме трассировок конкретного бизнес-требования BRQ-UC+SR
Демонстрация/представление требований на систему: отчет по модели по полному набору требований (пакет, группирующий требования по функциональной области, в нем UC+SR
Элементы учета: либо SRS по BRQ (документ), либо отдельные UC, SR (отдельные элементы в учетной системе), либо только UC

light вариант
Основные элементы – usecase (текст a-la user story/Usecase

2.0), requirement, связь trace, диаграмма, actor
2уровневая иерархия требований в 1 проекте: бизнес-требование (BRQ) – Usecase (UC)+ функциональные и нефункциональные требования (SR)
Основные диаграммы: диаграмма usecase, диаграмма трассировок UC-SR, BRQ-UC
Дополнительные диаграммы: activity, DataFlow, StateChart, Classes…

megalight
Основные элементы – usecase (без текста, только название и

уникальный Id), диаграмма, actor
2уровневая иерархия требований в 1 проекте: бизнес-требование (BRQ) – Usecase (UC)
Основные диаграммы: диаграмма use case, диаграмма трассировок BRQ-UC
Дополнительные диаграммы: activity, DataFlow, StateChart, Classes…

не мешая друг другу
Наличие актуальных требований на всю версию

(а не только на изменения)
Легкий поиск требований в проекте при impact-анализе
Скорость подготовки документов нужного формата (как отчетов по модели)
Снижение затрат на обучение при переходах из проекта в проект
Прозрачность требований для аналитиков смежных команд

систему
с конкретной точки зрения (требований)
с определенным уровнем

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

работы для всех аналитиков с централизованным управлением (бекап, зеркалирование,

управление доступом и т.д.)
повторное использование элементов (соответствие: 1 сущность – 1 элемент в модели и использование его на всех диаграммах для всех связей)
написание текстов и таблиц в элементах
рисование диаграмм (диаграмма – SQL запрос по модели),
генерация настраиваемых отчетов (word, html не подошел)
Возможность экспорта в другие системы (TFS самописный, Confluence?)
Версионирование

IT, у нас почти не занимает время)
Операционная поддержка пользователей

(вместе с базой) – 0,05 FTE
Допиливание (переход на новые версии, оптимизация отчетов и прочие маленькие улучшалки) – 0,2 FTE
Итоговые затраты – покупка и обновление лицензий, сервер для репозитория

фиксацией скоупа, много юридических согласований, много аналитиков на 1

проекте, много смежных команд, с которыми надо синхронизироваться)
Порталы и сервисы (несколько человек на 1 проекте + все как выше)
Набор проектов Core Technologies (одинаковые процессы разработки, много клиентов, 1 аналитик на несколько проектов)

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

результате), нет заморозки Scope/сроков, основной упор на добавление новой функциональности, мало связей с другими командами, мало аналитиков, умеющих моделировать)
инфраструктурные сервисы (малое количество аналитиков, 1 аналитик на 1-2 проектах, уникальные сложные системы, специфичная предметная область, программисты-эксперты, мало аналитиков, умеющих моделировать)
Сервисы (сильная воля руководства на создание полного справочника в текстовом виде)
Продукт (часть многоплатформенной программы, долгий срок жизни бизнес-требований)

Везде: маленькие команды, короткие итерации, над требованиями работает вся команда, постепенная детализация требований