Проектирование программных средств сбор требований и организация архитектуры программных средств

Краткое описание

Содержание

Введение…3

1.Сбор требований…4

2.Этапы по сбору требований.

2.1.Определение основных профилей пользователей…7

2.2.Формирование инициативной группы…8

2.3.Сбор пользовательских историй…8

3.Организация архитектуры программных средств...13

Заключение…15

Список использованной литературы…17

Введение 

Сбор требований - необходимый этап для любого проекта, но если в малых ещё можно что-то делать через постоянное обращение к клиенту: "делаем так?", то в случае большого или высоко нагруженного проекта без проведения этого этапа в полном объёме реализовать проекта. Цель этапа не создать юридический документ, а максимально полно зафиксировать требования клиента по проекту. На выполнение этого этапа не нужно выделять очень много времен. В случае сложной предметной области, возможно, заказчик сам не может толком собрать такие требования. 

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

Формирование детального описания будущего продукта — основная задача аналитика в процессе проектирования. Если на этапах сбора определялись требования пользователей к системе — мотивы, по которым они будут еѐ использовать, то теперь нужно определить, каким именно способом требования пользователей будут удовлетворены. Только с этого момента команда разработки продукта получает право принимать проектные решения — решать, какая конкретно функциональность будет реализована (Отвечать на вопрос — «что?»). 

В процессе проектирования группой разработки продукта должно быть создано «Техническое задание» (Functional Specification), на основе которого будет производиться разработка и тестирование продукта. Это документ должен содержать следующие элементы: 

• Требования к продукту уровня системы. 

• Модель взаимодействия с пользователем: 

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

- Потоки выполнения вариантов использования. 

- Ограничения интерфейсов. o GUI макеты. 

- CLI/ API спецификации. 

• Архитектура продукта. 

• Техническая информация. 

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

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