5. Формирование требований к программному продукту.

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

Внешнее описание играет роль точной постановки задачи и должно содержать всю информацию, необходимую пользователю для применения программного средства. Оно является исходным документом для 3-х параллельно протекающих процессов:

- для разработки текстов программ (конструирование и кодирование).

- разработки документации по применению ПС.

- разработка существенной части комплекта тестов для тестирования ПС.

Исходным документом для разработки внешнего описания является определение требований к ПС, документ издается на основе общения с заказчиком.

В спецификации выделяют 2 части:

1. Функциональная спецификация, описывающая функции программы.

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

Внешнее описание ПС = определение требований + спецификация качества + функциональная спецификация.

3 уровня формализации спецификации:

1. словесная спецификация.

2. модельные и структурированные спецификации (построение схем, диаграмм и др.).

3. формальная спецификация (на основе математических формализмов).

По способу представления спецификации выделяют:

1. Спецификации, имеющие текстовое представление (текстовые и формальные);

2. Представление с помощью информационных объектов (модельные).

4. Определение требований к пс.

Представляет собой смесь объектов на естественном языке, различных таблиц и диаграмм. Важная задача – установление контекстов использования ПС.

3 способа разработки и определения требований:

1. Управляемая пользователем разработка. Требования определяются заказчиком, когда заключает договор с коллективом разработчиков. В этом случае разработчик должен выяснить: понятны ему требования заказчика или нет.

2. Контролируемая пользователем разработка. Требования формируются разработчиком при участии представителя пользователя. Пользователь информирует разработчика о своих потребностях и контролирует, насколько сформулированные требования отражают потребности (утверждается представителем пользователя).

3. Независимая от пользователя разработка (при перспективе широкого применения разработанного ПС).

Наиболее предпочтителен вариант 2.

6. Проектирование (разработка архитектуры пс)

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

Проектирование выполняется на 2 – х уровнях:

1. Проектирование архитектуры ПС в целом (проектирование «в большом»).

2. Детальное проектирование – проектирование модулей (проектирование «в малом»).

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

Основные задачи разработки архитектуры ПС:

1. Выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании).

2. Определение способов взаимодействия между выделенными программными подсистемами.

В совокупности программную архитектуру описывают 4 структуры:

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

2. Модульная – определяет организацию ПС как совокупности модулей, т. е. программных единиц, выполняемых членами команды разработчиков.

3. Процессная – описывает поведение системы во время выполнения программы.

4. Физическая – определяет отображение элементов ПС на аппаратное обеспечение.

Также используют другие структуры: структура вызовов, структура потоков, данных, структура потоков управления, структура классов.