Это два тесно связанных процесса.
В процеесе постановки задачи:
а) четко формулируют назначение и основные требования к ИС и его результатам,
б) выявляются ограничения, существующие для достижения целей ИС и выполнения требований.
Установление требований– процесс ЖЦ программы, во время которого требования заказчика уточняются, формализуются и документируются. Требования к системе это формулировка:
а) сути системного сервиса (функциональные требования) и
б) ограничений.
Формулировка сути сервиса:
1) Определение функции, кототрые должно выполнять разрабатываемое ПО. Характеризует поведение системы по отношению к пользователям. Это определение бизнес - правил, которые должны всегда выполняться, например, «двухнедельная зарплата выплачивается в среду» или «стипендия студентам начисляется до 25 числа месяца» и т.д. Основной решаемый вопрос – «Что должна делать будущая система?»
2)Формулирование вычислительных операций. Это может быть связана с вычислениями, которые должна прозвести система, например, «начислять стипендию студентам в текущем семестре на основе их успеваемости в предыдущем семестре с использованием конкретной формулы».
Формулировка ограничений выражает ограничивающие условия:
а)на поведение системы
б)разработку системы.
в) эксплуатацию системы
Примером первого ограничения может быть ограничение на безопасность, например, : «только непосредственные руководители могут обращаться к информации об зарплате их персонала». Пример второго типа ограничения: » разработчики должны использовать средство разработки Delphi 7».
Задачей этапа установления требований является определение, анализ и обсуждение требований с заказчиком. Если ПО имеет прототипы, то требования определяют по аналогии, учитывая структуру и характеристики уже существующего ПО. Если аналогов нет, то необходимо провести предпроектные исследования.
На этом этапе применяются различные методы сбора информации от заказчиков: интервью, анкеты, изучение первичных документов, отчетов и т.д. т.е. смесь фрагментов на естественном языке, различных таблиц и диаграмм. Такая смесь, должна быть понятной пользователю, не ориентирующемуся в специальных программистских понятиях. Обычно в определении требований не содержится формализованных фрагментов, кроме случаев достаточно для этого подготовленных пользователей (например, математически) - формализация этих требований составляет содержание дальнейшей работы коллектива разработчиков.
Формулируется цель решения задачи и подробно описывается ее содержание:
- что дано,
- что необходимо найти, получить;
- как определить решение;
- какие данные должны быть подготовлены и источники их получения.
Этап постановки задачи заканчивается разработкой технического задания, фиксирующего принципиальные требования, и принятием основных проектных решений.
На этапе анализа тебований ТЗ формулируют содержательную постановку задачи, выбирают математический аппарат формализации, строят модель предметной области, определяют подзадачи и выбирают или разрабатывают методы их решения.
Неправильное понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль требуемого ПС в среде его использования. Поэтому важной задачей при создании определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот контекст в определении требований представить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т.п.) и характеристики связей между ними.
Известны три способа разработки определения требований к ПС:
· управляемая пользователем разработка,
· контролируемая пользователем разработка,
· независимая от пользователя разработка.
В управляемой пользователем разработке определения требований к ПС определяются заказчиком, представляющим организацию пользователей. Это происходит обычно в тех случаях, когда организация пользователей (заказчик) заключает договор на разработку требуемого ПС с коллективом разработчиков и требования к ПС являются частью этого договора. Роль разработчика ПС в создании этих требований сводится, в основном, в выяснении того, насколько понятны ему эти требования с соответствующей критикой рассматриваемого документа. Это может приводить к созданию нескольких редакций этого документа в процессе заключения указанного договора.
В контролируемой пользователем разработке требования к ПС формулируются разработчиком при участии представителя пользователей. Роль пользователя в этом случае сводится к информированию разработчика о своих потребностях в ПС, а также к контролю того, чтобы формулируемые требования действительно выражали его потребности в ПС. Разработанные требования, как правило, утверждаются представителем пользователя.
В независимой от пользователя разработке требования к ПС определяются без какого-либо участия пользователя (на полную ответственность разработчика). Это происходит обычно тогда, когда разработчик решает создать ПС широкого применения в расчете на то, разработанное им ПС найдет спрос на рынке программных средств.
С точки зрения обеспечения надежности ПС наиболее предпочтительным является контролируемая пользователем разработка.
Анализ требований включает переговоры между разработчиками и
заказчиками для исключения противоречивых и дублирующихся требований, а также согласования стоимости системы и сроков разработки.
Этап планирования и анализа требований
Цель:
- получение требований ;
- выработка производных от них требований для этапа оценки безопасности.
Входные данные:
- требования к системе, аппаратный интерфейс, архитектура системы;
- план разработки ПО;
- стандарты на требования к ПО.
Первичный результат - данные о требованиях.
Основные принципы:
- интерфейсные и функциональные требования к системе, реализуемые на базе ПО, должны быть проанализированы на предмет противоречий, несоответствия и неопределенности;
- неадекватные и некорректные входные данные должны быть направлены на выработавшие их подэтапы для разъяснения или исправления;
- каждое требование к системе, реализуемое на базе ПО, должно быть включено в требования;
- должны быть особо отмечены требования , соответствующие системным требованиям по предотвращению выхода системы из строя;
- требования должны соответствовать стандартам на требования к ПО;
- требования должны формулироваться в количественных терминах;
- требования не должны описывать детали разработки или тестирования, за исключением указанных и проверенных ограничений конструкции;
- каждое системное требование, реализуемое на базе ПО, должно быть сводимо к одному или более требованиюУ к ПО;
- каждое требование , за исключением производных требований, должно быть сводимо к одному или нескольким системным требованиям;
- производные требования должны быть направлены этапу оценки безопасности системы.
Проектирование –процесс ЖЦ ИС, во время которого исследуется ее структура и взаимосвязи элементов. Основной решаемый вопрос – «Как система будет удовлетворять полученным требованиям?»
Проектирование должно выполняться как архитектуры системы в целом, так и архитектуры программного обеспечения.
Проектирование ПО должно проводиться на двух уровнях
1) Проектирование архитектуры ПО (проектирование «в большом»). Архитектура программного продукта – это его представление как системы, состоящей из некоторой совокупности взаимодействующих подсистем (отдельных программ, модулей) (декомпозиция системы). Здесь необходимо определить основные компоненты ПО и их взаимосвязи.
2) Детальное проектирование ПО (проектирование программных модулей(компонентов), проектирование «в малом»).
Основными принципами проектирования ПО являются:
1. Принцип системного единства. Все программы, входящие в систему, должны представлять единое целое.
2. Принцип развития. Заключается в том, что к готовой системе в дальнейшем можно добавить новые программные модули или модернизировать уже существующие.
3. Принцип стандартизации. При разработке программного продукта должны использоваться стандартные инструментальные средства.
4. Принцип совместимости. Все программные модули, входящие в состав разрабатываемой системы, должны быть совместимы друг с другом по форматам данных.
Результатом анализа и проектировния должен стать проект, содержащий достаточное количество информации для реализации системы на его основе. Должна быть получена детальная модель разрабатываемого ПО вместе с описанием его компонентов. Тип модели зависит от выбранного подхода (структурный, объектный или компонентный) и конкретной технологии проектирования. Их различие состоит в разных способах декомпозиции систем.
Структурная (функциональная) декомпозиция рассматривает структуры системы в терминах иерархии функций и передачи информации. Здесь в качестве модульной структуры программы используется древовидная структура. В узлах такого дерева размещаются программные модули, а направленные дуги показывают статическую подчиненность модулей.
Самостоятельно (подробности) проектирования ПО при структурном подходе .
Объектная декомпозиция рассматривает структуру объектов и связей между ними, а также поведение системы в терминах обмена сообщений между объектами.
Компонентныйподход предполагает построение ПО из отдельных компонентов, т.е. физически отдельно существующих частей, которые взаимодействуют между собой через стандартизированные интерфейсы.
В нашем курсе мы будем знакомиться только со структурной т.к. у
вас будет дисциплина «Объектно-ориентированное программирование», где вы познакомитесь с объектно-ориентированой методологией.
Независимо от используемого подхода процесс проектирования охватывает как проктировние программ (подпрограмм) и определение взаимосвязей между ними, так и проектирование данных, с которыми взаимодействуют эти программы и подпрограммы.
Различают два аспекта проектирования:
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) Получение математических соотношений, связывающих выходные данные с входными с учетом принятых допущений и ограничений.
