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

Определение и анализ требований к ПО
(окончание)

Задачи бизнес-аналитика

Задачи бизнес-аналитика
Задачи аналитика — прежде всего выяснить, для чего нужна пользователям новая система, и затем определить пользовательские, функциональные и качественные требования, на основе которых команды смогут оценить и спланировать проект, а также спроектировать, построить и проверить продукт.
От таланта аналитика зависит успех проекта.
Аналитик — это посредник в общении, проясняющий смутные представления пользователей и обращающий их в четкие спецификации, которыми руководствуется команда разработчиков продукта.
В проектах гибкой разработки (agile) также нужен бизнес-анализ. В таких проектах обычно имеется роль владельца продукта, который выполняет часть традиционных задач бизнес-аналитика.

Выявление требований

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

Классификация предоставляемой клиентом информации

Документирование требований
«Спецификация требований к ПО» является отраслевым стандартом (ISO/IEC/IEEE 2011).
Каждая организация, специализирующаяся на разработке ПО, должна принять один или несколько стандартных шаблонов спецификации требований к ПО для использования в проектах. Доступны различные шаблоны спецификации.
Пример шаблона на основе ISO/IEC/IEEE 2011:
1. Введение
1.1 Назначение
1.2 Соглашения, принятые в документах
1.3 Границы проекта
1.4 Ссылки

Документирование требований
2. Общее описание
2.1 Общий взгляд на продукт
2.2 Классы и характеристики пользователей
2.3 Операционная среда
2.4 Ограничения дизайна и реализации
2.5 Предположения и зависимости
3. Функции системы
3.x Функция системы X
3.x.1 Описание
3.x.2 Функциональные требования
4. Требования к данным
4.1 Логическая модель данных
4.2 Словарь данных
4.3 Отчеты
4.4 Получение, целостность, хранение и утилизация данных

Документирование требований
5. Требования к внешним интерфейсам
5.1 Пользовательские интерфейсы
5.2 Интерфейсы ПО
5.3 Интерфейсы оборудования
5.4 Коммуникационные интерфейсы
6. Атрибуты качества
6.1 Удобство использования
6.2 Производительность
6.3 Безопасность
6.4 Техника безопасности
6.x [Другие]
7. Требования по интернационализации и локализации
8. Остальные требования
Приложение A. Словарь терминов
Приложение Б. Модели анализа

Документирование требований
Модели анализа
Никакое представление требований в одном виде не дает их полной картины (Davis, 1995). Необходима комбинация текстовых и визуальных способов представления требований на различных уровнях абстракции, чтобы получилась полная картина создаваемой системы.
Модели анализа должны дополнять — а не заменять — спецификации требований на естественном языке. Визуальные модели требований могут помочь выявить отсутствующие, излишние и несовместимые требования.

Документирование требований
К моделям визуального представления относятся:
Диаграммы потоков данных (data flow diagrams, DFD);
Диаграммы переходов состояний (state-transition diagrams, STD) и таблицы состояний;
Таблицы и деревья решений;
Диаграммы вариантов использования;
Функциональные диаграммы SADT;
диаграммы «сущность-связь» (entity-relationship diagrams, ERD);
Диаграммы рабочих потоков, такие как диаграммы swimlane;
…

Анализ и моделирование функциональной области внедрения ПС

Определения архитектуры ПО
В основе проектирования программных систем (ПС) лежит моделирование предметной области.
Этап проектирования ПС обычно состоит из двух подэтапов: архитектурное проектирование и детальное проектирование.
Анализ и моделирование предметной области внедрения ПС оказывает большое влияние на разработку архитектуры.
Рассмотрим, что такое архитектура программного обеспечения.

Определения архитектуры ПО
1. Архитектура – это организационная структура системы.
2. Архитектура информационной системы – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.
3. Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними.

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

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

Зачем все это?
7. Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания.
Определения архитектуры ПО

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

Бизнес-модель компании

Бизнес-модель компании
Миссия согласно [ISO-15704] -это
Деятельность, осуществляемая предприятием для того, чтобы выполнить функцию, для которой оно было учреждено, - предоставления заказчикам продукта или услуги.
Механизм, с помощью которого предприятие реализует свои цели и задачи.
Определение миссии позволяет сформировать дерево целей компании - иерархические списки уточнения и детализации миссии.
Дерево целей формирует дерево стратегий - иерархические списки уточнения и детализации способов достижения целей.
При уточнении и детализации происходит процессно-целевое описание компании, позволяющее получить взаимосвязанные ответы на следующие вопросы: зачем-что-где-кто-как-когда-кому-сколько.

Бизнес-модель компании

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