Анализ требований является первой фазой разработки ПО, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем ПО известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.
Список требований к разрабатываемой системе должен включать:
· совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отношение);
· описание выполняемых системой функций;
· ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности) определения. На этом этапе определяются:
· архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и ПО;
· интерфейсы и распределение функций между человеком и системой;
· требования к программным и информационным компонентам ПО, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонентов ПО, их интерфейсы.
Структурные технологии анализа.
В 70 - 80-х гг. при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы.
Под структурным анализом принято называть метод исследования системы, который начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Суть его в разбиении системы на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов. Для таких методов характерно
· разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней;
· ограниченный контекст, включающий лишь существенные на каждом уровне детали; использование строгих формальных правил записи;
· последовательное приближение к конечному результату.
Все методологии структурного анализа базируются на ряде общих принципов, в качестве двух базовых принципов используются следующие:
· декомпозиции системы, который является принципом решения трудных задач путем разбиения их на множество меньших независимых задач, легких для решения;
· принцип иерархического упорядочивания, который заключается в организации составных частей задачи в иерархические структуры.
Кроме того, важными принципами являются:
· принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
· принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
· принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
· принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными.
Перечисленные средства в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой.
CASE-средства.
Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:
• неадекватную спецификацию требований;
• неспособность обнаруживать ошибки в проектных решениях;
•низкое качество документации, снижающее эксплуатационные характеристики;
• затяжной цикл и неудовлетворительные результаты тестирования.
С другой стороны, разработчики ИС исторически всегда стояли последними в ряду тех, кто использовал компьютерные технологии для повышения качества, надежности и производительности в своей собственной работе (феномен «сапожника без сапог»).
Перечисленные факторы способствовали появлению программно-технологических средств специального класса - СASE-средств (Computer Aided Software Engineering), реализующих CASE-технологию создания и сопровождения ИС.
CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь"
Структурные модели.
SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает из формального определения модели в SADT. В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка - сама методология SADT. Графический язык SADT обеспечивает структуру и точную семантику естественному языку модели. Графический язык SADT организует естественный язык вполне определенным и однозначным образом.
С точки зрения SADT, модель может описывать либо на функции системы, либо её объекты. SADT-модели, ориентированные на функции, принято называть функциональными моделями, а ориентированные на объекты системы - моделями данных, функциональная модель представляет с требуемой степенью детализации систему функций, которые в свою очередь отражают свои взаимоотношения через объекты системы. Модели данных дуальны к функциональным моделям и представляют собой подробное описание объектов системы, связанных системными функциями. Полная методология SADT поддерживает создание множества моделей для более точного описания сложной системы.
Диаграммы потоков данных.
Диаграммы потоков данных (DFD) являются основным средством функционального моделирования проектируемой системы. Для изображения DFD традиционно используются две различные нотации: Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson).
В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных, описывающих процесс преобразования информации от ее ввода в систему до выдачи пользователю. С помощью этих диаграмм система разбивается на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств — продемонстрировать, как каждый процесс преобразует входные данные в выходные, а также выявить отношения между этими процессами. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно. Внешняя сущность- информационная структура вне контекста системы, являющуюся источником или приемником данных. Данные, при помощи потоков данных, являющиеся механизмами, для моделирования передачи информации из одной части системы в другую. Продуцирование выходных потоков из входных осуществляется информационными процессами. Хранилище данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами.
Задача множества DFD заключается в том, чтобы осуществить правильную декомпозицию системы, с целью показать функционирование системы ясными и понятными на каждом уровне детализации.