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

Это два тесно связанных процесса.

В процеесе постановки задачи:

а) четко формулируют назначение и основные требования к ИС и его результатам,

б) выявляются ограничения, существующие для достижения целей ИС и выполнения требований.

Почему требования - это важно?

Причины провалов проектов:

Факторы успеха проектов:

Требования связаны с тестами (V-модель):

V-модель помогает спланировать проект:

Конец формы

Конец формы

Установление требований – процесс ЖЦ программы, во время которого требования заказчика уточняются, формализуются и документируются. Требования к системе это формулировка:

а) сути системного сервиса (функциональные требования) и

б) ограничений.

Формулировка сути сервиса:

1) Определение функции, кототрые должно выполнять разрабатываемое ПО. Характеризует поведение системы по отношению к пользователям. Это определение бизнес - правил, которые должны всегда выполняться, например, «двухнедельная зарплата выплачивается в среду» или «стипендия студентам начисляется до 25 числа месяца» и т.д. Основной решаемый вопрос – «Что должна делать будущая система?»

2)Формулирование вычислительных операций. Это может быть связана с вычислениями, которые должна прозвести система, например, «начислять стипендию студентам в текущем семестре на основе их успеваемости в предыдущем семестре с использованием конкретной формулы».

Формулировка ограничений выражает ограничивающие условия:

а) на поведение системы

б) разработку системы.

в) эксплуатацию системы

Примером первого ограничения может быть ограничение на безопасность, например,: «только непосредственные руководители могут обращаться к информации об зарплате их персонала». Пример второго типа ограничения:» разработчики должны использовать средство разработки Delphi 7».

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

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

Формулируется цель решения задачи и подробно описывается ее содержание:

- что дано,

- что необходимо найти, получить;

- как определить решение;

- какие данные должны быть подготовлены и источники их получения.

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

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

Неправильное понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль требуемого ПС в среде его использования. Поэтому важной задачей при создании определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот контекст в определении требований представить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т.п.) и характеристики связей между ними.

Известны три способа разработки определения требований к ПС:

· управляемая пользователем разработка,

· контролируемая пользователем разработка,

· независимая от пользователя разработка.

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

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

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

С точки зрения обеспечения надежности ПС наиболее предпочтительным является контролируемая пользователем разработка.

Анализ требований включает переговоры между разработчиками и