Этап планирования и анализа требований

УСТАНОВЛЕНИЕ ТРЕБОВАНИЙ И ПРОЕКТИРОВАНИЕ

УПРАВЛЕНИЕ и разработка документации

Процесс управления длится весь жизненный цикл программного подукта и в условиях конкуренции главными задачами являются:

- возможность получения максимальной прибыли

- минимизация сроков разработки

- минимазация коллектива разработчиков.

Документация также рарабатывается в процессе всего ЖЦ (будем говорить отдельно).

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

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

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

а) формулировка сути системного сервиса и

б) формулировку ограничений.

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

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

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

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

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

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

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

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

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

Результатом этапа установления требований является документ, содержащий изложение требований, например, техническое задание.

Цель:
- получение требований;
- выработка производных от них требований для этапа оценки безопасности.
Входные данные:
- требования к системе, аппаратный интерфейс, архитектура системы;
- план разработки ПО;
- стандарты на требования к ПО.

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

Проектирование – процесс ЖЦ программы, во время которого исследуется ее структура и взаимосвязи элементов. Основной решаемый вопрос – «Как система будет удовлетворять полученным требованиям?»

Проектирование должно проводиться на двух уровнях

1) Проектирование архитектуры (проектирование системы, проектирование «в большом»). Архитектура программного продукта – это его представление как системы, состоящей из некоторой совокупности взаимодействующих подсистем (отдельных программ) (декомпозиция системы).

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

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

При проектировании архитектуры используются различные методологии, например, структурная и объектно-ориентированная. Их различие состоит в разных способах декомпозиции систем.

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

Объектная декомпозиция рассматривает структуру объектов и связей между ними, а также поведение системы в терминах обмена сообщений между объектами.

В нашем курсе мы будем знакомиться только со структурной т.к. у вас будет дисциплина «Объектно-ориентированное программирование», где вы познакомитесь с объектно-ориентированой методологией.

Первый уровень - проектирование архитектуры (проектирование «в большом») для структурной методологии включает следующие основные методы:

1.метод нисходящего проектирования (сверху – вниз)

2.метод восходящего проектирования (снизу – вверх)

Метод нисходящего проектирования (сверху – вниз) представляет собой подход функциональной декомпозиции на основе следующих двух стратегий:

1.пошагового уточнения, при котором на каждом следующем этапе декомпозиции определяются модули очередного, более низкого уровня.

2.Анализа сообщений, при котором анализируются потоки данных, обрабатываемые модулями.

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

Основыми методами проектирования модулей (второй уровень,т.е. проектирование в «малом») для структурной методологии являются:

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

- Структурные карты;

- Диаграммы деятельности

- Диаграммы переходов состояний

- Блок-схемы;

- Снимки экранов;

- структурограммы;

- Псевдокод

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

Псевдокод Алгоритм Евклида нахождения НОД A и B

Начало

Пока A<> B повторять

Начало

Если A > B то A = A – B

Иначе

B = B – A

Конец если

Конец

Вывод A

Стоп

Конец

Основными подходами к ведению анализа и проектирования при структурной методологи являются:

1.процедурно-ориентированные подходы, в которых первично проектирование функциональных компонентов

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

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

Конкретными подходами являются:

- Подход Йордана и Де Марко

- Подход Гейна-Сарсона

- Подход Константайна.

- Подход Джексона

- Подход Варнье-Орра

- Подход Мартина

- Подход промышленного метода Oracle

ПРОЕКТИРОВАНИЕ ПО включает в себя: построение функциональной, информационной и математической моделей задачи, разработка алгоритма.

Основными принципами проектирования ПО являются:

1. Принцип системного единства. Все программы, входящие в систему должны представлять единое целое.

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

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

4. Принцип совместимости. Все программные модули, входящие в состав разрабатываемой системы должны быть совместимы друг с другом по форматам данных.

При решении задач очень часто требуется разработка математической модели предметной области.

МАТЕМАТИЧЕСКАЯ МОДЕЛЬ объекта позволяет поставить задачу математически и тем самым свести решение реальной задачи к решению задачи математической.

Построение математических моделей - целая наука. Будут также специальные дисциплины. Мы же пока должны усвоить, что построение математической модели реальной задачи состоит из трех основных этапов(шагов):

1) Формулирование допущений и предположений, принимаемых при построении модели, т.е. здесь выделяются и описываются математически наиболее существенные стороны задачи и пренебрегаются несущественные и второстепенные; задаются требования к точности.

2) Определение того, что считается входными данными модели, а что выходными-результатами.

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